Results 1 to 4 of 4
  1. #1
    Join Date
    Jan 2003
    Posts
    1,605

    Unanswered: DB2 v9.7: Automatic storage migration from non-automatic database

    Hi,
    we are using DB2 v9.5 on Linux that was migrated from DB2 v8.2 few months ago. On production database all of the tablespaces SYSCATSPACE (system tablespace), TEMPSPACE1 (temporaly tablespace), USERSPACE1 (data tablespace) are using SMS tablespace type!

    I have read DB2 9.7 Overview presentation and on page 9 there is topic "Automatic Storage Migration" and first point is "Support ALTER DATABASE command for non-auto AS database".

    If I understand correctly alter database command now supports migration of non-automatic storage tablespaces to automatic tablespaces. This is probably for DMS tablespaces. Does this migration also supports database migration with SMS tablespaces (just like in our case)?
    Regards

  2. #2
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746
    Quote Originally Posted by grofaty View Post
    This is probably for DMS tablespaces.
    No, SMS as well. But the question is: are you going to migrate to V9.7? Those new "alter db" features are not for V9.5.
    And, do not worry too much about SMS vs DMS. Worry about you disks. I'd rather have a SMS-tablespace spread amoung 20 disks then a DMS tablespace using only 3 disks.

  3. #3
    Join Date
    Jan 2003
    Posts
    1,605
    Quote Originally Posted by dr_te_z View Post
    No, SMS as well. But the question is: are you going to migrate to V9.7? Those new "alter db" features are not for V9.5.
    Yes we are going to migrate to v9.7 in few months and this is good argument to migrate.

    Quote Originally Posted by dr_te_z View Post
    And, do not worry too much about SMS vs DMS. Worry about you disks. I'd rather have a SMS-tablespace spread amoung 20 disks then a DMS tablespace using only 3 disks.
    For testing purposes I have created two databases to the same disks using load and import functionality and DMS was working more then 20% faster compared to SMS. It is also easier to manage disk space in automatic-dms, just adding new path to alter database command.

    BTW, now in our environment there are multiple of 2 GB disks joined together in one 150 GB virtual disk. In Linux executing "df -h" command to see disk space by disks, I can only see one disk like /path_to_disk1. So I can only set one disk to DB2. Would it be better to have for example 10 disk paths by 15 GB instead?
    Last edited by grofaty; 01-19-10 at 10:05.

  4. #4
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746
    Quote Originally Posted by grofaty View Post
    using load and import functionality and DMS was working more then 20% faster compared to SMS.
    Yes, that makes sence: during the load-process the SMS tablespaces have to grow (ask extends to the O.S.) constantly. During normal DB work the diff. will be less sifnificant.

    Quote Originally Posted by grofaty View Post
    Would it be better to have for example 10 disk paths by 15 GB instead?
    For pure performance? I'd say yes. The more spindles, the better. When 1 disk dies is it acceptable that the DB crashes...? So there are always more factors to consider.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •