Re: DBA FAQ 1 - integrating Backup Strategies

From: David Schmitt <cds016_at_isadmin1.comm.mot.com>
Date: Thu, 2 Sep 1993 15:45:09 GMT
Message-ID: <1993Sep2.154509.7195_at_lmpsbbs.comm.mot.com>


In article <X5779B2w164w_at_cellar.org>, Scott Tiger <kml_at_cellar.org> wrote:
>DBA FAQ
>(Frequently Asked Questions for/from Database Administrators)
>by Kevin M. Loney, aka kml_at_cellar.org (username "Scott Tiger")
>
>3. The Hot Backup.
>===================
>
>Backup strategy for Archivelogs:
>--------------------------------
>
>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).

>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.

>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).

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

-Dave.

-- 
David Schmitt, Manager, Technical Services	Voice:	(708)538-4699
Motorola, Inc. - Land Mobile Products Sector	FAX:	(708)538-4638
1301 E. Algonquin Rd. (IL02 SH1C)		E-Mail:	cds016_at_email.mot.com
Schaumburg, IL 60196
Received on Thu Sep 02 1993 - 17:45:09 CEST

Original text of this message