Re: Crazy mistake in "Oracle Unleashed"

From: Thomas Kyte <tkyte_at_us.oracle.com>
Date: Wed, 30 Sep 1998 20:26:14 GMT
Message-ID: <361a9146.30806697@192.86.155.100>

A copy of this was sent to satar_at_my-dejanews.com (if that email address didn't require changing) On Wed, 30 Sep 1998 18:50:58 GMT, you wrote:

>John,
>read my post...Modified blocks are written to the REDO LOGS. After the END
>BACKUP is issued and at the next log switch, the changed blocks are then
>updated in the datafiles. It is such an easy concept to grasp, yet so many
>DBA's are confused about this procedure. Maybe I'm wrong, but I would hate to
>believe that I paid $1400 dollars to Oracle Education to mislead me on Backup
>and Recovery.

I don't think they mislead you -- you might have made an assumption that since the blocks are written to the redo log file they weren't written to the datafile -- nowhere in what you quote below does it say "we don't write to the datafiles" it only says "we write more stuff to the redo logs"

Modified blocks are written to the REDO LOGS in backup mode this is true (i'll tell you why in a moment). This differs from 'normal' mode where only changed bytes are recorded.

This (writing full blocks to the redo logs) does *not* preclude data blocks from being written to the datafiles as well -- and they are.

Lets say for grins you have 2- 1 megabyte ONLINE REDO LOGS. You are in archive log mode. You do a log switch every 5 minutes. It takes 15 minutes to backup (physically read and write the datafile) for a tablespace. That means that while you are backing up, the redo logs switched 3 times and one of the ONLINE REDO log files you would need (if we *didn't* write to the datafiles during a backup) would be archived -- it might NOT EVEN BE ON DISK anymore. It would be impossible for us in this situation to apply the redo to the datafiles to 'catch them up' -- the needed online redo log is no longer online!

We *do not* apply a tiny 'recovery' after a backup is done -- we just update datafile headers -- the datafile itself has been written to all along.

Why do we write full blocks to redo during a backup then? Its 100% due to the fact that we *do* write to the datafile. The answer is because of the way an OS will multiplex reads/writes with many processes. When we are backing up the file we are asking the OS to read the file for us. Lets say we use an 8K blocksize. We are reading the datafile for the backup. The OS is reading in its native blocksize (say 2k). It starts reading block 500 in file 2. It reads the first 4k and all of a sudden a write request from DBWR for block 500 in file 2 comes in and we are pre-empted for whatever reason. It (the OS) rewrites the block on disk. Our read completes after this -- we get the last 4k BUT its the last 4k of a block we did not read the first 4k of. We get in our backups the potential for blocks that are half from one checkpoint and half from another (this can and does happen). When recovering the recovery process will look at the head and tail of the restored block and make sure they are the same block timestamp (that we got the read all 8k without someone overwriting it). If the head and tail do not match -- we have the entire block from some point in the archived redo -- we can fix it.

>Satar Naghshineh
>In article <36115B13.89938F9D_at_deere.com>,
> "John P. Higgins" <jh33378_at_deere.com> wrote:
>> <HTML>
>> It is true: Oracle stops updating file headers durring backup mode.
>>
>> It is also true: Oracle writes changed blocks to the files durring backup
>> mode.
>>
>> satar_at_my-dejanews.com wrote:
>> <BLOCKQUOTE TYPE=CITE>OK, I think everyone is confused. According to
>"Oracle7:Backup
>> and Recovery
>> Volume Two * Student Guide" which I obtained durring my DBA Master's
>> program
>> held by Oracle Corporation, on page 10-13 through page 10-17 it tells
>> you the
>> following: After you administer BEGIN BACKUP...This action suspends
>> updates
>> to the header block of each database file belonging to the Tablespace.
>> If a
>> log switch occures, the sequence number information is updated as shown.
>> A
>> record is also written to the active redo log file to indicate that
>> an online
>> backup has begun. END BACKUP...This action will cause the header blocks
>> for
>> the datafiles belonging to the tablespace to be updated at the next
>> log
>> switch. If a log switch occures, the sequence number information is
>> updated
>> as shown. * The time between the ALTER BEGIN and ALTER END commands
>> should be
>> minimized, as more redo information is generated and written to the
>> redo log
>> files durring the backup since modified blocks are written to the redo
>> log
>> files. * Prior to Oracle7 release 7.2, any instance faliur while an
>> online
>> backup was in progress could cause the subsequent automatic recovery
>> at
>> startup to fail due to the header on the backed up file being frozen.
>> Oracle7
>> at startup would then detect that the header was out of sync with the
>> rest of
>> the files, and startup would fail with the message the file needed
>> recovery.
>> New to release 7.2, you can allow an online backup to be ended before
>> opening
>> the database after a system failure, by executing the ALTER DATABASE
>> DATAFILE
>> END BACKUP command.
>Oracle DBA/UNIX System Admin
>Advanced Enterprise Solutions
>(949) 756-0588
>Oracle Re-Seller
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government
Herndon VA

--
http://govt.us.oracle.com/ -- downloadable utilities

Opinions are mine and do not necessarily reflect those of Oracle Corporation

Anti-Anti Spam Msg: if you want an answer emailed to you, you have to make it easy to get email to you. Any bounced email will be treated the same way i treat SPAM-- I delete it. Received on Wed Sep 30 1998 - 15:26:14 CDT