I have a few snapshot questions for anyone else who's running Oracle:
1. Does a hot backup (as described on http://www.netapp.com/tech_library/3049.html) present any restoration problems? Has anyone done a restore from a hot backup? 2. Hot backups are as close to "live" as you're supposed to come, but it seems to me that a nice extra bit of paranoia would be to take snapshots 2-3 times per day of the live database. The image would be consistent, and Oracle would come up off of it as it would from a crash (unlike, say a tar of the data-files which would be junk). The only problem would be that you would loose any half-completed actions which were not correctly tansactionalized. Can anyone comment on this? 3. Has anyone seen roughly how much storage an Oracle snapshot takes? It seems to me that it would be larger than a filesystem snapshot because more blocks are changing. Of course, it depends on your read/write ratio, but is there a general consensus? I've so far been very impressed with my filer. Oracle over NFS sounded outright dumb to me at first, but damn if it isn't faster than local disk.
Thanks.
- Does a hot backup (as described on http://www.netapp.com/tech_library/3049.html) present any restoration problems?
The only caveat to this is if you're trying to use SnapMirror as well, which won't replicate 'manual' snapshots. Kind of a big gotcha when trying to really leverage the filer's features.
- Hot backups are as close to "live" as you're supposed to come, but it seems to me that a nice extra bit of paranoia would be to take snapshots 2-3 times per day of the live database. The image would be consistent, and Oracle would come up off of it as it would from a crash
Kinda. In practice, I would only consent to a clustered pair before running a database on top of it (just as you'd would want redundant paths and controllers in a local raid or jbod). However, if you spread your database out across these to take advantage of the added performance as well, then a 'live' snapshot is unreliable, as even with damn precise timing, both filers still won't take them in the same instance of time.
I've so far been very impressed with my filer. Oracle over NFS sounded outright dumb to me at first, but damn if it isn't faster than local disk.
I haven't seen the same, but thankfully the database running against them doesn't have heavy disk i/o requirements. What were the specs of the local disks you were comparing against -- was it anywhere close to an equivalent priced? I've found that a 760 runs out of CPU around ~18MB/s of sequential writes, not to mention the processor penalty from NFS client overhead.
One thing that did console me was the 'safety' of doing this over NFS, to a tightly-integrated box like the filers. We had run across problems with buggy FCAL drivers that were successfully returning from a write(), even when out of cmd tags. The catalyst was two-fold, with a failing hub taking down a poorly-laid out loop .. This caused for much corruption and pain, which thankfully under the realm of filer NFS is extremely unlikely (given that filer like to panic when things look bad, and NFS clients love to hang), and otherwise NFS is nicely handshaken.
..kg..
The only caveat to this is if you're trying to use SnapMirror as well, which won't replicate 'manual' snapshots.
No, SnapMirror does replicate *all* snapshots from the source file system to the target file system, not just the ones that are driving the SnapMirror process itself.
As you may know, SnapMirror is driven off of a pair of snapshots, and these snapshots would not ordinarily be coordinated with application activity in any way. In other words, these snapshots get created and removed in accordance with your SnapMirror scheduling, not when an application like Oracle is in its hot backup mode, or Microsoft Exchange is "quiesced" etc, etc... As a consequence the self-consistency of the application data within these snapshots is not guaranteed. But....
The snapshots created on the source file system that have been coordinated with an application in some way will get propogated to the target file system by the next SnapMirror cycle that occurs after they are created. They will simply appear as snapshots on the target, with the exact name you gave them on the source. Thus self-consistent copies of application data are normally available on the target for the purposes of disaster recovery (for the applications that need that, such as the databases). See:
http://www.netapp.com/tech_library/3057.html
Kinda. In practice, I would only consent to a clustered pair before running a database on top of it (just as you'd would want redundant paths and controllers in a local raid or jbod).
Fair enough.
However, if you spread your database out across these to take advantage of the added performance as well, then a 'live' snapshot is unreliable, as even with damn precise timing, both filers still won't take them in the same instance of time.
You do have to be somewhat careful for sure, but such a thing is eminently do-able. See:
http://www.netapp.com/tech_library/3046.html
Keith
-
Aaron Sherman -
Keith Brown -
kevin graham