TSM Server: AIX 4.3.3, TSM 18.104.22.168
RMAN Server: AIX4.3.3, TDP 5.2
RMAN Client: AIX 4.3.3, TSM 5.1.5, TDP5.2
The installation guide seems to be a little fuzzy on this topic…
At some point during the backup process we get this error in our
23:28:55 ANS4994S TDP Oracle AIX ANU0599 ANU2602E The object
/adsmorc//c-3756527612-20030714-03 was not found on the TSM Server
After doing some of my own research I realize its telling me that the
/adsmorc file space does not exist. My question is…. where is is supposed
to exist? Am I supposed to create an adsmorc file system or directory on the
TSM server, on the TDP/RMAN server, or the client? Is anything ever going to
get put there? Does it need to be its own mount point?
Any help would be greatly appreciated.
Thanks in advance
From: David Longo
You should NOT create a /adsmorc filesystem or mount point.
The docs are correct, this is just the filespace name used on the server
for this node name. You could change it to something else if you
want with the TDPO_FS env variable.
The message you are getting tells you that that particular object name
does not exist on the server. Do a “q filespace blah” for the node
name you are using and you should see /adsmorc.
Is this happening when the RMAN scripts try to delete an object?
Thanks for that bit of information… it definitely clears some things up.
According to the docs, we should be using unique TDPO_FS names for each node
we are backing up using TDP, correct?
After doing the query and some further investigation into the BACKUPS table,
it appears we are getting this message because of a missing “-“….
When I do a select in the BACKUPS table, the LL_NAME shows up as:
However, in the error we are getting, the name of the object is:
Any idea why this is??
No idea about the missing “-“. I believe the long name is built by
Oracle/RMAN and not TSM. So need to look there. I don’t know
how that is put together, need to get with your DBA or Oracle on that.
(I just looked at mine and all my RMAN backups use “_” as separators
and have different numbering format, but still a long name.)
We have unique names for each node with TDPO_FS, it’s not really
required though, you could use /adsmorc for each one. I think a good
naming standard for your environment is best.
My backups worked fine during several months, however, since some days ago, they often fail with a message indicating that some object like the one specified in the subject was not found on the TSM Server.
There are two things that could be happening. Your RMAN catalog is out of sync with TSM. Run the tdposync command against your DB instance. Or Your datafiles were open during the first scan, and then removed around the second scan. Acting like a temporary tablespace file. If the backup routine is passing, I would not worry about it. If the backup routine is failing, research what RMAN is doing outside of the TDP.
Typically, this error occurs in conjunction with some other errors. This should only be seen during backup at the end when Oracle tries to confirm that the object they just backed up actually got stored. If the object is not found, that indicates that some error occurred during the backup. You should check the activity log on the TSM Server prior to this error for some other indication of an error, and the tdpoerror.log for any other error that might have occurred before this.
Back to business, I finally have encountered this error message myself and I do have some news on this as well as looking for the final answer. This message have a direction relationship to TCP/IP connection errors, where sessions are being rejected by the TSM server. What I have found out with my research is , when RMAN dynamically creates a backuppiece name for the control files that are being saved during the process. At the same time RMAN is looking for this unique backuppiece name on the TSM server to remove it. The error message is the result of not finding this entry. The next entry is supposed to be the actual RMAN transmission displaying the catalog name, and the size of the transaction. My research suggests that we should suppress these error messages or redirect the errorlogs for better isolation.
My question is this – if this is TCP/IP related, will extending the COMMTIMEOUT to 600 or greater allow for enough time for RMAN to complete its backuppiece name generation and file transmission, thus removing the error messages??
This error message has been around for awhile, and since we are now Oracle 10g, there does not seem to be a permanent solution.
If you all feel that extending the server option and proven successful, let me know. If not and there is more to it, please share this as well. I am nevertheless contacting IBM for an answer as well.
Trackback from your site.