Quiesce of catalog/directory sequence

Joop Ammerlaan

Quiesce of catalog/directory sequence
Dear list,

Accoording to the Admin. Guide our QUIESCE statement for the
catalog/direcotory looks like:

QUIESCE TABLESPACE DSNDB01.DBD01
TABLESPACE DSNDB01.SCT02
TABLESPACE DSNDB01.SPT01
TABLESPACE DSNDB06.SYSDBASE
TABLESPACE DSNDB06.SYSDBAUT
TABLESPACE DSNDB06.SYSGPAUT
TABLESPACE DSNDB06.SYSGROUP
TABLESPACE DSNDB06.SYSPLAN
TABLESPACE DSNDB06.SYSPKAGE
TABLESPACE DSNDB06.SYSUSER
TABLESPACE DSNDB06.SYSSTR
TABLESPACE DSNDB06.SYSVIEWS
TABLESPACE DSNDB06.SYSSTATS
TABLESPACE DSNDB06.SYSDDF
TABLESPACE DSNDB06.SYSOBJ
TABLESPACE DSNDB01.SYSLGRNX
TABLESPACE DSNDB06.SYSSEQ
TABLESPACE DSNDB06.SYSSEQ2
TABLESPACE DSNDB06.SYSHIST
TABLESPACE DSNDB06.SYSGRTNS
TABLESPACE DSNDB06.SYSJAVA
TABLESPACE DSNDB06.SYSJAUXA
TABLESPACE DSNDB06.SYSJAUXB

The quiesce for SYSCOPY and SYSUTILX are in a seperate jobstep. The problem we have is that other
jobs/tasks get a timeout error on i.e. SYSDBASE or SYSLGRNX when we want to quiesce the DB2 cat/dir.

Is there a recommended sequence for the tablespaces (i.e. the most busy ones at the beginning)?

We we asked IBM about this and they came up with:

"Hi,
I've reviewed the pmr and when the objects are specified in the list, it doesn't matter which order they are
listed. The entire list will be serialized for the duration of the QUIESCE. This is because each object in the
list will recieve the same Quiesce point. So either the Quiesce will need to be run at a less busy time, or the
list can be broken up into several Quiesce jobs.
Regards,
Debbie"

This surprises me, because to my understanding DB2 will try to get (IN SEQUENCE) a drain on all the mentioned
tablespaces. So if there is a busy one on which it must wait for the drain to complete, all the other already drained
tablespaces are locked for further access.

Is there a way to determine which catalog/directory tablespaces are the most busy?

kind regards, Joop Ammerlaan - ABN Amro bank N.V. - The Netherlands
---------------------------------------------------------------------------
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return
e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited.
Please note that e-mails are susceptible to change.
ABN AMRO Bank N.V. (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in
this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the
integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.
---------------------------------------------------------------------------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mark Vickers

Re: Quiesce of catalog/directory sequence
(in response to Joop Ammerlaan)
Joop,
We run our Quiesce with the default (write yes) to get buffers written out,
backup the catalog and Quiesce again for a fast recovery point.
This job runs daily at a specific time which is normally the end of our
batch cycle, but before the online systems come up and we have not had any
problems (probably because our new Z990 gets through the batch cycle with a
few hours to spare!).
To check your locks/claims, how about the display database command (-DIS
DB(DSNDB*) SPACENAM(*) LIMIT(*) LOCKS/CLAIMERS/USE).
I used the IBM automation tool to generate these steps for me simply
specifying the DSNDB01/6 databases, and here is what it came up with:

COPY QUIESCE
STEP1 (STACKED ON TAPE) STEP1
DSNDB06.SYSDDF DSNDB01.DBD01
DSNRGFDB.DSNRGFTS DSNDB01.SCT02
DSNRLST.DSNRLS01 DSNDB01.SPT01
DSNDB06.SYSGPAUT DSNDB01.SYSLGRNX
DSNDB06.SYSGROUP DSNDB06.SYSCOPY
DSNDB06.SYSGRTNS DSNDB06.SYSDBASE
DSNDB06.SYSHIST DSNDB06.SYSDBAUT
DSNDB06.SYSJAUXA DSNDB06.SYSDDF
DSNDB06.SYSJAUXB DSNDB06.SYSGPAUT
DSNDB06.SYSJAVA DSNDB06.SYSGROUP
DSNDB06.SYSOBJ DSNDB06.SYSGRTNS
DSNDB06.SYSPKAGE DSNDB06.SYSHIST
DSNDB06.SYSPLAN DSNDB06.SYSJAUXA
DSNDB06.SYSSEQ DSNDB06.SYSJAUXB
DSNDB06.SYSSEQ2 DSNDB06.SYSJAVA
DSNDB06.SYSSTATS DSNDB06.SYSOBJ
DSNDB06.SYSSTR DSNDB06.SYSPKAGE
DSNDB06.SYSVIEWS DSNDB06.SYSPLAN
DSNDB01.SCT02 DSNDB06.SYSSEQ
DSNDB01.SPT01 DSNDB06.SYSSEQ2
STEP2 DSNDB06.SYSSTATS
DSNDB06.SYSDBASE DSNDB06.SYSSTR
STEP3 DSNDB06.SYSUSER
DSNDB06.SYSUSER DSNDB06.SYSVIEWS
STEP4 DSNRGFDB.DSNRGFTS
DSNDB06.SYSDBAUT DSNRLST.DSNRLS01
STEP5 STEP2
DSNDB01.SYSLGRNX DSNDB01.SYSUTILX
STEP6
DSNDB06.SYSCOPY
STEP7
DSNDB01.DBD01
STEP8
DSNDB01.SYSUTILX

Not too happy about the SYSCOPY included in the first quiesce step, so I
moved the SYSCOPY out to it's own STEP3.
Note that the Quiesce is simply ordered by name, so I would guess there is
not a recommended sequence here.
HTH,
Mark.


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Friday, October 31, 2003 2:41 AM
To: [login to unmask email]
Subject: [DB2-L] Quiesce of catalog/directory sequence

Dear list,

Accoording to the Admin. Guide our QUIESCE statement for the
catalog/direcotory looks like:

QUIESCE TABLESPACE DSNDB01.DBD01
TABLESPACE DSNDB01.SCT02
TABLESPACE DSNDB01.SPT01
TABLESPACE DSNDB06.SYSDBASE
TABLESPACE DSNDB06.SYSDBAUT
TABLESPACE DSNDB06.SYSGPAUT
TABLESPACE DSNDB06.SYSGROUP
TABLESPACE DSNDB06.SYSPLAN
TABLESPACE DSNDB06.SYSPKAGE
TABLESPACE DSNDB06.SYSUSER
TABLESPACE DSNDB06.SYSSTR
TABLESPACE DSNDB06.SYSVIEWS
TABLESPACE DSNDB06.SYSSTATS
TABLESPACE DSNDB06.SYSDDF
TABLESPACE DSNDB06.SYSOBJ
TABLESPACE DSNDB01.SYSLGRNX
TABLESPACE DSNDB06.SYSSEQ
TABLESPACE DSNDB06.SYSSEQ2
TABLESPACE DSNDB06.SYSHIST
TABLESPACE DSNDB06.SYSGRTNS
TABLESPACE DSNDB06.SYSJAVA
TABLESPACE DSNDB06.SYSJAUXA
TABLESPACE DSNDB06.SYSJAUXB

The quiesce for SYSCOPY and SYSUTILX are in a seperate jobstep. The problem
we have is that other
jobs/tasks get a timeout error on i.e. SYSDBASE or SYSLGRNX when we want to
quiesce the DB2 cat/dir.

Is there a recommended sequence for the tablespaces (i.e. the most busy ones
at the beginning)?

We we asked IBM about this and they came up with:

"Hi,
I've reviewed the pmr and when the objects are specified in the list, it
doesn't matter which order they are
listed. The entire list will be serialized for the duration of the QUIESCE.
This is because each object in the
list will recieve the same Quiesce point. So either the Quiesce will need
to be run at a less busy time, or the
list can be broken up into several Quiesce jobs.
Regards,
Debbie"

This surprises me, because to my understanding DB2 will try to get (IN
SEQUENCE) a drain on all the mentioned
tablespaces. So if there is a busy one on which it must wait for the drain
to complete, all the other already drained
tablespaces are locked for further access.

Is there a way to determine which catalog/directory tablespaces are the most
busy?

kind regards, Joop Ammerlaan - ABN Amro bank N.V. - The Netherlands
---------------------------------------------------------------------------
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender by
return
e-mail and delete this message from your system. Any unauthorised use or
dissemination of this message in whole or in part is strictly prohibited.
Please note that e-mails are susceptible to change.
ABN AMRO Bank N.V. (including its group companies) shall not be liable for
the improper or incomplete transmission of the information contained in
this communication nor for any delay in its receipt or damage to your
system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that
the
integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.
---------------------------------------------------------------------------

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm