DB2 LOGCOPY placement on PAV DASD.

Paul Weissman

DB2 LOGCOPY placement on PAV DASD.
Listees,

We run DB2 V7 on z/OS 1.4. Our shop is migrating to a latest & greatest model of DASD array, in this case HDS Tagmastore. Our Storage Admins want to eliminate all mod-3 size volumes in favor of mod-9 and mod-27. Our current DASD is an earlier HDS model with dynamic parallel access volumes (PAV) enabled. Our Production DB2 currently has every LOGCOPY dataset on a dedicated mod-3 volume. It's proposed to migrate these to two mod-9 or mod-27 volumes with all LOGCOPY1's on one volume and all LOGCOPY2's on another.

We DBAs object to this proposal, believing that performance will degrade when logs switch due to concurrent logging and archiving on the same volume. Problem is that the documentation predates PAVs. Our preference would be to keep the dedicated volumes or, as a second choice a 4 volume configuration with even-odd seperation of the LOGCOPY's (1-3-5-7 2-4-6-8) to reduce the likelihood of contention between logging & archiving.

Testing would be nice, but a bit problematic due to time & resource constraints and once the new DASD box is carved up into volumes it will be difficult to change.

Has anybody out there had any applicable experience with LOGCOPY datasets on DASD with PAV that they can share? Thanks.



Visit our website at http://www.ubs.com

This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.

---------------------------------------------------------------------------------
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

Billy Larsen

Re: DB2 LOGCOPY placement on PAV DASD.
(in response to Paul Weissman)
we have this configuration (with EMC2), we were a bit sceptic in the
beginning but the test shows no iosq time so we keep the solution (after al
PAV stands for Parallel Access Volume , so why should we be afraid about that ?)
The best thing for you is to create quite small logs , do inserts with
dsntiad to fill up the logs , and then observe if there is an impact . It
can be done in less than 15 minutes

regards

---------------------------------------------------------------------------------
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

Avram Friedman

Re: DB2 LOGCOPY placement on PAV DASD.
(in response to Billy Larsen)
A few warnings
1. When dealing with active log packs ... throw out EVERYTHING you think you know about DASD tuning from RMF, Absolutly none of it is correct.
One example IOSQUE is an indicator or I/O delay because the requests are not processed when they arrive and hence queue.
This Rule Of Thumb is based on the assumption that there are many I/O requestors and excess requests queue on the UCB. Not true for the journals of any multi address space DBMS. There in fact is a single physical I/O requestor, *MSTR in the case of DB2 and queueing in any does not occur on the UCB for the device it occurs on a lock / latch / dcb / acb in the application. In the case of DB2 it occurs on the Log Latch in DB2 ... RMF WILL NEVER, NEVER, SEE THIS.
2. PAVs do not help dedicated log volumes except in the rare cases of:
Logging and archiving from the same volume at the same time
Logging from several DB2 subsystems to the same volume
Primary and Secondary logs on the same volume at the same time
Non log data sets on the same log
If any of these are true there are other problems that need to be solved anyway.

3. There are a couple of rare conditions were (a) non sequencial writes can occur to the DB2 logs and (b) Reads and writes and occur at the same time.
(a) Two phase commit checkpoint processing where the buffers are not reused between the first and second phase.
(b) Backout / recovery using active logs
Normally PAVs would not help these situations because more than one access will not be assigned to a single extent and logs are usually allocated in a single extent.

NEED a GO-FAST for active logs because your substained log volume is to high?
THE SOLUTION IS STRIPING not PAV's

Billy Larsen <[login to unmask email]> wrote:
we have this configuration (with EMC2), we were a bit sceptic in the
beginning but the test shows no iosq time so we keep the solution (after al
PAV stands for Parallel Access Volume , so why should we be afraid about that ?)
The best thing for you is to create quite small logs , do inserts with
dsntiad to fill up the logs , and then observe if there is an impact . It
can be done in less than 15 minutes

regards

---------------------------------------------------------------------------------
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




Avram Friedman
(877)311-0480 Voice Mail
[login to unmask email]
Http://www.IBMsysProg.com




---------------------------------------------------------------------------------
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