Consequences of ARCHIVELOG

The guys responsible for the backup of our servers get our database (a large one) offline for over 6h for the whole backup scene.

I spoke to them asking if we could break that down to smaller and more frequent backup tasks, i.e. backing up each schema at time, or even sets of tables in different times.

Their answer was it was sort of possible if we decided to turn the ARCHIVELOG, which, would have performance consequences.

I'm quite unfamiliar with that just as much as with ways of doing backup.

Which other options would you guys recommend for backing up my schemas in a more efficient, or at least, not so down-time intensive way?

thanks!

f.开发者_如何转开发

if your database has its ARCHIVELOG disabled, you will lose data in case of a hardware failure (potentially all data entered since the last backup). If this is acceptable, then you can disable ARCHIVELOG.

On production instances it is common to have the requirement to NOT lose data (this would be the primary goal of a DBA). In that case the argument about performance is moot, you will turn ARCHIVELOG on because it is a requirement. Then you can have hot backups, they are not more complex than cold backups if you use RMAN, they also won't flush the database cache (improving performance). You can use RMAN to make incremental backups (instead of FULL cold backup) that will only log changes since the last backup.

Furthermore, with enough IO (add more disks), you can setup the database so that the writing of the archive logs doesn't impact performance noticeably.