May 21, 2008
It is an unfortunate reality that the database and the DBA are too often presumed guilty by default. Everyone tends to want to blame the database first, even though performance degradation could be caused by network problems, storage problems, the Web server, sun spots, or poor application coding. So, as a database professional, how do you get yourself out of the hot seat and prove your database’s innocence? Here's a checklist to assemble your defense:
- [[ ]] Index Read Efficiency (IREF) is less than 10 for the database thus suggesting that good indexes are providing quality guidance to desired rows
- [[ ]] The Synchronous Read Percentage (SRP) is 90% or higher thus indicating the general absence of scans and the presence of high quality indexes
- [[ ]] Bufferpool Logical Index Reads per Transaction (BPLITX) is less than (The number of Selects per Transaction (SELTX) plus the number of DML per Transaction multiplied by 6), thus indicating the likely absence of costly index leaf page scans
- [[ ]] There are no files closed (DFC)
- [[ ]] DB CFG LOGBUFSZ is at least 128, and preferably 256-512 if DMLTX is greater than 2
- [[ ]] The Catalog Cache Hit Ratio (CATHR) is 95% or higher
- [[ ]] Average Rows Read per Transaction for each and every table (TBRRTX) is less than 10
If you can put a check mark in the boxes for each of the aforementioned "innocence" tests, it is highly probable that you and your database are innocent and, indeed, not guilty of causing "performance beneath expectations". As a disclaimer, this is not an exhaustive list, and these defenses are largely circumstantial.
In a paternity suit, a man might claim that he doesn't know a woman, never had relations with a woman, and was not in the same geography as the woman during the suspected time frame of conception. While these are fairly convincing arguments to assert, memory is colored by the events of the day and it is possible that the man "forgot" the actual facts or materially misrepresented reality (lied under oath). Instead of circumstantial evidence and testimony, a DNA test can be used to determine matters of paternity with certainty.
Why is the DB2 instructor now blabbing about paternity suits during a DB2 educational blog? Glad you asked. In the next blog post, we're going to cover the DNA test of performance issue ownership.
The Shameless Marketing Moment
I would like to draw your attention to DBI's first "Tune Your Database for Charity Event and Contest" June 5th-19th, 2008. It costs nothing to participate, and you could win free attendance to the IBM IOD Conference 2008 in Las Vegas (including paid expenses)! Participants will vote for their favorite charities, and all charity pool money will be distributed on a pro rata basis according to the participant voting.
Participating is easy and costs nothing. For each participating database, DBI will be donating $25 to the charity pool, plus chipping in 1% of Q2 2008 new license sales. All you have to do, at a minimum, is send a couple of snapshots to DBI for judging - no business confidential data is required (for instance, no SQL snapshots please, just database, tablespace, and table). We've even already written the commands for you.
PLEASE, LEARN MORE and GET INVOLVED to benefit the American Red Cross,
Juvenile Diabetes Research Foundation, American Cancer Society,
American Heart Association, and Big Brothers Big Sisters.
Just for Fun
From the Press Release:
"This reminds me of the Pay It Forward movie and movement" said Scott Hayes, President & CEO of DBI. "Our intent is to help a lot of people, directly and indirectly. Several DBI team members have had their lives touched by cancer and diabetes, and others are active Big Brothers and Big Sisters. Good goes around. This is a good thing we are doing. We hope database professionals around the globe will participate" Hayes added.
Pay it Forward - Video Clip
Cheers,
Scott
Scott Hayes
President & CEO, DBI
IBM GOLD Consultant
www.Database-Performance.info
www.Database-Auditing.info
Your Performance IS Our Business
Trackback Pings
TrackBack URL for this entry:
http://www.ibmdatabasemag.com/blog/main/archives/2008/05/db2_luw_perform_26.html
« DB2 Certification: Restoring a database and understanding database privileges | Main | Celebrate DB2, U2, IMS, and IDS anniversaries by helping write their histories »
This is a public forum. CMP Media and its affiliates are not responsible for and do not control what is posted herein. CMP Media makes no warranties or guarantees concerning any advice dispensed by its staff members or readers.
Community standards in this comment area do not permit hate language, excessive profanity, or other patently offensive language. Please be aware that all information posted to this comment area becomes the property of CMP Media LLC and may be edited and republished in print or electronic format as outlined in CMP Media's Terms of Service.
Important Note: This comment area is NOT intended for commercial messages or solicitations of business.

