データベース バックアップのスプラッシュが少ない原因

低スプラッシュ バックアップとは

通常、Backup and DR サービスは、データベースの最初の完全インジェスト バックアップに時間がかかりますが、その後のすべてのバックアップは増分バックアップで、はるかに高速です。増分バックアップは、現在のスナップショットと前のスナップショットのビットマップを比較し、増分変更のみを適用します。

低スプラッシュ バックアップは、前のバックアップ ジョブのシステムエラーが原因で、信頼できないビットマップ イメージになった場合や、ビットマップを読み取ることができない場合に発生する特別なタイプのバックアップ ジョブです。ビットマップを読み取るサービスは、Linux 環境では cbt_server、Windows 環境では AAMService です。

低スプラッシュ バックアップでは、信頼できるビットマップを再作成するために完全な取り込みを再度行う必要があるため、通常の状態で作成されたバックアップよりも時間がかかります。その後、画像全体を置き換えることなく、増分変更を適用できます。

低スプラッシュ バックアップの原因にならないもの

  • コネクタのアップグレード
  • グレースフル システムの再起動
  • バックアップ時にサービスがまだ実行されていることを前提とした、cbt_server または AAMService の正常な再起動
  • 信頼できないビットマップを引き起こすエラーが発生しなかったフェイルオーバー。

信頼できないビットマップの原因

信頼できないビットマップは、次のような原因でバックアップ ジョブが中断された場合に発生します。

  • ホストのクリーンなシャットダウンの失敗
    • 正常なシャットダウンが行われないと、ビットマップの信頼性が低いため、スプラッシュが低下します。これには、物理マシンの電源を切ったり、正常なシャットダウンやブルースクリーン エラーを経ることなく Windows をオフにする方法が含まれます。これは、クラスタ内の 1 台のマシンでブルースクリーン エラーが発生し、フェイルオーバーがトリガーされた場合でも同様です。障害が発生したマシンのビットマップは信頼できないためです。
    • 前回のバックアップ以降にデータベースをホストしていたクラスタ内のすべての Windows サーバーが使用できず、Actifio サービスを実行していない場合。変更を検出するために、前回のバックアップ以降にデータベースをホストした各クラスタホストからビットマップを取得します。すべてのビットマップがない場合、データの整合性を維持するために低スプラッシュを実行する必要があります。データベースをホストしていたクラスタホストが BSOD に遭遇した場合、ビットマップはバックアップ時に使用できる可能性がありますが、信頼できないため、低スプラッシュになります。
  • カーネル モジュールの更新に失敗した
  • ユーザーモード デーモンのクラッシュまたは再起動
  • バックアップの実行中に指紋エラーが発生した。（Backup and DR Service は、各バックアップ ジョブに対して「フィンガープリント チェック」を実行してエラーを確認します）。
  • OS のシャットダウン中にストレージ ディスクがいっぱいになり、システムがすべてのデータを Vault に書き込めない場合、Vault への保存中にエラーが発生します。
  • SAP HANA ノードのフェイルオーバーにより、バックアップが別のノードにリダイレクトされる。
  • カーネル モジュールを読み込めないため、デグレード モードで実行されているバックアップ。これは通常、OS がサポートされていないバージョンの場合に発生します。
  • バックアップ中に cbt_server または AAMService が停止すると、ビットマップを取得できず、バックアップ ジョブは低スプラッシュ モードで実行されます。AAMService が長時間停止していない場合、AAMService を起動すると、通常のバックアップにビットマップを使用できるようになります。
    • cbt_server または AAMService が停止されて、数ギガバイトのイベントがドライバによってキューに追加されるまで時間がかかると、ビットマップを再作成できず、バックアップは低スプラッシュ モードになります。所要時間は、データベースで発生するディスク I/O の量によって異なります。通常、AAMService の停止は数日間必要です。
  • cbt_server または AAMService を正常にシャットダウンしないと、現在読み込まれているビットマップが信頼できなくなる可能性があります。ビットマップは、トラッキング対象のファイルが過去 15 分間に書き込まれた場合に読み込まれるため、通常、負荷の高いデータベースではスプラッシュが低くなります。
  • 追跡対象のファイル（SQL Server の .mdf ファイルなど）を含むボリュームがホストでマウント解除されてから再マウントされた場合、マウント解除中にファイルに書き込まれたものを確認する方法がないため、ビットマップは信頼できません。