High CPU usage on select

Question

This is a spin off from another thread which started off as slow inserts. But what actaully happens is every insert is preceded by select it turned out that the select was slow.
We have a multi-tier web application conencting to the DB using connection pool and inserting about a 100000 records in a table. To isolate the issue I wrote a PL/SQL which does the same thing.
This problem happens every time the schema is recreated or the table dropped and created again and we start inserting. When the table is empty, the selects choose a full table scan but as the records are inserted it continues to use the same even though after a few thousands of rows I run stats. But as its running if gather stats and flush the shared pool, it picks up the new plan using the indexes and immediately gets faster.
But in either case, full tablescan being slow after a few thousands of rows or using the index and getting much faster. Or me just doing the same select and no inserts on a table with 100000 rows, the CPU seems to be pegged to the core.
The code snipped repeated again
DECLARE
   uname    NVARCHAR2 (60);
   primid   NVARCHAR2 (60);
   num      NUMBER;
BEGIN
   FOR i IN 1 .. 100000
   LOOP
      uname := DBMS_RANDOM.STRING ('x', 20);
      primid := DBMS_RANDOM.STRING ('x', 30);
      DBMS_OUTPUT.put_line (uname || ' ==> ' || primid);
      SELECT   COUNT (*)
          INTO num
          FROM TEST
         WHERE ID = 0
           AND (primid = primid OR UPPER (username) = uname OR uiname = uname
           AND (deldate IS NULL)   
      ORDER BY TIME DESC;
      INSERT INTO TEST
           VALUES (0, uname, uname, 1, uname, primid);
      IF MOD (i, 200) = 0
      THEN
         COMMIT;
         DBMS_OUTPUT.put_line ('Commited');
      END IF;
   END LOOP;
END;This is the original thread
Re: Slow inserts

Answer 1

Maybe if you post the actual code, or a code as similar to the actual code, the users of this forum may provide you with more appropriate suggestions.
Personally, I would like to understand what is the logic behind, so I can provide you with better advices.
Anyway, let's focus on the code that we currently have on the table.
Why your CPU goes high?
- Huge amount of LIOs produced by SELECT statement which is executed 100000 times.
- Usage of single-row / aggregate functions
- You mentioned you have some indexes created on table TEST. Index maintenance consumes some CPU as well.
Let's focus on the SELECT statement, since it is the most important reason for having high number of LIOs thus having high CPU usage.
I built a test case using the query you provided, with one difference, I named TEST table columns as COL1, COL2, etc. And instead of 100,000 cycles, I did 10,000
declare
   uname varchar2(60);
   pname varchar2(60);
   num number(5);
   begin
   for i in 1..10000 loop
      uname:=dbms_random.string('x',30);
      pname:=dbms_random.string('x',20);
      select count(1)
      into num
      from test
      where col1=0
      and (col2=uname or upper(col5)=pname or col3=uname)
      and col4 is not null;
      insert into test
      values (0,uname,pname,1,uname,uname);
      if mod(i,200)=0 then
              commit;
      end if;
   end loop;
  end;When I run 10046 trace and made tkprof report, I got the following for the SELECT part:
SELECT COUNT(1)
FROM
TEST WHERE COL1=0 AND (COL2=:B1 OR UPPER(COL5)=:B2 OR COL3=:B1 ) AND COL4 IS
  NOT NULL
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute  10050      0.48       0.43          0          0         50           0
Fetch    10000     94.07      94.37          0    2910664          2       10000
total    20052     94.56      94.80          0    2910664         52       10000As you can see, tkprof report indicated high CPU usage and 2,910,664 LIO calls.
The execution plan (I didn't include that part) indicated FULL TABLE scan on table TEST was used.
At this point the goal should be to reduce the number of LIO calls.
For this purpose I created the following indexes:
TEST_IDX1 on TEST(col2)
TEST_IDX2 on TEST(col3)
TEST_IDX3 on TEST(upper(col5)) - a Function Based Index
Let's forget about the statistics at this moment.
I will use index_combine hint in the SELECT statement to make CBO to try every index combination for listed indexes (B-Tree) and make bitmap conversion.
The new code looks like this
declare
   uname varchar2(60);
   pname varchar2(60);
   num number(5);
   begin
   for i in 1..10000 loop
      uname:=dbms_random.string('x',30);
      pname:=dbms_random.string('x',20);
      select /*+ index_combine(test test_idx1 test_idx2 test_idx3) */ count(1)
      into num
      from test
      where col1=0
      and (col2=uname or upper(col5)=pname or col3=uname)
      and col4 is not null;
      insert into test
      values (0,uname,pname,1,uname,uname);
      if mod(i,200)=0 then
              commit;
      end if;
   end loop;
  end;After running 10046 trace and creating tkprof report, I got the following result:
SELECT /*+ index_combine(test test_idx1 test_idx2 test_idx3) */ COUNT(1)
FROM
TEST WHERE COL1=0 AND (COL2=:B1 OR UPPER(COL5)=:B2 OR COL3=:B1 ) AND COL4 IS
  NOT NULL
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute  10000      0.79       0.70          0          0          0           0
Fetch    10000      0.68       0.71          3      59884          0       10000
total    20001      1.47       1.42          3      59884          0       10000
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 54     (recursive depth: 1)
Rows     Row Source Operation
  10000  SORT AGGREGATE (cr=59884 pr=3 pw=0 time=1188641 us)
      0   TABLE ACCESS BY INDEX ROWID TEST (cr=59884 pr=3 pw=0 time=1012723 us)
      0    BITMAP CONVERSION TO ROWIDS (cr=59884 pr=3 pw=0 time=915796 us)
      0     BITMAP OR  (cr=59884 pr=3 pw=0 time=820728 us)
      0      BITMAP CONVERSION FROM ROWIDS (cr=20039 pr=1 pw=0 time=258455 us)
      0       INDEX RANGE SCAN TEST_IDX1 (cr=20039 pr=1 pw=0 time=157107 us)(object id 52988)
      0      BITMAP CONVERSION FROM ROWIDS (cr=19902 pr=1 pw=0 time=198466 us)
      0       INDEX RANGE SCAN TEST_IDX2 (cr=19902 pr=1 pw=0 time=109999 us)(object id 52989)
      0      BITMAP CONVERSION FROM ROWIDS (cr=19943 pr=1 pw=0 time=198730 us)
      0       INDEX RANGE SCAN TEST_IDX3 (cr=19943 pr=1 pw=0 time=107200 us)(object id 52990)As you can see the number of LIO calls fallen dramatically. Also CPU time is significantly less.
The second code completed in few seconds compared to the previous one which needed about 100 seconds to complete.
Please be aware that this is just an example of tuning the code that you provided.
This solution might not be suitable for your actual code, since we don't have any information about it. That's why it is important to give us as much information as you could, so you can get the most appropriate answer.
If the test code is similar to the actual one, you should focus on reducing LIOs calls.
In order to achieve it, you may want to use hints to force an index to be used.
Cheers,
Mihajlo