PART III in Software

Encode Code 39 Full ASCII in Software PART III

So to protect against media failure, you must have multiplexed copies of the controlfile, the online redo log files, and the archive redo log files You will also take backups of the controlfile, the data files, and the archive log files You do not back up the redo logs they are, in effect, backed up when they are copied to the archive logs Datafiles cannot be protected by multiplexing; they need to be protected by hardware redundancy either conventional RAID systems, or Oracle s own Automatic Storage Management (ASM)

An instance failure is a disorderly shutdown of the instance, popularly referred to as a crash This could be caused by a power cut, by switching off or rebooting the server machine, or by any number of critical hardware problems In some circumstances one of the Oracle background processes may fail this will also trigger an immediate instance failure Functionally, the effect of an instance failure, for whatever reason, is the same as issuing the SHUTDOWN ABORT command You may hear people talking about crashing the database when they mean issuing a SHUTDOWN ABORT command After an instance failure, the database may well be missing committed transactions and storing uncommitted transactions This is a definition of a corrupted or inconsistent database This situation arises because the server processes work in memory: they update blocks of data and undo segments in the database buffer cache, not on disk DBWn then, eventually, writes the changed blocks down to the datafiles The algorithm the DBWn uses to select which dirty buffers to write is oriented toward performance and results in the blocks that are least active getting written first after all, there would be little point in writing a block that is being changed every second But this means that at any given moment there may well be committed transactions that are not yet in the datafiles and uncommitted transactions that have been written: there is no correlation between a COMMIT and a write to the datafiles But of course, all the changes that have been applied to both data and undo blocks are already in the redo logs Remember the description of commit processing detailed in 8: when you say COMMIT, all that happens is that LGWR flushes the log buffer to the current online redo log files DBWn does absolutely nothing on COMMIT For performance reasons, DBWn writes as little as possible as rarely as possible this means that the database is always out of date But LGWR writes with a very aggressive algorithm indeed It writes as nearly as possible in real time, and when you (or anyone else) say COMMIT, it really does write in real time This is the key to instance recovery Oracle accepts the fact that the database will be corrupted after an instance failure, but there will always be enough information in the redo log stream on disk to correct the damage

The rules to which a relational database must conform, as formalized in the ACID test, require that it may never lose a committed transaction and never show an uncommitted transaction Oracle conforms to the rules perfectly If the database is corrupted meaning

that it does contain uncommitted data or is missing committed data Oracle will detect the inconsistency and perform instance recovery to remove the corruptions It will reinstate any committed transactions that had not been saved to the datafiles at the time of the crash, and roll back any uncommitted transactions that had been written to the datafiles This instance recovery is completely automatic you can t stop it, even if you wanted to If the instance recovery fails, which will only happen if there is media failure as well as instance failure, you cannot open the database until you have used media recovery techniques to restore and recover the damaged files The final step of media recovery is automatic instance recovery