Файли журналу бази даних Архів - Oracle DBA Forum
Файли журналу бази даних
Файли журналу бази даних - це дискові ресурси, які зберігають внесені користувачами Oracle зміни даних.
1) Оперативні файли журналу бази даних це фізичні файли, що зберігають інформацію з буфера журналу бази даних SGA. 2) Зміни, внесені в блоки даних у базі даних, зберігаються як записи повторів буфері журналу бази даних SGA. 3) Після фіксації транзакції або заповнення буфера журналу бази даних записи повторів завантажуються в оперативні файли журналу бази даних. 4) Оперативні файли журналу бази даних можуть мати дзеркалізовані файли. Кожен набір файлів, що містить ті самі дані, називається групою журналу бази даних, дзеркалізовані файли називаються членами журналу бази даних. 5) Якщо база даних використовується в режимі ARCHIVELOG, дані в оперативних файлах журналу бази даних архівуються у файлах архівних файлів журналу бази даних, як тільки журнал заповнюється. Це можна зробити вручну чи за допомогою автоматичних процесів архівування. 6) Якщо база даних працює в режимі NOARCHIVELOG, то не потрібно хвилюватися про архівування оперативних файлів журналу бази даних.
Контрольна точка регулярна подія в базі даних, що дає процесу запису в базі даних сигнал завантажити змінені буфери у файли даних і обносити файли керуючих і заголовки за допомогою інформації контрольної точки. Частота контрольної точки є одним із факторів, що впливають на час, необхідний базі даних на відновлення після несподіваного збою.
Контрольні точки виникають принаймні при перемиканні журналів бази даних. Вони можуть також виникати, якщо за допомогою параметрів файлу init.ora встановлюються більш часті інтервали. Якщо інтервал контрольної точки CKPTперевищує розмір файлу журналу бази даних, контрольні точки виникають лише під час перемикання журналів бази даних.
Призначення та структура оперативних файлів журналу бази даних.
Oracle використовує файли журналу бази даних для відстеження змін даних, що здійснюються користувачами, наприклад зміни в блоках сегментів даних у таблицях або індексах. Кожен процес, що робить таку зміну, генерує запис повтору, що вказує на виконану зміну. Цей запис повтору поміщається в область SGA, яка називається буфером журналу бази даних. Процес LGWR записує ці зміни у файли на диску, які називаються оперативними файлами журналу бази даних. Oracle передбачає, що є мінімум два файли журналу бази даних. Кожен із файлів журналу бази даних називається групою журналу бази даних (redo log group). В цілях надійності Oracle також дозволяє створювати дзеркальне відображення кожного файлу журналу бази даних. Такі дзеркальні (mirrored) файли називаються членами групи (members of the group)
Що відбувається із вмістом першої групи?
Відповідь це питання залежить від режиму архівування, у якому працює база даних Oracle. База даних може працювати як ARCHIVELOG чи NORACHIVELOG. При роботі в режимі NOARCHIVELOG LGWR пише в кожну групу журналів, а потім циклічно повертається до першої групи і перезаписують її вміст. У разі збою цей тип режиму не може повернути базу даних у стан на момент збою. У режимі ARCHIVELOG процес архіватора (ARCn) копіює внесені до груп журналів записи повторів у різні місця розташування. Для прискорення процесу архівування можна активізувати більше одного архіватора. При роботі в цьому режимі, базу даних можна відновити намомент збою, застосувавши ці записи архівних файлів журналу бази даних до відновлених резервних копій.
У цей момент багатьох менш досвідчених в управлінні Oracle адміністраторів БД цікавить наступне: якщо Oracle дозволяє відновитися на момент збою, коли база даних працює в режимі ARCHIVELOG, чому тоді хтось запускає базу даних в режимі NOARCHIVELOG? Відповідь проста. База даних, що працює в режимі ARCHIVELOG Oracle повільніше бази даних, що працює в режимі NOACHIVELOG, хоча при оптимальному налаштуванні бази даних різниця в продуктивності мінімальна. Крім того, не кожній базі даних Oracle потрібно архівувати всі її повтори. Наприклад, база даних у режимі «тільки для читання», яка використовується для звернень до інформаційного сховища, не потребує роботи в режимі ARCHIVELOG, тому що користувачі не зможуть змінити вже завантажені дані.
Перемикання режимів архівування.
Для перемикання між цими двома режимами необхідно виконати такі кроки.
Управління перемиканням журналу бази даних та контрольними точками.
Журнал бази даних запивається послідовно. Оскільки користувачі Oracle вносять зміни, серверний процес генерує повтор для відновлення змін, зроблених у межах транзакції користувача. Повтор записується у буфер повторів. З нього LGWR записує зміни до оперативного файлу журналу бази даних. Розмір файлу журналу бази даних обмежений. Після заповнення LGWR повинен перейти до наступного. Перемикання журналів (log switch) відбувається у той час, коли LGWR повністю заповнить групу оперативних файлів журналу бази даних і переходить початку запису у наступній групі.
При кожному перемиканні журналів відбувається кілька подій. Oracle генеруєновий порядковий номер для оперативного файлу журналу бази даних, відновлює файл реєстрації, який збирається вносити записи LGWR. Oracle також виконує контрольну точку. Контрольна точка виникає при кожному перемиканні. Контрольні точки можуть виникати частіше, ніж перемикання журналів. Під час контрольної точки фоновий процес контрольної точки CKPT оновлює заголовки всіх файлів даних та керуючих файлів, щоб відобразилося успішне завершення, і дає команду DBWn на завантаження змінених буферів у файли даних. Число буферів, які пише DBWn, визначається параметром FAST_START_IO_TARGET (або FAST_START_MTTR_TARGET), якщо він вказаний. Частота, з якою виникають контрольні точки, впливає на час, необхідний для відновлення екземпляра Oracle. При збої примірника змінені, але не записані на диск, блоки слід відновити з журналу бази даних. Незважаючи на те, що відновлення екземпляра відбувається автоматично під керуванням SMON, необхідний час залежить від різниці в часі між контрольними точками.
Під час перемикання журналів відбуваються такі події. По-перше, LGWR припиняє запис до заповненого журналу бази даних. По-друге, CKPT дає DBWn вказівку завантажити змінені буфери у файли даних і, нарешті, CKPT оновлює керуючі файли та заголовки файлу даних за допомогою інформації контрольної точки. Після виконання завдань введення контрольних точок LGWR зможе розпочати запис до наступної групи журналу бази даних із новим порядковим номером.
Від адміністратора БД мало що залежить під час управління перемиканням журналів. Оскільки користувачі завжди змінять дані, адміністратор БД може зробити щось для запобігання запису інформації про повтор. Це означає, що можна керувати частотоюперемикання, змінюючи розмір членів оперативних файлів журналу бази даних, або вручну, примусово встановлюючи перемикання журналів за допомогою команди alter system switch logfile. Чим більше файл, тим рідше відбувається перемикання журналів, а чим менше файли члена, тим частіше це відбувається.
Контрольна точка виникає не тільки під час перемикання журналів, але й через конфігурацію, коли для CKPT задаються регулярні інтервали. Якщо налаштувати CKPT з рівномірними інтервалами, то контрольні точки виникатимуть рівномірно, як і перемикання журналів.
Визначення частоти контрольної точки.
Якщо журнали бази даних дуже великі, слід налаштувати базу даних так, щоб контрольні точки виникали частіше, ніж у момент перемикання журналів. Параметр LOG_CHECKPOINT_INTERVAL або LOG_CHECKPOINT_TIMEOUT у файлі init.ora дозволить встановити частіші контрольні точки. Ці два параметри відображають два різні принципи, на яких ґрунтується частота контрольної точки: інтервали за обсягом та інтервали за часом.
LOG_CHECKPOINT_INTERVAL встановлює інтервали контрольної точки на основі обсягу. Коли LGWR записує скільки інформації журнал бази даних, скільки зазначено в LOG_CHECKPOINT_INTERVAL, виникає контрольна точка. Періоди з великим обсягом транзакцій вимагають більш частого завантаження зміненого буфера; і навпаки, періоди з малим обсягом транзакцій вимагають меншого числа записів до журналу бази даних та меншої кількості контрольних точок. Ефект від використання LOG_CHECKPOINT_INTERVAL аналогічний використанню журналу бази даних меншого розміру, але крім цього усуває додаткові непродуктивні витрати від перемикання журналу бази даних, наприклад архівування журналу бази даних.
Колизадається LOG_CHECKPOINT_INTERVAL, задана для контрольно-точкової позиції не може відставати від кінця журналу бази даних більш ніж на число блоків журналу бази даних, зазначених цим параметром. Це гарантує, що під час відновлення екземпляра доведеться зчитувати лише задану кількість блоків повторів.
Інший спосіб визначення частоти контрольної точки полягає у використанні часового інтервалу. Він задається у параметр LOG_CHECKPOINT_TIMEOUT файлу init.ora. Конфігурувати інтервали контрольної точки на основі часу набагато простіше, ніж на основі обсягу, хоча в цьому випадку контрольні точки виникають через однакові інтервали незалежно від обсягу транзакцій у системі. Завдання LOG_CHECKPOINT_TIMEOUT встановлює позицію контрольної точки на те місце у файлі журналу, де кінець журналу бази даних був кілька секунд тому. Завдяки цьому під час відновлення потрібно вважати лише число блоків, що дорівнює вказаній кількості секунд. Однак для Oracle різниця полягає лише у формулюванні. Щоб вимкнути контрольні точки на основі часу, встановіть LOG_CHECKPOINT_TIMEOUT в нуль, а також не забудьте про новий параметр FAST_START_IO_TARGET. Цей параметр підвищує продуктивність відновлення екземпляра. Чим менше значення цього параметра, тим вища продуктивність при відновленні, тому що доводиться відновлювати менше блоків. Якщо цей параметр встановлений, DBWn завантажує змінені буфери енергійніше.
Єдина проблема, яка може виникнути при заданні рівномірного виникнення контрольних точок, у тому, що контрольна точка може виникнути якраз перед перемиканням журналів бази даних. Щоб уникнути перемикання, що призводить до прискорення виникнення контрольних точок, вкажіть середній час, необхіднийдля заповнення журналу бази даних, та встановіть інтервал часу, який розкладається на множники в контрольній точці, що виникає під час перемикання журналів бази даних. Для цього розглянемо трасувальний файл, згенерований LGWR у каталозі, заданому параметром BACKGROUND_DUMP_DEST.
І нарешті можна примусово розставити контрольні точки за допомогою примусового перемикання журналів або виклику контрольної точки. І те, й інше можна виконати за допомогою команди alter system. Для примусового перемикання журналів введіть команду alter system switch logfie. Для примусового виклику контрольної точки введіть команду alter system checkpoint. Контрольні точки, що виникають без відповідного перемикання журналів бази даних, називаються швидкими контрольними точками (fast_checkpoints), а контрольні точки з перемиканням повними (full) або завершеними контрольними точками (complete chtckpoints)
Мультиплексування та підтримка журналу бази даних
Є кілька важливих моментів, пов'язаних із конфігуруванням файлів журналу бази даних. Важлива деталь має значення мультиплексування журналу бази даних. Для підвищення здатності до відновлення у разі збою диска адміністратор БД повинен конфігурувати Oracle для мультиплексування чи зберігання кожного члена груп журналу бази даних різних дискових ресурсах. Це означає, що Oracle підтримуватиме два і більше членів для кожної групи журналу бази даних.
Мультиплексування членів журналу бази даних дозволяє зберігати множинні копії журналу бази даних, доступні LGWR. Якщо у LGWR виникає проблема з диском, на якому зберігаються журнал бази даних (наприклад, при збої контролера диска), весь екземпляр продовжує працювати, тому що на іншому диску доступнийінший член журналу бази даних. Якщо у групі журналу бази даних лише один член або якщо кілька членів оперативних файлів журналу бази даних не мультиплексовані, а відбувається той самий збій, LGWR не зможе внести записи і в роботі екземпляра Oracle виникає збій. Це відбувається помитим, що LGWR повинен переносити записи з журналу бази даних на диск, щоб очистити простір у буфері журналу бази даних і дозволити користувачам процесам продовжувати вносити зміни до бази даних. Якщо LGWR не може очищати місце в пам'яті перенесенням записів журналу бази даних на диск, ніякі подальші зміни користувача неможливі.