Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
NaotoSakai
Advisor
Advisor

はじめに


以前にSAP SQL Anywhereのバックアップ方法についての記事を書きました。その中でバックアップの管理が重要ということに触れましたが、それに関して補完するものをご紹介したいと思います。



バックアップの管理


以前のおさらいです。

バックアップの際にログのトランケートを行わないとログの量が増え、バックアップに長時間かかるようになります。そのためいつかはログのトランケートを行わなければなりません。しかしトランケートを行った場合、インクリメンタルバックアップは「差分」ですのでその前のバックアップがないとリカバリーが不可能になります。



仮にこの様なスケジュールでバックアップを取得していた場合で、
このように土曜日18:00のバックアップ後にマシンが破損し、バックアップからのリカバリーが必要になった場合、赤で囲ったバックアップが必要になります。一つでも欠けると最新である土曜日18:00のバックアップが適用できなくなるのです。
そのため、バックアップを取得することは勿論、バックアップファイルの管理も重要となります。



管理を難しくする要素


管理を難しくする要素の一つに、SAP SQL Anywhere自体のバックアップ出力があります。
SQL Anywhereのバックアップ(イメージバックアップ)は






    • データベースファイルのバックアップ

      • 使用しているデータベースファイルと同一名で出力されます。



    • ログファイルのバックアップ

      • 使用しているログファイルと同一名で出力されます。

      • -n、あるいはTRANSACTION LOG RENAME MATCHを付与することによりyyyymmddxx.log形式で出力できるが、xxは時刻を表さない。



    • 同一名のファイルがバックアップ出力先に存在すると上書きされてしまう




という形で出力されます。



便利なスクリプト


このようにファイルの管理に注意が必要です。それを若干ですが簡単にするスクリプトを紹介します。



CREATE PROCEDURE "fullbackuptruncate"()
BEGIN
DECLARE backup_dir LONG VARCHAR;
DECLARE timestamptext CHAR(20);
SET timestamptext = DATEFORMAT( current timestamp, 'yyyymmddhhnnss' );
//バックアップ先は適宜変更してください。
SET backup_dir = 'd:\\backups\\' || timestamptext;

// Full backup + log trancate
BACKUP DATABASE DIRECTORY backup_dir TRANSACTION LOG TRUNCATE;

END;

CREATE PROCEDURE "inclbackup"()
BEGIN
DECLARE backup_dir LONG VARCHAR;
DECLARE timestamptext CHAR(20);
SET timestamptext = DATEFORMAT( current timestamp, 'yyyymmddhhnnss' );
//バックアップ先は適宜変更してください。
SET backup_dir = 'd:\\backups\\' || timestamptext;

// Incremental backup
BACKUP DATABASE DIRECTORY backup_dir TRANSACTION LOG ONLY;

END;

CREATE PROCEDURE "inclbackuptruncate"()
BEGIN
DECLARE backup_dir LONG VARCHAR;
DECLARE timestamptext CHAR(20);
SET timestamptext = DATEFORMAT( current timestamp, 'yyyymmddhhnnss' );
//バックアップ先は適宜変更してください。
SET backup_dir = 'd:\\backups\\' || timestamptext;

// Incremental backup + log trancate
BACKUP DATABASE DIRECTORY backup_dir TRANSACTION LOG ONLY TRANSACTION LOG TRUNCATE;

END;

これはストアドプロシジャです。それぞれ「フルバックアップ+ログトランケート」「インクリメンタルバックアップ」「インクリメンタルバックアップ+ログトランケート」を行うものですが、出力先を見てもらうとわかるように「yyyymmddhhnnss」という日時を名称にしたディレクトリに出力されます。バックアップ先に指定したディレクトリは存在しない場合作成されます。これを利用するとこのように毎回出力先を変更してバックアップを出力する事ができます。


実行する場合は下記のようにInteractive SQLなどからCALL文経由で実行することになります。



また、管理を考えた場合で、ログトランケートする場合はディレクトリ名末尾に「T」などわかるようにするというのも実践的です。例として挙げている例では「フルバックアップ+ログトランケート」「インクリメンタルバックアップ」「インクリメンタルバックアップ+ログトランケート」の3種類ですが、BACKUP DATABASE文を変更して必要なバックアップスクリプトを作成するようにしてください。



この例の場合、「本日分を除き末尾にTがついていないディレクトリは無条件に削除しても良い」という運用にすることもできます。古いバックアップを削除するバッチを書く際にも書きやすくなるでしょう。


 

自動バックアップ


上記のサンプルスクリプトは何故プロシジャとして記述したのか疑問かもしれません。これはSAP SQL Anywhereの「スケジュール機能」を利用するためです。この機能はSQL Anywhere自体が決められた時刻に事前に定義していた動作を実行するという機能です。OSもクーロンやタスクスケジューラー等同機能のものが含まれていますが、組み込みのスケジュール機能はSQL Anywhere単体で動作しますのでOS側、あるいはスケジューラーソフトウェアの方の設定やインストールは必要ありません。スケジュール機能は「SQL Anywhereが動作しているときのみ動作」という事に気をつければ非常に便利です。


スケジュールは以下のようにCREATE EVENT文で設定します。これは上記のバックアップスケジュール例






    • 日曜日0:00からフルバックアップ+ログトランケート

    • 毎日4:00、12:00、15:00、17:00、21:00にインクリメンタルインクリメンタルバックアップ

    • 平日0:00にインクリメンタルバックアップ+ログトランケート




の場合で、先に挙げたプロシジャを使用してスケジューリングしてみました。




CREATE EVENT "DBA"."fullbackup"
SCHEDULE START TIME '00:00' ON ( 'Sunday' )
HANDLER
BEGIN
CALL "DBA"."fullbackuptruncate"();
END;

CREATE EVENT "DBA"."inclbackup1"
SCHEDULE START TIME '04:00' ON ( 'Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday' )
HANDLER
BEGIN
CALL "DBA"."inclbackup"();
END;

CREATE EVENT "DBA"."inclbackup2"
SCHEDULE START TIME '12:00' ON ( 'Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday' )
HANDLER
BEGIN
CALL "DBA"."inclbackup"();
END;

CREATE EVENT "DBA"."inclbackup3"
SCHEDULE START TIME '15:00' ON ( 'Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday' )
HANDLER
BEGIN
CALL "DBA"."inclbackup"();
END;

CREATE EVENT "DBA"."inclbackup4"
SCHEDULE START TIME '17:00' ON ( 'Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday' )
HANDLER
BEGIN
CALL "DBA"."inclbackup"();
END;
CREATE EVENT "DBA"."inclbackup5"
SCHEDULE START TIME '21:00' ON ( 'Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday' )
HANDLER
BEGIN
CALL "DBA"."inclbackup"();
END;

CREATE EVENT "DBA"."incl_t_backup"
SCHEDULE START TIME '00:00' ON ( 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday' )
HANDLER
BEGIN
CALL "DBA"."inclbackuptruncate"();
END

スケジューリングは「XX時間ごと」という一定間隔の設定は出来るのですが、「4:00、12:00、15:00、17:00、21:00」のような不規則間隔のできませんのでインクリメンタルバックアップのスケジュールは5つに分けて定義しています。


CREATE EVENT文だけではなくGUIによるイベント作成ウィザードでもイベントの設定が可能です。





使い所とまとめ


 このようにSQL Anywhereの機能を組み合わせることで「放っておいても自動バックアップ」するシステムを作ることができます。なんと言ってもOSに依存せずスケジュールを仕掛けられるところは便利なのではないでしょうか?このスケジュール設定はデータベースファイル内に記述されます。つまりはSQL Anywhereの特性の一つである「データベースファイルはOSに依存しない」を組み合わせると、設定済みのデータベースファイルを配るだけでどんなOSでも自動でバックアップができることになります。(バックアップ先の変更が必要でしょうが。)


 ただし、このままですと取得したバックアップがどんどん増えていくことになります。「バックアップ先のディレクトリからある一定期間経過したバックアップは削除するという処理」も追加すると更に自動運転に近づきます。チャレンジしてみてください。