NetApp recently announced the release of SnapManager for Oracle 3.0. In the February issue of Tech OnTap, we described how you can use SMO to significantly improve common Oracle data management operations including backup to primary storage, protecting those backups on secondary storage, recovery, disaster recovery and cloning. Through the SMO interface you can create space-efficient FlexClones on both primary and secondary storage, and you can use clones on secondary storage to better support dev/test, business intelligence and other activities that would otherwise require a full copy of your primary data set. With SMO, you can also delegate responsibility for many of these tasks to DBAs or others in your organization so you don’t have to get involved in every activity that involves storage.
You can check out the article at http://www.netapp.com/us/communities/tech-ontap/tot-smo-0209.html
Have you tried SMO in your Oracle environment? Do the new features of SMO 3.0 make it more appealing?
We've been testing and trying to implement SMO in a very complex setup for quite some time. Because we are using the same hardware cluster for a number of different customers and networks, SMO has been extremely difficult to implement. Since there is no centralized management server (Protection Manager is hardly there) for SMO, the GUI client has to have access to every database instance as well as the central repository. A full software install is needed for each virtual machine (here: Solaris zones) and SMO operations often take a full volume scan of primary storage (ca. 190 volumes) for many operations, so they are slow.
Fundamentally, there should be one central software "master" that the GUI client could access. This server would then have access to all of the Oracle instances that are managed. Server-Client or Master-Slave relations for management software are a must when trying to reduce management overhead. SMO requires a prohibitive number of firewall openings to administer the number of databases we use for the number of customers we use because it lacks this fundamental administrative concept. Requiring Protection Manager just to mirror (QSM) data to secondary storage is also prohibitively expensive considering that we are only interested in using it for SMO and not the other 30+ filers we run.
SMO still has a way to go to be able to meet our needs easily.