|
СУБД INFORMIX
В
серверах баз данных фирмы INFORMIX можно ограничить или вовсе запретить
пользователям доступ к данным. Доступ можно ограничить на следующих четырех
уровнях: 1. В случае, если БД хранится в файлах операционной системы,
ограничением доступа можно управлять с помощью средств ОС. Однако этот уровень
недоступен при использовании сервера INFORMIX-OnLine. Это ядро само управляет
собственным дисковым пространством и правила операционной системы здесь не
применимы. 2. Можно использовать операторы GRANT и REVOKE, чтобы предоставить
или запретить доступ к БД или отдельным таблицам, а также разрешать или
запрещать проводить пользователями отдельных операций над БД. 3. Можно
использовать оператор CREATE VIEW для создания ограничивающего или обновляемого
представления. Ограничения могут быть горизонтальными (исключающие некоторые
строки) или вертикальными (исключающие некоторые столбцы) или одновременно
вертикальными и горизонтальными. 4. Допускается использование оператора GRANT
совместно с оператором CREATE VIEW для достижения более полного контроля над
частями таблицы и данными, которые пользователь может
изменять. Ядра баз данных INFORMIX (за
исключением INFORMIX-OnLine) хранят базы данных в файлах операционной системы.
Файлы собраны в каталоге, который представляет базу данных в целом. Можно
запретить доступ к базе данных, запретив доступ к каталогу базы данных
средствами операционной системы. Разрешение
на использование базы данных называется привилегией. Например, разрешение на
использование базы данных вообще называется привилегией CONNECT, тогда как
разрешение на добавление строк в таблицу называется привилегией INSERT. Можно
управлять доступом к базе данных, предоставляя привилегии пользователям или
отменяя их. Три уровня привилегии базы данных обеспечивают общие средства
управления тем, кто имеет доступ к базе данных. Привилегией самого нижнего уровня является привилегия CONNECT,
которая предоставляет пользователю базовые возможности запрашивать и обновлять
таблицы. Пользователь с этой привилегией может производить такие
операции: Создавать представления при условии,
что ему разрешено запрашивать таблицы, на которых основаны
представления; Создавать временные таблицы и индексы на них. Для этого
пользователь должен обладать привилегией CONNECT. Обычно, если БД не содержит
конфиденциальной информации, сразу после создания базы данных выполняется
операция GRANT CONNECT TO PUBLIC. Данная
привилегия предоставляет те же возможности, что и привилегия CONNECT, кроме
того, пользователь с привилегией RESOURCE может выполнять следующие
операции: Создавать новые постоянные таблицы
и индексы к ним. На высшем
уровне их трех уровней привилегий базы данных находятся привилегии
администратора базы данных (АБД). Создатель базы данных автоматически становится
ее администратором. Пользователь этого уровня доступа может осуществлять
следующее: Удалять или изменять любой объект
независимо от того, кому он принадлежит; Предоставлять
привилегии базы данных, включая привилегию АБД. Привилегиипредоставляются отдельным
пользователям по их именам, или всем пользователям – под именем PUBLIC. Все
привилегии, предоставленные под именем PUBLIC, действуют как привилегии по
умолчанию. Прежде, чем выполнить оператор, ядро базы данных определяет,
располагает ли пользователь необходимыми привилегиями. Сначала ядро ищет
привилегии, предоставленные именно данному пользователю. Если необходимые
привилегии обнаружены, то они предоставляются данному пользователю. Если же
пользователю такие привилегии не предоставлены, то сервер ищет их среди
общедоступных. Если такие найдены, то ядро использует их. Таким образом, можно
установить минимальный уровень привилегий для пользователей, предоставив
привилегии PUBLIC. В конкретных случаях эти привилегии могут быть перекрыты
путем предоставления пользователю более сильных привилегий. Если привилегия
CONNECT не делается общедоступной, то доступ к базе данных смогут получить
только те пользователи, которые имеют этот уровень привилегий. База данных, так же, как и каждая таблица, представление или
индекс и синоним этой базы имеет своего владельца. Обычно владельцем БД является
тот, кто его создал, хотя администратор базы данных может создавать объекты,
которые становятся принадлежащими другим пользователям. Владелец объекта имеет
на него все права и может изменить или удалить объект без каких-то
дополнительных привилегий. Привилегии нужны только для пользователей, которые не
являются владельцами объекта. Существует
шесть привилегий уровня таблицы, позволяющих передать пользователям, не
являющихся владельцами таблицы, привилегии владельца. Четыре из них – SELECT,
INSERT, UPDATE и DELETE – управляют доступом к содержимому таблицы. Привилегия
INDEX управляет созданием индекса. Привилегия ALTER определяет возможность
изменять определение таблицы. В ANSI-совместимых базах данных привилегии на
таблицу сразу после ее создания имеет только владелец. В других базах данных
ядро в процессе создания таблицы автоматически делает все табличные привилегии,
за исключением привилегии ALTER, общедоступными. Это означает, что только что
созданная таблица может быть доступна пользователю, который имеет привилегию
CONNECT. Если это нежелательно, то после создания таблицы ее владелец должен
отменить все привилегии, предоставленные PUBLIC в связи с этой
таблицей. Четыре привилегии управляют тем, как
пользователь может обращаться к таблице. Владелец таблицы может предоставлять
или не предоставлять, независимо одна от другой, следующие
привилегии: Привилегия INSERT позволяет добавлять в таблицу новые
строки; Привилегия SELECT необходима для выборки
содержимого таблицы, однако эта привилегия не является необходимой для обладания
другими привилегиями. Пользователь может иметь привилегии INSERT или UPDATE, не
имея при этом привилегии SELECT. Привилегия
INDEX позволяет создавать и изменять индексы в таблицах. Эта привилегия, так же,
как и привилегии SELECT, INSERT, UPDATE, DELETE, становится общедоступной после
создания таблицы. Можно предоставить привилегию INDEX всем пользователям, но
смогут пользоваться ею только те пользователи, кто имеет привилегию RESOURCE
уровня базы данных. Таким образом, хотя привилегия INDEX предоставляется
автоматически (кроме ANSI-совместиых баз данных), пользователи, обладающие
только привилегией уровня базы данных CONNECT не смогут воспользоваться
привилегией INDEX. Это имеет смысл, когда индексные файлы занимают много места
на диске. Привилегия ALTER позволяет пользователю использовать оператор ALTER
TABLE, включая возможность добавлять и удалять столбцы и т.д. Следует
предоставлять данную привилегия только тем пользователям, которые хорошо
понимают модель базы данных и достаточно квалифицированы, чтобы использовать эту
привилегию очень аккуратно. Можно
детализировать привилегии SELECT и UPDATE именами определенных столбцов. Это
позволит более тонко разграничить доступ пользователей к таблице: можно
позволять пользователю видеть или обновлять только определенные
столбцы. salary
decimal(4,2) Поскольку таблица содержит конфиденциальные данные, то сразу
после ее создания следует выполнить оператор REVOKE, который запрещает доступ к
данным: Для отдельных сотрудников отдела
кадров и менеджеров выполняется оператор типа: Таким образом, некоторым пользователям позволено видеть
все столбцы. GRANT список_привилегий_через_запятую
[(список_атрибутов через_запятую)] Для менеджеров, которые должны вводить
некоторые сведения о служащих, необходимо выполнить оператор типа: Этот оператор позволяет получить доступ к данным о зарплате и дате
приема на роботу служащих. Для некоторых пользователей из отдела кадров, которые
должны составлять технические данные о сотрудниках, нужно выполнить оператор
типа: Привилегии в системном каталоге Привилегии
регистрируются в таблицах системного каталога. Каждый пользователь, обладающий
привилегией CONNECT, может запросить информацию из таблиц системного каталога,
чтобы определить, какие и кому предоставлены привилегии. Привилегии базы
данных регистрируется в таблице sysusers, в который первичным ключом является
идентификатор пользователя, а в другом столбце находится символ C (CONNECT), R
(RESOURCE) или D (DBA), обозначающий уровень привилегий. Общедоступные
привилегии отображены под именем пользователя public (в нижнем
регистре). Привилегии уровня таблицы находятся в таблице systabauth, в которой
используется составной первичный ключ, включающий номер таблицы, идентификатор
пользователя, предоставившего привилегии на таблицу и идентификатор
пользователя, получившего их. В столбце tabauth привилегии закодированы в виде
шестибуквенного списка следующим образом (дефис обозначает не предоставленную
привилегию): r – REFERENCES (обращение к
заданной таблице в ограничениях целостности) Например, набор -u------ говорит, что
пользователь обладает только привилегией UPDATE. Если в третьей позиции
присутствует звездочка, то это означает, что для данной таблицы и пользователя
существуют еще какие-то привилегии уровня столбца. Конкретные привилегии
регистрируются в таблице syscolauth. Ее первичный ключ составлен из номера
таблицы, идентификатора пользователя, предоставившего привилегии, получившего
привилегии, и номера столбца. Единственный атрибут – двухбуквенный список,
показывающий тип привилегии: s-, -u или su. При создании представления ядро БД проверяет привилегии
пользователя на соответствующие таблицы и представления. При использовании же
представлений проверяются только привилегии на само
представление. При создании
представления ядро БД проверяет наличие у пользователя всех привилегий,
необходимых для выполнения оператора SELECT в определении представления. Если
таких привилегий нет, представление несоздается. Эта проверка не позволяет
пользователю получить несанкционированный доступ к таблице путем создания
представления для нее и обращения к представлению. После создания представления
ядро БД предоставляет его создателю и владельцу, как минимум, привилегию SELECT
для этого представления. Оно не становится автоматически общедоступным, как это
происходит с таблицей. Ядро БД определяет определение представления и выясняет,
является ли оно обновляемым. Если да, то создатель представления получает
привилегии INSERT, DELETE и UPDATE для этого представления при наличии этих
привилегий на порождающей таблице или представлении. Иными словами, если
создаваемое представление является обновляемым, то ядро БД копирует привилегии
INSERT, DELETE и UPDATE создателя представления и предоставляет их ему на новом
представлении. Если для порождающей таблицы создатель представления располагает
только привилегией INSERT, то он получит на представление только эту привилегию
и т.д. Эта проверка не позволяет пользователям получить какие-либо привилегии
кроме тех, которые у него уже есть. Поскольку для представления нельзя
выполнять операторы ALTER TABLE и CREATE INDEX, привилегии ALTER и INDEX никогда
не распространяются на представления. При попытке использовать представление, ядро БД проверяет
лишь те привилегии, которые относятся лишь к самому представлению. Оно не
проверяет права на доступ к определяющим его таблицам. Привилегии создателя
представления уже отмечались ранее. Для других пользователей привилегии
определяются создателем или тем, у кого есть привилегия WITH GRANT OPTION. Это
означает, что можно создать таблицу и отменить ее общедоступность. Затем можно
предоставить ограниченные привилегии на доступ к таблице через представления.
TO
список_пользователей_через_запятую [WITH GRANT OPTION] Директива WITHGRANT
OPTION наделяет указанных пользователей особыми полномочиями – правом
предоставления полномочий другим пользователям. Это означает, что для работы с
данным объектом они могут наделять полномочиями других пользователей. emp_num integer, Пусть
после создания таблицы был выполнен следующий оператор: Теперь создадим несколько представлений для разных категорий
пользователей. Для тех, кто может иметь доступ по чтению из неконфиденциальных
столбцов, создадим такое представление: Пользователи, получившие привилегию SELECT для
данного представления, могут видеть некоторые данные без возможности обновления.
Для работников отдела кадров создадим следующее представление: Этим
пользователям необходимо предоставить привилегии INSERT и UPDATE для этого
представления. Так как создатель таблицы и представления имеет привилегии на
вставку как для таблицы так и для представления, можно предоставить привилегии
INSERT и UPDATE на представление даже тем пользователям, у которых нет такой
привилегии: Для некоторых пользователей, которые могут вводить или изменять
некоторые данные о сотрудниках, создадим еще одно представление: Это
представление отличается от предыдущего тем, что в последнем не показываются
данные о зарплате сотрудников. Наконец, пусть менеджерам необходим доступ по
чтению и редактированию всех данных о работниках фирмы: GRANT SELECT, UPDATE, INSERT, DELETE ON emp_data TO alex_v
Внедрение в
информационную систему сервера INFORMIX-OnLine Dynamic Server требует решения
множества вопросов, которые влияют на производительность системы в целом.
Необходимо решить вопросы, где будут храниться данные, как к ним будет
осуществляться доступ, как защитить данные. OnLine Server позволяет настроить
систему на оптимальную производительность. Для этого необходимо понимать
архитектуру сервера и требований, возникающих во время эксплуатации
сервера. Сервер INFORMIX-OnLine может
хранить данные на диске двумя способами. Первый способ – это хранение данных в
файловой системе ОС. Второй способ – хранение данных на "сыром" дисковом
пространстве. В последнем случае сервер INFORMIX-OnLine сам управляет вводом-
выводом данных. Сервер INFORMIX-OnLine
использует следующие физические единицы хранения информации: Логические единицы хранения данных связаны с управлением
БД. К логическим единицам относятся: В дополнение к этому существуют следующие единицы хранения
информации о физической и логической целостности данных: Фрагмент диска 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
всегда хранится в пределах одного chunk'а и не может перекрывать его границы. В
случае, когда 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 копирует данные из первичного
во вторичный. Такой процесс называется Ведение физического протокола есть процесс
сохранения страниц, который INFORMIX-OnLine собирается менять, но до того, как
будут внесены реальные изменения в страницы. Другими словами, сервер перед
модификацией страниц в памяти сбрасывает их копии в буфер физического протокола
в памяти. – это множество последовательных страниц,
где INFORMIX-OnLine сохраняет неизмененные страницы ( Сервер манипулирует
before-image в буфере физического протокола до тех пор, пока один из очистителей
страниц не запишет ее на диск. Не попадают в протокол blob-страницы из
blopspace, т.к. в противном случае может произойти переполнение физического
протокола. Во время инициализации сервер размещает файлы логического и
физического протоколов в корневом пространстве БД root dbspace. Из-за
критичности физического протокола для работы INFORMIX-OnLine рекомендуется
зеркалировать dbspace, в котором хранится этот протокол. Копирует
неизмененные страницы в буфер физического протокола. Сохраняет буфер
физического протокола собственно в физическом протоколе на диске. При срабатывании контрольной точки (checkpoint)
сбрасывает буфер физического протокола на диск и затем очищает физический
протокол. Сервер INFORMIX-OnLine
хранит историю изменений в БД и сервере с момента генерации последнего архива и
сохранения записей протокола. Сервер сохраняет записи протокола в логическом
протоколе, из которого создаются файлы логического протокола. Этот протокол
называется логическим по той причине, что в нем сохраняются единицы работы,
связанные с логическими операциями работы сервера БД в противоположность
физическим операциям сервера. Все БД, управляемые одним сервером INFORMIX-
OnLine, сохраняют свой протокол в одном и том же логическом протоколе
сервера. Файлы логического протокола не являются файлами операционной системы.
Это часть дискового пространства, управляемого INFORMIX-OnLine. Каждый файл
логического протокола – это отдельное пространство на диске. При данной
активности системы, чем меньше будет отдано под файл логического протокола, тем
быстрее это место будет заполнено, и больше вероятность того, что активность
пользователя будет заблокирована во время архивирования логического протокола и
срабатывания контрольной точки. Когда файл логического протокола заполнен, необходимо его
заархивировать. Процесс архивирования может "заморозить" процесс обработки
транзакций, которые работают с данными из того же диска, что и файл логического
протокола. Поэтому рекомендуется выбирать время малой активности пользователей
для архивирования файла протокола. Как минимум
одна контрольная точка должна быть записана в логический протокол. Если
необходимо освободить файл, содержащий последнюю контрольную точку, то нужно
записать новую контрольную точку в текущий файл логического протокола.
Соответственно, чем чаще архивируется файл логического протокола и чем чаще он
освобождается, тем чаще случаются контрольные точки. Т.к. контрольная точка
блокирует работу пользователей, то это отрицательно сказывается на
производительности. Минимальный размер файла логического
протокола – 200 KB. Максимальный размер не ограничен, но следует иметь ввиду,
что если архивация происходит на медленный стример, то лучше делать размер файла
небольшим. Чем меньше размер файла, тем меньше информации может быть потеряно,
т.к. есть вероятность потерять последний не сохраненный файл логического
протокола при выходе диска из строя. Необходимо всегда иметь достаточное количество файлов
логического протокола для того, чтобы всегда иметь возможность переключиться на
новый файл и не допустить переполнения этих файлов. При инициализации
дискового пространства INFORMIX-OnLine размещает файлы логического прокола в
корневом пространстве БД (root dbspace). Файлы логического протокола содержат
критически важную информацию и должны быть зазеркалированы для обеспечения
максимальной надежности данных. Каждый файл имеет свой уникальный
идентификатор. Последовательность номеров начинается с 1 для первого файла
логического протокола, заполненного после инициализации дискового пространства.
При заполнении текущего файла сервер переключается на следующий и присваивает
ему номер на 1 больше, чем предыдущий. Актуальное дисковое пространство,
выделенное для каждого файла логического протокола, имеет идентификационный
номер logid. Например, если вы сконфигурировали 6 логического протокола, то эти
файлы имеют номера от 1 до 6. После того, как эти файлы заархивированы и
освобождены, INFORMIX-OnLine повторно использует дисковое пространство для
файлов логического протокола, однако сервер будет нумеровать уникальным
идентификатором, которой равен предыдущему плюс единица. добавленный , когда этот файл только что добавлен. Он не
будет доступен для использования до тех пор, пока не будет создан архив нулевого
уровня корневого пространства БД. , когда он доступен для использования. Этот файл был освобожден
после архивирования, все транзакции внутри файла протокола были завершены и
последняя запись контрольной точки находится в следующем по порядку
протоколе. ,
когда он нужен серверу для восстановления (откат транзакций или поиск последней
записи контрольной точки). после того, как этот файл был в самом деле
заархивирован. Last (L) , когда он содержит самую последнюю запись контрольной точки.
Этот файл не может быть освобожден до тех пор, пока сервер не запишет новую
контрольную точку в другой файл логического протокола. Если INFORMIX-OnLine
пытается переключиться на следующий по порядку файл логического протокола,
который еще не освобожден, то вся работа приостанавливается. Это происходит даже
в том случае, когда один из файлов протокола свободен. Сервер не может
использовать произвольный по номеру файл. Работаостанавливается для защиты
данных в файле протокола. Файл логического протокола может быть занят по
следующим причинам: Длинная транзакция – это такая транзакция,
которая начинается в одном файле логического протокола и не фиксируется, когда
INFORMIX-OnLine нуждается в повторном использовании того же файла протокола.
Т.е. длинная транзакция перекрывает больше пространства, чем выделено всего под
логический протокол. Т.к. сервер не может освободить файл логического
протокола до тех пор, пока все записи не будут ассоциированы с закрытыми
транзакциями, длинная транзакция мешает освободить первый файл протокола и
делает его недоступным для использования. Проверить, не заполняется ли файл логического
протокола слишком быстро. Установить границу, по достижении которой INFORMIX-OnLine
автоматически свернет обработку длинной транзакции. Система восстановления INFORMIX-OnLine позволяет архивировать
данные и восстанавливать их в случае порчи. Архив – это копия всех или части данных, которыми
управляет сервер, т.е. это копия одного или более dbspace и любых
вспомогательных данных, которые могут понадобиться для восстановления. Архив
логического протокола – это копия файлов логического протокола на диске или
ленте, которые заполнены и готовы к архивированию. Восстановление – это
процесс восстановления данных INFORMIX-OnLine, в частности, пространств БД из
архива и архивированных файлов логического протокола. Восстановление данных необходимо производить в
два этапа. Первый этап – физическое восстановление, второй – логическое
восстановление. Физическое восстановление – процесс восстановления страниц
пространств БД из архива. Логическое восстановление использует архивированный
логический протокол для "наката" транзакций в восстановленных пространствах
БД. ON-Archive Архивировать файлы логического протокола; В дополнение к этому Множество средств защиты и
доступа к Работать без непосредственного участия
человека. Все,
чем управляет INFORMIX-OnLine может быть заархивировано за исключением
следующего: Конфигурационные файлы не
архивируются; Blob'ы в blobspace, хранимые на оптическом
носителе; Нет смысла каждый раз архивировать все данные
INFORMIX-OnLine. Поддерживаются три типа добавочного архивирования: Level-1 – архивируются все изменения с момента
последнего архива нулевого уровня; Архивирование логического
протокола Если было инициировано протоколирование БД, то INFORMIX-OnLine
записывает транзакции, произошедшие между процедурами архивирования, в
логический протокол, который состоит из определенного числа файлов логического
протокола на диске. Сервер нуждается как в записи новых данных в протокол, так и
в чтении протокола для восстановления транзакций. Для того, чтобы файлы
логического протокола не закончились, необходимо архивировать заполненные файлы
логического протокола. Если же протоколирование не используется, тем не менее,
все равно необходимо архивировать файлы логического протокола. В этом случае
протокол содержит информацию о создании и удалении фрагментов диска и о записи
контрольной точки. Эта информация нужна для "теплого" восстановления БД даже в
том случае, когда БД не протоколируются. Если необходимо архивировать файлы логического протокола
сразу после их заполнения, то нужно запустить автоматическое архивирование. В
этом режиме архивируются все файлы логического протокола, готовые к
архивированию и процесс останавливается на текущем файле. Также можно
запустить непрерывное архивирование. Тогда сервер автоматически архивирует файл
логического протокола сразу по его заполнению. При автоматическом
архивировании нет необходимости помнить об архивировании файла, но нужно
помнить, что на устройстве архивирования всегда должно быть свободное
место. В процессе восстановления
INFORMIX-OnLine воссоздает данные, которые стали недоступными в результате
аппаратного или программного сбоя. В любом из трех приведенных ниже случаях
необходимо восстановление данных: Процесс восстановления
делится на фазы физического и логического восстановления: При
логическом восстановлении производится восстановление транзакций. Если необходимо восстановить данные после
сбоя, в результате которого сервер перешел в режим off-line, то необходимо
восстановить все данные, управляемые сервером. Такой тип восстановления
называется полным восстановлением системы. Если сбой не привел к останову
системы, то можно выборочно восстанавливать выборочные dbspace или
blobspace. При переходе INFORMIX-OnLine в режим off-line из-за сбоя диска
критические данные 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-OnLine и
Утилиты , их
необходимо предварительно выгрузить с помощью dbload Утилита по схеме
БД создает файл с выражениями на SQL, который можно использовать затем для
создания таблиц с аналогичной структурой. Эти две утилиты выгружают и загружают данные из БД или ее части
страницами. Поэтому на использование этих утилит накладываются некоторые
ограничения. Убедиться,
что размер страницы и представление чисел должно быть одинаковым на обоих
системах. Если нужно, перенести носитель с
выгруженными данными на другую систему. Создать
архив нулевого уровня новой БД. необходимо выполнить следующие
шаги: oncheck Если нужно, перенести носитель с
выгруженными данными на другую систему. Создать архив нулевого уровня модифицированной
БД. Выбор между onunload, dbimport и
LOAD dbload загружает БД целиком и ею необходимо воспользоваться в том
случае, когда нет возможности использовать При использовании
утилиты (или выражения LOAD) нужно загружать данные в уже
существующую таблицу. Если таблицы не существует, то ее нужно создать, например,
с помощью SQL-выражения CREATE можно создать таблицу, представление или
синоним. Утилита dbschema создает файл с SQL-
операторами, необходимыми для воспроизведения указанной БД, таблицы и других
объектов БД (например, триггера). После создания файла со схемой БД, этот файл
можно вручную отредактировать с целью изменения некоторых характеристик БД или
таблицы (или еще чего-нибудь). Можно изменить следующие характеристики: Размеры начального и последующих extent'ов. Выражение
UNLOAD позволяет записывать строки, извлеченные выражением SELECT в ASCII-файл.
Выражение UNLOAD создает файл в соответствие с установками в окружении
пользовательского приложения. Оператор LOAD загружает данные из предварительно
созданного файла в объект БД (таблицу, синоним или представление). Обычно на
входе используется файл, созданный оператором UNLOAD, т.к. оператор LOAD требует
строго форматированный файл. , может форматировать
входные данные перед тем, как вставлять их в указанную таблицу. В дополнение к
этому опции командной строки Откладывать
блокировки таблицы во время вставки данных; Прерывать
загрузку после определенного количества найденных некорректных строк. может брать на входе несколько файлов и вставлять их содержимое в
заданные таблицы, созданные из файла схемы БД. манипулируют
только базами данных целиком. Для использования этих утилит нужно быть
подключенным к серверу БД как пользователь выгружает данные в ASCII-
файлы. В дополнение к этому создает ASCII-файл, в котором
содержится схема базы данных, необходимая для повторного создания БД, идентичной
данной, на другом сервере. читает входные файлы. Она
использует файл схемы БД для создания копии базы. Можно указать характеристики
протоколирования новой БД с помощью опций командной строки. После создания БД
происходит ее наполнение содержимым файлов, созданных утилитой
off-line В
режиме off-line сервер не запущен. В режиме quiescent выполняются
административные процедуры. Для этого прекращается вся работа с базой данных.
Только пользователи или утилит командной
строки. В этом режиме нельзя подключиться к серверу, однако можно узнать его
текущее состояние. В режиме on-line пользователи могут подсоединяться к своим
базам данных и выполнять запросы. В это время администратор может менять
определенные настройки в файле ONCONFIG. Режим recovery
является переходным. В этом режиме сервер находится при переходе из режима off-
line в режим quiescent. Быстрое восстановление выполняется в этом
режиме. Режим shutdown также является переходным. Он может возникнуть при
переходе из режима on-line (или quiescent) в режим off-line. INFORMIX-
OnLine Dynamic Server создает и поддерживает БД sysmaster. Эта база данных
содержит информацию о самом сервере. Sysmaster состоит из следующих
таблиц: Таблицы интерфейса системного мониторинга (SMI) содержат
информацию о состоянии сервера INFORMIX-OnLine. Можно обращаться к этим таблицам
для определения "узких мест" в обработке информации, определения использования
ресурсов, отслеживания активности сессий или сервера БД, и т.п. INFORMIX-OnLine создает БД автоматически
при инициализации дискового пространства. Нельзя удалить эту БД или таблицы в
ней, а также нельзя изменить состояние протоколирования БД. , создавать хранимые процедуры и триггеры в этой БД.
Но INFORMIX-OnLine не будет исполнять созданные пользователем в Интерфейс системного мониторинга
состоит из некоторого числа таблиц и псевдотаблиц, которые автоматически
поддерживаются INFORMIX-OnLine и не сбрасываются на диск во время
работы. Статус протоколирования баз
данных Любой пользователь может
запрашивать информацию из любой таблицы sysmaster за исключением таблиц
sysadinfo и sysaudit. Последние две таблицы может просматривать только
пользователь informix. Триггеры по изменению в SMI-таблицах никогда не
выполняются, т.к. INFORMIX-OnLine производит изменения в SMI-таблицах не с
помощью SQL-выражений. Конфигурационная
информация аудитинга Маски событий
аудитинга Статистика ввода-вывода для
chunk'ов Информация о
базах данных Информация о пространствах БД Информация по репликации данных Информация о
размещении extent'ов Информация об
активных блокировках Информация о файлах
логического протокола Описание каждого пользовательского
соединения Время ожидания пользователем каждого из нескольких
объектов Описание каждой таблицы, управляемой INFORMIX-
OnLine Для извлечения информации из таблиц SMI используется утилита
| |
