Re: Replicated File System Consistency

Pat wrote:
> So we've got a half dozen or so Oracle 10G (10.2.0.3) servers with
> production data on them.
>
> Historically, we ran them with direct attached RAID arrays, but
> recently we moved them to a new data center with a netapp 3040 SAN.
> Performance on the new hardware seems about the same; SAN is
> theoretically faster but I think there's more latency so from what I
> can see its a wash.
>
> Question I have though is about dr and consistency.
>
> We have a second san offsite.
>
> I can configure san mirroring to mirror our primary san off to another
> data center (more accurately I can ask the san guys to do so).
>
> In the event of a catastrophy at my primary center, can I mount the
> mirror copy of the database in dr, go through a recovery, and be
> relatively comfortable I've got a conistent data set?
>
> I know that if I pull the plug on the machine, Oracle commits that,
> post recovery, I won't lose any commits and it'll be consistent
> (although the recovery may take a while).
>
> Does the same commitment hold if I'm using a lower level (block level)
> replication technology and the replication fails in some unexpected
> place?
>
> Sorry if this is an obscure question, but I don't understand the
> interaction of Oracle's file system with the SAN well enough to make
> intelligent recommendations to the DR guys.

David's link is a good one but I'd like to address the fact that you are not seeing any improvement from the NetApp 3040. Here are a couple of questions you might explore:

1. What is the limiting factor? CPU? Network bandwidth/latency? Storage?
2. How many LUNs? (one is never almost never the right answer)
3. What RAID level?
4. How is the cache configured? What percentage read? What percentage write?
5. How many physical disks are you striped over for your hottest data files? -- Daniel A. Morgan Oracle Ace Director & Instructor University of Washington damorgan_at_x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.org