and want to use the snapmirror & cluster-technologie for Oracle-datafiles exactly as described in the technical documents TR3046 & TR3057 of Network Appliance. Network Appliance states that the fully support this!

They do support it and atleast in my experience go out of their way to ease implementation -- people buy alot of storage and spend alot of money on their databases, so its a sweet market...

TR3046 is pretty straightforward and we ran w/ this without any major problems for some time. Setup was a F760 cluster serving an E4500 with a Catalyst 4006 handling the VLAN we dedicated for it. See the notes below, but it worked quite well. We eventually replaced it w/ some local raid to bump capacity and performance (cheaper than filer upgrades, which we couldn't afford anymore), but still kept the filers around for other applications that were really well suited for them.

Be sure to pay close attention to TR3057 before getting too excited (I didn't, and was disappointed) and make sure your DBA's are in the loop. The key thing we encountered was how Oracle handles read-only tablespaces -- apparently (IANA DBA), a write to the tablespace is required before making it read only. That meant that the production DB had to be put into RO mode, then a snapshot taken, and then put back into RW mode. This atleast seemed to bring up too many caveats for us to persue further.

The solution we used was to simply snapmirror hotbackups, and periodically break the replica (by bringing the volumes into RW mode) to ensure integrity. The full sync that's obviously required following this made it an ugly prospect, but its certainly no worse than it would be with any other filesystem-level replication (having dealt with this, using an application level replication product designed for Oracle would seem to be preferable if your DBA's have the time an patience to deal with it). I had hoped that there was some magic way we could make Oracle (on the backup database) operate RO w/ perhaps some tweaking of local (and small) control files (and likewise not require any accomodations on the production DB) so we could run fully against the snapshot, but this didn't seem possible. (if anyone is coughing at this, I'd love to know a way around it).

Some things to keep in mind (points that NTAP sales and other vendors who know you're considering them will bring up):

* VXFS and even UFS (under 2.8) do point-in-time snapshots (IIRC, Sun has another product with some horrible name for snapshotting as well that supposedly better suited for 'high-end' applications). Clearly any of these are avaiable irregardless of the local disks subsystem you select. I'll avoid embarassing myself (for lack of thorough understanding of implementation in the three cases) and the ensuing flamewar, but think about where you're going to use them. In our case, it was just for backups.

- In the case of backups, even if UFS and VXFS snapshotting suck tremendously, you'll only be dealing with them for a few hours in the early morning -- a period which you otherwise would've had to been banging on your rbs while the hotbackup got spun to tape. Does it matter?

- Presuming NetApp is the only suitable choice for snapshots, how likely are you to need functionality such as SnapRestore? Its a sweet feature, and if you require very short recovery times in the case of db corruption, its hard to beat. If you can bear tape recovery times in the case of corruption, then its a moot point.

- SnapMirror. The only equivalent to this that I'm aware of (and does't send shivers down my spine) is ??? (forgot FeatureName) on the EMC Symmetrix. (Watch out when you talk w/ EMC -- they love to drop Symmetrix only features when you're talking about a Clariion). I still have some greivances w/ SnapMirror (see list archives), but its all cosmetic; I've seen no problems at all w/ snapmirror from a functional standpoint (replicating ~.75tb coast-to-coast).

- Snapshots + NDMP + local tape -- we still haven't bothered to implement this yet, but its damn nice, esp if you're dealing with alot of storage. Being able to kick off a backup of your filer from NotBackedup or NyetWorker and have it consume 0% host resources is fantastic. During backups you've still got somewhat degraded disk performance, but the database's CPU and network is never touched.

* Cost. With that nagging 'profitability' word hanging over every mention of budget expenditures, replacements are about all I've had a chance to buy in the past year. Perhaps prices have come down, but don't forget to compare final prices w/ locally attached raid. Compromising heavily on features (but picking up performance), I was able to get some no-name SCSI-attached RAID's for a fraction of the cost.

- One upside to this, is the filer _is_ still a generic NFS box -- in my case, being able to allocate storage under the battle cry of "for the database" (which goes over pretty easy), you can still carve off some hefty volumes for other applications (yes, you could nfs export a chunk of local storage off your database, but hopefully this scares you as much as it does me)

- If you find you need some high-performance storage in little chunks here and there, the filer's also really handy to have around; there have been times I've needed 100gb of fast storage that was either temporary or not cost-effective for its own dedicated storage -- the filers were perfect for this. Yeah, you can spend bank on a nice SAN solution, but from what I've seen, you've got to scale a good deal before its cost effective, and the chance that I've got a 100mbit (or gig, if needed) interface available, or already installed is a whole lot better than that of a fabric-cabable FC adapter (not to mention cost).

* Performance scalability.

- The filers are pretty heavy boxes -- you upgrade in big chunks (ie. you have 2 840's instead of 4 cheaper scsi raid boxes). If your growth is predictable, and can be budgeted for appropriately, this isn't a big deal.

- Network IO. Storage busses always take the cake here. NetApp's done a _really_ nice job w/ OnTAP's VIF's (more options than you'd get even on a high-end Cisco, for example), but the client-side is lagging significantly.

- Most local-attach boxes will support VXVM's DMP (dynamic multipathing) -- with this you can (relatively) easily add several Ultra-<largenumber> SCSI pipes and loadbalance evenly between them. In Sun's case, you've got SunTrunking (hard to find anyone to talk knowledgably about), and some hacks like ip.mpathd and ifs_groups. Neither are really intended with storage in mind, and often don't provide much help for point-to-point bandwidth.

- ...not to say this isn't addressable -- some careful tending and creative networing _can_ render as big of a pipe as you need, but it won't be as easy. (...of course, if you don't plan on outgrowing a single GigE, none of this matters)

Please don't forget about monitoring.. This is the one place where I really regret not using netapp. The disks I'm using now have a nice serial menued vt100 interface, but there is _no_ programatic way I've found to do routine things like check their health (temp, disk failures, etc) even after working w/ the vendor. This is a major shortcoming and makes me uneasy whenever I see an autosupport email from the filers and remember the rest of my storage doesn't do me that same favor.

Ugh. This has gone too long. Hopefully it addressed what you were looking for..

..kg..