Re: DBA FAQ 1 - integrating Backup Strategies

In article <1993Sep2.154509.7195_at_lmpsbbs.comm.mot.com> cds016_at_isadmin1.comm.mot.com (David Schmitt) writes:
>In article <X5779B2w164w_at_cellar.org>, Scott Tiger <kml_at_cellar.org> wrote:
>>DBA FAQ
>>2. Before you backup the control file, force an archive log switch.
>>This will update the header information in the control file.
>
>Could someone explain this further? I specifically chose to backup the
>control file _before_ forcing the log switch to insure that I have
>_every_ log possibly referenced by the control file. By forcing the
>log switch before, it is possible that one more log switch could occur
>before you get around to grabbing the control file (heavily loaded DB).

Why does it make any difference? If you are using the control file from a backup then you are going to have to enter the logfiles you want applied anyway. It doesn`t make any difference what log the control file thinks you where on because he wont stop until to tell him to.

Is that true? I'm pretty sure about it. I always thought the only point of forcing the switch was to put any data that may have been sitting around out to the archive location.

>>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.
>
>Wow. Is this in any of Oracle's normal documentation? Sounds like this
>would apply to us on a UNIX platform.
>
>One of the reasons we liked the idea of hot backups is that we can continue
>batch processing at night. This makes that a little less attractive.

I read it somewhere but I dont remember that if it was part of the docs. I cant find it in my IUG, and cant imagine that they would put it anywhere else cause it is a implementation issue.

I dont view it as a big deal however, I guess that if you where limited on disk space it could cause a problem but the archive logs are just as valid as before they just take up more room and take longer to apply.

>>Integrating the three methods.
>>==============================
>>Shutdown once a week. If possible, run a full export immediately prior
>>to the shutdown. If this is not possible because of time constraints,
>>perform the export on the previous night. While down, perform a cold
>>backup of all Oracle-related files, then restart. On all other nights,
>>perform a hot backup while the database is up using the methodology
>>described above.
>
>Wouldn't you shutdown immediately before the export and come up in DBA
>only mode? Otherwise you aren't guaranteed logical consistency _between_
>the tables (even though tables are self-consistent).

I think he is saying do the export before your cold backup not do your export without shuting down.

>Why perform the cold backup on top of the export? Just because you don't
>trust your hot backups?

How are you going to get joe blow's single table back without a export? If you don't have an export you have to bring a small version of the old db up on a different disk/system. A real pain.

-- 
Regards, 

Lee E. Parsons                  		Baker Hughes Inteq, Inc
Oracle Database Administrator 			lparsons_at_exlog.com