Буферный кэш базы данных содержит копии блоков Oracle из файлов дан­ных. Эти блоки могут быть одного из следующих типов: данные, индексы, вре­менные данные, сегменты отката или загрузочные/котированные сегменты. На самом деле буферный кэш базы данных часто содержит несколько версий

наиболее активно используемых блоков из файлов данных. Эти версии блоков

данных создаются для различных транзакций, требующих согласованных по

чтению изображений данных.

Oracle реализует 

многоверсиоппую совместимость по чтению, 

применяя 

изобра­жения до 

внесения изменений (далее "изображения до") из сегментов отката

(когда допустимо) для обеспечения согласованного чтения между транзакция­ми. Базовая концепция гласит, что выбранные и посылаемые пользователю строки - это обязательно зафиксированные (committed) данные. Исключением из правила можно считать случай, если пользователь сам является инициато­ром транзакции, и желает сделать запрос о произведенных изменениях еще до момента принятия решения о том, будут ли данные зафиксированы или откаче­ны. По умолчанию в Oracle никогда нельзя сделать то, что называется 

грязным 

(прочесть данные, в которые кто-то другой внес изменения, но они еще

не зафиксированы). Эта концепция обсуждается самым подробным образом в главе "Настройка подключения".

Размер буферного кэша базы данных определяется параметром инициализа­ции DB_BLOCK_BUFFERS. Количество памяти, используемое этой структурой памяти, является функцией от DB_BLOCK_SIZE, умноженного на DB_BLOCK_ BUFFERS. Если в кэше 10 тысяч блоков по 8 Кбайт каждый, размер выделяемой памяти составляет 81920000 байт или около 78 Мбайт.

Параметр LOGJBUFFER устанавливает количество памяти, используемой

для хранения информации об обновлениях, или журнала изменений базы дан-
ных. Задание правильного размера этой структуры памяти является критичным
для систем, в которых происходит множество DML.        они являются

сердцевиной механизма восстановления Oracle, очень важно задать им прави­льный размер, не слишком при этом переусердствовав (см. главу "Настройка эк­земпляра - настройка буферов журнала обновлений и прочая настройка").

С возникновением Oracle 7.3 появилась и лучшая поддержка управления во-
просами, поставленными большими хранимыми SQL и PL/SQL (пакетами, про-
цедурами и функциями). Это разделение        запоздало, так как
маленькие операторы SQL и большие операторы SQL (или хранимые SQL) час-
то интерферируют друг с другом при их хранении в одной и той же области, та-
ким образом, вызывая старение SQL и фрагментацию коллективного пула.
Поэтому был введен параметр SHARED_POOL_RESERVED_SIZE, единственной
целью которого является разнесение малых и больших SQL по разным облас­тям для того, чтобы они не могли интерферировать друг с другом.

С появлением Огас1е8 был введен в обиход и новый пул памяти (не входящий в состав области коллективного пула). Добавление большого пула объясняется необходимостью предоставления места параллельным операциям для исполь­зования в конфигурациях с MTS и в RMAN. Эта область конфигурируется при установке параметра

Появился в Oracle8i. Конфигурируется параметром JAVA POOL SIZE и ис­пользуется программами на Java точно так же, как область коллективного пула применяется операторами SQL. Заметьте, что для инсталляции компонента Java необходимо, чтобы этот пул был обязательно сконфигурирован, но рекоменда­ции Oracle кажутся нам слишком узкими. Нужно, чтобы размер пула, устанавли­ваемого с помощью указанного выше параметра, был около 100 Мбайт. Только в этом случае компонент будет установлен удачно.

Вплоть до версии       в отчете команды show sga или

в представлении V$SGASTAT размер памяти, выделенной пулу Java, указывался неверно.