<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic NetApp Plug-in for Oracle RMAN and Clustered ONTAP Load-Sharing mirrors in ONTAP Discussions</title>
    <link>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-Plug-in-for-Oracle-RMAN-and-Clustered-ONTAP-Load-Sharing-mirrors/m-p/107278#M22811</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;we are running into the following problem when testing the NetApp Plug-in for Oracle RMAN hosting databases on a clustered ONTAP setup:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We are using the plugin to duplicate an exising database and then present it to a host. This involves a volume clone operation on the NetApp storage, followed by a mount of the cloned volume on the host before it is able to mount the duplicated/cloned database.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;However, we are following best practices on our clustered ONTAP setup, which means we have created load sharing replica volumes of the SVMs root volume across all the nodes in the cluster.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-DE6D34B9-5E21-4AE7-9A48-04E3832CAD45.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-DE6D34B9-5E21-4AE7-9A48-04E3832CAD45.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;With the following setup:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;- Oracle database volume sitting on an aggregate on node 01 of the cluster&lt;/P&gt;
&lt;P&gt;- SVM root volume sitting on node 02 of the cluster&lt;/P&gt;
&lt;P&gt;- LS mirror replicate SVM root volumes on node 01 and 02 of the cluster, with a 15-minute LS mirror update interval.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;the duplication action fails and we are in fact running into a fairly common problem described here:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FBACA2B1-2716-4A79-BC09-14303F68F8BA.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FBACA2B1-2716-4A79-BC09-14303F68F8BA.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;because the LS mirrors of the root volume haven't received the information about the new volume in the namespace yet.&lt;/P&gt;
&lt;P&gt;This is the specific error message that is logged in sbtio.log:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;SBT-23806 07/06/15 10:37:59 popen_cmd: The command failed to exectue error=mount.nfs: mounting vsnasnp02-473-1:/TAG20150706T103756_NetApp_clone_x_01qb261m_6_1_20150702172822_CL failed, reason given by server: No such file or directory&lt;/P&gt;
&lt;P&gt;.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If we wait a number of minutes and then execute the mount manually (by then the LS mirrors of the root volume have received&amp;nbsp;&lt;/P&gt;
&lt;P&gt;the updates in the namespace), it works without problems.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I think the best solution that the author of this plugin could implement for clustered ONTAP setups is to perform the mount with the /.admin/ prefix so the cluster is forced to go to the real root volume of the SVM:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FF081604-FA5C-4839-B475-26CCC3E5439D.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FF081604-FA5C-4839-B475-26CCC3E5439D.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Alternatively, an LS mirror update could be launced and a small timeout could be built in to wait for the update to finish,&lt;/P&gt;
&lt;P&gt;like this:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-ED018707-D778-4D1E-AC76-D13A4CD7518A.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-ED018707-D778-4D1E-AC76-D13A4CD7518A.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is this something the authors of this plugin are aware of ?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Best regards!&lt;/P&gt;</description>
    <pubDate>Wed, 04 Jun 2025 23:49:05 GMT</pubDate>
    <dc:creator>uptimenow</dc:creator>
    <dc:date>2025-06-04T23:49:05Z</dc:date>
    <item>
      <title>NetApp Plug-in for Oracle RMAN and Clustered ONTAP Load-Sharing mirrors</title>
      <link>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-Plug-in-for-Oracle-RMAN-and-Clustered-ONTAP-Load-Sharing-mirrors/m-p/107278#M22811</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;we are running into the following problem when testing the NetApp Plug-in for Oracle RMAN hosting databases on a clustered ONTAP setup:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We are using the plugin to duplicate an exising database and then present it to a host. This involves a volume clone operation on the NetApp storage, followed by a mount of the cloned volume on the host before it is able to mount the duplicated/cloned database.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;However, we are following best practices on our clustered ONTAP setup, which means we have created load sharing replica volumes of the SVMs root volume across all the nodes in the cluster.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-DE6D34B9-5E21-4AE7-9A48-04E3832CAD45.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-DE6D34B9-5E21-4AE7-9A48-04E3832CAD45.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;With the following setup:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;- Oracle database volume sitting on an aggregate on node 01 of the cluster&lt;/P&gt;
&lt;P&gt;- SVM root volume sitting on node 02 of the cluster&lt;/P&gt;
&lt;P&gt;- LS mirror replicate SVM root volumes on node 01 and 02 of the cluster, with a 15-minute LS mirror update interval.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;the duplication action fails and we are in fact running into a fairly common problem described here:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FBACA2B1-2716-4A79-BC09-14303F68F8BA.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FBACA2B1-2716-4A79-BC09-14303F68F8BA.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;because the LS mirrors of the root volume haven't received the information about the new volume in the namespace yet.&lt;/P&gt;
&lt;P&gt;This is the specific error message that is logged in sbtio.log:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;SBT-23806 07/06/15 10:37:59 popen_cmd: The command failed to exectue error=mount.nfs: mounting vsnasnp02-473-1:/TAG20150706T103756_NetApp_clone_x_01qb261m_6_1_20150702172822_CL failed, reason given by server: No such file or directory&lt;/P&gt;
&lt;P&gt;.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;If we wait a number of minutes and then execute the mount manually (by then the LS mirrors of the root volume have received&amp;nbsp;&lt;/P&gt;
&lt;P&gt;the updates in the namespace), it works without problems.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I think the best solution that the author of this plugin could implement for clustered ONTAP setups is to perform the mount with the /.admin/ prefix so the cluster is forced to go to the real root volume of the SVM:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FF081604-FA5C-4839-B475-26CCC3E5439D.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1368017/html/GUID-FF081604-FA5C-4839-B475-26CCC3E5439D.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Alternatively, an LS mirror update could be launced and a small timeout could be built in to wait for the update to finish,&lt;/P&gt;
&lt;P&gt;like this:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;A href="https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-ED018707-D778-4D1E-AC76-D13A4CD7518A.html" target="_blank"&gt;https://library.netapp.com/ecmdocs/ECMP1653502/html/GUID-ED018707-D778-4D1E-AC76-D13A4CD7518A.html&lt;/A&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Is this something the authors of this plugin are aware of ?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Best regards!&lt;/P&gt;</description>
      <pubDate>Wed, 04 Jun 2025 23:49:05 GMT</pubDate>
      <guid>https://community.netapp.com/t5/ONTAP-Discussions/NetApp-Plug-in-for-Oracle-RMAN-and-Clustered-ONTAP-Load-Sharing-mirrors/m-p/107278#M22811</guid>
      <dc:creator>uptimenow</dc:creator>
      <dc:date>2025-06-04T23:49:05Z</dc:date>
    </item>
  </channel>
</rss>

