UDB Questions

[Raquel]

Hello!! Had some questions about UDB...

1. In the disaster recovery section, the manual states: "

"If your plan for disaster recovery is to recover the entire database
on another machine, you require at least one full database backup and
all the archived logs for the database. Even if you have a separate
backup image of every table space, you cannot use them to recover the
database.".

I don't quite appreciate this. Backup image of ever table space
*should* ensure recoverability of all the 'data' in the database. By
recovering all the tablespaces, I will not have recovered the meta-data
associated with the database (UDFs etc.) but at least all the user data.
However the manual however specifically negates it. Seems there is something
I am missing.

2. UDB manuals have frequent references to "administra tion notification
log file". What is this file and where is it located on Linux? How
often should it be browsed for system messages?

3. The manual states: "When considering active log space, it may be
better to have a larger number of smaller log files. For example, if there
are 2 very large log files and a transaction starts close to the end of
one log file, only half of the log space remains available." What does
it mean by 'only half of the log space remains available'?

4. The manual recommends: "If you are enabling an existing database for
rollforward recovery, change the number of primary logs to the sum of
the number of primary and secondary logs, plus 1.". What is the basis of
this recommendation? Can we not specify logsecond for recoverable
databases?

TIA
Raquel.

[Mauro Cazzari]

Re: UDB Questions

Hi Raquel,
Tablespace backups are allowed only if the database is recoverable, which
means that they cannot run offline. Therefore, after a tablespace is
restored, a rollforward must always be executed. If you have backed up all
of your tablepaces but don't have any logs, there is no way you can recover
the database.
The administration notification file is a file called db2.nfy, and it's
located in the same directory where the db2diag.log resides, which is
<instance home directory>/sqllib/db2dump. Among other things, it records
messages coming from the Health Monitor. Because its generally much smaller
than db2diag.log, it's also much easier to browse for diagnostic info.
As for the number of logs to allocate, there are many school of thoughts
when it comes to choosing the best strategy. If your database is recoverable
and you're using a userexit to archive the logs, small logs may cause the
program to be called very often in case the database content changes
frequently. On the other side, having larger logs may cause problems during
a recovery if one of the logs is corrupted; therefore, the larger the log,
the larger the amount of data that is lost. Other considerations apply to
when a database is first accessed; with circular logging, the primary logs
are allocated when either the database is activated or when someone connects
to it. If the logs are large in size and their number is high, it may take
some time for DB2 to allocate all of them. The same is true for secondary
logs; when DB2 needs to allocate them, their size can play an important role
in determining how long it takes to allocate them. My personal choice if for
a small number of primary logs and a large number of secondary logs. As for
their size, I look at the workload.
Hope this helps.
Mauro.


"Raquel" <raquel_rodrigu ezus@yahoo.com> wrote in message
news:9a73b58d.0 311122145.4ea1f 39c@posting.goo gle.com...[color=blue]
> Hello!! Had some questions about UDB...
>
> 1. In the disaster recovery section, the manual states: "
>
> "If your plan for disaster recovery is to recover the entire database
> on another machine, you require at least one full database backup and
> all the archived logs for the database. Even if you have a separate
> backup image of every table space, you cannot use them to recover the
> database.".
>
> I don't quite appreciate this. Backup image of ever table space
> *should* ensure recoverability of all the 'data' in the database. By
> recovering all the tablespaces, I will not have recovered the meta-data
> associated with the database (UDFs etc.) but at least all the user data.
> However the manual however specifically negates it. Seems there is[/color]
something[color=blue]
> I am missing.
>
> 2. UDB manuals have frequent references to "administra tion notification
> log file". What is this file and where is it located on Linux? How
> often should it be browsed for system messages?
>
> 3. The manual states: "When considering active log space, it may be
> better to have a larger number of smaller log files. For example, if there
> are 2 very large log files and a transaction starts close to the end of
> one log file, only half of the log space remains available." What does
> it mean by 'only half of the log space remains available'?
>
> 4. The manual recommends: "If you are enabling an existing database for
> rollforward recovery, change the number of primary logs to the sum of
> the number of primary and secondary logs, plus 1.". What is the basis of
> this recommendation? Can we not specify logsecond for recoverable
> databases?
>
> TIA
> Raquel.[/color]

[P. Saint-Jacques]

Re: UDB Questions

Raquel, an answer to your No. 1
The database in DB2 UDB LUW is a physical entity with its own config.
file and logs as well as some control files that are located in the
database path at creation. End directory ...../SQLnnnnn
As well at db create a unique seed number is generated.
All these are required to exist in the target system if you plan to
recover a db with only its tablespaces. This means that a reccovery
strategy based on tablespaces REQUIRES the target db to ecist.
When one or more tablespaces are recovered to a target db the recovery
process ALWAYS verifies the existing tablespaces in the target against
the list of tablespaces contained in the image. They must match.

Of course, if you recover from a full db backup, you can restore new as
everything is in the image. This is not the case in an image that
contains only one or more images of tablespaces backups.

UDB for LUW has a complete db, this is not like a DB2 for z/OS where the
DB2 system is basically a huge tablespace repository where tablespaces
can be "copied" between db2 sussystem.
HTH, Pierre.

Raquel wrote:
[color=blue]
> Hello!! Had some questions about UDB...
>
> 1. In the disaster recovery section, the manual states: "
>
> "If your plan for disaster recovery is to recover the entire database
> on another machine, you require at least one full database backup and
> all the archived logs for the database. Even if you have a separate
> backup image of every table space, you cannot use them to recover the
> database.".
>
> I don't quite appreciate this. Backup image of ever table space
> *should* ensure recoverability of all the 'data' in the database. By
> recovering all the tablespaces, I will not have recovered the meta-data
> associated with the database (UDFs etc.) but at least all the user data.
> However the manual however specifically negates it. Seems there is something
> I am missing.
>
> 2. UDB manuals have frequent references to "administra tion notification
> log file". What is this file and where is it located on Linux? How
> often should it be browsed for system messages?
>
> 3. The manual states: "When considering active log space, it may be
> better to have a larger number of smaller log files. For example, if there
> are 2 very large log files and a transaction starts close to the end of
> one log file, only half of the log space remains available." What does
> it mean by 'only half of the log space remains available'?
>
> 4. The manual recommends: "If you are enabling an existing database for
> rollforward recovery, change the number of primary logs to the sum of
> the number of primary and secondary logs, plus 1.". What is the basis of
> this recommendation? Can we not specify logsecond for recoverable
> databases?
>
> TIA
> Raquel.[/color]

--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.

[Raquel]

Re: UDB Questions

Thanks Pierre. You definitely clear things up for me.

Raqauel.

[Raquel]

Re: UDB Questions

Thanks Mauro. Your explanation was very helpful.

Raquel.

[Kelly D. Rodger]

Re: UDB Questions

Mauro Cazzari wrote:
[color=blue]
> Tablespace backups are allowed only if the database is recoverable, which
> means that they cannot run offline. Therefore, after a tablespace is
> restored, a rollforward must always be executed. If you have backed up all
> of your tablepaces but don't have any logs, there is no way you can recover
> the database.[/color]

Just wanted to clarify... a recoverable database is a prerequisite for
tablespace backup/restore, but you can still perform both offline and
online backup/restore operations.

kdr
--
=============== =============== =============== =============== =========
Kelly D. Rodger IBM Canada
DB2 UDB Development Backup & Restore
=============== =============== =============== =============== =========

[P. Saint-Jacques]

Re: UDB Questions

Yes. Both at the tablespace and db level.
Regards, Pierre.

Kelly D. Rodger wrote:[color=blue]
> Mauro Cazzari wrote:
>[color=green]
>> Tablespace backups are allowed only if the database is recoverable, which
>> means that they cannot run offline. Therefore, after a tablespace is
>> restored, a rollforward must always be executed. If you have backed up
>> all
>> of your tablepaces but don't have any logs, there is no way you can
>> recover
>> the database.[/color]
>
>
> Just wanted to clarify... a recoverable database is a prerequisite for
> tablespace backup/restore, but you can still perform both offline and
> online backup/restore operations.
>
> kdr[/color]

--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.