I have a dsmvolhist.log file on disk which I understand is a copy of what is held internally. Looking through it I see FILE volumes from 10/23/2007 and forward that don't even exist. My log file is 136K lines. The server starts really slow and I was wondering if it goes through this log every time it starts. But in any case, can I safely clean out some of this log? We use drm so I think it takes care of clearing the database backup entries. It there some automatic maintenance I should be doing? I understand I can use the log to see what volumes hold my last backup but is all the other stuff needed?
-
-
Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)
Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.
How to clean up volhist
- Thread starter drfranks
- Start date
DanGiles
ADSM.ORG Senior Member
Volhist isn't all that important. Most places I've been to keep anywhere from 30 to 90 days worth of information; a few days to a week for db backups. If you perform a 'del volhist type=dbb -todate=XXX', make sure 'XXX' is greater than the retention for DB backups set in DRM.
(Note the cmd parameters may not be correct but I'm too lazy right now to look it up
)
(Note the cmd parameters may not be correct but I'm too lazy right now to look it up
)Hi
I don't understand why you frequently restart TSM server, bit usually TSM start time depends on TSM database size (not DB utilization).
In all cases you can also delete old stgnew, stgreuse and stgdelete records from database using command delete volhist. Of course it will be correspond with your storage requirements.
Efim
I don't understand why you frequently restart TSM server, bit usually TSM start time depends on TSM database size (not DB utilization).
In all cases you can also delete old stgnew, stgreuse and stgdelete records from database using command delete volhist. Of course it will be correspond with your storage requirements.
Efim
BBB
ADSM.ORG Moderator
Database startup time is significantly affected by the log size. It will read through pretty much the entire log on startup, so if you have a 12gb log it takes a while.
I don't think your volhist will affect your startup time.
Most of the entries in your volhist are prob stgnew and stgdelete as efim suggested. Delete all those older than X days, say 10 days or so, depending on how long you keep your DB backups for.
I don't think your volhist will affect your startup time.
Most of the entries in your volhist are prob stgnew and stgdelete as efim suggested. Delete all those older than X days, say 10 days or so, depending on how long you keep your DB backups for.
Hi
I measure off startup time for small TSM server with logsize 40 Mb and 12 Gb (Logmode=normal) :
Recovery log assigned capacity is 40 megabytes.
Database assigned capacity is 200 megabytes.
Startup ~ 10 sec
Recovery log assigned capacity is 12040 megabytes.
Database assigned capacity is 200 megabytes.
Startup ~ 1.5 min
The most time was spent for process: Recovery log volume mount in progress.
Efim
I measure off startup time for small TSM server with logsize 40 Mb and 12 Gb (Logmode=normal) :
Recovery log assigned capacity is 40 megabytes.
Database assigned capacity is 200 megabytes.
Startup ~ 10 sec
Recovery log assigned capacity is 12040 megabytes.
Database assigned capacity is 200 megabytes.
Startup ~ 1.5 min
The most time was spent for process: Recovery log volume mount in progress.
Efim
Last edited:
BBB
ADSM.ORG Moderator
Was the 10 second test meant to be a 40mb log?
Thanks. I trimmed the volhist back and put this command in a schedule:
delete volhist t=all todate=today-30
If we restart the server, it takes a half hour before we can log in to it. Our database is 140 GB and we are utilizing 77%. The log is 7.6 GB.
delete volhist t=all todate=today-30
If we restart the server, it takes a half hour before we can log in to it. Our database is 140 GB and we are utilizing 77%. The log is 7.6 GB.
So in my case the log is 7600 MB.
7600 MB x 10 sec/40 MB x 1 minute/60 sec = 31.67 minutes
which would match our half hour startup time.
So is it the size of the log that matters or the amount of the log utilized at the time of the restart. Would an incremental backup clear the log and make the startup time shorter?
7600 MB x 10 sec/40 MB x 1 minute/60 sec = 31.67 minutes
which would match our half hour startup time.
So is it the size of the log that matters or the amount of the log utilized at the time of the restart. Would an incremental backup clear the log and make the startup time shorter?
GregE
ADSM.ORG Senior Member
It should be the amount utilized, not allocated log space. I have a 12GB log. Only used space is read. When only a few percent utilized, the server restarts in under a minute. I can't say I have had a highly utilized log at restart so I don't have an example of that.
I backed up the database. The log utilization was 0.0%. I halted and restarted. It took 37 minutes before I could reconnect. Is this normal behavior? Is there anything else I should look at. I started in quiet mode so really couldn't see what it was doing all that time.
cjhood
ADSM.ORG Moderator
drfranks,
Not a solution sorry, but you're not alone with this - when I bounce one of my instances (12Gb Log) I see similar startup times, even with 0.0% or otherwise extremely low Log utilization. Somewhere around 30-40 minutes each and every time which I considered normal for a server of this size.
My smaller servers have half the Log allocation and start up a lot quicker. Next time it's restarted I'll bring it up in the foreground and time it properly.
-Chris
Not a solution sorry, but you're not alone with this - when I bounce one of my instances (12Gb Log) I see similar startup times, even with 0.0% or otherwise extremely low Log utilization. Somewhere around 30-40 minutes each and every time which I considered normal for a server of this size.
My smaller servers have half the Log allocation and start up a lot quicker. Next time it's restarted I'll bring it up in the foreground and time it properly.
-Chris
DanGiles
ADSM.ORG Senior Member
I haven't watched a TSM server come up for a while, but if I remember correctly (and you'll see this if you start it up in the foreground), it loads in (and reports on) a chunk of pages at a time, regardless or utilization. If you're log is in roll-forward mode (and it looks like that's the case), you'll see TSM verify the last couple of entries.
If your max log util always stays well below 50%, you may want to reduce the space and have a trigger to add log volumes if it ever hits 75% util. That should speed up recovery time. Best practices states the log shouldn't go above 50%, but on a 10+GB log, I usually feel I can hedge that a bit.
If your max log util always stays well below 50%, you may want to reduce the space and have a trigger to add log volumes if it ever hits 75% util. That should speed up recovery time. Best practices states the log shouldn't go above 50%, but on a 10+GB log, I usually feel I can hedge that a bit.
luisvidal
ADSM.ORG Member
- Joined
- Feb 6, 2006
- Messages
- 111
- Reaction score
- 0
- Points
- 0
- Location
- Miami, FL, USA
- Website
- Visit site
I don't know, guys, but 30-40 minutes sound a bit too much to me. I have servers with a 32GB DB and 12GB log, and they don't take more than 10 minutes to come up.
BBB
ADSM.ORG Moderator
What is it doing for that 30-40 minutes?
Start it up manually from the command line and you'll see where the delay is. It'll either be in the log processing, or it could be to do with your disk pools. Do you have big disk pools with a lot of data in them (not file pools, disk pools)?
Start it up manually from the command line and you'll see where the delay is. It'll either be in the log processing, or it could be to do with your disk pools. Do you have big disk pools with a lot of data in them (not file pools, disk pools)?
Hi
Some new numbers:
TSM 5.5.3 (Windows)
BUFPOOLSIZE 56000
LOGPoolsize 512
Logmode Normal
DB Utilization ~100 Mb
LOG____[GB]__0,04__12___0,04___12
DB_____[GB]___0,2__0,2___50,2___50,2
Startup_[sec]___10__90____110___360
It's nonlinear dependence.
Efim
Some new numbers:
TSM 5.5.3 (Windows)
BUFPOOLSIZE 56000
LOGPoolsize 512
Logmode Normal
DB Utilization ~100 Mb
LOG____[GB]__0,04__12___0,04___12
DB_____[GB]___0,2__0,2___50,2___50,2
Startup_[sec]___10__90____110___360
It's nonlinear dependence.
Efim
umur
ADSM.ORG Senior Member
My largest TSM start in 1-2 minutes with 7GB log and 55GB db (45% utilised), your issue doesn't seem to be a log one. If I were to venture a guess, I would check your disks for any bad sectors, just my two cents.
Doesn't that depend on RAM and CPU as well?
Doesn't that depend on RAM and CPU as well?
The database is 143 GB with 77% utilized.
For storage pools, I have 30 TB of FILE and 7 TB DISK
Do DISK pools have a negative affect on the startup time?
I will probably restart it later today to see what it is doing unless I am told this is how long a TSM server of this size should take. So I just run "dsmserv" and not use the "quiet" argument to do this? We usually start it in the background with "quiet".
carlisr
ADSM.ORG Member
I've called IBM before about slow startup problems on my TSM servers. It took about an hour for the server to come up and my DB is only 8GB. We saw that it was going through every volume in the volhist file. We commented out the volhist entry in the dsmserv.opt and the server would come up in a couple of minutes. Now I just leave the line commented out and backup the volhist to a file everyday.
