Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

How do I freaking scale Oracle?

A quick-and-dirty guide to scaling your apps with Oracle DB

By Andrew C. Oliver, InfoWorld, 02/07/13

For the record, I'm a NoSQLer and a big data guy. After nearly 20 years of dealing with what I've come to refer to as "the beast" (aka Oracle), I've turned coat and decided I prefer solving the problem rather than mitigating it.

That said, many companies I work with have spent 20 years painting themselves into an Oracle corner. While they may have one eye on a brighter future, they still must ensure their Oracle database is high-performance and highly available -- and scales as well as possible. Despite what you may read in NoSQL vendor marketing materials (or even in my blog), it is possible to scale Oracle.

There's just one catch: Nothing I'm going to suggest costs less than my house for a nontrivial installation. Heck, when you include the hardware and data center resources, some cost more than my whole neighborhood.

What availability and scalability really mean
Before I describe how to accomplish high availability or scalability, we'd all be better served if you know what I mean by those terms.

High availability means close to zero downtime -- in other words, a system that can tolerate a one-node failure with either zero downtime or minimal downtime (usually less than 5 minutes) for the failover process. Sometimes this can be done across data centers to allow for high availability even in a disaster scenario.

As for scalability, it's important to understand from the outset that performance is a different concept. Performance is the time it takes to service a request. Scalability means flexibility in expanding or reducing your server capacity and infrastructure. Higher scalability means handling a larger number of requests within our expectation of performance.

There is some overlap, however, in performance and scalability. Ideally, a database and its related infrastructure handles all availability issues under the hood so that the client can stay "dumb." However, if certain aspects of transaction logic are outsourced to the client, then performance and scalability can both be at risk.

Take sharding, for example. The dragon is always complexity -- and including sharding logic in application code introduces a bug risk associated with the sharding algorithm "rolled" by the developer. This threatens scalability because the sharding algorithm might not be very good or correct (for example, Foursquare in October 2010).

What do you need? You need fault tolerance against server outages, storage outages, and data center outages (aka disaster). You'll also need a way to balance load against servers and/or CPU cores as well as disks. Several products and techniques can accomplish this.

Oracle RAC
Oracle RAC is mainly about load balancing and high availability to Oracle processes. It uses a shared disk architecture, which means that while it keeps the database available against a server outage, it does not protect against any outages that affect storage.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.