Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Keeping a Table in Memory Administration TipsHow do I keep a table in memory?The short answer is: you cant.Packages and procedures can be kept in the Library Cache of the shared pool: executedbms_shared_pool.keep(name_of_package) will guarantee that the named package orprocedure will never age out of the Library Cache.But table data is stored in the Buffer Cache, not the Library Cache, and there is noequivalent to the keep procedure to keep it there.Nor, frankly, is there much need to. The Buffer Cache is managed by the "Least RecentlyUsed" list. Blocks which are frequently used (i.e., are useful to many Users) will be at theMost Recently Used (MRU) end of the LRU list. Deeply unpopular blocks which are seldomused will be at the Least Recently Used (LRU) end of the list. When Oracle has to choosewhich blocks to age out of the Buffer Cache to make room for new arrivals, it chooses theones at the LRU end of the LRU list. So, if your table is worth keeping in memory, becauseit is hugely important to your application and is therefore constantly accessed, it will tendto stay in memory automatically, because its blocks will always be at the MRU end of theLRU list. Forcing an unpopular table to be "kept" in the buffer cache would simply be awaste of buffers.That said, it is possible for a popular table to be washed out of the Buffer Cache becausesome looney decides to do a select * from enormous_table -we need to find room for abazillion new blocks of data, there arent enough free buffers, so we just flush the entireLRU list (MRU end and all) to make as much room as we can. Bye-bye useful table blocks.Can that be stopped? Sort of... but Oracle even has a mechanism for trying to avoid thisproblem too. Usually, when Oracle reads a block of data off disk, it (naturally enough)places it onto the MRU end of the LRU list (its the most recently touched block, after all).But any full table scans you do have the blocks they touch placed around half-way downthe LRU list. Thats designed to prevent any select * queries from flushing out the entireLRU list, but cant guarantee that a particularly large full tablescan wont nevertheless beforced to flush the entire list.Introduced in Oracle 8.0, however, was the concept of dividing your Buffer Cache intoseparate Buffer Pools. There are three possible: the DEFAULT pool (which behaves exactlyas an undivided Buffer Cache would), the RECYCLE pool (which is designed to flush blocksout of the Cache as quickly as possible) and the KEEP pool (which is designed to allowblocks to hang around in memory for as long as possible). You must always have aDEFAULT pool, but whether you have both a RECYCLE and a KEEP is up to you: either orboth is acceptable.Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 3
  2. 2. Keeping a Table in Memory Administration TipsThe first thing to say about this, however, is that the KEEP pool provides no guarantees: ifa large full tablescan inadvertently goes through the KEEP pool, it will still flush the entirepool of its more useful buffers.To set up the multiple pools in Oracle 8.0 or Oracle 8.1, you configure a few init.oraparameters (all aspects of Buffer Cache management have changed significantly in Oracle9i).DB_BLOCK_LRU_LATCHES sets up the total number of latches available to manage theBuffer Cache (each pool needs its own set of latches)DB_BLOCK_BUFFERS sets up the total number of buffers. Without further qualification,they all belong to the DEFAULT pool.BUFFER_POOL_KEEP sets up the number of buffers to be allocated to the KEEP pool,taking those buffers out of the total previously set by DB_BLOCK_BUFFERS. It alsospecifies how many of the total available latches should be used to manage this pool.BUFFER_POOL_RECYCLE does the same for the RECYCLE pool. Again, the number ofbuffers specified here comes from the total pool of buffers allocated byDB_BLOCK_BUFFERS, and it also specifies a number of latches to manage the pool.You might, for example, set up four init.ora lines like this:DB_BLOCK_LRU_LATCHES=6DB_BLOCK_BUFFERS=20000BUFFER_POOL_KEEP=(BUFFERS:12000, LRU_LATCHES:3)BUFFER_POOL_RECYCLE=(BUFFERS:2000, LRU_LATCHES:1)...and that will mean there are 20,000 buffers in total, of which 12,000 are assigned to theKEEP pool,managed by 3 latches; 2,000 are allocated to the RECYCLE pool, managed by asingle latch; and (by implication) 6,000 buffers are left for the DEFAULT pool, managed by2 latches. (Note that the syntax changed between 8.0 and 8i -the above example worksfor 8i only. In Oracle 8.0, you the syntax was simply "buffer_pool_keep=12000" and so on -with no mention of the latches).Note that a latch must manage at least 50 buffers, so you couldnt have a line reading, forexample: BUFFER_POOL_KEEP=(buffers:100, lru_latches 3) -because that would require atleast 150 buffers.Having set up a number of different buffer pools, you have then to tell Oracle to whichpool blocks from a particular table should be sent. If you miss out this step, then a tablesblocks will always be sent to the DEFAULT pool by, er... default.You can do this at table (or index) creation time. For example:Copyright © Howard Rogers 2001 10/17/2001 Page 2 of 3
  3. 3. Keeping a Table in Memory Administration TipsCREATE TABLE ALBUM(PHOTOID NUMBER,PHOTODESC CHAR(15))STORAGE (BUFFER_POOL RECYCLE)TABLESPACE DATA4;Blocks from this table will now always be loaded into the RECYCLE pool (and if,incidentally, you havent actually defined such a pool, its blocks will be loaded into theDEFAULT pool instead).You can also change a table (or index) to use a particular pool after its already beencreated:ALTER TABLE MUSIC STORAGE (BUFFER_POOL KEEP);ALTER INDEX MUSIC_PK STORAGE (BUFFER_POOL KEEP);What tables and indexes should be directed to the RECYCLE pool? Basically, large onesthat are subject to lots of random reads (the random reads is important: it means that theblocks Frank reads are unlikely to be needed by Scott when he does some reads later). Atable which is around twice the size of the entire DEFAULT pool subject to random reads isa prime candidate -using our parameters above, and assuming an 8K block size, that wouldmean that any tables bigger than (2 x 6000 x 8)K would be a good candidate (by mycalculations, thats around 96M).How about the KEEP pool? What tables and indexes should go in there? Relatively smalltables that are frequently accessed in their entirety are good candidates here. Thestandard advice is that a frquently-used table which is smaller than around 10% of theDEFAULT pool is a prime candidate (again, using our earlier init.ora parameters, thatwould suggest tables smaller than around 5M would be KEEP material).By setting up multiple pools in the Buffer Cache in this way, and then making sure bigtables are directed to the RECYCLE pool whilst small ones go to the KEEP pool, you helpminimise the chances of a huge tablescan flushing out a small, useful table from the cache(since the scan will be flushing the RECYCLE pool like crazy, and not touching the stuff inthe KEEP pool at all). But you can never stop a huge table, accidentally assigned to theKEEP pool, from flushing all the small tables out.You might also check out the tip on "How useful is the CACHE clause?", since that isfrequently touted as a means of achieving the pinning of tables in memory. It isnt anysuch thing, of course.Copyright © Howard Rogers 2001 10/17/2001 Page 3 of 3