oracle - 如何诊断 Oracle Data Pump 导入失败并出现错误 1089 的问题

Question

我正在尝试将架构导入 Ubuntu14.04 中的 dockerized 容器中。该容器基于 this image ，其中包含 Oracle XE 11g。警报日志对此没有显示任何内容，impdp 本身生成的跟踪仅显示创建的最后一个表脚本(每次运行都不同)。

我使用的命令是:

/u01/app/oracle/product/11.2.0/xe/bin/impdp myshema/mypass@"(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=db)(PORT\=1521)))(CONNECT_DATA\=(SID\=XE)))" PARFILE=/myschema/myschema.par;

导入会持续一段时间，然后在某个半随机点失败，并显示“Oracle 错误 1089”。它在创建表的过程中进行到一半(重复运行每次都在不同的表处结束)。从另一个 session 连接到我的 Oracle 实例表明，即使在此故障之后，该实例仍然正常运行并工作。

Import: Release 11.2.0.2.0 - Production on Tue Oct 18 15:07:22 2016

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
Master table "MYSCHEMA"."SYS_SQL_FILE_SCHEMA_01" successfully loaded/unloaded
Starting "MYSCHEMA"."SYS_SQL_FILE_SCHEMA_01":  MYSCHEMA/********@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db)(PORT=1521)))(CONNECT_DATA=(SID=XE)))D\=XE))) PARFILE=/MYSCHEMA/MYSCHEMA.par
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/SYNONYM/SYNONYM
Processing object type SCHEMA_EXPORT/TYPE/TYPE_SPEC
Processing object type SCHEMA_EXPORT/DB_LINK
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/SEQUENCE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/TABLE

UDI-01089: operation generated ORACLE error 1089
ORA-01089: immediate shutdown in progress - no operations are permitted
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3326
ORA-06512: at "SYS.DBMS_DATAPUMP", line 4551
ORA-06512: at line 1
Process ID: 242
Session ID: 23 Serial number: 5

我的参数文件是:

SQLFILE=imp_dir:myschema_import.sql
SCHEMAS=MYSCHEMA 

# ignore storage attributes for tables & use defaults 
TRANSFORM=SEGMENT_ATTRIBUTES:n
DIRECTORY=imp_dir 
DUMPFILE=MYSCHEMA_META.DMP 

# set this for some extra tracing:
TRACE=1FF0300 

EXCLUDE=TABLESPACE_QUOTA
EXCLUDE=MATERIALIZED_VIEW_LOG
EXCLUDE=SCHEMA_EXPORT/USER
EXCLUDE=SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS

REMAP_TABLESPACE=INDEX1:users 
REMAP_TABLESPACE=INDEX2:users 
REMAP_TABLESPACE=DATA1:users 
REMAP_TABLESPACE=DATA2:users 

为了完整起见，警报日志中唯一不舒服的行是:

Wed Oct 19 11:56:26 2016
Starting ORACLE instance (normal)
Errors in file /u01/app/oracle/diag/rdbms/xe/XE/trace/XE_ora_70.trc:
ORA-27167: Attempt to determine if Oracle binary image is stored on remote server failed
ORA-27300: OS system dependent operation:parse_df failed with status: 2
ORA-27301: OS failure message: No such file or directory
ORA-27302: failure occurred at: parse failed
ORA-27303: additional information: Filesystem     1K-blocks     Used Available Use% Mounted on
none           101799456 42184988  55159488  44% /
Image consistency checking encountered an error, checking disabled
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =61
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production.
Using parameter settings in client-side pfile /u01/app/oracle/product/11.2.0/xe/config/scripts/init.ora on machine 11
2c1560d28e

这似乎是一个 red herring ，因为它每次启动数据库时都会发生(直接从原始的 docker 镜像)，并且似乎不会影响其他任何事情。

有一个与导入相关的跟踪日志:XE_dm00_232.trc。直到最后(据我估计)似乎没有什么不寻常的。不幸的是，对我来说，这些信息并不比 1089 错误更有帮助:

*** 2016-10-19 11:58:57.861
KUPC:11:58:57.860: Before Listen: consumer = MCP
KUPC:11:58:57.861:  from queue = SYS.KUPC$C_1_20161019115822

*** 2016-10-19 11:58:58.916
KUPM:11:58:58.916: Client count is: 1
KUPM:11:58:58.916: In check_workers...
KUPM:11:58:58.916: Live worker count is:  1
KUPM:11:58:58.916: In set_longops
KUPM:11:58:58.938: Work so far is: 0
KUPM:11:58:58.938: Checking for resumable waits
KUPC:11:58:59.051: Before Listen: consumer = MCP
KUPC:11:58:59.051:  from queue = SYS.KUPC$C_1_20161019115822

*** 2016-10-19 11:59:04.048
KUPC:11:59:04.048: Before Listen: consumer = MCP
KUPC:11:59:04.049:  from queue = SYS.KUPC$C_1_20161019115822

*** 2016-10-19 11:59:08.942
KUPC:11:59:08.942: Error Code: -1089
KUPC:11:59:08.942: Error Text: dequeueMessage ORA-01089: immediate shutdown in progress - no operations are permitted
KUPM:11:59:08.942: Error detected by MCP
KUPC:11:59:09.083: Before ENQ: Sending Type: 2022 ID:
KUPC:11:59:09.083:  DG,KUPC$S_1_20161019115822,MCP, ,22,Y
kwqberlst rqan->lascn_kwqiia > 0 block
kwqberlst rqan->lascn_kwqiia  22
kwqberlst ascn 355628 lascn 22
KUPM:11:59:09.194: ORA-39097: Data Pump job encountered unexpected error -1089
KUPC:11:59:09.230: Before ENQ: Sending Type: 2022 ID:
KUPC:11:59:09.230:  DG,KUPC$S_1_20161019115822,MCP, ,23,Y
kwqberlst rqan->lascn_kwqiia > 0 block
kwqberlst rqan->lascn_kwqiia  22
kwqberlst ascn 355628 lascn 22
KUPM:11:59:09.231: ORA-39065: unexpected master process exception in MAIN
KUPM:11:59:09.231: ORA-01089: immediate shutdown in progress - no operations are permitted
KUPM:11:59:09.231:     ORA-06512: at "SYS.KUPC$QUEUE_INT", line 572
KUPM:11:59:09.231:     ORA-06512: at "SYS.KUPM$MCP", line 1072
KUPM:11:59:09.231:     ORA-06512: at "SYS.KUPM$MCP", line 857
KUPM:11:59:09.231:     ----- PL/SQL Call Stack -----
KUPM:11:59:09.231:       object      line  object
KUPM:11:59:09.231:       handle    number  name
KUPM:11:59:09.231:     0x7b1dd540     15140  package body SYS.KUPM$MCP
KUPM:11:59:09.231:     0x7b1dd540       994  package body SYS.KUPM$MCP
KUPM:11:59:09.231:     0x7b3bbb48         2  anonymous block
KUPM:11:59:09.231: In RESPOND_TO_START
KUPM:11:59:09.231: Killing workers on fatal exception...
KUPM:11:59:09.231: In check_workers...
KUPM:11:59:09.231: Live worker count is:  1
KUPF:11:59:09.233: In FILE_REQUEST_NAK...
KUPF:11:59:09.233: ...sent 0 exit messages

*** 2016-10-19 11:59:11.232
KUPC:11:59:11.232: Before Listen: consumer = MCP
KUPC:11:59:11.232:  from queue = SYS.KUPC$C_1_20161019115822
KUPP:11:59:11.233: Entering kuppkilw
KUPP:11:59:11.233: mso = 0x7a559c60, Error = 39119
KUPP:11:59:11.233: Called ksvhdlshut to kill all workers for this job
KUPP:11:59:11.233: Exiting kuppkilw
KUPV:11:59:11.234: Update request for job: MYSCHEMA.SYS_IMPORT_SCHEMA_01, func: 1
KUPP:11:59:11.272: Action = 1, mso = 0x7a559c60
KUPP:11:59:11.281: Entering kuppkilw
KUPP:11:59:11.281: mso = 0x7a559c60, Error = 31673
KUPP:11:59:11.282: Called ksvhdlshut to kill all workers for this job
KUPP:11:59:11.282: Exiting kuppkilw
root@112c1560d28e:/u01/app/oracle/diag/rdbms/xe/XE/trace#

Answer 1

在注意到手动运行导入(有时)后，我意识到我可以通过在数据库已经“打开”之后添加额外的延迟来解决这个问题。

30 秒的延迟会产生以下结果(不同的错误):

UDI-12528: operation generated ORACLE error 12528
ORA-12528: TNS:listener: all appropriate instances are blocking new connections

60 秒的延迟允许导入成功进行。即使在数据库打开后，数据库似乎也有一些not-quite-ready。

这可以解决这个问题，但我更喜欢更好的解释，或者不涉及神奇的、任意的延迟来等待数据库真正准备好的替代解决方案。