Indicators of potential scaling issues
- From: Kevin Lidh <kevin.lidh@xxxxxxxxx>
- To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Sat, 4 Feb 2006 08:45:03 -0700
One of the systems I help maintain is a very large (5 TB) implementation of
a CRM product. My primary charge, though, is to assist our customer with
testing of new functionality on a very scaled-down (830 GB) version. We
have the typical problems of the CBO not making the same decisions because
of differing statistics (which I'm working on) but the point of this e-mail
was a meeting we had yesterday afternoon. My concern was that we aren't
looking at the right things to identify potentially bad, or worse yet
dibilitating, SQL before they get into production. Our customer's Oracle
consultant said high buffer gets per execution (+3000). I said there has to
be more that would be an indication of an SQL that won't scale when a
greater load is applied, meaning frequency and concurrency. He asked,
"Isn't buffer gets the leading indication of a scaling issue?" My question
was, "Isn't that like saying height is a leading factor for describing a
human?" He countered with the obvious question which I don't have the
answer to: what else would you look at?. I've read papers about the Tailor
atomic modelling method for capacity planning and I'm in the middle of Tom
Kyte's and Jonathan Lewis's new books but I think I'm still missing some
critical pieces. I apologize for the lack of brevity of this e-mail (and if
this isn't the right forum for this question) but I wanted to frame my
question so there isn't any ambiguity. My question is, are there
combinations of statistics and/or information I can get from the database
during the execution of a test on a scaled-down system which would indicate
that an SQL (or combination) won't scale up even if it performs fine in the
test? I have no problems doing the reading and research on my own if you
just have general ideas.
Thank you for your consideration of this question,
Kevin Lidh
kevin.lidh@xxxxxxxxx
Other related posts:
