Основные параметры запуска ядра СУБД

 

Способ ведения журнала транзакций для СУБД. Ведение журнала транзакций — это процесс, при котором происходит запись логических и физических транзакций в специальные файлы в системной области БД, т. е. всех обновлений области данных и областей индексов методов доступа. Обычно поддерживаются два основных типа ведения журнала транзакций — циклическое и архивное [1, 46].

Циклическое ведение журнала транзакций использует некоторое количество первичных журналов, определенное при задании параметров конфигурации СУБД. При этом способе журналы транзакций применяются в определенной последовательности. Записи помещаются в первый файл до тех пор, пока он не будет заполнен до установленного администратором базы данных уровня, затем открывается второй журнал, и все новые транзакции записываются в него. Транзакции из первого файла журнала переписываются ядром в БД, и, когда их обработка завершается, первый журнал закрывается и может быть использован повторно. Если ядро СУБД базы данных запросит следующий журнал, а он еще не доступен для повторного использования, то будет открыт еще один журнал. Эта ситуация будет продолжаться до тех пор, пока число вторичных журналов транзакций не достигнет определенного значения. Процесс продолжается циклически без необходимости останавливать работу ядра СУБД из-за отсутствия места в журнале транзакций. Первичные журналы транзакций создаются обычно автоматически при создании базы данных, вторичные создаются по необходимости и удаляются, как только ядро СУБД помечает их как ненужные. Циклическое ведение журналов обеспечивает поддержку аварийного восстановления при текущем автооткате ядра СУБД, но не поддерживает восстановление с повторением журналов транзакций.

Архивное ведение журнала транзакций не допускает повторного использования журналов. Когда файл журнала заполняется, создается очередной файл. Обычно администратор базы данных конфигурирует несколько первичных журналов транзакций. Это делается для того, чтобы новый файл был создан заранее, и его отсутствие не привело бы к остановке работы СУБД. Журналы архивируются и удаляются из оперативной области администратором базы данных по мере их заполнения.

В различных СУБД могут быть свои варианты ведения журналов транзакций. Например, для СУБД DB2 различают активные, онлайновые и офлайновые архивы.

Активные архивы. Эти файлы содержат информацию, связанную с транзакциями, которые еще не зафиксированы (или не отменены) в БД. Они также содержат информацию для транзакций, которые были начаты, но еще не были полностью переписаны на диски из буферного пула ввода-вывода. Активные файлы журналов используются при аварийном восстановлении.

Онлайновые архивы. Эти файлы содержат информацию, связанную с законченными транзакциями. Их называют онлайновыми, потому что они находятся в том же самом подкаталоге, что и активные журналы регистрации.

Офлайновые архивы. Это файлы, которые были перемещены из активного подкаталога журналов транзакций.

Ядро DB2 при работе с архивными журналами при завершении работы последнего приложения усекает и закрывает последний журнал транзакций для освобождения пространства. Эта опция полезна, когда база данных должна быть неактивной в определенные промежутки времени. Однако, в условиях низкой нагрузки, когда характерны частые и короткие периоды, в которые ни одно приложение не работает с базой данных, эта особенность превращается в дополнительную трату ресурсов. Ресурсы расходуются на закрытие последнего активного файла журнала при завершении работы приложений и создание первичных журналов с началом работы какого-либо приложения. Это пример того, что АБД должен использовать специальные параметры конфигурации и управления для эффективной работы. Следует заметить, что файлы журнала потенциально являются узким местом с точки зрения производительности информационной системы из-за постоянного обращения к ним подсистемы ввода-вывода СУБД и ОС. Администратору базы данных необходимо размещать их на наиболее быстрых и надежных носителях.

Поиск сервера БД. В начале работы станция пользователя БД должна найти сервер БД. Для этого программное обеспечение станции рассылает запрос всем устройствам в сети «Ты сервер?» Станция-сервер отвечает и передает в ответ на запрос свой физический адрес (МАС-адрес). Этот адрес записывается в специальной таблице математического обеспечения рабочей станции, хранящейся в оперативной памяти (таблица МАС- адресов серверов сети). Обычно отвечает станции ближайший (по времени ответа) сервер, если в параметрах запуска программного обеспечения АБД не указал конкретного сервера. Аналогичный опрос ведет любой сервер БД, выясняя, какие рабочие станции активны, и заполняя свою таблицу активных пользователей. АБД должен задать параметры поиска сервера: число попыток поиска, таймаут, при котором поиск прекращается.

Максимальпое число залокированных записей. Необходимо указать, сколько записей БД может быть единовременно залокировано (задержано) для последующих изменений. АБД следует понимать, что записи именно «локируются» (lock), т. е. удерживаются ядром СУБД от доступа других пользователей пока не будут освобождены (unlock) тем пользователем, который первый их захватил или ядром СУБД. АБД не должен путать этот процесс с блокированием записей — хранением записей в блоках на диске или оперативной памяти для более быстрого обращения к ним.

Время взаимолокирования (deadlock — «смертельные объятия»). АБД задает параметр ядра, ограничивающий по времени длительность локирования (lock) записей или отношений для обновления. После этого требуемая запись будет освобождена ядром, и приложение сможет попытаться заново осуществить операцию изменения записи или отношения БД. Процесс локирования тесно связан с процессом обеспечения целостности с помощью аппарата транзакций [11, 49]. Процесс управления работой транзакций сложен и имеет множество особенностей. АБД следует внимательно изучить его реализацию для конкретной СУБД согласно технической документации.

Максимальное время неактивности пользователя БД (время на disconnect). Если приложение на станции «зависло», то через указанное в этом параметре время его надо сделать неактивным для ядра СУБД и удалить все ссылки на него в оперативной памяти. АБД должен задать этот параметр либо использовать умолчания для предотвращения ситуации, когда неработающее приложение занимает ресурсы СУБД.

Максимальное число подключенных станций. Необходимо указать максимальное число пользователей, одновременно работающих с ИС.

Директории для хранения журналов транзакций и сообщений. Задаются АБД или задаются по умолчанию.