There is also a problem with Oracle not deleting the backups. This is the
response we received from Oracle support (we are running TSM 3.7.3):
'I have managed to track down the problem to bug:1420513. The base bug is
bug:1419888 and details on how to delete the orphaned backuppieces - this is
a problem unique to Tivoli-ADSM'.
'A back port has been raised but it is not fixed until 8.0.6.3 patchset, due
sometime in late February 2001'
> Bob Smith - Core Infrastructure EMEA
> EDS UK c/o Rolls-Royce plc, Derby UK
> tel: 01332 522029
> email: [EMAIL PROTECTED] - EDS userid LZTZ3V
>
>
>
>
>
>
-----Original Message-----
From: Loon, E.J. van - SPLXM [mailto:[EMAIL PROTECTED]]
Sent: 12 February 2001 13:44
To: [EMAIL PROTECTED]
Subject: Re: Orphaned Oracle backups
Hi Wanda!
A while ago I promised you that I would have our Oracle guys test the Oracle
delete with Oracle 8 and TDP for Oracle.
We started an Oracle delete with an invalid tcpserveraddress. The job
reports errors but the backup files are being removed from the Oracle
catalog!
This way inconsistency are still possible and it will result in orphaned
backup files. I guess it's just the way it's designed, so one still has to
perform a manual compare between TSM storage and the Oracle catalog every
now and then.
Kindest regards,
Eric van Loon
-----Original Message-----
From: Prather, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 18, 2001 23:07
To: 'Loon, E.J. van - SPLXM '
Subject: RE: Orphaned Oracle backups
Hi Eric,
Yes, I had problems with my data store growing at an unreasonable rate, and
I finally figured out that we had about a TB of backup data that was due to
these "orphans".
Part of the problem occurred when we upgraded one system from Oracle 7 to
Oracle 8. The RMAN software (Oracle 8) did not recognize the backups that
were previously done by EBU (Oracle 7), so the older backups never got
deleted. That was really an oversite on the part of the person who set up
RMAN for that host.
We have also found that many of the "orphans" occurred due to deletes
failing. We have a script that regularly runs to delete old backup
versions. The delete apparently does not or cannot check on return codes
from the API call to TSM. If the script starts up, but the connection to
the TSM server fails with an error, the deletes from the Oracle catalog are
done anyway. We have seen this happen due to password failures with the
ADSM 3.1 agent and EBU (Oracle 7), for example. I do not know for sure if
there is still this exposure with the TDP agent and RMAN (Oracle 8). (It
would be easy to test - change the TSM agent's password on the server end,
then try to run the deletes.)
We could find no way to correct this problem using standard TSM or Oracle
tools. We got around it by renaming the filespace, letting new backups run
for 90 days, then blowing the old filespace away.
That let me take care of the problem without having to use the unsupported
"delete" command as you did.
I think it demonstrates again the need for a SUPPORTED DELETE OBJECT
command.
Wanda
-----Original Message-----
From: Loon, E.J. van - SPLXM
To: [EMAIL PROTECTED]
Sent: 1/18/01 5:20 AM
Subject: Orphaned Oracle backups
Hi *SM-ers!
Today I have compared the backup files on TSM with the file references
in
the Oracle catalog. I discovered a lot of "orphaned" backup files: files
in
TSM which are not in the Oracle catalog.
I had to delete these files manually by using the undocumented DELETE
OBJECT
0 command.
Has anybody done the same thing and did you also discover
irregularities?
Has anybody found the cause or know how to prevent this?
Thanks for your reply in advance!
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines
**********************************************************************
This e-mail and any attachment may contain confidential and privileged
material intended for the addressee only. If you are not the addressee,
you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to
this e-mail or attachment is strictly prohibited, and may be unlawful.
If you have received this e-mail by error, please notify the sender
immediately by return e-mail, and delete this message. Koninklijke
Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees
shall not be liable for the incorrect or incomplete transmission of this
e-mail or any attachments, nor responsible for any delay in receipt.
**********************************************************************
