如何诊断Oracle Data Pump导入失败的问题，错误1089

时间：2016-10-19 12:39:30

标签： oracle docker

我正在尝试将模式导入到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 error 1089”。它通过创建表得到了中途（每次重复运行在不同的表结束）。从另一个会话连接到我的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#

1 个答案:

答案 0 :(得分：0)

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

30秒的延迟产生了这个（不同的错误）：

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

延迟60秒允许导入成功进行。即使在数据库打开之后，似乎数据库not-quite-ready也存在某些内容。

这解决了这个问题，但我更喜欢一个更好的解释，或者一个替代解决方案，它不会让一个神奇的，任意的延迟等待数据库真的准备就绪。< / p>

相关问题
最新问题