Probleme beim Import eines Datenbank dump

[SonnyHH]

Hallo zusammen,

ich bin leider in Sachen Oracle Administration nicht wirklich fit und habe aktuell ein Problem beim Import einer Datenbanksicherung in eine neue Datenbank.

Szenario:
Ich möchte den dump einer produktiv genutzten Datenbank (Oracle 10g) in einer neue Datenbank (Testdatenbank) importieren.
BTW: Ich weiß, dass die Version hoffnungslos veraltet ist, die Benutzung hat aber ihre Gründe. ;-)

Die Datenbank wird jede Nacht mit folgendem Befehl gesichert:

set oracle_sid=klug
exp 'system/passwort' file=d:\backup\klug.dmp full=Y log=d:\backup\klugexp.log

Ich habe nun eine neue Datenbank angelegt und folgende Schritte ausgeführt (so vom Vorgänger übernommen):

set oracle_sid=testklug
sqlplus
Benutzer: system
Passwort: passwort
create user admin identified by passwort;
grant dba to admin;

exit

Dann möchte in den dump mit folgendem Befehl importieren:

set oracle_sid=testklug
imp 'system/passwort' file=d:\backup\klug.dmp full=Y log=d:\backup\klugimp.log

Der Import startet und bricht irgendwann an folgender Stelle ab:

. importing TSMSYS's objects into TSMSYS
"ALTER SESSION SET CURRENT_SCHEMA= "TSMSYS""
IMP-00003: ORACLE error 1435 encountered
ORA-01435: user does not exist
IMP-00000: Import terminated unsuccessfully

Der Fehler sagt mir überhaupt nichts, außer, dass ein User nicht existiert. Dieser User ist zu diesem Zeitpunkt tatsächlich nicht in der Benutzertabelle der Testdatenbank zu finden, während er in der Produktion vorhanden, aber deaktiviert ist.

Ich war davon ausgegangen, dass bei diesem Vorgehen die Benutzer alle aus dem dump angelegt werden und es hatte bisher auch immer mit diesen Skripten funktioniert, die schon seit Ewigkeiten hier benutzt werden.

Kann mir jemand einen Hinweis geben, woran es liegt, bzw. was ich zu tun habe?

Vielen Dank!

 

[dabadepdu]

Du machst einen FULL Export. (Full=y) Das bedeutet alle User der DB mit allen Schemata und den Daten dort drin werden exportiert.
Du importierst offenbar in eine leere DB oder eine die mit User/Schema Ausstattung nicht dem Original entspricht.

Import des Users TSMSYS macht u.U. keinen Sinn, weil seine Aufgabe hauptsächlich aus Funktionserweiterungen (z.B. Grid) besteht. Das kann ich aber nicht sicher sagen. Da er in der Quelle deaktiviert ist, brauchst Du ihn sehr wahrscheinlich nicht. Jedenfalls kann man den User und seine Funktionen per Script anlegen.

Irgendwas an Deinen Angaben kann nicht stimmen (Hat immer funktioniert).
Ggf ist die ZielDB, die ja auch irgendwo herkommen muss, sonst anders entstanden?


Der User, der hier zum Fehler führt, ist ein Standard User von Oracle DB und Du könntest den z.B. einfach anlegen leer anlegen, bevor Du den Import startest (und ihn auch direkt deaktivieren). Dann würde das Script weiter laufen (bis zum nächsten fehlenden User)
Oder Du könntest feststellen, welche User Du überhaupt brauchst. Mglw nur einen einzigen.

In Oracle hat jeder User ein eigenes Schema. Was in anderen Systemen einer ganzen DB entsprechen kann. Ein Full Backup macht nur bedingt Sinn, bzw. ein Full Backup auch Full wieder einzuspielen, macht wenig Sinn.

Finde raus, welche User / Daten / Funktionen Du brauchst.
Wenn die Import und Exportbefehle immer so liefen, dann
finde raus, wie die DB testklug zuvor initialisiert wurde. (Es macht einen Unterschied, ob man eine DB mit der UI erstellt oder mit einem create Befehl. Das Create ist relativ minimalistisch, der Weg über die UI legt mglw. viel mehr an, als man braucht. Davon ist u.U. einiges Kompatibilitätsbalast, der so oder ähnlich nie verwendet wird/wurde, nicht nur der User TSMSYS.

 

[SonnyHH]

Vielen Dank für die Antwort.

Ich habe den Prozess so übernommen, der besagt:

- Testdatenbank löschen
- Neue Datenbank anlegen (UI)
- Admin User erstellen und dbo zuweisen
- dump einspielen

Die Datenbank dient einer alten Software und enthält sehr viele User, die mit der Software arbeiten.

Es ist eigentlich egal, ob bestimmte Accounts notwendig sind oder nicht. Das Ziel ist, dass die Testdatenbank als Clone der Produktionsdatenbank existiert und darin "gespielt" werden kann. Die "realen" User werden natürlich benötigt.

Ich habe jetzt einmal den TSMSYS User angelegt und den Import neu gestartet. Läuft jetzt deutlich länger und es werden etliche Objekte importiert. Die Software lässt sich sogar bereits starten, als wäre alles in Ordnung.

Allerdings steigt der Import erneut aus und meldet, dass ein User nicht vorhanden ist. Bei diesem User konnte ich den Namen identifizieren und es handelt sich um eine reale Person aus dem Unternehmen.

Ist es bei Oracle nicht möglich, eine 1:1 Kopie einer DB zu erstellen?

 

[castorp]

Ist es bei Oracle nicht möglich, eine 1:1 Kopie einer DB zu erstellen?

Nicht mit der Version 10.

Seit der 12.x geht das über pluggable databases. Und mit datapump (expdp, impdp) geht das alles auch deutlich einfacher.

Eigentlich dachte ich, dass imp die User aus einem "FULL=Y" export auch mit anlegt. Nur Tablespaces muss man vorher manuell anlegen. Ich habe aber imp/exp bestimmt schon seit über 15 Jahren nicht mehr verwendet (ist ja irgendwie deprecated). Also ja, kann durchaus sein, dass man alle User bei Verwendung von imp vorher manuell anlegen muss.

Hast Du mal versucht imp mit IGNORE=y zu starten? Dabei werden Fehler ignoriert und der Import macht weiter. Kannst ja dann mal prüfen was dann tatsächlich importiert worden ist.

 

[SonnyHH]

Vielen Dank, ich werde den Parameter mal testen.

 

[castorp]

Hmm, laut Handbuch sollten die Benutzer vollständig in einem Dump enthalten sein. Allerdings können die nur zurückgespielt werden, wen der User der IMP laufen lässt, die Rolle IMP_FULL_DATABASE hat. Ich weiß nicht mehr wie das in Oracle 10 war, aber es könnte durchaus sein, dass das nur mit SYS, aber nicht mit SYSTEM geht.

 

[dabadepdu]

Neue Datenbank anlegen (UI)

Das ist u.U. der problematische Punkt, weil es variiert werden kann und nicht zu bestehenden Skripten passt oder nicht so gemacht wird, wie es erforderlich wäre.

Es ist eigentlich egal, ob bestimmte Accounts notwendig sind oder nicht.

Halte ich für eine gewagte Theorie. Wenn man Oracle hat, dann vielleicht weil man etwas von seinen Möglichkeiten nutzt und selbst wenn das nur 1 stellige % der Möglichkeiten sind, hat man eine gute Chance, dass man Oracle System User benötigt oder auch individuelle (selbstprogrammierte) Schema oder sogar individuelle Daten der Unternehmens-User.

Ist müßig, müsstest Du wissen oder ein Kollege oder rausfinden.

Alternativ zu ignore errors würde ich einfach alle User anlegen, die im Quellsystem vorhanden sind.
Die kann man mit einem Select Statement abfragen und daraus create scripte machen oder gleich ein Select, was die Create User Anweisungen ausgibt.

Bei diesen Usern gibt es vlt. ca ein Dutzend Oracle System User, wo man sich überlegen kann, ob man sie exportiert und importiert oder per Script neu anlegt.
Nebenbei muss es irgendein Verfahren geben, was für die "Spiel"-User auch Passwörter vergibt, wiederherstellt, ... zumindest wenn es viele sind, sollte es irgendwas schlaue geben (z.B. das Original PW, das aus dem Backup stammt)

Mglw. ist der Schlüssel zu der Sache kein reiner Export-Import, sondern initial das Restore eines rictigen Backups (inkl. aller Bestandsuser und deren Credentials). Dann Löschen des Application Users (Altdaten) und Export, Import der aktuellen Application User Daten. Wenn das so war, dann wäre der Schritt "- Löschen der Testdatenbank" tatsächlich nur ein "- Löschen des Schemas / Tabellen des Application Users".

Du kannst natürlich ein aktuelles Backup der Quell Datenbank einspielen. Ohne die Nutzung von exp/imp.

Du kannst alternativ wahrscheinlich auch Oracle Tools neuerer Versionen nehmen, so vorhanden. Mit 12er Tools z.B. solltest Du auch auf 10er DB zugreifen können, also mit einer neueren, komfortableren Version ein Backup anlegen oder in die Testumgebung spielen. Das Spiel geht aber nicht beliebig ewig rückwärts. 12 ist ja auch schon uralt. Ob man mit 19c Tools noch eine 10er "bedienen" kann, weiß ich nicht.