3
我正試圖將模式導入到Ubuntu14.04中的dockerized容器。容器基於this image，其中包含Oracle XE 11g。警報日誌沒有顯示任何內容，並且impdp本身生成的跟蹤只顯示最後創建的表腳本（每次運行都不相同）。如何診斷與Oracle數據泵導入失敗的問題，錯誤1089
我使用的命令是：
/u01/app/oracle/product/11.2.0/xe/bin/impdp myshema/[email protected]"(DESCRIPTION\=(ADDRESS_LIST\=(ADDRESS\=(PROTOCOL\=TCP)(HOST\=db)(PORT\=1521)))(CONNECT_DATA\=(SID\=XE)))" PARFILE=/myschema/myschema.par;
導入進行了一段時間，則在一些半隨機點失敗，「Oracle錯誤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不過，因爲它每次數據庫啓動時（從原始碼頭鏡像開始）都會發生，並且似乎不會影響其他任何內容。
導入有一個相關的跟蹤日誌：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
[email protected]:/u01/app/oracle/diag/rdbms/xe/XE/trace#
刪除我的答案，沒有幫助。數據庫已打開，部分導入成功（'MYSCHEMA'中有1909個對象），但仍以「UDI-01089」中止。我迷路了。 –
謝謝@Martin。我也可以從導入的''中選擇*，併成功返回0行（導入只包含模式 - 沒有數據）。 –
Gerrat
可能會將「TABLE_EXISTS_ACTION = SKIP」添加到您的導入參數文件並重新啓動導入，直到它成功完成？這並不能解釋它，但它可能會解決你眼前的問題（現在......）。 –