An Oracle blog about Database and Grid Infrasructure Maintenance

  • August 9, 2012

Rationalization - How much complexity do you want to handle?

Guest Author
Once you are in control of the information on the applications and resources within your data center, you are in a position to begin the process of rationalization. So how many different infrastructure stacks: server, operating system, database, and middleware, do you think you can manage? Bear in mind that is not just the initial construction of these stacks that you need to think about. These stacks demand on-going monitoring, management and maintenance, and furthermore, you will need the in-house skills to cope with these demands.

Even with just these four layers, the potential combinations expand very quickly: Two options for each layer leads to sixteen different stacks (24), three results in eighty-one (34) possibilities. This assuming that all options are available at each level, but does not take into consideration patching to the server firmware, the operating system, the database, or the middleware! So it's fairly clear that you must restrict yourself to one, or possibly two options at each layer to give yourself a chance of gaining, and maintaining, a grip on the complexity in your data center.

So what options do you pick? It's hard to be prescriptive here, but in general the latest versions of software have the most features, and fix the majority of the high priority bugs known on the previous release. Consequently, there is value in building on standard components that are as close to the leading edge as is reasonable. For example, you might pick Oracle Solaris 10 8/11 with a view to adopting Oracle Solaris 11 11/11 if and when the next release of Oracle Solaris 11 becomes available. In addition, you might choose to employ Oracle Grid Infrastructure 11g Release 2 as your primary availability platform for either or 10.2.0.x Oracle databases.

Having said all that, there is still room for exception handling. Some applications just cannot be coerced onto one of your standard platforms, so they must be treated as exceptions. But again, you must keep the number of these down to keep complexity under control as you marshal your resources for the consolidation phase.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.