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" <ra****************@yahoo.com> wrote in message
news:9a**************************@posting.google.c om...
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 "administration 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.
