Can a raw device container extension be combined with auto-storage?
in [DB2]
|
Prev: DB2 DBA - Distributed Database Administrator required at Morgan Stanley, UK, London
Next: Try IBM preperation series
From: Troels Arvin on 17 May 2010 16:49 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
From: Hardy on 18 May 2010 10:57 On May 17, 3:49 pm, Troels Arvin <tro...(a)arvin.dk> wrote: > 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 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.
From: Troels Arvin on 18 May 2010 13:43 Hardy wrote: > but for significant one, for example a 10T BI database, it doesn't make > sense to use AMS to make life easier. Why not? -- Troels
From: Helmut Tessarek on 18 May 2010 14:15 Hi Troels, > 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. Raw devices cannot be used with automatic storage. Automatic storage either creates SMS tablespaces or DMS tablespaces with file containers. > 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? 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. */
From: Hardy on 18 May 2010 18:06
On May 18, 12:43 pm, Troels Arvin <tro...(a)arvin.dk> wrote: > Hardy wrote: > > but for significant one, for example a 10T BI database, it doesn't make > > sense to use AMS to make life easier. > > Why not? > > -- > Troels 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. |