The backup methodology for Sybase is fairly straightforward:
You can do a full database backup, or an incremental (log) backup since the last full database backup. Every Sybase backup is a consistent recoverable backup. The 'recovery' stage of the backup is hidden from the administrator and there's just never a reasont to worry about it.
Oracle, on the other hand, is a bit different. The administrator (for historical reasons?) has far more visibility into the underlying mechanisms of making a backup consistent or not. What this usually means is that the backup process is far more complicated and error-prone.
For the purposes of this 'paper,' I'm going to only skim the old backup methodologies and concentrate on RMAN (recovery manager) backups.
Legacy Oracle Backup Methods
You could do a 'cold' database backup, which involves shutting down the instance, copying all datafiles and redo logs (redo logs not really necessary) to the backup location, then bringing the database back up. Obviously, this is suboptimal. Sybase doesn't even have a corresponding concept.
You could do a 'hot' database backup, which involves putting individual OracleTablespaces? into 'backup' mode, copying the datafiles that make up that tablespace to the backup location, putting the tablespace back into 'normal' mode, then repeating for all tablespaces until the database is fully backed up. This method gives you an 'inconsistent' backup that further requires archive logs for recovery when restoring the backup. Complicated and nasty, but scriptable, and that's the important part.
Recovery Manager
Now Oracle has joined Sybase with a modern backup solution. Now, with RMAN, you can do a full database backup and incremental backups. Well, I guess I'm oversimplifying a little bit. It looks like OracleRMANIsntQuiteReady for the prime time, as of April 2001.
First, however, you need to lay the RMAN groundwork:
- Setup the RMANRecoveryCatalog? (another Oracle database)
- Register the database to backup into the catalog
- Backup the database
You setup the RMANRecoveryCatalog? on some machine that can run a small Oracle database. This special recovery catalog database should be backed up using a legacy method, probably cold backup would be most convenient. If this catalog is lost, then you are very vulnerable since you can't recover any of your production databases if they get lost.
To register your database with the RMANRecoveryCatalog?, you issue a "reset database" command at the RMAN> prompt.
Next, you must do a level 0 (full) database backup. Here is an example RMAN script to do a level 0 database backup:
run {
allocate channel d1 type disk;
backup
incremental level=0
tag dbIdTagLevel0
format '/backupLoc/dbId_datafile_[[d_]]u'
database;
sql 'alter system archive log current';
backup
format '/backupLoc/archlogs/dbId_archlog_[[d_]]u'
archivelog all delete input;
# prevent RMAN-06089 errors
change archivelog all crosscheck;
release channel d1;
}
The above script can be treated as a black box that does the level 0 backup, putting files into a certain directory location with a certain naming convention so that when you see the file, it makes sense.
The above script should be cronned to run via RMAN every time you want a full database backup. For me, that's nightly.
Here's a script to do a level 1 (incremental) backup. This will back up every data block that's changed since the last level 1 or level 0 backup.
run {
allocate channel d1 type disk;
backup
incremental level=1
tag dbIdTagLevel0
format '/backupLoc/dbId_datafile_[[d_]]u'
database;
sql 'alter system archive log current';
backup
format '/backupLoc/archlogs/dbId_archlog_[[d_]]u'
archivelog all delete input;
# prevent RMAN-06089 errors
change archivelog all crosscheck;
release channel d1;
}
Now, the concept is, you can cron the full level 0 backup daily, then the incremental level 1 backup (say) four times a day. If your database crashes, RMAN will discover what files are needed for the recovery. At this date (April, 2001) I've not done an RMAN recovery, so I'm not sure if it works as advertised, but I've been assured it's "way cool," so decide for yourself.
The change archivelog all crosscheck command was inserted after I found out that sometimes RMAN errors occur if you don't put it in there. Obviously, this is one of those things that makes me long for the days of simple Sybase backups, but I digress.
Update: RMAN was a bit unstable. It may be better now, but I wouldn't try using it for a production system for another year or two.