469,275 Members | 1,344 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,275 developers. It's quick & easy.

is there a recover "db2 subsystem" command in DB2 for OS/390 ..?

I come from Oracle background. In Oracle, when one wants to do a point
in time
recovery, one can specify recover database until timestmap. Oracle's
database maps to a db2 subsystem, i.e., in Oracle database means
entire database, i.e.. all tablespaces (including indexes).

I see only recover tablespace and recover indexspace (or index)
commands in db2.
Therefore, one has to specify all the tablespaces and indexspaces and
recover them
to a spaecific rba (is that right).

I did not see a recover database command in db2. That can be quite
useful.

My db2 subsystem runs 24x7. Db2 provides a quiesce command to make
various tablespaces consistent to a point in time. Why do I need this
command, if database is 24x7 and I will be always backing up using
shrlevel change.

I am new to db2, so please pardon if I am asking some nnewbie
questions ...

Thanks.
Nov 12 '05 #1
5 3610
"Prem K Mehrotra" <pr**********@hotmail.com> wrote in message
news:43**************************@posting.google.c om...
I come from Oracle background. In Oracle, when one wants to do a point
in time
recovery, one can specify recover database until timestmap. Oracle's
database maps to a db2 subsystem, i.e., in Oracle database means
entire database, i.e.. all tablespaces (including indexes).

I see only recover tablespace and recover indexspace (or index)
commands in db2.
Therefore, one has to specify all the tablespaces and indexspaces and
recover them
to a spaecific rba (is that right).

I did not see a recover database command in db2. That can be quite
useful.

My db2 subsystem runs 24x7. Db2 provides a quiesce command to make
various tablespaces consistent to a point in time. Why do I need this
command, if database is 24x7 and I will be always backing up using
shrlevel change.

I am new to db2, so please pardon if I am asking some nnewbie
questions ...

Thanks.


When you speak about DB2 you ALWAYS need to specify what platform (OS) you
are on. You are obviously on OS/390 or z/OS, since DB2 for Linux, Unix, and
Windows allows backup and restore at the database level just like Oracle.

DB2 for OS/390 does not allow recovery (restore) at the sub-system level.
The reason for this has to do with the nature of the mainframe vs. smaller
platforms, where there is often one (or a few) production DB2 sub-system
that is shared by all applications. On Linux, Unix, and Windows platforms,
it is often the case that one application has it owns database server or at
least its own sub-system (database).

You do not have to specify RBA. You can just say "recover" and DB2 will
apply the last image copy and roll the logs the forward to the current time.
Recovering to an RBA is fairly unusual. Most people just "Recover" (to
current point in time) or recovery to a (image) copy.

Quiece has some other features such as taking a synchpoint on the log. This
makes it a bit quicker to recover if there are no changes to the database
(or few changes) between the time you do the quiece and the backup. As you
mentioned, it also helps if you need to recover to an RBA.
Nov 12 '05 #2
Mark:

Thanks a lot. Yes I am on OS/390. Is is correct that the primary
purpose
of quiesce is fast recovery and not data comsistency. Is quiesce like
a checkpoint in Oracle.
If my database is 24x7, I do not have to run quiesce command because
it seems to require shrlevel read.
Prem
Nov 12 '05 #3
"Prem K Mehrotra" <pr**********@hotmail.com> wrote in message
news:43**************************@posting.google.c om...
Mark:

Thanks a lot. Yes I am on OS/390. Is is correct that the primary
purpose
of quiesce is fast recovery and not data comsistency. Is quiesce like
a checkpoint in Oracle.
If my database is 24x7, I do not have to run quiesce command because
it seems to require shrlevel read.

Prem


You don't have to issue a quiece. But it does write the changed pages from
the bufferpool to disk for the specified tablespace(s) and records the RBA
in the SYSCOPY catalog table. This can be an aid to faster recovery and data
consistency. It is recommended (but not required) that you run the quiece
before an image copy, even if it is sharelevel change.

I am not sure what you mean by "it seems to require sharelevel read." The
quiece command typically only takes one or two seconds (at most) to execute.
Nov 12 '05 #4
Mark:

After reading the doceument carefully, yes the command does not require
shrlevel reference, it seems to have same effect as shrlevel reference.

while quiesce is going on, one cannot do any updates, that's where I got the
impression of SHRLEVEL reference.

Thanks a lot for clarifying.

Prem
Nov 12 '05 #5
"Prem K Mehrotra" <pr**********@hotmail.com> wrote in message
news:43**************************@posting.google.c om...
Mark:

After reading the doceument carefully, yes the command does not require
shrlevel reference, it seems to have same effect as shrlevel reference.

while quiesce is going on, one cannot do any updates, that's where I got the impression of SHRLEVEL reference.

Thanks a lot for clarifying.

Prem


It runs very quickly, so I would not worry about it unless you have
extremely high transaction rates.
Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Dmitri | last post: by
1 post views Thread by LazyAnt | last post: by
reply views Thread by wxqun | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.