DB2 Basics: Storage Groups

You may also like...

3 Responses

  1. Toben Nelson says:

    I really liked the level of detail in this post; it’s perfectly geared for the DBA. Some discussions of storage can get too wonky, some too thin on detail. This was a perfect primer with sample commands that I can use to quickly get a storage group setup and some ASTs created and using it. Thanks!

  2. Enrique Valdez says:

    Hi Ember:

    First I must outline that your webpage and the posts in it (plus the effort to generate them) is simply awesome.

    Now let’s go to the point,

    You wrote “Since storing permanent data in DMS and SMS tablespaces has been deprecated, it is clear that IBM’s direction is to eliminate the use of these in favor of AST and storage groups.”.

    Since in our shop we manage out table/tablespaces assigment in ‘the old mainframe school’ way (1 table = 1 Tablespace), we’re concerned about how we’re going to accomplish not just the performance but the practical side of knowing exactly where our DB2 objects are located.
    WIll AST be the only way to manage our DB2 storage in the near future? We’d like to continue the way we manage our data file location/allocation, but it seems that we won’t be able to.

    Thanks again for the wonderful contents of your webpage.


    • Ember Crooks says:

      The Old-School way of doing it has been fading away for years. I still hear of a few large shops doing things that way, but I have a very hard time seeing the advantage of it. I do still often separate out my few very large or very active tables to their own tablespaces, but I fail to see the true advantage of doing it for every table. I like it so I can keep a busy table from swamping my bufferpool or dedicate bufferpool resources to it.

      One reason is the ability of admin_move_table to move tables between tablespaces in an online manner. You can very much control and know what disks specific objects are on, but you’re not telling me that each tablespace has it’s own filesystem, are you?

      With the newer model, you could continue to have each table in a separate tablespace, but have those tablespaces spread across a small number of storage groups and grouped by storage characteristics or content characteristics. Tablespaces can then be easily moved between storage groups, online, if you discover that you have to separate something out. If anything, the addition of the storage group layer makes this easier and more seamless.

Leave a Reply

Your email address will not be published. Required fields are marked *