SAP HANA Installation
SAP HANAアップデート手順：計画から検証までの実践ガイド
SAP HANAオンプレミスのアップデート手順を、リビジョン戦略、事前確認、バックアップ、hdblcm実行、テナント検証、事後確認の順に解説します。
SAP HANAオンプレミスのアップデートは、ソフトウェアを適用する作業だけではありません。対象リビジョンの選定、停止時間の調整、バックアップ、互換性確認、実行後の検証までを一つの変更計画として扱うことが重要です。本記事では、SAP HANA 2.0のマルチテナント構成を前提に、実務で使いやすいアップデート手順を整理します。
SAP HANAアップデートの全体像
SAP HANA 2.0は、システムデータベースとテナントデータベースで構成されるマルチテナントシステムです。アップデートでは、データベースだけでなく、ホスト上のサービス、追加コンポーネント、クライアントソフトウェアとの関係も確認します。
一般的な流れは、次のとおりです。
- 現行環境と対象リビジョンを確認する
- 変更影響、停止時間、ロールバック方針を決める
- バックアップと復旧可能性を確認する
- インストールメディアと権限を準備する
hdblcmまたはhdblcmguiでアップデートを実行する- サービス、データベース、アプリケーションを検証する
新規構築を含む環境では、先にSAP HANAインストール手順を確認すると、インストールとアップデートの作業範囲を分けて計画できます。
リビジョン戦略を決める
対象リビジョンは、単に最新の番号だけで決めません。利用中のアプリケーション、SAPノート、接続クライアント、バックアップ製品、監視製品、運用手順との整合性を確認します。特に業務システムでは、開発・検証・本番の順に適用し、各環境で動作結果を記録します。
検討時には、次の情報を一覧化します。
- 現在のSAP HANAバージョンとリビジョン
- 対象となるSAP HANA Serverのインストールメディア
- 対応するSAP HANAクライアントやJDBCドライバー
- SAP NetWeaver、SAP S/4HANA、BIツールなどの接続先
- 適用対象のSAPノートと既知の制限事項
- 必要な停止時間、担当者、承認経路
リビジョンの候補を比較するときは、機能追加だけでなく、サポート期間、障害修正、導入実績、運用チームの習熟度も評価します。短期間で複数回の更新を繰り返すより、検証可能なリビジョン戦略を定めて変更単位を明確にする方が、監査と障害対応にも適しています。
アップデート前の環境確認
まず、SAP HANA cockpitまたはSAP HANA database explorerで、システムの稼働状態、サービス、データベース、アラートを確認します。SAP HANA cockpitでは、システムの状態やアラート、バックアップ状況をまとめて確認しやすくなります。SAP HANA database explorerでは、システムデータベースとテナントデータベースへの接続状態やSQLベースの確認を行えます。
次の項目を変更記録に残します。
- システムID、インスタンス番号、ホスト名
- システムデータベースと各テナントデータベースの状態
- 稼働中のサービスと重要なアラート
- ファイルシステムの空き容量
- OSユーザー、
<sid>admの利用可否 - 監視、バックアップ、ジョブ、外部接続の稼働状態
インスタンス番号やホストを使った運用操作を確認する場合は、SAP HANAの起動・停止手順も参照できます。アップデート前のベースラインを取得しておくと、完了後に性能やサービス状態を比較できます。
バックアップと復旧計画
アップデート前には、データバックアップ、ログバックアップ、設定情報、必要な暗号化ルートキーの保護状態を確認します。バックアップが正常終了したという表示だけでなく、保存先、保持期間、復旧に必要な認証情報、復旧テストの結果まで確認します。
バックアップ暗号化を使用している場合は、ルートキーを必ずバックアップし、キーを変更した後にも再度バックアップします。変更後のバックアップ暗号化ルートキーがバックアップされていない状態では、そのバックアップを復旧できません。この点は、アップデート計画の中で明示的に担当者と確認します。
データボリューム暗号化、ログボリューム暗号化、バックアップ暗号化は、それぞれ個別に設定されます。暗号化を利用する環境では、どのキーがどの用途に対応するかを記録し、保管場所へのアクセス権限も確認します。
復旧計画には、アップデートが予定どおり完了しない場合の判断基準を含めます。たとえば、サービス起動、データベース接続、バックアップ、アプリケーション接続のどの状態をもって継続または復旧開始とするかを、作業前に合意します。
インストールメディアと権限の準備
SAP HANA Serverの対象メディアを、実行ホストまたは計画した共有場所に準備します。ダウンロードしたファイルの完全性、使用するSAP HANAコンポーネント、適用対象のホストを確認します。分散システムでは、各ホストへの到達性と、必要なOSユーザーの権限も事前に確認します。
コマンドラインのライフサイクル管理にはhdblcmを使用します。グラフィカルフロントエンドはhdblcmguiです。両者を使い分けることで、標準化されたコマンド実行と対話型の確認を選択できます。パラメータ、ログの保存先、実行ユーザー、作業ディレクトリは変更記録に残します。
SAP HANA cockpitを導入する場合は、SAP HANA cockpitパッケージの内部からhdblcmを実行します。導入または更新の対象がSAP HANA Serverなのか、SAP HANA cockpitなのかを作業票で明確にし、異なるコンポーネントの手順を混在させないことが大切です。詳細はSAP HANA cockpitのインストールで確認できます。
hdblcmでアップデートを実行する
作業時間帯に入り、接続アプリケーション、バッチ、監視ジョブ、バックアップジョブを計画に沿って停止または抑制します。その後、対象システムの状態と直前バックアップを確認し、アップデートを開始します。
hdblcmでは、対象コンポーネント、インストールメディア、インストール先、管理ユーザーの認証情報などを確認しながら処理を進めます。入力内容は、対象システム、ホスト、インスタンス番号、適用するメディアと一致していることを確認します。ログは後日の監査や障害分析に使用できるよう、安全な場所へ保存します。
hdblcmguiを利用する場合も、画面に表示される対象、コンポーネント、事前チェックの結果を記録します。GUI操作では、選択したホストや対象コンポーネントを見落としやすいため、実行前の確認画面を変更記録に添付すると有効です。
処理中は、サービス停止、ファイル更新、データベース起動、コンポーネント検証の進行を監視します。エラーが発生した場合は、ログ、エラーコード、発生時刻、直前の処理を保存し、独断で再実行せず、定めた判断基準に従います。
テナントデータベースの確認
アップデート後は、システムデータベースだけでなく、すべてのテナントデータベースを確認します。M_DATABASESでテナントの一覧と状態を確認し、各テナントへ接続して、業務ユーザー、アプリケーション接続、ジョブ、バックアップの状態を検証します。
特定のテナントだけを起動または停止する運用操作では、システムデータベース上でALTER SYSTEM START DATABASE <name>またはALTER SYSTEM STOP DATABASE <name>を使用します。SAP HANA全体を扱うHDBスクリプトやsapcontrolは、個別テナントの操作ではなく、システム全体の起動・停止に使用します。
SAP HANA 2.0のマルチテナント構成では、システムデータベースとテナントデータベースの状態を分けて記録します。テナント数が多い環境では、接続確認表を作成し、テナント名、接続先、代表的な業務処理、確認結果、確認者を一覧化すると漏れを抑えられます。
アップデート後の検証
検証は、ソフトウェアのバージョン確認だけで終了させません。次の順序で、基盤から業務まで段階的に確認します。
- すべての必要なサービスが稼働している
- システムデータベースとテナントデータベースへ接続できる
- 重大なアラートが発生していない
- データバックアップとログバックアップが継続している
- 監視、ジョブ、外部インターフェースが正常に動作する
- 代表的な照会、登録、更新、帳票処理を実行できる
- 性能、メモリ、ディスク使用量が許容範囲にある
アップデート前後で、接続時間、代表SQLの実行時間、バッチ所要時間、エラー件数を比較します。列ストアの利用状況を確認する場合は、M_CS_TABLESのMEMORY_SIZE_IN_TOTALとRECORD_COUNTを使って、主要テーブルのメモリ使用量とレコード数を確認できます。
性能問題が疑われる場合は、変更前のベースラインと比較し、アラート、トレース、SQL実行状況を調べます。アップデート直後の一時的な処理と、継続的な性能劣化を分けて判断することが重要です。
作業記録と運用への引き継ぎ
作業完了後は、実行日時、担当者、対象ホスト、対象コンポーネント、使用メディア、実行ログ、バックアップ結果、検証結果を変更記録へまとめます。未解決の警告や監視上の注意点があれば、担当チーム、期限、暫定対応を明記します。
運用手順書には、更新後のバージョン確認方法、起動停止の担当範囲、テナント確認手順、バックアップ確認、障害時の連絡先を反映します。次回の更新で同じ調査を繰り返さないよう、所要時間と発生した問題も記録します。
SAP HANAアップデートは、メディアを適用する一回の作業ではなく、計画、保護、実行、検証、引き継ぎからなる変更管理です。環境ごとの検証結果を蓄積し、再現可能な更新プロセスとして整備すると、停止時間と運用リスクを抑えやすくなります。