hello Richard, right - fooling around with dsmserv audit is really nonsens, but if you get problems with your database, and tsm-support tells you: audit please, next question is how long will it take? - I never got an answer - and so I am glad that somebody wrote down his experiences, how long an audit will take ... - and thats the only reason why you should take a look at this page.
But if your customer asks you: Could you please tell me, why I can´t restore my server? You will be glad if you have that simple calculating example - it´s better than telling him: oh there´s a problem and IBM support is fixing it, but we can´t tell how long it takes .. OK kids out there: don´t do this at home (auditing without having problems, and if you have, take the phone and ask IBM)- and sorry, I will never post any dangerous links again. Stefan -----Ursprüngliche Nachricht----- Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von Richard Sims Gesendet: Donnerstag, 6. Dezember 2007 14:59 An: ADSM-L@VM.MARIST.EDU Betreff: Re: [ADSM-L] AW: [ADSM-L] DB Audit On Dec 6, 2007, at 4:23 AM, Lehmann, Stefan wrote: > Hello Andy, > > it´s a fact that audits are painfully slow ... - some weeks ago my tsm > productive DB 30GB DB-Size on a p570 and a DS8100 (AIX 5.3/TSM > 5.4.1.2) needed an audit - 12 hours later the audit was done !! So I > think the audit process doesn´t care about fast hardware .. maybe you > find the pages on http://www.lascon.co.uk/d005106.htm#dbaud > useful - here are some facts and calculating examples described.. > While well-intended, that Web page fails to advise the uninitiated that performing a Fix=Yes audit to correct database problems without TSM Support direction can result in worse problems, including data loss. Structural problems and inconsistencies in any database system can be much more complex than a vanilla utility can properly deal with. If you have reason to believe that your TSM database has problems, contact TSM Support for assistance in dealing with them: do not attempt amateur surgery. The data represented in the database does not belong to you, and its owners put it there with the full expectation that you would fully safeguard it until they need it. Database problems often result from not following TSM recommendations for mirroring and proper server operation, so assure that procedures are as they should be, first. If your database does not exhibit any problems, don't monkey with it. Richard Sims
