如何诊断Oracle数据泵导入失败，错误1089的问题
我想在Ubuntu14.04中将模式导入到dockerized容器中。 该容器基于此映像 ，其中包含Oracle XE 11g。 警报日志没有显示任何信息，而impdp本身生成的跟踪只显示了最后创build的表脚本（每次运行都不相同）。
我正在使用的命令是：
/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;
import进行了一段时间，然后在一些半随机点失败，“甲骨文错误1089”。 它通过创build表格（重复运行每次结束在不同的表格）。 从另一个会话连接到我的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
这似乎是一个红鲱鱼 ，因为它每次启动数据库（正确的原始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#
在注意到手动运行导入工作（有时）后，我意识到我可以通过在数据库已经“打开” 之后添加额外的延迟来解决问题。
30秒延迟产生这个（一个不同的错误）：
UDI-12528: operation generated ORACLE error 12528 ORA-12528: TNS:listener: all appropriate instances are blocking new connections
60秒延迟允许导入成功进行。 数据库打开后，似乎数据库还not-quite-ready 。
这解决了这个问题，但是我更喜欢更好的解释，或者是一个替代的解决scheme，不需要一个神奇的，任意的延迟来等待数据库真正准备好。