Q
Problem solve Get help with specific problems with your technologies, process and projects.

Oracle RAC to consolidate silo databases

I have silo databases for housing several applications. Each has its own application server and database server and its own storage. I was thinking of using Oracle RAC to consolidate all these silo applications. What are your thoughts, and are there any example white papers I can find for best practice in consolidation?

I have silo databases for housing several applications. Say, for example HR , FINANCIAL and SALES. Each has its own application server and database server and its own storage. I was thinking of using RAC to consolidate all these silo applications.

My initial thoughts are:

  • Each application will have its own application server. Each application will have its own instance. So we have three servers containing application servers and instances of Oracle.
  • Here I am undecided whether to have several databases all sharing the same storage or consolidate them into one big database for all the applications (seperate schemas though).

Having all applications in one database can affect scheduled availability as quarterly patches and other fixes require shutdown of the databases. If several databases are configured then one or two of the applications are still available with frequent patches or fixes.

What are your thoughts, and are there any example white papers I can find for best practice in consolidation?

You may not need RAC to consolidate applications into the same Oracle instance. Here are a few rules that I follow when faced with a similar situation.

First, I take a look at the resources of the servers running the Oracle instances. How much memory is being used by each Oracle instance? Are the CPUs always busy, or mostly idle? When you consolidate instances, you will be sharing resources. You may find that your resource requirements are not that high and you can easily consolidate instances into one database server. If resource demands are high, then you may have to implement RAC so as to spread those resource requirements out over multiple database nodes.

Second, I always put different application data into different schemas. This way, applications cannot see the other applications' data. Additionally, I try to seperate the application's data onto different disk devices if at all possible. This way, high disk usage of one application will not impact other applications.

Third, if you are considering RAC, then take a look at the management aspects. It is easier to manage three separate database servers running three applications than it is to implement a three-node RAC cluster. So you may be doing more harm than good by combining applications into one Oracle database and putting RAC into the equation. RAC should be used for two reasons. One, higher availability. If one node goes down, another node can still be used to access the data. Two, better performance. By splitting the load across multiple nodes, one can spread out the resource demands. If these two reasons do not apply, then implementing RAC can waste the company valuable man hours to manage a high-end configuration that may not be necessary.

Dig Deeper on Oracle database design and architecture

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide.com

SearchDataCenter

SearchContentManagement

SearchHRSoftware

Close