Home » RDBMS Server » Server Utilities » EXP vs IMPDP interrogating dump file (10g and up, SUSE 10)
EXP vs IMPDP interrogating dump file [message #466094] Fri, 16 July 2010 18:12 Go to next message
jacc
Messages: 3
Registered: July 2010
Location: North Dakota
Junior Member
Hello Everyone (newbie alert),

I have a bit of an issue with Oracle datapump dump files and I am trying to figure out a solution.

Today, I manage the export and import of oracle dump files. As part of the batch export process I have a script which essentially says:

For each schema realated to my application in THIS instance, export schema via the system user (system user allows me privs to all schemas).



On the import UI side of things I am able to run a "head -20" command on the dmp file and determine the "export client version", "date the schema was dumped", and "what schema it was dumped from". All useful info presented in my UI.

Sample output: Begin

EXPORT:V09.02.00
DSYSTEM
RUSERS
8192
Wed Jun 30 11:51:21 UserXXX.dmp
#C##
#C##
-05:00
BYTE
INTERPRETED
CONNECT UserXXX
PROCACTION
BEGIN
sys.dbms_logrep_imp.instantiate_schema(schema_name=>'UserXXX', export_db_name=>'instanceName', inst_scn=>'71081913');

Sample output: End


This helps me, in that I allow the importation of production schemas into test schemas, (contained in a different tablespace). Based on naming convention I can determine the schema type (production or test). Additionally and probably most importantly, I am assured where the data has come from.

In looking at "expdp" and the dump file. Using the same method as above, it appears the data pump dump DOES NOT carry similar headers. Because of this, I am unable to return very little useful info from the dump file.


I realize I could run the impdp with the "sqlfile=myfile.sql" and then interrogate the sql file for the info. But on large dump files this would be fairly time consuming compared to a "head -20" on a dump file.

Okay that is the background.

Now the question. I would greatly appreciate any suggestions on how to resolve this issue? Please keep in mind after interrogating the dump file a UI must be presented (so time is of the essence).

Thanks in Advance

Jim
Re: EXP vs IMPDP interrogating dump file [message #466655 is a reply to message #466094] Tue, 20 July 2010 07:48 Go to previous messageGo to next message
LKBrwn_DBA
Messages: 487
Registered: July 2003
Location: WPB, FL
Senior Member
Maybe that is the reason you should KEEP the log file(s).

[Updated on: Tue, 20 July 2010 07:51] by Moderator

Report message to a moderator

Re: EXP vs IMPDP interrogating dump file [message #466699 is a reply to message #466655] Tue, 20 July 2010 11:32 Go to previous messageGo to next message
jacc
Messages: 3
Registered: July 2010
Location: North Dakota
Junior Member
Thanks for the reply.

You are probably right, I do have the log file available to me.

Problem with the log file is there is no real relationship between it and the actual dump file. I can have a log file which says one thing and a dumpfile which could have been restored, copied, moved, ftp'd from anywhere potentially. Not to mention the log file becoming corrupted for whatever reasons.

To use an analogy, this is no different than carrying a note that says "This hundred dollar bill is not counterfeit" and that makes the hundred dollar bill legit.

I suppose a person could create some sort of CRC on the log file and the dump file at the time they are created and then make comparisons and then if a match, interrogate the log file to determine the dump files source.

But...... It seems there ought to be a way (an oracle convenience tool) to internally determine the source of the dump file and if altered in anyway the integrity of the dump file should be considered compromised.



Re: EXP vs IMPDP interrogating dump file [message #466701 is a reply to message #466699] Tue, 20 July 2010 12:28 Go to previous messageGo to next message
cookiemonster
Messages: 13961
Registered: September 2008
Location: Rainy Manchester
Senior Member
I'd suggest oracle assumes everyone can protect the integrity of their own dump files.
If you control what they're called and where they are put there shouldn't be an issue.
Re: EXP vs IMPDP interrogating dump file [message #466741 is a reply to message #466701] Tue, 20 July 2010 17:23 Go to previous message
jacc
Messages: 3
Registered: July 2010
Location: North Dakota
Junior Member
I think you are missing what I am striving for here. Yes, there are things I should be doing to insure the integrity of my data, such as "determining the dumpfiles source", securing access, naming convention, file security......

As part of my due diligence, I was hoping there would be a little help from the process which creates the dump file which would assist me in identifying the source of the content of the dump file, since the process is building the dump file (perhaps a LABEL parameter).

But since it appears there is not, every consumer of the product is forced to create their own methods of identifying the source of the dumpfile as it moves around from system to system during it life. This practice, in my opinion, lends to inconsistent and unreliable results which is by no means a benefit.



Previous Topic: HOW TO PROCESS ASCII CHARACTER 29 WHILE LOADING DATA WITH SQL LOADER
Next Topic: Migration from postgress into oracle columns with spaces
Goto Forum:
  


Current Time: Mon Dec 23 14:24:00 CST 2024