Online Backup versus Offline Backup ?? What's the point ??

[manwiththeaxe.70]

I have recently begun to migrate our DB2 UDB v7.2 enterprise databases
up to DB2 UDB v8.2.

One question I can't seem to understand is why would I want to run an
offline backup for a database now that the online backup includes the
necessary log files.

Is there a reason why I would need or want to go through the hassle of
getting exclusive control of a db for an offline backup?
(ps - forgive me if this is a question that lets my inexperience show
through...........)
Regards,
Richard M.

[Pierre Saint-Jacques]

First, you need to be careful.
The include logs option as far as I know only includes the logs that were
active from the start of the backup to the end of the backup.
For example, if the first active log is log 15 when you launch the backup
and the when you took the previous backup and finished with log 10; then,
logs 11,12,13,14 will NOT be included in your current online backup with
include logs.

Some disaster recovery strategies are easier to implement when you are
coming from an offline backup.
Given where V8.2 is, I don't see any glaring requirements for offline
backups apart from the DBA'S peace of mind!!
HTH, Pierre.

--
Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515
<ma**************@gmail.com> a écrit dans le message de news:
11*********************@o13g2000cwo.googlegroups.c om...

I have recently begun to migrate our DB2 UDB v7.2 enterprise databases
up to DB2 UDB v8.2.

One question I can't seem to understand is why would I want to run an
offline backup for a database now that the online backup includes the
necessary log files.

Is there a reason why I would need or want to go through the hassle of
getting exclusive control of a db for an offline backup?
(ps - forgive me if this is a question that lets my inexperience show
through...........)
Regards,
Richard M.

[Knut Stolze]

Pierre Saint-Jacques wrote:

First, you need to be careful.
The include logs option as far as I know only includes the logs that were
active from the start of the backup to the end of the backup.
For example, if the first active log is log 15 when you launch the backup
and the when you took the previous backup and finished with log 10; then,
logs 11,12,13,14 will NOT be included in your current online backup with
include logs.
Pierre, I'd say that the logs 11 thru 14 are the data changes that are
actually backup up. Or do you mean that you still have to keep the log
files if you want to recover to a point in time that is before the current
backup?
Some disaster recovery strategies are easier to implement when you are
coming from an offline backup.
Given where V8.2 is, I don't see any glaring requirements for offline
backups apart from the DBA'S peace of mind!!

Offline backups were there first. So they won't go away so quickly.
Besides, an offline backup should run much faster because no locking issues
need to be considered. And if the environment allows to take the DB
offline, this might be important when working out the backup strategies.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany

[Pierre Saint-Jacques]

All right, I should have been clearer.
The changes in logs 11-14 are obviously in the tables as the logs are now
archivable. However, if your current online backup cannot be restored,
you'll need the previous one and also logs 11.-14 + whatever goes beyoond to
restore rollforward. And yes if you need to recover to a PIT before the
online backup, you'll need the previous image and logs 11-14 + whatever logs
are beyound to reach your PIT.

Another point that a post in this newsgroup made me think about. Sometimes,
when you need to migrate to a new version of DB2, there's seems to be a
problem in rolling forward logs of a version to another db of another
version.
Say:
Current V72+ online backups and logs
Restore to a V8.2+ system. The restore migrates the db to a V8 But...
Roll Forward has apparently reported problems in trying to roll forward a V7
log on V8 db or so the post seems to indicate.

That would be another reason why an off line backup may be needed.
HTH, Pierre.

--
Pierre Saint-Jacques
SES Consultants Inc.
514-737-4515
"Knut Stolze" <st****@de.ibm.com> a écrit dans le message de news:
dq**********@lc03.rz.uni-jena.de...

Pierre Saint-Jacques wrote:

First, you need to be careful.
The include logs option as far as I know only includes the logs that were
active from the start of the backup to the end of the backup.
For example, if the first active log is log 15 when you launch the backup
and the when you took the previous backup and finished with log 10; then,
logs 11,12,13,14 will NOT be included in your current online backup with
include logs.

Pierre, I'd say that the logs 11 thru 14 are the data changes that are
actually backup up. Or do you mean that you still have to keep the log
files if you want to recover to a point in time that is before the current
backup?

Some disaster recovery strategies are easier to implement when you are
coming from an offline backup.
Given where V8.2 is, I don't see any glaring requirements for offline
backups apart from the DBA'S peace of mind!!

Offline backups were there first. So they won't go away so quickly.
Besides, an offline backup should run much faster because no locking
issues
need to be considered. And if the environment allows to take the DB
offline, this might be important when working out the backup strategies.

--
Knut Stolze
DB2 Information Integration Development
IBM Germany

[richard_mccutcheon]

Thank you gentlemen. That is the kind of information that I need to
help decide on my strategy.

Part of my problem is that we have a number of third party applications
(such as Tivoli TEC, PeopleSoft, SmartTeam, etc.) that have been
implemented with admin ids as part of the instance group. This is the
documented requirement for some of these apps and makes a DBA's skin
crawl...............My problem is that we occassionally can't get
exclusive control for offline backups so we are flirting with the idea
of online only.

Pierre you mentioned something I heard about as well, but have
forgotten. Thank you.
Regards,
Richard McCutcheon,
Honda of Canada, Manufacturing.