Merging DB2 Subsystems

[login to unmask email]

Merging DB2 Subsystems
OS390 DB2 V6.

We have a situation where we have 2 productions DB2 subsystems. Originally
the second subsystem was running on a separate LPAR (for various business
and office politics reasons, not for DB2 related reasons). Since then we
have merged the LPARS. I have the task of identifying reasons For and
Against merging the 2 subsystems.

Current Situation:
On one subsys we have a primarily on-line customer order system (with a
significant batch component). On the other subsys we have the billing
system, which is primarily batch oriented but also has a minor but
important online component. A subset of data is replicated in both systems
and passed back and forth via batch unloads/loads. There is some also some
online access of data between the subsystems using dynamic SQL. Both
subsystems are setup with virtually identical ZPARMS and not tuned at all
(all TS/IS in BP0) due to 'office politics' (I can't convince the right
clients that there will be no negative impacts on performance during
tuning, and there are some senior managers who are rabidly paranoid about
that sort of thing). When performance/response time decreases 'they' just
buy more CPU cyles (agghhh!).

I've come up with the following list of arguments For and Against:

For
- Eliminate CPU overhead for 1 DB2 subsystem (minor in overall CPU useage)
- makes DR simpler (no need for separate subsys, we currently only DR 1
subsys)
- makes new development of application that access tables from both subsys
(Is becoming more of an issue as time passes). Currently we either use
dynmaic SQL or separate static modules to retrieve data
- speed up data transfer/transform between the subsys (significant portion
of batch process on both sides)
- eliminate need for DRDA (currently planning to implement it)


Against
- lost opportunity for application specific tuning of subsys (but we don't
do it anyway!)
- maybe something in merged subsys becomes too large?
- merge process take too long. When we first set up second subsys this was
a concern because binds took too long. No longer as much of a concern, we
now have proof that it can be done in reasonable (ie weekend) timeframe.

Any other suggestions, either For or Against would be greatly appreciated.

TIA
Rohn

PS: loosely related question. I haven't found anything in the manuals
(suggestions where to look would also be appreciated), yet, on the
following questions. We have a production DB with approx 600 TS plus
indexes and DBD LENGTH = 512816. I can easily, logically, split roughly
2/3 of the TS out into about a dozen separate DBs leaving our major
sub-application in the application with just over 200 TS in one DB. Craig
Mullins book suggests limiting DBs to about 3 dozen TS/IS. Can anyone tell
me if there are performance implications (hopefully positive) to reducing
DB and DBD size? I know about DBD locking issues, we keep tripping over
that one. I can't think of any, but are there any issues with a program
retrieving data from more than one DB in a subysystem?



Eric Pearson

Re: Merging DB2 Subsystems
(in response to Rohn.Solecki@MTS.MB.CA)
Have you considered yet another option - Data Sharing?
This will allow you to do maintenance without a
the users seeing an outage. It also offers a way to
get rid of the duplicated data.

Regards,
eric pearson
NS ITO Database Support


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Monday, December 17, 2001 3:55 PM
To: [login to unmask email]
Subject: Merging DB2 Subsystems


OS390 DB2 V6.

We have a situation where we have 2 productions DB2 subsystems. Originally
the second subsystem was running on a separate LPAR (for various business
and office politics reasons, not for DB2 related reasons). Since then we
have merged the LPARS. I have the task of identifying reasons For and
Against merging the 2 subsystems.

Current Situation:
On one subsys we have a primarily on-line customer order system (with a
significant batch component). On the other subsys we have the billing
system, which is primarily batch oriented but also has a minor but
important online component. A subset of data is replicated in both systems
and passed back and forth via batch unloads/loads. There is some also some
online access of data between the subsystems using dynamic SQL. Both
subsystems are setup with virtually identical ZPARMS and not tuned at all
(all TS/IS in BP0) due to 'office politics' (I can't convince the right
clients that there will be no negative impacts on performance during
tuning, and there are some senior managers who are rabidly paranoid about
that sort of thing). When performance/response time decreases 'they' just
buy more CPU cyles (agghhh!).

I've come up with the following list of arguments For and Against:

For
- Eliminate CPU overhead for 1 DB2 subsystem (minor in overall CPU useage)
- makes DR simpler (no need for separate subsys, we currently only DR 1
subsys)
- makes new development of application that access tables from both subsys
(Is becoming more of an issue as time passes). Currently we either use
dynmaic SQL or separate static modules to retrieve data
- speed up data transfer/transform between the subsys (significant portion
of batch process on both sides)
- eliminate need for DRDA (currently planning to implement it)


Against
- lost opportunity for application specific tuning of subsys (but we don't
do it anyway!)
- maybe something in merged subsys becomes too large?
- merge process take too long. When we first set up second subsys this was
a concern because binds took too long. No longer as much of a concern, we
now have proof that it can be done in reasonable (ie weekend) timeframe.

Any other suggestions, either For or Against would be greatly appreciated.

TIA
Rohn

PS: loosely related question. I haven't found anything in the manuals
(suggestions where to look would also be appreciated), yet, on the
following questions. We have a production DB with approx 600 TS plus
indexes and DBD LENGTH = 512816. I can easily, logically, split roughly
2/3 of the TS out into about a dozen separate DBs leaving our major
sub-application in the application with just over 200 TS in one DB. Craig
Mullins book suggests limiting DBs to about 3 dozen TS/IS. Can anyone tell
me if there are performance implications (hopefully positive) to reducing
DB and DBD size? I know about DBD locking issues, we keep tripping over
that one. I can't think of any, but are there any issues with a program
retrieving data from more than one DB in a subysystem?








[login to unmask email]

Re: Merging DB2 Subsystems
(in response to Eric Pearson)
Yes we are considering it. However, I am not convinced that there really
are any technical reasons for keeping the subsystems separate. In our
situtation I am wondering if Data Sharing is more of a 'solution' than we
really need (sort of like trying to stuff the engine from a Formula 1 race
car into a Volkswagen, more horsepower than you can usefully put to the
road <g> ).





"Pearson, Eric L," <[login to unmask email]>@RYCI.COM> on 2001/12/17
03:18:26 PM
Subject: Re: Merging DB2 Subsystems

Have you considered yet another option - Data Sharing?
This will allow you to do maintenance without a
the users seeing an outage. It also offers a way to
get rid of the duplicated data.

Regards,
eric pearson
NS ITO Database Support


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Monday, December 17, 2001 3:55 PM
To: [login to unmask email]
Subject: Merging DB2 Subsystems


OS390 DB2 V6.

We have a situation where we have 2 productions DB2 subsystems. Originally
the second subsystem was running on a separate LPAR (for various business
and office politics reasons, not for DB2 related reasons). Since then we
have merged the LPARS. I have the task of identifying reasons For and
Against merging the 2 subsystems.

Current Situation:
On one subsys we have a primarily on-line customer order system (with a
significant batch component). On the other subsys we have the billing
system, which is primarily batch oriented but also has a minor but
important online component. A subset of data is replicated in both systems
and passed back and forth via batch unloads/loads. There is some also some
online access of data between the subsystems using dynamic SQL. Both
subsystems are setup with virtually identical ZPARMS and not tuned at all
(all TS/IS in BP0) due to 'office politics' (I can't convince the right
clients that there will be no negative impacts on performance during
tuning, and there are some senior managers who are rabidly paranoid about
that sort of thing). When performance/response time decreases 'they' just
buy more CPU cyles (agghhh!).

I've come up with the following list of arguments For and Against:

For
- Eliminate CPU overhead for 1 DB2 subsystem (minor in overall CPU useage)
- makes DR simpler (no need for separate subsys, we currently only DR 1
subsys)
- makes new development of application that access tables from both subsys
(Is becoming more of an issue as time passes). Currently we either use
dynmaic SQL or separate static modules to retrieve data
- speed up data transfer/transform between the subsys (significant portion
of batch process on both sides)
- eliminate need for DRDA (currently planning to implement it)


Against
- lost opportunity for application specific tuning of subsys (but we don't
do it anyway!)
- maybe something in merged subsys becomes too large?
- merge process take too long. When we first set up second subsys this was
a concern because binds took too long. No longer as much of a concern, we
now have proof that it can be done in reasonable (ie weekend) timeframe.

Any other suggestions, either For or Against would be greatly appreciated.

TIA
Rohn

PS: loosely related question. I haven't found anything in the manuals
(suggestions where to look would also be appreciated), yet, on the
following questions. We have a production DB with approx 600 TS plus
indexes and DBD LENGTH = 512816. I can easily, logically, split roughly
2/3 of the TS out into about a dozen separate DBs leaving our major
sub-application in the application with just over 200 TS in one DB. Craig
Mullins book suggests limiting DBs to about 3 dozen TS/IS. Can anyone tell
me if there are performance implications (hopefully positive) to reducing
DB and DBD size? I know about DBD locking issues, we keep tripping over
that one. I can't think of any, but are there any issues with a program
retrieving data from more than one DB in a subysystem?



Tim Lowe

Re: Merging DB2 Subsystems
(in response to Rohn.Solecki@MTS.MB.CA)
Rohn,
We are also attempting to merge our 2 production DB2 subsystems (that run
on the same lpar).

Our reasons for merging them are primarily due to applications that need to
access tables in both subsystems.
We have been copying some tables between subsystems for years to get around
this, but this is also an increasing problem as batch windows shrink and
there is more need for this.
And, we have found that the separation does not provide any benefit to us.
Also, each of our test systems is "merged", while our production systems
are separate, and this has cause major implementation problems, lending
some additional justification to merging them.

If we don't merge them, then the increased overhead of replicating data
becomes more and more of a problem. We could greatly reduce the overhead
with replication software. But the additional software and hardware cost
is impossible to justify when the problem can be solved by merging the 2
subsystems. (especially in today's political environment of "cost
cutting".) And, even with additional software, if the production systems
are kept separate, then there will be continued implemenation problems
since our test systems are merged.

I would strongly recommend that you merge your subsystems before you even
consider replicating tables. Otherwise, you may wind up where we are
today, with a lot of jcl and processes to copy tables from one subsystem to
another. And, it is a mess trying to untangle it all. In my opinion,
the sooner you "bite the bullet" and merge them the better.

In our case, each of these subsystems is also using data sharing on another
lpar. This provides us some options for availability and growth.

Thanks,
Tim Lowe
Lead Database Analyst
St. Paul Companies

P.S. Other than DBD locking problems and DBD size/EDMPOOL problems, I
can't think of any other reasons to keep DBD size down. But, isn't that
enough?



Francis C - CNF Leblanc

Re: Merging DB2 Subsystems
(in response to Tim Lowe)
Hi Rohn!

Another argument for combining the subsystems is to reduce the
systems programmer effort required to maintain multiple subsystems. We have
a dozen subsystems here, and it literally takes about 3 months to update
them all. And naturally, the bulk of this work occurs on weekends.

You might also consider taking this opportunity to at least break
out a separate bufferpool for sort work. The actual work of combining of
the 2 subsystems could also be spread out, and coincidentally done with some
bufferpool tuning. For example, since you're combining 2 subsystems, create
some new bufferpools for the table and indexes that are being moved. Define
them initially similar to the way they are currently defined. Once you have
the new bufferpools, you can then tune them as needed, almost without
management micro-managing them.

As for the unrelated question: I usually think of a database as a
logical object, and I've never had any problem with any process accessing
tables from several separate databases. I've not seen any performance
differences between 1 large DBD or multiple smaller DBDs, other than perhaps
the amount of time to initially load the DBD. Of course, there is some
logging overhead when updating the database. We have PeopleSoft HR
application installed, and multiple test databases to support it. In some
cases, the test database is implemented as installed, while in other cases,
we've broken it into multiple databases, primarily to relieve DBD lock
contention.

Good luck, whichever way you go.

Fritz

> -----Original Message-----
> From: [login to unmask email] [SMTP:[login to unmask email]
> Sent: Monday, December 17, 2001 2:05 PM
> To: [login to unmask email]
> Subject: Re: Merging DB2 Subsystems
>
> Yes we are considering it. However, I am not convinced that there really
> are any technical reasons for keeping the subsystems separate. In our
> situtation I am wondering if Data Sharing is more of a 'solution' than we
> really need (sort of like trying to stuff the engine from a Formula 1 race
> car into a Volkswagen, more horsepower than you can usefully put to the
> road <g> ).
>
>
>
>
>
> "Pearson, Eric L," <[login to unmask email]>@RYCI.COM> on 2001/12/17
> 03:18:26 PM
> Subject: Re: Merging DB2 Subsystems
>
> Have you considered yet another option - Data Sharing?
> This will allow you to do maintenance without a
> the users seeing an outage. It also offers a way to
> get rid of the duplicated data.
>
> Regards,
> eric pearson
> NS ITO Database Support
>
>
> -----Original Message-----
> From: [login to unmask email] [mailto:[login to unmask email]
> Sent: Monday, December 17, 2001 3:55 PM
> To: [login to unmask email]
> Subject: Merging DB2 Subsystems
>
>
> OS390 DB2 V6.
>
> We have a situation where we have 2 productions DB2 subsystems.
> Originally
> the second subsystem was running on a separate LPAR (for various business
> and office politics reasons, not for DB2 related reasons). Since then we
> have merged the LPARS. I have the task of identifying reasons For and
> Against merging the 2 subsystems.
>
> Current Situation:
> On one subsys we have a primarily on-line customer order system (with a
> significant batch component). On the other subsys we have the billing
> system, which is primarily batch oriented but also has a minor but
> important online component. A subset of data is replicated in both
> systems
> and passed back and forth via batch unloads/loads. There is some also
> some
> online access of data between the subsystems using dynamic SQL. Both
> subsystems are setup with virtually identical ZPARMS and not tuned at all
> (all TS/IS in BP0) due to 'office politics' (I can't convince the right
> clients that there will be no negative impacts on performance during
> tuning, and there are some senior managers who are rabidly paranoid about
> that sort of thing). When performance/response time decreases 'they' just
> buy more CPU cyles (agghhh!).
>
> I've come up with the following list of arguments For and Against:
>
> For
> - Eliminate CPU overhead for 1 DB2 subsystem (minor in overall CPU useage)
> - makes DR simpler (no need for separate subsys, we currently only DR 1
> subsys)
> - makes new development of application that access tables from both subsys
> (Is becoming more of an issue as time passes). Currently we either use
> dynmaic SQL or separate static modules to retrieve data
> - speed up data transfer/transform between the subsys (significant portion
> of batch process on both sides)
> - eliminate need for DRDA (currently planning to implement it)
>
>
> Against
> - lost opportunity for application specific tuning of subsys (but we don't
> do it anyway!)
> - maybe something in merged subsys becomes too large?
> - merge process take too long. When we first set up second subsys this
> was
> a concern because binds took too long. No longer as much of a concern, we
> now have proof that it can be done in reasonable (ie weekend) timeframe.
>
> Any other suggestions, either For or Against would be greatly appreciated.
>
> TIA
> Rohn
>
> PS: loosely related question. I haven't found anything in the manuals
> (suggestions where to look would also be appreciated), yet, on the
> following questions. We have a production DB with approx 600 TS plus
> indexes and DBD LENGTH = 512816. I can easily, logically, split roughly
> 2/3 of the TS out into about a dozen separate DBs leaving our major
> sub-application in the application with just over 200 TS in one DB. Craig
> Mullins book suggests limiting DBs to about 3 dozen TS/IS. Can anyone
> tell
> me if there are performance implications (hopefully positive) to reducing
> DB and DBD size? I know about DBD locking issues, we keep tripping over
> that one. I can't think of any, but are there any issues with a program
> retrieving data from more than one DB in a subysystem?
>
>
>
>
>



Raymond Bell

Re: Merging DB2 Subsystems
(in response to Francis C - CNF Leblanc)
Thought about suggesting data sharing but didn't, as if you've got
difficulties allocating multiple bufferpools you'll have a hard time
getting data sharing approved! But, and I apologise in advance for going
off-topic, you can never have too much horsepower. Saw a brief TV thing
last night about some German car tuning company (B&B?) that had managed to
extract 300bhp from Audi's 1.8 engine and crowbarred it into a VW Lupo!


Raymond



Rohn.Solecki@M
TS.MB.CA To: [login to unmask email]
Sent by: DB2 cc:
Data Base Subject: Re: Merging DB2 Subsystems
Discussion
List
<[login to unmask email]
M>


18/12/01 11:05
Please respond
to DB2 Data
Base
Discussion
List





Yes we are considering it. However, I am not convinced that there really
are any technical reasons for keeping the subsystems separate. In our
situtation I am wondering if Data Sharing is more of a 'solution' than we
really need (sort of like trying to stuff the engine from a Formula 1 race
car into a Volkswagen, more horsepower than you can usefully put to the
road <g> ).





"Pearson, Eric L," <[login to unmask email]>@RYCI.COM> on 2001/12/17
03:18:26 PM
Subject: Re: Merging DB2 Subsystems

Have you considered yet another option - Data Sharing?
This will allow you to do maintenance without a
the users seeing an outage. It also offers a way to
get rid of the duplicated data.

Regards,
eric pearson
NS ITO Database Support


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Monday, December 17, 2001 3:55 PM
To: [login to unmask email]
Subject: Merging DB2 Subsystems


OS390 DB2 V6.

We have a situation where we have 2 productions DB2 subsystems. Originally
the second subsystem was running on a separate LPAR (for various business
and office politics reasons, not for DB2 related reasons). Since then we
have merged the LPARS. I have the task of identifying reasons For and
Against merging the 2 subsystems.

Current Situation:
On one subsys we have a primarily on-line customer order system (with a
significant batch component). On the other subsys we have the billing
system, which is primarily batch oriented but also has a minor but
important online component. A subset of data is replicated in both systems
and passed back and forth via batch unloads/loads. There is some also some
online access of data between the subsystems using dynamic SQL. Both
subsystems are setup with virtually identical ZPARMS and not tuned at all
(all TS/IS in BP0) due to 'office politics' (I can't convince the right
clients that there will be no negative impacts on performance during
tuning, and there are some senior managers who are rabidly paranoid about
that sort of thing). When performance/response time decreases 'they' just
buy more CPU cyles (agghhh!).

I've come up with the following list of arguments For and Against:

For
- Eliminate CPU overhead for 1 DB2 subsystem (minor in overall CPU useage)
- makes DR simpler (no need for separate subsys, we currently only DR 1
subsys)
- makes new development of application that access tables from both subsys
(Is becoming more of an issue as time passes). Currently we either use
dynmaic SQL or separate static modules to retrieve data
- speed up data transfer/transform between the subsys (significant portion
of batch process on both sides)
- eliminate need for DRDA (currently planning to implement it)


Against
- lost opportunity for application specific tuning of subsys (but we don't
do it anyway!)
- maybe something in merged subsys becomes too large?
- merge process take too long. When we first set up second subsys this was
a concern because binds took too long. No longer as much of a concern, we
now have proof that it can be done in reasonable (ie weekend) timeframe.

Any other suggestions, either For or Against would be greatly appreciated.

TIA
Rohn

PS: loosely related question. I haven't found anything in the manuals
(suggestions where to look would also be appreciated), yet, on the
following questions. We have a production DB with approx 600 TS plus
indexes and DBD LENGTH = 512816. I can easily, logically, split roughly
2/3 of the TS out into about a dozen separate DBs leaving our major
sub-application in the application with just over 200 TS in one DB. Craig
Mullins book suggests limiting DBs to about 3 dozen TS/IS. Can anyone tell
me if there are performance implications (hopefully positive) to reducing
DB and DBD size? I know about DBD locking issues, we keep tripping over
that one. I can't think of any, but are there any issues with a program
retrieving data from more than one DB in a subysystem?








Mike Holmans

Re: Merging DB2 Subsystems
(in response to Raymond Bell)
This is a question which we have looked at on a couple of our production
boxes.

We've thought about how to go about doing it, and decided that it's a lot of
work to achieve it, but that it's do-able if you think it's worth it. One
set of below-the-line code is better than two. One maintenance slot to keep
software up to the required level is better than two.

On the other hand, there's all those batch jobs which include subsystem id
(and heaven knows which parameter files referred to in obscure bits of JCL
include it), and all those library names which have to be brought into line
with the new dispensation.

But what has invariably proved to be the crucial argument is what happens if
you have a serious fault in one of the applications/subsystems. Can you
stand having no access to the other application if one of them gets into
such a serious mess that you have to take the subsystem down (or it keels
over of its own accord and you have the fun of restarting it)?

Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view



>>-----Original Message-----
>>From: [login to unmask email] [mailto:[login to unmask email]
>>Sent: Monday, December 17, 2001 8:55 PM
>>To: [login to unmask email]
>>Subject: [DB2-L] Merging DB2 Subsystems
>>
>>
>>OS390 DB2 V6.
>>
>>We have a situation where we have 2 productions DB2
>>subsystems. Originally
>>the second subsystem was running on a separate LPAR (for
>>various business
>>and office politics reasons, not for DB2 related reasons).
>>Since then we
>>have merged the LPARS. I have the task of identifying reasons For and
>>Against merging the 2 subsystems.
>>
>>Current Situation:
>>On one subsys we have a primarily on-line customer order
>>system (with a
>>significant batch component). On the other subsys we have the billing
>>system, which is primarily batch oriented but also has a minor but
>>important online component. A subset of data is replicated
>>in both systems
>>and passed back and forth via batch unloads/loads. There is
>>some also some
>>online access of data between the subsystems using dynamic SQL. Both
>>subsystems are setup with virtually identical ZPARMS and not
>>tuned at all
>>(all TS/IS in BP0) due to 'office politics' (I can't convince
>>the right
>>clients that there will be no negative impacts on performance during
>>tuning, and there are some senior managers who are rabidly
>>paranoid about
>>that sort of thing). When performance/response time
>>decreases 'they' just
>>buy more CPU cyles (agghhh!).
>>
>>I've come up with the following list of arguments For and Against:
>>
>>For
>>- Eliminate CPU overhead for 1 DB2 subsystem (minor in
>>overall CPU useage)
>>- makes DR simpler (no need for separate subsys, we currently
>>only DR 1
>>subsys)
>>- makes new development of application that access tables
>>from both subsys
>>(Is becoming more of an issue as time passes). Currently we
>>either use
>>dynmaic SQL or separate static modules to retrieve data
>>- speed up data transfer/transform between the subsys
>>(significant portion
>>of batch process on both sides)
>>- eliminate need for DRDA (currently planning to implement it)
>>
>>
>>Against
>>- lost opportunity for application specific tuning of subsys
>>(but we don't
>>do it anyway!)
>>- maybe something in merged subsys becomes too large?
>>- merge process take too long. When we first set up second
>>subsys this was
>>a concern because binds took too long. No longer as much of
>>a concern, we
>>now have proof that it can be done in reasonable (ie weekend)
>>timeframe.
>>
>>Any other suggestions, either For or Against would be greatly
>>appreciated.
>>
>>TIA
>>Rohn
>>
>>PS: loosely related question. I haven't found anything in the manuals
>>(suggestions where to look would also be appreciated), yet, on the
>>following questions. We have a production DB with approx 600 TS plus
>>indexes and DBD LENGTH = 512816. I can easily, logically,
>>split roughly
>>2/3 of the TS out into about a dozen separate DBs leaving our major
>>sub-application in the application with just over 200 TS in
>>one DB. Craig
>>Mullins book suggests limiting DBs to about 3 dozen TS/IS.
>>Can anyone tell
>>me if there are performance implications (hopefully positive)
>>to reducing
>>DB and DBD size? I know about DBD locking issues, we keep
>>tripping over
>>that one. I can't think of any, but are there any issues
>>with a program
>>retrieving data from more than one DB in a subysystem?
>>
>>
>>To change your subscription options or to cancel your
>>subscription visit the DB2-L webpage at
http://www.ryci.com/db2-l. The owners of the list can be reached at
[login to unmask email]



Kirk Hampton

Re: Merging DB2 Subsystems
(in response to Mike Holmans)
Data Sharing does not seem to apply as a solution to Rohn's problem here.
Data Sharing consists of having two or more DB2 subsystems on two or more
separate LPAR's access (share) one common DB2 catalog and user tablespaces.
Rohn has only one LPAR to deal with here, and TWO separate DB2 subsystems
with TWO separate DB2 catalogs and sets of tablespaces. Data Sharing does
not
allow you to merge two existing DB2's into a Data Sharing Group. He would
have to
go throught the process of merging all his tablespaces into one of the two
subsystems, and then, if he wanted to, he could basically destroy the
second
subsystem and rebuild it as the second partner in the Data Sharing Group.
However,
going to Data Sharing with an essentially untuned DB2 setup with everything
in BP0
sounds like a recipe for disaster.

Kirk Hampton
DB2 OS/390 Sysprog
IBM Certified Solutions Expert - DB2 V7 Database Administration OS/390
TXU Energy Services
Dallas, Texas





Raymond Bell <[login to unmask email]> on 12/17/2001 05:17:08 PM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

To: [login to unmask email]
cc: (bcc: Kirk Hampton/BIZSRV/TXU)
Subject: Re: Merging DB2 Subsystems



Thought about suggesting data sharing but didn't, as if you've got
difficulties allocating multiple bufferpools you'll have a hard time
getting data sharing approved! But, and I apologise in advance for going
off-topic, you can never have too much horsepower. Saw a brief TV thing
last night about some German car tuning company (B&B?) that had managed to
extract 300bhp from Audi's 1.8 engine and crowbarred it into a VW Lupo!


Raymond



Rohn.Solecki@M
TS.MB.CA To: [login to unmask email]
Sent by: DB2 cc:
Data Base Subject: Re: Merging DB2
Subsystems
Discussion
List
<[login to unmask email]
M>


18/12/01 11:05
Please respond
to DB2 Data
Base
Discussion
List





Yes we are considering it. However, I am not convinced that there really
are any technical reasons for keeping the subsystems separate. In our
situtation I am wondering if Data Sharing is more of a 'solution' than we
really need (sort of like trying to stuff the engine from a Formula 1 race
car into a Volkswagen, more horsepower than you can usefully put to the
road <g> ).





"Pearson, Eric L," <[login to unmask email]>@RYCI.COM> on 2001/12/17
03:18:26 PM
Subject: Re: Merging DB2 Subsystems

Have you considered yet another option - Data Sharing?
This will allow you to do maintenance without a
the users seeing an outage. It also offers a way to
get rid of the duplicated data.

Regards,
eric pearson
NS ITO Database Support


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Monday, December 17, 2001 3:55 PM
To: [login to unmask email]
Subject: Merging DB2 Subsystems


OS390 DB2 V6.

We have a situation where we have 2 productions DB2 subsystems. Originally
the second subsystem was running on a separate LPAR (for various business
and office politics reasons, not for DB2 related reasons). Since then we
have merged the LPARS. I have the task of identifying reasons For and
Against merging the 2 subsystems.

Current Situation:
On one subsys we have a primarily on-line customer order system (with a
significant batch component). On the other subsys we have the billing
system, which is primarily batch oriented but also has a minor but
important online component. A subset of data is replicated in both systems
and passed back and forth via batch unloads/loads. There is some also some
online access of data between the subsystems using dynamic SQL. Both
subsystems are setup with virtually identical ZPARMS and not tuned at all
(all TS/IS in BP0) due to 'office politics' (I can't convince the right
clients that there will be no negative impacts on performance during
tuning, and there are some senior managers who are rabidly paranoid about
that sort of thing). When performance/response time decreases 'they' just
buy more CPU cyles (agghhh!).

I've come up with the following list of arguments For and Against:

For
- Eliminate CPU overhead for 1 DB2 subsystem (minor in overall CPU useage)
- makes DR simpler (no need for separate subsys, we currently only DR 1
subsys)
- makes new development of application that access tables from both subsys
(Is becoming more of an issue as time passes). Currently we either use
dynmaic SQL or separate static modules to retrieve data
- speed up data transfer/transform between the subsys (significant portion
of batch process on both sides)
- eliminate need for DRDA (currently planning to implement it)


Against
- lost opportunity for application specific tuning of subsys (but we don't
do it anyway!)
- maybe something in merged subsys becomes too large?
- merge process take too long. When we first set up second subsys this was
a concern because binds took too long. No longer as much of a concern, we
now have proof that it can be done in reasonable (ie weekend) timeframe.

Any other suggestions, either For or Against would be greatly appreciated.

TIA
Rohn

PS: loosely related question. I haven't found anything in the manuals
(suggestions where to look would also be appreciated), yet, on the
following questions. We have a production DB with approx 600 TS plus
indexes and DBD LENGTH = 512816. I can easily, logically, split roughly
2/3 of the TS out into about a dozen separate DBs leaving our major
sub-application in the application with just over 200 TS in one DB. Craig
Mullins book suggests limiting DBs to about 3 dozen TS/IS. Can anyone tell
me if there are performance implications (hopefully positive) to reducing
DB and DBD size? I know about DBD locking issues, we keep tripping over
that one. I can't think of any, but are there any issues with a program
retrieving data from more than one DB in a subysystem?