Re: Export and Import Utility

From: Stan Novinsky <stan_novinsky_at_jhuapl.edu>
Date: 1995/06/27
Message-ID: <3sp1vd$jqr_at_aplinfo.jhuapl.edu>


Stan Novinsky <stan_novinsky_at_jhuapl.edu> wrote:
>
> rod.fergusson_at_canada.attgis.com (Rod Fergusson) wrote:
> >
> > In article <3rhcrm$775_at_aplinfo.jhuapl.edu>, stan_novinsky_at_jhuapl.edu
> > says...
> > >
> > >Rod Fergusson <rod.fergusson_at_canada.attgis.com> wrote:
> > >>
> > >
> >
> > Hi Stan!
> >
> > Hmmm...Yes you are correct...you have to export the whole table...you
> > can't just export a row. Now...messages from 45 tables...1 row
> > each...that is going to be brutal to track if you are exporting a slew
> > of 1 record .DMP files to tape. Your solution will become very
> > complicated if your client insists on storing the files on tape. By the
> > way...I did a little research to make sure that streaming to tape was in
> > fact a real possibility and not just a theory. I knew that it was
> > possible to stream Oracle Archiver Logs directly to tape...but could not
> > find any reference to export & import files. I called Oracle to verify
> > that the export & import utilities would accept the specification of a
> > tape device as opposed to a disk device and they said that yes you are
> > able to do so...but they do not recommend doing so unless you files will
> > be relatively small...which appears to be the situation in this case.
> > The reason they deter people from doing this with larger files is the
> > risk of transmission errors buggering up the export files. For your
> > reference the Oracle TAR (Technical Application Request) number is
> > #623519.
> >
> > Based on the scenerio that you have painted...two of the biggest issues
> > you have to resolve are; (1) tracking the date,time and filenames of
> > export files written to tape (2) retrieving the data correctly from a
> > sequentially written tape file. Before proceeding with trying to
> > resolve these issues, I would suggest that you re-visit this issue with
> > your client...if disk space isn't a problem, why don't they just let you
> > stuff the records into a database table? The client is going to pay in
> > a very big way in terms of application performance if they choose to
> > write everything to tape. What happens if the tape fills up midday, the
> > computer operator is on lunch and there is no one to pop a new tape in
> > the drive...what is the application going to do if it can't write?? Or,
> > what is going to happen if the client wants to retrieve some logs, but
> > they were partially written on a previous tape...and now two tape mounts
> > have to be performed..? How are they going to know which tape volume
> > to tell the Operator to mount? Is your client prepared to wait the time
> > necessary to mount the tapes...and for the application to try to find
> > the desired files...load them...and finally view them? If these delays
> > are acceptable...then I guess you will have to proceed as we had
> > discussed earlier. Can you write to 1 table instead of 45? If
> > yes..then what I think you should look at is writing AFTER INSERT
> > triggers on the 45 various tables that essentially write whatever the
> > log record was that you inserted into the (1 of 45) tables...into one
> > "collector" table that you create. That way...you don't have to do 45
> > separate exports of 1 row...you can do intermittant exports of all the
> > records that you have accumulated in your collector table. No matter
> > which solution you choose to employ...you are going to have to maintain
> > database tables to track the date,time,tape volume ID and filename for
> > retrieval purposes. So...dependant on their rationale for wanting to
> > cut everything to tape...this may/may not defeat the purpose of it. Let
> > me know if you want to continue to work on a solution to manage the
> > export/import of these records to tape...I am very curious as to why
> > they want to use tape...any insights?
> >
> > Sincerely, Sandra Fergusson
> >
> Hello Sandra:
>
> I greatly appreciate the call to ORACLE. From all documentation I
> have read, only a file (.DMP) could be exported. This is, I guess
> good news.
>
> I agree with you that this will be "brutal". But, we must push on.
>
> Anyway, this tape requirement thing is written in a document that
> we must adhear to. The user, at any time, "will have the option
> to save log data to tape" and "retrieve data and view date".
> We can not change the requierment. I will be meeting with my
> project members in the next few days to discuss solutions.
> I will respond later with any new news.
>
> Thanks again.
>
> Stan
>
>

I thought I would just keep in touch with this posting. We have not come up with any definite solution on how to perform the logging of table info to tape. One idea discussed was to keep an RMS file or files as a parallel branch to the tables. That is, when a entry is logged into a table, write this entry to the file. That way, that data can be copied to tape without extracting it from the DB table. The problem with this is, when the data neeeds to be restored and viewed, how will the user view it from a Form? It would have to be inserted into a table for viewing...

Any comments.

We still have to meet and discuss other options in our design besides this problem. This may take a while.

Thanks

Stan Received on Tue Jun 27 1995 - 00:00:00 CEST

Original text of this message