Thank very much to all, the solution was to issue a cleanup backupgroup and
then the dsmserv auditdb ran really quickly (less than an hour)
In fact, I upgraded my server recently from 4.1.3 and I think this was a
problem coming from this version.

Regards


Etienne GUILLAUMONT
e-mail : [EMAIL PROTECTED]

RGB Technologie
Parc d'Innovation, Bâtiment PYTHAGORE
11 Rue Jean SAPIDUS
67400 ILLKIRCH
Tél :  03 90 40 60 60
Fax : 03 90 40 60 61


                                                                                       
                                                       
                    Sias Dealy                                                         
                                                       
                    <[EMAIL PROTECTED]        To:     [EMAIL PROTECTED]                
                                                         
                    com>                 cc:                                           
                                                       
                    Sent by:             Subject:     Re: Problem with audit DB        
                                                       
                    "ADSM: Dist                                                        
                                                       
                    Stor Manager"                                                      
                                                       
                    <[EMAIL PROTECTED]                                                 
                                                            
                    RIST.EDU>                                                          
                                                       
                                                                                       
                                                       
                                                                                       
                                                       
                    27/03/2003                                                         
                                                       
                    15:37                                                              
                                                       
                    Please                                                             
                                                       
                    respond to                                                         
                                                       
                    hnre                                                               
                                                       
                                                                                       
                                                       
                                                                                       
                                                       




ANR0102E asalloc.c(6428): Error 1 inserting row in
table "AS.Segments".
This is a known error with TSM 4.1, APAR IC33270 , such that
when a volume becomes emptied, not all the pointers get
deleted, and an audit volume fix=yes may or may not correctly
delete them either.

It is a volume-related problem, so if you mark the tapes
involved "unav", or if they are scratch, remove them from the
robot inventory, the problem will be alleviated although it has
not gone.

Since you are running TSM 5.1.6.2, I wonder if this old issue
is re-appearing.

Sias


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag


---- On    , GUILLAUMONT Etienne ([EMAIL PROTECTED])
wrote:

> Hello,
>
> My TSM level is 5.1.6.2
> My database size is 2.3 Gb
> My TSM server is a Ibm RS/6000 43p140 AIX 4.3.3 with a L20
Storagetek (I
> know, It's an old and slow machine, I am waiting a F80 to
replace it)
> I have AIX, NT, 2000, 98 clients (about 10 clients)
>
> The first problem I had was that I received this message
during reclamation
> of My offsite Copy Storage Pool :
>
> ANR0102E asalloc.c(6428): Error 1 inserting row in
table "AS.Segments".
>
> And I still have this message so I can't make any reclamation
in this storage pool
>
>
>
> Etienne GUILLAUMONT
> e-mail : [EMAIL PROTECTED]
>
> RGB Technologie
> Parc d'Innovation, Bâtiment PYTHAGORE
> 11 Rue Jean SAPIDUS
> 67400 ILLKIRCH
> Tél :  03 90 40 60 60
> Fax : 03 90 40 60 61
>
>
>

>
>                     Jurjen
Oskam

>
>                     <[EMAIL PROTECTED]        To:     ADSM-
[EMAIL PROTECTED]
>
>                     NDOUS.ORG>
cc:
>
>                     Sent by: "ADSM: Dist         Subject:
Re: Problem with audit DB
>
>                     Stor
Manager"

>
>                     <ADSM-
[EMAIL PROTECTED]

>
>
>

>
>

>
>

>
>                     26/03/2003
20:12

>
>                     Please respond
to

>
>                     "ADSM: Dist
Stor

>
>
Manager"

>
>

>
>

>
>
>
>
>
> On Wed, Mar 26, 2003 at 04:13:14PM +0100, GUILLAUMONT Etienne
wrote:
> >
> > I had a problem with my TSM db, it couldn't make a
reclamation with an
> > error on the db (some raws could not be deleted as I
remember)
> > So I am trying to do an auditdb but the problem is that I
get the
> > followings messages :
> >
> > ANR4306I AUDITDB: Processed 324433 database entries
(cumulative).
> > ANR4306I AUDITDB: Processed 324433 database entries
(cumulative).
> > ANR4306I AUDITDB: Processed 324433 database entries
(cumulative).
> > ANR4306I AUDITDB: Processed 324433 database entries
(cumulative).
> > ANR4306I AUDITDB: Processed 324433 database entries
(cumulative).
> > ANR4306I AUDITDB: Processed 324433 database entries
(cumulative).
> > ANR9999D imaudit.c(5630): ThreadId<11> Inventory object
0.3081816
> deleted.
> > ANR4306I AUDITDB: Processed 324434 database entries
(cumulative).
> > ANR4306I AUDITDB: Processed 324434 database entries
(cumulative).
> > ANR4306I AUDITDB: Processed 324434 database entries
(cumulative).
>
> You forgot to mention a *lot* of information, for example:
>
>  - What level of TSM are you on?
>  - How large is your database (GB)?
>  - On what type of hardware does the TSM server run?
>  - What kind of clients do you have?
>
>
> For what it's worth, I encountered this problem too, once. It
was on
> a level of TSM that was mishandling Windows 2000 System
Objects. Before
> resolving the problem, an auditdb took hours and hours (2G),
after
> resolving the problem an auditdb took 25 minutes.
>
> Search the archives for the "CLEANUP BACKUPGROUP" command.
*If* the System
> Objects are causing this problem, CLEANUP BACKUPGROUP can
help. Note
> that CLEANUP BACKUPGROUP is only available at later TSM
levels!
>
> --
> Jurjen Oskam
>
> PGP Key available at http://www.stupendous.org/
>

Reply via email to