Derek, et. al;

I'll reply to you publicly on the list and see if I get a rise out of any of the others on Toasters.

First: I'd advise you to not yet rule out qtree snapmirrors because they won't cascade. Tell us all why you need more than one mirror to do DR and backup with?

Second: I just finished setting up qtree mirrors for a couple databases I've got. What I have, actually, are five volumes:

Orabackup Oraarch Oradata Orabase Oralog

I've got five databases, and five qtrees in each volume, one per database. And let me tell you: as bad as you might think qtree mirroring is, volume mirroring is worse for this configuration.

Anyway: you can do your backup any number of ways. The ways I considered are: 1) Shutdown of the database and mirror or snap of the "oradata" contents (database files themselves). 2) Do nightly full dumps and snap, mirror or backup those. 3) Put the database into hot backup mode and snap both the data and the logs.

There might be other, more creative ways, but I'm not a dba.

Anyway: the task was to mirror these existing volumes to an R200. Right away, a bad problem surfaced: my oralog volume on my production filer was only two 72GB drives. Doing volume mirroring would eat up huge amounts of space on the R200 destination filer for no good reason.

So I mirrored all the qtrees while doing a hot backup operation. Seems to work OK. Watch out! It takes extra space for the mirror snaps on the source filers!

For what it's worth: NetApp filers stand the OFA on it's head, and there don't seem to be many people walking around who know this yet. There are some good hints on Oracle configuration on now.netapp.com, but they don't go into extreme detail at all.

In the next couple weeks, I hope to change this on a few of my test/dev databases by making one huge volume and exporting the database mounts from qtrees. I will recover SIX parity drives for reuse as data if I do this!

Keep up the chatter. This is an important topic that few seem to understand well.

JKB

-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Derek Lai Sent: Monday, June 28, 2004 1:09 PM To: 'toasters@mathworks.com' Subject: RE: DR project - SnapMirroring Oracle database

I have not gotten much response. Hopefully it is due to the timing of my Friday afternoon email.

If you have done a DR project with Database and SnapMirroring, I'd love to hear about your experience.

Over the weekend I just came across another big obstacle to using SnapMirroring - you can't cascade qtree SnapMirror! This one seems to be a very big restriction as it means wasting quite a bit of space to do things like backup and DR.

Derek

-----Original Message----- From: Derek Lai [mailto:Derek.Lai@onyxco.com] Sent: Friday, June 25, 2004 3:12 PM To: 'toasters@mathworks.com' Subject: DR project - SnapMirroring Oracle database

I'm in the process of architecting a DR project for mirroring our production Oracle database and would love to hear from those who have done so already.

We have been SnapMirroring the daily changes from one of our cluster F940 filer to the other for backup. In looking through the SnapMirror log I see that we are snapmirroring about 23GB of data on average. This is on a database of about 200GB total. We were thinking about using the max of the daily snapmirror number to size the pipe we need to the DR site. That is figuring to be a fair size pipe.

Now our DBA is telling me that using Oracle's archive log they could just ship the logs to the remote site and play it back and achieve pretty much the same result. And the archive logs are averaging only about 4.5GB. That is 1/5 the size. It is fairly significant when you are shipping it half-way across the country! (We are in Foothill Ranch, CA and our DR site is in St. Louis). If that is true then management will probably choose to go with log shipping as opposed to SnapMirroring the data.

I'm going through the data that we are SnapMirroring to figure out if there is something wrong with our setup. I think we are actually SnapMirroring the archive logs as well. Has anyone else been down this path? Any other ideas or suggestions? We are thinking that the log shipping method is going to involve alot more manual work and would like to avoid it if possible but we need to have good justification for that as well.

Derek