Re: point in time recovery and moving datafiles online

From: "Alex Adriaanse" <alex_a(at)caltech(dot)edu>
To: <marc(at)bloodnok(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: point in time recovery and moving datafiles online
Date: 2002-02-22 11:55:14
Message-ID: JIEIIHMANOCFHDAAHBHOIEMDCNAA.alex_a@caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marc Munro <marc(at)bloodnok(dot)com> writes:
> Add hooks for begin_backup and end_backup at a data file level. Between
> the calls begin_backup(myfile) and end_backup(myfile), writes to myfile
> will be disabled allowing the file to be safely copied.

I pasted some Oracle documentation below that talks about how it's
implemented in Oracle (Oracle leaves the backing up of the data and redo log
files up to the administrator, so that tar, cp, or anything else can be used
so that you're not restricted to backup files in tar format. All they do is
implement ALTER TABLESPACE ... BEGIN/END BACKUP statements, and a way to
create archives of redo log files and the rest is up to the administrator).
I hope I'm not just pasting the obvious here.

I got this off
http://download-west.oracle.com/otndoc/oracle9i/901_doc/server.901/a90134/os
backup.htm#9419 - they've got lots of neat stuff in this guide in some of
the other chapters as well.

===============
You must put a read/write tablespace in backup mode to make user-managed
datafile backups when the tablespace is online and the database is open. The
ALTER TABLESPACE BEGIN BACKUP statement places a tablespace in backup mode.

Oracle stops recording checkpoints to the datafiles in the tablespace when a
tablespace is in backup mode. Because a block can be partially updated at
the very moment that the operating system backup utility is copying it,
Oracle copies whole changed data blocks into the redo stream while in backup
mode. After you take the tablespace out of backup mode with the ALTER
TABLESPACE ... END BACKUP or ALTER DATABASE END BACKUP statement, Oracle
advances the datafile header to the current database checkpoint.

When you restore a datafile backed up in this way, the datafile header has a
record of the most recent datafile checkpoint that occurred before the
online tablespace backup, not any that occurred during it. As a result,
Oracle asks for the appropriate set of redo log files to apply should
recovery be needed. The redo logs contain all changes required to recover
the datafiles and make them consistent.

...

Caution: If you forget to take the tablespace out of backup mode, then
Oracle continues to write entire copies of data blocks in this tablespace to
the online redo logs, possibly causing performance problems. Also, you will
receive an ORA-01149 error if you attempt to shut down the database with the
tablespaces still in backup mode.
===============

So I guess to sum it up, when you put the database in hot-backup mode, the
database is still completely functional, and all changes are still written
to disk (to the redo log file until the backup of the data files are done,
which is when the changes from the redo log are flushed to the data files).
Once that's done, you archive the redo log, back up the archived logs, and
you're all set.

Best regards,

Alex

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-02-22 12:40:49 Re: Strange problem when upgrading to 7.2 with pg_upgrade.
Previous Message Jean-Michel POURE 2002-02-22 11:39:55 Re: [ODBC] UTF-8 data migration problem in Postgresql 7.2