3. Архітектура віртуальної фс. Блокування доступу до файлу.

Буферна кеш. Внутрішня структура буферного кешу.

буферний кеш

• Це складова частина SGA

• Використовується для швидкого доступу до даних

• Використовує LRU алгоритм, для того щоб позбавлятися непопулярних даних

• Містить внутрішні структури: Default buffer pool, Keep buffer pool і Recycle buffer pool

• Параметром DB_CACHE_SIZE встановлюється розмір

Це найбільша складова області SGA. Оскільки буферний кеш належить SGA, то буфера доступним всім користувачам. У буферному кеші сервер Oracle зберігають блоки бази даних після зчитування з диска. Буферний кеш містить тільки буфера, але не керуючі структури. Для кожного буфера є відповідний буферний заголовок у змінній області SGA. Аналогічно, working set headers, the hash chain headers та їх засувки також знаходяться у змінній області SGA. Очевидно, що оперувати даними, що знаходяться в пам'яті, значно швидше, ніж з даними знаходяться на диску. Тому головне завдання буферного кешу - мінімізація фізичного введення - виведення. Оракл виходить з того, що якщо блок даних прочитаний, то він, швидше за все, може знадобитися знову. Звичайно, ідеальним варіантом у цьому контексті може бути розмір буферного кешу на стільки великий, що в ньому містяться всі блоки даних, з якими належить працювати протягом дня. Але так ніколи не буває. Тому в результаті роботи екземпляра в буферному кеші зберігаються найбільш затребувані блоки даних. І як наслідок, при обробці даних можливі два варіанти розвитку подій:

• Якщо необхідні дані знаходяться в кеші, то Оракл обробляє їх, не звертаючись до файлів даних (cache hit) - «потрапляння»

• Якщо необхідні дані не знаходяться в кеші, Оракл змушений читати блоки з файлів даних (cache miss) - «промах»

Для підвищення продуктивності серверний процес іноді читає кілька блоків за одну операцію читання. З цією ж метою процес DBWn записує кілька блоків за одну операцію запису.

Буферний кеш складається з буферів, які можуть перебувати в наступних станах:

• Clean (чисті) буфера - означає, що буфер в даний час не закріплений (unpinned) і є кандидатом на видалення з кешу, якщо на його вміст не буде знову посилань. Вміст буфера або синхронізовано з блоком на диску, або буфер використовувався для генерації та обробки старого моментального знімка блоку в режимі цілісного читання (Consistent read - CR блок)

• pinned буфера («закріплені») - означає, що кілька сеансів не можуть в один і той же момент часу писати в один блок і змушені чекати доступу до блоку

• free / unused (вільне / закинутий) - означає, що буфер порожній, тому що примірник щойно був запущений. Стан дуже схоже на Clean, за виключення того, що буфер ще не використовувався.

• Dirty («брудний») - буфер більше не є закріпленим, але його вміст було змінено і має бути записано на диск процесом DBWR перед видаленням з кешу.

У довільний момент часу кеш буферів може містити кілька копій одного і того ж блоку бази даних. Тільки одна з них є поточної, решта конструюються на основі сегментів скасування (construct read-consistent copies from past image information-CR block. Вони забезпечують цілісні читання даних.

Спрощено можна стверджувати, що для управління буферним кешем Оракл використовує два списки:

• Список брудних буферів (Dirty List, Write List, LRUw, checkpoint queue)

• Список чистих буферів (LRU)

Список «брудних» буферів (checkpoint queue) містить перелік покажчиків на модифіковані (командами insert, update, delete) буфера, які необхідно записати на диск у файл даних. Запис проводиться фоновим процесом DBWR.

Список «чистих» буферів використовується для того, щоб утримати в пам'яті як можна довше популярні блоки даних для мінімізації витрат на операції введення-виведення. Більш детально можна прочитати в пості «Трохи про LRU списку».

Під час пошуку вільного буфера для збереження прочитаного блоку користувальницький серверний процес використовує обидва списку: LRU List і Dirty List:

• Поки сканується LRU List в пошуку вільних буферів, серверний процес переміщує dirty блоки, які попалися на шляху пошуку за LRU в Dirty список.

• При кожному додаванні брудний список зростає. Коли його розміри перевищать встановлений поріг, процес DBWR починає запис модифікованих буферів на диск.

• Але DBWR може почати запис модифікованих буферів, не чекаючи перевищення цього порога. Це стає можливим, якщо серверний процес переглянув занадто багато буферів і не знайшов вільного. У цьому випадку брудні буфера пишуться безпосередньо з LRU списку на диск (без попереднього перенесення в Dirty список).

Буферний кеш у версіях до Oracle 8.0 представляв собою один великий кеш. Всі блоки кешована однаково. У Oracle 8.0 додана можливість створення буферних пулів.

Типово завжди створюється DEFAULT BUFFER POOL (параметр db_cache_size). Містить всі дані, які спеціально не закріплені в інших пулах.

KEEP BUFFER POOL (параметр db_keep_cache_size) - пул для найбільш затребуваних блоків. Використовується для розміщення цілком невеликих таблиць, які часто використовуються (наприклад, довідники). Специфіка пулу - дані постійно в ньому знаходяться, а не викидаються з часом з нього як застарілі. Вірніше бій за право залишитися в цьому пулі відбувається тільки між таблицями, закріпленими саме за цим пулом, а не з усіма даними. Буфера управляються в пулі також як і в DEFAULT BUFFER POOL (own LRU list and checkpoint queue). Що б отримати ефект від використання цього пулу - встановіть правильний розмір.

RECYCLE BUFFER POOL (параметр db_recycle_cache_size) - блоки, поміщені в цей пул, відразу ж після використання видаляються з нього (після завершення транзакції). Ефективно для роботи з великими таблицями, якщо ймовірність повторного використання блоку незначна. Немає сенсу утримувати таку інформацію в пуле.Буфера управляються в пулі також як і в DEFAULT BUFFER POOL (own LRU list and checkpoint queue

Щоб блоки Вашої таблиці потрапили в пул KEEP або RECYCLE потрібно явно призначити пул для цієї таблиці. Інакше, за замовчуванням вона потрапить у DEFAULT.

alter table my_table1 storage (BUFFER_POOL KEEP);

alter table my_table2 storage (BUFFER_POOL RECYCLE);

Так як всі пули (default, recycle, keep) управляються однаково, то розміром холодної та гарячої частини LRU-списків так само керують аналогічні параметри:

• _db_percent_hot_default

• _db_percent_hot_keep

• _db_percent_hot_recycle

У Oracle 10g з'явилися параметри:

• DB_2K_CACHE_SIZE

• DB_4K_CACHE_SIZE

• DB_8K_CACHE_SIZE

• DB_16K_CACHE_SIZE

• DB_32K_CACHE_SIZE

Ці параметри (db_nn_cache_size) використовуються для створення окремих пулів буферів даних, які використовуються для розділення (segregate) даних і ізолювання (isolate) об'єктів з різними характеристиками введення / виведення. Таким чином, для роботи з блоками іншого розміру, ніж встановленого параметром DB_BLOCK_SIZE, можна створювати відповідні пули.

Параметр DB_BLOCK_SIZE завжди використовується для створення файлів даних SYSTEM, SYSAUX і temporary табличних просторів. Це змінити ніколи не можна.

Параметри db_nn_cache_size не можуть використовуватися для завдання розміру кешу з буферами, рівними стандартному розміру блоку. Якщо значення DB_BLOCK_SIZE одно nK, тоді не можна задати параметр db_nК_cache_size. Розмір кешу з буферами стандартного розміру завжди визначається параметром DB_BLOCK_SIZE.

Пули keep і recycle можуть працювати тільки з блоками, розмір яких в екземплярі встановлений за замовчуванням.

«Нетрадиційні» блоки містяться в спеціально створених табличних просторах. Наприклад:

CREATE TABLESPACE TEST_DATA_16K LOGGING DATAFILE 'C: \ ORACLE \ ORADATA \ SAM \ TEST_DATA_16K.ORA' SIZE 100M BLOCKSIZE 16384 EXTENT MANAGEMENT LOCAL

Про розмір блоку в існуючих табличних просторів можна дізнатися з вибірки:

SELECT TABLESPACE_NAME, BLOCK_SIZE FROM DBA_TABLESPACES;

Ще кілька корисних запитів:

SELECT TABLE_NAME, CACHE, BUFFER_POOL FROM USER_TABLES ORDER BY TABLE_NAME;

select name, value, isdefault, ismodified from v $ parameter where name = 'db_cache_advice' or name = 'db_cache_size';

На останок хотілося б сказати, що не так все просто з буферним кешем, як тут все описано. Існує в Оракл таке поняття як WORKING SETS (WS). Буфера в буферному кеші розподілені по цих WORKING SETS, тобто WS - це підмножина буферів у буферному кеші. Кожен WS пов'язаний з одним процесом DBWn, захищений своєї cache buffers lru chain клямкою, має свої списки LRU і checkpoint queue. Опис WS можна знайти в таблиці X $ KCBWDS. Кількість WS залежить від кількості процесорів (CPU) у системі та кількості сконфигурированних фонових процесів DBWR.В свою чергу пули складаються з набору WS. Про це - у таблиці X $ KCBWBPD. Ясно, що все це організовано для підвищення проізводітельності.Для чого ж ще? Паралельна робота на різних процесорах проходить без конкурентної боротьби завдяки тому, що кожен використовує свій WS.