Also I would like a answer to my original question. While I appreciate the review of the scripts I would still like to know what the significant meaning is to the error code.
You need to check that part with Oracle as error code comes from their side. I checked similar issue with AWS on ORA forum (see RMAN and Amazon Web Services | Oracle Community) and there they do not use commas, but rather space - have you tried that? Most likely that will get you going.
Thank you for the reply, but you are incorrect as this error code being reported by the Media Management Library comes from the DDBoost code. I know this because Oracle has advised that Additional Information Codes are reported by the vendor type being used, TSM, Data Domain, etc...etc...
As for my script, my syntax or use of it is not the problem nor my question. Its failing when we set the database parameter "backup_tape_io_slaves=TRUE" and restart the DB. The backup will fail with this error code "Additional information: 3978"
Please keep reading...
Now if I take that same database and the same RMAN script and set the parameter to "backup_tape_io_slaves=FALSE" then restart the database the back up completes wit no error and everyone is happy...
Now normally you don't need "backup_tape_io_slaves=TRUE" because its sole function with DDBoost is to allow for Managed File Replication. And since we don't use MFR and we replicate our MTRee its not needed. So I know my script is fine because all my other backups using it are working. My question was never about my script or failing backups...
"We need to know what error code 3978 is. We are working on different combinations of RMAN parameters and this one error seems to be constant. "
Which means we are trying different parameter combinations for testing purposes, and this one error when using "backup_tape_io_slaves=TRUE" is popping up when setting the DB parameter. We would simply like to know what it means. And yes it is a EMC error code....Oracle has even confirmed it is not them.
The reason why I said ORA could point out to what additional information points to is because of API handshake which is the same for all vendors communicating with Oracle (see Troubleshooting RMAN Operations - there they mention range only valid for 7k so we still do not know what it is for 3k).
BACKUP_TAPE_IO_SLAVES default is false so I it is expected it would work this way. Do you see anything related in alert log when this fails while using this set to true? As you said, this is needed only with MFR (there is at least one article indicating that), you can skip it, but I agree it would be interesting to see why/where does it fail. I think to learn more, you may also wish to request official support ticket to get engineering values or/and debug binary which can provide more details.
We are having the same exact issue. We have been working with Oracle support, but no solution. But I did find an odd work around. We are using Oracle RAC 11.2.0.3 on Solaris sparc 64bit. If you shutdown all instances of the database, and start one instance manually using SQL*plus, then the RMAN script it works, with BACKUP_TAPE_IO_SLAVES=TRUE. It looks like some interaction with the GRID_HOME/bin/oraagent.BIN could be a problem, but not sure at this time. Requesting additional information from EMC on exact nature of the 3978 code. Same problem also exist with 11.2.0.4 on an Oracle Restart envrionment, which also used oraagent.BIN to startup the database instances.
crazyrov
4 Operator
•
1.3K Posts
0
August 10th, 2015 03:00
Hello PeterDragon,
Have you set the path variable in the RMAN script that you are running, typically it is as follows :
SBT_LIBRARY=/usr/lib/ddbda/lib64/libddboostora.so
PeterDJr
5 Posts
0
August 10th, 2015 05:00
We are not using that exact lib, but yes we are setting it, below is one example of the channels being allocated.
allocate channel ch01 device type 'SBT_TAPE' MAXOPENFILES 1 MAXPIECESIZE 512G PARMS 'BLKSIZE=1048576,SBT_LIBRARY=/oracle/product/11.2.0.3/db/lib/libddobk.so,ENV=(LD_LIBRARY_PATH=/oracle/product/11.2.0.3/db/lib,STORAGE_UNIT=ORA_LSU,BACKUP_HOST=DDHOST.example.com,ORACLE_HOME=/oracle/product/11.2.0.3/db)' SEND 'set username USER
password HIDDEN servername DDHOST.example.com;
Also if I set " backup_tape_io_slaves=FALSE." the backup works.
crazyrov
4 Operator
•
1.3K Posts
0
August 10th, 2015 06:00
I still dont see SBT_LIBRARY defined in your script !
SBT_LIBRARY=<$ORACLE_HOME>/lib/libddobk.so
PeterDJr
5 Posts
0
August 10th, 2015 07:00
allocate channel ch01 device type 'SBT_TAPE' MAXOPENFILES 1 MAXPIECESIZE 512G PARMS 'BLKSIZE=1048576,SBT_LIBRARY=/oracle/product/11.2.0.3/db/lib/libddobk.so,ENV=(LD_LIBRARY_PATH=/oracle/product/11.2.0.3/db/lib,STORAGE_UNIT=ORA_LSU,BACKUP_HOST=DDHOST.example.com,ORACLE_HOME=/oracle/product/11.2.0.3/db)' SEND 'set username USER
password HIDDEN servername DDHOST.example.com;
PeterDJr
5 Posts
0
August 10th, 2015 10:00
Also I would like a answer to my original question. While I appreciate the review of the scripts I would still like to know what the significant meaning is to the error code.
Additional information: 3978 <---
ble1
4 Operator
•
14.4K Posts
0
August 13th, 2015 16:00
You need to check that part with Oracle as error code comes from their side. I checked similar issue with AWS on ORA forum (see RMAN and Amazon Web Services | Oracle Community) and there they do not use commas, but rather space - have you tried that? Most likely that will get you going.
PeterDJr
5 Posts
0
August 14th, 2015 04:00
Thank you for the reply, but you are incorrect as this error code being reported by the Media Management Library comes from the DDBoost code. I know this because Oracle has advised that Additional Information Codes are reported by the vendor type being used, TSM, Data Domain, etc...etc...
As for my script, my syntax or use of it is not the problem nor my question. Its failing when we set the database parameter "backup_tape_io_slaves=TRUE" and restart the DB. The backup will fail with this error code "Additional information: 3978"
Please keep reading...
Now if I take that same database and the same RMAN script and set the parameter to "backup_tape_io_slaves=FALSE" then restart the database the back up completes wit no error and everyone is happy...
Now normally you don't need "backup_tape_io_slaves=TRUE" because its sole function with DDBoost is to allow for Managed File Replication. And since we don't use MFR and we replicate our MTRee its not needed. So I know my script is fine because all my other backups using it are working. My question was never about my script or failing backups...
"We need to know what error code 3978 is. We are working on different combinations of RMAN parameters and this one error seems to be constant. "
Which means we are trying different parameter combinations for testing purposes, and this one error when using "backup_tape_io_slaves=TRUE" is popping up when setting the DB parameter. We would simply like to know what it means. And yes it is a EMC error code....Oracle has even confirmed it is not them.
Thanks,,,
ble1
4 Operator
•
14.4K Posts
0
August 15th, 2015 15:00
The reason why I said ORA could point out to what additional information points to is because of API handshake which is the same for all vendors communicating with Oracle (see Troubleshooting RMAN Operations - there they mention range only valid for 7k so we still do not know what it is for 3k).
BACKUP_TAPE_IO_SLAVES default is false so I it is expected it would work this way. Do you see anything related in alert log when this fails while using this set to true? As you said, this is needed only with MFR (there is at least one article indicating that), you can skip it, but I agree it would be interesting to see why/where does it fail. I think to learn more, you may also wish to request official support ticket to get engineering values or/and debug binary which can provide more details.
davidmelton
1 Message
0
August 28th, 2015 14:00
We are having the same exact issue. We have been working with Oracle support, but no solution. But I did find an odd work around. We are using Oracle RAC 11.2.0.3 on Solaris sparc 64bit. If you shutdown all instances of the database, and start one instance manually using SQL*plus, then the RMAN script it works, with BACKUP_TAPE_IO_SLAVES=TRUE. It looks like some interaction with the GRID_HOME/bin/oraagent.BIN could be a problem, but not sure at this time. Requesting additional information from EMC on exact nature of the 3978 code. Same problem also exist with 11.2.0.4 on an Oracle Restart envrionment, which also used oraagent.BIN to startup the database instances.