бд. Системауправлениябазами
 Скачать 0.74 Mb.
|
|
Пример 3 BACKUP STOP ALL SINCE '09.07.2002:12:00' UNTIL '09.07.2002:14:00'; Пояснение Будет произведена попытка останова всех запущенных в указанном диапазоне времени асинхронных процессов оперативного архивирования, в том числе и процессов, запущенных другими пользователями СУБД ЛИНТЕР с правами DBA: будут остановлены процессы, у которых время запуска попадает в интервал между 12:00 и 14:00 девятого июля 2002 года. Механизм асинхронного архивирования Асинхронное оперативное архивирование выполняется следующим образом: • пользователь подает SQL-запрос на запуск оперативного асинхронного архивирования БД и сразу получает от ядра СУБД код завершения об успешном/ неуспешном старте процесса; • запуск последующих процессов асинхронного архивирования можно выполнять по одному и тому же соединению с БД, не дожидаясь завершения предыдущих процессов; • в случае успешного старта процесса асинхронного архивирования СУБД сама выделяет ему отдельный канал для работы с БД; • в любом случае (как в случае успешного окончания процесса архивирования, так и неуспешного) этот канал будет корректно закрыт (освобожден) ядром СУБД; • взаимодействие с выделенным процессу архивирования каналом выполняет ядро СУБД при обработке SQL-запросов BACKUP STOP; Пользователь БД имеет возможность в любой момент времени получить информацию о ходе выполнения асинхронного архивирования путем выборки нужных данных из системной таблицы $$$INKERNBACK; например, запросом SELECT * FROM $$$INKERNBACK. При запуске процесса архивирования в эту таблицу добавляется строка, соответствующая данному процессу, которая в течение архивирования будет периодически модифицироваться для отражения текущего статуса процесса. • в поле Status будет помещено значение в процентах (от 0 до 100) о процессе архивации. Структура системной таблицы $$$INKERNBACK: CREATE TABLE $$$INKERNBACK ( © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 71 Оперативное архивирование BackId INTEGER, UserId INTEGER, ChannelId INTEGER, LinterRetCode INTEGER, Status INTEGER, StartTime DATE, EndTime DATE); Описание столбцов таблицы: Столбец Описание BackId Идентификатор процесса архивирования UserId Идентификатор пользователя, подавшего SQL-запрос на оперативное архивирование ChannelId Идентификатор канала, открытого для процесса архивирования (канал, который выделяет само ядро СУБД для порожденного процесса) LinterRetCode Код завершения процесса архивирования (приложение 1 ) Status Число в процентах, отражающее степень завершения процесса архивирования StartTime Дата-время начала процесса архивирования EndTime Дата-время окончания процесса архивирования Если эта таблица существует, то добавляется соответствующая строчка, содержащая необходимые данные. Наличие таблицы проверяется на этапе начального запуска in- kernel backup в асинхронном режиме. В случае её отсутствия будет выведена соответствующая ошибка, и процесс не запустится. Если таблица существует, то в нее добавляется строчка, содержащая BackId, UserId, ChannelId, LinterRetCode равный нулю, т.к. пока он не известен, StartTime и EndTime, где StartTime будет равно EndTime и соответствовать дате-времени старта процесса. По окончании процесса архивации значения LinterRetCode, Status и EndTime, возможно, изменятся в соответствии с действительным кодом завершения процесса, состоянием в процентах и реальным окончанием времени завершения процесса. Все состояния завершения не асинхронных процессов в эту таблицу попадать не будут, т.к. пользователь получает необходимые данные по окончании процесса архивации. Мониторинг процессов асинхронного архивирования Пользователь может в любой момент получить информацию о состоянии процесса оперативного архивирования в статусе прорезервного сохранения путем SQL-запросов: 1 SELECT * FROM $$$INKERNBACK; (всех процессов резервного сохранения, запущенных когда-либо) 2 SELECT * FROM $$$INKERNBACK WHERE BackId = number; (конкретного процесса, где number – идентификатор процесса, возвращенный после успешного старта оного). 72 © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 Оперативное архивирование Возвращенным значением станут данные из этой таблицы, где наиболее интересным будет значение поля Status. Для него возможны следующие варианты: • от 0 до 100 – статус, в процентах, работы процесса резервного сохранения; • 100 – завершение процесса (если значение поля LinterRetCode равно 0, то успешное); • -1 – в случае некорректной или неудавшейся попытки получить статус работающего или завершившегося процесса. Коды завершения СУБД ЛИНТЕР при работе резервного сохранения Код Описание 0 Успешное завершение 6900 Неправильный параметр 6901 LHB процесс активен 6902 LHB процесс не активен 6903 Неправильный объект (отношение, пользователь, последовательность, процедура ...) 6904 Неправильный номер атрибута/таблицы 6906 Не хватает памяти для канала 6907 LHB не стартовал 6908 Нарастающее архивирование: не найден конец в системном протоколе архивирования 6910 Таблица для триггеров не существует 6911 Процедура уже существует 6912 Триггер уже существует 6913 Невозможно добавить тело процедуры 6916 Невозможно прочитать данные из таблицы SERVER 6917 Невозможно прочесть таблицу $$$REPL 6918 Невозможно восстановить сервер 6919 Не удается восстановить правило репликации 6920 Сервер для правила репликации не существует 6931 Таблица $$$INKERNBACK отсутствует в БД 6932 Нарушение прав доступа к архивному файлу 6933 Не могу найти файл архива 6934 Превышен предел количества одновременно открытых файлов 6935 Файл архива уже существует 6936 Невозможно открыть файл архива 6937 Невозможно удалить файл архива 6938 Невозможно произвести запись в файл архива 6939 Асинхронный процесс архивации остановлен пользователем 6940 Запрошен останов конкретного процесса – не могу найти указанный процесс © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 73 Оперативное архивирование Код Описание 6941 У пользователя нет привилегий DBA 6942 Ошибка чтения из таблицы $$$INKERNBACK 6943 Асинхронный процесс архивации уже остановлен 6944 Невозможно прочесть файл архива 6945 Некорректные инкрементные данные в файле архива 6946 Некорректное имя архивного файла 6947 Некорректное имя устройства 6948 Событие принадлежит другому пользователю 74 © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 Приложение 1 Коды завершения утилиты lhb Код Причина 30100 Не могу найти начало ленты 30101 Лента не читается 30102 Ошибка открытия ленты 30103 Ошибка закрытия ленты 30104 Ошибка записи на ленту 30105 Ошибка открытия файла 30106 Нажат Ctrl-Break 30107 Ошибка CRC 30108 Ошибка чтения файла 30109 Ошибка записи в файл 30110 Ошибка удаления файла 30111 Ошибка соединения с БД 30112 Ошибка начала сохранения 30113 Не могу остановить процесс добавления 30114 Не найдена информация о добавлении 30115 Не найдена информация о добавлении 30116 Ошибка запрещения переиспользования системного журнала 30117 Ошибка разрешения переиспользования системного журнала 30118 Ошибка сохранения пользователя 30119 Ошибка сохранения представления 30120 Ошибка сохранения синонима 30121 Ошибка сохранения роли 30122 Ошибка сохранения назначения роли 30123 Ошибка сохранения привилегий 30124 Ошибка сохранения ссылочной целостности 30125 Ошибка восстановления привилегий 30126 Ошибка восстановления пользователя 30127 Ошибка восстановления роли 30128 Ошибка восстановления назначения роли 30129 Ошибка восстановления синонима 30130 Ошибка восстановления ссылочной целостности 30131 Ошибка восстановления представления 30132 Ошибка восстановления таблицы 30133 Ошибка поиска LHB-раздела 30134 Такой файл на ленте уже есть 30135 Ошибка в данных на ленте 30136 Нет маркера 'конец данных' на ленте © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 75 Приложение 1 Код Причина 30137 Слишком старая версия Линтера 30138 Слишком новая версия Линтера 30139 Ошибка переименования файла 30140 Ошибка создания каталога 30141 Ошибка запуска программы 30142 Неизвестный метод сжатия блока 30143 Версия Линтера не совпадает с версией архива 30144 Неверно закодированный блок 30145 Файл не является LHB архивом 30146 Нет памяти 30147 Нет данных на ленте 30148 Ошибка блокирования ленты 30149 Ошибка разблокирования ленты 30150 Невозможно продолжить инкрементный архив 30151 Не найден конец ленты 30152 Инкрементный файл не закончен 30153 Ошибка поиска на ленте 30154 Ошибка установки размера блока на ленте 30155 Ошибка записи маркера файла 30156 Ошибка поиска маркера файла 30157 Функция не поддерживается 30158 Не могу восстановить БД - не совпадает порядок байт 30159 Ошибка сохранения таблицы 30160 Ошибка чтения из устройства ввода 30161 Файл не закончен - корректное восстановление невозможно 30162 Ошибка Линтера 30163 Нет свободного места на диске 30164 Не могу сохранить триггер 30165 Не могу сохранить процедуру 30166 Не могу восстановить триггер 30167 Не могу восстановить процедуру 30168 Программа остановлена пользователем 30169 Ошибка сохранения информации о сервере 30170 Ошибка сохранения правила репликации 30171 Ошибка восстановления информации о сервере 30172 Ошибка восстановления правила репликации 30173 Не могу сохранить событие 30174 Не могу восстановить событие 30175 Ошибка сохранения последовательности 30176 Ошибка восстановления последовательности 76 © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 Приложение 1 Код Причина 30177 Неверные параметры командной строки 30178 Ошибка синтаксиса в скрипте 30179 Ошибка при создании контрольной точки 30180 Ошибка сохранения фразовых индексов 30181 Ошибка сохранения устройств 30182 Контрольная точка не существует в БД 30183 Неверный пароль архива 30184 Ошибка при загрузке сообщений 30185 Ошибка чтения директории © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 77 Приложение 2 Примеры применения утилиты lhb Создание инкрементного архива и его поддержка Необходимо нам это для того, чтобы в течение определенного времени иметь наиболее полный резервный архив БД, но место на жестком диске ограничено, т.е. мы не можем держать сразу несколько копий полностью сохраненной БД. Пример Производим запуск инкрементного сохранения: lhb s -u SYSTEM/MANAGER -f db.lhb -startinc В файле db.lhb будет находиться полностью сохраненная БД, и в самой БД будет установлена контрольная точка, указывающая, с какого места необходимо продолжать инкрементное наращивание. С этого момента все вновь создаваемые файлы журнала также будут оставаться в БД (поэтому, если БД очень быстро разрастается в объеме, то лучше все-таки воспользоваться периодическим полным сохранением БД). Далее, по прошествии определенного времени, нам необходимо дописать к файлу архива те изменения, которые произошли в БД со времени последнего инкрементного архивирования: lhb s -u SYSTEM/MANAGER -f db.lhb -inc Файл следует указывать именно тот, для которого мы начинали инкрементный архив. Утилита проверит соответствие контрольной точки, записанной в файл, той, которая находится в БД, и в случае соответствия допишет в конец файла архива те файлы журнала, которые были добавлены за время от последнего сохранения. Контрольная точка в БД будет обновлена для того, чтобы освободить уже ненужные файлы журнала (они впоследствии в ходе работы ядра будут удалены), и следующее инкрементное архивирование будет уже производиться от момента нашего последнего сохранения. Операцию можно повторять необходимое число раз. Впоследствии при возникновении каких-либо неприятностей можно будет восстановить данные из этого архива. При старте на восстановленной БД ядро произведет запись всех изменений из журнала в БД, и она будет готова к работе. Если резервное сохранение производилось достаточно регулярно, она будет наиболее близка к изначальной. По прошествии определенного (возможно длительного) времени необходимо будет начать новый инкрементный архив БД. Ведь если БД довольно сильно разрослась в объеме за это время, то лучше будет произвести полное или начать новое инкрементное резервное сохранение, т.к. последующее восстановление можно осуществить более быстро, нежели произвести восстановление первоначальной БД и всех накопленных файлов журнала, и предоставить ядру СУБД ЛИНТЕР переносить изменения из файлов журнала в файлы самой БД. При определенных условиях это может потребовать значительного времени. Исходя из всего вышесказанного, прежде чем начать новое инкрементное сохранение, лучше закрыть старое. Пример Если все еще существует файл db.lhb (в который мы накапливали инкрементные изменения), то подаем команду: 78 © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 lhb s -u SYSTEM/MANAGER -f db.lhb -stopinc После чего контрольная точка, соответствовавшая файлу архива, удалится из БД. Никакие новые данные при этом в файл архива сохранены не будут. Дальнейшее инкрементное наращивание этого файла станет невозможным. Другой вариант, как удалить более не используемую контрольную точку (необходимость может возникнуть в случае, если, например, файл архива был поврежден): lhb cp -u SYSTEM/MANAGER -list Результатом будет примерно следующее: Linter On-line BACKUP utility v.4.1.0.870 for RDBMS Linter SQL v. 6.9.0 for Unix Copyright (C) 1990-2013 Relex, Inc. All rights reserved. CP(00): Fri Jul 19 10:18:41.04 2013 BACKUP (LongLived) File: 0 CP(01): Fri Jul 19 10:20:05.19 2013 BACKUP (LongLived) File: 0 Т.е. в БД установлены две контрольные точки, каждая из которых была создана в результате старта инкрементного архивирования. Допустим, что первая из них нами уже не будет использоваться для инкрементного архивирования, и поэтому вполне логично её удалить: lhb cp -u SYSTEM/MANAGER -clear 0 В результате первая контрольная точка удалится, а файлы журнала освободятся, и если они нигде больше не нужны, будут удалены. Создание полного архива БД Преимущества использования метода полного архивирования данных: • наиболее быстрое последующее восстановление БД из файла архива; • сохранение информации о фразовых индексах поддерживается только для полного сохранения; • не используются контрольные точки, и, как следствие, не остаются более не используемые файлы журнала. Недостатки: • относительно длительный процесс архивации; • т.к. БД может достигать значительного размера, то хранение нескольких файлов архива может потребовать немало места; • по вышеуказанным причинам относительно затруднительно вести частое резервное сохранение БД. Поэтому метод, применяемый при резервном архивировании, должен выбираться системным администратором в каждом случае индивидуально. Наиболее оптимальный – комбинирующий методы полного резервного сохранения и инкрементного. Пример Необходимо произвести полное сохранение БД в файл full.lhb, который в свою очередь следует разбить на тома по 650Мб (например, для хранения на CD). Хотелось бы, чтобы утилита не выдавала запрос на создание нового тома и чтобы сохранилась информация об имеющихся фразовых индексах. Подаем следующую команду: © Архивирование и восстановление базы данных. ЗАО НПП «РЕЛЭКС», 1990-2021 79 lhb s -u SYSTEM/MANAGER -f full.lhb -v 650M -qc NV -pi Другой вариант запуска: имеется текстовый файл run.txt, в котором написана эта строка: s -u SYSTEM/MANAGER -f full.lhb -v 650M -qc NV -pi Тогда подаем команду читать параметры из внешнего файла: lhb ef run.txt Результат будет аналогичен предыдущему. Восстановление из полного архива БД При восстановлении не имеет значения, какое было сохранение БД – полное или инкрементное. Ядро СУБД ЛИНТЕР может быть не запущено. Перед восстановлением желательно создать/очистить каталог, в который будет производиться восстановление БД (настоятельно рекомендуется, чтобы восстанавливаемый каталог не был каталогом существующей БД). Также желательно убедиться в наличии свободного места на диске, исходя из того, что его может потребоваться в два-три раза больше, чем занимает сам файл архива, из-за используемой в нем компрессии данных. Пример Подаем команду на восстановление (предположим, что файл архива был разбит на тома, и мы не хотим подтверждать открытие каждого нового тома) в каталог NEW_DB: lhb r -u SYSTEM/MANAGER -f full.lhb -qc NV -p NEW_DB В результате все файлы восстановленной БД будут помещены в каталог NEW_DB. Можно производить запуск ядра СУБД ЛИНТЕР на восстановленной БД. Если восстановленная БД содержала информацию о фразовых индексах, то при старте ядро проанализирует эту информацию и создаст заново необходимые фразовые индексы (что может потребовать определенного времени). Затем БД будет готова к работе. Сохранение и восстановление отдельных объектов БД из архива БД Сохранение отдельных объектов отличается от полного сохранения структурой создаваемого файла архива. При сохранении отдельных объектов файлы журнала не сохраняются. Для восстановления объектов необходимо работающее ядро СУБД ЛИНТЕР на уже существующей БД. Также желательно, чтобы восстанавливаемые объекты отсутствовали в БД. При сохранении объектов сохраняется их структура, а для таблиц также сохраняются данные (если не указан ключ -otwd при сохранении таблиц). Случаи необходимости сохранения и восстановления отдельных объектов БД: • какой-либо из объектов БД очень часто меняется по сравнению с другими (например, таблица), и поэтому её периодическое сохранение более выгодно, чем создание полного архива БД или инкрементного; • для переноса в другую БД некоторых объектов (например, таблиц и их триггеров, пользователей и ролей); • при сильной нехватке свободного места на диске. |