由于业务需要,在Oracle 10.2.0.2版本RAC的一个节点上使用了DataPump工具对表做导出导入工作。
先贴部分日志:expdp日志
oracle@cupd25k-b@/oracle/oracle $ export ORACLE_SID=H2
oracle@cupd25k-b@/oracle/oracle $ expdp linc directory=dump_dir dumpfile=hxdb_acct_exp_111213.dmp logfile=hxdb_acct_exp_111213.log tables=hxdb_acct
Export: Release 10.2.0.2.0 - 64bit Production on Tuesday, 13 December, 2011 3:40:57
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Password:
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
Starting "LINC"."SYS_EXPORT_TABLE_01": linc/******** directory=dump_dir dumpfile=hxdb_acct_exp_111213.dmp logfile=hxdb_acct_exp_111213.log tables=hxdb_acct
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 1.829 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "LINC"."HXDB_ACCT" 1.178 GB 1649468 rows
Master table "LINC"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for LINC.SYS_EXPORT_TABLE_01 is:
/other/dumpdir/hxdb_acct_exp_111213.dmp
Job "LINC"."SYS_EXPORT_TABLE_01" successfully completed at 03:44:22
impdp日志
oracle@cupd25k-b@/oracle/oracle $ echo $ORACLE_SID
H2
oracle@cupd25k-b@/oracle/oracle $ impdp linc directory=dump_dir dumpfile= hxdb_acct_exp_111213.dmp logfile=hxdb_acct_imp_111213.log
Import: Release 10.2.0.2.0 - 64bit Production on Tuesday, 13 December, 2011 3:48:22
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Password:
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
Master table "LINC"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "LINC"."SYS_IMPORT_FULL_01": linc/******** directory=dump_dir dumpfile= hxdb_acct_exp_111213.dmp logfile=hxdb_acct_imp_111213.log
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
. . imported "LINC"."HXDB_ACCT" 1.178 GB 1649468 rows
Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Job "LINC"."SYS_IMPORT_FULL_01" successfully completed at 03:55:25
H2实例的alert日志
Tue Dec 13 03:41:29 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_2_20111213034126.HX' SCOPE=MEMORY SID='H2';
Tue Dec 13 03:41:29 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_2_20111213034126.HX','SYS$SYS.KUPC$S_2_20111213034126.HX' SCOPE=MEMORY SID='H2';
kupprdp: master process DM00 started with pid=44, OS id=24084
to execute - SYS.KUPM$MCP.MAIN('SYS_EXPORT_TABLE_01', 'LINC', 'KUPC$C_2_20111213034126', 'KUPC$S_2_20111213034126', 0);
kupprdp: worker process DW01 started with worker id=1, pid=57, OS id=24728
to execute - SYS.KUPW$WORKER.MAIN('SYS_EXPORT_TABLE_01', 'LINC');
Tue Dec 13 03:44:25 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$S_2_20111213034126.HX' SCOPE=MEMORY SID='H2';
Tue Dec 13 03:44:26 2011
ALTER SYSTEM SET service_names='' SCOPE=MEMORY SID='H2';
Tue Dec 13 03:48:43 2011
The value (30) of MAXTRANS parameter ignored.
Tue Dec 13 03:48:44 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_2_20111213034843.HX' SCOPE=MEMORY SID='H2';
Tue Dec 13 03:48:45 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$C_2_20111213034843.HX','SYS$SYS.KUPC$S_2_20111213034843.HX' SCOPE=MEMORY SID='H2';
kupprdp: master process DM00 started with pid=44, OS id=24410
to execute - SYS.KUPM$MCP.MAIN('SYS_IMPORT_FULL_01', 'LINC', 'KUPC$C_2_20111213034843', 'KUPC$S_2_20111213034843', 0);
kupprdp: worker process DW01 started with worker id=1, pid=57, OS id=24563
to execute - SYS.KUPW$WORKER.MAIN('SYS_IMPORT_FULL_01', 'LINC');
Tue Dec 13 03:48:57 2011
Thread 2 advanced to log sequence 91978
Current log# 19 seq# 91978 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB14
Thread 2 advanced to log sequence 91979
Current log# 20 seq# 91979 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB15
Tue Dec 13 03:49:13 2011
Thread 2 advanced to log sequence 91980
Current log# 16 seq# 91980 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB11
Thread 2 advanced to log sequence 91981
Current log# 17 seq# 91981 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB12
Tue Dec 13 03:49:29 2011
Thread 2 advanced to log sequence 91982
Current log# 18 seq# 91982 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB13
Thread 2 advanced to log sequence 91983
Current log# 19 seq# 91983 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB14
Tue Dec 13 03:49:45 2011
Thread 2 advanced to log sequence 91984
Current log# 20 seq# 91984 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB15
Thread 2 advanced to log sequence 91985
Current log# 16 seq# 91985 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB11
Tue Dec 13 03:50:00 2011
Thread 2 advanced to log sequence 91986
Current log# 17 seq# 91986 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB12
Thread 2 advanced to log sequence 91987
Current log# 18 seq# 91987 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB13
Tue Dec 13 03:50:16 2011
Thread 2 advanced to log sequence 91988
Current log# 19 seq# 91988 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB14
Thread 2 advanced to log sequence 91989
Current log# 20 seq# 91989 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB15
Tue Dec 13 03:50:31 2011
Thread 2 cannot allocate new log, sequence 91990
Checkpoint not complete
Current log# 20 seq# 91989 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB15
Thread 2 advanced to log sequence 91990
Current log# 16 seq# 91990 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB11
Thread 2 advanced to log sequence 91991
Current log# 17 seq# 91991 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB12
Tue Dec 13 03:50:48 2011
Thread 2 advanced to log sequence 91992
Current log# 18 seq# 91992 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB13
Tue Dec 13 03:53:51 2011
Thread 2 advanced to log sequence 91993
Current log# 19 seq# 91993 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB14
Tue Dec 13 03:55:19 2011
Thread 2 advanced to log sequence 91994
Current log# 20 seq# 91994 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB15
Tue Dec 13 03:55:26 2011
ALTER SYSTEM SET service_names='SYS$SYS.KUPC$S_2_20111213034843.HX' SCOPE=MEMORY SID='H2';
Tue Dec 13 03:55:26 2011
ALTER SYSTEM SET service_names='' SCOPE=MEMORY SID='H2';
Tue Dec 13 04:17:41 2011
Thread 2 advanced to log sequence 91995
Current log# 16 seq# 91995 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB11
Thread 2 advanced to log sequence 91996
Current log# 17 seq# 91996 mem# 0: /dev/vx/rdsk/oradgHX/lv_hx_logB12
在使用DataPump工具时,service_names参数会被修改,这个修改动作是给DataPump自己的队列操作使用的,而在操作结束后,这个参数会被修改为原来的值。从alert log中可以看到,RAC环境使用DataPump工具结束后,memory中的service_names参数被修改为了''。
ALTER SYSTEM SET service_names='' SCOPE=MEMORY SID='H2';
这是由于在实例启动时,数据库的service name没有被指定,那么该参数值就会使用默认的database name,这就导致了在DataPump操作结束后,这个新的service name被定义为了''(null)。
即使如此,现有的使用默认database name的service不会因此受到影响,这个service(使用默认的database name)总是存在的,不会被删除,所以我们不必太过担心。如果listener重启的话,pmon会自动在listener中重新注册该默认服务。
不过考虑到毕竟service_names参数被修改是我们非期望的,所以在RAC环境的建库脚本中,建议指定该参数,避免类似的现象发生。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/20750200/viewspace-713332/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/20750200/viewspace-713332/