<?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 SMO Performance in Data Protection</title>
    <link>https://community.netapp.com/t5/Data-Protection/SMO-Performance/m-p/16887#M7691</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi All,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We use SMO to on Linux to protect our Oracle 10gR2 DB.&amp;nbsp; In the past, the average for SMO to put the DB in hotbackup and initiate the snap was about 12 minutes.&amp;nbsp; As of 12/1, the time has jumped up to an average of 1hr,20minutes.&amp;nbsp; Can anyone provide some insight on how to troubleshoot this performance problem.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Michael&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 05 Jun 2025 06:40:07 GMT</pubDate>
    <dc:creator>michaeldparker</dc:creator>
    <dc:date>2025-06-05T06:40:07Z</dc:date>
    <item>
      <title>SMO Performance</title>
      <link>https://community.netapp.com/t5/Data-Protection/SMO-Performance/m-p/16887#M7691</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi All,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We use SMO to on Linux to protect our Oracle 10gR2 DB.&amp;nbsp; In the past, the average for SMO to put the DB in hotbackup and initiate the snap was about 12 minutes.&amp;nbsp; As of 12/1, the time has jumped up to an average of 1hr,20minutes.&amp;nbsp; Can anyone provide some insight on how to troubleshoot this performance problem.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Michael&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 06:40:07 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/SMO-Performance/m-p/16887#M7691</guid>
      <dc:creator>michaeldparker</dc:creator>
      <dc:date>2025-06-05T06:40:07Z</dc:date>
    </item>
    <item>
      <title>Re: SMO Performance</title>
      <link>https://community.netapp.com/t5/Data-Protection/SMO-Performance/m-p/16892#M7692</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Michael,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;first open a support case with netapp to help you troubleshoot it, they'll ask you to create a diagnostic file of the backup that is taking a long time, as well as the nSanity output from both the servers and the controllers.&lt;/P&gt;&lt;P&gt;to create the SMO diag, right-click over the backup and choose create diagnostics.&lt;/P&gt;&lt;P&gt;to create the nSanity, go to the NOW website, click on toolchest and look for nSanity.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;step 2, is to look into the logs and find out if SMO is taking longer on database operations, or during snapdrive operations.&lt;/P&gt;&lt;P&gt;you can find the logs for smo under /var/log/smo&lt;/P&gt;&lt;P&gt;and for snapdrive in /var/log/sd-trace.log (it gets recreated every time sdu is executed)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;also if you're in an ITIL kind of organization check if any changes were logged against that server around the 1/12, &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 19 Dec 2011 09:47:21 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Data-Protection/SMO-Performance/m-p/16892#M7692</guid>
      <dc:creator>jcosta</dc:creator>
      <dc:date>2011-12-19T09:47:21Z</dc:date>
    </item>
  </channel>
</rss>

