RMAN backup finish with ORA-07445: exception encountered: core dump

Question

Hi Group,
Repeatly we have problems with RMAN, showing this message, we need to know if this message is related to Oracle Database or is the backup software.
Thanks a lot
/pcpdci/oracle/product/920/admin/PCPDCI_bd/udump/pcpdci_ora_31187.trc
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
ORACLE_HOME = /pcpdci/oracle/product/920
System name:    Linux
Node name:      bd.copesa.cl
Release:        2.6.9-78.ELhugemem
Version:        #1 SMP Wed Jul 9 15:57:33 EDT 2008
Machine:        i686
Instance name: PCPDCI
Redo thread mounted by this instance: 1
Oracle process number: 948
Unix process pid: 31187, image: [email protected] (TNS V1-V3)
*** 2011-04-11 00:58:44.241
*** SESSION ID:(1519.515) 2011-04-11 00:58:44.240
SKGFQ OSD: Error in function sbtwrite2 on line 1031
SKGFQ OSD: Look for SBT Trace messages in file /pcpdci/oracle/product/920/admin/PCPDCI_bd/udump/sbtio.log
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x126, PC: [0xf6abe90b, __GI_strlen()+11]
Registers:
%eax: 0x00000126 %ebx: 0xf6b7dff4 %ecx: 0x00000002
%edx: 0x00000000 %edi: 0x00000000 %esi: 0x00000126
%esp: 0xfeff6154 %ebp: 0xfeff6794 %eip: 0xf6abe90b
%efl: 0x00010202
  __GI_strlen()+0 (0xf6abe900) mov 0x4(%esp),%ecx
  __GI_strlen()+4 (0xf6abe904) mov %ecx,%eax
  __GI_strlen()+6 (0xf6abe906) and $3,%ecx
  __GI_strlen()+9 (0xf6abe909) je 0xf6abe933
__GI_strlen()+11 (0xf6abe90b) cmpb %ch,(%eax)  __GI_strlen()+13 (0xf6abe90d) jz 0xf6abe9aa
  __GI_strlen()+19 (0xf6abe913) inc %eax
  __GI_strlen()+20 (0xf6abe914) xor $3,%ecx
  __GI_strlen()+23 (0xf6abe917) je 0xf6abe933
*** 2011-04-11 00:58:44.570
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [__GI_strlen()+11] [SIGSEGV] [Address not mapped to object] [0x126] [] []
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
ksedmp()+274         call     ksedst()             1 ? 0 ? 0 ? 1 ? 33396562 ?
===========================================================
Tracing started for:
   Application Client :   TDPO Linux86
              Version :   5.4.1.0
===========================================================
SBT-13207 07/12/2010 16:32:29 send2.cpp(412): sbtwrite2(): Exit - DSMSENDDATA() failed. dsmHandle = 1
===========================================================
Tracing started for:
   Application Client :   TDPO Linux86
              Version :   5.4.1.0
===========================================================
SBT-14436 07/12/2010 16:52:58 send2.cpp(412): sbtwrite2(): Exit - DSMSENDDATA() failed. dsmHandle = 1
===========================================================
Tracing started for:
   Application Client :   TDPO Linux86
              Version :   5.4.1.0
===========================================================
SBT-15110 07/12/2010 17:01:58 send2.cpp(412): sbtwrite2(): Exit - DSMSENDDATA() failed. dsmHandle = 1
===========================================================
Tracing started for:
   Application Client :   TDPO Linux86
              Version :   5.4.1.0

Answer 1

Reply from nagulan is correct. Our turned out to be an error with TSM. The disk pool had filled up and it was writing this to tape before allowing the backup to continue. The backup didn't handle the "pause" event well and failed out. We only get this with V9 RMAN, not V10 or V11 RMAN backups. This has to be addressed by the backup vendor for V9 as the Oracle RMAN software doesn't seem to handle it well. Maybe configuring a really large timeout for responses MAY fix this, depending on what the code returned from the backup software vendor is and why RMAN isn't happy with it.
In the end it is an issue between V9 RMAN and the backup software we run TSM. Maybe version incompatibility or maybe just V9 is not that robust.