Database Growth and Solutions Part II

This is our 2nd part, of three, sessions discussing database growth and the possible solutions to deal with such growth. Just an FYI, this discussion stems from a presentation by John Stouffer, Solution Beacon, and Rich Butterfield of HP. The Database Growth: Problems and Solutions presentation can be found on the Solution Beacon web site at the following link http://www.solutionbeacon.com/ind_pres.htm

Add Capacity through Hardware Upgrades

This isn’t really a solution and reflects that you cannot remove any more data, and you have, typically, exhausted all means of controlling/minimizing your data growth. So now what?

This is when you need to manage with what you have and plan for the future to control where you go; either that, or at least provide enough time to plan for a new career elsewhere.

• Perform some type of capacity planning effort to see how fast you are growing and how quickly you will outgrow or outperform what you currently have


• Start tracking data growth
• Start planning on scaling up with more/faster CPUs and additional RAM, or scaling out, with RAC solutions. You can plan years ahead and stretch the cost to ensure you can keep performance and availability in check


• Consider as much of the data deletion/purging activities as possible

This doesn’t solve the problem, it just delays the inevitable from occurring.

Decentralize or Do Not Consolidate Data

Think twice before consolidating your databases into one large database. It is sometimes much easier to manage a few small to medium size instances than it is to manage a large growing one. If one database is more or less static, stable and less likely to grow and then you consolidate it with another instance that is growing rapidly and more likely to encounter performance and data issues, you have now caused that stable instance to be in a state of disarray too. You now have twice as many unhappy users. Certainly choosing not to centralize your data may not help control IT resources, costs and overall manageability, but it may be the best solution for your enterprise.

Database Partitioning

Partitioning allows the segregation of data (tables/indexes) into smaller segments, while maintaining a seamless view of all the data as a whole.
Figuring out the best partitioning approach for your tables and indexes can take a considerable amount of analysis, but if implemented correctly, can potentially reap extensive performance gains and potential storage savings.
Older, lightly used partitions can be ported to cheaper, lower end storage solutions. Additionally, depending on the configuration of your partitions, when cloning to other instances, the partitions can be removed, thus reducing the storage needs on target servers.

Partitioning is standard out of the box for only a select set of Oracle Application modules and custom partitioning must have the database partitioning option licensed with Oracle.
Partitioning still doesn’t address the data growth issue and takes a considerable amount of ongoing maintenance and support to maintain the partitions and performance of the partitions.

So, stay tuned for next weeks final posting on Database Growth and Solutions where we will discuss Database Archiving and Hierarchical Storage Management (HSM)