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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Haberstroh, Debbie (IT)
Sent: Monday, July 09, 2007 4:39 PM
To: ADSM-L AT VM.MARIST DOT 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:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Daad Ali
Sent: Monday, July 09, 2007 1:54 PM
To: ADSM-L AT VM.MARIST DOT 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
|
