DBAsupport.com Forums - Powered by vBulletin
Page 4 of 4 FirstFirst ... 234
Results 31 to 39 of 39

Thread: Export Direct=Y

  1. #31
    Join Date
    May 2002
    Posts
    219
    Originally posted by DcsoBob
    Okay, after a meeting with the boss, I must give her more credit than I did in the previoius posts. Confusion was on my part as to her understanding of the export issue. Boss was fully understanding the fact that the exports were only an Instant-in-time recovery and that all info would be lost between exports. She viewed these exports as a worst-case disaster recovery, assuming no access to the production machine.
    Reason she boss is the, hmmm?
    yodaDBA@hotmail.com

  2. #32
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Hm, DcsoBob, at the end it seems it turned out that my initial post (the one that kinda upset you, remember? ) was not only a criticism as you initialy saw it. Let me repeat what I wrote few days ago:
    The main question I see here is: Why on earth would someone want to take full export of a database every six hours?
    I think now you understand where I was pointing to. The main isue was not "How to speed up the export", it was "Do I realy need to do it?" (or at least "Do I realy need to do it so often"). And also "Am I aware of all the implication of my backup/recovery scenario and is it doable at all?".

    And don't forget about your new mantra from Jeff....
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  3. #33
    Join Date
    Feb 2001
    Posts
    99
    well, we are not quite there yet. And I have been chanting the mantra. I am going to spend the day playing with this arena some more.

    As a test of something you put in one of your replies, I also dropped the system tablespace. Big mistake. Now I get to practice full recovery. I am going to take my cold backup from the 3rd, restore the dbf files, control files, etc. Then, I am going to dump a trace of the current control file, copy over the archive logs since cold backup, and see what happens.

    Now, will this work? If i restore the dbf's in conjunction iwth the control file, the SCN's and other information should jive right. Cause its not really a new instance, its a copy of the old.


  4. #34
    Join Date
    Nov 2000
    Location
    greenwich.ct.us
    Posts
    9,092
    Originally posted by DcsoBob

    Now, will this work? If i restore the dbf's in conjunction iwth the control file, the SCN's and other information should jive right. Cause its not really a new instance, its a copy of the old.
    Yup, that's the idea. See http://metalink.oracle.com/metalink/...1&blackframe=0 for generalizations about backups and http://metalink.oracle.com/metalink/...T&p_id=69468.1 for your situation.
    Jeff Hunter

  5. #35
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Originally posted by DcsoBob
    As a test of something you put in one of your replies, I also dropped the system tablespace.
    What exactly do you mean by that????

    You have misundestood something obviously. In one of my replies I said you should drop SYSTEM user before the full import, not the SYSTEM tablespace!!!!! I suggested that because it was obvious that you don't know that only SYS objects are excluded from full export, but the objects from user SYSTEM are exported as any other user.

    So I guess it was entirely your fault. But on the other hand, I think what you did was a good thing. That way at least you are forced to practice real recovery. I guess your shop needed this the most.

    And once again: do not read this message as a criticism, it is not ment as one.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  6. #36
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Originally posted by DcsoBob
    Now I get to practice full recovery. I am going to take my cold backup from the 3rd, restore the dbf files, control files, etc. Then, I am going to dump a trace of the current control file, copy over the archive logs since cold backup, and see what happens.
    Be carefull with that! Two isues:

    1.) Do not restore online redo logs from your cold backup!
    2.) Do not restore controlfiles from your cold backup and do not backup your current control files to trace. No need for this, simply leave them as they are now and use them in the recovery.

    It is obviously you will have to do point in time recovery (up to the point where you dropped the SYSTEM tablespace). So when you are done with the applying redo logs you will have to open your database with RESETLOGS option.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  7. #37
    Join Date
    Feb 2001
    Posts
    99
    oops, I did not make something clear I think.

    All of this dropping/testing/etc is being done a test server. My production machine is alive and well, chugging right along.

    I did not drop the system tablespace, only the system user. If I type tablespace earlier....my bad.

    Jurij, I am not taking it as anything other than helpful input. I can take criticism, good always, bad most of the time. The one from you just happen to catch me at a REALLY bad point in my day. Don't sweat it, water under the bridge. Think we have our repoire established here so I want you to give it to me with both barrels!!

    After dropping the SYSTEM user, I executed an import of the DIRECT export. TONS of errors, failed miserably.

    So, to provide a test for me, my plan is to do the following on my TEST server:
    1) take the cold backup of my production system done 3 days ago and restore the dbfs, control files, redo logs, etc. Everything. Treat it as if I just installed oracle
    2) issue a log switch on my PRODUCTION machine.
    3) backup my PRODUCTION control file to trace.
    4) edit this trace to show the new locations of my dbfs, control files, etc, since they are different on my TEST server.
    5) copy over the archive logs from my PRODUCTION server to TEST server that were created since the shutdown and backup of PRODUCTION
    6) Mount the TEST database using the backup controlfile
    7) Roll forward the TEST database.
    8) if all goes well, the last command (according to the doc) is to issue the alter database open resetlogs

    Is my scenario workable? Pse, show me the errors. I am spending the today, tomorrow, and probably Friday working with this so I am comfortable.

    The only restore scenario I have done so far is to blow away oracle, and reinstall. NOTHING on the instance side changed. Database started right up and away we went. THAT was on semi-production server.

    Are we having fun yet?

  8. #38
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Ah, the picture is much clearer now. With the scenario you described everything should go as expected. Only a couple of remarks:

    - after your step 4) you need two additional steps:
    4.a) Start the database in NOMOUNT mode
    4.b) Run the "CREATE CONTROLFILE ..." script you have just edited in step 4) This will create a new controlfile(s), so there realy is no need to restore controlfiles from the cold backup in step 1 (but it doesn't hurt if you do, they will simply be overwritten if they are in the same locations as the new ones).

    In step 7) you will have to specify that you are recovering with a controlfile that is not in sysnc with the database: RECOVER DATABASE USING BACKUP CONTROLFILE.....

    You are correct, in step 8) you'll have to open the database with the RESETLOGS option. This will create brand new redolog files, so again there is no need to restore them in step 1) either, es they will be overwritten in any case.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  9. #39
    Join Date
    Feb 2001
    Posts
    99

    Thumbs up

    Thanks. Forgot to put those steps in.

    Will let ya know. I am also going to do another direct export and try importing it without dropping system user. If it works, I will then do an import where I drop the system user.

    Stay tuned to this channel. HOpe others besides me are getting some useful info out of all of this. If nothing else, at least what NOT to do.

    chants "import/export is not a backup scheme"
    chants "import/export is not a backup scheme"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width