tag:blogger.com,1999:blog-13518440.post113457471404549456..comments2023-12-12T04:39:52.103-08:00Comments on TSMAdmin: Unload/Load of DB pitfallChad Smallhttp://www.blogger.com/profile/02637281120881655693noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-13518440.post-1155216290865805292006-08-10T06:24:00.000-07:002006-08-10T06:24:00.000-07:00Any TSM Server patch levels ending with a ~.0 alwa...Any TSM Server patch levels ending with a ~.0 always has some exposures/bugs. Always go for a version that does not end with ~.0 as this can be a beta release ie. not properly regression tested. AC 2006.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-13518440.post-1135167273381331062005-12-21T04:14:00.000-08:002005-12-21T04:14:00.000-08:00Hi,5.3.2.0 is not enough - I was on 5.3.2.0 and ha...Hi,<BR/>5.3.2.0 is not enough - I was on 5.3.2.0 and had to go to 5.3.2.1<BR/>Your DB size is about 5 times larger than mine (so the full DB backup time) so I expect the unload/load <BR/>is going to take 5 times more time - so a day for each (with no problem encountered!). Maybe more .... can your backup system be down for such a long time?<BR/>Maybe Chad's suggestion for starting a fresh instance is a way - but it depends on your environment.Harry_Redlhttps://www.blogger.com/profile/17950374908364822243noreply@blogger.comtag:blogger.com,1999:blog-13518440.post-1135108411973254442005-12-20T11:53:00.000-08:002005-12-20T11:53:00.000-08:00Chad, Per reading your and harry's comment..I havi...Chad, <BR/>Per reading your and harry's comment..I having a second thought to do re-org of database...database size is 141Gb and about 89% utilized...database backup take 3-4/hrs...I update the TSM server from 5.1.8 to 5.3.2.0...any thing i should watch for..? <BR/><BR/>-Atif<BR/>813-486-4953Atifhttps://www.blogger.com/profile/15344676944951909746noreply@blogger.comtag:blogger.com,1999:blog-13518440.post-1134584102735792662005-12-14T10:15:00.000-08:002005-12-14T10:15:00.000-08:00Defragmenting the TSM DB is a nightmare. We had o...Defragmenting the TSM DB is a nightmare. We had one that ran over a week and in the meantime we started a new TSM instance...well guess what we never went back to the defragged one because there was too much data now in the new instance. We actually had TSM support tell us you are better off starting a new instance and letting the old data expire rather than defragging. This is why TSM needs an enterprise DB backend. Too much is dependent on DB performance and current the TSM DB is too old school to keep up with demands.Chad Smallhttps://www.blogger.com/profile/02637281120881655693noreply@blogger.com