Richard my sincerest apologies to you and the group. I consider myself scolded ! Twice!!
TSM Verson 5.1.0 is the server level. Taking the server up to say 5.1.6 may well fix it Richard. Unfortunately, we live an far from perfect world and we have SAN agents running that need to go up at the same time. These agents are across a great many nodes. So these issues need also to be considered. Unloaddb failed. This is an undocumented feature in 5.1.0 so the unload and reload is not on. Seems also that on closer look simultaneous writes to different storage pools may be causing and issue. (This we expect is fixed on 5.2) ???? Once again we need to consider the SAN agents on the other machines. These need to come up to version 5.2 at the same time and the nodes need a reboot if not mistaken. This is not as a simple task in our environment and will need to be phased in over time. The upside may well be the phase in process, which may be that we dedicate a new 5.2 Server and move across the nodes as we upgrade each node. What we need to consider is the method of eventually marrying the two machines after all is done! Meantime, we'll keep a close eye on the monitoring of the database, and recovery log consumption etc, until we can move up to a Version 5.2. We hope there are no gotcha's there. If there gotchas then I'd sure appreciate a posting. Thanks again for the scolding. Stephen :-) -----Original Message----- From: Richard Sims [mailto:[EMAIL PROTECTED] Sent: 16 December, 2003 9:33 PM To: [EMAIL PROTECTED] Subject: Re: Intermittant TSM Server - Database stops ... >Since then, TSM Server stops at random times. (no messages in the actlog) The *SM server has traditionally been programmed to produce an error log in its server directory when it crashes. Have a look for such. It could well be that simply boosting your maintenance level will resolve the issue. A server with such issues needs to be carefully monitored. In particular, watch Database and Recovery Log consumption as the server operates through the day, and watch for space constraints and anomalies. Your surviving Activity Log from the crash vicinity may record the start of some highly-consumptive process which may need investigation. Richard Sims, BU
