Tivoli TDP for Oracle - ANU2614E error

stevenma

ADSM.ORG Member
Joined
Jan 16, 2003
Messages
2
Reaction score
0
Points
0
Website
Visit site
We're using TSM v5.4 and TDP for Oracle v5.3 (Oracle 10gR2/Linux). Here's what we're trying to do:

- RMAN Backup a DB on one server using the TDPO client (this works fine)
- Restore the same DB using RMAN and the TDPO client on another server (this is the problem)

After backing up the DB on server #1, I modified server #2's tdpo config files (dsm.sys and tdpo.opt) to make it impersonate server #1. I ran tdpoconf password and changed the password to server #1's, which ran successfully. When we try to RMAN restore the DB on that node, we get the following error message:

ORA-19511: Error received from media manager layer, error text:
ANU2614E Invalid sequence of function calls to Data Protection for Oracle
failover to previous backup

Any ideas? Is what we're looking to do valid? This is a DR test to restore a database on a server that has died, to a new server. Sounds simple enough, but I'm sure we're missing something. Reviewing the error message on IBM's site and google just points us to "call oracle support" (which we'll do, but I'm guessing they won't help much)
 
With RMAN there is an internal database number that is unique to each system.
ie, when you connect to RMAN initially, it gives you this unique number it has assigned to a database.

Wonder if it's getting caught on that?...?
Like it can't identify the second instance has access to the first instances data?
 
RMAN needs to reference a totally separate dsm.opt file that is equivalent to server two. This means a second stanza in the dsm.sys files and a separate dsm.opt per server. To validate run tdpoconf showenv -tdpo_optfile=servername.opt - if you receive a response then you are OK
 
With RMAN there is an internal database number that is unique to each system.
ie, when you connect to RMAN initially, it gives you this unique number it has assigned to a database.

Indeed if you want to perform complete recovery of your database, you need its DBID. Below you can see commands used in a successfully tested recovery scenario using control files based backups (as opposite to rman catalog).

export ORACLE_SID=orcl
rman target /
set dbid 2061194014;
startup nomount pfile='/orasw/app/oraprod/product/10.2.0/dbs/initorcl.ora';

run {
allocate channel ch1 type 'SBT_TAPE' parms 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt.ORCL)';
restore controlfile from autobackup until time "TO_DATE('23/02/07:06:20', 'DD/MM/YY:HH24:MI')";
alter database mount;
set until time "TO_DATE('23/02/07:06:00', 'DD/MM/YY:HH24:MI')";
restore database;
recover database;
release channel ch1;
}

alter database open resetlogs;

So first you define Oracle SID, connect to this instance and the you set the DBID to the appropriate value. After that you start the instance in nomount mode where you can also set which pfile to use. Then you run recovery script, where you set the TDPO_OPTFILE parameters, restore control files from autobackup, mount database, restore dbfiles, recover database with archive logs and finally open database with reset logs option. This is also a good time to do new L0 or full backup of your database. Be careful, if you are not using RMAN catalog; there is no other option to restore your control files from TSM backup in case of DR, but from autobackup which has to be configured before you start to backup your database to TSM. You can do that using this in the RMAN command line:

CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt.ORCL)';

By default autobackup is off and default device is DISK. So we enable autobackup, change default device type to TSM and define the TDPO_OPTFILE parameter to the RMAN. Hope this helps, at least I had no problems when testing 2TB database complete restore/recovery on an empty instance. Note that also Oracle program files and the rest of the structure was also restored using TSM BA client.

Regards Tom
 
Thanks!

Many thanks to all who responded to my initial question. For the record it turns out that I simply missed changing the TDPO_FS= line in the tdpo.opt file on server #2 from its original filespace, to server #1's filespace. Once I did that the restore from server #1's backup onto server #2 worked perfectly.

I appreciate all the answers, they certainly got me looking in the right direction!
 
Back
Top