СУБД INFORMIX Администрирование и безопасность

архитектуру сервера и требований, возникающих во время эксплуатации

сервера.

Организация хранения данных

Сервер INFORMIX-OnLine может хранить данные на диске двумя

способами. Первый способ – это хранение данных в файловой системе ОС.

Второй способ – хранение данных на “сыром” дисковом пространстве. В

последнем случае сервер INFORMIX-OnLine сам управляет вводом-выводом

данных.

Единицы хранения данных

Сервер INFORMIX-OnLine использует следующие физические единицы

хранения информации: chunk, page, blobpage, extent.

Логические единицы хранения данных связаны с управлением БД. К

логическим единицам относятся: dbspace, blobspace, database, table,

tblspace.

В дополнение к этому существуют следующие единицы хранения

информации о физической и логической целостности данных: logical log,

physical log, reserved pages.

Фрагмент диска chunk – это максимальная физическая единица хранения

информации сервером INFORMIX-OnLine. Фрагмент может быть файлом

операционной системы или специальным символьным устройством системы. В

первом случае данные размещаются в обычном файле и записью на диск

управляет ОС. В этом случае INFORMIX-OnLine не гарантирует, что

записанные данные реально попадут на диск, так как данные могут быть

помещены в дисковую кэш-память ОС. Во втором случае сервер гарантирует,

что те данные, которые должны попасть на диск, будут записаны. Кроме

этого, заметно выше производительность системы ввода-вывода. Однако не

каждая операционная система позволяет организовать chunk на “сыром”

диске. INFORMIX-OnLine поддерживает размер chunk до 2 GB. Максимальное

количество chunk’ов – 2048.

Страница page – это единица информации, которой сервер INFORMIX-

OnLine обменивается с устройством хранения данных для доступа к БД.

Размер страницы варьируется. Обычно это 2 или 4 КБ. Фрагмент диска

содержит определенное количество страниц. Страница не может выходить за

пределы chunk’а.

Blobpage – единица дискового пространства, которой INFORMIX-OnLine

манипулирует для хранения данных типа BYTE и TEXT. Размер blobpage

задается администратором и может варьироваться.

Когда создается таблица, INFORMIX-OnLine выделяет фиксированное

число страниц для хранения данных. Когда выделенное пространство

исчерпывается, сервер выделяет дополнительное место. Физическая единица

данных, которая используется для этих целей, называется extent. При

создании таблицы задаются initial extent size и next extent size.

Первый – первоначальный объем под таблицу (в килобайтах). Второй –

величина прироста объема таблицы в килобайтах.

Extent всегда хранится в пределах одного chunk’а и не может

перекрывать его границы. В случае, когда INFORMIX-OnLine не может

выделить достаточно пространства в текущем фрагменте, он ищет его в

другом фрагменте.

Базовой логической единицей хранения информации сервером INFORMIX-

OnLine является пространство БД (dbspace). Пространство БД отображает

физическое пространство на логическое пространство хранения данных.

Обычно одному dbspace соответствует один chunk, хотя одному dbspace

может соответствовать несколько фрагментов.

Зеркалирование

Зеркалирование позволяет резервировать фрагмент диска точно такого

же размера фрагментом. Запись в первичный chunk порождает запись в

резервный chunk. В случае сбоя первичного фрагмента сервер INFORMIX-

OnLine переключается на резервный автоматически, при этом работа

пользователя не прерывается.

Технология резервирования позволяет администратору восстанавливать

данные в первичном фрагменте параллельно с работой пользователя с

вторичным фрагментом.

За возможность зеркалирования придется платить дополнительным

дисковым пространством.

В случае, когда незеркалированный chunk выходит из строя, INFORMIX-

OnLine не может добраться к данным из него и будет возвращать ошибку

при обращении к этому фрагменту. Если из строя вышел незеркалированный

фрагмент, который хранит logical log, physical log или root dbspace,

сервер немедленно переходит в режим off-line, т.е. прекращает работу.

Сервер делает запись в оба фрагмента параллельно и читает из обоих

разные части (split read) для минимизации времени ввода-вывода.

Когда создается зеркалированный chunk, INFORMIX-OnLine копирует

данные из первичного во вторичный. Такой процесс называется

восстановлением (recovery). Зеркалирование начинает работать сразу

после завершения процесса восстановления.

Физический и логический протоколы работы

Физический протокол (physical log)

Ведение физического протокола есть процесс сохранения страниц,

который INFORMIX-OnLine собирается менять, но до того, как будут

внесены реальные изменения в страницы. Другими словами, сервер перед

модификацией страниц в памяти сбрасывает их копии в буфер физического

протокола в памяти.

Физический протокол – это множество последовательных страниц, где

INFORMIX-OnLine сохраняет неизмененные страницы (before-image). Это

нужно для быстрого восстановления после “падения” сервера.

Сервер манипулирует before-image в буфере физического протокола до

тех пор, пока один из очистителей страниц не запишет ее на диск.

Не попадают в протокол blob-страницы из blopspace, т.к. в

противном случае может произойти переполнение физического протокола.

Во время инициализации сервер размещает файлы логического и

физического протоколов в корневом пространстве БД root dbspace. Из-за

критичности физического протокола для работы INFORMIX-OnLine

рекомендуется зеркалировать dbspace, в котором хранится этот протокол.

Сервер выполняет физический протокол за шесть шагов:

Читает страницы данных в буфер.

Копирует неизмененные страницы в буфер физического протокола.

Отображает изменения в буфере страницы после того, как приложение

изменяет данные.

Сохраняет буфер физического протокола собственно в физическом протоколе

на диске.

Сохраняет буфер страницы на диске.

При срабатывании контрольной точки (checkpoint) сбрасывает буфер

физического протокола на диск и затем очищает физический протокол.

Логический протокол (logical log)

Сервер INFORMIX-OnLine хранит историю изменений в БД и сервере с

момента генерации последнего архива и сохранения записей протокола.

Сервер сохраняет записи протокола в логическом протоколе, из которого

создаются файлы логического протокола. Этот протокол называется

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

связанные с логическими операциями работы сервера БД в

противоположность физическим операциям сервера.

Все БД, управляемые одним сервером INFORMIX-OnLine, сохраняют свой

протокол в одном и том же логическом протоколе сервера.

Файлы логического протокола не являются файлами операционной

системы. Это часть дискового пространства, управляемого INFORMIX-

OnLine. Каждый файл логического протокола – это отдельное пространство

на диске.

При данной активности системы, чем меньше будет отдано под файл

логического протокола, тем быстрее это место будет заполнено, и больше

вероятность того, что активность пользователя будет заблокирована во

время архивирования логического протокола и срабатывания контрольной

точки.

. Архивирование файла логического протокола

Когда файл логического протокола заполнен, необходимо его

заархивировать. Процесс архивирования может “заморозить” процесс

обработки транзакций, которые работают с данными из того же диска,

что и файл логического протокола. Поэтому рекомендуется выбирать

время малой активности пользователей для архивирования файла

протокола.

. Контрольные точки

Как минимум одна контрольная точка должна быть записана в

логический протокол. Если необходимо освободить файл, содержащий

последнюю контрольную точку, то нужно записать новую контрольную

точку в текущий файл логического протокола. Соответственно, чем

чаще архивируется файл логического протокола и чем чаще он

освобождается, тем чаще случаются контрольные точки. Т.к.

контрольная точка блокирует работу пользователей, то это

отрицательно сказывается на производительности.

Общий размер логического протокола есть произведение количества

файлов протокола на их размер:

. Минимальный размер файла логического протокола – 200 KB.

. Максимальный размер не ограничен, но следует иметь ввиду, что

если архивация происходит на медленный стример, то лучше делать

размер файла небольшим.

. Чем меньше размер файла, тем меньше информации может быть

потеряно, т.к. есть вероятность потерять последний не

сохраненный файл логического протокола при выходе диска из

строя.

. Всегда необходимо иметь минимум 3 файла логического протокола.

. Необходимо всегда иметь достаточное количество файлов

логического протокола для того, чтобы всегда иметь возможность

переключиться на новый файл и не допустить переполнения этих

файлов.

При инициализации дискового пространства INFORMIX-OnLine размещает

файлы логического прокола в корневом пространстве БД (root dbspace).

Файлы логического протокола содержат критически важную информацию и

должны быть зазеркалированы для обеспечения максимальной надежности

данных.

Каждый файл имеет свой уникальный идентификатор. Последовательность

номеров начинается с 1 для первого файла логического протокола,

заполненного после инициализации дискового пространства. При заполнении

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

номер на 1 больше, чем предыдущий.

Актуальное дисковое пространство, выделенное для каждого файла

логического протокола, имеет идентификационный номер logid. Например,

если вы сконфигурировали 6 логического протокола, то эти файлы имеют

номера от 1 до 6. После того, как эти файлы заархивированы и

освобождены, INFORMIX-OnLine повторно использует дисковое пространство

для файлов логического протокола, однако сервер будет нумеровать

уникальным идентификатором, которой равен предыдущему плюс единица.

Файлы логического протокола имеют один из следующих статусов:

Added (A) Файл протокола имеет статус добавленный, когда этот файл

только что добавлен. Он не будет доступен для использования до тех пор,

пока не будет создан архив нулевого уровня корневого пространства БД.

Free (F) Файл логического протокола свободен, когда он доступен для

использования. Этот файл был освобожден после архивирования, все

транзакции внутри файла протокола были завершены и последняя запись

контрольной точки находится в следующем по порядку протоколе.

Used (U) Файл логического протокола задействован, когда он нужен

серверу для восстановления (откат транзакций или поиск последней записи

контрольной точки).

Backed-up (B) Файл протокола имеет статус заархивирован после того,

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

Current (C) Файл протокола имеет статус текущий, когда сервер

заполняет его протоколом.

Last (L) Файл имеет статус последний, когда он содержит самую

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

до тех пор, пока сервер не запишет новую контрольную точку в другой

файл логического протокола.

Если INFORMIX-OnLine пытается переключиться на следующий по порядку

файл логического протокола, который еще не освобожден, то вся работа

приостанавливается. Это происходит даже в том случае, когда один из

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

номеру файл. Работа останавливается для защиты данных в файле

протокола. Файл логического протокола может быть занят по следующим

причинам:

. Файл логического протокола не заархивирован.

. Файл содержит открытую транзакцию.

Длинная транзакция – это такая транзакция, которая начинается в

одном файле логического протокола и не фиксируется, когда INFORMIX-

OnLine нуждается в повторном использовании того же файла протокола.

Т.е. длинная транзакция перекрывает больше пространства, чем выделено

всего под логический протокол.

Т.к. сервер не может освободить файл логического протокола до тех

пор, пока все записи не будут ассоциированы с закрытыми транзакциями,

длинная транзакция мешает освободить первый файл протокола и делает его

недоступным для использования.

Для предотвращения такой ситуации нужно учесть следующее:

. Проверить, не заполняется ли файл логического протокола слишком

быстро.

. Проверить, не остается ли транзакция слишком долго открытой.

Установить границу, по достижении которой INFORMIX-OnLine

автоматически свернет обработку длинной транзакции.

Архивирование данных

Система восстановления INFORMIX-OnLine позволяет архивировать

данные и восстанавливать их в случае порчи.

Устройство системы восстановления данных

Архив – это копия всех или части данных, которыми управляет сервер,

т.е. это копия одного или более dbspace и любых вспомогательных данных,

которые могут понадобиться для восстановления.

Архив логического протокола – это копия файлов логического

протокола на диске или ленте, которые заполнены и готовы к

архивированию.

Восстановление – это процесс восстановления данных INFORMIX-OnLine,

в частности, пространств БД из архива и архивированных файлов

логического протокола.

Физическое и логическое восстановление

Восстановление данных необходимо производить в два этапа. Первый

этап – физическое восстановление, второй – логическое восстановление.

Физическое восстановление – процесс восстановления страниц пространств

БД из архива. Логическое восстановление использует архивированный

логический протокол для «наката» транзакций в восстановленных

пространствах БД.

Система восстановления INFORMIX-OnLine

INFORMIX-OnLine предоставляет две системы восстановления данных: ON-

Archive и ontype. Они позволяют сделать следующее:

. Архивировать данные INFORMIX-OnLine;

. Архивировать файлы логического протокола;

. Делать добавочное архивирование файлов логического протокола;

. Восстанавливать данные из архива;

В дополнение к этому On-Archive позволяет следующее:

. Планирование и отслеживание архивов;

. Множество средств защиты и доступа к On-Archive;

. Возможность параллельно работать с несколькими ленточными

устройствами;

. Работать без непосредственного участия человека.

Сохранение страниц и логического протокола в архиве

Все, чем управляет INFORMIX-OnLine может быть заархивировано за

исключением следующего:

. Страницы dbspace, выделенные для сервера, но не привязанные к

какому-либо фрагменту tblspace;

. Конфигурационные файлы не архивируются;

. Страницы из зеркальных фрагментов не архивируются, если доступен

первичный фрагмент;

. Blob’ы в blobspace, хранимые на оптическом носителе;

Уровни архива

Нет смысла каждый раз архивировать все данные INFORMIX-OnLine.

Поддерживаются три типа добавочного архивирования:

. Level-0 – архивируются все страницы;

. Level-1 – архивируются все изменения с момента последнего архива

нулевого уровня;

. Level-2 – архивируются все изменения с момента последнего архива

первого уровня.

Архивирование логического протокола

Если было инициировано протоколирование БД, то INFORMIX-OnLine

записывает транзакции, произошедшие между процедурами архивирования, в

логический протокол, который состоит из определенного числа файлов

логического протокола на диске. Сервер нуждается как в записи новых

данных в протокол, так и в чтении протокола для восстановления

транзакций. Для того, чтобы файлы логического протокола не закончились,

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

Если же протоколирование не используется, тем не менее, все равно

необходимо архивировать файлы логического протокола. В этом случае

протокол содержит информацию о создании и удалении фрагментов диска и о

записи контрольной точки. Эта информация нужна для “теплого”

восстановления БД даже в том случае, когда БД не протоколируются.

Автоматическое и непрерывное архивирование

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

после их заполнения, то нужно запустить автоматическое архивирование. В

этом режиме архивируются все файлы логического протокола, готовые к

архивированию и процесс останавливается на текущем файле.

Также можно запустить непрерывное архивирование. Тогда сервер

автоматически архивирует файл логического протокола сразу по его

заполнению.

При автоматическом архивировании нет необходимости помнить об

архивировании файла, но нужно помнить, что на устройстве архивирования

всегда должно быть свободное место.

Режимы восстановления данных

В процессе восстановления INFORMIX-OnLine воссоздает данные,

которые стали недоступными в результате аппаратного или программного

сбоя. В любом из трех приведенных ниже случаях необходимо

восстановление данных:

. Ошибка в программе запортила данные в БД;

. Необходимо перенести данные на другой компьютер.

. Процесс восстановления делится на фазы физического и логического

восстановления:

. При физическом восстановлении из архива восстанавливаются

страницы dbspace и blobspace;

. При логическом восстановлении производится восстановление

транзакций.

Выбор типа физического восстановления

Если необходимо восстановить данные после сбоя, в результате

которого сервер перешел в режим off-line, то необходимо восстановить

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

полным восстановлением системы. Если сбой не привел к останову системы,

то можно выборочно восстанавливать выборочные dbspace или blobspace.

При переходе INFORMIX-OnLine в режим off-line из-за сбоя диска

критические данные dbspace будут повреждены. К критическим dbspace

относятся:

. root dbspace;

. содержащий физический протокол dbspace;

. содержащий файлы логического протокола dbspace.

Восстановление критических dbspace необходимо производить в

“холодном” режиме.

Выборочное восстановление dbspace или blobspace

Если после сбоя INFORMIX-OnLine не перешел в состояние off-line, то

повреждения dbspace не являются критическими. Если сбой случился в

фрагменте диска dbspace, который размещается на нескольких фрагментах,

то все активные транзакции в этом dbspace должны быть прерваны перед

восстановлением. Можно запустить операцию восстановления до завершения

транзакций. Тогда процесс восстановления будет ждать, пока сервер не

завершит проверку того, что все транзакции, активные в момент сбоя,

были завершены.

“Холодный” режим восстановления

Как показано на рис. 1, восстановление всех dbspace и blobspace

(полное восстановление системы) можно сделать с помощью одного

физического и одного логического восстановления.

INFORMIX-OnLine находится в режиме off-line в начале процесса

восстановления, но затем, после восстановления резервных страниц,

сервер переходит в режим восстановления. С этого момента сервер

находится в данном режиме до тех пор, пока не будет завершено

логическое восстановление.

“Теплый” режим восстановления

В данном режиме можно восстанавливать некритичные dbspace и

blobspace при работе INFORMIX-OnLine в режиме on-line или quiescent.

“Теплый” режим состоит из одного или нескольких физических

восстановлений, логического архивирования и восстановления.

При “теплом” восстановлении заархивированные файлы логического

протокола “проигрываются” для восстановления транзакций в

восстановленных dbspace (рис. 2).

Смешанный режим восстановления

Смешанный режим восстановления состоит из холодного восстановления,

за которым следует теплое восстановление. Некоторые dbspace и blobspace

восстанавливаются в холодном режиме (INFORMIX-OnLine находится в режиме

off-line). Такой режим восстановления обычно применяется, когда

требуется полное восстановление системы, но в ходе его требуется

частичный доступ к некоторым таблицам. В этом случае выполняется

холодное восстановление критических dbspace и dbspace, которые содержат

важную информацию.

Экспорт-импорт данных

Миграция данных, т.е. перенос базы данных или ее частей может

понадобиться по следующим причинам:

. Для переноса разработанной системы заказчику;

. Для переноса на другую аппаратную платформу;

. Для распространения пользователям;

. Для переноса данных между INFORMIX-SE и INFORMIX-OnLine.

Методы миграции данных, используемые в INFORMIX-OnLine

Сервер INFORMIX-OnLine следующие методы для переноса данных из

одной БД в другую:

. Утилитами onunload и onload;

. Утилитами dbexport и dbimport;

. Выражениями LOAD и UNLOAD;

. Утилитой dbload.

Утилиты onunload и onload взаимосвязаны, т.е. для того, чтобы

загрузить данные с помощью onload, их необходимо предварительно

выгрузить с помощью onunload. Аналогично, для работы dbimport нужны

файлы, подготовленные dbexport. Утилита dbload и выражение LOAD могут

загружать данные из любого файла, если он отвечает определенным

требованиям по формату.

Утилита dbschema по схеме БД создает файл с выражениями на SQL,

который можно использовать затем для создания таблиц с аналогичной

структурой.

Использование утилит onunload и onload

Эти две утилиты выгружают и загружают данные из БД или ее части

страницами. Поэтому на использование этих утилит накладываются

некоторые ограничения.

При переносе данных между компьютерами необходимо:

Убедиться, что размер страницы и представление чисел должно быть

одинаковым на обоих системах.

Запустить утилиту oncheck для проверки целостности базы данных.

Запустить утилиту onunload.

Если нужно, перенести носитель с выгруженными данными на другую

систему.

Запустить утилиту onload.

Установить желаемый статус протоколирования новой БД.

Создать архив нулевого уровня новой БД.

При переносе таблиц между компьютерами с помощью onunload и onload

необходимо выполнить следующие шаги:

Удостовериться, что размер страниц и представление чисел одинаково на

обоих системах.

Запустить утилиту oncheck для проверки целостности базы данных.

Запустить утилиту onunload.

Если нужно, перенести носитель с выгруженными данными на другую

систему.

Выключить протоколирование

Запустить утилиту onload.

Создать архив нулевого уровня модифицированной БД.

Включить протоколирование, если нужно.

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

Выбор между onunload, dbimport и LOAD

При невозможности использования утилит onunload и onload,

необходимо сделать выбор между dbload, dbimport и LOAD. Каждый из этих

способов позволяет модифицировать схему БД.

Утилита dbimport загружает БД целиком и ею необходимо

воспользоваться в том случае, когда нет возможности использовать

onload. Для загрузки таблиц используйте выражение LOAD или утилиту

dbload.

При использовании утилиты dbload (или выражения LOAD) нужно

загружать данные в уже существующую таблицу. Если таблицы не

существует, то ее нужно создать, например, с помощью SQL-выражения

CREATE можно создать таблицу, представление или синоним.

Модификация схемы БД

Утилита dbschema создает файл с SQL-операторами, необходимыми для

воспроизведения указанной БД, таблицы и других объектов БД (например,

триггера). После создания файла со схемой БД, этот файл можно вручную

отредактировать с целью изменения некоторых характеристик БД или

таблицы (или еще чего-нибудь). Можно изменить следующие характеристики:

. Права доступа;

. Владельца объекта (таблица, индекс, представление);

. Режим блокировки;

. Размеры начального и последующих extent’ов.

. Dbspace, где хранятся таблицы.

Использование выражений UNLOAD и LOAD

Выражение UNLOAD позволяет записывать строки, извлеченные

выражением SELECT в ASCII-файл. Выражение UNLOAD создает файл в

соответствие с установками в окружении пользовательского приложения.

Оператор LOAD загружает данные из предварительно созданного файла в

объект БД (таблицу, синоним или представление). Обычно на входе

используется файл, созданный оператором UNLOAD, т.к. оператор LOAD

требует строго форматированный файл.

Использование утилиты dbload

Данная утилита, используя команды в командном файле dbload, может

форматировать входные данные перед тем, как вставлять их в указанную

таблицу. В дополнение к этому опции командной строки dbload дают

следующие возможности:

. Проверить синтаксис выражений командного файла;

. Откладывать блокировки таблицы во время вставки данных;

. Игнорировать определенное число строк с начала входного файла;

. Пропускать некорректные строки;

. Прерывать загрузку после определенного количества найденных

некорректных строк.

Утилита dbload может брать на входе несколько файлов и вставлять их

содержимое в заданные таблицы, созданные из файла схемы БД.

Использование утилит dbexport и dbimport

Утилиты dbexport и dbimport манипулируют только базами данных

целиком. Для использования этих утилит нужно быть подключенным к

серверу БД как пользователь informix или иметь права системного

администратора.

Утилита dbexport выгружает данные в ASCII-файлы. В дополнение к

этому dbexport создает ASCII-файл, в котором содержится схема базы

данных, необходимая для повторного создания БД, идентичной данной, на

другом сервере.

Утилита dbimport читает входные файлы. Она использует файл схемы БД

для создания копии базы. Можно указать характеристики протоколирования

новой БД с помощью опций командной строки. После создания БД происходит

ее наполнение содержимым файлов, созданных утилитой dbexport.

Режимы работы сервера INFORMIX-OnLine

Сервер имеет несколько режимов работы:

. off-line

. quiescent

. on-line

. read-only

. recovery

. shutdown

В режиме off-line сервер не запущен.

В режиме quiescent выполняются административные процедуры. Для

этого прекращается вся работа с базой данных. Только пользователи

informix и root могут выполнять административные процедуры с помощью ON-

Monitor или утилит командной строки. В этом режиме нельзя подключиться

к серверу, однако можно узнать его текущее состояние.

В режиме on-line пользователи могут подсоединяться к своим базам

данных и выполнять запросы. В это время администратор может менять

определенные настройки в файле ONCONFIG.

Режим read-only приложения могут только запрашивать данные с

сервера, но не могут их обновлять.

Режим recovery является переходным. В этом режиме сервер находится

при переходе из режима off-line в режим quiescent. Быстрое

восстановление выполняется в этом режиме.

Режим shutdown также является переходным. Он может возникнуть при

переходе из режима on-line (или quiescent) в режим off-line.

Средства диагностики сервера INFORMIX-OnLine

Системная БД sysmaster

INFORMIX-OnLine Dynamic Server создает и поддерживает БД sysmaster.

Эта база данных содержит информацию о самом сервере. Sysmaster состоит

из следующих таблиц:

. Таблицы SMI

Таблицы интерфейса системного мониторинга (SMI) содержат

информацию о состоянии сервера INFORMIX-OnLine. Можно обращаться

к этим таблицам для определения “узких мест” в обработке

информации, определения использования ресурсов, отслеживания

активности сессий или сервера БД, и т.п.

. Таблицы каталога ON-Archive

Эти таблицы содержат информацию о запросах, наборах томов,

наборов сохранения.

INFORMIX-OnLine создает БД sysmaster автоматически при

инициализации дискового пространства. Нельзя удалить эту БД или таблицы

в ней, а также нельзя изменить состояние протоколирования БД.

Можно, как пользователь informix, создавать хранимые процедуры и

триггеры в этой БД. Но INFORMIX-OnLine не будет исполнять созданные

пользователем в sysmaster триггеры.

Описание таблиц SMI

Интерфейс системного мониторинга состоит из некоторого числа таблиц

и псевдотаблиц, которые автоматически поддерживаются INFORMIX-OnLine и

не сбрасываются на диск во время работы.

Таблицы SMI содержат следующую информацию:

. Аудитинг

. Обращение к дискам

. Информация о пользователях

. Статус протоколирования баз данных

. Таблицы

. Chunk’и

. Ввод-вывод chunk’ов

. Пространства БД

. Блокировки

. Extent’ы

. Системная информация

Любой пользователь может запрашивать информацию из любой таблицы

sysmaster за исключением таблиц sysadinfo и sysaudit. Последние две

таблицы может просматривать только пользователь informix.

Триггеры по изменению в SMI-таблицах никогда не выполняются, т.к.

INFORMIX-OnLine производит изменения в SMI-таблицах не с помощью SQL-

выражений.

Ниже приведен список используемых SMI-таблиц:

|sysaudinfo |Конфигурационная информация аудитинга |

|sysaudit |Маски событий аудитинга |

|syschkio |Статистика ввода-вывода для chunk’ов |

|syschunks |Информация о chunk’ах |

|sysdatabase|Информация о базах данных |

|s | |

|sysdbspaces|Информация о пространствах БД |

|sysdri |Информация по репликации данных |

|sysextents |Информация о размещении extent’ов |

|syslocks |Информация об активных блокировках |

|syslogs |Информация о файлах логического протокола |

|sysprofile |Системная информация |

|sysptprof |Информация по таблицам |

|syssesprof |Подсчет действий пользователей |

|syssessions|Описание каждого пользовательского соединения |

|sysseswts |Время ожидания пользователем каждого из нескольких |

| |объектов |

|systabnames|Описание каждой таблицы, управляемой INFORMIX-OnLine |

Извлечение диагностической информации о работе сервера

Для извлечения информации из таблиц SMI используется утилита

onstat. Ниже приведены некоторые возможные опции этой утилиты:

|Опции onstat|Запрос к таблицам SMI|

|-d |sysdbspaces |

| |syschunks |

|-D |sysdbspaces |

| |syschkio |

|-F |sysprofile |

|-g dri |sysdri |

|-g glo |sysvpprof |

|-k |syslocks |

|-l |syslogs |

| |sysprofile |

|-p |sysprofile |

|-u |syssessions |

| |syssesprof |

Использованная литература:

“INFORMIX. Учебное пособие”, Киев, Из-во ANTEC, 1996

-----------------------

ЛЕНТЫ АРХИВА ЛОГИЧЕСКОГО ПРОТОКОЛА

АРХИВНЫЕ ЛЕНТЫ

ТРАНЗАКЦИИ

Root DBS

Dbspace1

dbspace2

Рис. 1

ЛЕНТЫ АРХИВА ЛОГИЧЕСКОГО ПРОТОКОЛА

ТРАНЗАКЦИИ

Root DBS

Dbspace1

dbspace2

Рис. 2

АРХИВНЫЕ ЛЕНТЫ

Страницы: 1, 2