DB2 and SMS

Ford Wong

DB2 and SMS
Dear Fellow Listers.

Our shops is finally thinking about going completely to DB2 and SMS. All our development databases stogroups have been SMS where SMS is controlled by our systems people (who add volumes when we need them). We are thinking about going SMS for our Productions Systems and having control by our DBA group. In the past we have had problems with getting enough space when we needed it and that is why we stayed away from SMS in our Production systems.

Here are some specific questions which we have?

1. Can any one point me to where I can find information about DB2 and SMS? (Red Books, Good Practices, etc). How to set up, etc.

2. If our stogroups are SMS managed, how does SMS ensure that there is enough space to run online reorgs of VERY VERY large tablespaces, etc? Doesn't SMS spread DASD usage evenly through all diskpacks it the stogroup which leaves lots of small pieces of free storage?

3. How does SMS ensure that there is enough contiguous space available when you need to load a VERY large tablespace?

4. If anyone is willing to share information, I would be interested in finding out how you have implemented DB2 and SMS in your shop, how much DASD (including spares) are needed, etc.
Information about how much DASD is needed to support SMS would also be useful.

5. Who handles the administration of the SMS Groups. At our shop the systems people do it. If the DBAs were to do it how is this done? What are their responsibilities and duties.

6. Any tips and words of advice are VERY welcome.

We are currently running DB2 V8.1 (and will someday be going to V9.1).

If you like to contact me, I can be reached at (780) 420-3975. My email is [login to unmask email]

Although I have worked with SMS, I have not with DB2, so I am sorry if my questions seem naive.

Thanks In Advance,

Ford

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/events/index.html is your DB2 Events calendar! RUG meetings,
Webcasts, Conferences- what is going on next?
RUG leaders- get your events on the calendar today!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Neil Duffee

Re: DB2 and SMS
(in response to Ford Wong)
Ford : I'm a recent lurker to the list but haven't seen a response yet
so thought I'd add my local experience. I'm with the Storage Admin
group and not a DBA. We're a very small shop compared to others. (150
3390-3s for *all* sub-system table/index spaces)

There is a Redbook "Storage Management with DB2..." SG24-5462 (1999) but
you might search for something more up-to-date.

You don't mention how the development environment is set up but my first
bit of advice is 'No micro-management'. Unless you have solid - mostly
performance related - reasons, all the old DB2 StoGroups should be
dropped into a single SMS StorGrp. In fact, we only have 3 StorGrps :
Validation/Verification/System Install (3 subsys), Application
Development (3 subsys : Dev, QA, UserQA), and Warehouse (special
reporting only subsys), despite the pre-existing (and still active, by
the way) 15+ StoGroups in each. (I discovered that the StoGroup
requests are ignored by SMS and DB2 didn't even notice.)

2nd advice is Quiesced volumes and Overflow StorGrp. Each StorGrp
should have 1 (or more) volumes in Quiesce,New status that allows for
spillage within the group. It allows for your big re-orgs and a single
point to watch for decreasing space availability. If it gets used
continually, you need to add more volume(s) to the group. Anticipating
problems with contiguous space? Vary SMS,Quiesce,New a few volumes then
re-org the tablespaces off them. (Remember, they're not disabled from
use but selected in the 2nd round.) Your environment should also have
an Overflow StorGrp that acts in the same manner but for all other
StorGrps. Again, if something appears there, there's a space problem.

A common misconception is that SMS manages the StorGrps. HSM (and
related competitors) is used to manage existing data ie. Interval
Management. In fact, SMS (through the ACS routines) is *only* involved
at dataset creation time at which point it will choose the best target
among what is currently available. There were problems in previous
releases concerning its tendency to spread everything out but I believe
(from chatter I've heard on IBM-Main) that more recent algorithms try to
obtain a balanced approach. We haven't needed to bother about it here.

Local environment (all 3390-3) : DB2VALID storGrp - 10 volumes, 1
quiesced; DB2APPDEV - 49 vol, 2 quiesced; DB2W - 22 vol, 2 quiesced;
DB2P (non-SMS) - 61 vol, 7 empty, SPILL (public overflow storGrp) - 10
vol. I'm betting that with DB2P under SMS we'll only need 52-53
volumes.

My DBAs have liked the switch so far since they spend zero time managing
the StoGroup volumes anymore. I watch the quiesced and overflow volumes
for activity (daily report) and, when warranted, will add/subtract a
volume. We use FDR/ABR here so I have a daily job that will even
attempt, as part of the report process, to move the datasets off the
'spill' volumes. ('course, if it's open to DB2, that can't happen so my
weekly report e-mails the DBAs to "please re-org these"; 3 in the last
6 months.) For DB2, most of these table/index spaces are the result of
a re-org finding insufficient target space.

We'd also like to manage production but I'm not sure about how to
accomplish deliberate placements for performance reasons. I'd like to
be able to re-org these special dsn without manual intervention but am
not sure, yet, how to achieve that. (Actually, you'll see me making an
inquiry to the list, soon, asking about how others achieve it.)



----------> signature = 6 lines follows <--------------
Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee
"How *do* you plan for something like that?" Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent" John Norgauer 2004


________________________________

From: Ford Wong [mailto:[login to unmask email]
Sent: January 25, 2010 16:35
Subject: DB2 and SMS


Our shops is finally thinking about going completely to DB2 and
SMS. All our development databases stogroups have been SMS where SMS
is controlled by our systems people (who add volumes when we need them).
We are thinking about going SMS for our Productions Systems and having
control by our DBA group. In the past we have had problems with
getting enough space when we needed it and that is why we stayed away
from SMS in our Production systems.

Here are some specific questions which we have?
1. [snip] information about DB2 and SMS? [snip]
2. [snip] how does SMS ensure that there is enough space
[snip] usage evenly [snip]
3. How does SMS ensure that there is enough contiguous space
[snip]


_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Max Scarpa

Re: DB2 and SMS
(in response to Neil Duffee)
Hi Ford

It's a wide topic, so don't think this post is an answer. I put only some
hints from the trenches where I lived for some years, wearing my helmet
and some other protections for other parts of my miserable body.

1) Some papers:

- Disk storage access with DB2 for z/OS by Paolo Bruni and John
Iczkovits, 2006 (Redbookspaper)
- DB2 and Storage Management, a Guide to Surviving a Perfect Marriage
by John Iczkovits various SHARE proceedings 2007,2008
(highly recommended).
- I/O performance and DB2 for z/OS by Cristian Molaro, IDUG EU 2007

- Ready to Access DB2 for z/OS Data on Solid State Drives by Paolo
Bruni, Jeffrey Berger RedBooks redpaper, 2009
- Storage Management with DB2 for OS/390 by Paolo Bruni, Hans Duerr,
Daniel Leplaideur, Steve Wintle 1999 - pretty old but with useful
informations
-How does the MIDAW facility improve the performance of FICON channels
By Paolo Bruni Jeffrey Berger (about DB2, SMS and MIDAW)
using DB2 and other workloads?

- zCDP for DB2 by Glenn Wilcock, SHARE 2007 (about data protection &
DB2)
- SMS Volume Selection By Ruth Ferziger (SHARE 2005 but probably
there are more recent version in SHARE proceedings)
- Re-Inventing SMS: Same Dog, New Tricks By Sherman Sidwell
share 2006
- Getting Started with SMS Ruth Ferziger various share proceedings
- More paper about SMS in SHARE proceedings and redbooks (search DFSMS).

2) In last SMS versions you may have a huge amount of extents to
accomodate space, but you can manage dasd space using SMS DATACLASS
options. Then there are other non-SMS options to manage space shortage as
using some automation tools like BMC Autooperator or equivalent tool: for
instance you can add volumes when pool free space drop below a given %,
or add volumes when you start reorg flow etc. ('dynamic non-SMS space
shortage management').
At the very end there are some SMS option (like GUARANTEED SPACE, SPILL
volumes if I remember well) and non-SMS procedure (automation) to control
DASD space, but it depends on your organization etc. For example in a
previous shop we use spare disks (i.e. disks still unassigned to any pool,
every shop generally has spare disks) to allocate DB2 utilities 'temp'
files (reorg,load...).
But we could do it because we have some prod 'standards' for spare disks.
It's a very 'wide' topic and it has to be 'taylored' on your prod
environment. See SHARE procediings for some SMS papers.

3) As above, SMS has some options to relief space shortage. DEFRAG is an
option but not always it's possible.

4) It depends: I worked in shops where DB2 pool was >> 2 x (space
allocated by tablespace), other where it was 1.2. Not all shops have (or
don't want to spend) money for a bunch of DASD. Having a huge amount of
space means more channels, powerful control units with very high internal
throughput ecc. as well so more expensive machines.
Personally I used in the past to have al least enough free space to
allocate shadow copies of the 'n' (in my case it was n=10) biggest prod
tablespace as if they had to be be reorganized in parallel ('maximum
bearing capacity', evaluated considering your CPU power, DASD I/O, elaps
time of reorgs, batch window etc. Usually normal reorg 'load' is lower).
In all shops I worked we had 2 DB2 pools, one for TSs one for IXs, but
it's not mandatory of course. I prefere 2 pools so during reorgs TSs and
IXs do not interfere, you can manage datasets better etc.

5) System people should manange storage, dot. DBA *could at most* add
volumes if requested. SMS and storage in general request a deep knowledge
of many things and IT'S BETTER to keep your hands away from modifying an
ACS routine if you haven't a knowledge of SMS and of your company's
standards (involving RACF as well, in some cases).

6) It depends.....but it's better to ask tips when you've a particular
problem.

I'm sure other listers will add more and more to these simple hints, it's
only a very very basic starting point . There's no definitive answer of
course. Let me know if you've more specific requests.

HTH

Max Scarpa

Certified spare DB2 sysprog (In an emergency break the glas)
Certfied SB-37 DB2 sysprog
Certified DB2 watchdog (bite ISO 9001 certified)

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/rug/index.html - with almost 150 IDUG Regional User Groups,
there is probably one near you!
Regional User Groups are your local connection to the Worldwide DB2 User Community
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Ted MacNEIL

Re: DB2 and SMS
(in response to Max Scarpa)
>In all shops I worked we had 2 DB2 pools, one for TSs one for IXs, but it's not mandatory of course. I prefere 2 pools so during reorgs TSs and IXs do not interfere,  you can manage datasets better etc.


I think you are suffering from an old-style belief.
Putting index and table space in the same pool (if SMS-Managed: Storage Group), with today's DASD, does not cause interference, nor does it make a bit of difference as to managing DASD.

I've hear this from a lot of DBA's over the years.
As you say, later in your post, DBA's should not be managing DASD.
It should be left up to your Storage Admins.
As long as you don't run out of space, and you don't have 'interference', then it should not matter to a DBA how many Storage Groups there are, and what is put into each of them.

IBM no longer recommends splittin index & table space into separate groups.
As of the DS8xxx series of DASD, along with newer/faster FICON channels, they recommend the opposite.

The whole purpose of SMS is to remove the 'worrying' about dataset management/placement from individuals/departments and centralising it to one group that can manage it as a whole, and ensure a consistent company-wide policy which takes cost, recovery and business goals into account.

If your Storage Admins are not doing that it's time to review:
a. education/training
or:
b. exit strategies.

-
Too busy driving to stop for gas!

Bayard Tysor

Re: DB2 and SMS
(in response to Ted MacNEIL)
Hi Neil,

Great advice. I worked with the Storage Admin group to set up a similar
approach some ten years ago and it was fantastic. Us DBAs spent zero time
worrying about adequate storage or placement.

One thing that I would like to suggest is to separate index spaces from
table spaces. We initially made a mistake by putting that separation in the
DFSMS rules based on our naming standards. Then we brought in a purchased
system which had different naming rules. We then decided to have two
STOGROUPS, and the DBAs the could specify one STOGROUP for indexes and
another for tablespaces.

Tink

On Tue, Feb 2, 2010 at 6:36 PM, Neil Duffee <[login to unmask email]> wrote:

> Ford : I'm a recent lurker to the list but haven't seen a response yet so
> thought I'd add my local experience. I'm with the Storage Admin group and
> not a DBA. We're a very small shop compared to others. (150 3390-3s for
> *all* sub-system table/index spaces)
>
> There is a Redbook "Storage Management with DB2..." SG24-5462 (1999) but
> you might search for something more up-to-date.
>
> You don't mention how the development environment is set up but my first
> bit of advice is 'No micro-management'. Unless you have solid -
> mostly performance related - reasons, all the old DB2 StoGroups should be
> dropped into a single SMS StorGrp. In fact, we only have 3 StorGrps :
> Validation/Verification/System Install (3 subsys), Application Development
> (3 subsys : Dev, QA, UserQA), and Warehouse (special reporting only subsys),
> despite the pre-existing (and still active, by the way) 15+ StoGroups in
> each. (I discovered that the StoGroup requests are ignored by SMS and DB2
> didn't even notice.)
>
> 2nd advice is Quiesced volumes and Overflow StorGrp. Each StorGrp should
> have 1 (or more) volumes in Quiesce,New status that allows for spillage
> within the group. It allows for your big re-orgs and a single point to
> watch for decreasing space availability. If it gets used continually, you
> need to add more volume(s) to the group. Anticipating problems with
> contiguous space? Vary SMS,Quiesce,New a few volumes then re-org the
> tablespaces off them. (Remember, they're not disabled from use but selected
> in the 2nd round.) Your environment should also have an Overflow StorGrp
> that acts in the same manner but for all other StorGrps. Again, if
> something appears there, there's a space problem.
>
> A common misconception is that SMS manages the StorGrps. HSM (and related
> competitors) is used to manage existing data ie. Interval Management. In
> fact, SMS (through the ACS routines) is *only* involved at dataset creation
> time at which point it will choose the best target among what is currently
> available. There were problems in previous releases concerning its tendency
> to spread everything out but I believe (from chatter I've heard on IBM-Main)
> that more recent algorithms try to obtain a balanced approach. We haven't
> needed to bother about it here.
>
> Local environment (all 3390-3) : DB2VALID storGrp - 10 volumes, 1 quiesced;
> DB2APPDEV - 49 vol, 2 quiesced; DB2W - 22 vol, 2 quiesced; DB2P (non-SMS) -
> 61 vol, 7 empty, SPILL (public overflow storGrp) - 10 vol. I'm betting that
> with DB2P under SMS we'll only need 52-53 volumes.
>
> My DBAs have liked the switch so far since they spend zero time managing
> the StoGroup volumes anymore. I watch the quiesced and overflow volumes for
> activity (daily report) and, when warranted, will add/subtract a volume. We
> use FDR/ABR here so I have a daily job that will even attempt, as part of
> the report process, to move the datasets off the 'spill' volumes. ('course,
> if it's open to DB2, that can't happen so my weekly report e-mails the DBAs
> to "please re-org these"; 3 in the last 6 months.) For DB2, most of these
> table/index spaces are the result of a re-org finding insufficient target
> space.
>
> We'd also like to manage production but I'm not sure about how to
> accomplish deliberate placements for performance reasons. I'd like to be
> able to re-org these special dsn without manual intervention but am not
> sure, yet, how to achieve that. (Actually, you'll see me making an inquiry
> to the list, soon, asking about how others achieve it.)
>
> ----------> signature = 6 lines follows <--------------
> Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
> telephone:1 613 562 5800 x4585 fax:1 613 562 5161
> mailto:NDuffee <NDuffee> of uOttawa.ca http:/ /aix1.uottawa.ca/~nduffee
> "How *do* you plan for something like that?" Guardian Bob, Reboot
> "For every action, there is an equal and opposite criticism."
> "Systems Programming: Guilty, until proven innocent" John Norgauer 2004
>
> ------------------------------
> *From:* Ford Wong [mailto:[login to unmask email]
> *Sent:* January 25, 2010 16:35
> *Subject:* DB2 and SMS
>
> Our shops is finally thinking about going completely to DB2 and SMS.
> All our development databases stogroups have been SMS where SMS is
> controlled by our systems people (who add volumes when we need them). We
> are thinking about going SMS for our Productions Systems and having control
> by our DBA group. In the past we have had problems with getting enough
> space when we needed it and that is why we stayed away from SMS in our
> Production systems.
>
> Here are some specific questions which we have?
> 1. [snip] information about DB2 and SMS? [snip]
> 2. [snip] how does SMS ensure that there is enough space [snip] usage
> evenly [snip]
> 3. How does SMS ensure that there is enough contiguous space [snip]
>
>
> ------------------------------
>
> [image: IDUG - The Worldwide DB2 User Community! ] < http://www.idug.org/db2-north-america-conference/index.html >
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
> not already an IDUG member, please register here. < http://www.idug.org/register >
>



--
B.L. "Tink" Tysor
Bayard Lee Tysor, Inc.
[login to unmask email]
401-965-2688

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/rug/index.html - with almost 150 IDUG Regional User Groups,
there is probably one near you!
Regional User Groups are your local connection to the Worldwide DB2 User Community
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Max Scarpa

Re: DB2 and SMS
(in response to Bayard Tysor)
As past DASD manager I knew since many years that dataset placement with
modern DASD is 'trasparent' to z/OS even if there are some situations
where it still matters (see for instance J. Goldstein, various papers;
Steve Thomas, IDUG 2009) . And I noticed in the past there were problems
even in modern DASD (see Beretvas' papers), but with WLM options and PAV
(or equivalent) you could avoid many problematic situations.

2 SGs policy isn't suggested for performance reasons, but because as a DB2
DBA/Sysprog I know (expecially in big companies) DASD managers and DB2
folks often don't communicate very well.

I saw many time reorgs (but even LOADs) 'interfering': DASD managers
usually are asked to satisfy space requests for tablespaces+indexes and
these requests are based on a forecasted growth. usually considered linear
but very often with spikes (or even explosive growth). Storage pools have
enough space to accomodate spikes and space request due to online reogs
for that TSs/IXs. Often, due to application(s) improvements, new indexes
are requested and for big tablespace you could have quite big NPIs/DPSIs
as well. Nowadays most of reorgs are automated via REXXs, 3rd party tools
(CA DB Analyzer for instance), etc and it could happen (and happened) that
you're executing reorgs for many big tablespace and their indexes in
parallel. In that case it could happen you've not enough space for all
shadow copies. And if you have some LOBs (now there's online reorg for
them) the risk is higher because LOBs in many cases are quite big.

Using 2 storage pools limits 'space interference' , increase what I call
'maximum bearing capacity' for reorgs in a given system (considering
space,CPU available, batch window, etc) ,you can use less free space per
SG, it's a better long-term guarantee (it's a somewhat a implicit
'safety'), expecially at the end of the year, when workload in some
companies increases (for instance in banks) and you've few spare DASDs
available, waiting managers' approval for a new array (plus the time
from the order to installation). Usually there's no problem for DR as
modern disks are mirrored/replicated as a whole machine at recovery site
so it doesn't matter if you have 1 or 2 SG for DB2. Work requested to
modify ACS routine is minimal if you have good standard for names (not
always, in the last company I worked we hadn't).

It simplify reports making them more precise expecially if your boss (and
apps managers) asks every 5 minutes reports about space allocated/used by
TSs and/or indexes. In the same time you can use SMS features for space
shortage as further safety. It could (but never tested) help with new V8
sliding sec. quantity feature . In test indexes can be migrated if not
used, and if you're recalling TSs and IXs (or migrated index(es)) there's
less 'fight' among TS and its indexes to allocate space if they belong to
a unique SG. It's a common observation in test you can recall TS and not
all indexes (or indexes without the relative tablespace), even if your
data is a sample of real prod data.

From my personal experience space shortage happens in the worst periods of
prod cycle (nights, weekends,holidays) and simply adding DASDs sometimes
isn't enough. Of course YMMV.

Max Scarpa





Ted MacNEIL <[login to unmask email]>
Sent by: IDUG DB2-L <[login to unmask email]>
03/02/2010 09.45
Please respond to
IDUG DB2-L <[login to unmask email]>


To
[login to unmask email]
cc

Subject
Re: [DB2-L] DB2 and SMS






>In all shops I worked we had 2 DB2 pools, one for TSs one for IXs, but
it's not mandatory of course. I prefere 2 pools so during reorgs TSs and
IXs do not interfere, you can manage datasets better etc.


I think you are suffering from an old-style belief.
Putting index and table space in the same pool (if SMS-Managed: Storage
Group), with today's DASD, does not cause interference, nor does it make a
bit of difference as to managing DASD.

I've hear this from a lot of DBA's over the years.
As you say, later in your post, DBA's should not be managing DASD.
It should be left up to your Storage Admins.
As long as you don't run out of space, and you don't have 'interference',
then it should not matter to a DBA how many Storage Groups there are, and
what is put into each of them.

IBM no longer recommends splittin index & table space into separate
groups.
As of the DS8xxx series of DASD, along with newer/faster FICON channels,
they recommend the opposite.

The whole purpose of SMS is to remove the 'worrying' about dataset
management/placement from individuals/departments and centralising it to
one group that can manage it as a whole, and ensure a consistent
company-wide policy which takes cost, recovery and business goals into
account.

If your Storage Admins are not doing that it's time to review:
a. education/training
or:
b. exit strategies.

-
Too busy driving to stop for gas!

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/rug/index.html - with almost 150 IDUG Regional User Groups,
there is probably one near you!
Regional User Groups are your local connection to the Worldwide DB2 User Community
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Ted MacNEIL

Re: DB2 and SMS
(in response to Max Scarpa)
>Us DBAs spent zero time worrying about adequate storage or placement.
 
>One thing that I would like to suggest is to separate index spaces from table spaces

If you are spending zero time worrying about adequate storage or placement, why are you concerned about separate index/table spaces?

I've mentioned this before: modern DASD does not require this, especially with the newer/faster FICON channels.

IBM has recommended to no longer split the space types, since the release of the DS8xxx series DASD family.

Chances are, unless you are a huge shop, you are going to have everything on one or two controllers.
And, logical separation of data does not guarantee physical separation, due to the way RAID works.

Also, SMS works better with fewer Storage Groups.

Since you are not a Storage Admin, and are a DBA, you should leave all placement concerns up to the Space Cadets.

As long as you have no space related abends, reliable back-ups & recovery, and meet performance levels, the implementation details are irrelevant.

-
Too busy driving to stop for gas!

Ted MacNEIL

Re: DB2 and SMS
(in response to Ted MacNEIL)
>Using 2 storage pools limits 'space interference' , increase what I call 'maximum bearing capacity' for reorgs in a given system (considering space,CPU available,  batch window, etc) ,you can use less free space per SG, it's a better long-term guarantee (it's a somewhat a implicit 'safety'),

I disagree.
If you 'collapse' the storage groups without removing any DASD, it's the same thing.



>expecially at the end of the year, when workload in some companies increases (for instance in banks) and you've few spare DASDs available,

That's NOT a split table and index issue.
It's an issue of acquisition and configuration management.



>waiting managers' approval  for a new array (plus the time from the order to installation).

That's what capacity planning is for.

(Remember what I said about reviewing exit strategies?)
-
Too busy driving to stop for gas!