ORA-600(qctopn1)错误

Posted on 2012/07/12 by yangtingkun

客户11.2.0.2环境数据库出现这个ORA-600错误。
详细错误信息如下：

Tue Jun 12 09:50:47 2012
Errors IN file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_28252.trc (incident=329000):
ORA-00600: internal error code, arguments: [qctopn1], [], [], [], [], [], [], [], [], [], [], []
Incident details IN: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_329000/orcl2_ora_28252_i329000.trc
Tue Jun 12 09:51:21 2012
Dumping diagnostic DATA IN directory=[cdmp_20120612095121], requested BY (instance=2, osid=28252), summary=[incident=329000].
Tue Jun 12 09:51:21 2012
USE ADRCI OR Support Workbench TO package the incident.
See Note 411.1 at My Oracle Support FOR error AND packaging details.
Tue Jun 12 09:51:22 2012
Sweep [inc][329000]: completed
Sweep [inc2][329000]: completed

导致这个错误的原因在于CREATE TABLE语句执行的时候尝试对子查询接嵌套。详细的描述可以参考Bug 10398457 – ORA-600 [qctopn1] from disjunctive Subquery Unnest on a CREATE TABLE as SELECT [ID 10398457.8]。这个错误确认影响的数据库版本为11.2.0.2，Oracle在11.2.0.3中FIXED了这个问题。
除了版本升级外，还可以通过设置隐含参数”_optimizer_cost_based_transformation”为FALSE，或者设置”_fix_control”的值为”4768040:OFF”来避免子查询的UNNEST。

Posted in BUG | Tagged , , , , , , | Leave a comment

删除归档出现ORA-15028错误

Posted on 2012/07/11 by yangtingkun

在10.2.0.4 RAC环境中使用RMAN删除归档报错ORA-15028。
错误信息如下：

RMAN> DELETE archivelog ALL completed BEFORE 'sysdate-3';
Do you really want TO DELETE the above objects (enter YES OR NO)? YES
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure OF DELETE command ON ORA_DISK_1 channel at 07/10/2012 07:24:27
ORA-15028: ASM file '+DATA/archive/orcl1/1_78034_751396292.dbf' NOT dropped; currently being accessed

Oracle的MOS上对应的具体描述为：Unable to Delete an ASM File From RMAN and at OS Level ( ORA-15028 ) [ID 1472178.1]，根据文档的描述，导致这个问题的原因是部署了复制进程，而复制进程挂起，导致了文件无法删除。解决方法是停止并重启复制软件来释放文件的锁。
客户的环境中确实部署了DSG复制工具，不过客户当时为了解决问题，将整个数据库进行了重启，问题同样解决。不过这并不能说明问题就一定处在数据库实例上，因为一旦数据库重启，DSG复制对应的进程同样被释放，如果是复制工具HANG死导致的问题，那么数据库重启变相达到了复制软件进程重启的目的，所以问题同样的解决。

Posted in BUG | Tagged , , , , , , | Leave a comment

ORA-600(kffmXpGet)错误

Posted on 2012/07/10 by yangtingkun

第一次碰到Exadata上的bug。
数据库环境Exadata V2-2，数据库版本为11.2.0.2，错误信息为：

Wed Apr 25 11:32:35 2012
Errors IN file /u01/app/oracle/diag/rdbms/ods/orcl2/trace/orcl2_ora_9495.trc (incident=304808):
ORA-00600: internal error code, arguments: [kffmXpGet], [145], [69784], [], [], [], [], [], [], [], [], []
ORA-03135: connection lost contact
Incident details IN: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_304808/orcl2_ora_9495_i304808.trc
USE ADRCI OR Support Workbench TO package the incident.
See Note 411.1 at My Oracle Support FOR error AND packaging details.
opidcl aborting process UNKNOWN ospid (9495) AS a RESULT OF ORA-600
Wed Apr 25 11:32:36 2012
Dumping diagnostic DATA IN directory=[cdmp_20120425113236], requested BY (instance=2, osid=9495), summary=[incident=304808].
Wed Apr 25 11:32:36 2012
Sweep [inc][304808]: completed
Sweep [inc2][304808]: completed
Wed Apr 25 11:32:39 2012
Errors IN file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_pmon_10797.trc (incident=302224):
ORA-00600: internal error code, arguments: [kffmXpGet], [181], [87276], [], [], [], [], [], [], [], [], []
Incident details IN: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_302224/orcl2_pmon_10797_i302224.trc
Dumping diagnostic DATA IN directory=[cdmp_20120425113240], requested BY (instance=2, osid=10797 (PMON)), summary=[incident=302224].
USE ADRCI OR Support Workbench TO package the incident.
See Note 411.1 at My Oracle Support FOR error AND packaging details.
Errors IN file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_pmon_10797.trc:
ORA-00600: internal error code, arguments: [kffmXpGet], [181], [87276], [], [], [], [], [], [], [], [], []
PMON (ospid: 10797): terminating the instance due TO error 472
Wed Apr 25 11:32:41 2012
opiodr aborting process UNKNOWN ospid (11248) AS a RESULT OF ORA-1092
Wed Apr 25 11:32:41 2012
opiodr aborting process UNKNOWN ospid (1967) AS a RESULT OF ORA-1092
Wed Apr 25 11:32:42 2012
ORA-1092 : opitsk aborting process
Wed Apr 25 11:32:43 2012
License high water mark = 573
Instance TERMINATED BY PMON, pid = 10797
USER (ospid: 8755): terminating the instance
Instance TERMINATED BY USER, pid = 8755

由于ORA-600[kffmXpGet]错误的出现，最终出现了ORA-1092的错误，并致使opitsk进程退出，导致数据库实例崩溃。
Oracle在MOS文档Bug 12387467 instance crash by ORA-600 [kffmxpget]中描述了这个问题，确认影响的版本为11.2.0.1、11.2.0.2、11.2.0.3，Oracle在11.2.0.2 的Bundle Patch 16 for Exadata以及11.2.0.3 Bundle Patch 5 for Exadata中fixed了这个问题，Oracle计划在11.2.0.4和12.1中彻底Fixed该问题。
这个错误只会发生在Exadata中，因为导致错误的原因和Smart Scan有关。当会话执行Smart Scan操作时使用了Ctrl + C中止该操作，会导致PMON进程出现这个600错误。Oracle建议在执行数据文件的SHRINK操作前，中止并退出所有执行Exadata Smart Scan的会话。

Posted in BUG | Tagged , , , , , , , , , , | Leave a comment

数据安全警示录——Oracle DBA手记4

Posted on 2012/07/09 by yangtingkun

Eygle的新书经历了4个多月的等待，终于面世了。
我应该是这本书的第一个读者，4个月前Eygle刚刚完成初稿的时候，我就完整的看过一遍了。
我平常看书比较慢，不过那次却看得很快。一方面是由于大部分案例都比较熟悉；另一方面得益于Eygle的文笔，把故障原因、分析过程、解决思路和处理过程描述得非常清晰，给人一种一气呵成的感觉。导致我这个帮忙审稿的，多次都陷入到具体的内容中了，虽然对于我来说看得很爽，但是对于审稿而言并不是一件好事。审稿应该始终站在一个中立的角度，而如果在审稿的过程中过于关注内容，就会忽略掉一些细节的问题。好在Eygle对于自己文章的严谨程度很高，因此通篇看完也没有发现多少不妥之处，估计也不会遗漏太多的问题。
书中的所有内容都来自真实的案例，而且其中有三个个重要的案例都是来自2011年12月30日到2011年12月31日这两天。在2012年元旦马上要来临之前，Eygle接连帮助三个客户进行了数据库的恢复，这件事刺激了Eygle，于是元旦回来，Eygle就开始构思并执笔他的新作。一个多月的时间，这本《数据安全警示录》就基本上完成了。
上次看得是电子版，拿到实体书后感觉这次的印刷质量还是很不错的，等有空的话还要再把这本书再看一遍。

Posted in BOOKS | Leave a comment

ORA-600(kfnsBackground03)错误

Posted on 2012/07/08 by yangtingkun

客户的数据库出现了ORA-600(kfnsBackground03)错误。
数据库版本为10.2.0.3 RAC for HP-UX 11.23。这个错误在ASM实例和数据库实例都可能出现，如果发生在ASM实例，并不会导致ASM实例的崩溃，但是如果发生在数据库实例，则会导致数据库实例被强制关闭：

Tue May 15 10:28:05 2012
NOTE: DATABASE ORCL1:ORCL failed during msg 19, reply 2
Tue May 15 10:32:50 2012
NOTE: DATABASE ORCL1:ORCL failed during msg 19, reply 2
Tue May 15 10:33:05 2012
NOTE: DATABASE ORCL1:ORCL failed during msg 19, reply 2
Tue May 15 10:34:44 2012
NOTE: DATABASE ORCL1:ORCL failed during msg 19, reply 2
Tue May 15 10:43:05 2012
NOTE: DATABASE ORCL1:ORCL failed during msg 19, reply 2
Tue May 15 10:46:13 2012
Errors IN file /u01/app/oracle/admin/+ASM/udump/+asm1_ora_18846.trc:
ORA-00600: internal error code, arguments: [kfnsBackground03], [], [], [], [], [], [], []
Tue May 15 10:46:14 2012
Trace dumping IS performing id=[cdmp_20120515104614]

上面是ASM实例的报错，下面是对应时刻数据库实例的报错：

Tue May 15 10:38:12 2012
kkjcre1p: unable TO spawn jobq slave process 
Tue May 15 10:38:12 2012
Errors IN file /u01/app/oracle/admin/ORCL/bdump/orcl1_cjq0_17957.trc:
Tue May 15 10:42:19 2012
PMON failed TO acquire latch, see PMON dump
Tue May 15 10:43:04 2012
found dead shared server 'S006', pid = (90, 4)
Tue May 15 10:43:10 2012
Errors IN file /u01/app/oracle/admin/ORCL/bdump/orcl1_j000_19938.trc:
ORA-12012: error ON auto EXECUTE OF job 42579
ORA-27468: "EXFSYS.RLM$EVTCLEANUP" IS locked BY another process
Tue May 15 10:45:06 2012
Errors IN file /u01/app/oracle/admin/ORCL/bdump/orcl1_j002_23628.trc:
ORA-12012: error ON auto EXECUTE OF job 8888975
ORA-27468: "ORCL.P_DATA_C" IS locked BY another process
Tue May 15 10:45:10 2012
Errors IN file /u01/app/oracle/admin/ORCL/bdump/orcl1_j003_23959.trc:
ORA-12012: error ON auto EXECUTE OF job 8855572
ORA-27468: "ORCL.P_DATA" IS locked BY another process
Tue May 15 10:46:14 2012
Errors IN file /u01/app/oracle/admin/ORCL/bdump/orcl1_asmb_18844.trc:
ORA-15064: communication failure WITH ASM instance
ORA-00600: internal error code, arguments: [kfnsBackground03], [], [], [], [], [], [], []
Tue May 15 10:46:14 2012
ASMB: terminating instance due TO error 15064
Tue May 15 10:46:15 2012
System state dump IS made FOR LOCAL instance
System State dumped TO trace file /u01/app/oracle/admin/ORCL/bdump/orcl1_diag_17903.trc
Tue May 15 10:46:16 2012
Shutting down instance (abort)
License high water mark = 52

如果从这次数据库的实例崩溃看，问题似乎和主机上的资源耗尽有关。在问题发生之前，数据库实例已经出现了kkjcre1p: unable to spawn jobq slave process和PMON failed to acquire latch的问题。
当时其他时刻出现这个错误时，似乎并没有确定的资源不足的信息：

Sat May 26 09:47:49 2012
NOTE: DATABASE ORCL1:ORCL failed during msg 19, reply 2
Sat May 26 09:49:44 2012
NOTE: DATABASE ORCL1:ORCL failed during msg 19, reply 2
Sat May 26 09:52:23 2012
Errors IN file /u01/app/oracle/admin/+ASM/udump/+asm1_ora_21722.trc:
ORA-00600: internal error code, arguments: [kfnsBackground03], [], [], [], [], [], [], []
Sat May 26 09:52:25 2012
Trace dumping IS performing id=[cdmp_20120526095225]

对应这个时刻的数据库告警信息为：

Sat May 26 09:52:24 2012
Errors IN file /u01/app/oracle/admin/ORCL/bdump/orcl1_asmb_21720.trc:
ORA-15064: communication failure WITH ASM instance
ORA-00600: internal error code, arguments: [kfnsBackground03], [], [], [], [], [], [], []
Sat May 26 09:52:24 2012
ASMB: terminating instance due TO error 15064
Sat May 26 09:52:25 2012
System state dump IS made FOR LOCAL instance
System State dumped TO trace file /u01/app/oracle/admin/ORCL/bdump/orcl1_diag_20837.trc
Sat May 26 09:52:26 2012
Shutting down instance (abort)
License high water mark = 46
Sat May 26 09:52:30 2012
Instance TERMINATED BY ASMB, pid = 21720
Sat May 26 09:52:31 2012
Instance TERMINATED BY USER, pid = 536

这次错误的出现并没有任何其他的信息，数据库实例就直接DOWN掉了。不过每次在出现这个错误时，ASM实例上都会存在告警信息：NOTE: database ORCL1:ORCL failed during msg 19, reply 2。这说明ASM实例和数据库的通信存在了问题。kfnsBackground是Kernel Files Network Service Background的缩写。其中MSG 19是指IOSTAT，而reply 2指的是TIMEOUT，这说明ASM在进行io操作是出现了timeout导致了ASM的异常并导致实例的崩溃。
这个错误相对比较罕见，整个METALINK中，只有3篇文章和这个错误相关，其中两篇是和归档路径空间不足导致系统HANG住，最终导致IO的TIMEOUT，并产生了错误；而另外一篇则没有进一步的信息。其中这三次错误对应的版本分别是10.2.0.4 FOR AIX、10.2.0.4 FOR SOLARIS和10.2.0.3 FOR HPUX，这说明这个错误和平台没有关系，但是问题集中在10.2.0.3和10.2.0.4版本上。
根据上面的分析，应该部署操作系统信息监控工具，以便于随时观察系统资源的使用情况，在出现类似的错误可以进行辅助分析。由于这个问题没有出现在10.2.0.5中的记录，因此把数据库升级到10.2.0.5有可能避开这个问题。

Posted in BUG | Tagged , , , , | Leave a comment

DROP PARTITION为什么不进回收站

Posted on 2012/07/07 by yangtingkun

前几天在给公司的员工讲一个案例的提到这个问题。
其实当时提到了这个特点，DROP TABLE会进入回收站，但是DROP PARTITION并不会，因此DROP PARTITION之后，数据无法简单的回复，只能通过逻辑或物理备份的方式来进行数据的回复。

SQL> CREATE TABLE t_drop (id NUMBER);
TABLE created.
SQL> DROP TABLE t_drop;
TABLE dropped.
SQL> SELECT object_name, original_name FROM recyclebin;
OBJECT_NAME ORIGINAL_NAME
------------------------------ --------------------------------
BIN$xJhZqpmfWZXgRDzZK0pZWw==$0 T_DROP
SQL> CREATE TABLE t_part_drop (id NUMBER) partition BY range (id) 
2 (partition p1 VALUES less than (10), 
3 partition p2 VALUES less than (20), 
4 partition p3 VALUES less than (30), 
5 partition pmax VALUES less than (maxvalue));
TABLE created.
SQL> INSERT INTO t_part_drop SELECT rownum FROM user_objects;
176 ROWS created.
SQL> commit;
Commit complete.
SQL> ALTER TABLE t_part_drop DROP partition p1;
TABLE altered.
SQL> SELECT object_name, original_name FROM recyclebin;
OBJECT_NAME ORIGINAL_NAME
------------------------------ --------------------------------
BIN$xJhZqpmfWZXgRDzZK0pZWw==$0 T_DROP

本来只是普及一下这个常识，不过有人问我Oracle为什么没有实现将删除分区放在回收站中。这个问题问的很好，因为如果这个功能很容易实现，那么Oracle肯定早就实现了，而到了11.2中Oracle仍然没有实现这个功能，那么一定说明这个功能不是无法实现，就是实现的困难太大。
回收站的实现并不复杂，当一张表被删除的时候，Oracle没有直接释放表在表空间上的空间占用，而是将表简单的打了个标识，这样在正常查询数据字典时就不会看到这张被删除的表，而如果需要恢复这张表时，只需要将标识位改回来既可。
那么同样是修改数据字典，为什么不能将被删除的分区通过标识的方法放到回收站中呢，这是因为，对于表而言，删除操作是将一个整理完全删除。而对于分区的删除，是删除整体中的一个部分。对于删除这个动作其实并没有太大的影响，但是回收站的功能不是为了删除，而是为了可以快速的恢复。对表而言，直接恢复整体不存在任何的问题，即使同名对象存在，也只需改个名字既可。而对于删除分区的恢复而言，问题就不那么简单了。由于分区表并没有删除，因此这个表仍然可以继续进行操作，虽然某个分区被删除了，但是除非是范围分区中的MAXVALUE分区和列表分区中的DEFAULT分区，否则再插入原分区对应的数据时，并不会报错，而是会插入到其他分区中：

SQL> SELECT * FROM t_part_drop partition (p2);
        ID
----------
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
10 ROWS selected.
SQL> INSERT INTO t_part_drop VALUES (5);
1 ROW created.
SQL> SELECT * FROM t_part_drop partition (p2);
        ID
----------
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
         5
11 ROWS selected.

原表应该插入分区P1的数据，由于分区P1被删除，因此现在满足分区P2的条件，被插入到分区P2中，考虑这种情况下，如果直接恢复P1分区会怎样。
显然这不是一个简单的数据字典的修改就能解决的问题，不但涉及到分区数据改变的问题，还必然会带来全局和本地索引失效的问题，更重要的是，可能带来主键冲突的情况。
这还只是分区表进行了DML的情况，如果删除分区后，分区表又进行了DDL，比如新SPLIT了P1分区，那么删除分区的恢复操作就更无法进行了。
如果一个功能觉得很简单就可以实现，但是Oracle却一直没有实现，那么很可能实现这个功能并不像想象的那么简单。

Posted in ORACLE | Tagged , , , , | Leave a comment

11gr2增强CREATE OR REPLACE TYPE功能

Posted on 2012/07/06 by yangtingkun

11.2对于CREATE OR REPLACE TYPE语句进行了增加，增加了FORCE选项。
在11.2之前，只要有其他的表或TYPE依赖了当前对象，这个对象就无法进行REPLACE了：

SQL> CREATE TYPE t_num_tab IS TABLE OF NUMBER;
2 /
TYPE created.
SQL> CREATE TYPE t_record IS object (id NUMBER, n_tab t_num_tab);
2 /
TYPE created.
SQL> CREATE OR REPLACE TYPE t_num_tab IS TABLE OF NUMBER(5);
2 /
CREATE OR REPLACE TYPE t_num_tab IS TABLE OF NUMBER(5);
*
ERROR at line 1:
ORA-02303: cannot DROP OR REPLACE a TYPE WITH TYPE OR TABLE dependents

这是11.2之前的情况，尝试执行CREATE OR REPLACE将会导致ORA-2303错误，在11.2中Oracle增加了FORCE功能，使得一个仅被TYPE所依赖的对象仍然可以执行REPLACE的操作：

SQL> CREATE OR REPLACE TYPE t_num_tab force IS TABLE OF NUMBER(5);
2 /
TYPE created.
SQL> SELECT * FROM v$version;
BANNER
--------------------------------------------------------------------------------
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS FOR Solaris: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

有意思的是，FORCE语句的位置不对则不会生效，这时同样会报ORA-2303的错误，而并不会导致语句错误：

SQL> CREATE OR REPLACE force TYPE t_num_tab IS TABLE OF NUMBER(5);
CREATE OR REPLACE force TYPE t_num_tab IS TABLE OF NUMBER(5)
*
ERROR at line 1:
ORA-02303: cannot DROP OR REPLACE a TYPE WITH TYPE OR TABLE dependents
 
SQL> CREATE OR REPLACE TYPE t_num_tab IS TABLE OF NUMBER(5) force;
2 /
CREATE OR REPLACE TYPE t_num_tab IS TABLE OF NUMBER(5) force;
*
ERROR at line 1:
ORA-02303: cannot DROP OR REPLACE a TYPE WITH TYPE OR TABLE dependents

最后这个功能只对被TYPE所依赖的对象有效，一旦对象被表所依赖，则FORCE功能也不起作用：

SQL> CREATE TABLE t_type_tab (id NUMBER, c_tab t_num_tab)
2 nested TABLE c_tab store AS c_tab_tab;
TABLE created.
SQL> CREATE OR REPLACE TYPE t_num_tab force IS TABLE OF NUMBER(6);
2 /
CREATE OR REPLACE TYPE t_num_tab force IS TABLE OF NUMBER(6);
*
ERROR at line 1:
ORA-22866: cannot REPLACE a TYPE WITH TABLE dependents

Oracle的错误信息也变成了ORA-22866。其实这时可以预料的，因为一旦创建了表，就相当于进行了实体化的工作，如果依赖的类型发生了变化，将会影响表中已有的数据的读写。不过其实Oracle可以做到更进一步，就是如果表段没有创建或者表中没有插入数据的情况下，允许对依赖的对象进行修改。

Posted in ORACLE | Tagged , , , , | Leave a comment

10g RMAN的REDUNDANCY策略改变

Posted on 2012/07/05 by yangtingkun

最近发现10g的RMAN备份保留REDUNDANCY策略和9i相比发生了改变。
在Oracle9i中，备份保留策略的REDUNDANCY的值，指的是备份冗余的个数。也就是说，如果REDUNDANCY设置为1，那么Oracle会保留2个备份。
但是在10g以后，REDUNDANCY的值，就是最终备份保留的值，手头没有10g的环境，用11g的rman做了一个例子：

solaris*orcl-/home/oracle$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production ON Sun Jul 8 19:04:43 2012
Copyright (c) 1982, 2011, Oracle AND/OR its affiliates.  ALL rights reserved.
connected TO target DATABASE: ORCL (DBID=1299676637)
RMAN> SHOW retention policy;
USING target DATABASE control file instead OF recovery catalog
RMAN configuration parameters FOR DATABASE WITH db_unique_name ORCL are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # DEFAULT
RMAN> backup tablespace ts_32k;
Starting backup at 08-JUL-12
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=180 device TYPE=DISK
channel ORA_DISK_1: starting FULL datafile backup SET
channel ORA_DISK_1: specifying datafile(s) IN backup SET
INPUT datafile file NUMBER=00005 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_ts_32k_7w1w3zmb_.dbf
channel ORA_DISK_1: starting piece 1 at 08-JUL-12
channel ORA_DISK_1: finished piece 1 at 08-JUL-12
piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_07_08/o1_mf_nnndf_TAG20120708T190559_7zltdqxy_.bkp tag=TAG20120708T190559 comment=NONE
channel ORA_DISK_1: backup SET complete, elapsed TIME: 00:00:01
Finished backup at 08-JUL-12
RMAN> backup tablespace ts_32k;
Starting backup at 08-JUL-12
USING channel ORA_DISK_1
channel ORA_DISK_1: starting FULL datafile backup SET
channel ORA_DISK_1: specifying datafile(s) IN backup SET
INPUT datafile file NUMBER=00005 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_ts_32k_7w1w3zmb_.dbf
channel ORA_DISK_1: starting piece 1 at 08-JUL-12
channel ORA_DISK_1: finished piece 1 at 08-JUL-12
piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_07_08/o1_mf_nnndf_TAG20120708T190609_7zltf22b_.bkp tag=TAG20120708T190609 comment=NONE
channel ORA_DISK_1: backup SET complete, elapsed TIME: 00:00:02
Finished backup at 08-JUL-12
RMAN> list backup OF tablespace ts_32k;
 
List OF Backup Sets
===================
 
BS KEY  TYPE LV SIZE       Device TYPE Elapsed TIME Completion TIME
------- ---- -- ---------- ----------- ------------ ---------------
20      FULL    2.69M      DISK        00:00:01     08-JUL-12      
        BP KEY: 20   STATUS: AVAILABLE  Compressed: NO  Tag: TAG20120708T190559
        Piece Name: /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_07_08/o1_mf_nnndf_TAG20120708T190559_7zltdqxy_.bkp
  List OF Datafiles IN backup SET 20
  File LV TYPE Ckp SCN    Ckp TIME  Name
  ---- -- ---- ---------- --------- ----
  5       FULL 28932281   08-JUL-12 /u01/app/oracle/oradata/ORCL/datafile/o1_mf_ts_32k_7w1w3zmb_.dbf
BS KEY  TYPE LV SIZE       Device TYPE Elapsed TIME Completion TIME
------- ---- -- ---------- ----------- ------------ ---------------
21      FULL    2.69M      DISK        00:00:01     08-JUL-12      
        BP KEY: 21   STATUS: AVAILABLE  Compressed: NO  Tag: TAG20120708T190609
        Piece Name: /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_07_08/o1_mf_nnndf_TAG20120708T190609_7zltf22b_.bkp
  List OF Datafiles IN backup SET 21
  File LV TYPE Ckp SCN    Ckp TIME  Name
  ---- -- ---- ---------- --------- ----
  5       FULL 28932300   08-JUL-12 /u01/app/oracle/oradata/ORCL/datafile/o1_mf_ts_32k_7w1w3zmb_.dbf
RMAN> DELETE obsolete;
RMAN retention policy will be applied TO the command
RMAN retention policy IS SET TO redundancy 1
USING channel ORA_DISK_1
Deleting the following obsolete backups AND copies:
TYPE                 KEY    Completion TIME    Filename/Handle
-------------------- ------ ------------------ --------------------
Backup SET           20     08-JUL-12         
  Backup Piece       20     08-JUL-12          /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_07_08/o1_mf_nnndf_TAG20120708T190559_7zltdqxy_.bkp
Do you really want TO DELETE the above objects (enter YES OR NO)? yes
deleted backup piece
backup piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_07_08/o1_mf_nnndf_TAG20120708T190559_7zltdqxy_.bkp RECID=20 STAMP=788123159
Deleted 1 objects

可以看到，从10g开始设置的REDUNDANCY的值，就是最终备份保留的个数。为了确认这个问题，特意查询了一下9i和10g的官方文档。
9i的说法是：

The REDUNDANCY parameter specifies that any NUMBER OF backups OR copies beyond a specified NUMBER need NOT be retained.

而10g的文档中，该参数的描述变为：

A redundancy-based backup retention policy determines whether a backup IS obsolete based ON how many backups OF a file are currently ON disk.

Oracle改变功能的实现很常见，但是没有想到，对于这种细节的定义也会调整。对于熟悉9i备份策略的DBA需要留神，在设置10g以后的RMAN备份保留策略时，需要在9i的基础上增加1。

Posted in ORACLE | Tagged , , , , , | Leave a comment

9iRAC环境遭遇library cache lock和library cache load lock等待

Posted on 2012/07/04 by yangtingkun

客户数据库版本为9208 RAC FOR AIX，客户反应系统缓慢，检查告警日志，发现大量Library cache lock和Library cache load lock等待。
由于客户的原因，这个问题只是远程协助的方式帮忙检查了一下，因此没有留下任何的操作记录，这里只是简单描述一下问题。
客户反应数据库操作响应变慢，平时一个执行很快的基于主键的UPDATE操作也变得异常缓慢，且执行计划本身并未发生改变。
登录数据库后检查两个节点上的告警日志，并未发现任何异常报错。分别检查两个实例的等待信息，发现除了上面提到的大量Library cache lock和Library cache load lock以外，还有明显的gc等待。
但是随后发现，查询V$SESSION和GV$SESSION的结果居然没有区别，接着查询GV$INSTANCE视图，发现只有当前的实例存在，而此时恰好连接另一个节点的工具出现了断连，以至于我一度以为另外一个节点上的实例已经DOWN掉，但是随后重新登录到该节点上，发现数据库实例仍然存在，而且登录到数据库实例中也可以进行任何正常的操作。不过发现在当前节点所有的GV$视图都只会返回当前实例的信息，这与另外一个节点的情况完全一样。显然两个节点间的通信出现了问题，当前节点已经不清楚另外一个节点的状态的。
现在再去分析那些等待信息已经没有太多的意义了，因为整个数据库已经处于不正常的状态。不难推断，当前数据库的异常是由于节点间的通信异常导致。由于9i使用的操作系统的CLUSTER，还没有Oracle的clusterware，剩下只能由操作系统或硬件维护人员去进一步跟踪了。
最终数据库和系统在夜间闲时进行了重启操作，重启后数据库恢复正常，GV$视图的结果也恢复了正常。

Posted in ORACLE | Tagged , , , , , | Leave a comment

DBMS_OUTPUT包无法输出空行

Posted on 2012/07/03 by yangtingkun

正常情况下，DBMS_OUTPUT包无法直接输出一个空行。
以前还真没有注意这个问题，前两天想在输出结果的时候进行一下简单的格式化，发现了这个问题：

SQL> SET serverout ON
SQL> BEGIN
2 dbms_output.put_line('a');
3 dbms_output.put_line(' ');
4 dbms_output.put_line('b');
5 dbms_output.new_line; 
6 dbms_output.put_line('c');
7 END;
8 /
a
b
c
PL/SQL PROCEDURE successfully completed.

导致问题的原因在于，如果使用DBMS_OUTPUT包输出的一行都是不可见字符，那么这行内容被DBMS_OUTPUT包忽略掉。
虽然DBMS_OUTPUT包本身并没有提供开关来屏蔽这个属性，不过这个问题依然很容易解决，最简单的方法莫过于直接把回车包含在字符串中：

SQL> BEGIN
2 dbms_output.put_line('a
3 
4 b');
5 dbms_output.put_line('
6 c');
7 END;
8 /
a
b
c
PL/SQL PROCEDURE successfully completed.

当然这种方法有可能导致PL/SQL代码的可读性变差，也容易影响代码的缩进格式，此外还有一种方式：

SQL> BEGIN
2 dbms_output.put_line('a' || chr(10) || chr(13));
3 dbms_output.put_line('b');
4 dbms_output.put_line(chr(10) || chr(13) || 'c');
5 END;
6 /
a
b
c
PL/SQL PROCEDURE successfully completed.
Posted in ORACLE | Tagged , , , , | Leave a comment