[Oracle 10g] Importeren van een .dmp file

[MMUilwijk]

Ik probeer een .dmp bestand van een "vreemde" Oracle server (9.x.x) te importeren in een schone Oracle 10g omgeving. Dit kan uiteraard met het imp commando.

De database omgeving is geinstalleerd in c:\oracle\... Ik probeer vervolgens te importeren met:

code:

imp sysman/password full=y commit=y ignore=y log=filetje

waarbij e.e.a. uiteraard vervangen is door de juiste gegevens

Het probleem is nu dat ik een foutmelding krijg die mij meldt dat de locatie niet gevonden kan worden waarnaar de inhoud van de dump weggeschreven moet worden. Een inspectie van het logbestand leert dat de dmp file verwacht dat de database in c:\Uo2\... moet worden geplaatst. Als ik vervolgens de mappen aanmaak gaat het importeren wel goed en zie ik ook fysiek de .dbf files terug in de map. Echter, nergens in de oracle omgeving is de database te zien! Noch in de Database Administration Tool, noch via het aanmaken van een listener kan ik een connectie maken met de database.

Omdat ik niet weet met welke user de .dmp file is geexporteerd kan ik dit ook niet overzetten (fromuser touser). De -help optie van imp laat mij ook geen opties zien waarmee ik de standaard locatie kan wijzigen, en ook aangeven dat de data in een lege database die wel bestaat moet worden geplaatst behoort niet de mogelijkheden.

Iemand enig idee hoe ik toch de data kan importeren zonder hulp van vage exotische tools?

[JaQ]

MMUilwijk schreef op zaterdag 01 december 2007 @ 15:37:
Ik probeer een .dmp bestand van een "vreemde" Oracle server (9.x.x) te importeren in een schone Oracle 10g omgeving. Dit kan uiteraard met het imp commando.

De database omgeving is geinstalleerd in c:\oracle\... Ik probeer vervolgens te importeren met:

code:

imp sysman/password full=y commit=y ignore=y log=filetje

waarbij e.e.a. uiteraard vervangen is door de juiste gegevens

Het probleem is nu dat ik een foutmelding krijg die mij meldt dat de locatie niet gevonden kan worden waarnaar de inhoud van de dump weggeschreven moet worden. Een inspectie van het logbestand leert dat de dmp file verwacht dat de database in c:\Uo2\... moet worden geplaatst. Als ik vervolgens de mappen aanmaak gaat het importeren wel goed en zie ik ook fysiek de .dbf files terug in de map. Echter, nergens in de oracle omgeving is de database te zien! Noch in de Database Administration Tool, noch via het aanmaken van een listener kan ik een connectie maken met de database.

Omdat ik niet weet met welke user de .dmp file is geexporteerd kan ik dit ook niet overzetten (fromuser touser). De -help optie van imp laat mij ook geen opties zien waarmee ik de standaard locatie kan wijzigen, en ook aangeven dat de data in een lege database die wel bestaat moet worden geplaatst behoort niet de mogelijkheden.

Iemand enig idee hoe ik toch de data kan importeren zonder hulp van vage exotische tools?

Sinds wanneer worden er datafiles aangemaakt via een dump? Ik heb nog nooit meegemaakt dat de import utility tablespaces en datafiles voor me aanmaakt. Wel heb ik veel problemen ondervonden door het ontbreken van de juiste tablespaces, users met rechten en of NLS_LANG settings.

In dit geval (omdat je niets weet over die dump), raad ik je aan om de dump te openen met ultraedit (of iets dergelijks) om eens rustig wat statements te gaan lezen. Hierbij moet je letten op (de eerder genoemde) datafiles en usernames.

Zonder ervaring in het importeren van dumpfiles en met weinig Oracle kennis kan dit nog wel eens een pijnlijke exercitie gaan worden voor je... Heb je geen Oracle DBA of Developer in je vriendenkring?

[kwiebus]

JaQ schreef op maandag 03 december 2007 @ 23:08:
[...]

Sinds wanneer worden er datafiles aangemaakt via een dump? Ik heb nog nooit meegemaakt dat de import utility tablespaces en datafiles voor me aanmaakt.

Als je een full import doet en je hebt de IMP_FULL_DATABASE role dan worden de volgende objecten voor je aangemaakt:

To import system objects from a full database export file, the IMP_FULL_DATABASE role must be enabled. The parameter FULL specifies that the following system objects are included in the import when the export file is a full export:

Profiles
Public database links
Public synonyms
Roles
Rollback segment definitions
Resource costs
Foreign function libraries
Context objects
System procedural objects
System audit options
System privileges
Tablespace definitions
Tablespace quotas
User definitions
Directory aliases
System event triggers

http://download-uk.oracle...er.101/b10825/exp_imp.htm

[JaQ]

kwiebus schreef op maandag 03 december 2007 @ 23:52:
[...]


Als je een full import doet en je hebt de IMP_FULL_DATABASE role dan worden de volgende objecten voor je aangemaakt:

en daar staan dus geen datafiles tussen

[kwiebus]

JaQ schreef op dinsdag 04 december 2007 @ 15:53:
[...]


en daar staan dus geen datafiles tussen

Mijn ervaring is toch anders.

Bevatten de Tablespace definitions dan niet de informatie om de tablespaces en datafiles aan te maken?

Als je bijvoorbeeld migreerd van UNIX naar Windows en een full import doet dien je er rekening mee te houden dat de import de datafiles wil creëren

Before importing the dump file, you must first create your tablespaces, using the information obtained in Step 1. Otherwise, the import will create the corresponding datafiles in the same file structure as at the source database, which may not be compatible with the file structure on the target system.

http://download-uk.oracle...er.101/b10825/exp_imp.htm

Ik ben natuurlijk geen echte Oracle DBA zoals jij maar hobby maar wat bij op mijn werk, dus zal ik het wel niet bij het juiste eind hebben.

[MMUilwijk]

JaQ schreef op dinsdag 04 december 2007 @ 15:53:
[...]


en daar staan dus geen datafiles tussen

Tsja, en toch worden die datafiles aangemaakt. Die verzin ik er niet bij Daarnaast zie ik ook daadwerkelijk een import van de rows gebeuren. Wanneer ik het bestand open met een texteditor zie ik inderdaad de diverse statements. Ga proberen om wat wijzigingen aan te maken met betrekking tot filelocation e.d., maar ik begrijp niet goed waarom de database niet in de huidige Oracle omgeving wordt gehangen. Dat moet het import commando toch ook (kunnen) regelen?

Wat betreft ervaring, heb redelijk veel SQL Server ervaring (understatement), maar Oracle is enigzins nieuw voor mij. Ontdek wel dat er weinig grafische managementtools bijgeleverd zijn, maar goed.

Enfin, iemand suggesties hoe ik het .dmp bestand wel goed geimporteerd krijg?

[kwiebus]

Ik ben niet zo bekend met Oracle op Windows maar heb wel enige ervaring met Oracle op AIX.

Bij jouw import commando geef je in de connect string niet mee naar welke ORACLE_SID je connect, ik neem aan dat je deze als variable gezet hebt naar de juiste instance voordat je de import startte?

Heb je de alert log van de database bekeken?

Wat voor foutmelding krijg je als je met sqlplus probeert te connecteren naar de database?

[JaQ]

kwiebus schreef op dinsdag 04 december 2007 @ 16:46:
[...]


Mijn ervaring is toch anders.

Bevatten de Tablespace definitions dan niet de informatie om de tablespaces en datafiles aan te maken?

Als je bijvoorbeeld migreerd van UNIX naar Windows en een full import doet dien je er rekening mee te houden dat de import de datafiles wil creëren

Ik ben natuurlijk geen echte Oracle DBA zoals jij maar hobby maar wat bij op mijn werk, dus zal ik het wel niet bij het juiste eind hebben.

Je hebt helemaal gelijk, ik wist dit niet (en had dit even horen op te zoeken voordat ik schreeuwde, juist als DBA ben ik dat verplicht ).

MMUilwijk schreef op dinsdag 04 december 2007 @ 19:09:
Tsja, en toch worden die datafiles aangemaakt. Die verzin ik er niet bij Daarnaast zie ik ook daadwerkelijk een import van de rows gebeuren. Wanneer ik het bestand open met een texteditor zie ik inderdaad de diverse statements. Ga proberen om wat wijzigingen aan te maken met betrekking tot filelocation e.d., maar ik begrijp niet goed waarom de database niet in de huidige Oracle omgeving wordt gehangen. Dat moet het import commando toch ook (kunnen) regelen?

Als een compleet path voor het datafile wordt opgegeven in de dump, dan kan je weinig vrees ik (anders dan in de dump editen, maar ik ga je net garanderen dat je die dump daarna nog kan importeren). Als er geen path bij het datafile staat, zou je met de db_create_file_dest parameter kunnen spelen. (db_file_name_convert gaat niet werken in dit geval).

Verder zou het logfile van de imp utility, of het alert$SID.log van de database (normaliter in %ORACLE_HOME%/admin/%ORACLE_SID%/bdump te vinden, anders op de locatie van background_dump_dest) iets moeten roepen.

[kwiebus]

JaQ schreef op woensdag 05 december 2007 @ 20:02:
[...]


Je hebt helemaal gelijk, ik wist dit niet (en had dit even horen op te zoeken voordat ik schreeuwde, juist als DBA ben ik dat verplicht ).

Een simpele import is natuurlijk ook veel te triviaal voor een echte Oracle ACE.

[MMUilwijk]

JaQ schreef op woensdag 05 december 2007 @ 20:02:
[...]


Je hebt helemaal gelijk, ik wist dit niet (en had dit even horen op te zoeken voordat ik schreeuwde, juist als DBA ben ik dat verplicht ).


[...]


Als een compleet path voor het datafile wordt opgegeven in de dump, dan kan je weinig vrees ik (anders dan in de dump editen, maar ik ga je net garanderen dat je die dump daarna nog kan importeren). Als er geen path bij het datafile staat, zou je met de db_create_file_dest parameter kunnen spelen. (db_file_name_convert gaat niet werken in dit geval).

Verder zou het logfile van de imp utility, of het alert$SID.log van de database (normaliter in %ORACLE_HOME%/admin/%ORACLE_SID%/bdump te vinden, anders op de locatie van background_dump_dest) iets moeten roepen.

Ok dat ga ik morgen gelijk proberen, samen met het hacken van de dump file. Zal ook direct even kijken of ik iets kan doen met db_create_file_dest en/of het Oracle_SID. Ik las op een Duitse site iets over het connecten met een ORACLE_SID specifieke user (als in user/password@ORACLE_SID), misschien dat ik daar wat verder mee kom.

Anders is misschien het handmatig aanmaken van de juiste tablespaces en die laten overschrijven door de dump een idee?

[kwiebus]

JaQ schreef op woensdag 05 december 2007 @ 20:02:
Als een compleet path voor het datafile wordt opgegeven in de dump, dan kan je weinig vrees ik (anders dan in de dump editen, maar ik ga je net garanderen dat je die dump daarna nog kan importeren).

Waar zou je trouwens de dump mee willen editen? Het is volgens mij een binair bestand wat je niet zomaar even met een texteditor kunt editten.

[justmental]

Je moet kijken hoe de tablespaces heten in de dump, dat kun je met een text editor.
Vervolgens maak je deze tablespaces aan in je doel database.
Bij het importeren gebruik je ignore=y en kun je de foutmeldingen op het aanmaken van de tablespaces negeren.

[JaQ]

kwiebus schreef op woensdag 05 december 2007 @ 20:15:
Een simpele import is natuurlijk ook veel te triviaal voor een echte Oracle ACE.

gaat ie dat zeggen.... alsof je als ACE alles weet (nou ja.. bijna alles dan ). Maareh.. ken ik jou toevallig, of heb je dit uit de HK?

kwiebus schreef op woensdag 05 december 2007 @ 23:00:
Waar zou je trouwens de dump mee willen editen? Het is volgens mij een binair bestand wat je niet zomaar even met een texteditor kunt editten.

Nou.. er zit een show vlag bij je import utility. Je kan daarmee de statements uit je dump filteren.... (maar een texteditor als VIM heeft ook al meer dan eens dienst bewezen. Garantie tot de hoek )

[kwiebus]

JaQ schreef op donderdag 06 december 2007 @ 14:30:
gaat ie dat zeggen.... alsof je als ACE alles weet (nou ja.. bijna alles dan ). Maareh.. ken ik jou toevallig, of heb je dit uit de HK?

Je hebt jouw naam staan in het e-mail adres in jouw profiel en dan is één en één snel twee. Jij bent namelijk enige tijd geleden bij ons op bezoek geweest in verband met een migratie project en toen door jouw werkgever geïntroduceerd als Oracle ACE.

JaQ schreef op donderdag 06 december 2007 @ 14:30:

Nou.. er zit een show vlag bij je import utility. Je kan daarmee de statements uit je dump filteren.... (maar een texteditor als VIM heeft ook al meer dan eens dienst bewezen. Garantie tot de hoek )

Uiteraard kan je met een texteditor achterhalen wat de statement zijn in de dump file. Maar als je deze probeert aan te passen in de dumpfile dan kan je volgens mij een succesvolle import hiervan wel vergeten.

[JaQ]

kwiebus schreef op donderdag 06 december 2007 @ 14:58:
Je hebt jouw naam staan in het e-mail adres in jouw profiel en dan is één en één snel twee. Jij bent namelijk enige tijd geleden bij ons op bezoek geweest in verband met een migratie project en toen door jouw werkgever geïntroduceerd als Oracle ACE.

Aha.. je zit dus in Den Bosch?

tsja.. voor mijn werkgever is het commercieel interessant om daar mee te schermen.

kwiebus schreef op donderdag 06 december 2007 @ 14:58:
Uiteraard kan je met een texteditor achterhalen wat de statement zijn in de dump file. Maar als je deze probeert aan te passen in de dumpfile dan kan je volgens mij een succesvolle import hiervan wel vergeten.

mmm.. dan dus toch de show=y optie. Om eerlijk te zijn gebruik ik bijna nooit de imp en exp utilities van Oracle. Sinds Oracle 10.2 zijn ze alleen beschikbaar voor backwards compatibillity, niet voor nieuwe exports. Uiteraard werken ze nog wel, maar toch... Persoonlijk ben ik een enorme RMAN fan, het duurt alleen even voordat je goede RMAN skills hebt.

[kwiebus]

JaQ schreef op donderdag 06 december 2007 @ 15:25:
Aha.. je zit dus in Den Bosch?

Good Guess.

JaQ schreef op donderdag 06 december 2007 @ 15:25:Sinds Oracle 10.2 zijn ze alleen beschikbaar voor backwards compatibillity, niet voor nieuwe exports. Uiteraard werken ze nog wel, maar toch...
Persoonlijk ben ik een enorme RMAN fan, het duurt alleen even voordat je goede RMAN skills hebt.

Eerlijk gezegd ben ik (nog) niet zo bekend met alle features van Oracle 10g. Ik gebruik import en export nog altijd. Ik maak van alle databases zowel (full) exports als RMAN backups. Als ik snel even alleen een table terug moet halen dan is een import wel erg handig. RMAN gebruik ik voor disaster recovery om makkelijk een complete database terug te kunnen halen.