|
|
Posted at 8:18 AM on Apr. 17, 2009
|
|
Opening this as a new topic, rather than discuss these issues in the old topic which just speculated about what and when for 6.1
Opening this as a new topic, rather than discuss these issues in the old topic which just speculated about what and when for 6.1
|
|
|
Posted at 8:24 AM on Apr. 17, 2009
|
|
Posted at 1:52 PM on Apr. 15, 2009
The 6.1 upgrade does present a few challenges.
You will need empty disk space for the new database and logs, maybe 33-50% more than your existing space. You cannot convert the database in place
While you are running the database extract and reload, your old server is unavailable. The extract runs at between 5 and 10GB per hour. If you are moving database to database you can do the extract and import simultaneously, but if you are staging the extract to tape, then the two processes are sequential. Bottom line is plan for an extended downtime, and include time for a full database backup before you start.
Once you convert, then all TSM 5.x instances on your server are unusable. So if you run several TSM instances on one hardware server, you either need a new server for 6.1, or convert all your TSM instances in one go.
The conversion will also affect any disk storage pools., so if you need to backout, then you have to backout the diskpools too. This means you either have to backup the disk pools before you start, or better, migrate all the data off to tape before you start. Active Copy pools will be an added complication.
Posted at 1:52 PM on Apr. 15, 2009
The 6.1 upgrade does present a few challenges.
You will need empty disk space for the new database and logs, maybe 33-50% more than your existing space. You cannot convert the database in place
While you are running the database extract and reload, your old server is unavailable. The extract runs at between 5 and 10GB per hour. If you are moving database to database you can do the extract and import simultaneously, but if you are staging the extract to tape, then the two processes are sequential. Bottom line is plan for an extended downtime, and include time for a full database backup before you start.
Once you convert, then all TSM 5.x instances on your server are unusable. So if you run several TSM instances on one hardware server, you either need a new server for 6.1, or convert all your TSM instances in one go.
The conversion will also affect any disk storage pools., so if you need to backout, then you have to backout the diskpools too. This means you either have to backup the disk pools before you start, or better, migrate all the data off to tape before you start. Active Copy pools will be an added complication.
|
|
|
Posted at 8:33 AM on Apr. 17, 2009
|
|
Posted at 11:34 PM on Apr. 16, 2009 by Bumblebee
Jim, one thing to mention when you are planning the upgrade is that if you are using raw file system today for the TSM db vols you can't reuse that space for DB2 volumes. The disk storage pools can be on raw file system as before. I believe that IBM are planning a Redbook deployment guide about this.
Posted at 11:34 PM on Apr. 16, 2009 by Bumblebee
Jim, one thing to mention when you are planning the upgrade is that if you are using raw file system today for the TSM db vols you can't reuse that space for DB2 volumes. The disk storage pools can be on raw file system as before. I believe that IBM are planning a Redbook deployment guide about this.
|
|
|
Posted at 3:39 PM on Jul. 22, 2009
|
|
Jim said: Posted at 11:34 PM on Apr. 16, 2009 by Bumblebee Jim, one thing to mention when you are planning the upgrade is that if you are using raw file system today for the TSM db vols you can't reuse that space for DB2 volumes. The disk storage pools can be on raw file system as before. I believe that IBM are planning a Redbook deployment guide about this. It works, but it's not _supported_ Craigy
[quote=Jim] Posted at 11:34 PM on Apr. 16, 2009 by Bumblebee
Jim, one thing to mention when you are planning the upgrade is that if you are using raw file system today for the TSM db vols you can't reuse that space for DB2 volumes. The disk storage pools can be on raw file system as before. I believe that IBM are planning a Redbook deployment guide about this. [/quote]
It works, but it's not _supported_
Craigy
|
|
Anonymous
|
|
Posted at 7:56 PM on Jul. 22, 2009
|
|
Interesting - I never really understood why you could not re-use raw volumes as you would reformat the space when creating the new DB volumes, and that should destroy any residual info left over from the old TSM release.
Interesting - I never really understood why you could not re-use raw volumes as you would reformat the space when creating the new DB volumes, and that should destroy any residual info left over from the old TSM release.
|
|
|
Posted at 10:38 PM on Jul. 22, 2009
|
|
said: Interesting - I never really understood why you could not re-use raw volumes as you would reformat the space when creating the new DB volumes, and that should destroy any residual info left over from the old TSM release. The support statement that TSM 6.1 wouldn't support raw volumes for the DB is simply because the installer for TSM only allows for a system managed space datastore (DB2 parlance for "we're putting the DB contents on a filesystem"). The raw volumes way of doing things is called DMS, and isn't even an option on the TSM 6.1 installer. It *is* possible (but NOT supported) to set up your own TSM DB2 with any parameters you like, however. The new 128GB logfile size limit is also breakable using this technique.. Craigy
[quote=] Interesting - I never really understood why you could not re-use raw volumes as you would reformat the space when creating the new DB volumes, and that should destroy any residual info left over from the old TSM release. [/quote] The support statement that TSM 6.1 wouldn't support raw volumes for the DB is simply because the installer for TSM only allows for a system managed space datastore (DB2 parlance for "we're putting the DB contents on a filesystem"). The raw volumes way of doing things is called DMS, and isn't even an option on the TSM 6.1 installer. It *is* possible (but NOT supported) to set up your own TSM DB2 with any parameters you like, however. The new 128GB logfile size limit is also breakable using this technique..
Craigy
|
|
|