3
fehlschlägt? Ich versuche, ein Schema in einen dockerisierten Container in Ubuntu14.04 zu importieren. Der Container basiert auf this image, die Oracle XE 11g enthält. Das Alert-Log zeigt nichts davon an, und der von impdp selbst erzeugte Trace zeigt nur das zuletzt erstellte Tabellenskript (das bei jedem Lauf anders ist).Wie kann ich das Problem diagnostizieren, dass der Oracle Data Pump-Import mit Fehler 1089
Der Befehl Ich verwende ist:
/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;
Die Einfuhr Erlös für eine Weile, dann irgend semistochastische Punkt scheitert mit „Oracle-Fehler 1089“. Es wird teilweise durch die Erstellung der Tabellen (wiederholte Läufe enden jeweils an einer anderen Tabelle). Die Verbindung mit meiner Oracle-Instanz aus einer anderen Sitzung zeigt, dass die Instanz auch nach diesem Fehler noch aktiv ist.
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
Meine Parameterdatei ist:
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
Nur der Vollständigkeit halber, die nur unpassende Linien im Alarmprotokoll sind:
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
Dies scheint jedoch eine red herring zu sein, wie es tritt jedes Mal auf, wenn die Datenbank gestartet wird (direkt vom ursprünglichen Docker-Image), und scheint nichts anderes zu beeinflussen.
Es gibt ein relevantes Ablaufverfolgungsprotokoll für den Import: XE_dm00_232.trc. Nichts scheint mir ungewöhnlich bis zum Ende. Leider ist für mich, ist diese Information nicht wirklich hilfreicher als der Fehler 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#
Löschte meine Antwort, war nicht hilfreich. Datenbank ist geöffnet, Import ist teilweise erfolgreich (1909 Objekte in 'MYSCHEMA'), bricht aber trotzdem mit' UDI-01089' ab. Ich bin verloren. –
Danke, @Martin. Ich kann auch 'auswählen * von', die importiert wurde, und es gibt erfolgreich 0 Zeilen zurück (der Import enthält nur das Schema - keine Daten). –
Gerrat
Fügen Sie Ihrer Importparameterdatei möglicherweise einen 'TABLE_EXISTS_ACTION = SKIP 'hinzu und starten Sie den Import neu, bis er erfolgreich abgeschlossen wurde. Das erklärt es nicht, aber es könnte Ihr momentanes Problem lösen (vorerst ...). –