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

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

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

dbcc checkcatalog (testdb)

4. ddcc checkalloc [(<имя БД> [,fix | nofix])]

Эта команда проверяет для указанной БД следующее:

• все ли страницы правильно распределены;

• нет ли распределенных страниц, которые не используются;

• нет ли используемых страниц, которые не распределены.

Команда dbcc checkalloc выдает информацию об объеме памяти - распределенном и используемом.

Опция fix используется, когда БД запущена в однопользовательском режиме командой:

sp_dboption <имя БД>, "single user", true

Опция nofix используется по умолчанию.

5. dbcc tablealloc ({<имя таблицы> | <идентификатор таблицы>}

[{, full | optimized | fast | null}

[,fix | nofix]])

Эта команда осуществляет аналогичный контроль, что и команда dbcc checkalloc, но для одной таблицы (<идентификатор таблицы> берется из колонки id таблицы sysobjects).

По этой команде выдается три типа отчета: full, optimized и fast.

1) full - полный отчет по всем типам ошибок распределения (по аналогии с отчетом по команде dbcc checkalloc, только для таблицы);

2) optimized - в этот отчет входит информация о распределении страниц, перечисленных только в области распределения страниц для объекта (таблицы);

3) fast - отчет содержит информацию о страницах, которые связаны с экстентом, но не распределены в нем.

6. dbcc indexalloc ({<имя таблицы> | <идентификатор таблицы>},

index_id [,{full | optimized | fast | null}

[,fix | nofix]])

Эта команда осуществляет аналогичный контроль, что и команда dbcc checkalloc, но только для индекса и также может выдавать аналогичные три типа отчета (как в команде dbcc tablealloc).

7. dbcc dbrepair (<имя БД>, dropdb)

По этой команде уничтожается сбойная БД, так как команда drop database на сбойной БД не работает.

8. dbcc reindex ({<имя таблицы> | <идентификатор таблицы>})

По этой команде контролируется целостность индексов для пользовательских таблиц.

9. dbcc fix_text ({<имя таблицы> | <идентификатор таблицы>})

По этой команде расширяются значения типа text после преобразования множества символов SQL-сервера в мультимножество символов.

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

Для сохранения всех изменений в БД SQL-сервер использует транзакции. Каждая БД имеет свой собственный журнал транзакций, системную таблицу syslogs. Каждая транзакция, выполненная любым пользователем, автоматически записывается в журнал транзакций. После того как все изменения внесены в журнал, они перезаписываются в кеш-копию страницы данных. Страница данных остается в оперативной памяти (кеш-копии) до тех пор, пока не потребуется другая страница данных. В это время, эта страница записывается на диск данных.

Если выполнение оператора в транзакции закончилось неудачей, то SQL-сервер отменяет все изменения, сделанные этой транзакцией. SQL-сервер вносит в журнал специальную запись "конец транзакции" при каждом завершении любой транзакции, записывая при этом статус транзакции (успех или неудача).

SQL-сервер использует механизм контрольных точек для синхронизации БД и ее журнала. Контрольная точка записывает все страницы, которые были изменены в оперативной памяти, но не были записаны на диск со времени создания последней контрольной точки, на диск БД. Это обеспечивает восстановление БД после сбоя системы за очень короткое время.

Каждый раз, когда перезапускается SQL-сервер, например после сбоя системы или использования команды shutdown, он автоматически выполняет множество восстановительных процедур для каждой БД.

При этом сравнивается каждая БД со своим журналом транзакций. Если запись об изменении в БД занесена в журнал позже, чем в страницу данных БД, то это изменение переносится из журнала в БД. Если сбой системы прервал транзакцию (она выполнилась не до конца), то все изменения, сделанные этой транзакцией, отменяются.

После загрузки сервера для восстановления БД выполняется следующее:

1) восстановление БД master;

2) восстановление sybsecurity;

3) восстановление БД model;

4) восстановление БД tempdb (копирование БД model);

5) восстановление sybsystemprocs;

6) восстановление пользовательских БД в последовательности, указанной в sysdatabases.dbid.

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

Команда dump database делает копию, включающую и данные, и журнал транзакций. Дампы с помощью этой команды выполняются динамически, т.е. пользователи могут продолжать работать с БД во время дампирования.

Команда dump database выполняется за три фазы. О выполнении каждой фазы система выдает соответствующую запись.

Команда dump transaction (сокращенно: dump tran) делает копию журнала транзакций. В эту копию входят все изменения, сделанные со времени последнего дампирования БД или журнала, а предыдущие изменения уничтожаются.

Для выполнения команды dump transaction требуется меньше времени и памяти, чем для полной копии БД. Эта команда выполняется только в том случае, если журнал транзакций БД расположен в отдельном сегменте.

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

Для восстановления БД с дампа необходимо использовать команду load database. Восстановить БД можно на "старое" место или создать новую БД с опцией for load. Восстановление БД осуществляется в однопользовательском режиме, т.е. никакие другие пользователи в это время не могут работать с БД.

После восстановления БД необходимо восстановить журнал транзакций с помощью команды load transaction (сокращенно: load tran). В промежутке между вводом команд load database и load tran нельзя вводить никаких команд, иначе команда load tran не выполнится.

Опции команды dump tran

Если данные и журнал БД находятся в одном сегменте, то команда dump transaction with truncate_only уничтожает журнал, а команда dump database копирует БД, включая журнал. Если не было восстановления более ранних транзакций, то команда dump transaction with truncate_only уничтожает журнал, а команда dump database копирует только БД. Если дампирование журнала закончилось неудачей из-за нехватки памяти для журнала, то команда dump transaction with no_log уничтожает журнал без записи этого события, а команда dump database сразу же копирует БД, включая журнал.

Пример 1: процесс дампирования и восстановления БД, если вышел из строя диск данных.

1) Понедельник, 16.30 - создание БД (create database).

2) Понедельник, 17.00 - дампирование БД (dump database) на ленту 1 (180 Мб).

3) Вторник, 10.00 - дампирование журнала (dump transaction) на ленту 2 (45 Мб).

4) Вторник, 12.00 - дампирование журнала (dump transaction) на ленту 3 (45 Мб).

5) Вторник, 14.00 - дампирование журнала (dump transaction) на ленту 4 (45 Мб).

6) Вторник, 16.00 - дампирование журнала (dump transaction) на ленту 5 (45 Мб).

7) Вторник, 17.00 - дампирование БД (dump database) на ленту 6 (180 Мб).

8) Вторник, 18.00 - сбой диска данных!

9) Вторник, 18.15 - дампирование журнала (dump transaction with no_truncate)
на ленту 7.

10) Вторник, 18.20 - восстановление БД (load database) с ленты 6.

11) Вторник, 18.35 - восстановление журнала (load transaction) c ленты 7.

Пример 2: процесс дампирования и восстановления БД, если вышел из строя диск данных и оператор не успел снять дамп с БД перед этим.

1) Понедельник, 16.30 - создание БД (create database).

2) Понедельник, 17.00 - дампирование БД (dump database) на ленту 1 (180 Мб).

3) Вторник, 10.30 - дампирование журнала (dump transaction) на ленту 2 (45 Мб).

4) Вторник, 12.00 - дампирование журнала (dump transaction) на ленту 3 (45 Мб).

5) Вторник, 14.00 - дампирование журнала (dump transaction) на ленту 4 (45 Мб).

6) Вторник, 16.00 - дампирование журнала (dump transaction) на ленту 5 (45 Мб).

7) Вторник, 16.30 - сбой данных, дампирование в 17.00 не состоялось.

8) Вторник, 17.15 - дампирование журнала (dump transaction with no_truncate)
на ленту 6 (45 Мб).

9) Вторник, 17.20 - восстановление БД (load database) с ленты 1.

10) Вторник, 17.35 - восстановление журнала (load transaction) с ленты 2.

11) Вторник, 17.40 - восстановление журнала (load transaction) с ленты 3.

12) Вторник, 17.45 - восстановление журнала (load transaction) с ленты 4.

13) Вторник, 17.50 - восстановление журнала (load transaction) с ленты 5.

14) Вторник, 17.55 - восстановление журнала (load transaction) с ленты 6.

Для дампирования и восстановления БД можно использовать не только ленты, но и серверы дампирования (backup server). Во время дампирования может потребоваться замена ленточного тома (копия БД не умещается на 1 том). Это выполняется с помощью процедуры sp_volchanged.

Для запуска сервера дампирования используется утилита startserver, а для его останова - команда shutdown. Информацию о дисках-дампах можно получить с помощью запроса:

select * from master..sysdevices

where status=16 or status=24

Для добавления диска-дампа используется процедура:

sp_addumpdevice {"tape" | “disk”}, <имя диска>,

<физическое имя>, <размер>

Дампирование БД master осуществляется после каждого изменения в этой БД. Эти изменения выполняются следующими командами и системными процедурами:

1) disk init, sp_addumpdevice, sp_dropdevice;

2) все команды копирования дисков;

3) сегментые процедуры: sp_addsegment, sp_dropsegment и sp_extendsegment;

4) create procedure и drop procedure;

5) sp_logdevice;

6) sp_configure;

7) create database и alter database.

Кроме этого, необходимо иметь копии системных таблиц: sysdatabases, sysusages, sysdevices и syslogins. И наконец, необходимо снять дамп с журнала транзакций БД master.

Аналогичным образом необходимо позаботиться о БД model и sybsystemprocs.

Копирование и восстановление пользовательских БД

Для команд дампирования и восстановления БД необходимы имя БД и диск (лента) дампирования. Кроме этого, в эти команды необходимо включать следующие опции:

1) at <имя сервера> - определение удаленного дампа-сервера;

2) density, blocksize, capacity - определение характеристик ленты;

3) dumpvolume - определение имени ленты;

4) file = <имя файла> - определение имени файла, который дампируется/восстанавливается;

5) stripe on <имя диска> - определение добавочных дисков дампирования;

6) dismount, unload, init, retaindays - определение особой ситуации на ленте;

7) notify - определение сообщений, посылаемых клиенту или оператору во время начала дампирования/восстановления.

Имя БД может быть определено как литерал или как локальная переменная или как параметр хранимой процедуры.

Для определения диска (ленты) дампирования необходимо руководствоваться следующими правилами:

1) определение имени диска (ленты) как литерала, локальной переменной или параметра хранимой процедуры;

2) нельзя дампировать или восстанавливать БД с "null" диска (ленты);

3) при дампировании (восстановлении) БД для определения диска (ленты) можно использовать:

а) полный путь;

б) относительный (неполный) путь;

в) имя логического диски из системной таблицы sysdevices;

4) при дампировании/восстановлении БД в сети:

а) необходимо задать полный путь к диску дампирования (нельзя использовать
неполный путь или имя диска из таблицы sysdevices);

б) полный путь должен быть допустим на машине, на которой работает сервер
дампирования;

в) если имя включает специальные символы, цифры или знак подчеркивания
(_), то его необходимо заключить в кавычки.

Примеры:

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

dump database pubs2 to "/dev/nrmt4"

load database pubs2 from "/dev/nrmt4"

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

dump database pubs2 to "MTA0:"

load database pubs2 from "MTA0:"

Примеры: дампирования/восстановления БД на удаленном сервере дампирования (в системе UNIX): dump database pubs2 to "/dev/nrmt0" at REMOTE_BKP_SERVER

load database pubs2 from "/dev/nrmt0" at

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

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