Re: Table and index degree disparity

  • From: Stefan Koehler <contact@xxxxxxxx>
  • To: oracle-l <oracle-l@xxxxxxxxxxxxx>, sbecker6925@xxxxxxxxx
  • Date: Wed, 10 Feb 2016 19:10:13 +0100 (CET)

Hi Sandy,

Q1: No one is complaining about performance right now, although I have seem 
some queries that could be tuned. Maybe users are just used to that
level of performance? Not sure. Is it worth being proactive in this instance?

What are your SLAs for the corresponding business processes? Do you actually 
measure the response time of these? If you just look at query or SQL
level without focus on the business you may tune forever (e.g. "Compulsive 
Tuning Disorder") without any possible benefit to business / end users. I
just can highly recommend (once again) Method R for that, e.g. here on page 20: 
http://www.oracle.com/technetwork/testcontent/millsap-ch01-131133.pdf
or here: 
http://assets.red-gate.com/products/oracle-development/education/webinars/Assets/cary-millsap-performance-is-a-feature-webinar.pdf

P.S.: Please don't confuse this with reducing the resource consumption on 
database servers, if this is your goal, but you talked about end users and
performance.

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK
 
Sandra Becker <sbecker6925@xxxxxxxxx> hat am 8. Februar 2016 um 22:20 
geschrieben:

 Oracle EE 11g and 12c
 Both Exadata and non-Exadata environments

 While familiarizing myself with all the databases at my new job (still feels 
new after 4 months), I noticed that several tables and indexes in our
production databases have a degree of parallelism disparity.  I remember 
encountering some serious issues at my last employer that required getting
Oracle developers involved.  One of the items of concern that they raised was 
the degree disparity between tables and indexes, i.e. we had degree of
32 on in indexes and degree of 1 on the tables.  We were told to make them 
the same to avoid bottlenecks.  After resetting both sides to an
appropriate value for our environment, performance significantly improved.  
We had more tweaks to do (unfortunately, no code tweaks which would have
helped even more) before performance was acceptable.

 Question 1:  No one is complaining about performance right now, although I 
have seem some queries that could be tuned.  Maybe users are just used
to that level of performance?  Not sure.  Is it worth being proactive in this 
instance?  Our team is split on the value and I wanted other opinions.

 Question 2:  Same issue on our Exadata databases.  The DBA who initially set 
up the Exadata databases sees no value in making changes since we are
using HCC compression.  I am a newbie to Exadata and have been studying, but 
I haven't seen anything to indicate that we shouldn't still follow best
practices or be proactive.  Opinions?  Does the compression really remove the 
"bottleneck" situation from degree disparity?

 I appreciate your opinions and comments.  Thank  you.

 --
 Sandy B.
--
//www.freelists.org/webpage/oracle-l


Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 02-2016