SYBASE8 (988810), страница 6

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

Текст из файла (страница 6)

REMOTE_BKP_SERVER

Если в качестве диски дампирования/восстановления БД используется лента, то часто необходимо указывать ее характеристики: плотность, размер блока и объем копии (хотя лучше использовать значения этих характеристик по умолчанию в ваших системах).

Характеристика плотности имеет смысл только при дампировании в открытых VMS-системах. Необходимо правильно указать значение плотности для вашего лентопротяжного диски. Плотность может принимать следующие значения: 800, 1600, 6250, 6666, 10000, 38000. Характеристика плотности не указывается при восстановлении с ленты в открытых VMS-системах, а также при дампировании/восстановлении в системах UNIX и PC.

Пример: density=6250

Значение длины блока, как правило, равно размеру одной страницы БД (для большинства систем 2048 байт). В открытых VMS-системах размер блока определяется только при дампировании и имеет значение 16384. В системах UNIX размер блока определяется и при дампировании, и при восстановлении, при этом значения размеров блоков и там и там должны совпадать.

Пример: blocksize=2048

Характеристика объема копии указывается при дампировании. В открытых VMS-системах дамп, по умолчанию, пишется до обнаружения физического маркера конца ленты, после чего выдается сообщение о замене ленты. В UNIX-системах этого нет, поэтому необходимо указывать количество килобайт для дампа на ленте.

Пример: capacity=1024

Для определения имени ленты используется опция dumpvolume=<имя тома>. С помощью команд dump database и dump transaction имя тома записывается в качестве метки ленты. Команды load database и load transaction проверяют эту метку, и если имена томов не совпадают, то выдается сообщение об ошибке.

При дампировании БД или журнала транзакций сервер копирования создает, по умолчанию, имя файла дампирования путем конкатенации следующих символов:

1) последние 7 символов имени БД;

2) 2 цифры года;

3) 3-х цифровой номер для дня года (1¸366);

4) количество секунд, прошедших с полуночи, в шестнадцатиричной системе счисления.

Можно изменить это имя, указав опцию file=<имя файла>. Имя файла не должно превышать 17 символов.

Пример имени файла дампирования журнала транзакций БД publications (без указания опции file):

cations930590E100

Если при снятии дампа или при восстановлении требуется определить целое множество томов дампирования, то необходимо использовать структуру stripe on для определения имени и характеристик каждого диски. В команде дампирования/восстановления БД можно использовать до 31 структуры stripe on (т.е. максимум 32 тома дампирования).

Примеры (использования трех томов для дампирования и двух томов для восстановления):

1) в системе UNIX:

dump database pubs2 to "/dev/nrmt0"

stripe on "/dev/nrmt1"

stripe on "/dev/nrmt2"

load database pubs2 from "/dev/nrmt0"

stripe on "/dev/nrmt1"

2) в системе VMS:

dump database pubs2 to "MTA0:"

stripe on "MTA1:"

stripe on "MTA2:"

load database pubs2 from "MTA0:"

stripe on "MTA1:"

После восстановления БД с двух лент оператору придет сообщение установить третью ленту.

Для определения особой ситуации на ленте в структуре with команд дампирования/восстановления можно использовать следующие опции:

1) nodismount/dismount (только для VMS)

nodismount необходима для поддержки готовности ленты к созданию дополнительных дампов или восстановлений (не размонтировывается лента после первого дампирования/восстановления);

2) nounload/unload

unload перематывает в начало и разгружает ленту после дампирования/восстановления;

3) retaindays = <количество дней> - защищает файлы от перезаписи в течение указанного количества дней;

4) noinit/init

init переинициализует ленту перед выполнением дампирования.

Примеры инициализации двух томов перед дампированием нового журнала транзакций:

1) в системе UNIX:

dump transaction pubs2

to "/dev/nrmt0"

stripe on "/dev/nrmt1"

with init

2) в системе VMS:

dump transaction pubs2

to "MTA0:"

stripe on "/dev/nrmt1"

with init

Сообщения о том, как идет процесс дампирования и о смене лент, по умолчанию, посылаются оператору. В опции notify структуры with можно отменить сообщения систем по умолчанию.

В системах VMS для отмены посылки сообщений оператору (например: посылать сообщения на другие терминалы) необходимо задать notify = client.

В системах UNIX, по умолчанию, сообщения посылаются клиенту, и для изменения этого необходимо указать notify = operator_console.

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

Опция with no_truncate в команде dump transaction позволяет копировать журнал транзакций после сбоя БД. При этом для определения физического местонахождения журнала используются указатели из системных таблиц sysdatabases и sysindexes. Это может быть использовано только в том случае, когда журнал транзакций расположен в отдельном сегменте и доступна БД master.

Замечание. Никогда не используйте опцию with no_truncate для активной БД.

Если журнал транзакций БД расположен не в отдельном сегменте, то нельзя использовать команду dump transaction для копирования журнала и последующего уничтожения его. Для таких БД необходимо:

1. для уничтожения журнала использовать опцию with truncate_only команды dump transaction;

2. для копирования БД, включающую журнал, использовать команду dump database.

Пример копирования БД mydb, включая журнал, который затем уничтожается:

dump database mydb to mydevice

dump transaction mydb with truncate_only

В случае переполнения журнала по памяти для его дампирования необходимо использовать опцию with no_log в команде dump transaction.

Замечание. После выполнения команды dump transaction с опцией with truncate_only или с опцией with no_log нет способа восстановления транзакций, выполненных со времени снятия последнего дампа.

Реакция на запросы о замене лент(томов)

В системах VMS сообщение о готовности следующей ленты дампирования посылается с помощью команды REPLY, а в системах UNIX и РС используется системная процедура sp_volchanged.

Синтаксис запуска этой системной процедуры:

sp_volchanged <идентификатор сеанса>,<имя диска>,

<действие> [,<имя файла>[,<имя тома>]]

Параметры <идентификатор сеанса> и <имя диска> определяют запрос на смену тома.

Параметр <действие> определяет одно из трех действий:

1) abort - прервать выполнение дампирования/восстановления;

2) proceed - продолжить дампирование/восстановление;

3) retry - перезапустить дампирование/восстановление.

Параметр <имя файла> определяет файл, который должен быть восстановлен. Если этот параметр не указывается, то сервер копирования восстановит первый файл на ленте.

Параметр <имя тома> определяет метку ленты, т.е. при дампировании эта метка записывается на ленту, а при восстановлении - проверяется. Если этот параметр не указывается, то используется имя тома, указанное в командах dump и load.

Восстановление БД

Восстановление вышедшей из строя БД включает следующие шаги:

1. Получить дамп текущего журнала транзакций каждой БД на диске.

2. Посмотреть объем памяти, используемой каждой БД на диске.

3. Уничтожить все БД.

4. Уничтожить сбойный диск.

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

6. Пересоздать все БД по одной.

7. Защитить каждую БД от пользователей.

8. Восстановить каждую БД с наиболее "свежего" дампа.

9. Восстановить с дампов каждый журнал транзакций в порядке их создания.

Первый шаг осуществляется с помощью команды dump transaction with no_truncate для каждой БД на сбойном диске. Например, получить дамп журнала БД mydb:

dump transaction mydb

to "/dev/nrmt0" at REMOTE_BKP_SERVER

with init, no_truncate,

notify = "operator_console"

Получение информации об объеме памяти выполняется либо запросом в БД master, либо запуском системной процедуры sp_helpdb:

1) select segmap, size from sysusages

where dbid = db_id ("<имя БД>")

В поле segmap выдаются значения: 3, 4 и 7. Значение 3 означает, что память отводится под данные; 4 - память отводится под журнал; 7 - данные и журнал находятся на одном диске. В поле size указывается количество блоков размером 2К. Чтобы получить объем памяти в Мб, надо разделить значение size на 512.

2) sp_helpdb <имя БД>.

Третий шаг осуществляется командой drop database, выполняемой для каждой БД. Если при этом выдаются системные ошибки, необходимо выполнить команду dbcc dbrepair с опцией dropdb, например:

dbcc dbrepair (mydb, dropdb)

Уничтожение сбойного диска выполняется системной процедурой sp_dropdevice.

Инициализация новых дисков осуществляется командой disk init.

Пересоздание всех БД по одной осуществляется командой create database. Если не удалось получить информацию об объеме памяти каждой БД, то можно использовать create database с опцией for load для создания новой, как правило большей по объему памяти, БД.

Пример пересоздания БД mydb:

1) create database mydb

on datadev1=20,

datadev2=10

log on logdev1=10

for load

2) расширение дисковой памяти для данных и журнала БД mydb

alter database mydb on datadev3=2 for load

alter database mydb log on logdev2=4 for load

Защита БД от внесения изменений в них пользователями на то время, пока они не восстановлены, выполняется с помощью использования системной процедуры sp_dboption для установки опций nо chkpt on recovery, dbo use only и read only в значения TRUE.

Восстановление всех БД осуществляется командой load database, выполненной для каждой БД.

Восстановление журналов транзакций выполняется командой load transaction в той же последовательности, в которой были созданы дампы журналов. Последним восстанавливается текущий журнал.

По окончании восстановления БД необходимо проверить целостность БД командами dbcc, а также снять защиту с БД, установив процедурой sp_dboption опции nо chkpt on recovery, dbo use only и read only в значения FALSE.

Дампирование и восстановление системных БД

Во время работы с БД могут выйти из строя системные БД: master и sybsystemprocs.

Для дампирования БД master лучше всего иметь отдельную ленту. Восстановить БД master необходимо в двух случаях:

1) вышла из строя БД, но диск с БД master остался невредим;

2) вышел из строя диск с БД master.

Таблицы в БД master управляют всеми функциями SQL-сервера, всеми БД и всеми дисками данных, поэтому процесс восстановления БД master состоит из:

1) восстановления БД master на время после ее инсталляции;

2) восстановления БД master на время ее последнего дампирования;

3) выполнения специальных процедур для восстановления изменений на дисках и в БД, сделанных после последнего дампирования.

Рассмотрим процесс восстановления БД master более подробно. Системный администратор должен выполнить следующие действия:

1. Сделать распечатки системных таблиц, необходимых для восстановления дисков, БД и входных имен.

2. Если на диске с БД master есть другие БД и они доступны, то выполнить их дампирование с помощью команды dump database.

3. Выполнить процедуру buildmaster для построения новой БД master или диска для БД master.

4. Командой startserver перезапустить SQL-сервер в режиме одного пользователя.

5. Если ваша БД master занимает больше 3 Мб, то необходимо пересоздать ее характеристики в sysusages. Размер БД master может увеличиваться командами alter database или расширениями SQL-сервера, требующими увеличения БД master.

6. Если имя в сети вашего сервера дампирования не SYB_BACKUP, необходимо изменить это имя в sysservers.

7. Проверить, что сервер дампирования запущен.

8. Для восстановления БД master выполнить команду load database, используя самый "свежий" дамп БД.

9. Вновь перезапустить SQL-сервер в однопользовательском режиме с помощью команды startserver.

10. Если появились добавочные диски БД со времени выполнения последнего дампирования, то необходимо выполнить команду disk reinit для пересоздания sysdevices.

11. Если со времени последнего дампирования выполнялись команды disk reinit или create database или alter database, то сделать распечатки sysusages и sysdatabases, а затем выполнить команду disk refit для пересоздания этих системных таблиц.

Характеристики

Список файлов учебной работы