Fidelity Case Study

So I guess this is old news since they finished this implementation back in June last year and even presented at Open World. But this case study is just a goldmine of information and totally worth reviewing if you’re anywhere close to RAC, Data Guard, ASM, RMAN, or Flashback (and more I’m sure).

The big picture is that Fidelity migrated a 10TB data warehouse from DB2 to Oracle RAC. (Charles Kim was the lead on it.) Most of the data was unstructured PDF or XML stored in LOBs. Interestingly this is a perfect example of something that Robin Harris recently discussed on storagemojo… and then Kevin Closson picked up on his blog as well: that the future of storage is not IOPS or OLTP workloads; it’s capacity and unstructured data… think LOBs and sequential reads (or as Kevin pointed out, Oracle 11g Secure Files).

Update: Noticed that Nuno Suoto blogged just this morning about the same thing.

What’s really amazing is just the level of detail about everything that’s in this report. From high-level business reasons for the move to Oracle to line-by-line printouts of scripts Chris really has everything in there. It’s well worth a read!

You can download the report here:
http://www.oracle.com/technology/deploy/availability/htdocs/FNF_CaseStudy.html

Since I see quite a bit of RAC I particularly liked this quote; Charles makes a good assessment of some of the costs that you need to be aware of before investing in RAC for your environment:

It is crucial to realize that the success factor for RAC deployment depends heavily on the UNIX System Administration team who understands clustering technology. FNF was fortunate to have system administrators who were subject matter experts in HACMP, MPIO, Hitachi HDLM, SAN Architecture, AIX system administration, raw device technologies and much more. SAs were able to leverage their expertise in previous clustering technologies towards Oracle RAC.

This totally reminds me of a [much shorter] paper that Mogens Norgaard wrote several years ago called You Probably Don’t Need RAC. (Which I hear didn’t go over well at Oracle, probably having something to do with IBM picking up on it…) He said a few very similar things in his paper:

There are other indirect costs associated with going RAC: You’ll need more skills in your organisation, both with respect to RAC and clusters. If your organisation is not familiar with clusters you’ll need to learn a lot, for instance.

…

I have already touched on this in several places in the paper, so let’s just repeat here that it’s not only RAC skills that are needed, but also (and probably most) cluster skills if your organisation is going RAC.

Just as Mogens says in his paper, “RAC is very cool technology.” But you are adding a whole new level of complexity when you introduce clusterware. Granted: today it’s easier than it’s ever been in the past since you can run Oracle’s own clusterware on any platform. Cache fusion has obsoleted a lot of tricks we used to need to eliminate those nasty block pings on hot spots. But you’re still talking about a more complicated system; and when problems do happen (and I promise that someday they will) you’re going to need to know what you’re doing (or pay someone who does). I’m actually a big fan of cluster technology – you can dramatically increase your capacity and tackle very big problems with it! I just think people need to know that it’s not trivial to do.