A short update on the many problems I have had with Snapmanager 3.0 for Oracle
protection manager
Since 3.0 SMO supports migration of snapshots to a disaster netapp. There is an extra license and software involved though namely Protection Manager. If you are thinking of using it, don’t. To take advantage of these Protection Manager features through SnapDrive, you must have a DFM server with version 3.7 or later, and your storage systems must be running Data ONTAP 7.3 or later. ( 7.3 is currently in Beta )
Scheduling
Scheduling has no pre or post script options. So if you want to manually call something before or after snapshotting ( say for example snapmirror, or a status mail ), you have to go back to full scripting. Scheduling is also NOT possible on command line. I have no idea what the devs were thinking. Every SMO action has a command line option except the scheduling, a pain in the ass if you want to automate creations of profiles, backups and backup schedules.
a third and UNACCEPTABLE “feature” is that SMO scheduling is NOT cluster aware. On creation of the schedule, the hostname gets written in the database ( SMO_30_SCHEDULEDOPERATION ), when you run your database on another host the software forgets the profiles as it is now another host/db combination. Recreating the profiles doesn’t work because the name is already in use.
I felt naughty and updated the tables manually with the virtual IP’s of the databases, but to no avail.
Netapp Name
Not a real SMO problem but rather a snapdrive problem. When taking snapshots, Snapdrive uses the hostname from the netapp. This means that when you try to mount one of the snapshots and the name you use to talk to your netapps is different then the hostname, Snapdrive gives an error :
for example :
netapp name : stor01
lan network : stor01l
storage network : stor01s
mounts are on storage network :
stor1s:/vol/vol_df
stor1s:/vol/vol_arch
stor1s:/vol/vol_redo1
stor1s:/vol/vol_redo2
When you try to run a verify, restore or mount :
/usr/sbin/snapdrive snap connect -fs /test/DB/oradata/datafiles /opt/NetApp/smo/mnt/-test-DB-oradata-datafiles-20081212141831810_0 -destfv stor1:/vol/vol_df SnapManager_20081212141831851_test_df -snapname stor1:/vol/vol_df:smo_test_20081212_141644_hourly_1_8a809e8a1e2b576f011e2b5778580001_0 -autorename -noreserve
0002-044 Command error: The following Storage System Volume(s) do not exist in the snapshot and cannot be renamed
Volumes : stor1:/vol/vol_df
When adding stor1 in /etc/hosts with ip stor1s and changing the mounts to use stor1 instead of stor1s, it works. So you have to mount your volumes with the hostname of your netapp. Something to keep in mind.
Archivelogs
Archivelogs are still not cleaned up automatically. You need a separate script to do the cleanup. ( post-script would solve this for a part )
…
More to come
