dbTalk Databases Forums  

Thoughts about SMS tablespaces

comp.databases.ibm-db2 comp.databases.ibm-db2


Discuss Thoughts about SMS tablespaces in the comp.databases.ibm-db2 forum.



Reply
 
Thread Tools Search this Thread Display Modes
  #11  
Old   
stefan.albert
 
Posts: n/a

Default Re: Thoughts about SMS tablespaces - 01-04-2008 , 03:03 AM






The AUTORESIZE feature - it should be called AUTOINCREMENT for DMS -
is a built-in-feature for SMS because the OS manages the files - the
only limits are based on filesize (use more containers) and filesystem
size (use more containers).

SMS is (for me) the chioce when having much dynamic traffic (create -
mass insert - drop) with tables.
The problem with DMS and AUTOresize is, that if the tablespace (TS)
grows and tables are dropped, the size remains. There is no "good" way
to decrease the size of the DMS-TS (this should be changed in version
9.5).

We have a DB with DMS (created by Performance Expert) and a very big
DMS (due to some "features" of PE) because of big tables. They now are
quite empty, but the size of the DMS can't be reduced accordingly. (We
have version 8) Even a reorg didn't help...

This won't be the case when using SMS.

All the other disadvantages of DMS to SMS disappeared since version 7,
and the reason for having 1 TS for 1 table also, because the LOAD
command was inproved (TS was unusable after some LOAD failures).

* because of AUTORESIZE
* large TS
* get information about table data and index size (before db2pd you
were lost with DMS - with SMS you just scanned the files of the table
in the filesystem)

For recovery purposes (minimum restore object is TS) you can use
export (slow) or High Performance Unload (HPU) to backup/retrieve
tables. HPU can also extract tables from a backup set into files for a
LOAD operation - thats great.

And the last thing: Since version 9 a TS can be restored to a
different one. Up to version 8 it was only allowed to restore a TS
into the SAME TS - bad thing if it was dropped (or another DB).

For me there are still some reasons to stay at SMS:
* real autoresize
* use "free space" in the filesystems for temporary tablespaces (OK
there won't be any left if the FS gets full, but this situation should
be avoided anyway)

The list became shorter and shorter since we started with version 7...


On Jan 4, 2:18*am, alexhguerra <alexhgue... (AT) uol (DOT) com.br> wrote:
Quote:
On Jan 2, 11:29 pm, Sanjuro <ashru... (AT) gmail (DOT) com> wrote:





On Jan 2, 4:17 pm, "Mark A" <nob... (AT) nowhere (DOT) com> wrote:

kschl... (AT) ca (DOT) ibm.com> wrote in message

news:314577cd-40b1-4494-920f-d1d38e12d347 (AT) d4g2000prg (DOT) googlegroups.com....

Just as an FYI, there are some people that do prefer to have a single
table per tablespace (or some small number of tables per tablespace)
for recovery purposes. *The lowest level of recovery is the tablespace
so by doing this you can get table-level recovery.

Regards,
Kelly

Some do it, but it is not generally recommended, as is the case on DB2for
z/OS where it is almost universally recommended to have a separate
tablespace for each table.

I knew a LUW DBA who mandated one tablespace per table. I believe for
recovery reasons. If he had performance in mind while considering such
a design, then there might actually be negative performance gains as
the server would require more IOSERVERS and IOCLEANERS to work
concurrently for all tablespaces. This is my understanding and I might
be wrong.

Couple of questions, that Alex asked, Is there a tool to help you move
from SMS to DMS (may be, none of the free ones).
Can the tablespace grow by a certain amount when full to a certain
extent? Yes, please check the AUTORESIZE and Automatic Storage
features in DB2 v9. That gives you another reason to upgrade, if you
haven't already planned so.

Question to Mark - The z/OS recommendation of having one table per
tablespace is to enhance recoverability or due to performance
considerations?

Happy new year!
~Sanjuro

The problem still that (as far as i know) the AUTORESIZE feature
applies only to DMS Tablespaces.

Which of the DB2 documentation PDFs could give some insights about
choosing which tables to put togheter in the same tablespace ? The
first rule
that i could imagine is having tables of the same size/growing
proportion

About the DMS migration tool, any that could be a start?

Thanks- Hide quoted text -

- Show quoted text -


Reply With Quote
Reply




Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.