Управляющий файл Oracle.Сообщение в alert.log «kccrsz: expanded controlfile». ORA-00227. CONTROL_FILE_RECORD_KEEP_TIME

dbstalker, 21 июня

При очередном просмотре alert.log обнаружилось сообщение:

kccrsz: expanded controlfile section 11 from 755 to 839 records
  requested to grow by 83 record(s); added 6 block(s) of records

Что это такое, на сколько серьёзно такое сообщение? Пришлось собрать информацию из нескольких открытых источников. И вот что в итоге удалось накопать:

Управляющий файл

Очевидно, что проблемы возникли в управляющем файле, поэтому разбор полётов начнем с него. Управляющий файл (Control File) – очень важный файл базы данных, содержащий информацию необходимую для монтирования (перевода базы из состояния nomount в состояние mount) и проверки целостности базы данных. В этом файле размещена информация о том, где находятся файлы данных, файлы журнализации, как называется база данных. Во время работы базы управляющий файл претерпевает изменения в соответствии с событиями, происходящими в жизни базы данных.

Какова его структура? Первый блок контрольного файла – блок заголовка, содержащий информацию о размере и числе блоков в управляющем файле. Размер блока в управляющем файле такой же, как и у базы данных. При монтировании оракл проверяет информацию, записанную в заголовке со значением параметра db_block_size и размером файла, который выдает операционная система. Если информация не совпадает, получаем сообщение об ошибке в управляющем файле.

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

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

Заголовок управляющего файла имеет в своем составе следующие поля

Физический порядок полей заголовка:

  • блочный тип,
  • формат,
  • неиспользуемые 2 байта,
  • RDBA,
  • SCN,
  • последовательность,
  • флаг,
  • контрольная сумма,
  • неиспользуемые 2 байта.

Хвост блока состоит из младших двух байтов SCN и номера последовательности. Согласованность заголовка и хвоста проверяется всякий раз, когда читается блок. Ошибка ORA-00227 возвращается, если заголовок и хвост не соответствует, или если блочная контрольная сумма не соответствует контрольной сумме записанной в заголовке.

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

  • The database name
  • The timestamp of database creation
  • The names and locations of associated datafiles and online redo log files
  • Tablespace information
  • Datafile offline ranges
  • The log history
  • Archived log information
  • Backup set and backup piece information
  • Backup datafile and redo log information
  • Datafile copy information
  • The current log sequence number
  • Checkpoint information

Из представления V$CONTROLFILE_RECORD_SECTION можно почерпнуть следующую информацию об этих секциях:

  • Типы секций
  • Размер записи
  • Количество записей в каждой секции
  • Максимально допустимое число записей в секции

Создание управляющего файла

Управляющий файл создается во время первоначального создания базы данных CREATE DATABASE. В него вносится информация о файлах данных, архивных файлах, оперативных журнальных файлах. Поэтому параметры MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY, которые задаются при создании базы данных, определяют его размер и содержание. Значения этих параметров являются постоянными, изменить их можно только путем пересоздания управляющего файла

MAXLOGFILES - определяет максимальное число групп файлов журналирования операций, которые могут быть использованы в БД.

MAXLOGMEMBERS - определяет максимальное число членов группы файлов журналирования операций. Значение для вашей БД можно получить из запроса: select dimlm from x$kccdi.

MAXLOGHISTORY - этот параметр определяет максимальное количество архивных файлов журналирования, которое может быть записано в log history управляющего файла. Log history используется для автоматического восстановления системы. В управляющем файле сохраняется история только об MAXLOGHISTORY числе redo logs. Когда log history исчерпывает этот лимит, то oracle перезаписывает поверху старых записей. То есть, log history формируется циклически. Чем больше значение этого параметра, тем объемнее управляющие файлы. Имеет смысл только для Oracle with the Parallel Server option in parallel mode

MAXDATAFILES - определяет максимальное число файлов данных, которые могут быть добавлены к БД перед автоматическим расширением управляющего файла. Нужно задавать этот параметр с большим запасом и к тому же maxdatafiles >= db_files (параметр инициализации, задающий количество открытых файлов в SGA).

Пересоздание управляющего файла

Если эти параметры у работающей базы данных Вас не устраивают или возникли проблемы из-за их значения, то поменять их можно путем пересоздания управляющего файла (create controlfile):

  1. Выполнить команду Alter database backup controlfile to trace для получения скрипта на создание управляющего файла.
  2. В полученном файле трассировки откорректировать необходимые значения
  3. Остановить базу shutdown immediate
  4. Стартовать базу startup nomount
  5. Выполнить скрипт на создание управляющего файла, откорректированный в п.2
  6. Базу открыть alter database open

Redo Log History в управляющем файле

Журнал транзакций в оракле - это группа файлов операционной системы на сервере баз данных. БД должна иметь минимум две группы журналов. Группа состоит из одного или больше идентичных файлов операционной системы, содержащих журнальные данные зафиксированных транзакций. Журнальная группа, в которую в данный момент процесс LGWR делает запись, называется текущей группой. Каждая группа имеет постоянный размер и в результате работы БД наступает момент, когда текущая группа заполняется информацией.

Как только группа заполняется, оракл выполняет переключение. В процессе переключения, оракл закрывает текущую журнальную группу, открывает следующую и начинает писать журнальные данные в новую текущую группу. LGWR делает запись данных в log history контрольного файла во время журнального переключения, а не тогда, когда redo log архивируются. Во время переключения журналов, LGWR также объявляет контрольную точку. Когда выполняется контрольная точка, LGWR сообщает DBWR, что нужно записать все грязные блоки на диск. Если на протяжении дня журнальные переключения происходят очень часто, то могут возникнуть проблемы: если ваши журнальные группы маленькие, то LGWR тратит относительно много времени на переключение журналов, а также DBWR много времени тратит на запись грязных блоков на диск.

Просмотреть, как часто происходит журнальное переключение в вашей базе, можно используя запрос к представлению V$LOG_HISTORY. Здесь указано время переключения для каждого журнала из последних N журналов, где n –это значение параметра базы данных MAXLOGHISTORY.

Если экземпляр оракла подключается к базе данных в exclusive mode с доступным только одним потоком (thread), нет необходимости в log history. Однако, log history полезна в многопоточной среде (Oracle with the Parallel Server option in parallel mode), даже если открыт один поток.

Представление V$RECOVERY_LOG показывает информацию об архивированных журналах, которые нужны для complete media recovery. Эта информация является производной от записей в log history .

CONTROL_FILE_RECORD_KEEP_TIME

Для того чтобы полностью понять, почему появляется ошибка «kccrsz: expanded controlfile…», нужно знать что представляет собой параметр инициализации CONTROL_FILE_RECORD_KEEP_TIME .

Параметр инициализации CONTROL_FILE_RECORD_KEEP_TIME (установленный по умолчанию в 7) указывает минимальное количество дней, прежде чем многократно используемая (циклическая) запись в секции будет перезаписана. Этот параметр относится только к записям в секциях управляющего файла, которые циклически многократно используются. Если в такую секцию нужно добавить новую запись, а самая старая запись хранится меньше чем CONTROL_FILE_RECORD_KEEP_TIME дней, то секция вынуждена расширяться. То есть, если у Вас, например, накапливается больше журнальных логов, чем указано в параметре maxloghistory за кол-во дней меньшее, чем control_file_record_keep_time, то происходит ошибка: kccrsz: expanded controlfile section 11…

Установленное значение control_file_record_keep_time можно изменить командой:

ALTER SYSTEM SET control_file_record_keep_time=новое_количество_дней;

Вот теперь понятно, что ничего страшного с нашим ораклом не произошло, а сообщение в алерте было просто информативным. Но можно сделать следующие выводы:

  • Файлы журнализации транзакций не должны иметь маленький размер
  • Переключение журнальных файлов должно происходить не очень часто (20-60 мин).
  • При глобальных изменениях в структуре базы данных (добавление файлов данных, redo groups и прочее) необходимо делать backup управляющего файла: alter database backup controlfile to trace.

Мониторинг управляющего файла можно с помощью представления V$CONTROLFILE_RECORD_SECTION

select type from V$CONTROLFILE_RECORD_SECTION

Ценную информацию об управляющем файле можно получить ещё и таким образом:

alter session set events 'immediate trace name controlf level 10'; 

 

Новый комментарий

Я не спамер: введите суму 4+4



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Досуг для взрослых
19 июня, 1 ответа
авто
19 июня, 1 ответа
Отдых
18 июня, 2 ответа