Working case – 第 25 页

为什么不走hash join？

2008-06-14 4条评论

今天，某省的同事来告诉我，表重组后，他用于统计的一个sql脚本运行变慢了，之前只需要17、8分钟能出来的结果，现在1小时40分钟左右才能出来结果。我们一起来看看脚本中的一个sql：

SQL> explain plan for
  2  select a.startdate,b.subsid from tab_1 a,tab_2 b where 
  3  a.servid='025001003681' and a.status!='C' and a.mid=b.mid;

Explained.

Elapsed: 00:00:00.03

SQL> select * from table(dbms_xplan.display)
SQL> /

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                           |  Name                    | Rows  | Bytes | Cost  | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                          |   369 | 23985 |   980 |       |       |
|   1 |  NESTED LOOPS                       |                          |   369 | 23985 |   980 |       |       |
|   2 |   PARTITION HASH ALL                |                          |       |       |       |     1 |     4 |
|*  3 |    TABLE ACCESS BY LOCAL INDEX ROWID| tab_1             |   369 | 14022 |   242 |     1 |     4 |
|*  4 |     INDEX RANGE SCAN                | IDX_tab_1_SERVID  |   492 |       |    10 |     1 |     4 |
|   5 |   PARTITION HASH ITERATOR           |                          |       |       |       |   KEY |   KEY |
|   6 |    TABLE ACCESS BY LOCAL INDEX ROWID| tab_2               |     1 |    27 |     2 |   KEY |   KEY |
|*  7 |     INDEX UNIQUE SCAN               | PK_tab_2_MID        |     1 |       |     1 |   KEY |   KEY |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("A"."STATUS"<>'C')
   4 - access("A"."SERVID"='025001003681')
   7 - access("A"."MID"="B"."MID")

Note: cpu costing is off

22 rows selected.

Elapsed: 00:00:00.56

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

SQL> explain plan for

2 select a.startdate,b.subsid from tab_1 a,tab_2 b where

3 a.servid='025001003681' and a.status!='C' and a.mid=b.mid;

Explained.

Elapsed: 00:00:00.03

SQL> select * from table(dbms_xplan.display)

SQL> /

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 369 | 23985 | 980 | | |

| 1 | NESTED LOOPS | | 369 | 23985 | 980 | | |

| 2 | PARTITION HASH ALL | | | | | 1 | 4 |

|* 3 | TABLE ACCESS BY LOCAL INDEX ROWID| tab_1 | 369 | 14022 | 242 | 1 | 4 |

|* 4 | INDEX RANGE SCAN | IDX_tab_1_SERVID | 492 | | 10 | 1 | 4 |

| 5 | PARTITION HASH ITERATOR | | | | | KEY | KEY |

| 6 | TABLE ACCESS BY LOCAL INDEX ROWID| tab_2 | 1 | 27 | 2 | KEY | KEY |

|* 7 | INDEX UNIQUE SCAN | PK_tab_2_MID | 1 | | 1 | KEY | KEY |

----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

3 - filter("A"."STATUS"<>'C')

4 - access("A"."SERVID"='025001003681')

7 - access("A"."MID"="B"."MID")

Note: cpu costing is off

22 rows selected.

Elapsed: 00:00:00.56

我们看到这个sql是通过索引后在走nested l […]

..experience, Working case

职业生涯最严重的一次宕机

2008-06-12 13条评论

昨天，经历了职业生涯中最令人心惊胆颤的危机，差点要去买锄头准备回家种地去了。-_-!! 早上5点钟，被同事叫醒，说应用程序连数据库报TNS没响应。于是开始登录数据库主机。登录的时候，用常用的浮动IP连接，没响应，此时第一个反映就是是不是数据库主机挂了？难道要去机房？现在可是奥运前期，进出机房是件挺麻 […]

..experience, Working case

误将对象创建在system表空间中

2008-06-08 4条评论

昨天一位同事在执行创建数据库全量对象脚本时，在sys用户下执行了，那些本来应该在应用用户下创建的对象，不小心创建在了sys用户下。由于创建的对象是一个脚本执行的，里面有近1500个对象，要是一个一个删除，那是不可能了。由于测试部的同事急着要用，先在应用用户下重新把创建数据库对象的全量脚本再次执行了 […]

..experience, Working case

insert大量数据的一些经验

2008-06-07 2条评论

在很多时候，我们会需要对一个表进行插入大量的数据，并且希望在尽可能短的时间内完成该工作，这里，和大家分享下我平时在做大量数据insert的一些经验。前提：在做insert数据之前，如果是非生产环境，请将表的索引和约束去掉，待insert完成后再建索引和约束。 1. [crayon-6904288c […]

..experience, Working case

一次可怕的crosscheck

2008-05-23 没有评论

某省有个数据库的备份坏了，同事采取的策略是每天定期的用脚本删除归档。于是，当备份恢复的时候，需要做一次crosscheck，以便验证那些归档是validate的，于是可怕的事情发生了：crosscheck运行了1小时，还是没动静——需要crosscheck的日志太多了！！查了一下文档，原来cros […]

..experience, Working case

oracle的sysdba权限登录问题

2008-05-23 没有评论

最近的时间，在搞数据库的安全加固问题，关于数据库中关于sysdba权限的登录，通过最近的一些实践和测试，在这里记录一下：数据库用sysdba登录的验证有两种方式，一种是通过os认证，一种是通过密码文件验证；登录方式有两种，一种是在数据库主机直接登录（用os认证的方式），一种是通过网络远程登录；需要 […]

..experience, Working case

RAC的高可用也不是那么好用

2008-05-09 5条评论

oracle一直在“鼓吹”着他的rac是如何如何的高可用，如何如何的可以实现针对应用透明的failover，但是，在实际的使用过程中，要完全实现这样的透明，条件是何等的苛刻。先从一次故障说起吧。某天中午正在吃饭的时候，突然接到电话做应用程序连接数据库挂死了，并且也在客户端测试连接数据库也是挂死，长 […]

..experience, Working case

数据库迁移几种方式简单介绍

2008-04-22 没有评论

我们常常需要对数据进行迁移，迁移到更加高级的主机上、迁移到远程的机房上、迁移到不同的平台下…… 一、exp/imp：

    这也算是最常用最简单的方法了，一般是基于应用的owner级做导出导入。
   
    操作方法为：在新库建立好owner和表空间，停老库的应用，在老库做exp user/pwd owner=XXX file=exp_xxx.dmp log=exp_xxx.log buffer=6000000，传dmp文件到新库，在新库做imp user/pwd fromuser=XXX touser=XXX file=exp_xxx.dmp log=imp_xxx.log ignore=y.

         优缺点：优点是可以跨平台使用；缺点是停机时间长，停机时间为从exp到网络传输到新库，再加上imp的时间。

1

2

3

4

5

这也算是最常用最简单的方法了，一般是基于应用的owner级做导出导入。

操作方法为：在新库建立好owner和表空间，停老库的应用，在老库做exp user/pwd owner=XXX file=exp_xxx.dmp log=exp_xxx.log buffer=6000000，传dmp文件到新库，在新库做imp user/pwd fromuser=XXX touser=XXX file=exp_xxx.dmp log=imp_xxx.log ignore=y.

优缺点：优点是可以跨平台使用；缺点是停机时间长，停机时间为从exp到网络传输到新库，再加上imp的时间。

二、存储迁移：

      这种情况下，数据文件、控制文件、日志文件、spfile都在存储上（一般情况下是裸设备），我们可以直接把存储挂到新机器上，然后在新机器上启动数据库。

      操作方法：将老库的pfile（因为里面有指向裸设备的spfile链接），tnsnames.ora，listener.ora，密码文件传到新库的对应位置。将存储切至新机，或者用文件拷贝或dd的方式复制数据文件，启动数据库。

      优缺点：优点是该迁移方式非常简单，主要的工作是主机工程师的工作，dba只需配合即可，停机时间为当库、切存储、起库的时间。缺点是要求新老库都是同一平台，是相同的数据库版本。

1

2

3

4

5

这种情况下，数据文件、控制文件、日志文件、spfile都在存储上（一般情况下是裸设备），我们可以直接把存储挂到新机器上，然后在新机器上启动数据库。

操作方法：将老库的pfile（因为里面有指向裸设备的spfile链接），tnsnames.ora，listener.ora，密码文件传到新库的对应位置。将存储切至新机，或者用文件拷贝或dd的方式复制数据文件，启动数据库。

优缺点：优点是该迁移方式非常简单，主要的工作是主机工程师的工作，dba只需配合即可，停机时间为当库、切存储、起库的时间。缺点是要求新老库都是同一平台，是相同的数据库版本。

三、利用data guard迁移： […]

..experience, Working case

一次redolog丢失的恢复

2008-04-18 5条评论

接到同事的电话，某省的一个用于监控的siteview数据库启动不了了，登录后检查alertlog发现：

Completed first pass scan
 9868 redo blocks read, 655 data blocks need recovery
Thu Apr 19 16:52:42 2007
Started recovery at
 Thread 1: logseq 700, block 194931, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 3 Seq 700 Reading mem 0
  Mem# 0 errs 0: C:\ORACLE\ORADATA\IMALLSV\REDO03.LOG
Thu Apr 19 16:52:43 2007
Ended recovery at
 Thread 1: logseq 700, block 204799, scn 0.147914177
 655 data blocks read, 655 data blocks written, 9868 redo blocks read
Crash recovery completed successfully
Thu Apr 19 16:52:43 2007
Errors in file c:\oracle\admin\imallsv\bdump\imallsv_lgwr_4180.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\IMALLSV\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

Thu Apr 19 16:52:43 2007
Errors in file c:\oracle\admin\imallsv\bdump\imallsv_lgwr_4180.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\IMALLSV\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

ORA-313 signalled during: alter database open...

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

Completed first pass scan

9868 redo blocks read, 655 data blocks need recovery

Thu Apr 19 16:52:42 2007

Started recovery at

Thread 1: logseq 700, block 194931, scn 0.0

Recovery of Online Redo Log: Thread 1 Group 3 Seq 700 Reading mem 0

Mem# 0 errs 0: C:\ORACLE\ORADATA\IMALLSV\REDO03.LOG

Thu Apr 19 16:52:43 2007

Ended recovery at

Thread 1: logseq 700, block 204799, scn 0.147914177

655 data blocks read, 655 data blocks written, 9868 redo blocks read

Crash recovery completed successfully

Thu Apr 19 16:52:43 2007

Errors in file c:\oracle\admin\imallsv\bdump\imallsv_lgwr_4180.trc:

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\IMALLSV\REDO01.LOG'

ORA-27041: unable to open file

OSD-04002: 无法打开文件

O/S-Error: (OS 2) 系统找不到指定的文件。

Thu Apr 19 16:52:43 2007

Errors in file c:\oracle\admin\imallsv\bdump\imallsv_lgwr_4180.trc:

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\IMALLSV\REDO01.LOG'

ORA-27041: unable to open file

OSD-04002: 无法打开文件

O/S-Error: (OS 2) 系统找不到指定的文件。

ORA-313 signalled during: alter database open...

原来是redolog被干掉了，其实对于redolog的丢失，如果丢失的不是active或者current（这个在win中一般不会被 […]

..experience, Working case

愚人节，被数据库“娱”了一下

2008-04-01 一条评论

4月1日，早上7点半正要出门的时候，被某省的同事电话叫住了，说归档目录快满了，由于带库正在备份另一个生产库，这个报表库暂时还不能用带库备份归档，想用手工删除归档日志，却无法删除，ls能列出所有文件，但是ls 某一个归档文件却报错无法找到该文件！单个文件ls不到，更别说rm了。归档目录剩下6G左右的 […]

..experience, Working case

建表空间的时候数据库宕机

2008-04-01 6条评论

今天在建表空间的时候，数据库不知道被谁停了，在建的时候报oracle not avaliable，等再次确认没有“雷锋”帮我shutdown数据库之后，startup了数据库。启动时，没有报错，提示数据库已经mount、已经open。可是，再次重建表空间的时候，却报错了数据文件已经存在： [cra […]

..experience, Working case

add column时default null的问题

2008-03-21 一条评论

昨晚在对一个省进行打patch时，发现数据库升级脚本执行了很久还没执行完，查看了一下这个执行了很久的语句：

alter table TABLE_BIG add column_a date default null;

1	alter table TABLE_BIG add column_a date default null;

类似这样的语句有好几个，而且由于其中涉及到了流水的历史表——一个非常非常大的分区表，执行时间非常的长！其中的一个已经执行了1个 […]