an analysis of database issues

8/9/2019 An Analysis of Database Issues

http://slidepdf.com/reader/full/an-analysis-of-database-issues 1/3

An Analysis of Database Issues

The top ten issues seen while consulting on Oracle databases

Mike Ault

In my ten plus years as a database consultant before joining Quest Software I had theopportunity to visit hundreds of client sites. At client sites I performed analysis of their environments to help them improve the performance of their database systems. In this

blog I want to talk about the top ten performance-related issues that I saw over and over again.

The following table lists them in order of occurrence:

Problem Solution 7/8i 9i 10g Totals

Initialization ParametersAdjust init parameters(tunememory) 39 25 9 73

Literal SQL Use bind variables 21 12 5 38Shared pool incorrect Properly size/flush pool 19 15 2 36Missing/improper indexes Revise indexes 8 7 5 20PGA_AGGREGATE_TARGETnot used/tuned Use PAT/Tune 14 5 19No advanced indexes Use advanced indexes 6 8 4 18Improper SQL Rewrite SQL 8 3 2 13Indexes wide Rebuild indexes 8 5 13No automatic object analysis Implement Object analysis 7 6 13RAID improper/not used Use RAID10 if possible 2 6 4 12

As you can see a majority of shops didn’t have initialization parameters set correctly.Since initialization parameters control memory, options available, how disks are accessedand a number of other performance related areas, bad setpoints cause a plethora of issues.

Of course, the next big item was the use of literals in SQL. This use of literals means thatthe developers of the application did not use bind variables but instead used the actualliteral value in the SQL statement in WHERE clauses. Of course non-use of literals leadsto excess CPU, excess latching, re-parsing and thrashing of the shared pool.

Shared pool incorrectly sized, this issue, while related to initialization parameter settings,

deserves its own place in the top ten list. The shared pool holds the PL/SQL and SQLlibraries as well as a multitude of other items. In 9i the list of shared pool areas was ableto easily fit on a single printed page with room to spare, in Oracle11g it takes 17 printed

pages. Sizing the shared pool properly is critical, and just because 10g and 11g offer some automation, believe me, setting the base size of the pool is still important.



I would hope that number four on our little hit parade is fairly self-explanatory, if youhave missing or improper indexes the optimizer will use full table scans or other lessoptimal access schemes to get at data. Proper indexes are vital to performance.

In 9i the PGA_AGGREGATE _TARGET, PAT for short, initialization parameter was

introduced. The PAT parameter was going to solve all of our sort, hash and temporarytable memory issues. Well, if set properly, PAT does solve many issues, but, we all haveseen that one set of processes, a report, an index build, or others, that defy a one-stop-shop approach to sort or hash area tuning. Afraid we must still use sort and hash areasettings on special occasions. Make sure you set the PAT such that at 5% per process itwill handle hashes and sorts.

The issue with no advanced indexes refers to not using function-based indexes, bitmapindexes, reverse key indexes or index-only-tables when they should be used. Oracle hasgiven us a multitude of indexes that, when used properly, can greatly enhance our database performance.

Improper SQL means using too complex, over written SQL, or, writing SQL that doesn’ttake into consideration Oracle’s built-in limitations. For example, doing over a 7 table

join in 9i and above means you may have to monkey with table order in the FROMclause. Why? Because in 9i and above the MAX_OPTIMIZER_PERMUTATIONS

parameter becomes a hidden parameter set at 2000, since the join paths equate to n! (afactorial of the number n) where n is the number of objects in the join, then 6! Is 720 and7! is 5040, meaning Oracle may not get to table 7 moving left to right evaluating paths

before it reaches the limit!

The indexes wide issue actually points to the whole rebuild/don’t rebuild indexes issues. Iam not going to argue that point right now. However, if there are excessive empty slots inyour monotonically increasing indexes (meaning they will not be refilled) then your indexes may need coalescing or rebuilding and if those indexes are used for indexscanning operations you will see a performance improvement. Enough said.

The no automatic analysis issue kind of falls by the wayside in 10g and 11g, however,since many of you are still on 9i and some on 8i it bears mentioning. The cost basedoptimizer runs on statistics, bad statistics lead to bad execution plans. However there arecertain tip-over points, a sort of cost based optimizer no-mans land, where the old plan is

better than the new plan. I suggest an automated plan that first exports critical tablestatistics and then performs analysis so that you have a retreat path. You will be happy toknow that in Oracle11g you can have automated analysis but it can be setup so that thenew statistics are only used after you approve them.

The RAID issues are a reflection of the whole RAID10 verses RAID5 issue. I likeRAID10 because it provides a higher IO bandwidth using modern dual read/writecontrollers that can read or write on either disk in a mirror, than a RAID5 setup for thesame storage volume. Of course you JBOD users who don’t use RAID could gainenormous benefit from either form of RAID.



So those where my top ten issues I would see over and over again at various sites,sometimes sites would have almost all of the top ten and many of the other issues as well.Hopefully this list will get you looking in your environment to see how many you caneliminate.

an analysis of database issues

Documents