RE: BCHR Tuning
Book me on the next flight to Sydney please. -Original Message- Sent: Monday, January 13, 2003 6:24 PM To: Multiple recipients of list ORACLE-L Morgens is very correct in saying tha all sorts of measurements have their place. Actually, the length-of-skirt measurement works very well for me. Here is the algorithm: Heat-by-day in inversely proportional to length of skirt which again is inversely proportional to my desire to have lunch outdoors at sidewalk cafe, but which directly affects my enjoyment of the day and inversely affects my productivity (much like this posting). Right now (Jan / Feb), we are experiencing our heatwaves (30+ Celsius by day, 20 by night = absolute bliss), so I get a lot of opportunity to streamline the algorithm and processes. Melbourne is the place to be, unless you can get to work on Bondi beach in Sydney, where the skirt length = zero. Of course, if you study the skirts or lack of it TOO intensely, this leads a high jealous-boyfriend-hit-ratio, which inversely affects my overall well-being and morale, so you need to find that optimal balance between appreciation and blatant gawking or technically put : maximum benefit within minimized response time. Ferenc Mantfeld -Original Message- From: Mogens Norgaard [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 12:00 PM To: Multiple recipients of list ORACLE-L Subject:Re: BCHR Tuning Something here doesn't compute. If you tried to use time-based measurements and didn't find out where the time went - well, bad for you. If you then stumbled on something, say the database startup/database shutdown ratio (would normally be fairly close to 1, but could vary) or the log file switch/archive log file ratio (again, could be close to 1 or 100% or something - or could vary) or the ratio of blocks from a certain index found in the permanent pool versus the number of PIO's required for that statement - or whatever - it would still be guesswork, checklist tuning, or what you'd prefer to call it. All sorts of measures have their place. All sorts of measures could prove interesting. When I went to school the famous example was the wolf population of Canada which seemed to follow the birthrate of children in Denmark. Or the length of skirts versus economic prosperity in the Western world, which also proved rather closely matched. If you want to measure response time (what else?) it just might be of interest to find out where the time is spent. The BCHR, the x/y, the DBStarup/DBShutdown ratio or other ratios or measurements might be important to find out symptoms of things - but to say that that kind of guesswork still has it's place is like saying that we should still carefully watch the wolf population of Canada or the skirt length in the Western World...because you never know. And that just might be the case: You never (will) know until you adopt an approach that is hierachical (spelling?) and which you can use to prioritize and quantify your efforts (try that with the BCHR - the x$kcbrbh, etc. of course are grossly wrong in those respects). Yep, I've been there, I've used it all, I've tried to use all the notes and articles regarding the wonderful statistics available in bstat/estat - I've been through the stages of collecting more and more queries and numbers and ratios until my file with scripts and queries was bigger than Holland. Yet it never gave me solutions, just a lot of things to check and change and fiddle with - without knowing which one to choose first, and how much it would help. The YAPP method works. There are cases where it is not 100% accurate. In most cases it's spot on. Watch where the monitoring tools are going. Spotlight in the latest edition have the YAPP method built in. Let's see what Oracle does in 10i. Precise has it. Steve Adams' scripts has it. This is not about the BCHR being low or high or in between. This is about using a METHOD instead of 100s of different numbers that don't mean anything. Mogens [EMAIL PROTECTED] wrote: >I too think the BCHR has its place, as a problem indicator. It can tell me >theres something wrong with my database. Say, I have this database >performing well, the users are happy, the BHR is mostly at 90%, and now it >suddenly shoots down to 70%, or it suddenly increases to 98. Somethings >amiss. Its less tasking, to code for scripts that query v$sysstat to >indicate me of some problems, rather than querying v$sqlarea. Or I need to >code for some intelligent scripts to query v$session_wait or >V$system_event. Or I need to look at the statspack reports every hour. The >point is when do I look at wait events? When the user calls me up? > >All the papers out there, asking us rightly, to look at wait events, trash >the BCHR. I think what the authors intended was to tell us that increasing >DB_BLOCK_BUFFERS was not the solution to
Re: BCHR Tuning
Ferenc, If I didn't say it before, I'll say it now: This was one of the better messages I've seen for a very long time. Jolly good laugh, as the English would say. Remind me to take you to lunch next time I'm in Melbourne (as if I'm in Australia very often ... ). Take care. Mogens mantfield wrote: Morgens is very correct in saying tha all sorts of measurements have their place. Actually, the length-of-skirt measurement works very well for me. Here is the algorithm: Heat-by-day in inversely proportional to length of skirt which again is inversely proportional to my desire to have lunch outdoors at sidewalk cafe, but which directly affects my enjoyment of the day and inversely affects my productivity (much like this posting). Right now (Jan / Feb), we are experiencing our heatwaves (30+ Celsius by day, 20 by night = absolute bliss), so I get a lot of opportunity to streamline the algorithm and processes. Melbourne is the place to be, unless you can get to work on Bondi beach in Sydney, where the skirt length = zero. Of course, if you study the skirts or lack of it TOO intensely, this leads a high jealous-boyfriend-hit-ratio, which inversely affects my overall well-being and morale, so you need to find that optimal balance between appreciation and blatant gawking or technically put : maximum benefit within minimized response time. Ferenc Mantfeld -Original Message- From: Mogens Norgaard [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 12:00 PM To: Multiple recipients of list ORACLE-L Subject: Re: BCHR Tuning Something here doesn't compute. If you tried to use time-based measurements and didn't find out where the time went - well, bad for you. If you then stumbled on something, say the database startup/database shutdown ratio (would normally be fairly close to 1, but could vary) or the log file switch/archive log file ratio (again, could be close to 1 or 100% or something - or could vary) or the ratio of blocks from a certain index found in the permanent pool versus the number of PIO's required for that statement - or whatever - it would still be guesswork, checklist tuning, or what you'd prefer to call it. All sorts of measures have their place. All sorts of measures could prove interesting. When I went to school the famous example was the wolf population of Canada which seemed to follow the birthrate of children in Denmark. Or the length of skirts versus economic prosperity in the Western world, which also proved rather closely matched. If you want to measure response time (what else?) it just might be of interest to find out where the time is spent. The BCHR, the x/y, the DBStarup/DBShutdown ratio or other ratios or measurements might be important to find out symptoms of things - but to say that that kind of guesswork still has it's place is like saying that we should still carefully watch the wolf population of Canada or the skirt length in the Western World...because you never know. And that just might be the case: You never (will) know until you adopt an approach that is hierachical (spelling?) and which you can use to prioritize and quantify your efforts (try that with the BCHR - the x$kcbrbh, etc. of course are grossly wrong in those respects). Yep, I've been there, I've used it all, I've tried to use all the notes and articles regarding the wonderful statistics available in bstat/estat - I've been through the stages of collecting more and more queries and numbers and ratios until my file with scripts and queries was bigger than Holland. Yet it never gave me solutions, just a lot of things to check and change and fiddle with - without knowing which one to choose first, and how much it would help. The YAPP method works. There are cases where it is not 100% accurate. In most cases it's spot on. Watch where the monitoring tools are going. Spotlight in the latest edition have the YAPP method built in. Let's see what Oracle does in 10i. Precise has it. Steve Adams' scripts has it. This is not about the BCHR being low or high or in between. This is about using a METHOD instead of 100s of different numbers that don't mean anything. Mogens [EMAIL PROTECTED] wrote: I too think the BCHR has its place, as a problem indicator. It can tell me theres something wrong with my database. Say, I have this database performing well, the users are happy, the BHR is mostly at 90%, and now it suddenly shoots down to 70%, or it suddenly increases to 98. Somethings amiss. Its less tasking, to code for scripts that query v$sysstat to indicate me of some problems, rather than querying v$sqlarea. Or I need to code for some intelligent scripts to query v$session_wait or V$system_event. Or I need to look at the statspack reports every hour. The point is when do I look at wait events? When the user calls me up? All the papers out there, asking us rightly, to look at wai
RE: BCHR Tuning
GASP... you mean I'm not the ONLY one who does that from time to time. I feel so much better! :-) >>WHEN does increasing the pctused to pctfree gap help ? And >>should this be done by increasing the PCTFREE or decreasing >>the PCTUSED - >>** It's a mistake I make quite often because of the image of >>two lines across a data block representing the pctused and >>pctfree levels. To push the pctfree line UP, you have to DECREASE >>the pctfree value - and the entire paragraph was written from >>the perspective of moving the lines, not changing the numbers. -Original Message- Lewis Sent: Saturday, January 18, 2003 3:34 PM To: Multiple recipients of list ORACLE-L Jared, Thanks for the note - I loved the closing lines especially. I have to say that I've already spotted two error in my note, one of them a silly slip, but the other is likely to cause confusion. Silly slip - in the bit about decreasing block sizes - Good point - especially in Oracle 9; and especially if the waits are for UNDO blocks, although that might (depending on the nature of the activity) increase the waits on segment header blocks ** That should have been "on the UNDO segment header blocks" in the last phrase - referring to the fact that a large transaction has to update its undo segment header block every time it fills an undo block and crosses into a new undo block. Confusing comment - in the bit about the 'gap' WHEN does increasing the pctused to pctfree gap help ? And should this be done by increasing the PCTFREE or decreasing the PCTUSED - ** It's a mistake I make quite often because of the image of two lines across a data block representing the pctused and pctfree levels. To push the pctfree line UP, you have to DECREASE the pctfree value - and the entire paragraph was written from the perspective of moving the lines, not changing the numbers. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- > >Thanks Jonathan, for a breakdown on the cause and cure >of buffer busy waits. > . . . > >The abstract for one of Niemic's presentation at IOUG states >that folks trying to encourage others to use some intelligence in >maintaining their systems must have some vested interest. > >This works both ways I guess. :) > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Robert Freeman INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Jared, Thanks for the note - I loved the closing lines especially. I have to say that I've already spotted two error in my note, one of them a silly slip, but the other is likely to cause confusion. Silly slip - in the bit about decreasing block sizes - Good point - especially in Oracle 9; and especially if the waits are for UNDO blocks, although that might (depending on the nature of the activity) increase the waits on segment header blocks ** That should have been "on the UNDO segment header blocks" in the last phrase - referring to the fact that a large transaction has to update its undo segment header block every time it fills an undo block and crosses into a new undo block. Confusing comment - in the bit about the 'gap' WHEN does increasing the pctused to pctfree gap help ? And should this be done by increasing the PCTFREE or decreasing the PCTUSED - ** It's a mistake I make quite often because of the image of two lines across a data block representing the pctused and pctfree levels. To push the pctfree line UP, you have to DECREASE the pctfree value - and the entire paragraph was written from the perspective of moving the lines, not changing the numbers. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- > >Thanks Jonathan, for a breakdown on the cause and cure >of buffer busy waits. > . . . > >The abstract for one of Niemic's presentation at IOUG states >that folks trying to encourage others to use some intelligence in >maintaining their systems must have some vested interest. > >This works both ways I guess. :) > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Wow! Thanks Jonathan, for a breakdown on the cause and cure of buffer busy waits. I was taken in at one time, ( long time ago) by some of these rules of thumb and quick tips, but it became apparent that there's really no such thing for tuning. The only rules of thumb I have any more are educated guesses used when designing a new database. And since I've had little opportunity to do that in the past 2 years', I'm hoping I remember how. :) The 'quick tips' that Mr Niemiec, and by extension, TUSC, advocates, are driven by the belief that all that is needed to make everything work perfectly is to follow a checklist and get all the numbers in order. If that's all it takes, then why are there DBA's? Just hire some MCSE's that can follow a checklist. This methodology implies that there is no science involved, just buy a recipe and be sure to follow instructions. It almost seems like the point is that anyone can maintain your database systems, if they just buy the right book. The abstract for one of Niemic's presentation at IOUG states that folks trying encourage others to use some intelligence in maintaining their systems must have some vested interest. This works both ways I guess. :) Again Jonathan, thank your clear and concise insights. Jared On Friday 17 January 2003 16:15, Jonathan Lewis wrote: > There was a flurry of notes about Richard Niemiec's > most recent article in Oracle Magazine, about which > ... -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
There was a flurry of notes about Richard Niemiec's most recent article in Oracle Magazine, about which I passed the comment: > >Having said that, I thought the article was far better >than usual. There was still plenty of scope for >criticism, but it seemed to convey more useful >information than usual, even though presentation >and ordering were somewhat garbled in places, and >there were several small errors and misunderstandings. > Jared, I think, suggested that it would be it would be appropriate to produce some sort of critique of the article to shed light on some of the criticisms that it had received. The following question came up on comp.databases.oracle.server today, so I took a few minutes to answer it - and thought I would offer my comments to the rest of the list for review. Since the question was about the paragraph on buffer busy waits, I have dissected just that paragraph. Don Burleson wrote in message <[EMAIL PROTECTED]>... >Rich Niemiec, president of IOUG writes in Oracle magazine (page 100, >Jan 2003): > >Buffer Busy - "This is a wait for a buffer that is being used in an >unshareable way or is being read into the buffer cache. . . . wait >is on a segment header. If this is the case, increase the freelist >groups or increase the pctused to pctfree gap." > >I was always under the impression (from Oracle Support) that: > >1 - An instance is only able to attach to one freelist group, and >multiple freelists groups are only for OPS/RAC systems. > >2 - The best way to reduce segment header contention is to add >multiple freelists, not freelist groups. > >Has anyone ever tried multiple freelists groups or increasing the >PCTUSED-PCTFREE "gap" top reduce segment header contention? I had to read the full text to check if there was any omission in your extract that might explain the oddity: Quoted text is at the margin, commentary indented: 4. Buffer Busy. This is a wait for a buffer that is being used in an unshareable way or is being read into the buffer cache. Sloppy wording, but technically not wrong, however (a) there are ways that a buffer can be used in an unsharable way that are not BBWs (e.g. write complete waits - although the newest versions of Oracle bypass this one). (b) grammar - if you eliminate the middle clause, you get "a buffer that ... is being read into the buffer cache" - data blocks are read into the buffer cache, the buffers are already there. (c) if a block is being read into the buffer cache, the buffer IS being used in an unsharable way, so the 'or' would be better as 'e.g.' Buffer busy waits should not be greater than 1 percent. One percent of what ? Physical reads, consistent gets, consistent gets plus current gets, consistent gets plus current gets plus buffer is pinned count ? If my buffer busy waits are much less than one percent of (say) my consistent gets, should I dismiss the issue - even if all those waits are for segment headers ? Should I dismiss the issue if the wait time is significant ? Check the Buffer Wait Statistics section (or V$WAITSTAT) to find out if the wait is on a segment header. If this is the case, increase the freelist groups or increase the pctused to pctfree gap. Step one for segment headers is to examine the freelists, not the freelist groups. There are side-effects to freelist groups that you do not want to introduce if the problem can be addressed through freelists. WHEN does increasing the pctused to pctfree gap help ? And should this be done by increasing the PCTFREE or decreasing the PCTUSED - or perhaps by changing both in the same direction but by different amounts. This comment displays the worst aspect of the 'quick tip' psychology - it seems to be designed to show that the author has some deep insight into subtle mechanics, but in the absence of an explanation the comment could encourage the novice DBA to do something inappropriate. If the wait is on an undo header, you can address this by adding rollback segments; I can agree with that - on the other hand, if the wait time is not significant, this might increase I/O activity and help to overload the I/O subsystem - so I might advise caution, and I might advise reducing the size of the rollback segments at the same time. if it's on an undo block, you need to reduce the data density on the table driving this consistent read This addresses the issue of one user trying to read an undo block whilst another user is modifying it - which could happen when one set of processes needs to read data in consistent mode VERY shortly after something else has changed it AND the undo blocks containing the required undo are still the most current undo blocks and are still subject to change. Data density is not really the issue. (Of course, you might ask how you find out which table is
RE: BCHR Tuning
Morgens is very correct in saying tha all sorts of measurements have their place. Actually, the length-of-skirt measurement works very well for me. Here is the algorithm: Heat-by-day in inversely proportional to length of skirt which again is inversely proportional to my desire to have lunch outdoors at sidewalk cafe, but which directly affects my enjoyment of the day and inversely affects my productivity (much like this posting). Right now (Jan / Feb), we are experiencing our heatwaves (30+ Celsius by day, 20 by night = absolute bliss), so I get a lot of opportunity to streamline the algorithm and processes. Melbourne is the place to be, unless you can get to work on Bondi beach in Sydney, where the skirt length = zero. Of course, if you study the skirts or lack of it TOO intensely, this leads a high jealous-boyfriend-hit-ratio, which inversely affects my overall well-being and morale, so you need to find that optimal balance between appreciation and blatant gawking or technically put : maximum benefit within minimized response time. Ferenc Mantfeld -Original Message- From: Mogens Norgaard [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 12:00 PM To: Multiple recipients of list ORACLE-L Subject:Re: BCHR Tuning Something here doesn't compute. If you tried to use time-based measurements and didn't find out where the time went - well, bad for you. If you then stumbled on something, say the database startup/database shutdown ratio (would normally be fairly close to 1, but could vary) or the log file switch/archive log file ratio (again, could be close to 1 or 100% or something - or could vary) or the ratio of blocks from a certain index found in the permanent pool versus the number of PIO's required for that statement - or whatever - it would still be guesswork, checklist tuning, or what you'd prefer to call it. All sorts of measures have their place. All sorts of measures could prove interesting. When I went to school the famous example was the wolf population of Canada which seemed to follow the birthrate of children in Denmark. Or the length of skirts versus economic prosperity in the Western world, which also proved rather closely matched. If you want to measure response time (what else?) it just might be of interest to find out where the time is spent. The BCHR, the x/y, the DBStarup/DBShutdown ratio or other ratios or measurements might be important to find out symptoms of things - but to say that that kind of guesswork still has it's place is like saying that we should still carefully watch the wolf population of Canada or the skirt length in the Western World...because you never know. And that just might be the case: You never (will) know until you adopt an approach that is hierachical (spelling?) and which you can use to prioritize and quantify your efforts (try that with the BCHR - the x$kcbrbh, etc. of course are grossly wrong in those respects). Yep, I've been there, I've used it all, I've tried to use all the notes and articles regarding the wonderful statistics available in bstat/estat - I've been through the stages of collecting more and more queries and numbers and ratios until my file with scripts and queries was bigger than Holland. Yet it never gave me solutions, just a lot of things to check and change and fiddle with - without knowing which one to choose first, and how much it would help. The YAPP method works. There are cases where it is not 100% accurate. In most cases it's spot on. Watch where the monitoring tools are going. Spotlight in the latest edition have the YAPP method built in. Let's see what Oracle does in 10i. Precise has it. Steve Adams' scripts has it. This is not about the BCHR being low or high or in between. This is about using a METHOD instead of 100s of different numbers that don't mean anything. Mogens [EMAIL PROTECTED] wrote: >I too think the BCHR has its place, as a problem indicator. It can tell me >theres something wrong with my database. Say, I have this database >performing well, the users are happy, the BHR is mostly at 90%, and now it >suddenly shoots down to 70%, or it suddenly increases to 98. Somethings >amiss. Its less tasking, to code for scripts that query v$sysstat to >indicate me of some problems, rather than querying v$sqlarea. Or I need to >code for some intelligent scripts to query v$session_wait or >V$system_event. Or I need to look at the statspack reports every hour. The >point is when do I look at wait events? When the user calls me up? > >All the papers out there, asking us rightly, to look at wait events, trash >the BCHR. I think what the authors intended was to tell us that increasing >DB_BLOCK_BUFFERS was not the solution to a low BCHR, and that a BCHR of 99% >does not mean a highly efficient database. Vice Versa, a BCHR of 50% does >not indicate a poorly perform
Re: BCHR Tuning
Something here doesn't compute. If you tried to use time-based measurements and didn't find out where the time went - well, bad for you. If you then stumbled on something, say the database startup/database shutdown ratio (would normally be fairly close to 1, but could vary) or the log file switch/archive log file ratio (again, could be close to 1 or 100% or something - or could vary) or the ratio of blocks from a certain index found in the permanent pool versus the number of PIO's required for that statement - or whatever - it would still be guesswork, checklist tuning, or what you'd prefer to call it. All sorts of measures have their place. All sorts of measures could prove interesting. When I went to school the famous example was the wolf population of Canada which seemed to follow the birthrate of children in Denmark. Or the length of skirts versus economic prosperity in the Western world, which also proved rather closely matched. If you want to measure response time (what else?) it just might be of interest to find out where the time is spent. The BCHR, the x/y, the DBStarup/DBShutdown ratio or other ratios or measurements might be important to find out symptoms of things - but to say that that kind of guesswork still has it's place is like saying that we should still carefully watch the wolf population of Canada or the skirt length in the Western World...because you never know. And that just might be the case: You never (will) know until you adopt an approach that is hierachical (spelling?) and which you can use to prioritize and quantify your efforts (try that with the BCHR - the x$kcbrbh, etc. of course are grossly wrong in those respects). Yep, I've been there, I've used it all, I've tried to use all the notes and articles regarding the wonderful statistics available in bstat/estat - I've been through the stages of collecting more and more queries and numbers and ratios until my file with scripts and queries was bigger than Holland. Yet it never gave me solutions, just a lot of things to check and change and fiddle with - without knowing which one to choose first, and how much it would help. The YAPP method works. There are cases where it is not 100% accurate. In most cases it's spot on. Watch where the monitoring tools are going. Spotlight in the latest edition have the YAPP method built in. Let's see what Oracle does in 10i. Precise has it. Steve Adams' scripts has it. This is not about the BCHR being low or high or in between. This is about using a METHOD instead of 100s of different numbers that don't mean anything. Mogens [EMAIL PROTECTED] wrote: I too think the BCHR has its place, as a problem indicator. It can tell me theres something wrong with my database. Say, I have this database performing well, the users are happy, the BHR is mostly at 90%, and now it suddenly shoots down to 70%, or it suddenly increases to 98. Somethings amiss. Its less tasking, to code for scripts that query v$sysstat to indicate me of some problems, rather than querying v$sqlarea. Or I need to code for some intelligent scripts to query v$session_wait or V$system_event. Or I need to look at the statspack reports every hour. The point is when do I look at wait events? When the user calls me up? All the papers out there, asking us rightly, to look at wait events, trash the BCHR. I think what the authors intended was to tell us that increasing DB_BLOCK_BUFFERS was not the solution to a low BCHR, and that a BCHR of 99% does not mean a highly efficient database. Vice Versa, a BCHR of 50% does not indicate a poorly performing database. Give me a database with a 45% BHR, and I can get it to 99% by running a few queries. Point well understood. It does not mean in any way that I should now ignore PIO's and start tuning LIO's. I still use BCHR. "What you infer from the BCHR is what counts". Raj "Yechiel Adar"To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Subject: Re: BCHR Tuning Sent by: root@fatcity. com
Re: BCHR Tuning
I too think the BCHR has its place, as a problem indicator. It can tell me
theres something wrong with my database. Say, I have this database
performing well, the users are happy, the BHR is mostly at 90%, and now it
suddenly shoots down to 70%, or it suddenly increases to 98. Somethings
amiss. Its less tasking, to code for scripts that query v$sysstat to
indicate me of some problems, rather than querying v$sqlarea. Or I need to
code for some intelligent scripts to query v$session_wait or
V$system_event. Or I need to look at the statspack reports every hour. The
point is when do I look at wait events? When the user calls me up?
All the papers out there, asking us rightly, to look at wait events, trash
the BCHR. I think what the authors intended was to tell us that increasing
DB_BLOCK_BUFFERS was not the solution to a low BCHR, and that a BCHR of 99%
does not mean a highly efficient database. Vice Versa, a BCHR of 50% does
not indicate a poorly performing database. Give me a database with a 45%
BHR, and I can get it to 99% by running a few queries. Point well
understood. It does not mean in any way that I should now ignore PIO's and
start tuning LIO's.
I still use BCHR. "What you infer from the BCHR is what counts".
Raj
"Yechiel
Adar"To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
Subject: Re: BCHR Tuning
Sent by:
root@fatcity.
com
January 13,
2003 10:58 AM
Please
respond to
ORACLE-L
Hello Anjo
I just had a tuning session with Dov Hit, from ACS in Israel.
He used some of the scripts that you showed him 2 years ago when you did
some work for Amdocs.
Anyway, after doing some search on the waits, he checked the BCHR and found
out that this database has only 40%. That led us on further checks and we
found more offending SQL's.
The BCHR has it's place.
Just do not measure yourself JUST by it.
Yechiel Adar
Mehish
- Original Message -
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Sent: Monday, January 13, 2003 3:03 AM
> Hmm,
>
> Lately? That actually started publicly in 1998 as far as I am concerned
;-)
> And acutally long before that.
>
> Anjo.
>
> - Original Message -
> To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
> Sent: Sunday, January 12, 2003 11:43 PM
>
>
> > On Friday 10 January 2003 14:48, Mogens Nørgaard wrote:
> > > Obviously, we don't know what we're talking about. I can see there's
a
> > > presentation by Rich Niemich at IOUG-A where he'll address all those
> > > idiots who are saying you should ignore the Cash Hit Ratio (and who
are
> > > all just after making big money on their products - I loved that
one).
> > > > Or modify the set up of these tools to take action when BCHR
> falls..
> > > >
> >
> > Here's the session info:
> >
> > Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM
> > Venue: Southern Hemisphere 2, Walt Disney World
> >Dolphin, Lake Buena Vista, FL
> >
> > Abstract: Lately, there has been a big push to ignore your
> > hit ratio with claims that it is meaningless. This shallow
> &
Re: BCHR Tuning
Hello Anjo I just had a tuning session with Dov Hit, from ACS in Israel. He used some of the scripts that you showed him 2 years ago when you did some work for Amdocs. Anyway, after doing some search on the waits, he checked the BCHR and found out that this database has only 40%. That led us on further checks and we found more offending SQL's. The BCHR has it's place. Just do not measure yourself JUST by it. Yechiel Adar Mehish - Original Message - To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Sent: Monday, January 13, 2003 3:03 AM > Hmm, > > Lately? That actually started publicly in 1998 as far as I am concerned ;-) > And acutally long before that. > > Anjo. > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Sunday, January 12, 2003 11:43 PM > > > > On Friday 10 January 2003 14:48, Mogens Nørgaard wrote: > > > Obviously, we don't know what we're talking about. I can see there's a > > > presentation by Rich Niemich at IOUG-A where he'll address all those > > > idiots who are saying you should ignore the Cash Hit Ratio (and who are > > > all just after making big money on their products - I loved that one). > > > > Or modify the set up of these tools to take action when BCHR > falls.. > > > > > > > > Here's the session info: > > > > Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM > > Venue: Southern Hemisphere 2, Walt Disney World > >Dolphin, Lake Buena Vista, FL > > > > Abstract: Lately, there has been a big push to ignore your > > hit ratio with claims that it is meaningless. This shallow > > minded view (usually by people who sell a tuning tool) ignores > > why people look at hit ratios and what they are looking for. > > This quick tip talk will show you what to look for and why. > > You will definitely know when, where & why to look at your > > hit ratio in the future. > > > > Show you why your hit ratio matters. How to analyze the > > hit ratio. Fallacies by those who want to sell you products > > and tools instead. > > > > > > Shallow Minded ?! > > > > Jared > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Jared Still > > INET: [EMAIL PROTECTED] > > > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > > San Diego, California-- Mailing list and web hosting services > > - > > To REMOVE yourself from this mailing list, send an E-Mail message > > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > > the message BODY, include a line containing: UNSUB ORACLE-L > > (or the name of mailing list you want to be removed from). You may > > also send the HELP command for other information (like subscribing). > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Anjo Kolk > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Yechiel Adar INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Re: BCHR Tuning
I personally find the turn the argument is taking rather dispiriting. I have, like everybody who has been working with Oracle for some time, used BCHR in the past (and queried X$KCBRBH and its twin, X$KCBCBH). To be honest, I even have had some quite interesting results - which I would get by other means today. I have later understood that buffer gets were indeed a superior yardstick - till quite recently some experiments with IOTs convinced me that in some cases you had much better results in terms of response time (what ultimately matters) with slightly more buffer gets and more physical reads than what you could achieve. We all want to close on those outrageously bad lines of code or, more subtly, that poorly thought process. There is more than one angle of approach, some people will swear by trace files, other by events and waits, others by V$SQL or simply by code review or listening to end-users ... I guess it depends on whether you are more at heart a closet SA or a closet developer, and even in the later case whether you are a debugger artist or somebody trying to think globally; we are wired differently, all approaches may be respectable if taken with a pinch of salt. I would gladly say of Oracle tuning what my favorite author, Chamfort, says of love : "In love, everything is true, everything is false; it is the one subject on which one cannot express an absurdity." The holy war BCHR vs anti-BCHR has a definite Swiftian smell. My 0.02 euro. >- Original Message - >From: Jared Still <[EMAIL PROTECTED]> >To: Multiple recipients of list ORACLE-L ><[EMAIL PROTECTED]> >Sent: Sun, 12 Jan 2003 22:08:37 > > >And quite a number of folks were making use of the >v$ >stats quite some time before that with little >regard for the BCHR, >though maybe not officially yet ignoring the BCHR > >Jared > > >On Sunday 12 January 2003 17:03, Anjo Kolk wrote: >> Hmm, >> >> Lately? That actually started publicly in 1998 as >far as I am concerned ;-) >> And acutally long before that. >> >> Anjo. >> >> - Original Message - >> To: "Multiple recipients of list ORACLE-L" ><[EMAIL PROTECTED]> >> Sent: Sunday, January 12, 2003 11:43 PM >> >> > On Friday 10 January 2003 14:48, Mogens >Nørgaard wrote: >> > > Obviously, we don't know what we're talking >about. I can see there's a >> > > presentation by Rich Niemich at IOUG-A where >he'll address all those >> > > idiots who are saying you should ignore the >Cash Hit Ratio (and who are >> > > all just after making big money on their >products - I loved that one). >> > > >> > > > Or modify the set up of these tools to take >action when BCHR >> >> falls.. >> >> > Here's the session info: >> > >> > Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM >> > Venue: Southern Hemisphere 2, Walt Disney World > >> >Dolphin, Lake Buena Vista, FL >> > >> > Abstract: Lately, there has been a big push to >ignore your >> > hit ratio with claims that it is meaningless. >This shallow >> > minded view (usually by people who sell a >tuning tool) ignores >> > why people look at hit ratios and what they are >looking for. >> > This quick tip talk will show you what to look >for and why. >> > You will definitely know when, where & why to >look at your >> > hit ratio in the future. >> > >> > Show you why your hit ratio matters. How to >analyze the >> > hit ratio. Fallacies by those who want to sell >you products >> > and tools instead. >> > >> > >> > Shallow Minded ?! >> > >> > Jared >> > -- >> > Please see the official ORACLE-L FAQ: >http://www.orafaq.net >> > -- >> > Author: Jared Still >> > INET: [EMAIL PROTECTED] >> > >> > Fat City Network Services-- 858-538-5051 >http://www.fatcity.com >> > San Diego, California-- Mailing list >and web hosting services >> > >> > To REMOVE yourself from this mailing list, send >an E-Mail message >> > to: [EMAIL PROTECTED] (note EXACT spelling >of 'ListGuru') and in >> > the message BODY, include a line containing: >UNSUB ORACLE-L >> > (or the name of mailing list you want to be >removed from). You may >> > also send the HELP command for other >information (like subscribing). >-- >Please see the official ORACLE-L FAQ: >http://www.orafaq.net >-- >Author: Jared Still > INET: [EMAIL PROTECTED] > >Fat City Network Services-- 858-538-5051 >http://www.fatcity.com >San Diego, California-- Mailing list and >web hosting services >To REMOVE yourself from this mailing list, send an >E-Mail message >to: [EMAIL PROTECTED] (note EXACT spelling of >'ListGuru') and in >the message BODY, include a line containing: UNSUB >ORACLE-L >(or the name of mailing list you want to be removed >from). You may >also send the HELP command for other information >(like subscribing). >--- >-- >---
Re: BCHR Tuning
And quite a number of folks were making use of the v$ stats quite some time before that with little regard for the BCHR, though maybe not officially yet ignoring the BCHR Jared On Sunday 12 January 2003 17:03, Anjo Kolk wrote: > Hmm, > > Lately? That actually started publicly in 1998 as far as I am concerned ;-) > And acutally long before that. > > Anjo. > > - Original Message - > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Sunday, January 12, 2003 11:43 PM > > > On Friday 10 January 2003 14:48, Mogens Nørgaard wrote: > > > Obviously, we don't know what we're talking about. I can see there's a > > > presentation by Rich Niemich at IOUG-A where he'll address all those > > > idiots who are saying you should ignore the Cash Hit Ratio (and who are > > > all just after making big money on their products - I loved that one). > > > > > > > Or modify the set up of these tools to take action when BCHR > > falls.. > > > Here's the session info: > > > > Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM > > Venue: Southern Hemisphere 2, Walt Disney World > >Dolphin, Lake Buena Vista, FL > > > > Abstract: Lately, there has been a big push to ignore your > > hit ratio with claims that it is meaningless. This shallow > > minded view (usually by people who sell a tuning tool) ignores > > why people look at hit ratios and what they are looking for. > > This quick tip talk will show you what to look for and why. > > You will definitely know when, where & why to look at your > > hit ratio in the future. > > > > Show you why your hit ratio matters. How to analyze the > > hit ratio. Fallacies by those who want to sell you products > > and tools instead. > > > > > > Shallow Minded ?! > > > > Jared > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Jared Still > > INET: [EMAIL PROTECTED] > > > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > > San Diego, California-- Mailing list and web hosting services > > - > > To REMOVE yourself from this mailing list, send an E-Mail message > > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > > the message BODY, include a line containing: UNSUB ORACLE-L > > (or the name of mailing list you want to be removed from). You may > > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Hmm, Lately? That actually started publicly in 1998 as far as I am concerned ;-) And acutally long before that. Anjo. - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Sunday, January 12, 2003 11:43 PM > On Friday 10 January 2003 14:48, Mogens Nørgaard wrote: > > Obviously, we don't know what we're talking about. I can see there's a > > presentation by Rich Niemich at IOUG-A where he'll address all those > > idiots who are saying you should ignore the Cash Hit Ratio (and who are > > all just after making big money on their products - I loved that one). > > > Or modify the set up of these tools to take action when BCHR falls.. > > > > > Here's the session info: > > Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM > Venue: Southern Hemisphere 2, Walt Disney World >Dolphin, Lake Buena Vista, FL > > Abstract: Lately, there has been a big push to ignore your > hit ratio with claims that it is meaningless. This shallow > minded view (usually by people who sell a tuning tool) ignores > why people look at hit ratios and what they are looking for. > This quick tip talk will show you what to look for and why. > You will definitely know when, where & why to look at your > hit ratio in the future. > > Show you why your hit ratio matters. How to analyze the > hit ratio. Fallacies by those who want to sell you products > and tools instead. > > > Shallow Minded ?! > > Jared > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Jared Still > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Anjo Kolk INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
and those people "sell a tuning tool" hm, I hadn't noticed any selling going on here. Or perhaps it's been subliminal? --- Jared Still <[EMAIL PROTECTED]> wrote: > On Friday 10 January 2003 14:48, Mogens Nørgaard wrote: > > Obviously, we don't know what we're talking about. I can see > there's a > > presentation by Rich Niemich at IOUG-A where he'll address all > those > > idiots who are saying you should ignore the Cash Hit Ratio (and who > are > > all just after making big money on their products - I loved that > one). > > > Or modify the set up of these tools to take action when BCHR > falls.. > > > > > Here's the session info: > > Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM > Venue: Southern Hemisphere 2, Walt Disney World >Dolphin, Lake Buena Vista, FL > > Abstract: Lately, there has been a big push to ignore your > hit ratio with claims that it is meaningless. This shallow > minded view (usually by people who sell a tuning tool) ignores > why people look at hit ratios and what they are looking for. > This quick tip talk will show you what to look for and why. > You will definitely know when, where & why to look at your > hit ratio in the future. > > Show you why your hit ratio matters. How to analyze the > hit ratio. Fallacies by those who want to sell you products > and tools instead. > > > Shallow Minded ?! > > Jared > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Jared Still > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
On Friday 10 January 2003 14:48, Mogens Nørgaard wrote: > Obviously, we don't know what we're talking about. I can see there's a > presentation by Rich Niemich at IOUG-A where he'll address all those > idiots who are saying you should ignore the Cash Hit Ratio (and who are > all just after making big money on their products - I loved that one). > > Or modify the set up of these tools to take action when BCHR falls.. > > Here's the session info: Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM Venue: Southern Hemisphere 2, Walt Disney World Dolphin, Lake Buena Vista, FL Abstract: Lately, there has been a big push to ignore your hit ratio with claims that it is meaningless. This shallow minded view (usually by people who sell a tuning tool) ignores why people look at hit ratios and what they are looking for. This quick tip talk will show you what to look for and why. You will definitely know when, where & why to look at your hit ratio in the future. Show you why your hit ratio matters. How to analyze the hit ratio. Fallacies by those who want to sell you products and tools instead. Shallow Minded ?! Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Jonathan, Since you've mentioned it, how about summarizing those mistakes for the rest of us? This goes for you too, Mogens. :) A few things didn't sound right to me, but I don't often spend time doing actual tuning of the database. My tuning usually involves fixing or working around development errrors. When I have to actually tune the database, I just pick the worst offenders from the wait stats, and then figure out how to fix them by reading everyone else's research and/or experimenting. Which is a long winded way of saying this stuff doesn't last long in my internal LIFO buffer. :) Jared On Saturday 11 January 2003 01:16, Jonathan Lewis wrote: > A brilliant solution. > > I knew that the "real" Steve Adams couldn't > have edited it when I say the line starting: > > > Latches are low-level queuing mechanisms > > > The man who wrote THE book about latches in > Oracle couldn't possibly have made the mistake > of thinking that latching was a queueing mechanism. > In fact, there is a bit in Steve's chapter on latches > which says quite specifically: > > "latches do not support request queueing > latch requests are not necessarily serviced in > order." > > > > Having said that, I thought the article was far better > than usual. There was still plenty of scope for > criticism, but it seemed to convey more useful > information than usual, even though presentation > and ordering were somewhat garbled in places, and > there were several small errors and misunderstandings. > > > Regards > > Jonathan Lewis > http://www.jlcomp.demon.co.uk > > Coming soon a new one-day tutorial: > Cost Based Optimisation > (see http://www.jlcomp.demon.co.uk/tutorial.html ) > > Next Seminar dates: > (see http://www.jlcomp.demon.co.uk/seminar.html ) > > England__January 21/23 > USA_(CA, TX)_August > > > The Co-operative Oracle Users' FAQ > http://www.jlcomp.demon.co.uk/faq/ind_faq.html > > > > > > -Original Message- > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > Date: 11 January 2003 06:51 > > > Undskyld! > But you assumed that the Steve Adams mentioned at the bottom of that > article is the one you know ;)) > > They should have mentioned Steve's Web site. They did not miss tusc > and ioug URLs. Ummm. wonder why not ;) ;) > > I say poor Copy Editing on part of the publishers. > > - Kirti -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
The real Steve is sitting about 42 centimeters from me talking to his family in Australia. And I think the flight from Sydney took about 2000 hours, so it cannot possibly be him mentioned in the article by Rich. Thanks for pointing this out, Kerti. Suddenly it all makes sense. There are at least two SA's in the world. Mogens Jonathan Lewis wrote: A brilliant solution. I knew that the "real" Steve Adams couldn't have edited it when I say the line starting: Latches are low-level queuing mechanisms The man who wrote THE book about latches in Oracle couldn't possibly have made the mistake of thinking that latching was a queueing mechanism. In fact, there is a bit in Steve's chapter on latches which says quite specifically: "latches do not support request queueing latch requests are not necessarily serviced in order." Having said that, I thought the article was far better than usual. There was still plenty of scope for criticism, but it seemed to convey more useful information than usual, even though presentation and ordering were somewhat garbled in places, and there were several small errors and misunderstandings. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Date: 11 January 2003 06:51 Undskyld! But you assumed that the Steve Adams mentioned at the bottom of that article is the one you know ;)) They should have mentioned Steve's Web site. They did not miss tusc and ioug URLs. Ummm. wonder why not ;) ;) I say poor Copy Editing on part of the publishers. - Kirti -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
A brilliant solution. I knew that the "real" Steve Adams couldn't have edited it when I say the line starting: Latches are low-level queuing mechanisms The man who wrote THE book about latches in Oracle couldn't possibly have made the mistake of thinking that latching was a queueing mechanism. In fact, there is a bit in Steve's chapter on latches which says quite specifically: "latches do not support request queueing latch requests are not necessarily serviced in order." Having said that, I thought the article was far better than usual. There was still plenty of scope for criticism, but it seemed to convey more useful information than usual, even though presentation and ordering were somewhat garbled in places, and there were several small errors and misunderstandings. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Date: 11 January 2003 06:51 Undskyld! But you assumed that the Steve Adams mentioned at the bottom of that article is the one you know ;)) They should have mentioned Steve's Web site. They did not miss tusc and ioug URLs. Ummm. wonder why not ;) ;) I say poor Copy Editing on part of the publishers. - Kirti -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
1997, in Vejle, I had an interesting meeting with Bjørn Engsig about Sybase->Oracle migration. Denmark... small Great country. Nice, kind and friendly people who work diligently in peaceful atmosphere -- I love it. -- Vladimir Begun The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. Rachel Carmichael wrote: oh you tempter! I'd love to go back to Cophenhagen, Tivoli will be fun in May. If I get on a plane right after IOUGa and don't bother to stop and do laundry, I could make it. My boss would kill me though. I do plan on attending that presentation at IOUG. No way I can give up the chance to sit in the front and ask innocent questions. --- Mogens_Nørgaard <[EMAIL PROTECTED]> wrote: Obviously, we don't know what we're talking about. I can see there's a presentation by Rich Niemich at IOUG-A where he'll address all those idiots who are saying you should ignore the Cash Hit Ratio (and who are all just after making big money on their products - I loved that one). Well, to be on the safe side he's also written a very bad article (it's even - amazingly - got the NAMES of the typical waits wrong) about waits in Oracle Magasine. The editor can be excused. But what I truly love is the writing at the bottom of the article, with very small print, stating: "Editing help: Steve Adams". Right. Steve would write that kind of stuff and get the wait names wrong. Yep. As a consulting company we here at Miracle are delighted: We expect a lot of calls from customers who cannot locate these events or find events that are not mentioned in the article. Heh-heh. I love it. I'm just really sad I can't be at IOUG-A. Here's another idea: Why don't you all come to my 42nd birthday, which we'll celebrate on May 2nd (a Friday) here in Maaloev, Denmark? You're all welcome, and we'll find ways to let you sleep either in the Garage (our HQ) or my house. Then we'll do some cool presentations in the afternoon and celebrate in the evening. Let me know when you planes land in Copenhagen airport and I'll pick you up. Mogens -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Vladimir Begun INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
They win either way. Remember I'll finance beer for your class, too...I'm not sure about dancing in your class, though. The solution is of course that we'll keep partying on Saturday and possible Sunday as well, so you should be able to do both. Mogens Jonathan Lewis wrote: I've had a semi-official request to do my CBO class on Friday just after IOUG-A, rather than collide with their Sunday classes - and now you want everyone to go to your house for beer instead ! If I don't get a good audience I shall be blaming you. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Date: 10 January 2003 23:34 I love it. I'm just really sad I can't be at IOUG-A. Here's another idea: Why don't you all come to my 42nd birthday, which we'll celebrate on May 2nd (a Friday) here in Maaloev, Denmark? You're all welcome, and we'll find ways to let you sleep either in the Garage (our HQ) or my house. Then we'll do some cool presentations in the afternoon and celebrate in the evening. Let me know when you planes land in Copenhagen airport and I'll pick you up. Mogens
RE: BCHR Tuning
Undskyld! But you assumed that the Steve Adams mentioned at the bottom of that article is the one you know ;)) They should have mentioned Steve's Web site. They did not miss tusc and ioug URLs. Ummm. wonder why not ;) ;) I say poor Copy Editing on part of the publishers. - Kirti -Original Message-From: Mogens Nørgaard [mailto:[EMAIL PROTECTED]]Sent: Friday, January 10, 2003 4:49 PMTo: Multiple recipients of list ORACLE-LSubject: Re: BCHR TuningObviously, we don't know what we're talking about. I can see there's a presentation by Rich Niemich at IOUG-A where he'll address all those idiots who are saying you should ignore the Cash Hit Ratio (and who are all just after making big money on their products - I loved that one). Well, to be on the safe side he's also written a very bad article (it's even - amazingly - got the NAMES of the typical waits wrong) about waits in Oracle Magasine. The editor can be excused. But what I truly love is the writing at the bottom of the article, with very small print, stating: "Editing help: Steve Adams". Right. Steve would write that kind of stuff and get the wait names wrong. Yep. As a consulting company we here at Miracle are delighted: We expect a lot of calls from customers who cannot locate these events or find events that are not mentioned in the article. Heh-heh.I love it. I'm just really sad I can't be at IOUG-A. Here's another idea: Why don't you all come to my 42nd birthday, which we'll celebrate on May 2nd (a Friday) here in Maaloev, Denmark? You're all welcome, and we'll find ways to let you sleep either in the Garage (our HQ) or my house. Then we'll do some cool presentations in the afternoon and celebrate in the evening. Let me know when you planes land in Copenhagen airport and I'll pick you up.MogensDeshpande, Kirti wrote: Or modify the set up of these tools to take action when BCHR falls.. and that is to execute Connor's script ;) No more blinking red icons... or beepilepsy attacks... ;) - Kirti -Original Message-From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]]Sent: Friday, January 10, 2003 12:04 PMTo: Multiple recipients of list ORACLE-LSubject: RE: BCHR Tuning Rich, That is the first alarm that I turn off as soon as I establish a new DB connection ... even the operators in our Computer room know to ignore that alarm. 8:) Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -Original Message- From: Jesse, Rich [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 11:54 AM To: Multiple recipients of list ORACLE-L Subject: RE: BCHR Tuning And it is! Quest's Spotlight on Oracle (the new v3.0 has some great graphing) has alerted me nine times this week that the BCHR on my production ERP/MRP system was 0.00%. OF COURSE, I immediately bumped off the 200+ sessions, boosted the buffer cache by 25% and bounced the instance each time I got the alarm. ;) Rich
Re: BCHR Tuning
I've had a semi-official request to do my CBO class on Friday just after IOUG-A, rather than collide with their Sunday classes - and now you want everyone to go to your house for beer instead ! If I don't get a good audience I shall be blaming you. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Coming soon a new one-day tutorial: Cost Based Optimisation (see http://www.jlcomp.demon.co.uk/tutorial.html ) Next Seminar dates: (see http://www.jlcomp.demon.co.uk/seminar.html ) England__January 21/23 USA_(CA, TX)_August The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html -Original Message- To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> Date: 10 January 2003 23:34 >I love it. I'm just really sad I can't be at IOUG-A. Here's another >idea: Why don't you all come to my 42nd birthday, which we'll celebrate >on May 2nd (a Friday) here in Maaloev, Denmark? You're all welcome, and >we'll find ways to let you sleep either in the Garage (our HQ) or my >house. Then we'll do some cool presentations in the afternoon and >celebrate in the evening. > >Let me know when you planes land in Copenhagen airport and I'll pick you up. > >Mogens > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
oh you tempter! I'd love to go back to Cophenhagen, Tivoli will be fun in May. If I get on a plane right after IOUGa and don't bother to stop and do laundry, I could make it. My boss would kill me though. I do plan on attending that presentation at IOUG. No way I can give up the chance to sit in the front and ask innocent questions. --- Mogens_Nørgaard <[EMAIL PROTECTED]> wrote: > Obviously, we don't know what we're talking about. I can see there's > a > presentation by Rich Niemich at IOUG-A where he'll address all those > idiots who are saying you should ignore the Cash Hit Ratio (and who > are > all just after making big money on their products - I loved that > one). > Well, to be on the safe side he's also written a very bad article > (it's > even - amazingly - got the NAMES of the typical waits wrong) about > waits > in Oracle Magasine. The editor can be excused. But what I truly love > is > the writing at the bottom of the article, with very small print, > stating: "Editing help: Steve Adams". Right. Steve would write that > kind > of stuff and get the wait names wrong. Yep. As a consulting company > we > here at Miracle are delighted: We expect a lot of calls from > customers > who cannot locate these events or find events that are not mentioned > in > the article. Heh-heh. > > I love it. I'm just really sad I can't be at IOUG-A. Here's another > idea: Why don't you all come to my 42nd birthday, which we'll > celebrate > on May 2nd (a Friday) here in Maaloev, Denmark? You're all welcome, > and > we'll find ways to let you sleep either in the Garage (our HQ) or my > house. Then we'll do some cool presentations in the afternoon and > celebrate in the evening. > > Let me know when you planes land in Copenhagen airport and I'll pick > you up. > > Mogens > > > > Deshpande, Kirti wrote: > > > Or modify the set up of these tools to take action when BCHR > falls.. > > > > and that is to execute Connor's script ;) > > > > No more blinking red icons... or beepilepsy attacks... ;) > > > > - Kirti > > > > > > -Original Message- > > From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 10, 2003 12:04 PM > > To: Multiple recipients of list ORACLE-L > > Subject: RE: BCHR Tuning > > > > Rich, > > > > That is the first alarm that I turn off as soon as I establish a > new > > DB connection ... even the operators in our Computer room know to > > ignore that alarm. > > > > 8:) > > > > Raj > > __ > > Rajendra Jamadagni MIS, ESPN Inc. > > Rajendra dot Jamadagni at ESPN dot com > > Any opinion expressed here is personal and doesn't reflect that of > > ESPN Inc. > > QOTD: Any clod can have facts, but having an opinion is an art! > > > > > > -Original Message- > > From: Jesse, Rich [mailto:[EMAIL PROTECTED]] > > Sent: Friday, January 10, 2003 11:54 AM > > To: Multiple recipients of list ORACLE-L > > Subject: RE: BCHR Tuning > > > > > > And it is! Quest's Spotlight on Oracle (the new v3.0 has some > great > > graphing) has alerted me nine times this week that the BCHR on my > > production > > ERP/MRP system was 0.00%. > > > > OF COURSE, I immediately bumped off the 200+ sessions, boosted the > buffer > > cache by 25% and bounced the instance each time I got the alarm. > ;) > > > > Rich > > > > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Obviously, we don't know what we're talking about. I can see there's a presentation
by Rich Niemich at IOUG-A where he'll address all those idiots who are saying
you should ignore the Cash Hit Ratio (and who are all just after making big
money on their products - I loved that one). Well, to be on the safe side
he's also written a very bad article (it's even - amazingly - got the NAMES
of the typical waits wrong) about waits in Oracle Magasine. The editor can
be excused. But what I truly love is the writing at the bottom of the article,
with very small print, stating: "Editing help: Steve Adams". Right. Steve
would write that kind of stuff and get the wait names wrong. Yep. As a consulting
company we here at Miracle are delighted: We expect a lot of calls from customers
who cannot locate these events or find events that are not mentioned in the
article. Heh-heh.
I love it. I'm just really sad I can't be at IOUG-A. Here's another idea:
Why don't you all come to my 42nd birthday, which we'll celebrate on May
2nd (a Friday) here in Maaloev, Denmark? You're all welcome, and we'll find
ways to let you sleep either in the Garage (our HQ) or my house. Then we'll
do some cool presentations in the afternoon and celebrate in the evening.
Let me know when you planes land in Copenhagen airport and I'll pick you
up.
Mogens
Deshpande, Kirti wrote:
RE: BCHR Tuning
Or modify the set up of these tools to take
action when BCHR falls..
and that is to execute Connor's script
;)
No more blinking red icons... or beepilepsy
attacks... ;)
- Kirti
-Original Message-
From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 12:04 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: BCHR Tuning
Rich,
That is the first alarm that I turn off as soon as I
establish a new DB connection ... even the operators in our Computer room
know to ignore that alarm.
8:)
Raj
__
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect
that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is
an art!
-Original Message-
From: Jesse, Rich [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 11:54 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: BCHR Tuning
And it is! Quest's Spotlight on Oracle (the new v3.0
has some great
graphing) has alerted me nine times this week that the
BCHR on my production
ERP/MRP system was 0.00%.
OF COURSE, I immediately bumped off the 200+ sessions,
boosted the buffer
cache by 25% and bounced the instance each time I got the
alarm. ;)
Rich
RE: BCHR Tuning
Title: RE: BCHR Tuning Or modify the set up of these tools to take action when BCHR falls.. and that is to execute Connor's script ;) No more blinking red icons... or beepilepsy attacks... ;) - Kirti -Original Message-From: Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]]Sent: Friday, January 10, 2003 12:04 PMTo: Multiple recipients of list ORACLE-LSubject: RE: BCHR Tuning Rich, That is the first alarm that I turn off as soon as I establish a new DB connection ... even the operators in our Computer room know to ignore that alarm. 8:) Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -Original Message- From: Jesse, Rich [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 11:54 AM To: Multiple recipients of list ORACLE-L Subject: RE: BCHR Tuning And it is! Quest's Spotlight on Oracle (the new v3.0 has some great graphing) has alerted me nine times this week that the BCHR on my production ERP/MRP system was 0.00%. OF COURSE, I immediately bumped off the 200+ sessions, boosted the buffer cache by 25% and bounced the instance each time I got the alarm. ;) Rich
RE: BCHR Tuning
Title: RE: BCHR Tuning Rich, That is the first alarm that I turn off as soon as I establish a new DB connection ... even the operators in our Computer room know to ignore that alarm. 8:) Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed here is personal and doesn't reflect that of ESPN Inc. QOTD: Any clod can have facts, but having an opinion is an art! -Original Message- From: Jesse, Rich [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 11:54 AM To: Multiple recipients of list ORACLE-L Subject: RE: BCHR Tuning And it is! Quest's Spotlight on Oracle (the new v3.0 has some great graphing) has alerted me nine times this week that the BCHR on my production ERP/MRP system was 0.00%. OF COURSE, I immediately bumped off the 200+ sessions, boosted the buffer cache by 25% and bounced the instance each time I got the alarm. ;) Rich *This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*1
RE: BCHR Tuning
And it is! Quest's Spotlight on Oracle (the new v3.0 has some great graphing) has alerted me nine times this week that the BCHR on my production ERP/MRP system was 0.00%. OF COURSE, I immediately bumped off the 200+ sessions, boosted the buffer cache by 25% and bounced the instance each time I got the alarm. ;) Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -Original Message- > From: Robert Eskridge [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 10, 2003 10:05 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: BCHR Tuning > > > Of course it dropped dramatically. That's because you are no longer > doing 99% of the buffer gets that you were wasting to begin with. > > If it drops my resource use and increases my performanc, I'd love to > have a BCHR of 1%. (I know that's extreme, but wouldn't it be > cool..?) -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jesse, Rich INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Classic! --- "Fink, Dan" <[EMAIL PROTECTED]> wrote: > Here's an excellent real life example of why BCHR is not a good > tuning > metric and you should focus on reducing I/Os. > A simple fix for a query and here is the resulting email to the > client, who > understands that BCHR is not good. A little techie humor... > > I have good news and I have bad news. > > The good news is that the elapsed query time and total I/Os for the > latest > iteration dropped significantly. > > Old --> 1:42 min 2,715,659 i/os (15,925 physical) > > New --> 22 seconds 3318 i/os (2861) > > However, the bad news is that the Buffer Cache Hit Ratio dropped > dramatically! > > Old --> 99.36% > > New --> 13.77% > > So, I have undone all the changes I made and will begin looking at > other > methods to improve performance! > > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Dan, I apologize for not detecting the humor at first and giving a serious reply. Either I had some sort of weird window setting emphasizing the goofball portion of the message, or I need to tune my humor detector. (This is not a good sign on a Friday) -rje F> Here's an excellent real life example of why BCHR is not a good tuning F> metric and you should focus on reducing I/Os. F> A simple fix for a query and here is the resulting email to the client, who F> understands that BCHR is not good. A little techie humor... F> I have good news and I have bad news. F> The good news is that the elapsed query time and total I/Os for the latest F> iteration dropped significantly. Old -->> 1:42 min 2,715,659 i/os (15,925 physical) New -->> 22 seconds 3318 i/os (2861) F> However, the bad news is that the Buffer Cache Hit Ratio dropped F> dramatically! Old -->> 99.36% New -->> 13.77% F> So, I have undone all the changes I made and will begin looking at other F> methods to improve performance! -rje -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Robert Eskridge INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: BCHR Tuning
Of course it dropped dramatically. That's because you are no longer doing 99% of the buffer gets that you were wasting to begin with. If it drops my resource use and increases my performanc, I'd love to have a BCHR of 1%. (I know that's extreme, but wouldn't it be cool..?) F> Here's an excellent real life example of why BCHR is not a good tuning F> metric and you should focus on reducing I/Os. F> A simple fix for a query and here is the resulting email to the client, who F> understands that BCHR is not good. A little techie humor... F> I have good news and I have bad news. F> The good news is that the elapsed query time and total I/Os for the latest F> iteration dropped significantly. Old -->> 1:42 min 2,715,659 i/os (15,925 physical) New -->> 22 seconds 3318 i/os (2861) F> However, the bad news is that the Buffer Cache Hit Ratio dropped F> dramatically! Old -->> 99.36% New -->> 13.77% F> So, I have undone all the changes I made and will begin looking at other F> methods to improve performance! -rje -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Robert Eskridge INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
