2014-05-06 11:39 AM - edited 2015-12-18 01:10 AM
We will be migrating our database (Oracle 11g RAC) from an older Equallogic storage system to a NetApp FAS 2240 in the coming months. Currently the database is using ASM and is connected via iSCSI. When we move to the NetApp, at least initially we will use iSCSI and continue to use ASM. We would like to take advantage of Snapshots and Snapmirror when the database is moved to the NetApp. We will not be using SnapManager for Oracle at this time.
I am not quite sure how the NetApp SnapShot process integrates with the Oracle and what pieces are required to make this work.
How are Snapshots and Snapmirror handled so that the database is backed up properly? In particularly, how is the backup scheduled so that the database is put into hot or online backup mode when the snapshot and snapmirror runs? Is everything handled from the Oracle host side via a script that can make the database ready and then trigger the snapshot on NetApp or do you need to coordinate the snapshot on NetApp separately with Oracle?
Solved! SEE THE SOLUTION
2014-05-06 12:20 PM
Without SMO, there really isn't much "integration." It can all be scripted for coordination, either on the DB server or on a management server. You can either use SnapManager for windows/unix to run the snaps, or you can just have an ssh key from the server to the controllers to issue the snap commands. Basically, you have a script that puts the DB in hot standby mode (or similar), then you connect to the filer and take the snapshot, then you bring the DB out of hot standby. Depending on what your goals are, SnapMirror may be an independant topic - technically you can have the DB in hot standby for the duration of the snapmirror update, but many places don't want to spend that much time in hot standby. As long as your snapshots are consistent, SnapMirror replication can happen while the DB is active - your target volume will be inconsistent, but the target snaps will all be fine.
Hope that helps...
2014-05-06 12:46 PM
Well the perceived complexity is one reason. For this migration we are simply wanting to get the Database on to the NetApp, but would still like to take advantage of basic snapshot and more importantly Snapmirror so we can have a copy of the database offsite.
In looking into SMO it sounds like it would require quite a few components to work and I don't think we have the time to bring it all together properly. The SMO documentation I have read also mentions we need Protection Manager in order to use which we don't have (I cant figure out if this is even a product NetApp anymore?). Maybe I am wrong in my assumption as it is a chore to keep track of all of NetApp's separate applications and technologies.
2014-05-06 01:06 PM
Yes Bill that does help, thanks. A few questions though:
"You can either use SnapManager for windows/unix to run the snaps"
You are referring to SMO when you say SnapManager correct?
Depending on what your goals are, SnapMirror may be an independant topic
At least initially, my goal with SnapMirror is to get a consistent copy of the data base to our off site location to satisfy disaster recovery requirements.
technically you can have the DB in hot standby for the duration of the snapmirror update, but many places don't want to spend that much time in hot standby.
So I understand correctly, when a snapmirror job is initiated a snapshot of the volume (called volume_name_snapmirror. etc) is created and then this snapshot is then copied correct? It sounds like a script would require the database to be in Hot standby until the snapmirror update is complete?
As long as your snapshots are consistent, SnapMirror replication can happen while the DB is active - your target volume will be inconsistent, but the target snaps will all be fine.
If I schedule a script to run at 12:00 AM each day that puts the database into hot standby and then sends commands to the NetApp to create a snapshot of the volumes; I can then simply do a snapmirror update after this "consistent" snapshot is created. The snapmirror volume at the DR site however will not be consistent, but the SnapShot that was scheduled at 12:00AM would be. Is this correct? This would mean I would have to have the database in hot standby for the duration of the snapmirror update correct?
2014-05-06 01:09 PM
SMO with Protection Manager integration is not mandatory for snapmirror or snapvault update to protect the backup. You can try with backup with post script in SMO.
2014-05-06 01:34 PM
There are many snapmanager products - the basic ones are snapmanager for windows/unix. All these do is intall some commands through which you can manage the snapshots on the controller - for example, snap list, snap create, snap delete, etc. The connection is over one of the API channels. The other snapmanager products (for Oracle, Exchange, SharePoint, etc.) utilize the basic snapmanager products for talking to the controllers, but they also talk to the application in question, and will handle all the scheduleing and integration.
Remember that, in a snapmirror relationship, you're copying the source volume and snapshots. What you say about updating a snapmirror relationship creating a snap that is copied to the destination is technically correct, but that process is part of the internal workings, and I find it better just to focus on the volume and non-snapmirror snapshot data. So if you put your DB in hot standby, then issue a snapmirror update, wait for it to finish, then take your DB out of hot standby, you've got a consistent copy of your DB at DR that you could snapmirror back if needed.
If, however, you put your DB in hot standby, take a snapshot, take your DB out of hot standby, and THEN inititate the snapmirror update - which you don't need to wait for to finish - then your destination _volume_ is inconsistent from a DB perspective, because the DB was active when it was copied. The snapshot you took when the DB was in hot standby, though, also gets copied - and that is consistent. Instead of just reversing the direction of the snapmirror, you'd have to break the snapmirror, restore the volume to the desired snapshot on the destination, then mirror it back.
One caveat would be that a snapmirror reversal (as in my first scenario) would only copy incremental changes, while the second scenario would be a full copy - irrelevant in the event of a real disaster,but possibly impactful when faced with corruption. Another benefit of doing just the snapshots would be that you could keep multiple consistent copies around as well.
2014-05-06 01:46 PM
There are many snapmanager products - the basic ones are snapmanager for windows/unix. All these do is intall some commands through which you can manage the snapshots on the controller - for example, snap list, snap create, snap delete, etc. The connection is over one of the API channels.
There is no product called "SnapManager for Windows/UNIX." It sounds like you are referring to "SnapDrive for Windows/UNIX" here. That is probably the cause of some of LSOTECHUSER's confusion.
2014-05-07 08:08 AM
Thank you all for the good info. It is making sense, however, as there are several pieces involved I want to make sure I have them correct.
Can someone verify these steps as correct:
In my scenario I would run any scheduled scripts from the Oracle database hosts.
Lastly, as a related question, I am curious what you guys would recommend as far as volume setup? Is it better to have 1 volume that contains multiple LUNS (Data, Flash Recover, temp, etc) or is it better to have only 1 LUN per volume, thereby having multiple volumes?
I ask this as having 1 volume would be quite simple for consistency sake regarding snapshots and snapmirror. However, maybe this is not best practice. Also it sounds like I would then need more NetApp pieces to make sure snapshots are consistent when having multiple volumes. I would imagine the main downfall with 1 volume containing multiple LUNS is that if there are multiple databases and you only need to recover 1; you would have to recover all of them.
Thanks again for the assistance