null

Настраиваем резервное копирование Sybase ASE средствами NetBackup

Горячее резервное копирование в Sybase ASE (Adaptive Service Enterprise) выполняется двумя специальными SQL-командами - DUMP DATABASE и DUMP TRANSACTION. Если первая, как следует из названия переливает всю базу данных целиком, а вторая - только логи транзакций, то есть создает инкрементальные резервные копии. Эти команды умеют класть дампы на диск или ленту, но после "интеграции" с NetBackup - и на любой его медиа-сервер. Чтобы эту самую интеграцию выполнить, нужно скопировать файл libsysbackup.dll из директории %NetBackup%\DbExt\Sybase в %Sybase%\ASE-15_0\lib. Также нужно убедиться, что запущен внутренний сервис резервного копирования Sybase BCKServer.

Хотя данные команды и позволяют копировать базу данных "на горячую", сам процесс резервного копирования негативно влияет на производительность СУБД, так что проводить его лучше в часы наименьшей нагрузки.

Резервное копирование

Для того, чтобы выполнить резервное копирование базы ASE средствами NetBackup, нужно создать политику на мастер-сервере:

Типом политики нужно сделать "Sybase", в качестве клиента выбрать узел с запущенной на нем СУБД, а вот с расписаний должно быть три:

  • Default-Application-Backup - расписание резервного копирования, инициирумого клиентом (то есть самим Sybase). Создается автоматически, не трогаем его.
  • database_dump - автоматическое расписание дампа всей базы данных. В окна резервного копирования NetBackup вызовает специальный скрипт, который идет в СУБД и ининициирует командочку DUMP DATABASE.
  • transaction_dump - аналогично database_dump но для дампов транзакций


Собственно скрипт, вызываемый расписаниями database_dump и transaction_dump содержится в документации на агента Sybase и на сайте Symantec. Он также есть в дистрибутиве клиента, в директории NetBackup\DbExt\sybase\samples. После некоторой доработки напильником он выглядит так: sybase_mydb_script.cmd (для Windows). Собственно нужно переопределить переменные SYBASE, содержащую путь до бинарных файлов Sybase, SYBSERVER, содержащий имя узла, DATABASE_NAME - имя копируемой базы данных, а в строчке вызова команды isql - поставить правильный пароль от пользователя sa.

В оригинальном скрипте в команде, передаваемой isql был еще и путь до файла статусов: -STAT_FILE %STATUS_FILE%
Однако этот путь был слишком длинным для Sybase, что вызывало такую ошибку:
Msg 103, Level 15, State 9:
Server 'MERCURY', Line 1:
The device that starts with 'sybackup::-SERV nbu.skybird.com -POL sybase-test
-SCHED Test -STAT_FILE C:\Program Files\Veritas\NetBackup\Logs\user_ops\dbext\logs\
sybase_script_status.03212014.152523.2324.3368' is too long. Maximum length is 127.


Я убрал эту опцию из строки резервного копирования, но похоже теперь NetBackup не совсем корректно отслеживает статусы.

Чиним DUMP TRANSACTION

Если с дампом базы данных все довольно просто, то с транзакциями есть один нюанс: Sybase не умеет бекапить транзакции, если они расположены на одном диске с данными. Проверить это можно посредством команды sp_helpdb:
E:\Sybase\ASE-15_0\bin>isql -Usa -Pchangeme
1> sp_helpdb master
2> go
 name   db_size       owner dbid created      durability lobcomplvl inrowlen
         status
 ------ ------------- ----- ---- ------------ ---------- ---------- --------
         ------------------
 master       26.0 MB sa       1 Mar 20, 2014 full                0     NULL
         mixed log and data

(1 row affected)
 device_fragments               size          usage
         created                   free kbytes
 ------------------------------ ------------- --------------------
         ------------------------- ----------------
 master                               26.0 MB data and log
         Mar 20 2014  4:58PM                  14248
 device segment
 ------ ----------
 master default
 master logsegment
 master system
(return status = 0)


Если это так, то нужно разнести логи и данные по разным дискам. Перенос логов базы newtest на диск disk2 будет выглядеть так:

1> use master
2> go
1> sp_dboption newtest, "single user", true
2> go
Database option 'single user' turned ON for database 'newtest'.
Running CHECKPOINT on database 'newtest' for option 'single user' to take
effect.
(return status = 0)
1> sp_dboption newtest, "single user", false
2> go
Database option 'single user' turned OFF for database 'newtest'.
Running CHECKPOINT on database 'newtest' for option 'single user' to take
effect.
(return status = 0)
1> use master
2> go
1> sp_dboption newtest, "single user", true
2> go
Database option 'single user' turned ON for database 'newtest'.
Running CHECKPOINT on database 'newtest' for option 'single user' to take
effect.
(return status = 0)
1> sp_logdevice "newtest", "disk2"
2> go
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.
DBCC execution completed. If DBCC printed error messages, contact a user with
System Administrator (SA) role.
syslogs moved.
The last-chance threshold for database newtest is now 64 pages.
(return status = 0)
1> sp_helpdb newtest
2> go

<...>

 device_fragments               size          usage
         created                   free kbytes
 ------------------------------ ------------- --------------------
         ------------------------- ----------------
 disk1                                 6.0 MB data only
         Mar 25 2014  8:13AM                   2712
 disk2                                 6.0 MB log only
         Mar 25 2014  8:13AM       not applicable


 -------------------------------------------------------------------------------
-------------------------------
 log only free kbytes = 6092

(return status = 0)
1> sp_dboption newtest, "single user", false
2> go
Database option 'single user' turned OFF for database 'newtest'.
Running CHECKPOINT on database 'newtest' for option 'single user' to take
effect.
(return status = 0)


Кроме этого некоторые сегменты логов уже могут находиться на старом диске. Чтобы от них избавиться, нужно создать таблицу, и забить ее пустыми значениями, чтобы сегмент переполнился: http://infocenter.sybase.com/archive/index.jsp?topic=/com.sybase.dc00729_1500/html/errMessageAdvRes/CJAGJGCJ.htm а также выполнить команду dump transaction с опцией with truncate_only (это можно сделать, отредактировав переменную DUMP_OPTS в скрипте).

Восстанавливаемся

Остается только проверить восстановление базы данных. Для начала посмотрим список резервных копий. Это можно сделать через Backup, Archive & Restore Tool, но она не позволяет копировать имена файлов, так что лучше воспользоваться консольной bplist:
c:\Program Files\Veritas\NetBackup\bin>bplist -C mercury -S nbu -t 7 -R /
...
MERCURY.newtest.T.0.3420.25-03-2014.11:49:17:\
MERCURY.newtest.T.0.3580.25-03-2014.11:47:38:\
MERCURY.newtest.D.0.712.25-03-2014.11:46:35:\
...


Здесь mercury - это имя клиента, nbu - мастер-сервер NetBackup, а 7 - тип политики (Sybase). Сами имена резервных копий содержат имя базы данных, а буковки T и D указывают на тип бекапа: TRANSACTION и DATABASE соответственно. Таким образом нам надо последовательно накатить один дамп базы и два бекапа транзакций. Создадим тестовую базу для этого:
1> create database bkptest on disk1 log on disk2
2> go
CREATE DATABASE: allocating 1536 logical pages (6.0 megabytes) on disk 'disk1'
(1536 logical pages requested).
CREATE DATABASE: allocating 1536 logical pages (6.0 megabytes) on disk 'disk2'
(1536 logical pages requested).
Database 'bkptest' is now online.

И восстановим ее из NetBackup:
9> load database bkptest from "sybackup::MERCURY.newtest.D.0.712.25-03-2014.11:6:35 -SERV nbu"
10> go
Backup Server session id is: 8. Use this value when executing the
'sp_volchanged' system stored procedure after fulfilling any volume change
request from the Backup Server.
Backup Server: 4.132.1.1: Attempting to open byte stream device:
'sybackup::MERCURY.newtest.D.0.712.25-03-2014.11:46:35 -SERV nbu::000'
Backup Server: 6.28.1.1: Dumpfile name 'newtest140840A59B' section number 1
mounted on byte stream 'sybackup::MERCURY.newtest.D.0.712.25-03-2014.11:46:35
-SERV nbu::000'
Backup Server: 4.188.1.1: Database bkptest: 4740 kilobytes (38%) LOADED.
Backup Server: 4.188.1.1: Database bkptest: 12294 kilobytes (100%) LOADED.
Backup Server: 4.188.1.1: Database bkptest: 12304 kilobytes (100%) LOADED.
Backup Server: 4.125.1.1: Archive API information for
device='sybackup::MERCURY.newtest.D.0.712.25-03-2014.11:46:35 -SERV nbu::000':
Vendor application name='Veritas NetBackup for SYBASE, Library version=760000,
Message=.
Backup Server: 3.42.1.1: LOAD is complete (database bkptest).
Started estimating recovery log boundaries for database 'bkptest'.
Database 'bkptest', checkpoint=(1539, 16), first=(1539, 16), last=(1539, 20).
Completed estimating recovery log boundaries for database 'bkptest'.
Started ANALYSIS pass for database 'bkptest'.
Completed ANALYSIS pass for database 'bkptest'.
Started REDO pass for database 'bkptest'. The total number of log records to
process is 5.
Redo pass of recovery has processed 1 committed and 0 aborted transactions.
Completed REDO pass for database 'bkptest'.
Use the ONLINE DATABASE command to bring this database online; ASE will not
bring it online automatically.
1> load transaction bkptest from "sybackup::MERCURY.newtest.T.0.3580.25-03-2014.11:47:38 -SERV nbu"
2> go
Backup Server session id is: 12. Use this value when executing the
'sp_volchanged' system stored procedure after fulfilling any volume change
request from the Backup Server.
Backup Server: 4.132.1.1: Attempting to open byte stream device:
'sybackup::MERCURY.newtest.T.0.3580.25-03-2014.11:47:38 -SERV nbu::000'
Backup Server: 6.28.1.1: Dumpfile name 'newtest140840A5DA' section number 1
mounted on byte stream 'sybackup::MERCURY.newtest.T.0.3580.25-03-2014.11:47:38
-SERV nbu::000'
Backup Server: 4.58.1.1: Database bkptest: 12 kilobytes LOADED.
Backup Server: 4.125.1.1: Archive API information for
device='sybackup::MERCURY.newtest.T.0.3580.25-03-2014.11:47:38 -SERV nbu::000':
Vendor application name='Veritas NetBackup for SYBASE, Library version=760000,
Message=.
Backup Server: 3.42.1.1: LOAD is complete (database bkptest).
Started estimating recovery log boundaries for database 'bkptest'.
Database 'bkptest', checkpoint=(1539, 16), first=(1539, 16), last=(1539, 22).
Completed estimating recovery log boundaries for database 'bkptest'.
Started ANALYSIS pass for database 'bkptest'.
Completed ANALYSIS pass for database 'bkptest'.
Started full REDO pass for database 'bkptest'. The total number of log records
to process is 6.
Redo pass of recovery has processed 1 committed and 0 aborted transactions.
Completed REDO pass for database 'bkptest'.
Use the ONLINE DATABASE command to bring this database online; ASE will not
bring it online automatically.
1> load transaction bkptest from "sybackup::MERCURY.newtest.T.0.3420.25-03-2014.11:49:17 -SERV nbu"
2> go
...


Теперь остается только поднять базу в состояние online и убедиться, что тестовые данные пережили наши эксперименты:
1> online database bkptest
2> go
Started estimating recovery log boundaries for database 'bkptest'.
Database 'bkptest', checkpoint=(1539, 32), first=(1539, 31), last=(1539, 32).
Completed estimating recovery log boundaries for database 'bkptest'.
Started ANALYSIS pass for database 'bkptest'.
Completed ANALYSIS pass for database 'bkptest'.
Recovery of database 'bkptest' will undo incomplete nested top actions.
Started UNDO pass for database 'bkptest'. The total number of log records to
process is 2.
Undo pass of recovery has processed 1 incomplete transactions.
Completed UNDO pass for database 'bkptest'.
Database 'bkptest' is now online.
1> use bkptest
2> go
1> select * from test_table
2> go
 id          name
 ----------- --------------------------------
           1 Hello
           2 World
          12 tran2
          13 tran3
          14 tran4
          15 tran5
          16 tran6

(7 rows affected)

К списку статей

 

Интересуюсь по большей части системным анализом программного обеспечения: поиском багов и анализом неисправностей, а также системным программированием (и не оставляю надежд запилить свою операционку, хотя нехватка времени сказывается :) ). Программированием увлекаюсь с 12 лет, но так уж получилось, что стал я инженером.

Основная сфера моей деятельности связана с поддержкой Solaris и оборудования Sun/Oracle, хотя в последнее время к ним прибавились технологии виртуализации (линейка Citrix Xen) и всякое разное от IBM - от xSeries до Power. Учусь на кафедре Вычислительной Техники НИУ ИТМО.

See you...out there!

http://www.facebook.com/profile.php?id=100001947776045
https://twitter.com/AnnoyingBugs