SAP システムの移行でダウンタイムを削減する方法について

はじめに

本稿は、SAP システム移行プロジェクトの提案者、BASIS 担当者向けの内容となっております。
参考になれば幸いです。

昨今、SAP システムをオンプレミスからパブリッククラウドの IaaS に移行するプロジェクトが増えております。このような移行プロジェクトでよく課題となるのはダウンタイムです。このため、ダウンタイムを削減するために様々な対策を検討をされると思います。

今回は私が SAP システムの移行作業で経験した、ダウンタイム中のデータ転送量を減らすことで、ダウンタイムを削減する有効な方法をご紹介したいと思います。この方法は、オンプレミスとパブリッククラウド間のネットワーク帯域が狭い場合、特に有効となると思います。

SAP システムの移行

主な作業は、

システムコピー (ソースシステム)
移行データを準備します。
データ転送 (ソース＆ターゲットシステム)
移行データをソースシステムからターゲットシステムに転送します。
システムコピー (ターゲットシステム)
移行データを取り込みます。

になります。

システムがサービスを提供している時間を｢アップタイム｣と呼び、提供していない時間は｢ダウンタイム｣と呼びます。
移行データの準備とは、データベース内にあるデータを抽出 (エクスポート) すること、バックアップすることを指しています。
移行データの取込とは、移行データをデータベースに取込 (インポート) すること、リストアすることを指しています。
本稿ではデータベースのみを移行データとして扱います。
(データベース以外の移行データについては本稿の対象外とします。)

システムコピーの方式

システムコピーの方式は、大きく2つに分類されます。

一つはオペレーションシステム/データベースプラットフォームに依存しない R3load/Jload を利用した標準的な方式です。エクスポート/インポート方式とも呼ばれます。
もう一つは、データベースプラットフォームに依存し、データベース固有の機能を利用した方式です。データベース固有の方式とも呼ばれます。

今回のダウンタイム削減で利用する方式は、データベース固有の「バックアップ/リストア」を利用したものになります。

バックアップ/リストアによるデータベースの移行

前提

バックアップ/リストアによるデータベースの移行を計画する前に、下記をご確認ください。

ソースとターゲットのシステムでデータベースプラットフォームが異なる場合は、今回ご紹介する方法は利用できません。
エンディアンの異なる機種間の移行は、今回ご紹介する方法は基本的に利用できませんが、一部例外があり｢特殊なバックアップ｣でご紹介したいと思います。
データベースのバージョンは、ソースとターゲットのシステムで同じであることを基本としますが、ターゲットシステムのバージョンが高くても移行が行える場合があります。
詳しくはデータベースプラットフォームのベンダーが公開している、バックアップ互換性に関する情報をご確認ください。
データベースプラットフォームによっては、システムプロビジョニングツール (Software Provisioning Manager、以降は SWPM) がフルバックアップのみの移行にしか対応しない場合があり、その場合には今回ご紹介する方法は利用できません。
詳しくは SAP 社が提供するシステムコピーガイドをご確認ください。

バックアップの方式

データベースプラットフォームによって、バックアップの呼称と内容が異なることがあるため、今回は下記のように呼称と内容を定義させて頂きます。

フルバックアップ
バックアップを行った時点のデータベース全内容を対象としたバックアップです。
フルバックアップは、増分/差分バックアップの起点となります。

増分バックアップ
直前のバックアップを起点とし、起点から変更のあったデータベース内容のみを対象としたバックアップです。直前のバックアップとは、フルバックアップだけではなく増分/差分バックアップも対象となります。
データベースプラットフォームによっては、このバックアップのことを差分バックアップと呼ぶ場合がありますのでご注意ください。

差分バックアップ
直前のフルバックアップを起点とし、起点から変更のあったデータベース内容のみを対象としたバックアップです。複数の差分バックアップを行っても、起点は直前のフルバックアップとなります。

トランザクションログバックアップ
前回のトランザクションログバックアップを起点とし、起点からバックアップされていないトランザクションログを対象としたバックアップです。

作業の流れ

ダウンタイムを削減するために、データベースの移行をダウンタイムとアップタイムに分散して行います。これによって、ダウンタイム中のバックアップ時間、移行データ転送時間、リストア時間を削減することが出来ます。

通常の運用で定期的にフルバックアップを行っており、データベースの移行で利用するフルバックアップの後にフルバックアップを行う必要がある場合は、増分バックアップの代わりにトランザクションログバックアップを利用します。

アップタイム中

(Ⅰ) フルバックアップ

ソースシステムのデータベースをフルバックアップします。
- SAPシステムの状態は稼働/非稼働どちらでも問題ありませんが、稼働中に行う場合にはデータベースがオンラインでバックアップが出来るように設定されている必要があります。
- 可能であれば、バックアップの圧縮を有効にします。
  これはバックアップ時間、バックアップファイル転送時間の短縮に有効です。
- 可能であれば、バックアップを並列 (パラレル) で行います。
  これはバックアップ時間の短縮に有効です。
バックアップファイルをターゲットシステムに転送します。
バックアップファイルをターゲットシステムのデータベースにリストアします。

(Ⅱ) 増分バックアップ

ソースシステムのデータベースを増分バックアップします。
- SAP システムの状態は稼働/非稼働どちらでも問題ありませんが、稼働中に行う場合にはデータベースがオンラインでバックアップが出来るように設定されている必要があります。
- 可能であれば、バックアップの圧縮を有効にします。
  これはバックアップ時間、バックアップファイル転送時間の短縮に有効です。
- 可能であれば、バックアップを並列 (パラレル) で行います。
  これはバックアップ時間の短縮に有効です。
- データベースの変更履歴を記録 (トラッキング) する機能を有効にします。
  これはバックアップ時間、バックアップファイル転送時間の短縮に有効です。
バックアップファイルをターゲットシステムに転送します。
バックアップファイルをターゲットシステムのデータベースにリストアします。

ダウンタイム中

(III) 増分バックアップ

ソースシステムの SAP システムを停止します。
ソースシステムのデータベースを増分バックアップします。
- SAP システムの状態は稼働/非稼働どちらでも問題ありませんが、稼働中に行う場合にはデータベースがオンラインでバックアップが出来るように設定されている必要があります。
- 可能であれば、バックアップの圧縮を有効にします。
  これはバックアップ時間、バックアップファイル転送時間の短縮に有効です。
- 可能であれば、バックアップを並列 (パラレル) で行います。
  これはバックアップ時間の短縮に有効です。
- データベースの変更履歴を記録 (トラッキング) する機能を有効にします。
  これはバックアップ時間、バックアップファイル転送時間の短縮に有効です。
バックアップファイルをターゲットシステムに転送します。
バックアップファイルをターゲットシステムのデータベースにリストアします。
ターゲットシステムで SWPM によるシステムコピーを実施します。

特殊なバックアップ

Oracle：Cross-Platform Transportable Tablespaces (XTTS)

異なるエンディアンの機種間 (例えば、AIX から Linux) でシステムコピーを行う場合はエクスポート/インポート方式を利用しますが、データベースプラットフォームが Oracle でソースシステムのバージョンが 12c 以降であれば、バックアップ/リストア方式で行うことが出来ます。
バックアップ/リストアには、Oracle の XTTS を利用します。下記は XTTS の特徴になります。

XTTS のバックアップ単位は、表領域 (tablespace) となります。
バックアップ対象はユーザ系表領域となり、SAPシステムの移行であれば PSAPSR3、PSAPSR3<ReleaseNo.>、PSAPSR3USR、PSAPSR3DB などになります。
システム系表領域 (SYSTEM、SYSAUX) を移行するには、メタデータのエクスポート/インポートを行います。
表領域の PSAPTEMP、PSAPUNDO は移行の対象とせず、ターゲットシステムで新たに作成します。
エンディアン変換は、ソースシステム側のバックアップかターゲットシステム側のリストアのどちらかで行うことが出来ます。
利用できるバックアップ方式は、増分バックアップのみとなります。増分レベル０バックアップはフルバックアップに相当し、増分レベル１バックアップは増分バックアップに相当します。
ダウンタイム中に行う最後のバックアップは、ユーザ系表領域を読み取り専用にして行います。

最後に

SAP システムを移行するにあたっては、堅実な計画と入念なリハーサルを心掛けてください。
着実に行えるバックアップ/リストアスケジュールの計画、出来るだけ本番移行に近づけたリハーサル、をお勧めします。
特に、ソースシステム側の作業タイミングについては注意が必要です。本稼働しているソースシステムの運用にできるだけ影響を与えないことを心掛けてください。