ＤＢのバックアップなどで処理前後のスクリプトを利用している場合、サーバーの再起動後などに行われるデルタ・バックアップでは、（スクリプトの記述内容によっては）処理が失敗することがありえます。この点をご説明します。

どういう挙動?

FastBack Managerでは、下記のようにポリシー定義時に任意のスクリプトを指定できます。

ここで通常バックアップ時（全体・増分）とサーバー再起動後のデルタ・バックアップ時(※1)では起動される回数や順番が異なります。
具体的には、下記のようにサーバー再起動後のデルタバックアップの場合は整合性ポイント前とスナップショット前が2回繰り返され、
一度目のスナップショット後はスキップされます。

順番	通常バックアップ時（全体・増分）	デルタ・バックアップ時(※1)
1	整合性ポイント前	整合性ポイント前
2	スナップショット前	スナップショット前
3	スナップショット後	整合性ポイント前
4	n/a	スナップショット前
5	n/a	スナップショット後

※1...「ポリシー」→「チェックポイントの実行」でもデルタ・バックアップとなりますが、　その場合は上記の表でいう通常バックアップと同じ動きとなります。
　あくまでも「再起動したとき」に行われるデルタ・バックアップのお話です。

何が問題になる？

下記のようにオラクルでコールドバックアップを取るための停止・起動コマンドを定義したとします。

停止スクリプト(OraStop.bat)	開始スクリプト(OraStart.bat)
net stop "OracleOraDb10g_home1TNSListener" net stop "OracleServiceMYDB"	net start "OracleOraDb10g_home1TNSListener" net start "OracleServiceMYDB"

これ、通常時はうまくいくのですがデルタバックアップでは以下のようなシーケンスで実行されることになります。

順番	デルタ・バックアップ時(※1)	オラクルの状態
1	整合性ポイント前	停止コマンド発行(RC=0)
2	スナップショット前	N/A(未使用)
3	整合性ポイント前	再度停止コマンド発行 →停止状態で再度停止しようとしたのでRC≠0→FastBackから見たらエラー
4	スナップショット前	N/A(未使用)
5	スナップショット後	開始コマンド発行(RC=0)

FastBackはスクリプトからのRCが0かどうかでスクリプトの成否を判断します。
その意味で上記は「失敗」であり、ジョブは取り消し状態になってしまいます。
【結果例】

【２回目の停止スクリプトに対するイベント・ログ】

でどうすればいい？

上記のケースは、スキップされる可能性のある「スナップショット後」にスクリプトを指定したので
停止→開始の処理のシーケンスが崩れてしまったのが原因です。
実は、下記のように「スナップショット前」に 開始スクリプトを定義して、停止後すぐにオラクルを開始してしまえばよかったのです。

ただ、お客様がこのような定義をされた理由は容易に想像できます。
なぜなら、従来型の（整合性ポイント機能を持たない）バックアップソフトでコールドバックアップを
採取する場合は更新を予防するために、バックアップが終わるまでプロセスを「止めておく」のが普通だからです。
(プロセスを止めないとバックアップ中にデータが更新される可能性があります｡
もしデータを更新されてしまえば、ファイル中のデータの時点が同じであることが保証されていないので、
バックアップとして使いものにならなくなってしまいます。例えばバックアップに１時間かかるとして、
ある部分は１時間前のデータ、ある部分は直前５分前に更新されたデータ、ではリストアしても使い物になりませんよね。）

FastBackは独自の整合性ポイント機能を持っており、万が一プロセスがデータを更新しても、
整合性ポイント時点のデータをバックアップしてくれるというスゴイ機能を持っています。
ですので、FastBackを使えばオラクルを停止するのは数秒だけでよいのです。
バックアップが終わるまで延々と待つ必要は無く、すぐに業務を開始できます。

(このあたりの動きのご説明はスナップショットの仕組みのご説明のデモやFastbackとコールド・バックアップの記事をどうぞ。）