Forums & Discussions Home

    A place for members, communities, and committees to have discussions online and via e-mail.
    Click a category or topic to below to start the conversation...

    You are currently in view only mode for this forum. Please click the appropriate below to login as a member and participate. If you are not a member, please CLICK HERE for more information.


    Ford Wong
    [ATCO-ITEK]
    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
    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
    [Cx SpA]
    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
    >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
    [Bayard Lee Tysor, Inc.]
    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
    [Cx SpA]
    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
    >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
    >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!

    All Times America/New_York

    Copyright © 2014 IDUG. All Rights Reserved

    All material, files, logos and trademarks within this site are properties of their respective organizations.

    Terms of Service - Privacy Policy - Contact