We started using Tivoli in October of 2006 with version 5.3 but I did have to perform a DB Export to repair some issues with it. I can't find exactly when I did it but I think it was in 2007, June time frame. My server is an IBM x346 with 3.25 GB of memory and 2 Xeon 3.6 GHz processors. The tape drive is also FC connected to the server. I did recently move the database to another drive by creating the new volumes and issuing the delete dbvolume commands on the old ones. Not sure if that would have helped. I don't use TSM mirroring so not sure if that would add any overhead. Jeremy
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Paul Zarnowski Sent: Thursday, December 04, 2008 5:50 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Database size, Split to multiple instances or wait for version 6.1 Interesting.. we have a database that's about the same size, but it takes us 2 hours and 40 minutes to back it up to LTO3. We also have 15K rpm 36GB drives, in two mirrored RAID5,7 sets (TSM mirroring). SAN is 2Gb FC. Server is P5 570. Server is not entire idle, but mostly so. Our database is ancient, dating back to ADSM 1.2 days and has never been re-organized. How old is your database? I'm wondering if a re-org would improve things that much. ..Paul At 12:05 PM 12/4/2008, Conradt, Jeremy wrote: >Its actually not 350 GB. The actual used size is: > >Available Assigned Maximum Maximum Page Total Used Pct >Max. > Space Capacity Extension Reduction Size Usable Pages Util >Pct > (MB) (MB) (MB) (MB) (bytes) Pages >Util >--------- -------- --------- --------- ------- --------- --------- >----- >----- > 350,000 340,000 10,000 57,580 4,096 87,040,00 72,203,13 83.0 >83.1 > 0 6 > >The DB resides on 7 - 15K fiber channel drives in a Raid5 configuration >with 2 GB/s Fiber connection. >Also the Log resides on a separate lun on a separate controller. >Also during this time basically nothing else is happening on the system. > >The tape drive is LTO3. >If I backup the DB while multiple migration or reclamation processes >are running then the DB backup is significantly slowed down. >I have also attached the output of the last DBBackup for your reference >and for the doubters. >I actually estimated the time and I was a little high on it. I can't >give you the output from an expire because my log files have already >been replaced but here is the last run's time output. > >C:\Program Files\Tivoli\tsm\baclient>time /t >12:16 PM >C:\Program Files\Tivoli\tsm\baclient>dsmadmc -id=scriptrun >-password=****** expire inventory wait=yes >1>c:\scripts\logs\07-expire.txt >C:\Program Files\Tivoli\tsm\baclient>time /t >01:12 PM > >Jeremy > > >-----Original Message----- >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf >Of Bos, Karel >Sent: Thursday, December 04, 2008 10:45 AM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] Database size, Split to multiple instances or >wait for version 6.1 > >Ok, 350GB tsm db backing up in 1 hour? How did you get it that fast? > >Regards, > >Karel > >-----Original Message----- >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf >Of Conradt, Jeremy >Sent: donderdag 4 december 2008 17:19 >To: ADSM-L@VM.MARIST.EDU >Subject: Re: Database size, Split to multiple instances or wait for >version 6.1 > >Expiration takes about 1 hour. DB Backup takes about 1 hour 15 minutes. > >Thanks, >Jeremy > >-----Original Message----- >From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf >Of Wanda Prather >Sent: Wednesday, December 03, 2008 7:01 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] Database size, Split to multiple instances or >wait for version 6.1 > >How long does it take you now to do Expiration and DB backup? > > > >On Wed, Dec 3, 2008 at 4:24 PM, Conradt, Jeremy < >[EMAIL PROTECTED]> wrote: > > > I have a TSM server currently running version 5.3.5 on Windows 2003 > > that we plan to upgrade soon. > > The problem I have is our database has grown to 350 GB. > > The question I have is will version 6.1 of TSM be better capable of > > maintaining a database this size and much larger or should I break > > it apart? > > I would rather keep everything together so we can make better use of > > de-duplication that may be coming out with version 6. > > Thanks, > > Jeremy > > > > > > > > -- Paul Zarnowski Ph: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [EMAIL PROTECTED]