Completerecovery
Upcoming SlideShare
Loading in...5
×
 

Completerecovery

on

  • 244 views

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export ...

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

Statistics

Views

Total Views
244
Views on SlideShare
244
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Completerecovery Completerecovery Document Transcript

  • What’s a Complete Recovery? Backup and Recovery TipsWhat’s a Complete Recovery?A complete recovery is any recovery where you recover as much data as you aretheoretically able to. Put another way, it’s any recovery where you do not choose toterminate the recovery process before it would otherwise naturally finish.I stress the subtlety of that description, because recoveries performed without the use ofany archives whatsoever (i.e., you don’t run in archivelog mode) are traditionallyconsidered to be complete recoveries –despite the fact that, in the absence of any archives,the best you can do is restore the entire database from the time of the last cold backup –and that obviously means you’ve lost all transactions submitted to the database after thetime of that backup. The point is that ‘complete’ simply means ‘do as much as you can’ –even if that means, as it will in noarchivelog mode, that you end up losing data.If you do run in archivelog mode, however, a complete recovery means applying all theredo from the time of the start of the backup, until the time of the original failure. Therestored Data File is therefore brought completely up to date, and no committedtransactions whatsoever are lost.For that sort of functionality, there’s only one catch: every single bit of redo generated bythe entire database since the time of the start of the backup has to be available to therecovery session. No skipping of bits of redo you deem irrelevant is permitted. Thatmeans there can be no gaps in your archive sequence, and all the Online Redo Logs have tobe in fully working order, too. After all, one of those online logs is the ‘current’ log –andit contains valid redo just as much as the archives do.For the purposes of the rest of this paper, I’m going to assume that you have a databasecontaining just 5 Data Files, each of which gets backed up “hot”, 1 per hour, starting at1am. The database is also assumed to be running in archivelog mode, and there are nogaps in the archive sequence (otherwise we’d be into incomplete recovery territory!).Our Monday night backup therefore looks like this:File 1 : SYSTEM : backup started at 1amFile 2 : TEMP : backup started at 2.00amFile 3 : INDX : backup started at 3.00amFile 4 : RBS : backup started at 4.00amFile 5 : USERS : backup started at 5.00am…and this sort of pattern repeats every night, until on Thursday morning, some disastershit the database.Various disasters can be imagined (and most certainly will be!).Copyright © Howard Rogers 2001 24/10/2001 Page 1 of 8
  • What’s a Complete Recovery? Backup and Recovery TipsThe System Tablespace is stuffedOn Thursday morning, the database crashes for no apparent reason. The first thing you’ddo, of course, is check the Alert Log for any possible error messages –whereupon youdiscover that one of the last alerts recorded was a message along the lines of ‘Corruptblock detected in File 1’.File 1 is our SYSTEM tablespace, so the first thing we know immediately is that there is nopossibility of getting at least part of the database up and running whilst we do therecovery… a database simply can’t run without a SYSTEM tablespace and the datadictionary it contains. Therefore, we know that this recovery will have to take place withthe database in the MOUNT stage.The steps to recovery are then simple. First, we restore an uncorrupted version of File 1from one of our backups. Hopefully, the one we took at 1am on Thursday morning willsuffice. We should have been running dbverify against all our backups, so we wouldalready know if that backup had included any corruption (see my tip on ‘How can I checkthat my backups are “clean”?’) –but if we’d neglected to do that at the time of the backup,we could run it now before proceeding further.Once we know that our backup is clean, we restore it. Hopefully, we restore it to exactlythe same location as the original SYSTEM Data File occupied (but if not, we can deal withthat too –see my tip on ‘How do you restore a file to a new location?’). The restore isperformed using basic operating system commands –or whatever procedures your tapebackup software permits. However you do it, all that’s really happening is that an oldversion of the SYSTEM Data File is being copied back onto disk.Once the restore is finished, you can try and open the database. If you issue the normalSTARTUP command from within Server Manager or SQL Plus, the thing will fall over in theMOUNT state, with the error messageDATABASE MOUNTED.ORA-01113: FILE 1 NEEDS MEDIA RECOVERYORA-01110: DATA FILE 1: D:ORACLEORADATAHJR9SYSTEM01.DBFAlternatively, you could control the startup process so that the database gracefully parksitself into the MOUNT state with no error messages –you’d simply issue the commandSTARTUP MOUNT to do that.Now we can begin the actual recovery phase –the application of redo to the restored file tobring it up to date. We issue the following command: RECOVER DATAFILE 1.Oracle then determines the SCN of the restored file, works out which Archived Redo Logcontains that SCN, and prompts for the application of that log, like this:Copyright © Howard Rogers 2001 24/10/2001 Page 2 of 8
  • What’s a Complete Recovery? Backup and Recovery TipsSQL> RECOVER DATAFILE 1ORA-00279: CHANGE 76832 GENERATED AT 10/24/2001 09:00:40 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_141.RDOORA-00280: CHANGE 76832 FOR THREAD 1 IS IN SEQUENCE #141SPECIFY LOG: {<RET>=SUGGESTED | FILENAME | AUTO | CANCEL}There are four options available to you at this point, as listed on that last line of theprompt, “Specify Log”.You can hit the [Enter] key to accept the suggestion as to what archive to apply. You’d dothat if all your archives were still sitting on disk in the place where ARCH originally putthem. If you’ve moved your archives to another part of the disk, though, this option is notappropriate.Instead, you could type in the actual path and filename of where your logs are nowcurrently located. For example, and entry of E:STAGE1ARCH_141.RDO would suffice ifyou’ve moved your archives there.If all your logs are in the correct location, then pressing [Enter] will work –but what ifthere are dozens of archives to apply? Do you really want to be sitting there pressing[Enter] every few minutes for who knows how long? Instead, you can type in the word AUTO,and by doing so you are asserting that all Oracle’s suggestions about what logs to apply,and where to find them, are appropriate and correct.Finally, you can decide that all this recovery work is far too hard, and that you need a cupof coffee before proceeding. If you type in the one word CANCEL at this point, the recoveryprocess stops at the point it’s got to (in this case, before it’s even started!), ready toresume from the same point the next time you type in the RECOVER DATAFILE 1 command.Let’s assume that all our archives are available for use in all the right locations –so we canuse the AUTO option. Type that one word at the prompt, and press [Enter], and you’ll geta display like this:AUTOORA-00279: CHANGE 76892 GENERATED AT 10/24/2001 09:03:51 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_142.RDOORA-00280: CHANGE 76892 FOR THREAD 1 IS IN SEQUENCE #142ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_141.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 96950 GENERATED AT 10/24/2001 09:10:53 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_143.RDOORA-00280: CHANGE 96950 FOR THREAD 1 IS IN SEQUENCE #143Copyright © Howard Rogers 2001 24/10/2001 Page 3 of 8
  • What’s a Complete Recovery? Backup and Recovery TipsORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_142.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 97015 GENERATED AT 10/24/2001 09:10:55 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_144.RDOORA-00280: CHANGE 97015 FOR THREAD 1 IS IN SEQUENCE #144ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_143.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 97069 GENERATED AT 10/24/2001 09:11:18 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_145.RDOORA-00280: CHANGE 97069 FOR THREAD 1 IS IN SEQUENCE #145ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_144.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 97071 GENERATED AT 10/24/2001 09:11:24 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_146.RDOORA-00280: CHANGE 97071 FOR THREAD 1 IS IN SEQUENCE #146ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_145.RDO NOLONGER NEEDED FOR THIS RECOVERYLOG APPLIED.MEDIA RECOVERY COMPLETE.You’ll see in this example how logs 142 to 146 are sequentially applied, thus effectivelyrolling our restored SYSTEM Data File forward in time. At the end of the process, Oracledeclares that ‘media recovery is complete’, meaning that the SYSTEM Data File has beenrolled as far forward in time as it is possible to go –in other words, it is now insynchronisation with the rest of the database.Remember that all of this has taken place with the database in the MOUNT stage –so theonly thing left to do is to get the recovered database fully open. You do that with theusual ALTER DATABASE OPEN command, and you’ll then discover that your database has beenfully fixed.A non-SYSTEM tablespace is stuffedLater on Thursday, the database crashes again, and the Alert Log reports nothingparticularly mysterious. So you attempt to open the database by issuing the usual STARTUPcommand –at which point, the startup process bombs out with the following error message:DATABASE MOUNTED.ORA-01157: CANNOT IDENTIFY/LOCK DATA FILE 5 - SEE DBWR TRACE FILEORA-01110: DATA FILE 5: D:ORACLEORADATAHJR9USERS01.DBFCopyright © Howard Rogers 2001 24/10/2001 Page 4 of 8
  • What’s a Complete Recovery? Backup and Recovery TipsNow we notice from this that it is NOT the SYSTEM tablespace that is stuffed. Neither is itthe rollback segment tablespace, RBS, which is also required for a database to operatenormally. Therefore, we have the possibility of getting what’s left of the database open,around the problem, and fixing up this particular tablespace whilst Users go about theirbusiness elsewhere in the database.This is a good technique, because it minimises the impact of a failure in one part of thedatabase. Of course, if Users want anything out of the bit you are actually fixing, they’regoing to be disappointed. But all other tablespaces are open for business as usual, whichshould keep most Users happy most of the time.So the recovery approach in this situation is basically to persuade Oracle that what itthinks is a problem with tablespace USERS is not really a problem at all –and you do that byofflining it, leaving what’s left available to be opened:SQL> ALTER DATABASE DATAFILE 5 OFFLINE;DATABASE ALTERED.SQL> ALTER DATABASE OPEN;DATABASE ALTERED.Note that you have to offline the Data File, not the tablespace. That’s because you’re inthe MOUNT state, and you can only talk tablespace SQL language when the database isfully open. In practice, it amounts to much the same thing, though: those bits of thedatabase which could be fully functional are now indeed open and usable.Now we can recover the troublesome tablespace. The procedures are much as before:restore the Data File concerned, and apply redo to it:C:> COPY E:BACKUPSUSERS01.DBF D:ORACLEORADATAHJR9USERS01.DBFSQL> RECOVER DATAFILE 5;ORA-00279: CHANGE 76832 GENERATED AT 10/24/2001 09:00:40 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_141.RDOORA-00280: CHANGE 76832 FOR THREAD 1 IS IN SEQUENCE #141SPECIFY LOG: {<RET>=SUGGESTED | FILENAME | AUTO | CANCEL}…at which point, we are back in the business of either agreeing with the suggestionsOracle makes for where to find the required archives, supplying our own replacements, orselecting to apply all suggestions automatically:AUTOORA-00279: CHANGE 76892 GENERATED AT 10/24/2001 09:03:51 NEEDED FOR THREAD 1Copyright © Howard Rogers 2001 24/10/2001 Page 5 of 8
  • What’s a Complete Recovery? Backup and Recovery TipsORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_142.RDOORA-00280: CHANGE 76892 FOR THREAD 1 IS IN SEQUENCE #142ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_141.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 96950 GENERATED AT 10/24/2001 09:10:53 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_143.RDOORA-00280: CHANGE 96950 FOR THREAD 1 IS IN SEQUENCE #143ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_142.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 97015 GENERATED AT 10/24/2001 09:10:55 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_144.RDOORA-00280: CHANGE 97015 FOR THREAD 1 IS IN SEQUENCE #144ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_143.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 97069 GENERATED AT 10/24/2001 09:11:18 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_145.RDOORA-00280: CHANGE 97069 FOR THREAD 1 IS IN SEQUENCE #145ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_144.RDO NOLONGER NEEDED FOR THIS RECOVERYORA-00279: CHANGE 97071 GENERATED AT 10/24/2001 09:11:24 NEEDED FOR THREAD 1ORA-00289: SUGGESTION : D:ORACLEORADATAHJR9ARCHIVEARCH_146.RDOORA-00280: CHANGE 97071 FOR THREAD 1 IS IN SEQUENCE #146ORA-00278: LOG FILE D:ORACLEORADATAHJR9ARCHIVEARCH_145.RDO NOLONGER NEEDED FOR THIS RECOVERYLOG APPLIED.MEDIA RECOVERY COMPLETE.…I went for the “auto” option, and once again we get the ‘media recovery is complete’confirmation at the end.All that we need do now is bring the tablespace involved back online:SQL> ALTER TABLESPACE USERS ONLINE;TABLESPACE ALTERED.…at which point, the thing is fully available for normal use once again.Copyright © Howard Rogers 2001 24/10/2001 Page 6 of 8
  • What’s a Complete Recovery? Backup and Recovery TipsVariations on a ThemeYou’ll notice that in the last scenario, the loss of the non-SYSTEM tablespace caused thedatabase to crash… so we had to get to the MOUNT state before starting the recoveryprocess –though the actual recovery phase took place after the rest of the database hadbeen opened.It could be, however, that the loss of the tablespace occurred without crashing the entiredatabase.You’re then in the position of a database which is already fully open, but with part of itunavailable because of Data File loss or corruption. In such a scenario, the basic recoveryprinciples remain the same as before, but with a slight language variation –because you arealready in the fully open state, you can talk “tablespace” commands instead of “datafile”ones.So when a User suddenly reports that they are getting an error message like this one:SQL> SELECT * FROM EMP;SELECT * FROM EMP *ERROR AT LINE 1:ORA-00376: FILE 5 CANNOT BE READ AT THIS TIMEORA-01110: DATA FILE 5: D:ORACLEORADATAHJR9USERS01.DBF…then you can proceed to do an “open database recovery”.Now all recoveries require you to start by restoring copies of Data Files from backups. Butyou can’t copy a Data File from a backup on top of one that Oracle is still maintaining itsgrip on. So you have to release that grip first: and you do that by taking the tablespaceoffline:ALTER TABLESPACE USERS OFFLINE IMMEDIATE;Note the “immediate” keyword there. If you missed it out, you’d get an error message,because a ‘normal’ offline causes a checkpoint to be issued against the tablespace –andthe whole problem here is that there is clearly something wrong with the Data Files suchthat a checkpoint would fail. “Immediate” means, basically, checkpoint what you can,and don’t bother with what you can’t.Note also the use of the ‘alter tablespace’ language. Here is the difference between thisscenario and the last one: last time, we were stuck in the mount state, and had to do anALTER DATABASE DATAFILE command to offline the offending Data Files. This time, we’realready fully open, and can thus use tablespace language.Copyright © Howard Rogers 2001 24/10/2001 Page 7 of 8
  • What’s a Complete Recovery? Backup and Recovery TipsIncidentally, this step might not actually be required at all, because quite often Oracle issmart enough to notice the problem with the tablespace and take it offline automatically.Use SELECT FILE#, STATUS FROM V$DATAFILE_HEADER; to find out whether you need tomanually take the files offline (the report will show a status of ‘online’) or whetherOracle’s done the deed for you already (the report will show a status of ‘offline’).Now the Data Files are offline, whether manually or automatically, you can restore copiesof them from a backup. As before, that means use whatever Operating System commandsor tape backup software procedures are appropriate.Now comes the recovery phase, which proceeds pretty much exactly the same as before:RECOVER TABLESPACE USERS;…which brings up the usual prompts for the application of appropriate archives, followedby the ‘media recovery complete’ message.Once you see that message, the final thing to do is to bring the affected tablespace backonline:SQL> ALTER TABLESPACE USERS ONLINE;TABLESPACE ALTERED…and a ‘select * from emp’ now produces a functional report.SummaryWhat I’ve described here are the two basic recovery scenarios, plus one twist.You either perform recovery in the MOUNT state, or in the OPEN state. The twist comeswith doing OPEN recoveries.Either the database is already open (in which case you just ‘offline immediate’ thetablespace causing the problem and then perform recovery), or you have to get it open (inwhich case you first offline the Data File(s) causing the problem, followed by an ALTERDATABASE OPEN, and then perform recovery).In all cases, you restore troublesome file(s) from a backup, and then issue an appropriaterecovery command to apply redo to the restored file to bring it up to date. If it’s just oneor two files that are stuffed, the RECOVER DATAFILE command is appropriate. If you’re inthe OPEN state, you can use the RECOVER TABLESPACE command –although RECOVER DATAFILEis still available for use.In all cases, the files are brought completely up to date, and no committed data is lost.Copyright © Howard Rogers 2001 24/10/2001 Page 8 of 8