7.3.6. Практические советы
Архивация должна производиться своевременно, только тогда можно быть уверенным, что в случае каких-либо сбоев или форс-мажорных обстоятельств типа большого пожара, система восстановит свою работоспособность в кратчайшее время.
Если вы меняете конфигурацию системы, например добавляете чанк, пространство или логический журнал, а также если меняете какой-либо важный параметр, следует как можно скорее создать архив нулевого уровня. При создании архива Руководство администратора настоятельно рекомендует зафиксировать все необходимые конфигурационные параметры. Эти параметры потребуется при восстановлении системы “с нуля”, то есть когда придется восстанавливать и сервер базы данных (то есть его программные, исполняемые файлы), и собственно содержимое базы данных. Необходимость такого глобального восстановления может возникнуть, например, при утрате жесткого диска. Для фиксации всех нужных параметров настройки можно вооружиться карандашом и листком бумаги, а можно выполнить команду
onstat -a
Данная команда выдает значение всех конфигурационных параметров. Результат выдачи данной команды можно сохранить в файл, например, такой командой:
onstat -a > my_config.txt
Файл, в котором будут храниться параметры, можно переписать на дискету. Учитывая, что необходимость сохранения всех конфигурационных параметров возникает именно при создании архивов, можно предложить хранить данный конфигурационный файл на том же самом устройстве, что и архив системы, то есть, на ленточном устройстве.
Здесь есть, однако, два момента, с которыми надо обходиться очень аккуратно. Первое - это то, что носитель для архива - это, как правило, ленточное устройство, которое по умолчанию при каждой новой записи полностью переписывает свое содержимое. Поэтому при записывании на одно ленточное устройство файла с конфигурацией надо проводить на ленточное устройство без перемотки (обычно имя такого ленточного устройства в ОС Unix заканчивается на символ “n”, например /dev/rmt/0mn). А при последующей записи на эту ленту архива следует использовать это же устройство, но с перемоткой ленты (например, /dev/rmt/0m). Пример скрипта, который будет выполнять запись конфигурационного файла на ленту, а затем дописывать в конец ленты архив базы (при условии, что конфигурационный параметр TAPEDEV установлен в /dev/rmt/0m):
onstat -a > /dev/rmt/0mn ontape -s -L 0
Второй момент - это объем носителя. Если в начало ленточки будет записаны еще и конфигурационные параметры, то реальный объем ленточки, который можно будет использовать непосредственно для хранения архива, естественно, уменьшится. Нужно не забыть зафиксировать это изменением параметра TAPESIZE. Типичный размер выдаваемой командой onstat -a информации составляет около 30 КБт в символьном виде, и, следовательно, выделение под конфигурационные параметры 100-200 КБт заведомо будет достаточным. Учитывая, что типичная емкость ленточки - около 1ГБт, потеря емкости в размере около 0.1% не представляет особых проблем, но приносит существенное удобство - на одном носителе и конфигурация, и, собственно, архив.
Надо сделать еще одно очень важное замечание. Следует иметь два комплекта ленточек для хранения архивов и использовать их “по кругу”. Дело в том, что неприятность (короткое замыкание в компьютере, например) может произойти как раз в тот момент, когда вы делаете архив. И если у вас только один комплект ленточек, то вы потеряете и то, что есть в базе данных сейчас, и то, что есть на ленточке.
Хранить же архивные ленточки следует как можно дальше от компьютера, так как при возникновении пожара или наводнения меньше вероятность того, что погибнет и компьютер, и ленточка. Ну и конечно, следует иметь копию дистрибутива (стандартное лицензионное соглашение разрешает это) и копию ваших прикладных программ.
- 4.5. Упражнения 67
- Глава 6. Устройство Informix Dynamic Server 165
- Глава 7. Эксплуатация информационных систем 177
- Глава 1 Обзор основных архитектур баз данных
- 1.1. Архитектура на основе разделяемых файлов
- 1.2. Архитектура “Хост-терминал”
- 1.3. Архитектура “Клиент-Сервер”
- 1.4. Архитектура с использованием сервера приложений (трехзвенная архитектура)
- 1.5. Упражнения
- Глава 2 Модели данных
- 2.1. Уровни восприятия данных
- 2.2. Иерархическая модель данных
- 2.3. Сетевая модель данных
- 2.4. Реляционная модель данных
- 2.5. Объектно-реляционная модель данных
- Глава 3 Реализация информационных систем на основе продуктов Informix Software
- 3.1. Обзор продуктов Informix
- 3.2. Варианты построения систем
- Internet/Intranet-конфигурация
- 3.3. Выбор оптимальной конфигурации
- Глава 4 Математические основы реляционных субд
- 4.1. Основные понятия
- 4.2. Ключи
- 4.3. Основные операции над таблицами и их интерпретация
- 4.4. Нормализация
- 4.5. Упражнения
- Глава 5 Язык sql
- 5.1. Типы данных, доступные в sql
- 5.3. Основные sql-операторы для доступа и модификации данных
- 5.4. Управление транзакциями
- 5.5. Продвинутые варианты оператора поиска
- 5.5.1. Поиск по нескольким таблицам
- 5.5.2. Устранение повторения данных в операторе select
- 5.5.3. Вычисления внутри оператора select
- 5.5.4. Логические выражения в условии sql-операторов
- 5.5.5. Слияние двух выборок
- 5.5.6. Сортировка выборки
- 5.5.7. Вставка в таблицу нескольких строк одновременно
- 5.6. Использование sql в языках программирования
- 5.7. Программирование сервера базы данных
- 5.7.1. Динамический sql
- 5.7.3. Хранимые процедуры
- 5.7.4. Триггеры
- 5.8. Ограничители (задание целостности на уровне схемы)
- 5.9. Разграничение в sql прав пользователей
- 5.9.1. Права доступа
- 5.9.2. Права на уровне базы данных
- 5.9.3. Права на таблицы
- 5.9.4. Права на хранимые процедуры
- 5.9.5. Кто и как следит за соблюдением прав
- 5.9.6. Механизм ролей
- 5.9.7. Псевдотаблицы (view)
- 5.9.7. Синонимы
- 5.10. Управление одновременным доступом к данным
- 5.10.1. Что бывает, когда несколько человек одновременно пытаются обновить одни и теже данные
- 5.10.2. Открытие базы данных только для себя
- 5.10.3. Блокирование таблицы
- 5.10.4. Механизм блокирования записей и уровни изоляции
- 5.10.5. Управление ожиданием снятия блокировок
- 5.10.6. Тупиковые ситуации
- 5.11. Повышение скорости обработки запросов.
- 5.11.1. Индексы
- 5.11.2. Буферизация журнала транзакций
- 5.11.3. Блокировка на уровне записей и страниц
- 5.11.4. Эффективное построение запросов
- 5.11.5. Сортировка и поиск по коротким полям. Классификаторы
- 5.12. Объектное расширение sql в Informix ds/Universal Data Option
- 5.12.1. Зачем нужна поддержка объектов в серверах бд?
- 5.12.3. Внедрение объектно-ориентированной технологии
- 5.12.4. Реализация объектного подхода в Informix
- Informix ds/Universal Data Option - объектно-реляционная субд
- 5.12.5. Итак…
- Глава 6. Устройство Informix Dynamic Server
- 6.1. Внутренняя архитектура dsa
- 6.2. Механизм хранения данных
- 6.3. Инсталляция продукта
- 6.4. Запуск и останов сервера
- 6.5. Работа с русским языком
- Глава 7. Эксплуатация информационных систем
- Администрирование серверов баз данных
- 7.2. Обеспечение сохранности данных.
- 7.2.1. Технологии постоянного дублирования
- 7.2.2. Архивация
- 7.2.3. Так как же обеспечить сохранность данных?
- 7.3. Архивирование и восстановление данных
- 7.3.1. Что нужно архивировать
- 7.3.2. Утилиты архивации и восстановления
- 7.3.3. Создание архивов утилитой ontape
- 7.3.4. Восстановление из архивов утилитой ontape
- 7.3.5. Как узнать “когда”?
- 7.3.6. Практические советы
- 7.4. Средства контроля за доступом
- 7.4.1 Как работает аудитинг?
- 7.4.2. Конфигурирование списков протоколируемых событий
- 7.4.3. Задание файлов, запуск и остановка механизма аудитинга
- Анализ протокола
- 7.4.5. Практические советы или Что делать, если вы хотите…
- 7.5. Реагирование на чрезвычайные ситуации
- 7.6. Мониторинг текущего состояния сервера базы данных
- 7.6.1. Кто работает с сервером базы данных
- 7.6.2. Сколько памяти использует сервер бд
- 7.6.3. Сколько свободного места имеется у сервера бд
- 7.7. Достижение требуемой производительности
- 7.7.1. Как узнать, что ждет некоторый запрос
- 7.7.2. Как выяснять причины падения производительности
- 2. Общие принципы предлагаемой технологии
- 3. Как портировать приложение