Multiple DB2 subsystems on the same LPAR

Peter Cavan

Multiple DB2 subsystems on the same LPAR
We are running Z/OS V1.4, DB2 V7.1. We are running 1 very busy
production DB2 subsystem on a very busy LPAR.

Would it be beneficial to split the work into 2 separate DB2 subsystems
on the same LPAR?

Any comments from someone already running multiple production subsystems
on the same LPAR?



Pete Cavan






-----------------------------------------
This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you
should delete this message immediately.


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

Dave Nance

Re: Multiple DB2 subsystems on the same LPAR
(in response to Peter Cavan)
Pete,
We are not doing this, but a few things to bear in mind. If this is
such a busy LPAR, can it handle the overhead of another subsystem and
separate monitoring of that subsystem? Do you have enough memory to
ensure that you wouldn't be doing a lot of paging? What about the
increases in memory usage, now you have 2 DB2 catalogs and the BP0
associated with both of them. It seems to me you should be more
interested in another LPAR and using sysplex and data sharing to split
up the work between machines.

Dave Nance
First Health Services, Corp.
(804)527-6841


>>> [login to unmask email] 1/5/05 10:19:34 AM >>>

We are running Z/OS V1.4, DB2 V7.1. We are running 1 very busy
production DB2 subsystem on a very busy LPAR. Would it be beneficial to
split the work into 2 separate DB2 subsystems on the same LPAR?Any
comments from someone already running multiple production subsystems on
the same LPAR? Pete Cavan



This message and its contents (to include attachments) are the property
of Kmart Corporation (Kmart) and may contain confidential and
proprietary information. You are hereby notified that any disclosure,
copying, or distribution of this message, or the taking of any action
based on information contained herein is strictly prohibited.
Unauthorized use of information contained herein may subject you to
civil and criminal prosecution and penalties. If you are not the
intended recipient, you should delete this message immediately.
---------------------------------------------------------------------------------
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

"MMS <fhmail.firsthealth.com>" made the following annotations.
------------------------------------------------------------------------------
This message, including any attachments, is intended solely for the use
of the named recipient(s) and may contain confidential and/or
privileged information. Any unauthorized review, use, disclosure or
distribution of this communication(s) is expressly prohibited.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy any and all copies of the original message.
Thank you.
=====

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

Jeff Frazier

Re: Multiple DB2 subsystems on the same LPAR
(in response to Dave Nance)
Pete, we run 3 production DB2's on 1 Lpar. 1 is peoplesoft hr, 1
peoplesoft fs and 1 legacy. we are also z/os 1.4 and db2 v7 running on a
z/800 using db2 dataspaces. we split to separate hr from financials.
legacy of course was already there.
HTHs
Jeff




"Cavan, Peter" <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
01/05/2005 10:19 AM
Please respond to DB2 Database Discussion list at IDUG


To: [login to unmask email]
cc:
Subject: [DB2-L] Multiple DB2 subsystems on the same LPAR




We are running Z/OS V1.4, DB2 V7.1. We are running 1 very busy production
DB2 subsystem on a very busy LPAR.

Would it be beneficial to split the work into 2 separate DB2 subsystems on
the same LPAR?

Any comments from someone already running multiple production subsystems
on the same LPAR?



Pete Cavan




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

Ricky Wafford

Re: Multiple DB2 subsystems on the same LPAR
(in response to Jeff Frazier)
I have had that conversation with our management team on several occasions
over the years. Here are some of the observations to consider.


* First, the nature of your workload would have to support the split.
With 2 separate subsystems, you can no longer share the data.
* The split into 2 subsystems will add extra overhead items, like DASD
for catalogs and work table spaces, and DB2 logs, and support libraries
(load libraries and others). This will also mean more real storage and CPU
to support the 2 subsystems.
* If your current bottleneck or limiting factor is CPU or memory,
another DB2 Subsystem will not help that.
* If your current bottlenecks are specific DB2 resources, like
contention on the active logs, another DB2 subsystem will give you another
logging subsystem and another set of active logs to share the workload.
Another example of a "specific DB2 resource" would be storage in the DBM1
address space, where another subsystem could help you spread this resource
across 2 address spaces.

It has been my experience that there are very few "specific DB2 resources"
that cause these problems,,,, and splitting into 2 subsystems is not a good
solution.
However, there are other reasons (other than performance problems) where the
need to split into multiple subsystems is justified. (like the need to
maintain different maintenance levels or strategies) If one subsystem need
the latest and greatest bells and whistles while another needs a more
conservative approach.

Ricky Wafford
MBNA Technology Inc.
Manager - DB2 Technical Support
(469) 201-6271
Mailto:[login to unmask email] <mailto:[login to unmask email]>

-----Original Message-----
From: Cavan, Peter [mailto:[login to unmask email]
Sent: Wednesday, January 05, 2005 9:20 AM
To: [login to unmask email]
Subject: [DB2-L] Multiple DB2 subsystems on the same LPAR



We are running Z/OS V1.4, DB2 V7.1. We are running 1 very busy production
DB2 subsystem on a very busy LPAR.

Would it be beneficial to split the work into 2 separate DB2 subsystems on
the same LPAR?

Any comments from someone already running multiple production subsystems on
the same LPAR?



Pete Cavan





_____




This message and its contents (to include attachments) are the property of
Kmart Corporation (Kmart) and may contain confidential and proprietary
information. You are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on
information contained herein is strictly prohibited. Unauthorized use of
information contained herein may subject you to civil and criminal
prosecution and penalties. If you are not the intended recipient, you should
delete this message immediately.

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

Avram Friedman

Re: Multiple DB2 subsystems on the same LPAR
(in response to Ricky Wafford)
We run many DB2 subsystems usually as members of the same data sharing
group on a single LPAR.
Actually 12 members across 4 LPARS in a single data sharing group.

In spite of our use of data sharing we have a high degree of application
to member isolation.
We do this in part to protect key applications form outages in other
members (although these are rare).

A classic reason for several DB2s on the same LPAR was to address finite
resources, for example before hyper pools having many DB2s was a common
way to allow larger DB buffer pools.

The disadvantage of several DB2's per LPAR in the same data sharing
group are
Additional complexity
Additional overhead (for example if system check points are taken every
5 minutes, the total number of checkpoints is increased.
Additional storage requirements, count on 2 gig per DB2.
Defeats the idea of cross system query parallelism because there is now
completion for the same CPs from other DB2 members.

_____

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Cavan, Peter
Sent: Wednesday, January 05, 2005 10:20 AM
To: [login to unmask email]
Subject: [DB2-L] Multiple DB2 subsystems on the same LPAR



We are running Z/OS V1.4, DB2 V7.1. We are running 1 very busy
production DB2 subsystem on a very busy LPAR.

Would it be beneficial to split the work into 2 separate DB2 subsystems
on the same LPAR?

Any comments from someone already running multiple production subsystems
on the same LPAR?



Pete Cavan



_____

This message and its contents (to include attachments) are the property
of Kmart Corporation (Kmart) and may contain confidential and
proprietary information. You are hereby notified that any disclosure,
copying, or distribution of this message, or the taking of any action
based on information contained herein is strictly prohibited.
Unauthorized use of information contained herein may subject you to
civil and criminal prosecution and penalties. If you are not the
intended recipient, you should delete this message immediately.

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

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.


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

Joel Goldstein

Re: Multiple DB2 subsystems on the same LPAR
(in response to Avram Friedman)
Pete,

I think the key phrase is what you wrote
is " 1 very busy production DB2 subsystem on a very busy LPAR."
If your LPAR is already very busy, you probably can't afford to run a second DB2 there, even if you were thinking
that the cpu consumption might be split 50/50. It will cost you more cpu to do this, and as others mentioned, there are a lot
of other additional resource impacts as well.

Regards,
Joel
----- Original Message -----
From: Cavan, Peter
Newsgroups: bit.listserv.db2-l
To: [login to unmask email]
Sent: Wednesday, January 05, 2005 10:19 AM
Subject: [DB2-L] Multiple DB2 subsystems on the same LPAR


We are running Z/OS V1.4, DB2 V7.1. We are running 1 very busy production DB2 subsystem on a very busy LPAR.

Would it be beneficial to split the work into 2 separate DB2 subsystems on the same LPAR?

Any comments from someone already running multiple production subsystems on the same LPAR?



Pete Cavan





------------------------------------------------------------------------------


This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately.

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