Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: OLTP help

Re: OLTP help

From: Terry Sutton <>
Date: Fri, 18 Aug 2006 16:02:46 -0700
Message-ID: <013a01c6c31a$835a7f70$6610a8c0@TerryVaio>


I don't see block size as an issue that needs to be dealt with. As others have said, do you actually have a problem? 2300 buffer busy waits per day sure doesn't seem high, but the number of waits isn't important, the time spent waiting is what's important. But if you're doing a full table scan on all your queries on this table, and 95% of your queries use the "PK" columns, then you'll creating an inde on the "PK" columns will probably eliminate an enormous percentage of your logical reads. Reducing your logical reads will probably reduce your physical reads, and both will probably reduce your buffer busy waits (how much would depend on what the reason code for your BB waits is). This seems like a slam dunk to me.

I should point out, so Cary doesn't scold me, that you should confirm that the performance of the queries on this table are actually a problem which affects your users, rather than just being "bad" because they show up on a Statspack report. But that said, I don't see a real downside to having a primary key index on a table which is almost always queried by the columns which would be in that primary key.


  Okay, I'm a little OLTP-slow, so please be patient with this issue. I've got a table that's used heavily in an OLTP manner, residing in a DW (really an ODS). It averages 21,000,000 logical reads per day, 2300 buffer busy waits per day, and 7800 block changes per day. Its a status table used by an internally developed job scheduler, serving job schedules across 8 servers and 11 databases. I came across this table and have brought it up as an issue because of performance problems we're having in production, with this table understandably showing up at the top of worst offenders for various categories within STATSPACK reports.    

  The table has 11 columns, 100k rows, with 1 column updated the majority of the time (job status), with a composite key for the PK (never updated). The PK is in design only, with no physical index and/or constraint. Not sure why no index was created, but I'm thinking that may help a bit. My thought is to create a tablespace with a small block size, say 2 or 4K (vs. the 32K one this table is residing in now) and move it, along with various other tables used in the same OLTP fashion, to this 2k blocksize tablespace. I then thought I should create a physical PK within the same tablespace. My line of thinking is that access is nearly 95% of the time by PK columns - with an index and small blocksize, the number of blocks brought into cache and residing there would be very small and ideally cut down on the buffer busy waits. The logical reads should be cut down as well, since it'd be indexed access instead of full scans in the cache.    

  I'm second guessing myself as I keep thinking there's got to be a better design for this table, but am out of ideas. Anything I'm missing? I mean besides this is Oracle on Tru64 5.1b, GS1280 with 8 CPUs and 32GB of memory.    



-- Received on Fri Aug 18 2006 - 18:02:46 CDT

Original text of this message