If you server has enough resources (CPU, memory, storage...) then put the new instance on the same server. You have to update the clients DSM.OPT file for the ones that backup to the new "instance" anyway, but instead of chaning TCPSERVERADDRESS you change TCPPORT.
You currently have your TSM instance running on port 1500. So, first create an instance to be the library manager using port 1700. Setup server-server and create a shared library on the libmgr and define all your paths. Now define your TSM instance and create the paths to the drives. They'll be the same as what you just created for the libmgr. When you're ready, create a 3rd instance running on port 1600 with the same size of the production DB. Define the shared library and paths to this instance and using a Dbbackup from the TSM instance, restore it to your new TSM(3) instance. Bring it up, change settings (servername, serverhl, serverll,...) then start deleing the data for nodes in TSM(3) from TSM(1) and data visa versa. Change your client DSM.OPT files for the new TSM(3) instance. I'm not sure how TSM server licensing is, but if you put it on another server I think you need to purchase another license. But if you just create more instances on the same server,...? You should contact your IBM business partner for the definitive answer. So it may be cheaper in the long run to add more resources to the existing server and create multiple instances. Bill Boyer "Backup my harddrive? How do I put it in reverse?" - ?? -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Haberstroh, Debbie (IT) Sent: Monday, July 09, 2007 4:39 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: Splitting the TSM Database into three We are in the same state, my db is 180 Gb, 87% utilized. At a high level, one of the consultants we talked to suggested loading the database onto 2 different servers and then deleting different storage pools and nodes from each one, essentially putting part of the database on each server. We are at TSM 5.3 so would be going to the same OS and were going to keep the same TSM version. One of the obstacles I have with this method is almost all of my clients belong to the same copypool so I need to separate them before we can even attempt this. Once everyone was backing up to their new server, we could export the remaining nodedata that was backed up since the database backup was done. Good luck with your split, I will be interested to hear what method you use and how it works for you. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of Daad Ali Sent: Monday, July 09, 2007 1:54 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Splitting the TSM Database into three Hi All, We are discussing a way of splitting our TSM database. It is become very big and slow. We want to split it into 2 or 3(one will be the manager of the other two) I don't know how to split it so I am looking for a procedure/steps on how to do that. Also, after splitting the database, can I assign different platforms (AIX/Windows) to the two DBs. My db is about 200 GBs now and the server is version 5.2.6.0 >q db f=d Available Space (MB): 180,000 Assigned Capacity (MB): 180,000 Maximum Extension (MB): 0 Maximum Reduction (MB): 14,824 Page Size (bytes): 4,096 Total Usable Pages: 46,080,000 Used Pages: 34,660,427 Pct Util: 75.2 Max. Pct Util: 75.4 Physical Volumes: 9 Buffer Pool Pages: 272,144 Total Buffer Requests: 293,217,483 Cache Hit Pct.: 99.05 Cache Wait Pct.: 0.00 Backup in Progress?: No Type of Backup In Progress: Incrementals Since Last Full: 0 Changed Since Last Backup (MB): 5,818.36 Percentage Changed: 4.30 Last Complete Backup Date/Time: 07/09/07 01:15:44 ============== tsm: BRDTSM01>q log f=d Available Space (MB): 12,000 Assigned Capacity (MB): 10,020 Maximum Extension (MB): 1,980 Maximum Reduction (MB): 10,000 Page Size (bytes): 4,096 Total Usable Pages: 2,564,608 Used Pages: 4,369 Pct Util: 0.2 Max. Pct Util: 68.3 Physical Volumes: 6 Log Pool Pages: 128 Log Pool Pct. Util: 8.54 Log Pool Pct. Wait: 0.00 Cumulative Consumption (MB): 4,768,612.50 Consumption Reset Date/Time: 12/07/05 14:37:35 Thanks as always. Daad --------------------------------- Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail