Hi, I remember reading somewhere that a TSM DB should ideally not be allowed to grow passed 120GB before having another instance of TSM. You will find that you will have a major problem should you have to run an AUDITDB for example if you ever have errors in your DB. Instead of hours or a day, you would face an AUDIT of weeks, which happened to a TSM user in South Africa a while back.
I would look into splitting the Server up. Regards Adrian Compton Aspen Pharmacare Port Elizabeth tel: +2741 4072855 Fax: +2741 453 7452 Cell: +27823204495 Email: [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Schneider, Jim Sent: 21 August 2008 00:06 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] DB Mirroring - Poll and question (using small voice) I guess it's not "lots." 124,858,663 files, 131 TB occupancy, 90 GB database, ~100 clients. Jim -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Rodolfich Sent: Wednesday, August 20, 2008 4:33 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] DB Mirroring - Poll and question WOW, the 342 Million files is what is killing you but it still seems like an excessive amount of time. You mentioned Saturday as when it starts. You are running expiration daily aren't you? You should be able to run expiration and reclamation to completion each day or you need to look at another instance or configuration to meet your resource needs. If you don't complete expiration and reclamation daily, you will be queueing up unfinished work each day that will turn into a 24-48 hour expiration run(sounds like you are there). Expiration and reclamation go hand-in-hand. If your expiration doesn't complete then you reclamation can't either. As a result, you may have a good number of un-reclaimed and un-expired entries in your database. BTW, I have always been told, by my TSM mentors, that due to the database intensive nature of expiration, that it should always run by itself. Define LOTS? My specs are: 194GB DB 206TB Occupancy 342,194,690 files "Schneider, Jim" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 08/20/2008 01:58 PM Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] DB Mirroring - Poll and question We need 4-6 hours for 90GB DB, ~100 clients. The servers have LOTS of files. -----Original Message----- From: ADSM: Dist Stor Manager Michael Green Sent: Wednesday, August 20, 2008 12:48 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] DB Mirroring - Poll and question 48 hours sounds like an awfully looong time to me. On my busiest Linux server (90gb DB, ~100 clients) expiration completes in 20-30 minutes. -----Original Message----- From: Zoltan Forray/AC/VCU <[EMAIL PROTECTED]> Sent: Wednesday, August 20, 2008 18:14 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] DB Mirroring - Poll and question On my big, 194GB production Linux server, an EXPIRE INVENTORY runs 40-48 hours. Granted, the server is very busy performing other tasks such as client backups, stgbackups and such. The DB buffers and such are configured identically to the production server. On my first test expire run on my new test server (to which I reloaded the 194GB production DB), the expire ran in 10-hours - 1/4 of the usual time.
