We are accustomed to accept that Microsoft is having behavior in some
products which Tivoli cannot overcome. But not only M$ does so, and in
this case we are seeing similar Oracle behavior.
Current MML request is "delete that object and I will ignore the error if
it does not exist". If the API allowed to call something like "if this
object exists, delete it", than TDPO would be able to query the TSM server
without producing severe error.
Do not blame IBM/Tivoli for something Oracle must fix.

Zlatko Krastev
IT Consultant






Neil Rasmussen <rasmussn AT US.IBM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06.11.2003 00:29
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TDP for Oracle Errors


Eric,

Oracle 9i introduced the concept of autobackups for the control file.
During the autobackup process, Oracle dynamically generates the
backuppiece name for the control files that are being saved.  During this
backup processing, a unique name is generated by Oracle prior to backing
it up and the TSM Server is then checked to ensure that this backuppiece
name does not exist.

When performing this check for any existing objects that might have this
name, Oracle will first try to delete this file regardless of whether it
exists or not. The return code from the deletion process not finding the
object on the TSM Server is the ANU2602E message.

During the autobackup processing, Oracle calls the Media Management Layer
(Data Protection for Oracle/TSM Server in this case).   Oracle issues the
command to attempt a deletion prior to autobackup of the control file.
Because each MML operation is a unique and distinct session, the MML has
to treat each delete the same. In other words, Oracle gives no hints as to
the type of deletion being performed therefor Data Protection for Oracle
just attempts the delete.

>From Data Protection for Oracle's point of view a file not found during a
delete could be a potentially serious error. For example:
- During the delete the user is actually using a TSM filespace name that
is different than what the objects were originally backed up under.
- The TSM node does not have the backup delete permissions
(backdel=yes|no).
-  During the deletion a different TDPO_NODE is specified than what was
used during backup.
The reason that these are potentially dangerous is that when Data
Protection for Oracle detects an error during delete that a file is not
found or cannot be deleted Oracle specifies that the MML does not return
an error to Oracle. This causes a situation where during normal deletion
Oracle would remove the backuppiece name from it's catalog but the backup
could still exist on the TSM Server there by using up unnecessary storage
space.

Unfortunately, unless we ignore this error altogether then there is
nothing that we (developement) can do. In the mean time the only tips we
can give to work around these error messages during autobackups is for the
user to do the following: Use the DISABLE EVENTS command on the TSM Server
to suppress all ANU0599 ANU2602E messages so there would be no
notification when a the file is not being found during DP for Oracle
processing. For the tdpoerror.log, a different DSMI_LOG could be specified
(in the tdpo.opt file) for the autobackup so that the errorlog would go to
a different directory - in this way these logs could be monitored
separately.


------------------------------

Date:    Tue, 4 Nov 2003 16:28:55 +0100
From:    "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
Subject: TDP for Oracle Errors

Hi *SM-ers!
Our Oracle guys and girls are currently testing DP for Oracle 5.2 on
Oracle
9i. They turned one a new RMAN feature for automated controlfile backup
(for
those of you interested, the command is 'configure controlfile autobackup
on;') Now, whenever a controlfile backup is running it generates the
following error in both the tdpoerror.log and the actlog:

ANE4994S (Session: 1437562, Node: KL1003VC-ORC)  TDP Oracle AIX ANU0599
ANU2602E The object /mount/appl00001//c-213141136-20031104-0e was not
found
on the TSM Server

We had to make a trace to see that this error is generated because TSM
first
checks whether the object exists on the server before allocating it.
I created a PMR for this behavior and level 1 now says: works as designed,
just suppress ANE4994S from the actlog (impossible since ANE4994S is a
generic message) and build something yourself to clear your tdpoerror.log
periodically.
I find this a VERY disappointing reply from IBM
Has anybody encountered this behavior to and maybe found a better way to
solve these errors?
Maybe someone from development listening on this list has a good
suggestion?
I'm really stuck here with the Dutch level 1 support... :-((
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


Regards,

Neil Rasmussen
Software Development
Data Protection for Oracle
rasmussn AT us.ibm DOT com