DBAsupport.com Forums - Powered by vBulletin
Results 1 to 7 of 7

Thread: URGENT, please help!!!

  1. #1
    Join Date
    Sep 2000
    Posts
    103
    Hi,
    I'm trying to do a recovery on a win2000 machine.
    On giving recover database, I get the following error:
    *
    ORA-00279: change 866329 generated at 08/31/2001 09:36:52 needed for thread1
    ORA-00289: suggestion : D:\ORACLE\ORADATA\DB1\ARCHIVE_2\DB1_001_01937.ARC
    ORA-00280: CHANGE 866329 FOR THREAD 1 IS IN SEQUENCE #1937
    SVRMGR>

    What do I do next ?

    I gave recover from 'D:\ORACLE\ORADATA\DB1\ARCHIVE_2\DB1_001_01937.ARC' database, but it gives me the error
    ORA-00275: media recovery has already been started.

    Please help me in what I should do next ? I need to bring the server up.

    The first time, I did this, the machine just crashed and I got to see the win2k blue scrren. I dont want this to happen to the live server.

    thanks a lot
    pst

  2. #2
    Join Date
    Sep 2000
    Posts
    103
    Now if I give alter database open,
    *
    ORA-01113: file 5 needs media recovery
    ORA-01110: data file 5: 'D:\ORACLE\ORADATA\DB1\ARCHIVE_2\DB1_001_01937.ARC'

    I just copied the required datafile fro backup. Should I copy the system, control files as well.

    Please let me know how do I recover this.

  3. #3
    Join Date
    Mar 2001
    Location
    Ireland/Dublin
    Posts
    688
    First step:
    shutdown your database and make FULL cold backup.

  4. #4
    Join Date
    Sep 2000
    Posts
    103
    thanks, do i just use all the datafiles from my previous backup as I am trying to retrieve some deleted data.

    Will I have to copy all the backup datafiles before issuing the recover command?

  5. #5
    Join Date
    Jun 2001
    Posts
    316
    I found this article


    Backup strategy for Archivelogs:

    1. Do each tablespace one at a time. That is, rather than setting them all offline, then backing them up, then setting them back online, do them each separately. You don't want to risk having a system crash while the entire database is in begin backup state; recovery is a mess. Minimize your window of vulnerability by having only one tablespace in backup state at any one time.

    If you are using RAID devices or mirrored disks, in which the loss of a single disk does not cause the loss of a file, then you can simplify your backup procedures by taking all of the tablespaces offline at once, and backing them up as a set.

    2. Before you backup the control file, force an archive log switch. This will update the header information in the control file.

    3. Don't do it during user activity. When in backup state, a tablespace's activity is still written to the archive logs. However, it's written block-by-block rather than byte-by-byte. So changing one record in a tablespace that's being backed up will result in that record's entire block being written to the archive area. NOTE: This is correct only for those platforms where the physical sector size is less than the Oracle logical block size. On systems where the physical disk transfer size is equal to the Oracle block size, then we do not incur the penalty of having to log the entire block. This is true for MVS, VM, and perhaps other systems.

    Sample Archive log command file for VMS:

    NOTE: See Rama's book for a more complete script; the code is available at the Web site.

    $ dup = "backup/ignore=(noback,interl,label)/log"
    $ sqldba
    CONNECT INTERNAL
    alter tablespace system begin backup;
    exit
    $ dup u01:[oracle]ora_system.dbs tape1ra_system.bck/sav
    $ sqldba
    CONNECT INTERNAL
    alter tablespace system end backup;
    alter tablespace appl1 begin backup;
    exit
    $ dup u02:[oracle]appl1.dbs tape1:appl1.bck/sav
    $ sqldba
    CONNECT INTERNAL
    alter tablespace appl1 end backup;
    exit
    $!
    $! get archive logs
    $ rename/log u03:[oracle.arcs]*.arc *.arclogs
    $ rename/log u04:[oracle.arcs2]*.arc *.arclogs !secondary arcs dir
    $ sqldba
    CONNECT INTERNAL
    alter system switch logfile;
    exit
    $ dup u03:[oracle.arcs]*.arclogs,u04:[oracle.arcs2]*.arclogs
    tape1:logs.bck/sav
    $ del/log u03:[oracle.arcs]*.arclogs;0
    $ del/log u04:[oracle.arcs2]*.arclogs;0
    $!
    $! get control file
    $ sqldba
    CONNECT INTERNAL
    alter database backup controlfile to 'u01:[oracle]control.bkp' reuse;
    exit
    $ dup u01:[oracle]control.bkp tape1:control.bck/sav
    Note: The "alter system switch logfile" command is all but undocumented, (see pg 3-15 of the DBA guide. It refers you to a nonexistent cross-reference). It will NOT show up in the alert log. Don't be alarmed by that; it does actually work.

    NEW NOTE: Some people modify the script above to automatically pull the file names from DBA_DATA_FILES, so they don't have to hardcode the file names. I would only do that if the datafiles were all mirrored, so that a media failure wouldn't take down my database.

    Integrating the three methods.

    Use hot backups for all of your transaction-critical data. As a backup to the hot backups, perform cold backups periodically. As a backup to the physical file backups, use Exports.

    If you have a large amount of static data, you may wish to export only certain small tables, while relying on loading programs to re-create the static data when needed. As your database grows larger, the time required to perform Imports will remove Export as a viable backup option for all but the smallest of your tables.

    If at all possible in your O/S, it is also a good idea to shadow the disks on which your realtime and archived redo logs reside.



    author :Kevin Loney


    Hope this helps...

  6. #6
    Join Date
    Mar 2001
    Location
    Ireland/Dublin
    Posts
    688
    Yes, you have to replace datafiles from backup, only after you will be able to aply rachive log, as Oracle can't do roll back based on your archive logs, it able to make roll forward and aply data from archive logs to the data files.

    Originally posted by pst
    Will I have to copy all the backup datafiles before issuing the recover command?

  7. #7
    Join Date
    Sep 2000
    Posts
    103
    Thanks a lot fro your replies.

    I finally managed to get it in the end.

    I copied over all the datafiles and rollback segments

    and then issued the command
    RECOVER DATABASE UNTIL TIME '2001-08-31:17:45:00';

    and it worked.

    At first I tried with SCN, and for recover database until scn,
    i typed auto, and it applied all the logs upto the current time and so I wasnt able to retrieve my lost data.


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