This is the issue that requires the special fix. Call support, LEVEL 2 has
a fix for this.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-----Original Message-----
From: Suad Musovich [mailto:s.musovich AT AUCKLAND.AC DOT NZ]
Sent: Tuesday, October 08, 2002 12:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: 5.1.1.6 Upgrade (cleanup backupgroups)
Hmm, I tried running the "cleanup backupgroups" command and got the
result:
ANR0106E imutil.c(8262): Unexpected error 0 fetching row in table
"Object.Ids"
<Sigh> Seems to be a known problem. (and I'm running 4.2.2.12)
Suad
--
APAR= IC34375 SER= IN INCORROUT
TSM SERVER CLEANUP BACKUPGROUPS UTILITY NEEDS ENHANCEMENTS. ANR0106E
UNEXPECTED ERROR FOR OBJECT.IDS AND RESTARTABILITY
Status: CLOSED Closed: 09/30/02
Apar Information:
RCOMP= 5698TSMAX TSM AIX SERVER RREL= R420
FCOMP= 5698TSMAX TSM AIX SERVER PFREL= F999 TREL= T
SRLS: NONE
Return Codes:
Applicable Component Level/SU:
R420 PSY UP
R410 PSN UP
Error Description:
The cleanup backupgroups utility was created to cleanup orphaned entries
within a TSM server database table. While running this utility function to
perform the cleanup some addtion problems with the datbase entries were
encountered. When this occured ANR0106E imutil.c(3804): Unexpected error 0
fetching row in table "Object.Ids" was received. In addtion due to the long
running nature of this cleanup activity an enhancment to this code was
needed to make it a server process that could be cancelled and restarted if
needed. If restarted it should begin processing where it left off.
Local Fix:
Apply patch 4.2.2.12 or higher, available through
Tivoli Web Page to resolve this problem, or fixing
PTF when available.
Problem Summary:
****************************************************************
* USERS AFFECTED: 4.2.2.x and 5.1.x server users needing to *
* run the CLEANUP BACKUPGROUPS utility to *
* correct the orphaned group member problem. *
****************************************************************
* PROBLEM DESCRIPTION: The CLEANUP BACKUPGROUPS utility is *
* very difficult to manage in a *
* production environment. *
* It runs as a foreground process *
* without displaying any status and can *
* not be stopped and restarted. *
****************************************************************
* RECOMMENDATION: Install 423 ptf. *
****************************************************************
The CLEANUP BACKUPGROUPS utility runs as a foreground
process without displaying any status and can not be
stopped and restarted.
Temporary Fix:
Comments:
MODULES/MACROS: NONE
Problem Conclusion:
The CLEANUP BACKUPGROUP utility has been enhanced to run as
a backup ground process that:
Can be queried for progress.
Can be canceled.
Can be restarted and will restart where it left off.
On Tue, 2002-10-08 at 08:13, Lisa Cabanas wrote:
> So, Paul, would you recommend 4.2.1.12 as stable? I am at 4.2.1.9 (on
> AIX) and am unable to test 5.1 at this point. 4.2.1.9 to 4.2.2.12
> wouldn't seem to be that nasty of a jump.
>
> thanks
> lisa
>
>
>
> "Seay, Paul"
> <seay_pd@NAPTH To: ADSM-L AT VM.MARIST DOT EDU
> EON.COM> cc:
> Sent by: Subject: Re: 5.1.1.6 Upgrade
(cleanup backupgroups)
> "ADSM: Dist
> Stor Manager"
> <ADSM-L AT VM DOT MAR
> IST.EDU>
>
>
> 10/02/2002
> 07:29 PM
> Please respond
> to "ADSM: Dist
> Stor Manager"
>
>
>
>
>
>
> OK, I ran cleanup backupgroups for a week and it returned 1.5M pages
> to my database. However, that was not continuous time. I would run
> it for several hours and cancel it as needed to prevent conflicts with
> other stuff. My experience was it literally shuts down backup stg and
> database backups. I have not had to halt the server to get it out of
> the system. If you had to halt the server, you probably have an
> additional problem.
>
> Note that cleanup backupgroups is also in the release that I am
> running 4.2.2.12. You do not have to go to 5.1.1.6 to get this fix.
> The system object problem occurs in 4.2 as well.
>
> The time to run the cleanup backupgroups has not specific run time.
> It will run as long as it needs to seconds, minutes, hours, days,
> weeks, years, decades, centuries. Whatever it takes. Boy is this a
> nasty issue.
>
> Paul D. Seay, Jr.
> Technical Specialist
> Naptheon Inc.
> 757-688-8180
>
>
> -----Original Message-----
> From: Maria Ragan [mailto:mragan AT YCI DOT COM]
> Sent: Wednesday, October 02, 2002 10:59 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: 5.1.1.6 Upgrade
>
>
> Last week we moved the TSM server from an IBM H70 running AIX 4.3.3
> and TSM 4.2.2.4 to an IBM 6H1 running AIX 5.1.0.2 then upgraded to TSM
> 5.1.1.6. My database is about 51 gigs in size.
>
> Tivoli support told me to run "cleanup backupgroup" to cleanup
> orphaned records when I ran into problems with expiration. I was told
> other activities (such as backing up the database and client backups)
> could take place while the command ran. After the "cleanup
> backupgroup" command was running for 5 hours and a backupdb had been
> running for 2 hours getting a 4th of the way finished when it
> normally, takes 30 minutes, I halted the server to kill the cleanup
> command. Support tells me the cleanup command could take 2 days.
> They also tell me the next release (2 weeks) should include the
> ability to background the command and restart where you left off.
>
> Does anyone have any experience running cleanup backupgroup to
> validate the 2 day run time?
>
> Thank you,
> Maria
> Maria Ragan
> Systems Engineer
> Unix Systems Group
> Yamanouchi Consumer, Inc.
|
