Re: VLM and putting an entire database in memory

If db_block_buffers x db_block_size is only 5M, then that must be a pretty small database if it is all in memory. Perhaps someone flipped some init.ora parameters recently.

If the database were all in memory, meaining every data and index block, the cache hit ratio would be something like 99.99...%

Increase the db_block_buffers until the cache hit ratio is between 95 and 99% as you mentioned. It is tempting to allocate hundreds of MBs to db_block_buffers if you have gigs of RAM. However, if the number of db_block_buffers greatly exceeds the number of blocks of data and index, scans of the buffer cache for required data or index blocks may take longer than retrieving them from disk, because of the amount of time spent scanning empty blocks in the buffer cache.

Allan

In article <91bah9$cbg$1_at_nnrp1.deja.com>,   dmnwork_at_my-deja.com wrote:
>
>
> With an Alpha GS140 and gigabytes of RAM, you can apparently use
> something called VLM to put an entire database into memory.
>
> However, when I'm looking at a database said to be configured this way
> (I didn't configure the hardware or the database - Oracle 8.0.5 on
> OpenVMS), I see the database buffer cache hit ratio hovering around
> 50%; a far cry from the 95-99% figure said to be desirable.
>
> The shared pool is around 30% utilizied and is about 150MB. No obvious
> problem there.
>
> But the database buffer cache is only set to be 5MB! (five). So now
 I'm
> confused. Might the hit ratio be grossly skewed if the "entire
> database" is "in memory"? Any reason why someone wouldn't increase the
> DB_BLOCK_BUFFERS if memory were plentiful? Also noted these values:
>
> db_block_size = 2048
> db_file_multiblock_read_count = 16
>
> Isn't 2048 bytes ridiculously low? Shouldn't it at least be doubled
 for
> a large production system (not that I can rebuild the entire database
> at the moment)? What about multiblock_read_counts? Any reason it
> shouldn't be doubled to 32?
>
> Thanks.
>
> - Dana
>
> Sent via Deja.com
> http://www.deja.com/
>

Sent via Deja.com
http://www.deja.com/ Received on Thu Dec 14 2000 - 16:32:34 CST