Ask the Expert - Mr. Database
This month's question:
Q: Dear Mr. Database:
My Oracle database is starting to outgrow my current hardware – how should I respond?
Paul
Vancouver, CA |
 |
A: Dear Paul:
In answer to this question, I have good news and bad news. The good news is that the choices available to remedy this situation in the world of Oracle have changed in the last couple of years. It wasn't that long ago that there weren't many options besides scaling up to more expensive and capable hardware ie. buying more big boxes. In this monolithic world, exponentially increasing costs were a limiting factor to offering more throughput to growing applications.
Luckily for us, clustering technology - where many servers work as a team to satisfy client requests - has evolved into a real option. Adding capacity to a cluster is as simple - in theory - as adding a new node, which can easily be done using cheap commodity hardware.
Now for the bad news: the practice of scaling clustered technology, though undoubtedly more affordable, is still a pretty complex operation and might not necessarily fit the workload characteristics the database is being asked to serve. Generally, the most returns are generated when the database is utilized for requesting data, while write-intensive loads tend to avoid the gains offered by clustering. If you're needs are in the latter camp, your answer is simple - buy more of what you probably already have. If you're in the first camp, and you believe your infrastructure will continue to grow, it's probably time to move to RAC if you haven't already.
Creating a cluster around an existing database is the first step towards a Real Application Clusters (RAC) database - something you need to take advantage of Oracle clustering technologies. This layer is the infrastructure layer which sits between the hardware/operating system and the database - providing all the services required for the responsibility dispersal to all the nodes servicing the database. This complex upgrade cannot be performed in-place in a production environment as it requires quite a few steps and must be tested thoroughly.
Once the database to be shared is a RAC database it can be installed on hardware as required - adding and removing nodes as required. Of course there are a number of steps in this process, some documented better than others. At a high-level, the hardware and OS must be prepared, and then added as a cluster node, then finally a database instance can be deployed to the cluster node.
Sound complicated? It is. There is a sizable set of work that needs to be performed meticulously, checking the results after each step - something that can require deep introspection into the structures of the cluster and knowledge of what to look for. It's no surprise then that GridApp has made it our mission to automate Oracle scaling, among other database management tasks (and not to boast, but we offer the only comprehensive solution to up-provision a single-instance database or a small RAC database into a large cluster without opening up your environment to liabilities associated with hardware!). In the event of a hardware failure, Clarity will make the administrator's job of realigning available resources a simple task.
Without a software solution like GridApp Clarity, it makes sense to bring in expert help - assuming you do not already have this brainpower in house. If you're lucky enough to have folks with RAC expertise working for you, plan, you may also want to bring in some outside consultants who have more familiarity with newer RAC versions, so you can start off on the right foot.
Eric Gross, GridApp's Mr. Database, has 11 years of experience working with database infrastructures.
<< back |
