Hello,

For a while, I've followed a strategy of moving away from raw devices,
and to use automatic storage - in order to simplify database management.

But given the increasing smartness of storage systems (where it's easy to
extend the size of a LUN, for example), I find it tempting to re-think
our strategy of moving away from raw devices: If management of storage on
raw devices could somehow be combined with automatic storage, we could
remove the (small, but existing) overhead of a filesystem.

It seems that it's possible to extend the size of a tablespace container.
But only if non-automatic storage is used? Is there a way around this
that I'm overlooking?

--
Troels

On May 17, 3:49*pm, Troels Arvin <tro... (AT) arvin (DOT) dk> wrote:
we use auto storage to make storage management easier. just image you
have to deploy two dozens of small databases in a box.

but for significant one, for example a 10T BI database, it doesn't
make sense to use AMS to make life easier.

Hardy wrote:
Why not?

--
Troels

Hi Troels,

Raw devices cannot be used with automatic storage. Automatic storage either
creates SMS tablespaces or DMS tablespaces with file containers.

There are 3 types of DMS tablespaces:

1) no auto grow
2) auto grow
3) automatic storage

If you are using raw devices types 2 and 3 are not possible. 2) You can't
enable AUTORESIZE for tablespaces that use raw device containers. You will get
an SQLSTATE 42601. 3) Automatic storage does not use raw devices.

However, you can increase the tablespace size (even if you are using raw
device containers) manually by issuing ALTER TABLESPACE EXTEND or RESIZE.

I know that this was probably not the answer you wished for, but there is no
way around these restrictions.

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

On May 18, 12:43*pm, Troels Arvin <tro... (AT) arvin (DOT) dk> wrote:
better performance. master of storage is important for performance.
auto grow feature may not means as much as for lots of smaller
databases. this kind of DBs always have their own server/storage.
btw, for DBAs who manage very large db, to deal with raw devices is
not more difficult than to enjoy AMS.

with the improvement of virtual storage system and price dropping of
related storage product, AMS may also have more bright future in the
field of large scale databases. for now, I'd like to wait.

Hardy wrote:
So it's the auto-grow feature which could be troublesome?

If auto-growing may result in some kind of fragmentation (just guessing):
Could this not be mitigated by choosing a sufficiently high INCREASESIZE
parameter for the database?

--
Troels