Database Architecture Design - Memory to Storage Using DB2

Abstract


It continues to amaze me on the number of corporations running data-based applications on DB2 who view it as a black-box that simply houses their application data.  This disconnect with the importance of properly designed and more importantly…configured…data bases leads to application error, lowered customer satisfaction, drastically decreased potential being proactive with KPI’s and increased hardware and support costs.

This disconnect is so prevalent, that many organizations assume that the solution to a badly performing database is adding a score of new indexes, buying more memory or worse going through a massive conversion/upgrade effort with a new product.

Capital expenditure on additional memory and storage for a database that simply needs to be properly configured for its’ workload is something that I see various companies do every year and it’s a massive waste of shareholder equity.

In a previous life, I was responsible for capacity planning with Procter & Gamble’s technical infrastructure.  Following the Pareto Principle (i.e., 80 /20 rule), the first thing that I did was identify which portion of the infrastructure was responsible for the highest costs in support, licensing and new expenditures.

Three IBM 3090 mainframes jumped out with the highest costs so I initially placed my focus there.  Looking at daily workloads of each environment what became apparent was that the utilization between each machine ran a little over 40%.  

This was a massive waste of resources. 

So I simply rebalanced the workload, dividing processing between two machines and eliminating the third.  This simple act of effectively spreading workload utilization saved P&G $2M/year.

The workload within a DB2 database can also be effectively spread with an effective buffer pool and storage strategy.  This will drastically improve overall performance, eliminating the need to acquire additional memory and lowering support costs.  

I’ve been in numerous pre-sales situations were a client will sign a contract to purchase a data based application and as the ink is drying they will then ask architecture questions that they should have addressed beforehand:

What type of DB2 license should we buy?

How much memory will we need?

How much storage?

What kind of storage?

How many LUNs will we need to configure?

How many CPU’s will we need?

These are all very relevant questions that should be addressed…before…making the decision to purchase a shiny new data based application.  However, in my experience the key after the fact question that is rarely asked is, “What type of performance should I expect?”

In my experience performance is seldom discussed during project startup, but it is…always…brought up once the application is in production.

The issue as I stated earlier, is that many technical professionals view DB2 as a black-box in that they are only concerned with…space.  With this fixated view they look at the potential size of the database to figure out how much storage to purchase.  Then the storage size is used to guestimate the amount of memory and CPU that should be required.

The assumption is made that adequately estimating hardware based on database size will also equate into having adequate performance.

This is a woefully inadequate assumption that will lead to subpar performance in your production environment.

This white paper will illustrate via a case study the benefits of completing a database architecture design as one of the first project deliverables that contains the database configuration parameters, bufferpool design, tablespace design, LUN design, and device/file design.

This will ensure optimal database performance and low capital expenditures for your project.