Dear all,

I have some basic confusions ,pls let me know.

1Q)If i use logarchmeth1=logretain and i am going to take online backup, where will be logs archieved (default path)

2Q)if i use "INCLUDE LOGS " option , the archieved logs (in default location) are needed for restore ????
or
can i extract simply from backup image using LOG TARGET option??
pls i dont have any clear idea about logs, pls help me out.

3Q)first time i am setting logarchmeth1=logretain, and trying to take online backup, it is showing some error as follows:


SQL2413N Online backup is not allowed because the database is not recoverable
or a backup pending condition is in effect.

Explanation:

Online backup cannot be performed while the database is not
logging for forward recovery as forward recovery will be required
at restore time. Forward recovery is placed into effect by
setting either the database configuration LOGARCHMETH1 or
LOGARCHMETH2 and then performing an offline backup of the
database.

User Response:

Execute an offline backup or reconfigure the database for
roll-forward recovery and issue an offline backup so that
subsequent online backups will be allowed.

-------------------------------------------------------------------
why i have to take offline backup before online backup??

while restoring online backup, did you need this offline backup????
ur suggestions will be very valuble for me.....................

First, log archiving and taking backups has nothing to do with each other. A backup produces a snapshot of your database. Logs will be continued to be written and they will also be archived if necessary while the backup is running.

If you say INCLUDE LOGS for a BACKUP DATABASE command, it means that the backup image will contain a copy of all log records that were produced while the backup was running. That does not impact the handling of log files, i.e. the archiving. Why should it?

Why would you want to "extract" anything? If you need to recover the database using the backup image you just do that. Since the logs are included, you know that you will get a consistent database after the recovery.

Some basic things about backups and logging:

• The data inserted, deleted, or updated in tables as well as DDL statements will be applied to the pages cached in the buffer pool (in memory). There is no guarantee that those pages are actually written to disk when the respective transactions (that made the changes) has been COMMITed. Thus, in case of a power-outage or crash, those changes would be lost if the database system wouldn't log the changes separately in the log files, which are guaranteed to be written to disk. (Without that, DB2 couldn't deliver the ACID properties required for transactional systems.
• If you have a system crash and a loss of your database (e.g. corrupted file systems), you need to have a copy of the database and get it again to the point right before the crash. For that, you'll need a "backup image". A backup is a consistent snapshot of the database. Since you can't take a backup at every milli-second, a backup will always be outdated, of course. That is where the log files come into play: all logs written after the backup was taken are (automatically) applied on top of the backup snapshot, i.e. all changes made to the database after the backup are re-played (up to the point-in-time to which you want to recover).
• If a backup was taken OFFLINE, it means that no one could access the database while the backup image has been produced. Thus, it is guaranteed that the backup in itself only contains consistent data. If a backup was ONLINE, you may have had concurrent transactions modifying the data. Then you may have partial changes to data pages in the backup image, which may not be consistent. In order to get all information needed to recover to a consistent database again, the logs are needed again to complete (or undo) the transactions that were running while the backup was taken. This is where the INCLUDE LOGS option comes in: DB2 will determine for you which logs are needed and puts them into the backup image automatically.
• For logging, you could have circular logging or archival logging. With circular logging, DB2 will overwrite old logs at some point - with archival logging, it won't. A direct consequence is that you cannot use circular logging if you want to use the logs during database recovery.
• If you want to switch from circular to archival logging, it means that you want to use the logs to recover to potentially any point in time between backups.
• Now, since an ONLINE backup needs to have the logs included to come up with a consistent database, you cannot have circular logging while taking an ONLINE backup - some part of the log data may have been overwritten, which means that the required log data may not be complete. Hence, you get the error message that DB2 requires an OFFLINE backup (since an OFFLINE backup is always consistent even without the logs).

That was a very useful description by Knut. Thanks.

To supplement his post ..

the logs will not be archived, but 'retain'ed in the active log path.
For obvious reasons, this is not recommended.

if you want to rollforward to a point in time, you need more logs than what is in the backup. The logs in the backup will help you to rollforward to a consistent point very close to the end time of backup.
see previous comment.

You have to deactivate and activate the database for the parameter to take effect.

to establish a consistent starting point for online backups.
No

HTH

Thanku so much for ur suggestions Mr.Knut and Satyaram. they r very useful for me.........