DB2 and SMS, one large pool or a few medium pools

Jim Lazowski

DB2 and SMS, one large pool or a few medium pools
Hello,
I'm currently living with an old SMS set up that contains multiple pools such
that the datasets are allocated to the pools based on size: SM,MED,LRG & XL
(where the pools are all 3390 mod3's except the XL pool which consists of
Mod9's).

The intention of this method is to prevent fragmentation, however, you never
know if a table will be expanding beyond its original intended size and moving
the tablespace to match the pool after it grows is unproductive.

What I'm looking for how other shops set up their SMS pools for DB2
application data. Does one large pool work and are there any problems doing
it this way? If we go with a single pool of all Mod 9's how will it perform? Will
there be fragmentation in a one pool environment that will cause us allocation
failures? Should we split the Mod9's and Mod3's into 2 separate large pools
rather than mix them?

Please share your stories and experiences.

Thanks for your help!
Jim

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Lizette Koehler

Re: DB2 and SMS, one large pool or a few medium pools
(in response to Jim Lazowski)
Jim,

It Depends.

In our shop we actually setup separate pools based on the DB2 Application and Region. I use to like one pool fits all, but now I am leaning towards the new direction which is one pool one DB2 Application or Subsystem. This is due to the new way IBM and other vendors are looking towards Cloning DB2 Subsystems and/or DB2 applications, and Disaster Recovery processes.

I will leave it to others to discuss Mod3 vs Mod9. But as soon as I can, I will have MOD9s for everything. They perform fine. Now MOD27s or MOD54s could be another story.


Lizette


-----Original Message-----
>From: Jim Lazowski <[login to unmask email]>
>Sent: Dec 17, 2007 9:27 AM
>To: [login to unmask email]
>Subject: [DB2-L] DB2 and SMS, one large pool or a few medium pools
>
>Hello,
>I'm currently living with an old SMS set up that contains multiple pools such
>that the datasets are allocated to the pools based on size: SM,MED,LRG & XL
>(where the pools are all 3390 mod3's except the XL pool which consists of
>Mod9's).
>
>The intention of this method is to prevent fragmentation, however, you never
>know if a table will be expanding beyond its original intended size and moving
>the tablespace to match the pool after it grows is unproductive.
>
>What I'm looking for how other shops set up their SMS pools for DB2
>application data. Does one large pool work and are there any problems doing
>it this way? If we go with a single pool of all Mod 9's how will it perform? Will
>there be fragmentation in a one pool environment that will cause us allocation
>failures? Should we split the Mod9's and Mod3's into 2 separate large pools
>rather than mix them?
>
>Please share your stories and experiences.
>
>Thanks for your help!
>Jim
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Tom Moulder

Re: DB2 and SMS, one large pool or a few medium pools
(in response to Lizette Koehler)
All

I'll weigh in on the factors affecting the choice of 3390 model size.

If you have HYPERPAV installed and your disk array vendor supports it, then
I suggest that you use the largest model size supported. There are a number
of reasons why. HYPERPAV support will virtually eliminate queuing at the
device level. The largest models will allow you to reduce the number of
base UCB addresses required. HYPERPAV will also allow you to specify one
pool of alias UCB addresses and make much more efficient use of those
aliases so that you can reduce the number of aliases by at least half. All
of this is extremely important to large systems that are even close to the
64K device limit in z/OS.

Tom Moulder


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Lizette Koehler
Sent: Tuesday, December 18, 2007 12:35 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 and SMS, one large pool or a few medium pools

Jim,

It Depends.

In our shop we actually setup separate pools based on the DB2 Application
and Region. I use to like one pool fits all, but now I am leaning towards
the new direction which is one pool one DB2 Application or Subsystem. This
is due to the new way IBM and other vendors are looking towards Cloning DB2
Subsystems and/or DB2 applications, and Disaster Recovery processes.

I will leave it to others to discuss Mod3 vs Mod9. But as soon as I can, I
will have MOD9s for everything. They perform fine. Now MOD27s or MOD54s
could be another story.


Lizette


-----Original Message-----
>From: Jim Lazowski <[login to unmask email]>
>Sent: Dec 17, 2007 9:27 AM
>To: [login to unmask email]
>Subject: [DB2-L] DB2 and SMS, one large pool or a few medium pools
>
>Hello,
>I'm currently living with an old SMS set up that contains multiple pools
such
>that the datasets are allocated to the pools based on size: SM,MED,LRG & XL

>(where the pools are all 3390 mod3's except the XL pool which consists of
>Mod9's).
>
>The intention of this method is to prevent fragmentation, however, you
never
>know if a table will be expanding beyond its original intended size and
moving
>the tablespace to match the pool after it grows is unproductive.
>
>What I'm looking for how other shops set up their SMS pools for DB2
>application data. Does one large pool work and are there any problems
doing
>it this way? If we go with a single pool of all Mod 9's how will it
perform? Will
>there be fragmentation in a one pool environment that will cause us
allocation
>failures? Should we split the Mod9’s and Mod3’s into 2 separate large
pools
>rather than mix them?
>
>Please share your stories and experiences.
>
>Thanks for your help!
>Jim
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site, you
can also access the IDUG Online Learning Center, Tech Library and Code
Place, see the latest IDUG conference information, and much more. If you
have not yet signed up for Basic Membership in IDUG, available at no cost,
click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list
archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under the Listserv tab. While at the site, you
can also access the IDUG Online Learning Center, Tech Library and Code
Place, see the latest IDUG conference information, and much more. If you
have not yet signed up for Basic Membership in IDUG, available at no cost,
click on Member Services at http://www.idug.org/lsms



--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date: 12/17/2007
2:13 PM


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date: 12/17/2007
2:13 PM


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date: 12/17/2007
2:13 PM


The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Jim Lazowski

Re: DB2 and SMS, one large pool or a few medium pools
(in response to Tom Moulder)
Our devices have 3 PAV's per device. I'd like to go to dynamic PAV's which
sounds like the HYPERPAV's, but it may not happen for a while. Sounds like
mod3's would be better for us unless we limit the number of datasets to the
mod9's.

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Jim Lazowski

Re: DB2 and SMS, one large pool or a few medium pools
(in response to Jim Lazowski)
Lizette,
Thank you for your reply!
You mention having single pools for subsystems and maybe some applications
split out. What factors influence your decision to split something out into it's
own pool?

Jim

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms