[Oracle] Foutmelding schema SYS tijdens import ander schema*

[One_Gandalf]

Versie imp : 8.1.7.0.0

imp / file=database_full.dmp log=imp_schema.log fromuser=a,b,c touser=a,b,c rows=y

De dump-file is aangemaakt als een full export (full=y).

Bij de import worden alleen de schema's a, b en c geïmporteerd.

In de log-file 'imp_schema.log' komen echter de volgende foutmeldingen voor :

code:

IMP-00017: following statement failed with ORACLE error 1:
"BEGIN sys.dbms_ijob.submit( ... ); END;"
IMP-00003: ORACLE error 1 encountered
ORA-00001: unique constraint (SYS.I_JOB_JOB) violated
ORA-06512: at "SYS.DBMS_IJOB", line 210
ORA-06512: at line 1

Op de plaats van de drie puntjes staan de parameters voor 'sys.dbms_ijob.submit'.

Het object SYS.I_JOB_JOB is een index die bestaat uit het jobnummer. Blijkbaar is het jobnummer reeds aanwezig in de database.

Aangezien ik niet expliciet het schema SYS importeer vraag ik me af of het normaal is dat er toch geprobeerd wordt om objecten uit het schema SYS te importeren.

[drStrangepork]

Er is niets bijzonders aan dat er zaken in het SYS schema worden ingelezen. Metadata meestal, bijvoorbeeld over jobs zo blijkt...

Overigens zie ik dat je import versie 8.1.7.0.0 gebruikt. Laatste patchlevel is op zijn minst 8.1.7.0.4.0. Ik denk dat het zeker de moeite waard is om het met het hoogste patchlevel opnieuw te proberen. Er zijn issues geweest met import.

[JaQ]

Het probleem is niet je patchlevel (alhoewel: 8.1.7.0.0 is niet gesupport, voor support MOET je patchen naar 8.1.7.0.4 en dat is enkel sustaining support.) Anyway, een van de gebruikers die je probeert te importeren heeft blijkbaar een job. Ga eens in je bron database en voer deze query uit (als sys):

select job from dba_jobs;

Voer vervolgens dezelfde job uit in je target database en vergelijk de job nummers. Het kan ook zijn dat er privileges missen op de objecten in de job die je probeert te importeren (bijvoorbeeld een select grant op een tabel).

Mits je niet geïnteresseerd bent in de job, kan je altijd de data importeren met ingore=y.

Eventueel kan je de import ook doen met de opties "show=y rows=n",waarna je de output na een bestand cat en hier vervolgens de job in opzoekt (pas op, afhankelijk van de grootte van de schema's kan dit erg veel data veroorzaken).

[One_Gandalf]

JaQ schreef op woensdag 08 september 2010 @ 23:26:
...
Anyway, een van de gebruikers die je probeert te importeren heeft blijkbaar een job.
...

Klopt.

JaQ schreef op woensdag 08 september 2010 @ 23:26:
...
Mits je niet geïnteresseerd bent in de job, kan je altijd de data importeren met ignore=y.
...

De import van alle andere objecten is goed verlopen. Ik was eigenlijk alleen nieuwsgierig naar de reden van de melding.

[ Voor 44% gewijzigd door One_Gandalf op 12-09-2010 16:35 ]

[JaQ]

One_Gandalf schreef op zondag 12 september 2010 @ 16:33:
De import van alle andere objecten is goed verlopen. Ik was eigenlijk alleen nieuwsgierig naar de reden van de melding.

Die komt of door een gebrek aan rechten op dbms_job (oftewel: die gebruiker mag geen jobs aanmaken), of het komt door gebrek aan privileges op acties die in die job worden uitgevoerd. Heb je een privilege gemist bij het aanmaken van de gebruiker? (dba_sys_privs kan je helpen).

[DvE]

Het lijkt er eerder op dat er al een job met dat jobnummer al bestaat (een van de parameters bij het opvoeren van de job).
Vandaar dat de index (constraint) klaagt over het feit dat er een unique constraint overtreden (violated) wordt.
Kijken wat de job aanroept en hoe vaak en je kan deze alsnog handmatig later opvoeren.

Overigens is het versie 8.1.7.4 (niet 8.1.7.0.4)
Zoiezo is dat al een relatief oude versie

[JaQ]

Als je me dan (terecht) verbeterd, doe het dan wel goed (alhoewel mijn eerste punt wel een dubbel jobnumber suggereert). Het jobnumber is een uitvoerparameter, die kan je niet meegeven bij het aanmaken van een job in 8.1.7 volgens de documentatie