31018-1 (663207), страница 2
Текст из файла (страница 2)
CREATE TABLE emp_data
(
emp_num integer,
emp_name char(20),
hired date,
id-code char (10),
salary decimal(4,2)
)
Пусть после создания таблицы был выполнен следующий оператор:
REVOKE ALL ON emp_data FROM PUBLIC
Теперь создадим несколько представлений для разных категорий пользователей. Для тех, кто может иметь доступ по чтению из неконфиденциальных столбцов, создадим такое представление:
CREATE VIEW emp_data AS
SELECT emp_num, emp_name FROM emp_data
Пользователи, получившие привилегию SELECT для данного представления, могут видеть некоторые данные без возможности обновления. Для работников отдела кадров создадим следующее представление:
CREATE VIEW enter_data AS
SELECT emp_num,emp_name,id-code,salary FROM emp_data
Этим пользователям необходимо предоставить привилегии INSERT и UPDATE для этого представления. Так как создатель таблицы и представления имеет привилегии на вставку как для таблицы так и для представления, можно предоставить привилегии INSERT и UPDATE на представление даже тем пользователям, у которых нет такой привилегии:
GRANT SELECT, INSERT, UPDATE ON enter_data TO olga_s, helena_m
Для некоторых пользователей, которые могут вводить или изменять некоторые данные о сотрудниках, создадим еще одно представление:
CREATE VIEW enter_upd AS
SELECT emp_num,emp_name,id-code FROM emp_data
Это представление отличается от предыдущего тем, что в последнем не показываются данные о зарплате сотрудников. Наконец, пусть менеджерам необходим доступ по чтению и редактированию всех данных о работниках фирмы:
CREATE VIEW all_data AS
SELECT * FROM emp_data
Теперь можно дать менеджерам все привилегии:
GRANT SELECT, UPDATE, INSERT, DELETE ON emp_data TO alex_v
Администрирование сервера INFORMIX-OnLine
Внедрение в информационную систему сервера INFORMIX-OnLine Dynamic Server требует решения множества вопросов, которые влияют на производительность системы в целом. Необходимо решить вопросы, где будут храниться данные, как к ним будет осуществляться доступ, как защитить данные. OnLine Server позволяет настроить систему на оптимальную производительность. Для этого необходимо понимать архитектуру сервера и требований, возникающих во время эксплуатации сервера.
Организация хранения данных
Сервер 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 позволяет архивировать данные и восстанавливать их в случае порчи.
Устройство системы восстановления данных
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
