DDL触发器设置导致DDL无法执行(一)

公司测试数据库发现执行DDL报错。
由于篇幅所限,这里简单描述一下问题产生的现象。
打算进行个测试,结果发现建表时报错:

SQL> CREATE TABLE T_EXCHANGE (ID NUMBER, CREATED DATE, TYPE VARCHAR2(18))
   2 PARTITION BY RANGE (CREATED) SUBPARTITION BY LIST (TYPE)
   3 (PARTITION P1 VALUES LESS THAN (TO_DATE('2012-1', 'YYYY-MM'))
   4 (SUBPARTITION P1SP1 VALUES ('TABLE'),
   5 SUBPARTITION P1SP2 VALUES ('INDEX'),
   6 SUBPARTITION P1SP3 VALUES ('VIEW'),
   7 SUBPARTITION P1SP4 VALUES ('SYNONYM'),
   8 SUBPARTITION P1SP5 VALUES (DEFAULT)), 
   9 PARTITION P2 VALUES LESS THAN (TO_DATE('2012-2', 'YYYY-MM'))
  10 (SUBPARTITION P2SP1 VALUES ('TABLE'),
  11 SUBPARTITION P2SP2 VALUES ('INDEX'),
  12 SUBPARTITION P2SP3 VALUES ('VIEW'),
  13 SUBPARTITION P2SP4 VALUES ('SYNONYM'),
  14 SUBPARTITION P2SP5 VALUES (DEFAULT)),
  15 PARTITION P3 VALUES LESS THAN (MAXVALUE)
  16 (SUBPARTITION P3SP1 VALUES ('TABLE'),
  17 SUBPARTITION P3SP2 VALUES ('INDEX'),
  18 SUBPARTITION P3SP3 VALUES ('VIEW'),
  19 SUBPARTITION P3SP4 VALUES ('SYNONYM'),
  20 SUBPARTITION P3SP5 VALUES (DEFAULT)));
CREATE TABLE T_EXCHANGE (ID NUMBER, CREATED DATE, TYPE VARCHAR2(18))
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-04020: deadlock detected while trying TO LOCK object
EYGLE.BIN$trcEn8qthIjgQKjAEwAm+g==$0
ORA-06512: at line 24
 
SQL> CREATE TABLE T_EXCHANGE (ID NUMBER, CREATED DATE, TYPE VARCHAR2(18))
   2 PARTITION BY RANGE (CREATED) SUBPARTITION BY LIST (TYPE)
   3 (PARTITION P1 VALUES LESS THAN (TO_DATE('2012-1', 'YYYY-MM'))
   4 (SUBPARTITION P1SP1 VALUES ('TABLE'),
   5 SUBPARTITION P1SP2 VALUES ('INDEX'),
   6 SUBPARTITION P1SP3 VALUES ('VIEW'),
   7 SUBPARTITION P1SP4 VALUES ('SYNONYM'),
   8 SUBPARTITION P1SP5 VALUES (DEFAULT)), 
   9 PARTITION P2 VALUES LESS THAN (TO_DATE('2012-2', 'YYYY-MM'))
  10 (SUBPARTITION P2SP1 VALUES ('TABLE'),
  11 SUBPARTITION P2SP2 VALUES ('INDEX'),
  12 SUBPARTITION P2SP3 VALUES ('VIEW'),
  13 SUBPARTITION P2SP4 VALUES ('SYNONYM'),
  14 SUBPARTITION P2SP5 VALUES (DEFAULT)),
  15 PARTITION P3 VALUES LESS THAN (MAXVALUE)
  16 (SUBPARTITION P3SP1 VALUES ('TABLE'),
  17 SUBPARTITION P3SP2 VALUES ('INDEX'),
  18 SUBPARTITION P3SP3 VALUES ('VIEW'),
  19 SUBPARTITION P3SP4 VALUES ('SYNONYM'),
  20 SUBPARTITION P3SP5 VALUES (DEFAULT)));
CREATE TABLE T_EXCHANGE (ID NUMBER, CREATED DATE, TYPE VARCHAR2(18))
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 2
ORA-30511: invalid DDL operation IN system triggers
ORA-06512: at line 24

前后两次的报错信息还不一样,而且二者包含的信息都有意义。从第一次执行可以看出,执行DDL操作引发了ORA-4020死锁,而第二次则表示导致错误出现的因素和DDL触发器有关。
由于是测试环境,部署的环境比较复杂,很可能是其他组件或者某些测试代码导致DDL触发器出现错误。
检查了一下发生死锁时报错对象,这是回收站中的一个对象:

SQL> SELECT owner, object_name, original_name, operation, TYPE  
  2  FROM dba_recyclebin
  3  WHERE object_name = 'BIN$trcI7ykLAu7gQKjAEwAnkA==$0';
OWNER OBJECT_NAME                    ORIGINAL_NAME OPERATION TYPE
----- ------------------------------ ------------- --------- -----
EYGLE BIN$trcI7ykLAu7gQKjAEwAnkA==$0 T_PWD         DROP      TABLE
SQL> SELECT * FROM dba_dependencies WHERE TYPE = 'TRIGGER' AND REFERENCED_NAME IN ('T_PWD', 'BIN$trcI7ykLAu7gQKjAEwAnkA==$0');
no ROWS selected
SQL> SELECT * FROM dba_dependencies WHERE  REFERENCED_NAME IN ('T_PWD', 'BIN$trcI7ykLAu7gQKjAEwAnkA==$0');
no ROWS selected

系统中没有任何对象依赖于回收站中的这个对象,甚至没有任何对象依赖这个回收站对象删除前的原始对象。

SQL> SELECT OWNER, TRIGGERING_EVENT, COUNT(*) FROM DBA_TRIGGERS GROUP BY OWNER, TRIGGERING_EVENT ORDER BY 1;
OWNER                          TRIGGERING_EVENT                           COUNT(*)
------------------------------ ---------------------------------------- ----------
DBFW_CONSOLE_ACCESS            DDL                                               1
DBFW_CONSOLE_ACCESS            LOGOFF                                            1
DBFW_CONSOLE_ACCESS            LOGON                                             1
EXFSYS                         ALTER OR RENAME                                   1
EXFSYS                         CREATE OR ALTER                                   1
EXFSYS                         DROP                                              2
EXFSYS                         TRUNCATE                                          1
MDSYS                          CREATE                                            1
MDSYS                          DELETE                                            8
MDSYS                          DROP                                              7
MDSYS                          INSERT                                            9
MDSYS                          INSERT OR UPDATE                                  3
MDSYS                          INSERT OR UPDATE OR DELETE                        3
MDSYS                          TRUNCATE                                          1
MDSYS                          UPDATE                                            6
OLAPSYS                        DELETE                                            8
OLAPSYS                        INSERT OR UPDATE                                 40
SYS                            ALTER                                             1
SYS                            CREATE                                            2
SYS                            DROP                                              2
SYS                            SHUTDOWN                                          2
SYS                            STARTUP                                           2
SYSMAN                         DELETE                                           16
SYSMAN                         INSERT                                           18
SYSMAN                         INSERT OR UPDATE                                  6
SYSMAN                         INSERT OR UPDATE OR DELETE                        1
SYSMAN                         UPDATE                                            6
SYSMAN                         UPDATE OR DELETE                                  1
SYSTEM                         INSERT                                            1
SYSTEM                         UPDATE OR DELETE                                  1
TEST                           INSERT OR UPDATE OR DELETE                        1
WMSYS                          CREATE OR ALTER OR DROP OR RENAME                 1
WMSYS                          DROP                                              1
XDB                            DROP OR TRUNCATE                                  1
XDB                            INSERT OR UPDATE                                  1
XDB                            INSERT OR UPDATE OR DELETE                        2
XDB                            UPDATE OR DELETE                                  8
37 ROWS selected.

系统中只有一个DDL触发器,内容如下:

SQL> SELECT trigger_body FROM dba_triggers
   2 WHERE trigger_name = 'TRIGGER_LOGIN';
TRIGGER_BODY
--------------------------------------------------------------------------------
BEGIN
IF dbfw_console_access.is_local THEN
INSERT INTO dbfw_console_access.event(id,username,sessionid,event,text)
SELECT dbfw_console_access.event_seq.nextval,
sys_context('USERENV','SESSION_USER'),
sys_context('USERENV','SESSIONID'),
'LOGIN',
NULL
FROM dual;
END IF;
END;

有意思的时,回收站中报错的表是Eygle测试密码的临时表,使用完毕后被他删除。而这个触发器是Kamus测试FireWall功能创建的。而当我执行DDL时,两个完全没有关系的对象组合在一起报错。
Eygle创建并删除的表本身并没有什么特殊之处,而且已经在回收站中,就更不会对系统有什么额外的影响。相比较,Kamus创建的触发器就比较可疑了,毕竟这是一个DDL触发器,在执行DDL语句时就会触发,问题多半是这个触发器导致的。但是这个触发器实质上只有一个INSERT语句,没有道理导致死锁的产生,何况触发器和回收站中的对象完全没有任何联系。
简单的禁用或删除触发器同样会引发错误:

SQL> conn / AS sysdba
Connected.
SQL> ALTER TRIGGER DBFW_CONSOLE_ACCESS.TRIGGER_LOGIN disable;
ALTER TRIGGER DBFW_CONSOLE_ACCESS.TRIGGER_LOGIN disable
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-30511: invalid DDL operation IN system triggers
ORA-06512: at line 24
SQL> DROP TRIGGER DBFW_CONSOLE_ACCESS.TRIGGER_LOGIN;
DROP TRIGGER DBFW_CONSOLE_ACCESS.TRIGGER_LOGIN
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-30511: invalid DDL operation IN system triggers
ORA-06512: at line 24

看来问题不像想象中的那么简单,必须找到问题的原因才可以彻底解决。

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

20120222ACOUG&Oracle技术研讨会——Meeting Thomas Kyte

标题很长,没有办法,因为要表达的东西很多。
今天是ACOUG和Oracle联合组织的一期活动,和以往最大的区别在于,这一期我们请来了大名鼎鼎的Thomas Kyte,也就是ASK TOM中的Tom。正是由于Tom的明星人气,导致ACOUG的60个名额在4个小时内就已经满了。
近距离接触大师的机会是非常难得的,更难得是除了有机会聆听大师的演讲,还有机会向大师提问,唯一可惜的是,Tom对于我的提问回答是NO。当然我问的是12C的新特性,由于Oracle的策略所致,Tom无法在产品正式发布之前进行任何新特性的透露。
Tom的演讲的主体是Oracle的技术发展,总结了从9i到11g以来Oracle在各个方面所带来技术改变;而Eygle演讲的主体则是一个深入的技术细节,描述了一个数据库崩溃后如何进一步诊断和恢复。
明天在上海还有一场同样的ACOUG活动,这里预先祝愿活动圆满成功了。

Posted in NEWS | Leave a comment

获取表空间是否可自动扩展的SQL

好长时间没写SQL了,今天看到同事在使用一个检查表空间是否可自动扩展的SQL,不但效率不高,而且非常的累赘,忍不住自己写了一个。
原始SQL如下:

SQL> SELECT DISTINCT tablespace_name, autoextensible
  2 FROM DBA_DATA_FILES
  3 WHERE autoextensible = 'YES'
  4 UNION
  5 SELECT DISTINCT tablespace_name, autoextensible
  6 FROM DBA_DATA_FILES
  7 WHERE autoextensible = 'NO'
  8 AND tablespace_name NOT IN
  9 (SELECT DISTINCT tablespace_name
 10 FROM DBA_DATA_FILES
 11 WHERE autoextensible = 'YES');
TABLESPACE_NAME                AUT
------------------------------ ---
SYSAUX                         NO
SYSTEM                         NO
UNDOTBS1                       YES
USERS                          NO

这个SQL的唯一优点就是思路比较清晰,通过SQL的写法可以明确的看到作者是如何根据数据文件的可扩展性来判断表空间是否可以扩展的。
当一个表空间中只要包含一个可扩展的数据文件,则这个表空间就是可扩展的,只有表空间下所有的数据文件都是不可扩展的,这个表空间才是不可扩展的。
虽然作者的思路没有问题,但是这个SQL的写法实在不敢恭维,对DBA_DATA_FILES视图查询了三次,每次都使用了DISTINCT,同时还包含了NOT IN连接以及UNION集合。
其他的先不说,UNION在这里就完全没有意义,二者包含的结果是互斥的,那么这里至少应该使用UNION ALL。
其实这个SQL根本不需要这么麻烦,因为AUTOEXTENSIBLE只有两个取值,YES或NO,那么只需要一次查询DBA_DATA_FILES就可以得到结果:

SQL> SELECT TABLESPACE_NAME, MAX(AUTOEXTENSIBLE) 
  2  FROM DBA_DATA_FILES
  3  GROUP BY TABLESPACE_NAME;
TABLESPACE_NAME                MAX
------------------------------ ---
SYSAUX                         NO
UNDOTBS1                       YES
USERS                          NO
SYSTEM                         NO
Posted in ORACLE | Tagged , , | Leave a comment

ORA-600(kgeade_is_0)错误

一个和并行执行有关的bug。
虽然是并行执行相关,但是报错的并不是Pnnn进程,事实上,实在RAC环境中查询GV$表导致了这个错误。

Wed May 04 15:56:02 EAT 2011
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Interface TYPE 1 lan900 192.168.194.0 configured FROM OCR FOR USE AS a cluster interconnect
Interface TYPE 1 lan901 10.142.194.0 configured FROM OCR FOR USE AS a public interface
Picked latch-free SCN scheme 3
LICENSE_MAX_USERS = 0
SYS auditing IS disabled
ksdpec: called FOR event 13740 prior TO event GROUP initialization
Starting up ORACLE RDBMS Version: 10.2.0.5.0.
System parameters WITH non-DEFAULT VALUES:
processes = 2000
sessions = 3000
resource_limit = TRUE
lock_sga = FALSE
shared_pool_size = 2147483648
large_pool_size = 536870912
java_pool_size = 536870912
spfile = /oracle/spfileorcl.ora
nls_language = AMERICAN
nls_territory = AMERICA
disk_asynch_io = FALSE
sga_target = 75497472000
control_files = /oracle/control01.ctl, /oracle/control02.ctl, /oracle/control03.ctl
db_block_size = 8192
db_cache_size = 47194308608
db_keep_cache_size = 2147483648
db_writer_processes = 8
compatible = 10.2.0.5.0
log_archive_dest_1 = location=/orcl03/arch
db_file_multiblock_read_count= 16
cluster_database = TRUE
cluster_database_instances= 2
db_recovery_file_dest = /orcl02/flash_recovery_area
db_recovery_file_dest_size= 42949672960
thread = 2
fast_start_mttr_target = 300
recovery_parallelism = 6
instance_number = 2
undo_management = AUTO
undo_tablespace = UNDOTBS2
undo_retention = 7200
remote_login_passwordfile= EXCLUSIVE
db_domain =
distributed_lock_timeout = 700
dispatchers = (PROTOCOL=TCP) (SERVICE=orclXDB)
local_listener = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.142.194.10) (PORT = 1521))
remote_listener = LISTENERS_ORCL
job_queue_processes = 40
parallel_execution_message_size= 16384
_hash_join_enabled = TRUE
background_dump_dest = /oracle/app/admin/orcl/bdump
user_dump_dest = /oracle/app/admin/orcl/udump
core_dump_dest = /oracle/app/admin/orcl/cdump
audit_file_dest = /oracle/app/admin/orcl/adump
db_name = orcl
open_cursors = 2000
optimizer_index_cost_adj = 30
optimizer_index_caching = 88
query_rewrite_enabled = FALSE
pga_aggregate_target = 8589934592
Wed May 04 15:56:07 EAT 2011
Oracle instance running WITH ODM: Veritas 5.0 ODM Library, Version 1.0
cluster interconnect IPC version:
VERITAS IPC '5.0.31.5' 01:50:22 Jan 25 2010
IPC Vendor 86 proto 76
Version 1.0
PMON started WITH pid=2, OS id=23891
DIAG started WITH pid=3, OS id=23893
PSP0 started WITH pid=4, OS id=23895
LMON started WITH pid=5, OS id=23897
LMD0 started WITH pid=6, OS id=23899
LMS0 started WITH pid=7, OS id=23901
LMS1 started WITH pid=8, OS id=23903
LMS2 started WITH pid=9, OS id=23910
LMS3 started WITH pid=10, OS id=23912
MMAN started WITH pid=11, OS id=23914
DBW0 started WITH pid=12, OS id=23916
DBW1 started WITH pid=13, OS id=23918
DBW2 started WITH pid=14, OS id=23920
DBW3 started WITH pid=15, OS id=23922
DBW4 started WITH pid=16, OS id=23924
DBW5 started WITH pid=17, OS id=23926
DBW6 started WITH pid=18, OS id=23928
DBW7 started WITH pid=19, OS id=23930
LGWR started WITH pid=20, OS id=23932
CKPT started WITH pid=21, OS id=23934
SMON started WITH pid=22, OS id=23936
RECO started WITH pid=23, OS id=23938
CJQ0 started WITH pid=24, OS id=23940
MMON started WITH pid=25, OS id=23947
Wed May 04 15:56:08 EAT 2011
starting up 1 dispatcher(s) FOR network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started WITH pid=26, OS id=23949
Wed May 04 15:56:08 EAT 2011
starting up 1 shared server(s) ...
Wed May 04 15:56:23 EAT 2011
lmon registered WITH NM - instance id 2 (internal mem no 1)
Wed May 04 15:56:23 EAT 2011
Reconfiguration started (OLD inc 0, NEW inc 24)
List OF nodes:
0 1
Global Resource Directory frozen
* allocate DOMAIN 0, invalid = TRUE
Communication channels reestablished
* DOMAIN 0 valid = 1 according TO instance 0
Wed May 04 15:56:23 EAT 2011
Master broadcasted resource hash VALUE bitmaps
Non-LOCAL Process blocks cleaned OUT
Wed May 04 15:56:23 EAT 2011
LMS 0: 0 GCS shadows cancelled, 0 closed
Wed May 04 15:56:23 EAT 2011
LMS 1: 0 GCS shadows cancelled, 0 closed
Wed May 04 15:56:23 EAT 2011
LMS 3: 0 GCS shadows cancelled, 0 closed
Wed May 04 15:56:23 EAT 2011
LMS 2: 0 GCS shadows cancelled, 0 closed
SET master node info
Submitted ALL remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
ALL grantable enqueues GRANTED
Wed May 04 15:56:23 EAT 2011
LMS 0: 0 GCS shadows traversed, 0 replayed
Wed May 04 15:56:23 EAT 2011
LMS 1: 0 GCS shadows traversed, 0 replayed
Wed May 04 15:56:23 EAT 2011
LMS 2: 0 GCS shadows traversed, 0 replayed
Wed May 04 15:56:23 EAT 2011
LMS 3: 0 GCS shadows traversed, 0 replayed
Wed May 04 15:56:23 EAT 2011
Submitted ALL GCS remote-cache requests
Fix WRITE IN gcs resources
Reconfiguration complete
LCK0 started WITH pid=29, OS id=24102
Wed May 04 15:56:24 EAT 2011
ALTER DATABASE MOUNT
Wed May 04 15:56:29 EAT 2011
Setting recovery target incarnation TO 1
Wed May 04 15:56:29 EAT 2011
Successful mount OF redo thread 2, WITH mount id 3143841947
Wed May 04 15:56:29 EAT 2011
DATABASE mounted IN Shared Mode (CLUSTER_DATABASE=TRUE)
Completed: ALTER DATABASE MOUNT
Wed May 04 15:56:29 EAT 2011
ALTER DATABASE OPEN
Block CHANGE tracking file IS CURRENT.
Picked broadcast ON commit scheme TO generate SCNs
Wed May 04 15:56:29 EAT 2011
LGWR: STARTING ARCH PROCESSES
ARC0 started WITH pid=31, OS id=24229
Wed May 04 15:56:30 EAT 2011
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started WITH pid=32, OS id=24231
Wed May 04 15:56:30 EAT 2011
Thread 2 opened at log SEQUENCE 1086
CURRENT log# 4 seq# 1086 mem# 0: /oracle/redo04.log
Wed May 04 15:56:30 EAT 2011
Successful OPEN OF redo thread 2
Wed May 04 15:56:30 EAT 2011
ARC0: Becoming the 'no FAL' ARCH
Wed May 04 15:56:30 EAT 2011
ARC0: Becoming the 'no SRL' ARCH
Wed May 04 15:56:30 EAT 2011
ARC1: Becoming the heartbeat ARCH
Wed May 04 15:56:30 EAT 2011
Starting background process CTWR
CTWR started WITH pid=33, OS id=24233
Block CHANGE tracking service IS active.
Wed May 04 15:56:30 EAT 2011
SMON: enabling cache recovery
Wed May 04 15:56:32 EAT 2011
Errors IN file /oracle/app/admin/orcl/udump/orcl2_ora_24245.trc:
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
Wed May 04 15:56:34 EAT 2011
Successfully onlined Undo Tablespace 4.
Wed May 04 15:56:34 EAT 2011
SMON: enabling tx recovery
Wed May 04 15:56:34 EAT 2011
DATABASE Characterset IS ZHS16GBK
Opening WITH internal Resource Manager plan
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started WITH pid=37, OS id=24328
Wed May 04 15:56:39 EAT 2011
Completed: ALTER DATABASE OPEN
Wed May 04 15:56:39 EAT 2011
Errors IN file /oracle/app/admin/orcl/bdump/orcl2_m000_24393.trc:
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
Wed May 04 15:56:41 EAT 2011
Trace dumping IS performing id=[cdmp_20110504155641]
Wed May 04 15:56:44 EAT 2011
Errors IN file /oracle/app/admin/orcl/bdump/orcl2_mmon_23947.trc:
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
Wed May 04 15:56:44 EAT 2011
Errors IN file /oracle/app/admin/orcl/bdump/orcl2_m000_24393.trc:
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
Wed May 04 15:56:48 EAT 2011
Errors IN file /oracle/app/admin/orcl/bdump/orcl2_mmon_23947.trc:
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
Wed May 04 15:57:41 EAT 2011
Errors IN file /oracle/app/admin/orcl/udump/orcl2_ora_25174.trc:
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
Wed May 04 15:57:43 EAT 2011
Trace dumping IS performing id=[cdmp_20110504155743]
Wed May 04 15:58:44 EAT 2011
Errors IN file /oracle/app/admin/orcl/udump/orcl2_ora_25174.trc:
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
Wed May 04 15:59:46 EAT 2011
Reconfiguration started (OLD inc 24, NEW inc 26)
List OF nodes:
1
Global Resource Directory frozen
* dead instance detected - DOMAIN 0 invalid = TRUE
Communication channels reestablished
Master broadcasted resource hash VALUE bitmaps
Non-LOCAL Process blocks cleaned OUT
Wed May 04 15:59:46 EAT 2011
LMS 0: 0 GCS shadows cancelled, 0 closed
Wed May 04 15:59:46 EAT 2011
LMS 3: 0 GCS shadows cancelled, 0 closed
Wed May 04 15:59:46 EAT 2011
LMS 2: 0 GCS shadows cancelled, 0 closed
Wed May 04 15:59:46 EAT 2011
LMS 1: 0 GCS shadows cancelled, 0 closed
SET master node info
Submitted ALL remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
ALL grantable enqueues GRANTED
Post SMON TO START 1st pass IR
Wed May 04 15:59:46 EAT 2011
Instance recovery: looking FOR dead threads
Instance recovery: LOCK DOMAIN invalid but no dead threads
Wed May 04 15:59:46 EAT 2011
LMS 2: 1347 GCS shadows traversed, 0 replayed
Wed May 04 15:59:46 EAT 2011
LMS 3: 1386 GCS shadows traversed, 0 replayed
Wed May 04 15:59:46 EAT 2011
LMS 1: 1383 GCS shadows traversed, 0 replayed
Wed May 04 15:59:46 EAT 2011
LMS 0: 1430 GCS shadows traversed, 0 replayed
Wed May 04 15:59:46 EAT 2011
Submitted ALL GCS remote-cache requests
Fix WRITE IN gcs resources
Reconfiguration complete
Wed May 04 16:01:40 EAT 2011
Reconfiguration started (OLD inc 26, NEW inc 28)
List OF nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
* DOMAIN 0 valid = 1 according TO instance 0
Wed May 04 16:01:40 EAT 2011
Master broadcasted resource hash VALUE bitmaps
Non-LOCAL Process blocks cleaned OUT
Wed May 04 16:01:40 EAT 2011
LMS 0: 0 GCS shadows cancelled, 0 closed
Wed May 04 16:01:40 EAT 2011
LMS 1: 0 GCS shadows cancelled, 0 closed
Wed May 04 16:01:40 EAT 2011
LMS 3: 0 GCS shadows cancelled, 0 closed
Wed May 04 16:01:40 EAT 2011
LMS 2: 0 GCS shadows cancelled, 0 closed
SET master node info
Submitted ALL remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
ALL grantable enqueues GRANTED
Wed May 04 16:01:40 EAT 2011
LMS 2: 2224 GCS shadows traversed, 1095 replayed
Wed May 04 16:01:40 EAT 2011
LMS 3: 2255 GCS shadows traversed, 1073 replayed
Wed May 04 16:01:40 EAT 2011
LMS 1: 2339 GCS shadows traversed, 1110 replayed
Wed May 04 16:01:40 EAT 2011
LMS 0: 2300 GCS shadows traversed, 1216 replayed
Wed May 04 16:01:40 EAT 2011
Submitted ALL GCS remote-cache requests
Fix WRITE IN gcs resources
Reconfiguration complete

可以看到,数据库在还没有完全打开的时候就报出了这个错误,而在数据库实例打开之后,又由MMON进程引发了这个错误。

*** SERVICE NAME:(SYS$BACKGROUND) 2011-05-04 15:56:44.161
*** SESSION ID:(2977.1) 2011-05-04 15:56:44.161
*** 2011-05-04 15:56:44.161
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []
CURRENT SQL statement FOR this SESSION:
SELECT INSTANCE_NAME, HOST_NAME, NVL(GVI_STARTUP_TIME, SYSTIMESTAMP) - INTERVAL '1' SECOND AS SHUTDOWN_TIME FROM (SELECT RRI.INSTANCE_NAME AS INSTANCE_NAME, 
RRI.HOST_NAME AS HOST_NAME, FROM_TZ(RRI.STARTUP_TIME, '+00:00') AS RRI_STARTUP_TIME, DBMS_HA_ALERTS_PRVT.INSTANCE_STARTUP_TIMESTAMP_TZ(GVI.STARTUP_TIME) AS G
VI_STARTUP_TIME FROM RECENT_RESOURCE_INCARNATIONS$ RRI LEFT OUTER JOIN GV$INSTANCE GVI ON GVI.INSTANCE_NAME = RRI.RESOURCE_NAME WHERE RRI.RESOURCE_TYPE = 'IN
STANCE' AND :B2 = RRI.DB_UNIQUE_NAME AND :B1 = RRI.DB_DOMAIN) WHERE GVI_STARTUP_TIME IS NULL OR GVI_STARTUP_TIME > RRI_STARTUP_TIME GROUP BY INSTANCE_NAME, H
OST_NAME, GVI_STARTUP_TIME
----- PL/SQL Call Stack -----
  object      line  object
  handle    NUMBER  name
c0000012906ce9b0       301  package body SYS.DBMS_HA_ALERTS_PRVT
c0000012915b91f0         1  anonymous block
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedst()+64          CALL     ksedst1()            000000000 ? 000000001 ?
ksedmp()+2176        CALL     ksedst()             000000000 ?
                                                   C000000000000D20 ?
                                                   4000000004037940 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
ksfdmp()+112         CALL     ksedmp()             000000003 ?
                                                   9FFFFFFFFFFE5ED0 ?
                                                   60000000000BA290 ?
                                                   9FFFFFFFFFFE64A0 ?
                                                   C000000000000999 ?
                                                   400000000407F9B0 ?
kgerinv()+304        CALL     ksfdmp()             9FFFFFFFFFFE6A30 ?
                                                   000000003 ?
                                                   9FFFFFFFFFFE64B0 ?
                                                   60000000000BA290 ?
                                                   C000000000000612 ?
                                                   40000000098C38B0 ?
kgeasnmierr()+144    CALL     kgerinv()            60000000000318D0 ?
                                                   4000000001AD98A0 ?
                                                   6000000000032988 ?
                                                   4000000001AD98A0 ?
                                                   9FFFFFFFFFFE6A70 ?
$cold_kgeade()+64    CALL     kgeasnmierr()        60000000000318D0 ?
                                                   9FFFFFFFFD3B3438 ?
                                                   9FFFFFFFFD3B3448 ?
                                                   6000000000032D00 ?
                                                   9FFFFFFFFD45A598 ?
                                                   9FFFFFFFFFFE69B0 ?
                                                   9FFFFFFFFD460E98 ?
                                                   C000001290883058 ?
kgerev()+96          CALL     $cold_kgeade()       60000000000318D0 ?
                                                   6000000000031A50 ?
                                                   9FFFFFFFFD3B3438 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
kserec0()+160        CALL     kgerev()             60000000000318D0 ?
                                                   9FFFFFFFFD3B3438 ?
                                                   000000000 ?
                                                   6000000000032CF0 ?
                                                   9FFFFFFFFFFE6B38 ?

根据MOS记录的信息,当查询GV$视图,Oracle在RAC的多个节点同时查询本地的V$视图出错。导致错误的原因有可能是各个节点上的parallel_execution_message_size参数或者parallel_automatic_tuning参数设置不一致所致。
检查当前的RAC节点,发现各个PARALLEL相关的参数的设置都是相同的。虽然不是参数所致,但是发现,在报出后不久,当前节点就检测到RAC的另外一个节点CRASH,那么产生这个ORA-600错误的原因就是因为远端节点无法启动,导致远端的V$视图查询进程无法启动,从而产生了这个问题。

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

ORA-600(15214)错误

告警日志中包含ORA-600[15214]错误。
错误信息为:

Fri Feb 03 01:21:47 EAT 2012
Errors IN file /oracle/app/admin/orcl/bdump/orcl2_p155_29897.trc:
ORA-00600: internal error code, arguments: [15214], [0], [2], [], [], [], [], []
Fri Feb 03 01:21:49 EAT 2012
Trace dumping IS performing id=[cdmp_20120203012149]

很显然,这是一个并行执行导致的错误,进一步检查详细TRACE:

*** 2012-02-03 01:21:47.380
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [15214], [0], [2], [], [], [], [], []
CURRENT SQL statement FOR this SESSION:
ALTER INDEX ONWER01.PK_TABLE_INDEX rebuild partition P1 nologging parallel online
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedst()+64          CALL     ksedst1()            000000000 ? 000000001 ?
ksedmp()+2176        CALL     ksedst()             000000000 ?
                                                   C000000000000D20 ?
                                                   4000000003EC4A80 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
ksfdmp()+112         CALL     ksedmp()             000000003 ?
                                                   9FFFFFFFFFFF0500 ?
                                                   60000000000AF0E0 ?
                                                   9FFFFFFFFFFF0AD0 ?
                                                   C000000000000999 ?
                                                   4000000003F0CAF0 ?
kgeriv()+336         CALL     ksfdmp()             9FFFFFFFFFFF1060 ?
                                                   000000003 ?
                                                   9FFFFFFFFFFF0AE0 ?
                                                   60000000000AF0E0 ?
                                                   C000000000000695 ?
                                                   4000000009750DC0 ?
                                                   00002E217 ?
                                                   60000000000B9E08 ?
kgesiv()+192         CALL     kgeriv()             60000000000318D0 ?
                                                   6000000000032988 ?
                                                   40000000019720C0 ?
                                                   000000002 ?
                                                   9FFFFFFFFFFF1098 ?
ksesic2()+192        CALL     kgesiv()             60000000000318D0 ?
                                                   9FFFFFFFFD3B3720 ?
                                                   9FFFFFFFFD3B3730 ?
                                                   000000002 ?
                                                   9FFFFFFFFFFF1098 ?
$cold_kksfbc()+8800  CALL     ksesic2()            000003B6E ?
                                                   60000000000B9E08 ?
                                                   9FFFFFFFFFFF1098 ?
                                                   60000000000BA580 ?
                                                   000000002 ?
                                                   9FFFFFFFFD3D7B68 ?
                                                   000000000 ?
                                                   9FFFFFFFFD3D7B60 ?
kkspsc0()+2176       CALL     $cold_kksfbc()       9FFFFFFFFFFF2440 ?
                                                   4000000002F06BA0 ?
                                                   00002821B ?
                                                   9FFFFFFFFD3B4930 ?
                                                   000000061 ?
                                                   4000000000E1B9A0 ?
                                                   C00000119BF35118 ?
                                                   C00000119BF35118 ?
kksParseCursor()+35  CALL     kkspsc0()            9FFFFFFFFFFF3710 ?
2                                                  9FFFFFFFFD3B4930 ?
                                                   000000061 ? 000000003 ?
                                                   000000006 ?
                                                   4000000002F648E0 ?
                                                   000000000 ?
opiosq0()+4368       CALL     kksParseCursor()     9FFFFFFFFFFF3880 ?
                                                   C000000000001838 ?
                                                   4000000002E23DE0 ?
                                                   9FFFFFFFFD3C1888 ?
                                                   0FFDFFFFF ?
                                                   60000000000BC520 ?
                                                   60000000000BC878 ?
                                                   60000000000BC810 ?
kpooprx()+416        CALL     opiosq0()            000000003 ?
                                                   9FFFFFFFFFFF4370 ?
                                                   40000000029752C0 ?
                                                   00002F213 ?
                                                   C000000000000815 ?
kpoal8()+1152        CALL     kpooprx()            000000001 ?
                                                   9FFFFFFFFD3B4930 ?
                                                   000000060 ?
                                                   9FFFFFFFFFFF43B0 ?
                                                   000000001 ? 0000004A0 ?
                                                   60000000000AF0E0 ?
                                                   600000000009EA00 ?

出错的语句是一个索引重建,不过条件复杂一点,是对于索引的一个分区执行在线的并行NOLOGGING的重建操作,总会话应该是重建所有的分区,使用并行后,当前的会话会尝试重建其中一个分区。
不幸的是,这个错误在MOS中并没有对应的记录,虽然几乎所有的ORA-600[15214]错误都指向了Bug 6404447 – Intermittend OERI[15214] [ID 6404447.8],但是这个BUG已经在10.2.0.5中被明确FIXED了。而当前的数据库版本就是10.2.0.5。
同样在MOS上查询大量的已经明确应用了Patch 6404447补丁但仍然出现这个错误的情况,Oracle目前还没有给出明确的说明。
如果不是这个错误在10.2.0.5中没有真正解决,就是另外的问题导致了这个错误的产生。一般这个错误似乎后并行或直接路径有关,因此对于OLTP环境中,这个错误到也不是很严重。

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

ORA-600(kjzhablar:idx)错误

客户告警日志出现ORA-600[kjzhablar:idx]错误,已经碰到过ORA-7445[kjzhablar:idx]的错误,虽然错误函数相同,但是二者关系不大。
错误信息为:

Sat May 14 18:54:55 EAT 2011
Errors IN file /oracle/app/admin/orcl/bdump/orcl1_diag_3889.trc:
ORA-00600: internal error code, arguments: [kjzhablar:idx], [1], [1], [0x9FFFFFFFFD343AB4], [], [], [], []
Sat May 14 18:54:57 EAT 2011
Trace dumping IS performing id=[cdmp_20110514185457]

对应的TRACE文件包含下面的信息:

*** 2011-05-14 18:54:52.638
Switch TO short timeout FOR ipc polling
a SESSION (kjzha) IS registered
SESSION (kjzha) IS about TO END
Registered SESSION (kjzha)[11][4][0][1] IS cleaned up
Switch TO long timeout FOR ipc polling
Switch TO short timeout FOR ipc polling
a SESSION (kjzha) IS registered
*** 2011-05-14 18:54:55.828
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [kjzhablar:idx], [1], [1], [0x9FFFFFFFFD343AB4], [], [], [], []
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedst()+64          CALL     ksedst1()            000000000 ? 000000001 ?
ksedmp()+2176        CALL     ksedst()             000000000 ?
                                                   C000000000000D20 ?
                                                   4000000003EC4A80 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
ksfdmp()+112         CALL     ksedmp()             000000003 ?
                                                   9FFFFFFFFFFFBB00 ?
                                                   60000000000AF0E0 ?
                                                   9FFFFFFFFFFFC0D0 ?
                                                   C000000000000999 ?
                                                   4000000003F0CAF0 ?
kgerinv()+304        CALL     ksfdmp()             9FFFFFFFFFFFC660 ?
                                                   000000003 ?
                                                   9FFFFFFFFFFFC0E0 ?
                                                   60000000000AF0E0 ?
                                                   C000000000000612 ?
                                                   40000000097509D0 ?
kgeasnmierr()+144    CALL     kgerinv()            60000000000318D0 ?
                                                   40000000019720C0 ?
                                                   6000000000032988 ?
                                                   40000000019720C0 ?
                                                   9FFFFFFFFFFFC6A0 ?
kjzhablar()+1008     CALL     kgeasnmierr()        60000000000318D0 ?
                                                   60000000002F0E78 ?
                                                   60000000002F0E88 ?
                                                   6000000000032D00 ?
                                                   000000000 ?

这种有后台进程导致的ORA-600错误,多半和bug有关,查询MOS文档Bug 9062296 – DIAG process gets ORA-600[kjzhablar:idx] in RAC env [ID 9062296.8]描述的就是这个错误。在Rac环境的一个节点上DIAG进程出现这个ORA-600错误。
这个错误一般发生在读取V$SESSION的阻塞会话信息时,确认影响的版本是10.2.0.4正是当前的版本,Oracle将在解决这个bug的超集bug:9322219时将这个问题解决。因此这个bug在10.2.0.5.5中被修正。
Oracle给出的临时解决方案是通过设置隐含参数_diag_daemon为FLASE,来禁用DIAG进程。

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

ORA-600(1883)错误

一个数据泵导致的错误。
在告警日志中错误如下:

Sat Oct 08 17:08:28 EAT 2011
The VALUE (30) OF MAXTRANS parameter ignored.
Sat Oct 08 17:08:29 EAT 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20111008170828.CU3GP' SCOPE=MEMORY SID='cu3gp1';
Sat Oct 08 17:08:29 EAT 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_1_20111008170828.CU3GP','SYS$SYS.KUPC$S_1_20111008170828.CU3GP' SCOPE=MEMORY SID='cu3gp1';
kupprdp: master process DM00 started WITH pid=42, OS id=10975
TO EXECUTE - SYS.KUPM$MCP.MAIN('SYS_EXPORT_SCHEMA_01', 'SYS', 'KUPC$C_1_20111008170828', 'KUPC$S_1_20111008170828', 0);
kupprdp: worker process DW01 started WITH worker id=1, pid=43, OS id=10987
TO EXECUTE - SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_01', 'SYS');
Sat Oct 08 17:09:05 EAT 2011
Errors IN file /oracle/admin/cu3gp/bdump/cu3gp1_ora_10987.trc:
ORA-00600: internal error code, arguments: [1883], [0x000000000], [], [], [], [], [], []
ORA-19505: failed TO identify file "/arch/datapump/cu3gp.dmp"
ORA-17503: ksfdopn:4 Failed TO OPEN file /arch/datapump/cu3gp.dmp
ORA-17500: ODM err:File does NOT exist
Sat Oct 08 17:09:08 EAT 2011
Trace dumping IS performing id=[cdmp_20111008170908]

从错误前面的ALTER SYSTEM语句,以及SYS_EXPORT_SCHEMA_01信息,可以很容易的判断出当前在进行数据泵的导出操作。
而从报错的发生位置上看,应该是找不到导出时指定的DMP文件,从而引发了这个错误。
从MOS查询到的信息也确实证实了这一点,在文档ORA-600 [1883] hit at access of external dmp/sequential file [ID 1263128.1]中描述了这个问题,导致问题的原因可能是数据泵写DMP文件的时候发现DMP文件已经被删除或覆盖,或者通过EXPDP导出一个外部表,而这个外部表参考的外部DMP文件被删除或覆盖。总之导致问题的原因在于数据泵需要读或写的操作系统文件发生异常。
严格意义上说,这并不是一个bug,因为导致问题的原因在于操作系统上删除或修改了对应的文件,而之所以这成为一个bug,是因为Oracle报错信息不明确,引发了ORA-600内部错误。
在11.1中,Oracle解决了这个bug,不在出现ORA-600错误,而是普通的ORA错误信息。

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

ORA-7445(krslvna)错误

告警日志中出现ORA-7445[krslvna]错误,随后导致数据库的崩溃。
错误信息为:

Thu Sep 8 04:12:07 2011
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Interface TYPE 1 lan900 192.168.11.0 configured FROM OCR FOR USE AS a cluster interconnect
Interface TYPE 1 lan901 10.142.132.0 configured FROM OCR FOR USE AS a public interface
Picked latch-free SCN scheme 3
Autotune OF undo retention IS turned ON.
LICENSE_MAX_USERS = 0
SYS auditing IS disabled
ksdpec: called FOR event 13740 prior TO event GROUP initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters WITH non-DEFAULT VALUES:
processes = 800
sessions = 885
sga_max_size = 77309411328
__shared_pool_size = 4194304000
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 0
spfile = /dev/vg1/spfile
sga_target = 68719476736
control_files = /dev/vg1/control_01, /dev/vg2/control_02, /dev/vg3/control_03
db_block_size = 8192
__db_cache_size = 64474841088
compatible = 10.2.0.3.0
log_archive_config = DG_CONFIG=(ORCLS,ORCLP)
log_archive_dest_1 = LOCATION=/arch1/archive_log
log_archive_dest_2 = service=ORCLP LGWR ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=ORCLP
log_archive_trace = 12
fal_client = ORCLS
fal_server = orclp
db_file_multiblock_read_count= 16
cluster_database = TRUE
cluster_database_instances= 2
standby_file_management = auto
thread = 1
instance_number = 1
undo_management = AUTO
undo_tablespace = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain =
service_names = ORCLS
dispatchers = (PROTOCOL=TCP) (SERVICE=ORCLSXDB)
local_listener =
remote_listener = LISTENERS_ORCLS
job_queue_processes = 10
background_dump_dest = /oracle/admin/orcls/bdump
user_dump_dest = /oracle/admin/orcls/udump
core_dump_dest = /oracle/admin/orcls/cdump
audit_file_dest = /oracle/admin/orcls/adump
db_name = orclp
db_unique_name = orcls
open_cursors = 300
pga_aggregate_target = 15032385536
Cluster communication IS configured TO USE the following interface(s) FOR this instance
192.168.11.3
Thu Sep 8 04:12:11 2011
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2
PMON started WITH pid=2, OS id=4960
DIAG started WITH pid=6, OS id=5290
PSP0 started WITH pid=10, OS id=5292
LMON started WITH pid=14, OS id=5294
LMD0 started WITH pid=18, OS id=5296
LMS0 started WITH pid=22, OS id=5298
LMS1 started WITH pid=26, OS id=5300
LMS2 started WITH pid=30, OS id=5307
LMS3 started WITH pid=34, OS id=5309
LMS4 started WITH pid=38, OS id=5311
MMAN started WITH pid=42, OS id=5313
DBW0 started WITH pid=46, OS id=5320
DBW1 started WITH pid=50, OS id=5322
DBW2 started WITH pid=54, OS id=5327
DBW3 started WITH pid=58, OS id=5334
LGWR started WITH pid=62, OS id=5336
CKPT started WITH pid=66, OS id=5338
SMON started WITH pid=70, OS id=5345
RECO started WITH pid=74, OS id=5347
CJQ0 started WITH pid=78, OS id=5349
MMON started WITH pid=82, OS id=5356
MMNL started WITH pid=86, OS id=5359
Thu Sep 8 04:13:12 2011
starting up 1 dispatcher(s) FOR network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
Thu Sep 8 04:13:22 2011
lmon registered WITH NM - instance id 1 (internal mem no 0)
Thu Sep 8 04:13:22 2011
Reconfiguration started (OLD inc 0, NEW inc 2)
List OF nodes:
0
Global Resource Directory frozen
* allocate DOMAIN 0, invalid = TRUE
Communication channels reestablished
Master broadcasted resource hash VALUE bitmaps
Non-LOCAL Process blocks cleaned OUT
Thu Sep 8 04:13:23 2011
LMS 0: 0 GCS shadows cancelled, 0 closed
Thu Sep 8 04:13:23 2011
LMS 4: 0 GCS shadows cancelled, 0 closed
Thu Sep 8 04:13:23 2011
LMS 2: 0 GCS shadows cancelled, 0 closed
Thu Sep 8 04:13:23 2011
LMS 1: 0 GCS shadows cancelled, 0 closed
Thu Sep 8 04:13:23 2011
LMS 3: 0 GCS shadows cancelled, 0 closed
SET master node info
Submitted ALL remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
ALL grantable enqueues GRANTED
Post SMON TO START 1st pass IR
Thu Sep 8 04:13:23 2011
LMS 0: 0 GCS shadows traversed, 0 replayed
Thu Sep 8 04:13:23 2011
LMS 4: 0 GCS shadows traversed, 0 replayed
Thu Sep 8 04:13:23 2011
LMS 2: 0 GCS shadows traversed, 0 replayed
Thu Sep 8 04:13:23 2011
LMS 1: 0 GCS shadows traversed, 0 replayed
Thu Sep 8 04:13:23 2011
LMS 3: 0 GCS shadows traversed, 0 replayed
Thu Sep 8 04:13:23 2011
Submitted ALL GCS remote-cache requests
Fix WRITE IN gcs resources
Reconfiguration complete
LCK0 started WITH pid=98, OS id=5462
Thu Sep 8 04:13:23 2011
ALTER DATABASE MOUNT
Thu Sep 8 04:13:23 2011
This instance was FIRST TO mount
Setting recovery target incarnation TO 2
Thu Sep 8 04:13:28 2011
Successful mount OF redo thread 1, WITH mount id 422802531
Thu Sep 8 04:13:28 2011
DATABASE mounted IN Shared Mode (CLUSTER_DATABASE=TRUE)
Completed: ALTER DATABASE MOUNT
Thu Sep 8 04:13:28 2011
ALTER DATABASE OPEN
Thu Sep 8 04:13:28 2011
This instance was FIRST TO OPEN
Picked broadcast ON commit scheme TO generate SCNs
Thu Sep 8 04:13:28 2011
LGWR: STARTING ARCH PROCESSES
ARC0 started WITH pid=102, OS id=5496
Thu Sep 8 04:13:28 2011
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
(orcls1)
Thu Sep 8 03:24:29 2011
ARC0: Closing LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15995_684332778.dbf'
(orcls1)
Thu Sep 8 03:24:32 2011
Media Recovery Log /arch1/archive_log/1_15995_684332778.dbf
Media Recovery Waiting FOR thread 1 SEQUENCE 15996
Thu Sep 8 03:25:00 2011
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[31]: Assigned TO RFS process 15517
RFS[31]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[31]: Successfully opened standby log 7: '/dev/vg_3GeSales_01/rlv_186_sdlog1_1_01'
Thu Sep 8 03:25:03 2011
ARC1: Creating LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15996_684332778.dbf' (thread 1 SEQUENCE 15996)
(orcls1)
Thu Sep 8 03:25:04 2011
ARC1: Closing LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15996_684332778.dbf'
(orcls1)
Thu Sep 8 03:25:09 2011
Media Recovery Log /arch1/archive_log/1_15996_684332778.dbf
Media Recovery Waiting FOR thread 1 SEQUENCE 15997
Thu Sep 8 03:32:59 2011
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[32]: Assigned TO RFS process 18698
RFS[32]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[32]: Successfully opened standby log 7: '/dev/vg_3GeSales_01/rlv_186_sdlog1_1_01'
Thu Sep 8 03:33:10 2011
ARC0: Creating LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15997_684332778.dbf' (thread 1 SEQUENCE 15997)
(orcls1)
Thu Sep 8 03:33:12 2011
ARC0: Closing LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15997_684332778.dbf'
(orcls1)
Thu Sep 8 03:33:16 2011
Media Recovery Log /arch1/archive_log/1_15997_684332778.dbf
Media Recovery Waiting FOR thread 1 SEQUENCE 15998
Thu Sep 8 03:43:16 2011
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[33]: Assigned TO RFS process 22783
RFS[33]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[33]: Successfully opened standby log 7: '/dev/vg_3GeSales_01/rlv_186_sdlog1_1_01'
Thu Sep 8 03:43:16 2011
ARC1: Creating LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15998_684332778.dbf' (thread 1 SEQUENCE 15998)
(orcls1)
Thu Sep 8 03:43:16 2011
ARC1: Closing LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15998_684332778.dbf'
(orcls1)
Thu Sep 8 03:43:18 2011
Media Recovery Log /arch1/archive_log/1_15998_684332778.dbf
Media Recovery Waiting FOR thread 1 SEQUENCE 15999
Thu Sep 8 03:43:45 2011
ALTER SYSTEM ARCHIVE LOG
Thu Sep 8 03:52:03 2011
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[34]: Assigned TO RFS process 26342
RFS[34]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[34]: Successfully opened standby log 7: '/dev/vg_3GeSales_01/rlv_186_sdlog1_1_01'
Thu Sep 8 03:52:03 2011
ARC0: Creating LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15999_684332778.dbf' (thread 1 SEQUENCE 15999)
(orcls1)
Thu Sep 8 03:52:03 2011
ARC0: Closing LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_15999_684332778.dbf'
(orcls1)
Thu Sep 8 03:52:03 2011
Media Recovery Log /arch1/archive_log/1_15999_684332778.dbf
Media Recovery Waiting FOR thread 1 SEQUENCE 16000
Thu Sep 8 03:58:22 2011
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[35]: Assigned TO RFS process 28916
RFS[35]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[35]: Successfully opened standby log 7: '/dev/vg_3GeSales_01/rlv_186_sdlog1_1_01'
Thu Sep 8 03:58:29 2011
ARC1: Creating LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_16000_684332778.dbf' (thread 1 SEQUENCE 16000)
(orcls1)
Thu Sep 8 03:58:30 2011
ARC1: Closing LOCAL archive destination LOG_ARCHIVE_DEST_1: '/arch1/archive_log/1_16000_684332778.dbf'
(orcls1)
Thu Sep 8 03:58:34 2011
Media Recovery Log /arch1/archive_log/1_16000_684332778.dbf
Media Recovery Waiting FOR thread 1 SEQUENCE 16001
Thu Sep 8 04:04:52 2011
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[36]: Assigned TO RFS process 1725
RFS[36]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[36]: Archived Log: '/arch1/archive_log/1_16001_684332778.dbf'
Thu Sep 8 04:05:00 2011
Media Recovery Log /arch1/archive_log/1_16001_684332778.dbf
IDENTIFIED End-Of-Redo FOR thread 1 SEQUENCE 16001
Thu Sep 8 04:05:07 2011
Media Recovery End-Of-Redo indicator encountered
Thu Sep 8 04:05:08 2011
Media Recovery Applied until CHANGE 10988424928720
Thu Sep 8 04:05:08 2011
MRP0: Media Recovery Complete: End-Of-REDO (orcls1)
Resetting standby activation ID 418471684 (0x18f15f04)
Thu Sep 8 04:05:13 2011
MRP0: Background Media Recovery process shutdown (orcls1)
Thu Sep 8 04:07:17 2011
ALTER DATABASE commit TO switchover TO PRIMARY WITH SESSION shutdown
Thu Sep 8 04:07:17 2011
ALTER DATABASE SWITCHOVER TO PRIMARY (orcls1)
Thu Sep 8 04:07:17 2011
IF media recovery active, switchover will wait 900 seconds
Thu Sep 8 04:10:17 2011
SwitchOver after complete recovery through CHANGE 10988424928720
Thu Sep 8 04:10:40 2011
Standby became PRIMARY SCN: 10988424928718
Converting standby mount TO PRIMARY mount.
Thu Sep 8 04:10:40 2011
Switchover: Complete - DATABASE mounted AS PRIMARY (orcls1)
Completed: ALTER DATABASE commit TO switchover TO PRIMARY WITH SESSION shutdown
Thu Sep 8 04:10:40 2011
ARC0: STARTING ARCH PROCESSES
ARC2 started WITH pid=110, OS id=4267
Thu Sep 8 04:10:40 2011
ARC2: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Thu Sep 8 04:11:02 2011
ALTER DATABASE OPEN
Thu Sep 8 04:11:02 2011
This instance was FIRST TO OPEN
Picked broadcast ON commit scheme TO generate SCNs
Thu Sep 8 04:11:02 2011
Assigning activation ID 422708933 (0x193206c5)
LNSb started WITH pid=114, OS id=4419
Error 12541 received logging ON TO the standby
CHECK whether the listener IS up AND running.
Thu Sep 8 04:11:09 2011
Errors IN file /oracle/admin/orcls/bdump/orcls1_lgwr_10865.trc:
ORA-12541: TNS:no listener
Thu Sep 8 04:11:09 2011
LGWR: Error 12541 verifying archivelog destination LOG_ARCHIVE_DEST_2
LGWR: Continuing...
Thu Sep 8 04:11:09 2011
Errors IN file /oracle/admin/orcls/bdump/orcls1_lgwr_10865.trc:
ORA-07445: exception encountered: core dump [krslvna()+5073] [SIGSEGV] [Invalid permissions FOR mapped object] [0x000000254] [] []
Thu Sep 8 04:11:10 2011
Trace dumping IS performing id=[cdmp_20110908041110]
Thu Sep 8 04:11:13 2011
Errors IN file /oracle/admin/orcls/bdump/orcls1_pmon_10481.trc:
ORA-00470: LGWR process TERMINATED WITH error
Thu Sep 8 04:11:13 2011
PMON: terminating instance due TO error 470
Thu Sep 8 04:11:15 2011
Shutting down instance (abort)
License high water mark = 49
Thu Sep 8 04:11:23 2011
Termination issued TO instance processes. Waiting FOR the processes TO exit
Thu Sep 8 04:11:29 2011
Instance termination failed TO KILL one OR more processes
Instance TERMINATED BY PMON, pid = 10481
Thu Sep 8 04:11:39 2011
Termination issued TO instance processes. Waiting FOR the processes TO exit
Thu Sep 8 04:11:45 2011
Instance termination failed TO KILL one OR more processes
Instance TERMINATED BY USER, pid = 4542

其实跟错误相关的信息只有其中一两行,之所以列出这么多的信息,无非是要说明错误发生的具体环境,在错误发生之前做过DATA GUARD的SWITCHOVER,看来这个错误很可能与DATA GUARD有关。
查询结果也确实如此,在文档Bug 6490140 – LGWR may crash the instance [ID 6490140.8]描述了这个问题。当前数据库为主实例,且通过LGWR进程向远端写归档时可能碰到这个错误,而这个错误明显与DATA GUARD配置有关。确认影响的版本就是当前的10.2.0.4版本,Oracle在10.2.0.4 Data Guard Physical Recommended Patch Bundle #1、10.2.0.4.1、10.2.0.5和11.1.0.6中解决了这个问题。
从错误信息看,在这个ORA-7445错误出现之前,Oracle报了一个ORA-12541:no listener的错误,那么不难推测导致问题的原因在于LGWR写远端归档日志却发现远端没有配置监听,从而导致LGWR进程出现ORA-7445异常并退出,而LGWR进程的退出则意味着数据库的CRASH。
对于非DATA GUARD环境一般不会出现LGWR写远端归档的情况,而对于DATA GUARD环境,则要小心这个bug的产生。

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

EXCHANGE分区导致主键重复

分区表的EXCHANGE交换分区不检查数据有效性,可能导致LOCAL主键索引出现重复值。
通过一个简单的例子来说明这个问题:

SQL> CREATE TABLE T_PART_EXCHANGE (ID NUMBER, NAME VARCHAR2(30), TYPE VARCHAR2(18))
  2  PARTITION BY LIST (TYPE)
  3  (PARTITION P1 VALUES ('TABLE'), 
  4  PARTITION P2 VALUES (DEFAULT));
TABLE created.
SQL> CREATE INDEX IND_PART_EXCHANGE_TYPEID ON T_PART_EXCHANGE(TYPE, ID) LOCAL;
INDEX created.
SQL> ALTER TABLE T_PART_EXCHANGE ADD PRIMARY KEY (TYPE, ID) 
  2  USING INDEX IND_PART_EXCHANGE_TYPEID;
TABLE altered.
SQL> CREATE TABLE T_EXCHANGE_TEMP 
  2  AS SELECT * FROM T_PART_EXCHANGE;
TABLE created.
SQL> CREATE INDEX IND_EXCHANGE_TEMP_TYPEID ON T_EXCHANGE_TEMP(TYPE, ID);
INDEX created.
SQL> ALTER TABLE T_EXCHANGE_TEMP ADD PRIMARY KEY (TYPE, ID) 
  2  USING INDEX IND_EXCHANGE_TEMP_TYPEID;
TABLE altered.
SQL> INSERT INTO T_EXCHANGE_TEMP 
  2  SELECT ROWNUM, TABLE_NAME, 'TABLE'
  3  FROM USER_TABLES;
3 ROWS created.
SQL> SELECT * FROM T_EXCHANGE_TEMP;
        ID NAME                           TYPE
---------- ------------------------------ ------------------
         1 T_EXCHANGE_TEMP                TABLE
         2 T                              TABLE
         3 T_PART_EXCHANGE                TABLE
SQL> INSERT INTO T_EXCHANGE_TEMP VALUES (4, 'V_T', 'VIEW');
1 ROW created.
SQL> COMMIT;
Commit complete.

建立一个分区表,一个临时表用来交换数据,分区表上的主键使用LOCAL索引,而临时表上的对应列也建立了索引并添加了主键。
随后向临时表中添加记录,除了三条TYPE为TABLE的记录外,还增加了一条TYPE为VIEW的记录。
然后执行分区交换操作:

SQL> ALTER TABLE T_PART_EXCHANGE EXCHANGE PARTITION P1 WITH TABLE T_EXCHANGE_TEMP 
  2  INCLUDING INDEXES WITHOUT VALIDATION; 
TABLE altered.
SQL> SELECT * FROM T_PART_EXCHANGE PARTITION (P1);
        ID NAME                           TYPE
---------- ------------------------------ ------------------
         1 T_EXCHANGE_TEMP                TABLE
         2 T                              TABLE
         3 T_PART_EXCHANGE                TABLE
         4 V_T                            VIEW
SQL> INSERT INTO T_PART_EXCHANGE VALUES (4, 'V_T', 'VIEW');
1 ROW created.
SQL> COMMIT;
Commit complete.
SQL> SELECT * FROM T_PART_EXCHANGE;         
        ID NAME                           TYPE
---------- ------------------------------ ------------------
         1 T_EXCHANGE_TEMP                TABLE
         2 T                              TABLE
         3 T_PART_EXCHANGE                TABLE
         4 V_T                            VIEW
         4 V_T                            VIEW

由于Oracle不检测EXCHANGE进去的数据是否合法,就造成了数据重复的现场。这时如果通过主键访问,只会返回一条记录,而如果全表扫描则会返回两条记录:

SQL> SET AUTOT ON EXP
SQL> SELECT * FROM T_PART_EXCHANGE WHERE ID = 4 AND TYPE = 'VIEW';
        ID NAME                           TYPE
---------- ------------------------------ ------------------
         4 V_T                            VIEW
 
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 3202076975
----------------------------------------------------------------------------------------
|Id|Operation                          |Name                    |ROWS|Cost|Pstart|Pstop|
----------------------------------------------------------------------------------------
| 0|SELECT STATEMENT                   |                        |   1|   1|      |     |
| 1| PARTITION LIST SINGLE             |                        |   1|   1|  KEY |  KEY|
| 2|  TABLE ACCESS BY LOCAL INDEX ROWID|T_PART_EXCHANGE         |   1|   1|    2 |    2|
|*3|   INDEX RANGE SCAN                |IND_PART_EXCHANGE_TYPEID|   1|   1|    2 |    2|
----------------------------------------------------------------------------------------
Predicate Information (IDENTIFIED BY operation id):
---------------------------------------------------
   3 - access("TYPE"='VIEW' AND "ID"=4)
SQL> SELECT * FROM T_PART_EXCHANGE WHERE ID = 4;
        ID NAME                           TYPE
---------- ------------------------------ ------------------
         4 V_T                            VIEW
         4 V_T                            VIEW
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 820685725
-------------------------------------------------------------------------------------------
| Id  | Operation          | Name            | ROWS  | Bytes | Cost (%CPU)| Pstart| Pstop |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                 |     2 |    82 |     4   (0)|       |       |
|   1 |  PARTITION LIST ALL|                 |     2 |    82 |     4   (0)|     1 |     2 |
|*  2 |   TABLE ACCESS FULL| T_PART_EXCHANGE |     2 |    82 |     4   (0)|     1 |     2 |
-------------------------------------------------------------------------------------------
Predicate Information (IDENTIFIED BY operation id):
---------------------------------------------------
   2 - FILTER("ID"=4)
Note
-----
   - dynamic sampling used FOR this statement

即使扫描全表,查询的结果仍然可能是错误的:

SQL> SELECT ID, TYPE, COUNT(*)
  2  FROM T_PART_EXCHANGE
  3  GROUP BY ID, TYPE;
        ID TYPE                 COUNT(*)
---------- ------------------ ----------
         4 VIEW                        1
         1 TABLE                       1
         3 TABLE                       1
         2 TABLE                       1
         4 VIEW                        1
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 2336647613
------------------------------------------------------------------------------------------
|Id|Operation              |Name                    |ROWS|Bytes| Cost (%CPU)|Pstart|Pstop|
------------------------------------------------------------------------------------------
| 0|SELECT STATEMENT       |                        |   5|  120|     3  (34)|      |     |
| 1| PARTITION LIST ALL    |                        |   5|  120|     3  (34)|    1 |    2|
| 2|  HASH GROUP BY        |                        |   5|  120|     3  (34)|      |     |
| 3|   INDEX FAST FULL SCAN|IND_PART_EXCHANGE_TYPEID|   5|  120|     2   (0)|    1 |    2|
------------------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement
SQL> SELECT ID, TYPE, COUNT(*)
  2  FROM T_PART_EXCHANGE
  3  GROUP BY ID, TYPE          
  4  ORDER BY ID;
        ID TYPE                 COUNT(*)
---------- ------------------ ----------
         1 TABLE                       1
         2 TABLE                       1
         3 TABLE                       1
         4 VIEW                        2
 
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 98113653
------------------------------------------------------------------------------------------
|Id|Operation              |Name                    |ROWS|Bytes| Cost (%CPU)|Pstart|Pstop|
------------------------------------------------------------------------------------------
| 0|SELECT STATEMENT       |                        |   5|  120|     3  (34)|      |     |
| 1| SORT GROUP BY         |                        |   5|  120|     3  (34)|      |     |
| 2|  PARTITION LIST ALL   |                        |   5|  120|     2   (0)|    1 |    2|
| 3|   INDEX FAST FULL SCAN|IND_PART_EXCHANGE_TYPEID|   5|  120|     2   (0)|    1 |    2|
------------------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement

可以看到如果采用HASH GROUP BY,则GROUP BY被推到分区操作内部,因此完全相同的记录被计算两次。而加上ORDER BY语句,则Oracle采用SORT GROUP BY操作,这时GROUP BY在分区操作之外,因此得到的结果是正常的。
其实针对这个错误,倒是很容易解决,指定分区进行删除即可:

SQL> DELETE T_PART_EXCHANGE PARTITION (P1) WHERE ID = 4;
1 ROW deleted.
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 2501039200
-----------------------------------------------------------------------------------------
|Id|Operation              |Name           |ROWS|Bytes|Cost (%CPU)|TIME    |Pstart|Pstop|
-----------------------------------------------------------------------------------------
| 0|DELETE STATEMENT       |               |   1|   24|    3   (0)|00:00:01|      |     |
| 1| DELETE                |T_PART_EXCHANGE|    |     |           |        |      |     |
| 2|  PARTITION LIST SINGLE|               |   1|   24|    3   (0)|00:00:01|  KEY |  KEY|
|*3|   TABLE ACCESS FULL   |T_PART_EXCHANGE|   1|   24|    3   (0)|00:00:01|    1 |    1|
-----------------------------------------------------------------------------------------
Predicate Information (IDENTIFIED BY operation id):
---------------------------------------------------
   3 - FILTER("ID"=4)
Note
-----
   - dynamic sampling used FOR this statement
SQL> SET AUTOT OFF
SQL> SELECT * FROM T_PART_EXCHANGE; 
        ID NAME                           TYPE
---------- ------------------------------ ------------------
         1 T_EXCHANGE_TEMP                TABLE
         2 T                              TABLE
         3 T_PART_EXCHANGE                TABLE
         4 V_T                            VIEW
SQL> INSERT INTO T_PART_EXCHANGE VALUES (4, 'V_T', 'VIEW');
INSERT INTO T_PART_EXCHANGE VALUES (4, 'V_T', 'VIEW')
*
ERROR at line 1:
ORA-00001: UNIQUE CONSTRAINT (TEST.SYS_C007282) violated
SQL> COMMIT;
Commit complete.
Posted in ORACLE | Tagged , , | Leave a comment

语句级并行提示

最近才发现并行提示增加了语句级并行的功能。
以前添加并行都是对指定的表添加,最近才发现,如果不加表名,是指定这个语句的并行度:

SQL> CREATE TABLE t_p_i AS 
  2  SELECT * 
  3  FROM dba_objects 
  4  WHERE 1 = 2;
TABLE created.
SQL> CREATE TABLE t_p_s AS
  2  SELECT * 
  3  FROM dba_objects;
TABLE created.
SQL> SET autot ON EXP  
SQL> INSERT INTO t_p_i
  2  SELECT * 
  3  FROM t_p_s;
13593 ROWS created.
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 3463104165
----------------------------------------------------------------------------------
| Id  | Operation                | Name  | ROWS  | Bytes | Cost (%CPU)| TIME     |
----------------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |       | 14768 |  2985K|    53   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | T_P_I |       |       |            |          |
|   2 |   TABLE ACCESS FULL      | T_P_S | 14768 |  2985K|    53   (0)| 00:00:01 |
----------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
SQL> INSERT INTO t_p_i
  2  SELECT /*+ parallel(t_p_s 4) */ * 
  3  FROM t_p_s;
13593 ROWS created.
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 455351089
----------------------------------------------------------------------------------------
|Id|Operation               |Name    |ROWS |Bytes |Cost (%CPU)|   TQ |IN-OUT|PQ Distrib|
----------------------------------------------------------------------------------------
| 0|INSERT STATEMENT        |        |14768| 2985K|   15   (0)|      |      |          |
| 1| LOAD TABLE CONVENTIONAL|T_P_I   |     |      |           |      |      |          |
| 2|  PX COORDINATOR        |        |     |      |           |      |      |          |
| 3|   PX SEND QC (RANDOM)  |:TQ10000|14768| 2985K|   15   (0)| Q1,00| P->S |QC (RAND) |
| 4|    PX BLOCK ITERATOR   |        |14768| 2985K|   15   (0)| Q1,00| PCWC |          |
| 5|     TABLE ACCESS FULL  |T_P_S   |14768| 2985K|   15   (0)| Q1,00| PCWP |          |
----------------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
SQL> INSERT /*+ parallel(t_p_s 4) */ INTO t_p_i
  2  SELECT * 
  3  FROM t_p_s;
13593 ROWS created.
Execution Plan
----------------------------------------------------------
Plan hash VALUE: 3463104165
----------------------------------------------------------------------------------
| Id  | Operation                | Name  | ROWS  | Bytes | Cost (%CPU)| TIME     |
----------------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |       | 14768 |  2985K|    53   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | T_P_I |       |       |            |          |
|   2 |   TABLE ACCESS FULL      | T_P_S | 14768 |  2985K|    53   (0)| 00:00:01 |
----------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
SQL> commit;
Commit complete.
SQL> ALTER SESSION enable parallel dml;
SESSION altered.
SQL> SET autot off
SQL> EXPLAIN plan FOR
  2  INSERT /*+ parallel(t_p_i 4) */ INTO t_p_i
  3  SELECT * 
  4  FROM t_p_s;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------
Plan hash VALUE: 2807692233
---------------------------------------------------------------------------------------
|Id|Operation               |Name    |ROWS |Bytes |Cost (%CPU)|  TQ |IN-OUT|PQ Distrib|
--------------------------------------------------------------------------------------
| 0|INSERT STATEMENT        |        |14768| 2985K|   53   (0)|     |      |          |
| 1| PX COORDINATOR         |        |     |      |           |     |      |          |
| 2|  PX SEND QC (RANDOM)   |:TQ10001|14768| 2985K|   53   (0)|Q1,01| P->S |QC (RAND) |
| 3|   LOAD AS SELECT       |T_P_I   |     |      |           |Q1,01| PCWP |          |
| 4|    PX RECEIVE          |        |14768| 2985K|   53   (0)|Q1,01| PCWP |          |
| 5|     PX SEND ROUND-ROBIN|:TQ10000|14768| 2985K|   53   (0)|     | S->P |RND-ROBIN |
| 6|      TABLE ACCESS FULL |T_P_S   |14768| 2985K|   53   (0)|     |      |          |
---------------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
17 ROWS selected.
SQL> EXPLAIN plan FOR
  2  INSERT /*+ parallel(t_p_i 4) */ INTO t_p_i
  3  SELECT /*+ parallel(t_p_s 4) */ * 
  4  FROM t_p_s;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------
Plan hash VALUE: 2808998595
-------------------------------------------------------------------------------------
|Id|Operation             |Name    |ROWS |Bytes |Cost (%CPU)|  TQ |IN-OUT|PQ Distrib|
------------------------------------------------------------------------------------
| 0|INSERT STATEMENT      |        |14768| 2985K|   15   (0)|     |      |          |
| 1| PX COORDINATOR       |        |     |      |           |     |      |          |
| 2|  PX SEND QC (RANDOM) |:TQ10000|14768| 2985K|   15   (0)|Q1,00| P->S |QC (RAND) |
| 3|   LOAD AS SELECT     |T_P_I   |     |      |           |Q1,00| PCWP |          |
| 4|    PX BLOCK ITERATOR |        |14768| 2985K|   15   (0)|Q1,00| PCWC |          |
| 5|     TABLE ACCESS FULL|T_P_S   |14768| 2985K|   15   (0)|Q1,00| PCWP |          |
-------------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
16 ROWS selected.
SQL> EXPLAIN plan FOR
  2  INSERT /*+ parallel(4) */ INTO t_p_i
  3  SELECT * 
  4  FROM t_p_s;
Explained.
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------
Plan hash VALUE: 2808998595
-------------------------------------------------------------------------------------
|Id|Operation             |Name    |ROWS |Bytes |Cost (%CPU)|  TQ |IN-OUT|PQ Distrib|
-------------------------------------------------------------------------------------
| 0|INSERT STATEMENT      |        |14768| 2985K|   15   (0)|     |      |          |
| 1| PX COORDINATOR       |        |     |      |           |     |      |          |
| 2|  PX SEND QC (RANDOM) |:TQ10000|14768| 2985K|   15   (0)|Q1,00| P->S |QC (RAND) |
| 3|   LOAD AS SELECT     |T_P_I   |     |      |           |Q1,00| PCWP |          |
| 4|    PX BLOCK ITERATOR |        |14768| 2985K|   15   (0)|Q1,00| PCWC |          |
| 5|     TABLE ACCESS FULL|T_P_S   |14768| 2985K|   15   (0)|Q1,00| PCWP |          |
-------------------------------------------------------------------------------------
Note
-----
   - dynamic sampling used FOR this statement (level=2)
   - Degree OF Parallelism IS 4 because OF hint
17 ROWS selected.

从这个小例子可以看到,如果指定表级的并行,那么必须在访问表的语句中,比如上面的例子中,如果对查询的表指定并行,将并行的HINT放到INSERT语句中是没有效果的。
而如果想要INSERT和SELECT同时并行执行,那么必须在INSERT和SELECT语句中分别指定查询和插入表的并行度。如果存在多个表的连接,并行设置还会更麻烦。
而通过语句级的并行设置很好的解决了这个问题,通过在第一个命令后添加不带表名的并行提示,使得这个语句中所有的子句都会使用并行。

Posted in ORACLE | Tagged , | Leave a comment