Showing posts with label buffer cache. Show all posts
Showing posts with label buffer cache. Show all posts

Wednesday, May 30, 2012

Alter System Flush Shared_Pool and Alter System Flush Buffer_Cache

This example shows the effect of the alter system flush shared_pool and alter system flush buffer_cache commands. It was tested on Oracle 11.2. First create a table with some rows to count:
 
SQL> create table tab1
  2  as select * from dba_tables
  3  /
 
Table created.
 
SQL> begin
  2  for a in 1..5
  3  loop
  4  insert into tab1 select * from tab1;
  5  end loop;
  6  end;
  7  /
 
PL/SQL procedure successfully completed.
 
SQL>
 
The shared pool contains the library cache. This stores the parsing details and execution plans for SQL statements which have been run. You can remove these details by flushing the shared pool:
 
SQL> alter system flush shared_pool
  2  /
 
System altered.
 
SQL>
 
The buffer cache contains blocks which have been read from disk. You can flush the buffer cache as follows:
 
SQL> alter system flush buffer_cache
  2  /
 
System altered.
 
SQL>
 
Now you can get a baseline time (1.94 seconds) for parsing the SQL, creating an execution plan, getting the database blocks from disk and counting the rows:
 
SQL> set timing on
SQL> select count(*) from tab1
  2  /
 
  COUNT(*)
----------
     97920
 
Elapsed: 00:00:01.94
SQL>
 
Count the rows again. This time the SQL is already in the library cache so it does not need to be reparsed. The database blocks are still in the buffer cache from the previous SQL statement so there is no need to get them from disk either. As a result, this statement is much quicker (0.04 seconds):
 
SQL> select count(*) from tab1
  2  /
 
  COUNT(*)
----------
     97920
 
Elapsed: 00:00:00.04
SQL> set timing off
SQL>
 
Now flush the shared pool to remove the SQL from the library cache:
 
SQL> alter system flush shared_pool
  2  /
 
System altered.
 
SQL>
 
Run the SQL again. Having to reparse the SQL and recreate the execution plan adds a fraction of a second to the elapsed time:
 
SQL> set timing on
SQL> select count(*) from tab1
  2  /
 
  COUNT(*)
----------
     97920
 
Elapsed: 00:00:00.07
SQL> set timing off
SQL>
 
Flush the buffer cache to remove the database blocks:
 
SQL> alter system flush buffer_cache
  2  /
 
System altered.
 
SQL>
 
Count the rows in the table as before. Having to fetch the database blocks from disk again adds over a second to the elapsed time:
 
SQL> set timing on
SQL> select count(*) from tab1
  2  /
 
  COUNT(*)
----------
     97920
 
Elapsed: 00:00:01.49
SQL> set timing off
SQL>
 
Finally, flush both the shared pool AND the buffer cache:
 
SQL> alter system flush shared_pool
  2  /
 
System altered.
 
SQL> alter system flush buffer_cache
  2  /
 
System altered.
 
SQL>
 
Count the rows in the table for the last time. This involves reparsing the SQL, recreating the execution plan and fetching the database blocks. This time the elapsed time is roughly the same as the baseline time at the start:
 
SQL> set timing on
SQL> select count(*) from tab1
  2  /
 
  COUNT(*)
----------
     97920
 
Elapsed: 00:00:01.85
SQL> set timing off
SQL>

Saturday, December 03, 2011

Oracle Database 11g Release 2 Upgrade Seminar

I went to an Oracle seminar at CPC Venues in London recently. It explained how and why you should move to Oracle 11g release 2. The speakers were Mike Appleyard, John Nangle and Peter Alsop. It was extremely well done and, if you get the chance, you should go on it.

When I returned to work, I asked for a copy of the slides from the presentation and they sent me a link to download them a few hours later.

I decided to try out a new feature, which allows you to use solid state disk storage to extend your database's buffer cache. I then found a test database running on 11g release 2. Unfortunately I did not have a solid state disk to hand so I had to make do with an ordinary one.

To use this feature, you need to add two new parameters to your init.ora file. This is the first one:

db_flash_cache_file='/export/home/oracle/andrew/ssd'

It gives the name of a file on a solid state disk, which will be used as the buffer cache extension. Oracle creates it if it does not exist.

The second parameter gives the size of the file:

db_flash_cache_size=10m

Then I bounced the database:

11gR2 > sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Dec 2 18:24:58 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> startup force
ORA-01078: failure in processing system parameters
ORA-12427: invalid input value for db_flash_cache_size parameter

SQL>

This failure did not come as much of a surprise as the notes from the presentation suggested a size of 120 gigabytes! I tried again with a size of 100m and the database opened OK.

This is the file which Oracle created:
 
11gR2 > pwd
/export/home/oracle/andrew
11gR2 > ls -l ssd
-rw-r-----   1 oracle   dba      104857600 Dec  2 18:08 ssd
11gR2 >

That's as far as I can go with this new feature for now. Once I have a solid state disk, I will try it out properly and report my findings.

In the meantime, I will read through the slides from the presentation, try out some other new features and let you know how I get on.