Re: Q: storig frequently used tables into memory?
Date: 1996/03/19
Message-ID: <4il39c$25r_at_inet-nntp-gw-1.us.oracle.com>#1/1
I didn't catch the question on this one, but if you are looking for ways to cache tables, it is available with 7.1 and above. The following is from the 7.1 doc addendum:
<quote>
Caching Tables
Previous releases of the Oracle Server allowed tables to be cached by specifying a value for the SMALL_TABLE_THRESHOLD initialization parameter. Tables whose sizes were smaller than the value of this parameter were treated differently than other tables when a full table scan was performed.
Instead of a full scan causing a database block to be placed on the least recently used end of the LRU list in the buffer cache (so it will be paged out more quickly), the block would be placed on the most recently used end of the LRU list. This causes the blocks of the table to stay in the buffer cache for a longer time, and subsequent accesses of the table are more likely to find the table in the buffer cache. You may want to cache small lookup tables or large static historical tables to avoid I/O on subsequent accesses of the table.
In release 7.1 of the Oracle Server, you can specify tables this caching behavior on a per-table basis with the CACHE clause of the CREATE TABLE, ALTER TABLE, CREATE CLUSTER, and ALTER CLUSTER commands. The SMALL_TABLE_THRESHOLD parameter is no longer supported. The syntax of the CREATE TABLE command is illustrated below.
CACHE Specifies that the blocks retrieved for this table are placed at the most
recently used end of the LRU list
in the buffer cache when a full table scan is performed. This option is useful
for small lookup tables.
NOCACHE Specifies that the blocks retrieved for this table are placed at the
least recently used end of the LRU
list in the buffer cache when a full table scan is performed. This is the
default behavior.
</quote>
Scott Lawrence <73774.424_at_CompuServe.COM> wrote:
>You cannot store tables in the SGA. Only packages and procedures
>can be "held" in the SGA. Also, don't forget that each proc you
>pin in the SGA leaves less room for others.
>Scott Lawrence
>VGS, Inc.
>73774.424_at_compuserve.com
Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government
opinions and statements are mine and do not necessarily reflect the opinions of Oracle Corporation. Received on Tue Mar 19 1996 - 00:00:00 CET