ALL -

LUW 9.7.5 on AIX 6.1.

Like most DB2 shops our data resides in DMS tablespaces and
unfortunately most of our tablespaces remain Pre 9.7 with high-water
marks, etc.

Now, we hear lots about Automatic Storage and we read all the
documentation but I have a healthy amount of skepticism about turning
over management of our tablespaces to this 'black box' called
'automatic storage' into which I have very little visibility. We're
going to be moving our data to DB2 9.7 tablespaces to gain the ability
to lower High-Water, etc. and so now its 'crunch' time.

So here is what the documentation says (from the Information Center):

Of the three types of table spaces, automatic storage table spaces
are the easiest to set up and maintain, and are recommended for most
applications. They are particularly beneficial when:

You have larger tables or tables that are likely to grow
quickly
You do not want to have to make regular decisions about how to
manage container growth.
You want to be able to store different types of related objects
(for example, tables, LOBs, indexes) in different table spaces to
enhance performance.

DMS table spaces are useful when:

You have larger tables or tables that are likely to grow
quickly
You want to exercise greater control over where data is
physically stored
You want to be able to do make adjustments to or control how
storage is used (for example, adding containers)
You want to be able to store different types of related objects
(for example, tables, LOBs, indexes) in different table spaces to
enhance performance.

-----

Great. I'm concerned when I see this phrase: "to enhance performance"
spread all over the documentation...That phrase exists under Automatic
Storage as well as DMS...My point is that I'm getting mixed-signals
from this documentation and it isn't clear.

Am I guaranteed to get better performance from 'Automatic Storage' V.
DMS? If not, why? If so, why?
Is 'Automatic Storage' IBM's stated future direction?
If I move this data to DMS now will I have to revisit this issue in a
year or so because IBM has changed something?
I'm skeptical about turning over my storage considerations to
something which undoubtedly works but when management asks me about
clear-cut performance benefits then I simply won't be able to give a
good, straight, clear and informed answer.

IBM has evidently classified any technical information about Automatic
Storage as 'Eyes Only' and 'Top Secret' which is making it really
difficult to form a non-biased opinion on a subject which is pretty
important to me.

Thanks,

-B

Automatic Storage is not a new type of storage - it just provides the
ability to predefine locations for where tablespace containers will
live.

If you look under the covers using either db2pd or 'LIST TABLESPACE
CONTAINERS', you'll find that Automatic Storage tablespaces use DMS file
containers for everything except temporary tablespaces. User and system
temporary tablespaces still use SMS containers.

So there is no performance advantage or disadvantage inherent to
automatic storage in and of itself.


--- Posted via news://freenews.netfront.net/ - Complaints to news (AT) netfront (DOT) net ---

On Fri, 29 Jun 2012 11:24:58 -0700, Ian wrote:

Two main advantages of Automatic Storage that I know about:

- No more redirected restores (with SET TABLESPACE CONTAINERS) necessary when (and if) you have
to move databases around (such as in test environments).

- pureScale requries automatic storage, if and when you migrate to that.

On Jun 30, 1:30*am, Mark A <m... (AT) nowhere (DOT) com> wrote:
Thanks guys for your valuable input; it is much appreciated!

So what I'm hearing is that Automatic Storage is simply an obfuscating
wrapper around DMS-format Tablespaces.

The advantages to Automatic Storage therefore are:

The ability to define a large storage pool (like what we had with
Mainframe Storage-groups which are now becoming available under DB2
V10)
Automatic Storage will ensure that all of our tablespaces are
distributed across all pre-defined containers

The dis-advantages to Automatic Storage therefore are:

We lose visibility into those tablespaces which are shrinking or
growing
We lose the ability to place specific tablespaces into a specific
bufferpool
We lose our ability to designate Extentsize, Prefetchsize, etc when we
point to automatic storage

Redirected Restore ramifications aren't really a big issue so that's
neither a plus nor a minus.

So at the end-of-the-day when we add-up pluses and minuses for
automatic storage I don't see alot of advantages

If somebody else can weigh-in then that'd be wonderful...

Overall then for us Automatic Storage is a solution in search of a
problem.

Bruce <bwmiller16 (AT) gmail (DOT) com> writes:

Incorrect. You can still see and monitor tablespaces, their size, etc.
You can also manually increase / decrease the size of these tablespaces.

Incorrect. You can specify what bufferpool at tablespace creation time
or change which bufferpool later

Incorrect. You can still specify these parameters, just as with
non-automatic-storage tablespaces.

And, just like non-automatic-storage tablespaces, if you don't provide
explict values, extentsize still defaults to whatever the
DFT_EXTENT_SIZE database configuration parameter is set to.
PREFETCHSIZE defaults to AUTOMATIC, where DB2 determines the proper
value (read the docs on PREFTECHSIZE to see how it calculates this.


--- Posted via news://freenews.netfront.net/ - Complaints to news (AT) netfront (DOT) net ---

On Jul 2, 6:00*pm, Ian <ian.bjorho... (AT) gmail (DOT) com> wrote:

Personally, I can't think of any reason why you wouldn't use Automatic
Storage anymore, especially since V10 acquired the storage group
concept. The only missing possibilities I see (maybe I'm missing a
few) are:
- using SMS for data: older, slower, online backup can be tricky,
reclaimable storage works nice as well, isn't it deprecated by the
way?
- giving your tablespace containers nice names: as someone who is used
to AS, I guarantee you I never really felt the urge, but that's
personal.

To me, it seems that you should read a bit deeper into what it really
does, you'll probably like it. I do...

Kind regards,

Frederik Engelen

Frederik Engelen <engelenfrederik (AT) gmail (DOT) com> writes:

With the addition of Storage Groups automatic storage becomes much more
attractive to those of us who want some control and/or ability to
separate physical I/O between tablespaces.

DPF is another case where automatic storage has historically been a
little harder to implement due to the fact that storage paths have to
have the same path names across all partitions OR your file system
naming standard must be compatible with the '$N' expansion.





--- Posted via news://freenews.netfront.net/ - Complaints to news (AT) netfront (DOT) net ---