Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

Free Oracle Tips

HTML Text

 Home
 E-mail Us
 Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB   


 

 

 


 

 


                    The Best Oracle Resource on the Web

Note: Burleson Oracle Consulting is the leader in Oracle Emergency Support and is available to assist with any Oracle database problem, anywhere in the world, anytime.

 

Implement the KEEP Pool for Small-table, Full-scanned Tables

I worked on a database just last month in New Zealand (running 9.2.0.4) that had a 16 CPU Solaris server with 8GB of RAM. The complaint was that performance had been degrading since the last production change. A STATSPACK top five timed events report showed that over 80 percent of system waits related to “db file scattered reads.” A quick review of v$sql_plan using plan9i.sql showed lots of small-table, full-table scans, with many of the table not assigned to the KEEP pool (as denoted by the “K” column in the listing below):

                  Full table scans and counts
                                         
OWNER      NAME                     NUM_ROWS C K   BLOCKS  NBR_FTS
---------- -------------------- ------------ - - -------- --------
APPLSYS    FND_CONC_RELEASE_DISJS         39 N         44   98,864
APPLSYS    FND_CONC_RELEASE_PERIODS       39 N K       21   78,232
APPLSYS    FND_CONC_RELEASE_STATES         1 N K        2   66,864
APPLSYS    FND_CONC_PP_ACTIONS         7,021 N      1,262   52,036
APPLSYS    FND_CONC_REL_CONJ_MEMBER        0 N K      322   50,174
APPLSYS    FND_FILE_TEMP                   0 N        544   48,611
APPLSYS    FND_RUN_REQUESTS               99 N         98   48,606
INV        MTL_PARAMETERS                  6 N K       16   21,478
APPLSYS    FND_PRODUCT_GROUPS              1 N         23   12,555
APPLSYS    FND_CONCURRENT_QUEUES_TL       13 N K       10   12,257
AP         AP_SYSTEM_PARAMETERS_ALL        1 N K        6    4,521 

As you may know, rows fetched into the db_cache_size from full-table scans are not pinged to the Most-Recently-Used (MRU) end of the data buffer. Running my buf_blocks.sql script confirmed that the FTS blocks were falling off the least-recently-used end of the buffer, and had to be frequently reloaded into the buffer.

                           Contents of Data Buffers
                                             Number of Percentage             
                                             Blocks in of object
              Object           Object        Buffer    Buffer  Buffer    Block
Owner        Name              Type          Cache     Blocks  Pool       Size
------------ -------------------------- ----------- ---------- ------- -------
DW01         WORKORDER         TAB PART      94,856          6 DEFAULT   8,192
DW01         HOUSE             TAB PART      50,674          7 DEFAULT  16,384
ODSA         WORKORDER         TABLE         28,481          2 DEFAULT  16,384
DW01         SUBSCRIBER        TAB PART      23,237          3 DEFAULT   4,096
ODS          WORKORDER         TABLE         19,926          1 DEFAULT   8,192
DW01         WRKR_ACCT_IDX     INDEX          8,525          5 DEFAULT  16,384
DW01         SUSC_SVCC_IDX     INDEX          8,453         38 KEEP     32,768

In this case, I ran my buf_keep_pool.sql script to reassign all tables that experienced small-table, full-table scans into the KEEP pool. The output looks like this, and can be fed directly into SQL*Plus:

alter TABLE BOM.BOM_OPERATIONAL_ROUTINGS storage (buffer_pool keep);
alter INDEX BOM.CST_ITEM_COSTS_U1 storage (buffer_pool keep);
alter TABLE INV.MTL_ITEM_CATEGORIES storage (buffer_pool keep);
alter TABLE INV.MTL_ONHAND_QUANTITIES storage (buffer_pool keep);
alter TABLE INV.MTL_SUPPLY_DEMAND_TEMP storage (buffer_pool keep);
alter TABLE PO.PO_REQUISITION_LINES_ALL storage (buffer_pool keep);
alter TABLE AR.RA_CUSTOMER_TRX_ALL storage (buffer_pool keep);
alter TABLE AR.RA_CUSTOMER_TRX_LINES_ALL storage (buffer_pool keep);
alter INDEX WIP.WIP_REQUIREMENT_OPERATIONS_N3 storage (buffer_pool keep);

With more efficient buffer caching, I fixed the problem in less than one hour and overall database performance more than doubled.


If you like Oracle tuning, you might enjoy my latest book “Oracle Tuning: The Definitive Reference” by Rampant TechPress. It’s only $41.95(I don’t think it is right to charge a fortune for books!) and you can buy it right now at this link:

http://www.rampant-books.com/book_ 2005_1_awr_proactive_tuning.htm


 

 

 

  
 

 
 
 
 
Oracle performance tuning software
 
 

 

 
 
 
Oracle performance Tuning 10g reference poster
 
 
 
Oracle training in Linux commands
 
Oracle training Excel
 
Oracle training & performance tuning books
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2011 by Burleson Enterprises

All rights reserved.

Oracle © is the registered trademark of Oracle Corporation.