{"id":428,"date":"2013-04-24T15:52:14","date_gmt":"2013-04-24T21:52:14","guid":{"rendered":"http:\/\/www.ecimulti.org\/blog\/?p=428"},"modified":"2013-04-24T15:57:31","modified_gmt":"2013-04-24T21:57:31","slug":"emc-avamar-rman-backup-fails-with-rman-06403-ora-01034-and-ora-27101","status":"publish","type":"post","link":"https:\/\/www.ecimulti.org\/blog\/?p=428","title":{"rendered":"EMC Avamar RMAN backup fails with: RMAN-06403, ORA-01034 and ORA-27101"},"content":{"rendered":"<p>Hello folks,<\/p>\n<p>I had a really interesting (to me) Avamar RMAN backup failure after a system was rebooted. The system had been backing up perfectly for months, and then all of the sudden:<\/p>\n<blockquote><p>Recovery Manager: Release 11.2.0.3.0 &#8211; Production on Wed Apr 24 13:59:45 2013<br \/>\nCopyright (c) 1982, 2011, Oracle and\/or its affiliates. All rights reserved.<br \/>\nRMAN&gt; @@RMAN-blahblah-1543-cred1.rman<br \/>\n2&gt; connect target *;<br \/>\n3&gt; **end-of-file**<br \/>\n4&gt; run {<br \/>\n5&gt; configure controlfile autobackup on;<br \/>\n6&gt; set controlfile autobackup format for device type sbt to &#8216;CONTROLFILE.blahblah.%F&#8217;;<br \/>\n7&gt; allocate channel c0 type sbt PARMS=&#8221;SBT_LIBRARY=\/usr\/local\/avamar\/lib\/libobk_avamar64.so&#8221; format &#8216;%d_%U&#8217;;<br \/>\n8&gt; send channel &#8216;c0&#8217; &#8216;&#8221;&#8211;libport=32110&#8243; &#8220;&#8211;cacheprefix=blahblah_c0&#8221; &#8220;&#8211;sysdir=\/usr\/local\/avamar\/etc&#8221; &#8220;&#8211;bindir=\/usr\/local\/avamar\/bin&#8221; &#8220;&#8211;vardir=\/usr\/local\/avamar\/var&#8221; &#8220;&#8211;logfile=\/usr\/local\/avamar\/var\/Oracle_RMAN-blahblah_Group-1366836935662-5002-Oracle-blahblah-avtar.log0&#8221; &#8220;&#8211;ctlcallport=32108&#8243;&#8216;;<br \/>\n9&gt; allocate channel c1 type sbt PARMS=&#8221;SBT_LIBRARY=\/usr\/local\/avamar\/lib\/libobk_avamar64.so&#8221; format &#8216;%d_%U&#8217;;<br \/>\n10&gt; send channel &#8216;c1&#8217; &#8216;&#8221;&#8211;libport=32110&#8243; &#8220;&#8211;cacheprefix=blahblah_c1&#8221; &#8220;&#8211;sysdir=\/usr\/local\/avamar\/etc&#8221; &#8220;&#8211;bindir=\/usr\/local\/avamar\/bin&#8221; &#8220;&#8211;vardir=\/usr\/local\/avamar\/var&#8221; &#8220;&#8211;logfile=\/usr\/local\/avamar\/var\/Oracle_RMAN-blahblah_Group-1366836935662-5002-Oracle-blahblah-avtar.log1&#8221; &#8220;&#8211;ctlcallport=32108&#8243;&#8216;;<br \/>\n11&gt; backup database plus archivelog delete input;<br \/>\n12&gt; }<br \/>\n13&gt;<br \/>\nconnected to target database (not started)<br \/>\nusing target database control file instead of recovery catalog<br \/>\nRMAN-00571: ===========================================================<br \/>\nRMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============<br \/>\nRMAN-00571: ===========================================================<br \/>\nRMAN-03002: failure of configure command at 04\/24\/2013 13:59:45<br \/>\nRMAN-06403: could not obtain a fully authorized session<br \/>\nORA-01034: ORACLE not available<br \/>\nORA-27101: shared memory realm does not exist<br \/>\nRecovery Manager complete.<\/p><\/blockquote>\n<p>Sorry for the craptastic formatting there, gotta love Oracle&#8217;s gigantic errors \ud83d\ude42<\/p>\n<p>Being the type of guy who tries to figure things out myself, &#8230;I did the usual and checked support.emc.com, legacy Powerlink and of course Google. In my search, I came up with this EMC KB article: esg130176. It stepped me through making sure the instance was running and that the tnsnames.ora &#038; \/etc\/oratab were correctly formatted. <\/p>\n<p>All of this seemed to check out, and I was even able to perform a manual RMAN backup to local disk, which boggled me further.<\/p>\n<p>I tried to get our DBA&#8217;s to help out, but got the usual &#8220;everything looks good on our side&#8221; answer.<\/p>\n<p>I resigned myself to creating an SR with EMC. The gentleman who returned my call took a quick look and immediately knew what was wrong. He mentioned that when he originally discovered this issue for another customer, it had taken a while to figure out what was going on.<\/p>\n<p>Somehow since the last restart, someone had managed to add a \/ to the end of oracle&#8217;s ORACLE_HOME environment variable:<\/p>\n<blockquote><p>\n$ whoami<br \/>\noracle<br \/>\n$ env |grep ORACLE_HOME<br \/>\nORACLE_HOME=\/u01\/app\/oracle\/product\/11.2.0\/dbhome_1\/<\/p><\/blockquote>\n<p>Avamar apparently strips off that erroneous trailing \/ as it sets its own ORACLE_HOME when it starts the job and thus breaks sqlplus, rman&#8230; all of the those tools we so dearly need.<\/p>\n<p>I want my DBA&#8217;s to fix that environment variable, but that would require restarting this production database. To work around this, create a file called \/usr\/local\/avamar\/var\/avoracle.cmd and put this inside it. This will FORCE Avamar to tack on the \/.<\/p>\n<blockquote><p>\n&#8211;orahome=\/u01\/app\/oracle\/product\/11.2.0\/dbhome_1\/\n<\/p><\/blockquote>\n<p>Obviously you need to make that match YOUR environment!<\/p>\n<p>Try the backup again, and with any luck you&#8217;ll be &#8220;fixed&#8221;! I suggested to the EMC support engineer that he should add that to the above mentioned KB article, and he said he would do that.<\/p>\n<p>Till next time&#8230;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hello folks, I had a really interesting (to me) Avamar RMAN backup failure after a system was rebooted. The system had been backing up perfectly for months, and then all of the sudden: Recovery Manager: Release 11.2.0.3.0 &#8211; Production on Wed Apr 24 13:59:45 2013 Copyright (c) 1982, 2011, Oracle and\/or its affiliates. All rights [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[78],"tags":[113,82,114,80,81],"class_list":["post-428","post","type-post","status-publish","format-standard","hentry","category-avamar","tag-avamar","tag-backup-failure","tag-emc","tag-oracle","tag-rman"],"_links":{"self":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/428","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=428"}],"version-history":[{"count":17,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/428\/revisions"}],"predecessor-version":[{"id":445,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/428\/revisions\/445"}],"wp:attachment":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=428"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=428"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=428"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}