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:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag von
Richard Sims
Gesendet: Donnerstag, 6. Dezember 2007 14:59
An: ADSM-L AT VM.MARIST DOT 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