Re: Are Hot Backups Incremental?

In article <F1L3u7.2CH.0.debian_at_sirena.rinet.ru>, Konstantin Kivi <konst_at_sirena.rinet.ru> wrote:
>Winnie Liu <oracle_dba_at_zdnetmail.com> wrote:
>
>> I think you need need to read some books about backup and recovery. The
>> method to recovery it to point of failure is like this:
>
>> SUN MON TUE WED THU FRI SAT
>> COLD HOT HOT HOT HOT HOT HOT
>
>Can't you do hot backup for files in TABLESPACE_A on Monday,
>TS_B on Tuesday , TS_C on Wednesday ...
>then when it crashes on Saturday put it all together
>and feed it with archive logs that you have since Monday morning.

This is true. I think it's more a matter of the pain and suffering involved with rolling forward your archived redo logs. If the pain and suffering of doing the rollforward is less than copying all the data files off during a nightly hot backup, go for it.

One can use archived redo logs to silly extents. One of my Oracle instructors told this war story in which a client had apparently made a hot backup of all data files, and proceeded to archive the redo logs. All fine and dandy. They, however, never bothered making another hot backup of the data files. A year later, the machine, of course or there wouldn't be a story, goes down. A poor technician had to sit there for basically a week, feeding in the tapes to roll forward a year's worth of redo. Recovery, IIRC, was successful with this method, though, personally, I wouldn't want to try it.

>If this is not incremental backup then see my first question.

I recall the people at Veritas were working on true incremental file system backups. Basically, only the altered OS data blocks would be copied off to the backup device. I don't know how far they've gotten with this, but it's been about a year since I first heard of the work.

>You can also backup intensively changing data more often the other
>part of the database.

I think it depends on what you mean by incremental. One may consider the archived redo logs to be the "incremental" portion. And certainly, individual tablespaces may be backed up, instead of all the tablespaces. But, in the event of a media failure, _all_ archived redo logs since the point of failure will have to be used for recovery. So, in the case where you've been backing up the intensively changing tablespaces more frequently than the other ones, and if one of the relativley static ones dies, you will have to use all your redo logs from that point forward. There may be some gain, or it may be more costly, pain and suffering-wise. It depends on your situation. Received on Thu Oct 29 1998 - 11:38:27 CST