SAP ERP 6.0 IBM Db2 IBM の移行 Power Virtual Server

SAP Enterprise Resource Planning 6 (ERP) システムを IBM Db2 から IBM Power Virtual Server に移行するには、以下のガイドをご利用ください。 IBM Db2 データベースをターゲットシステムに移行するには、さまざまなオプションがあります。

IBM Db2 SAP 移住先オプション

IBM Db2 の SAP ERP の場合、2 つの移行オプションがあります：

移行オプション1 - バックアップと復元は、開始、停止、バックアップ、復元などの標準的な管理タスクに基づいています。これはよりシンプルなアプローチですが、移行中にダウンタイムが必要です。
移行オプション2 - IBM Db2 高可用性および災害復旧（HADR）は、 SAP の運用システム向けのダウンタイムを最適化するアプローチです。これは、 IBM Db2 高可用性および災害復旧（ IBM Db2 HADR）データベース同期およびオンラインバックアップに基づいています。システムのダウンタイムは最小限に抑えられますが、この方法ではオプション1と比較して、より高度な設定アプローチが必要となります。

移行オプション1 - バックアップと復元

バックアップと復元は、開発またはテスト用 SAP システムの移行に典型的なオプションです。この移行オプションは、ソースシステムからのデータベースのバックアップと、事前にインストールされたターゲットシステム上のデータベースを埋めるためのデータベースの復元に基づいています。

移行を完了するには、以下の手順が必要です

移行オプション1 - バックアップとリストアのアプローチの特徴：

ダウンタイム： SAP システムは移行プロセス中は利用できないため、 SAP システムの計画的なダウンタイムが必要です。
フォールバック ：ソース SAP システムに変更は加えられていません。必要に応じて、フォールバックアクションとして、移行を停止し、ソース SAP システムを再起動します。
複雑性 ：標準的な管理業務に基づく。この移行オプションは最も複雑ではありません。

マイグレーションの準備

以下の手順で移行の準備をする。

ソースサーバーとターゲットサーバーの両方で、定義済みのすべての環境変数が必要です。ソースの SAP サーバー上でコマンドを実行している間、コマンドを一時的なテキストファイルに保存します。ターゲットサーバーには、ターゲットシステム上のデータベースの復元の章で示されているのと同じコマンドが正確に必要です。

必要に応じて、以下の環境変数を設定してください。

ソースシステム上で、 root ユーザーとしてCシェルセッションを開始します
```
csh
```
環境変数を定義するためのコマンド構文は、シェルの種類によって異なります。 Db2 および SAP の管理者ユーザー db2<sid> および <sid>adm のデフォルトのシェルタイプはCシェルです。同じシェルを使用している場合は、コマンド例をコピーして、セッション環境に貼り付けることができます。
移行先のホスト名（例：cdb6ecc1 ）を定義し、それを移行先のホスト名に置き換えます
```
set TARGETSERVER=cdb6ecc1
```
ソースとターゲットの SAP システム上で、 SAP ERPソフトウェアと IBM Db2 データベースが同じバージョンで実行されていることを確認してください。
SAP インスタンスの管理者を定義します（この例は SAP インスタンス th1 用です）。そして、それを貴社のシステムに合わせて変更します。
```
set SIDADM=th1adm
```
IBM Db2 データベース名を定義します。 th1 を例として、システムに合わせて変更します
```
set DBNAME=th1
```
IBM Db2 データベース管理者を定義します
```
set DB2ADM=db2th1
```
バックアップファイルを保存するディレクトリを指定します
```
set BACKUPDIR=/db2/backup
```
以下のディレクトリが存在しない場合は作成する：
```
mkdir -p $BACKUPDIR
```
バックアップディレクトリの所有権を Db2 の管理者に移行します
```
chown $DB2ADM $BACKUPDIR
```
このバックアップディレクトリには、圧縮されたバックアップファイルを保存するための十分な容量が必要です。 GET_DBSIZE_INFO プロシージャを呼び出して、現在の IBM Db2 データベースのサイズを決定します。詳細は、GET_DBSIZE_INFO プロシージャを参照してください。

SAP アプリケーションを停止し、ソースサーバー上のデータベースを非アクティブ化する

以下の手順に従って、 SAP アプリケーションをシャットダウンし、ソースサーバー上のデータベースを無効にしてください。

SAP システムを起動または停止するには、 SAP インスタンスの管理者アカウント $SIDADM を使用します
```
su - $SIDADM
```

SAP システムを停止し、データベースを稼働し続けるには、次のコマンドを使用します

stopsap r3

オプションとして、次のコマンドを実行して、 SAP が必要な状態にあるかどうかを確認することができます

stopsap check

期待される出力は次の例のようになる：

Checking db6 Database
Database is running
-------------------------------------------
Checking SAP TH1 Instance ASCS01
-------------------------------------------
Instance ASCS01 is not running
Checking SAP TH1 Instance D00
-------------------------------------------
Instance D00 is not running

Db2 コマンドについては、 $SIDADM ユーザーセッションを終了します
```
exit
```
$DB2ADM ：
```
su - $DB2ADM
```
オプションとして、データベースを非アクティブ化する前に、以下のコマンドを実行してデータベースに接続しているアプリケーションがまだあるかどうかを確認することができます
```
db2 list applications
```
次の例は期待される出力である。
```
SQL1611W  No data was returned by Database System Monitor.
```
アプリケーションがまだ表示されている場合は、アプリケーションを停止し、再度確認してください。それでも外部アプリケーションが停止しない場合のみ、 db2 force applications all を使用してアプリケーションをデータベースサーバーから切断してみてください。
DB2ADM ユーザーの環境変数を再度定義します
```
set DBNAME=th1
```
```
set BACKUPDIR=/db2/backup
```
IBM Db2 オフラインバックアップには、データベースを非アクティブ化する必要があります。データベースを停止するには、以下のコマンドを使用する：
```
db2 deactivate database $DBNAME
```
以下の出力が期待されます。
```
DB20000I  The DEACTIVATE DATABASE command completed successfully.
```

ソースシステム上の IBM Db2 オフラインバックアップを使用する

ソースシステムで Db2 のオフラインバックアップを使用するには、以下の手順に従ってください。

圧縮されたオフラインバックアップを保存するためのバックアップディレクトリは、移行準備ステップで作成されました。

バックアップディレクトリにバックアップファイルを保存するのに十分な空き容量があることを確認してください
```
df -m $BACKUPDIR
```
IBM Db2 オフラインバックアップを開始します
```
db2 backup database $DBNAME to $BACKUPDIR compress
```
このコマンドはデータベースのサイズによって、長時間実行されます。

バックアップの進行状況は、コマンドで追跡できます。 db2 list utilities show detail

バックアップコマンドの出力の最後にタイムスタンプがあります。このタイムスタンプは、ターゲットシステム上のデータベースを復元するために必要です。

出力例:
```
Backup successful. The timestamp for this backup image is : 20240730170709
```
このタイムスタンプを覚えておいてください。次の2つのステップで参照する必要があります。
タイムスタンプを保存するには環境変数を使用します
```
set TIMESTAMP=<your timestamp>
```
IBM Db2 バックアップのタイムスタンプは、YYYYMMDDHHMMSS（年-月-日-時-分-秒）というフォーマットで、 20240730170709 のようになります。このタイムスタンプは、ターゲットの SAP サーバーでも必要です。この TIMESTAMP 定義コマンドを、移行準備から保存したコマンドのリストに追加します。
次のコマンドを使用してバックアップフォルダに変更します
```
cd $BACKUPDIR
```
タイムスタンプがファイル名に含まれているファイルを確認します
```
ls -l *$TIMESTAMP*
```
出力例:
```
TH1.0.db2th1.DBPART000.20240730170709.001
```

出力にリストアップされているファイルは、次のステップでターゲットシステムに転送されるバックアップファイルです。

バックアップファイルの転送

以下の手順でバックアップファイルを転送する。

ソースの SAP システムからターゲットにバックアップファイルをコピーします
```
scp ${BACKUPDIR}/*${TIMESTAMP}* \
    ${TARGETSERVER}:${BACKUPDIR}
```

この例では、セキュア・コピー（SCP）という、より低速のデータ転送方式を使用しています。バックアップファイルは、 IBM AIX の LPAR がある Power Virtual Server に直接転送するか、 IBM Cloud Object Storage に転送することができます。 IBM Cloud Object Storage で SCP または SFTP を使用する場合、 IBM FileManage ゲートウェイサービスを使用しているか、または転送の受信先としてターゲットの IBM Power Virtual Server 環境内または隣に SFTP サーバーをインストールして設定しているものと見なされます。

高速なオプションは、 IBM のデータ転送用高性能製品 Aspera です。多くの状況において、 IBM Aspera は従来の TCP ベースのプロトコルよりも数倍高速にデータを転送することができます。詳細については、 IBM Aspera Technologies をご覧ください。

このリファレンスには、高速ネットワーク転送移行ガイドも含まれています。

ターゲットシステム上のデータベースを復元する

以下の手順に従って、ターゲットシステム上のデータベースを復元してください。

ターゲットサーバーにログインして、復元手順を開始します
```
ssh $DB2ADM@$TARGETSERVER
```
ターゲットサーバーは、ソースシステム上で定義されている環境変数を認識できません。しかし、 $DBNAME、 $TIMESTAMP 、 $SIDADM の変数はターゲットシステム上で必要となります。これらの変数を定義するには、移行の準備とソースシステムでの IBM Db2 オフラインバックアップの使用の手順で保存したコマンドのリストを実行するか、環境変数を再度定義します。
完全な復元手順には、無効化された IBM Db2 データベースが必要です。プリインストールされたターゲット SAP システムで、これまでと同じ手順を実行します
```
db2 list applications
```
次の出力が期待されます
```
SQL1611W  No data was returned by Database System Monitor.
```
IBM Db2 データベースを無効化します
```
db2 deactivate database $DBNAME
```
データベースを完全に復元する：
```
db2 restore database $DBNAME \
    from $BACKUPDIR          \
    taken at $TIMESTAMP
```
replace existing をリストアコマンドに追加すると、上書き確認のプロンプトを回避できます。
Db2 コマンドは、バックアップを復元して既存のデータベースを上書きするか尋ねます
```
SQL2523W  Warning!  Restoring to an existing database that is different from the database on the backup image, but have matching names. The target database is overwritten by the backup version. The Roll-forward recovery logs associated with the target database is deleted.

Do you want to continue ? (y/n)
```
y 」と入力し、Enterキーを押す。

次の出力が期待されます
```
DB20000I  The RESTORE DATABASE command completed successfully.
```
リストアに失敗した場合は、事前に db2 drop database $DBNAME でターゲットシステムのデータベースを削除し、リストアコマンドを再度実行してください。
復元を完了するには、次のコマンドを使用します
```
db2 rollforward db $DBNAME to end of backup and stop
```

ターゲットデータベースには、ソースシステムデータが含まれています。

SAP ターゲットシステムを起動

以下の手順でターゲット・システムを起動する、

SAP インスタンスの管理者に切り替える：
```
login $SIDADM
```

SAP アプリケーションを起動する：

startsap

次の例は期待される出力である：

Checking db6 Database
Database is running
-------------------------------------------
Starting Startup Agent sapstartsrv
OK
Instance Service on host <TARGET> started
-------------------------------------------
starting SAP Instance ASCS01
Startup-Log is written to /home/th1adm/startsap_ASCS01.log
-------------------------------------------
/usr/sap/TH1/ASCS01/exe/sapcontrol -prot NI_HTTP -nr 01 -function Start
Instance on host <TARGET> started
Starting Startup Agent sapstartsrv
OK
Instance Service on host <TARGET> started
-------------------------------------------
starting SAP Instance D00
Startup-Log is written to /home/th1adm/startsap_D00.log
-------------------------------------------
/usr/sap/TH1/D00/exe/sapcontrol -prot NI_HTTP -nr 00 -function Start
Instance on host <TARGET> started

クライアントシステム（実行中の SAP ログオンGUI）がターゲットサーバーに接続されていることを確認するために、 SAP システムのDNSレコードをターゲットの SAP サーバーを指すように調整します。

これでマイグレーションは完了です。

SAP ソースサーバーのシステムがダウンしている
SAP ターゲットサーバー上のシステムが稼働中である

移行オプション2 - IBM Db2 高可用性および災害復旧（HADR）

移行オプション2は、ダウンタイムを最小限に抑えるための手順です。 IBM Db2 HADRを使用して、両側のデータベースのバックアップ、リカバリ、同期を組み合わせたものです。データベースが同期され、移行のための環境が整っている場合、コアの移行は事前にインストールされたターゲット SAP サーバーに切り替わります。

ソースシステムが IBM Db2 クラスタを使用している場合、または IBM Db2 HADRが有効になっている場合、移行により既存のHADR構成が拡張されます。特別なケース - ソースの移行 IBM Db2 クラスタは、必要な手順を説明し、リンクしています。

IBM Db2 ソース側でHADRが有効になっていない場合は、以下の手順が必要です

移行オプション 2 の特徴 - IBM Db2 HADR:

一般的なダウンタイム ：サーバーがソースからターゲットに切り替わる際の短いダウンタイムがあります。切り替え前は、ソースの SAP システムが稼働しています。切り替え後、ターゲットの SAP システムが引き継ぎます。
ダウンタイム、循環ログ ：HADRでは、 IBM Db2 データベースが archive logging モードであることが必要です。 IBM Db2 データベースが circular logging モードになっている場合は、HADR を使用する前に、 IBM Db2 データベースを archive logging モードに移行する必要があります。この手順により、データベースの一時的なダウンタイムが発生します。
フォールバック： 完全な移行が完了するまで、ソースの SAP システムが稼働していることを意味します。切り替え前に特別なフォールバックオプションは必要ありません。切り替えの前後で手順がうまくいかなかった場合は、手順を元に戻してソースの SAP システムを再度立ち上げ、稼働させることができます。

特別なケース - ソース IBM Db2 クラスタの移行

ソースの SAP システムが IBM Db2 HADRクラスタである場合、HADR構成はターゲットサーバーを含めるように拡張する必要があります。この場合は手順が簡単です。

説明されている設定手順のほとんどはすでに設定済みです。ターゲットシステムは、既存の IBM Db2 HADR構成に補助ノードとして追加する必要があります。詳細については、既存の Db2 HADRペアに新しい補助スタンバイを追加する手順に関するサポート記事（ IBM Db2 ）をご覧ください。

マイグレーションの準備

SAP システムを移行する準備をするには、以下の手順に従ってください。

移行の準備を進めるにあたり、以下の情報を念頭に置いてください。

セットアップで使用する2つのTCPポート番号を定義する必要があります。
HADRとの同期には、2つのネットワークポートの開放が必要です
- 送信トラフィック用のローカルポート
- 着信トラフィック用のリモートポート
両方のポートは、2つの IBM Db2 システムそれぞれに設定されていますが、順序が入れ替わっています。この例ではポート番号 5920/tcp と 5921/tcp を使用していますが、必要に応じてこれらのポートを変更することができます。
ファイアウォールは、ソースシステムとターゲットシステム間の TCP トラフィックを許可する必要があります。関係するすべてのファイアウォールとソースシステムおよびターゲットシステム上で、必要なファイアウォールルールが設定されていることを確認してください。

環境設定に応じて、以下の環境変数を設定します。

定義されたすべての環境変数は、ソースサーバーとターゲットサーバーの両方で必要です。ソースの SAP サーバー上でコマンドを実行している間に、そのコマンドを一時的なテキストファイルに保存します。ターゲットサーバーには、「ターゲットシステム上のデータベースの復元」で説明されているのと同じコマンドが必要です。

移行先のホスト名を定義します。 cdb6ecc1 は例であり、次のコマンドを使用して、移行先のホスト名に置き換えてください
```
set TARGETSERVER=cdb6ecc1
```
ターゲットサーバーが、ソース SAP システムと同じバージョンの SAP ERPソフトウェアと IBM Db2 データベースを実行していることを確認してください。
SAP インスタンスの管理者を定義し、次のコマンドを使用して、お客様のシステムに合わせて変更します（この例は、 SAP インスタンス th1 用です）
```
set SIDADM=th1adm
```
IBM Db2 データベース名を定義します。 th1 を例として再度示します。ご使用のシステムに合わせて変更してください
```
set DBNAME=th1
```
IBM Db2 データベース管理者を定義します
```
set DB2ADM=db2th1
```
バックアップファイルを保存するディレクトリを定義します
```
set BACKUPDIR=/db2/backup
```
以下のディレクトリが存在しない場合は作成する：
```
mkdir -p $BACKUPDIR
```
バックアップディレクトリの所有権を Db2 の管理者に移行します
```
chown $DB2ADM $BACKUPDIR
```
このバックアップディレクトリには、圧縮されたバックアップファイルを保存するための十分な容量が必要です。 GET_DBSIZE_INFO プロシージャを呼び出して、現在の IBM Db2 データベースのサイズを決定します。詳細は、 GET_DBSIZE_INFO プロシージャを参照してください。

IBM Db2 アーカイブログ機能が有効になっていることを確認する

IBM Db2 高可用性および災害復旧（HADR）には、 archive logging を有効にする必要があります。 circular logging IBM HADRをインストールすると、デフォルトで有効になります。 Db2 IBM Db2 archive logging が有効になっている SAP システムの大半。

アーカイブログの記録方法を確認する

どのログ記録方法が設定されているかを確認するには、以下の手順に従います。

IBM Db2 データベース管理者に切り替える：
```
su - $DB2ADM
```
両方のログアーカイブ方法の設定オプションを取得します
```
db2 get db cfg for th2 | grep LOGARCHMET
```
ログアーカイブ方法の少なくとも1つが ON に設定されている場合は、次のセクションに進みます。両方が OFF に設定されていないことを確認してください。この例は、アーカイブログを有効にした場合の出力がどのようなものになるかを示しています
```
 First log archive method                 (LOGARCHMETH1) = DISK:/db2/logarch/
 Second log archive method                (LOGARCHMETH2) = OFF
```
両方のログアーカイブ方法が OFF の場合、まずアーカイブログの設定を行う必要があります。次の例はその出力である：
```
 First log archive method                 (LOGARCHMETH1) = OFF
 Second log archive method                (LOGARCHMETH2) = OFF
```

アーカイブログの設定

IBM Db2 HADR にはアーカイブログが必須です。 LOGARCHMETH1 と LOGARCHMETH2 が OFF に設定されている場合、以下の手順に従ってアーカイブログを有効にしてください。

アーカイブログを有効にするには、ダウンタイムが必要です。

SAP の管理者ユーザーとしてログインし、 SAP システムを停止します
```
su - $SIDADM
```
SAP システムを停止するが、データベースは稼働したままにする
```
stopsap r3
```
SAP 管理ユーザーを終了する：
```
exit
```
IBM Db2 管理アカウントに切り替えます
```
su - $DB2ADM
```
保存したコマンドを使用して、 DBNAME や BACKUPDIR などの環境変数が設定されていることを確認してください。
ログアーカイブファイルのディレクトリを定義する：
```
set LOGARCHDIR=/db2/log_archive
```
可能であれば、ログアーカイブディレクトリを別のパーティションに作成してください。アーカイブログパーティションは、LPARのディスク設定に依存しますが、これはこの文書の対象外です。ソースシステムが IBM Db2 クラスターである場合、ログアーカイブはノード間で共有されるディレクトリであることを念頭に置いてください。
最低限、次のコマンドでログアーカイブディレクトリを作成します
```
mkdir $LOGARCHDIR
```

作成されたディレクトリを確認します

ls -ld $LOGARCHDIR

出力例:

drwxr-xr-x 7 db2th1 dbth1adm 256 Aug 30 11:24 /db2/log_archive

ディレクトリの所有者が Db2 の管理者であるかどうかを確認します。サンプル出力では、 db2th1 です。次に、オーナーが完全な権限を持っていることを確認してください。 rwx。
Db2 を、アーカイブログ用にこのディレクトリを持つディスクデバイスを使用するように設定します。ログ記録方法1:
```
db2 "update db cfg for $DBNAME using LOGARCHMETH1 DISK:$LOGARCHDIR"
```
予期される出力:
```
DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.
```
IBM Db2 データベースは、この変更後にバックアップを強制します
```
db2 backup database $DBNAME to $BACKUPDIR compress
```
バックアップの完了には時間がかかります。データベースのサイズによって異なります。
SAP の管理アカウント $SIDADM を使用してデータベースと SAP システムを再起動します
```
su - $SIDADM
```
```
startsap
```

ソースシステムデータベースからオンラインバックアップを作成する

SAP システムのダウンタイムを最小限に抑えるために、オンラインの Db2 データベースバックアップを作成します。

Db2 の管理者ユーザーに切り替える：
```
su - $DB2ADM
```
ログファイルを含め、オンラインバックアップを開始します
```
db2 backup db $DBNAME online to $BACKUPDIR compress include logs
```
バックアップには時間がかかることを念頭に置いてください。

バックアップが完了すると、タイムスタンプが印刷されます
```
Backup successful. The time stamp for this backup image is : 20240913091058
```
このタイムスタンプを暗記する。次の2つのステップで必要になります。
タイムスタンプを保存するには環境変数を使用します
```
set TIMESTAMP=<your timestamp>
```
IBM Db2 バックアップのタイムスタンプは、YYYYMMDDHHMMSS（年-月-日-時-分-秒）というフォーマットを使用しており、 20240913091058 のようになります。このタイムスタンプは、ターゲットの SAP サーバーでも必要です。この TIMESTAMP 定義コマンドを、ステップ「移行準備」で保存したコマンドのリストに追加します。

バックアップファイルをターゲットシステムに転送する

次の手順に従って、バックアップファイルをターゲットシステムに転送してください。

ソースシステム SAP からターゲットシステムにバックアップファイルをコピーします
```
scp ${BACKUPDIR}/*${TIMESTAMP}* \
    ${TARGETSERVER}:${BACKUPDIR}
```

ターゲットシステムの復元

以下の手順に従って、ターゲットシステムを復元してください。

データベースの復元はターゲットサーバー上で実行されます
```
ssh $DB2ADM@$TARGETSERVER
```
ターゲットサーバーは、ソースシステム上で定義されている環境変数を認識できません。しかし、 $DBNAME、 $TIMESTAMP 、 $SIDADM の変数はターゲットシステム上で必要となります。これらの変数を定義するには、移行の準備とソースシステムデータベースからのオンラインバックアップの作成の手順で保存したコマンドのリストを実行するか、環境変数を再度定義します。

オンラインバックアップを使用してデータベースに復元します。

db2 restore database $DBNAME \
    from $BACKUPDIR          \
    taken at $TIMESTAMP

Db2 コマンドは、バックアップを復元して既存のデータベースを上書きするか尋ねます

SQL2523W  Warning!  Restoring to an existing database that is different from the database on the backup image, but have matching names. The target database will be overwritten by the backup version. The Roll-forward recovery logs associated with the target database will be deleted. Do you want to continue? (y/n)

y 」と入力し、Enterキーを押す。

次の例は期待される出力である：
```
DB20000I  The RESTORE DATABASE command completed successfully.
```
復旧に失敗した場合は、事前に db2 drop database $DBNAME でターゲットシステムのデータベースを削除し、リストアコマンドを再度実行してください。

オプション1とは対照的に、アーカイブログをロールフォワードしない。 HADRは、次のステップにある変更データを同期するために、この状態を取ります。ソースの SAP システムが稼働している場合、ソースデータの変更が発生します。

最新の変更を転送するには、 IBM Db2 HADRデータベースの同期を設定します。

ターゲットシステムとソースシステムにおけるHADRローカルおよびリモートサービスポートの定義

以下の手順に従って、ターゲットシステムとソースシステム上のHADRローカルおよびリモートサービスポートを定義します。

HADRは、データの同期化に2つのTCPポートを使用します。

/etc/services にこれらのTCPポート番号が含まれていないことを両方のシステムで確認してください。両方のサーバーで、このファイルのポート番号を設定します。

/etc/services、 IBM、 Db2 でローカルおよびリモートのHADRポートが構成されている場合、番号ではなくサービス名を使用することで、構成がより読みやすくなります。

この例では、 5920/tcp と 5921/tcp というポートを使用していますが、異なるポートを定義することも可能です。

設定するポート番号の概要表：

/etc/services の両サーバーにおけるTCPポートの割り当て
サービス名	ソースサーバー上の値	ターゲットサーバー上の値	コメント
db2th1ha_l	`5921/tcp`	`5920/tcp`	ローカル・ポート
db2th1ha_r	`5920/tcp`	`5921/tcp`	リモート・ポート

お好みのエディタを使用して、両方のサーバー上の /etc/services を変更してください。
次のコマンドを使用して、設定ファイルが正しいかどうかを確認します
```
grep -e '592[01]/' /etc/services
```
ソースサーバーでの期待される出力は次のとおりです
```
db2th1ha_l        5921/tcp        # Db2 HADR local port
db2th1ha_r        5920/tcp        # Db2 HADR remote port
```
ポート番号はターゲットサーバー上で有効にする必要があります。ターゲットノードでの期待される出力は次の例の通りです
```
db2th1ha_l        5920/tcp        # Db2 HADR local port
db2th1ha_r        5921/tcp        # Db2 HADR remote port
```

ターゲットシステムとソースシステムでHADRを設定する

HADRには、以下の構成が必要です。

HADRパラメータの概要、両方のサーバー
Db2 HADRパラメータ	ソースサーバー上の値	ターゲットサーバー上の値	コメント
ローカルホスト			現在使用しているシステムのホスト名
HADR_LOCAL_SVC	db2th1ha_l	db2th1ha_l	ローカルポートは、定義されたとおりとする。 `/etc/services`
リモートホスト			もう一方のホストのホスト名
HADR_REMOTE_SVC	db2th1ha_r	db2th1ha_r	リモートポートは、定義されたとおりに `/etc/services`
HADR_REMOTE_INST	<db2 インスタンス名>	<db2 インスタンス名>	もう一方のノードの IBM Db2 インスタンス名（データベース名ではありません）
ログインデックスビルド	`ON`	`ON`	両方のホストで `ON` をオンに設定する
HADR_SYNCMODE	有効な同期モード	有効な同期モード	HADR同期モードを参照してください

ローカルおよびリモートのホスト名（HADR_LOCAL_HOST および HADR_REMOTE_HOST ）は、両方のシステムで有効にする必要があります。 HADR_LOCAL_HOST は常にノードのホスト名です。構成コマンドは実行され、リモートホストはそれぞれの他のシステムのホスト名です。

ローカルおよびリモートのサービスエントリ（HADR_LOCAL_SVC および HADR_REMOTE_SVC ）は同一です。これは、スイッチがすでに /etc/services で構成されているためです。

高可用性災害復旧（HADR）同期モードでは、さまざまな IBM Db2 HADR同期オプションとその利点について説明します。

以下のコマンドを使用して、両方のシステムを設定する：

ローカルホストとは、 hostname コマンドが報告するシステムです
```
db2 "update db cfg for $DBNAME using HADR_LOCAL_HOST `hostname`"
```
ローカルポートは、 /etc/services からのローカルポート定義です
```
db2 "update db cfg for $DBNAME using HADR_LOCAL_SVC db2th1ha_l"
```
リモートホストの場合、 $TARGETSERVER が他のサーバーを指していることを確認してください
```
db2 "update db cfg for $DBNAME using HADR_REMOTE_HOST $TARGETSERVER"
```
リモートポートは、 /etc/services からのリモートポート定義です
```
db2 "update db cfg for $DBNAME using HADR_REMOTE_SVC db2th1ha_r"
```
リモート IBM Db2 インスタンスを設定します。

方向性として、データベース名が th1 の場合、インスタンス名は db2th1 のようになります
```
db2 "update db cfg for $DBNAME using HADR_REMOTE_INST $DBINST"
```
両方のシステムでログインデックスの構築がオンになっていることを確認してください
```
db2 "update db cfg for $DBNAME using LOGINDEXBUILD ON"
```
HADR同期モードを定義します。 async は一例です。ご使用の環境に適した HADR同期モードに合わせて変更してください
```
db2 "update db cfg for $DBNAME using HADR_SYNCMODE async"
```

HADRの起動と同期データの確認

以下の手順でHADRを起動し、データが同期されているか確認します。

待機中のターゲットサーバーでHADRを開始します。 $DB2ADM としてターゲットサーバーに切り替えて、以下のコマンドを実行します
```
db2 start hadr on db $DBNAME as standby
```
期待される出力は次の例のようになる：
```
DB20000I  The START HADR ON DATABASE command completed successfully.
```
ソースサーバーでHADRをプライマリとして起動します。 $DB2ADM としてソースサーバーに切り替え、以下のコマンドを実行します
```
db2 start hadr on db $DBNAME as primary
```
期待される出力は次の例のようになる：
```
DB20000I  The START HADR ON DATABASE command completed successfully.
```

HADR状態を以下で確認してください

db2pd -d $DBNAME -hadr

そして、これらのフィールドを確認してください

HADRステータス値、両方のサーバー
フィールド	ソース・サーバー	ターゲット・サーバー
HADR_ROLE	`PRIMARY`	`STANDBY`
HADR_STATE	`PEER`	`PEER`
ハドルコネクトステータス	`CONNECTED`	`CONNECTED`

コアの移行を実行する

以下の手順に従って、 SAP システムをソースサーバーからターゲットサーバーへ移行を開始してください。

SAP システムのDNSレコードを調整し、ターゲットの SAP サーバーを指すようにします。この調整により、クライアントシステム（ SAP ログオンGUIを実行するシステムなど）がターゲットサーバーに接続することが確実になります。

Db2 データベースを含む SAP システムを停止する。

ソースシステムにログインし、 $SIDADM として以下のコマンドを実行します
```
stopsap
```
コマンドが完了するまで待つ。
$DB2ADM としてターゲットサーバーに切り替え、以下のコマンドを使用して乗っ取りを開始します
```
db2 takeover hadr on database $DBNAME
```
買収コマンドには、ソースシステムが正常にシャットダウンされなかった場合に役立つオプション by force があります。詳細は、 TAKEOVER HADRコマンドを参照してください。
ターゲットサーバー上の $DB2ADM として。次のコマンドを使用して、 IBM Db2 HADR ロールが standby から primary に変更されたことを確認してください
```
db2pd -d th2 -hadr | grep ROLE
```
IBM Db2 HADR ロールがターゲットサーバー上で primary である場合、 SAP システムをターゲットサーバー上で起動できます。 $SIDADM ユーザーに切り替えて、以下のコマンドを実行します
```
startsap
```
IBM Db2 データベースの同期は、現段階ではまだアクティブではありませんが、設定は完了しています。

対象システムが元に戻す予定である場合（災害シナリオの場合）、HADR構成はそのままにしておく。移行後にソースシステムが削除された場合は、「既存のHADR構成の削除方法」に記載されている手順に従ってHADR構成を削除します。

これでマイグレーションは完了です。

SAP ソースサーバーのシステムがダウンしている
SAP ターゲットサーバー上のシステムが稼働中である