Merging DB2 Subsystems and Happy Xmas!

Phil Grainger

Merging DB2 Subsystems and Happy Xmas!
As it's Christmas, just one more product plug (and perhaps my last of the

RC/Merger from CA is designed to enable you to merge two DB2 catalogs
without the pain of dropping and recreating the data.

To cut a long story short, it's like an RC/Migrator migration, BUT instead
of unloading/reloading the data, the VSAM clusters are copied/renamed
instead. RC/Migrator also looks after any potential "object collisions"
(where objects from different subsystems may have the same DBID, OBID, PSID

More details, contact me off the list etc etc etc

(PS Happy Christmas to one and all on the list)

Phil Grainger
Computer Associates
Product Manager, DB2
Tel: +44 (0)161 928 9334
Fax: +44 (0)161 941 3775
Mobile: +44 (0)7970 125 752
[login to unmask email]

Roger Miller

Re: Merging DB2 Subsystems
(in response to Phil Grainger)
I wrote an article some time ago on what must be separated, and think the
key to management and performance is often not separating anything that does
not need to be separated. Merging is not a simple process, and perhaps you
can check through some of these.

Roger Miller, DB2 for z/OS

Why can't we share?

The web, warehousing and data sharing add new twists to several old
questions, like merging of subsystems.
As we install data sharing and new applications, we often
need to answer questions like ...

Can this application be put into the existing subsystem?
Can several subsystems be merged into a single group?
Does the web mean a separate data sharing group?

The underlying question is "When can applications coexist in
a single subsystem or data sharing group?" What resources
can we share and which ones must be separate? We can make
our decisions on many different resources: processor time,
memory, locks, data, and IO. We also have to understand
some logical resources like the subsystem parameters, log,
catalog and directory.

Some changes in recent DB2 releases make coexistence in one group
easier. Some of the old rules can be broken much more easily
if you are running DB2 Version 6 or 7. Within a single DB2 subsystem,
we can have separate data. Separate data means that locking
is separate for the most part. If the databases and user ids
differ, then we can avoid catalog contention. Separate
buffer pools can keep one set of users from interfering with
data that is cached, other than for the catalog, directory,
and work files.

What do we have to share? Applications within a subsystem or
data sharing group must share the subsystem catalog and directory,
the log, the BSDS, and the EDMPOOL. Each subsystem has a
separate set of work files for all users. The data definitions
and authorization must be able to share a single name space.
Applications which will not follow naming rules cannot
coexist with others. If the resources and priorities are not
acceptable and resources are in short supply, then applications
will not be happy - regardless of separation or being together.
If the work load needs more processor time than we have, then
the contention can force separation even though it is more
efficient to share. If the peak work loads are at different
times, then both can get more from sharing. Data sharing lets
us share the work load across multiple machines.

A common misconception is that data sharing should drive
merging of subsystems. Most of the reasons why subsystems
were separated still apply. If the old reasons have gone away,
that is independent of data sharing. If you are considering
merging, then be sure that the subsystems have consistent
approaches to
- Naming conventions for users, plans, packages, databases,
tables, indexes, view, ...
- Authorization techniques
- Backup and recovery conventions
- Availability practices

The key attributes which require separation are

1) Availability

Applications which have high service level agreements for
availability must be tightly controlled. Applications without
tight controls can compromise the entire subsystem or group.
Failure to commit is the classic example. A simple error
or choice on the part of one programmer can cause a very long
restart or cold start for all.

The shared log data will elongate recovery times if applications
are combined in a subsystem or group. If applications are not
careful about log volume, they can compromise the recovery times
for other applications.

Applications that are not careful with EDMPOOL space can cause
exhaustion or poor performance for all. The need to run MODIFY
to keep the DBD sizes small is one example.

Applications which need to change data definitions frequently
can interfere with other access to the catalog data.
Catalog and directory locking can cause a problem. This is
getting to be less of a problem for dynamic SQL with changes
in V5. Applications with high availability must control
data definition changes and libraries very carefully.
A mix of controls is generally not workable.

2) Security: As I mentioned earlier, there is only one name
space. Applications which want their own convention for
names or demand many SYSADM users generally cannot coexist.
Some basic agreements are required.

Applications with stringent security needs will have
controls that can be unacceptable in time for people and
for processors in other applications. Security is generally
more narrowly granted, and audit controls are required.
While the production group for insurance or banking generally
has assigned auditors and security staff, there are no
similar resources for development systems or information

3) Performance: Applications can cause some mischief, but
most problems are about resources: processor time, storage,
IO, locks. If you must share, then it's easy to
encounter problems. Sharing is generally more effective
use of resources, but it does add possibilities for
one application to impact another.

CPU time is managed very well by the MVS dispatcher
or Work Load Manager (WLM). Distributed work and stored
procedures can be controlled and prioritized by the WLM.
DB2 uses the agent address space for the majority
of processing, so the MVS priority is used.

IO contention can occur if we share the same disk
and tape units. There can be some smaller effects
if we share the same address space and asynchronous
read / write engines. The LOGLOAD interval and
buffer pool write thresholds may need to be adjusted.

In one or two situations, customers have combined
subsystems and exceeded the concurrent data
set limit. Check limits when combining.

Main storage is more effective if you can share.
You probably need an extra 30 to 50 megabytes of central
storage for separate subsystems. Separate pools are
not as efficient, and multiple sets of code are loaded.
At very high work loads, storage limits could lead to
the need for separate subsystems. Check the storage
sizes with the IDUG Solutions Journal article.

Locks and latches can be issues, but they are more
ones of control and availability than of performance.
Within a single subsystem, you can separate the data
if you need to. That separates the locks. You can
have separate buffer pools, other than the work file
buffer pool and catalog pool. Separate sets of
authorization ids, plans, packages, and databases
provide the primary separation. You can also allow
Uncommitted Read access to data, so that locks are
not held or checked. The users need to understand that
the data is not consistent in this case.

The bottom line is that the people need to be able
to work together, to have some flexibility and to
trust each other. If they can't, then they
probably need to be separate. If they can, then they
can share resources for better efficiency.