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

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.

Yes we are going to migrate to v9.7 in few months and this is good argument to migrate.

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?

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.

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.