| EXP vs IMPDP interrogating dump file [message #466094] |
Fri, 16 July 2010 18:12  |
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 #466699 is a reply to message #466655] |
Tue, 20 July 2010 11:32  |
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 #466741 is a reply to message #466701] |
Tue, 20 July 2010 17:23 |
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.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
