SAP
SAP HANAのデルタマージとは？仕組み・実行条件・遅いときの確認方法
SAP HANAのデルタマージについて、メインストレージとデルタストレージの関係、自動マージの条件、処理が遅い場合の確認ポイント、運用上の注意点を管理者向けに解説します。
SAP HANAの運用で「デルタマージとは何か」「なぜマージが必要なのか」「処理が遅いときは何を確認すべきか」と疑問に感じることがあります。デルタマージは、更新データを一時的に保持する領域と、圧縮された読み取り用データを統合する重要なメンテナンス処理です。
特に、書き込みが多いテーブルや大規模な列ストアテーブルでは、デルタ領域の増加がメモリ使用量、検索性能、マージ処理時間に影響します。この記事では、SAP HANAの管理者が押さえたい基本概念から、監視とトラブルシューティングまでを順に説明します。
SAP HANAのデルタマージとは
デルタマージとは、列ストアテーブルのデルタストレージに蓄積された変更データを、メインストレージへ統合する処理です。SAP HANAでは、データを常に一つの領域へ直接書き込むのではなく、読み取りに適したメインストレージと、変更を受け入れやすいデルタストレージを使い分けます。
通常の書き込み処理では、INSERT、UPDATE、DELETEなどの変更がまずデルタストレージに記録されます。その後、デルタマージによって変更内容がメインストレージへ反映され、デルタ領域が整理されます。これにより、読み取り処理は圧縮と辞書エンコードが適用されたメインストレージを効率的に利用できます。
デルタマージは、単なるファイル整理ではありません。書き込み性能と読み取り性能のバランスを取るための、列ストアの基本的な仕組みです。マージを無制限に実行すればよいわけではなく、変更量、メモリ、CPU、同時実行中の処理を考慮して管理する必要があります。
メインストレージとデルタストレージの違い
メインストレージ
メインストレージは、列ごとにデータを保持し、圧縮や辞書エンコードによって読み取りを効率化する領域です。分析クエリや集計処理では、必要な列だけを読み取れるため、行ストアと比べて大量データの検索に向いています。
一方で、メインストレージは頻繁な更新を直接受け付ける用途には適していません。データ全体の再編成や圧縮が必要になるため、少量の変更を都度メインストレージへ反映すると、書き込みコストが高くなります。
デルタストレージ
デルタストレージは、新規データや更新、削除などの変更を一時的に保持する領域です。変更を先にデルタへ書き込むことで、トランザクションの書き込み処理を効率化できます。
ただし、デルタストレージにデータが蓄積し続けると、検索時にメインとデルタの両方を参照する必要があります。また、更新が多い場合は削除済み行や変更履歴の管理コストも増加します。そのため、適切なタイミングでデルタマージを実行することが重要になります。
二つの領域を使い分ける理由
メインストレージは読み取りに強く、デルタストレージは変更の受け入れに強いという特徴があります。SAP HANAはこの役割分担によって、リアルタイム分析と高頻度なデータ更新を両立します。
ただし、デルタマージ中にはCPU、メモリ、I/Oなどのリソースが使われます。したがって、マージの頻度だけでなく、システム全体の負荷とのバランスを見ることが管理上のポイントです。
デルタマージの基本的な仕組み
デルタマージは、概念的には次の流れで進みます。
- アプリケーションが列ストアテーブルへデータを挿入、更新、削除する。
- 変更内容がデルタストレージへ記録される。
- 自動または手動のマージが開始される。
- デルタの変更内容がメインストレージへ統合される。
- 新しいメインストレージが作成され、古い領域が解放される。
- マージ後のデルタ領域が再び変更を受け入れる。
実際の内部処理は、テーブルのサイズ、パーティション構成、圧縮状態、トランザクションの状況などによって異なります。大規模テーブルでは、一度のマージで多くのリソースを使う場合があるため、処理開始時刻と完了時刻を記録して傾向を把握します。
また、マージ中に同じテーブルへの書き込みが発生することもあります。新しい変更はマージ対象とは別のデルタ領域へ記録され、マージ完了後もデルタが残る場合があります。このため、処理が成功していてもデルタサイズが完全にゼロになるとは限りません。
自動デルタマージが実行される条件
SAP HANAでは、通常、システムが適切なタイミングで自動デルタマージを実行します。自動実行の判断には、デルタ領域のサイズ、変更量、テーブルの状態、システムリソースなど複数の要素が関係します。
管理者が見るべきなのは、単に「自動マージが有効か」だけではありません。次のような状況では、マージが期待どおりに進んでいない可能性があります。
- デルタサイズが長時間増え続けている
- マージの開始は記録されるが完了しない
- メモリ不足やリソース競合によってマージが中断される
- テーブルに長時間のトランザクションが残っている
- パーティションの一部だけに更新が集中している
- バックアップやロードなど別の重い処理と時間帯が重なっている
自動マージのしきい値や挙動は、SAP HANAのバージョン、テーブルの種類、設定、運用環境によって異なります。したがって、特定の数値をすべてのシステムへ一律に適用するのではなく、製品バージョンのドキュメントと実際の監視データを併せて判断します。
手動デルタマージを検討する場面
手動マージは、検証環境や計画停止に近いメンテナンス時間帯など、影響を評価できる場合に限定して検討します。運用中の本番環境で、デルタサイズが大きいという理由だけで繰り返し手動実行するのは避けるべきです。
手動実行を検討しやすい例は、次のとおりです。
- 大量データのロード後に計画的な整理を行う場合
- 自動マージの完了を待つと業務処理に影響する場合
- メンテナンス手順の一部として、実行時間を管理できる場合
- 検証環境でマージ時間とリソース消費を測定する場合
実行前には、対象テーブル、対象ホスト、メモリ空き容量、CPU使用率、実行中のバックアップやロードを確認します。手動マージは、根本原因を解決する機能ではありません。書き込み量が過大、クエリ設計に問題がある、パーティションが不適切といった原因が残っていれば、再びデルタが増加します。
SAP HANAのデルタマージが遅い主な原因
「sap hana merge 遅い」という状況では、処理そのものの速度だけでなく、開始できない、途中で待機する、完了後も負荷が続くといった状態を区別します。
1. データ量が大きい
対象テーブルやパーティションのデータ量が大きいほど、圧縮、辞書の再構築、データ配置の変更に時間がかかります。特に長期間マージされていなかったテーブルでは、単回の処理量が大きくなることがあります。
2. メモリに余裕がない
デルタマージでは、処理中に一時的なメモリが必要になります。通常のデータサイズだけを見て「空きがある」と判断すると、マージ用の追加領域を見落とすことがあります。マージ処理と業務クエリが同時にメモリを使用すると、処理が遅延したり、失敗したりする可能性があります。
3. CPUやI/Oの競合
大量の集計、データロード、バックアップ、レプリケーション関連処理が同時に実行されると、マージに割り当てられるリソースが不足します。時間帯によって処理時間が大きく変わる場合は、同時実行ジョブとの関係を確認します。
4. 長時間トランザクション
古いスナップショットや長時間継続するトランザクションがあると、古いバージョンのデータをすぐに解放できないことがあります。アプリケーション側のトランザクション管理も含めて調査する必要があります。
5. パーティションや更新分布の問題
大きなテーブルでも、更新が一部パーティションに集中している場合と、全パーティションへ広がっている場合では、処理の特徴が異なります。パーティション設計が実際のアクセスパターンに合っていないと、マージやクエリの負荷が偏ることがあります。
デルタマージの監視ポイント
調査では、単一の画面や単一の数値だけで結論を出さないことが大切です。テーブル単位、ホスト単位、時間軸の三つの視点で情報を組み合わせます。
テーブル単位で確認する情報
- テーブルの総サイズ
- デルタストレージのサイズ
- デルタレコード数や変更量
- 最終マージ時刻
- マージの実行回数と所要時間
- パーティションごとのサイズと偏り
システム単位で確認する情報
- ホスト別のメモリ使用量
- CPU使用率とロード状況
- ディスクI/Oの待機時間
- マージ中の同時実行ジョブ
- アラートやトレースに記録されたエラー
- バックアップ、ロード、レプリケーションの実行状況
SAP HANA cockpitを利用できる環境では、監視画面の概要から異常な負荷やアラートを確認し、必要に応じて詳細なテーブル情報へ進みます。cockpitの表示だけで判断できない場合は、システムビューやSQLによる履歴確認を組み合わせます。環境によって利用できるビューや権限が異なるため、実行するSQLは対象バージョンの公式ドキュメントで確認してください。
デルタマージのトラブルシューティング手順
障害や性能劣化が発生した場合は、次の順番で切り分けると、不要な手動操作を減らせます。
Step 1：影響範囲を確認する
特定のテーブルだけが遅いのか、複数のテーブルやシステム全体に影響しているのかを確認します。アプリケーションの応答時間、SQLの実行時間、メモリ使用量、アラート発生時刻を同じ時間軸で並べます。
Step 2：マージが実行中か、待機中かを分ける
マージが実行中であれば、対象テーブルと開始時刻、進行状況、消費リソースを確認します。実行記録がない場合は、自動実行条件、無効化設定、権限、スケジューラの状態などを調べます。
Step 3：メモリと同時実行処理を確認する
マージ時間帯に、バックアップ、データロード、重い集計、インデックス関連処理などが重なっていないか確認します。メモリ不足が疑われる場合は、マージだけを再実行する前に、不要な処理の停止やスケジュール変更を検討します。
Step 4：長時間トランザクションを確認する
長時間継続しているセッションや、終了していないアプリケーション処理がないか調べます。強制終了は業務影響やロールバックを伴う可能性があるため、所有者と影響を確認してから実施します。
Step 5：テーブル設計を見直す
更新頻度、アクセス条件、パーティションキー、データ保持期間を確認します。マージの頻度を増やすだけでは、データモデルやロード処理の問題を隠してしまうことがあります。
Step 6：結果を記録する
対象テーブル、開始時刻、終了時刻、処理中の負荷、エラー、実施した対策を記録します。記録があれば、同じ時間帯に再発した際の比較が容易になり、容量計画やジョブ設計にも活用できます。
デルタマージとメモリ管理
デルタマージを理解するには、通常時のデータ使用量と、処理中に必要な一時領域を分けて考える必要があります。マージの開始前に十分な空きがあっても、処理中の中間データや新しい書き込みによって余裕が小さくなる場合があります。
メモリの確認では、システム全体の使用率だけでなく、ホストごとの偏り、サービスごとの使用状況、急増の時刻を見ます。過去のピークと比較し、マージ開始時にだけ使用量が跳ね上がっているか、ロードやクエリでも同じ傾向があるかを確認します。
また、メモリ不足を解決するために、根拠なくパラメータを変更したり、キャッシュを一律に削除したりするのは危険です。まずはデータ保持期間、ロード方式、クエリ、パーティション、同時実行数を確認し、再発防止につながる対策を優先します。
運用で避けたいデルタマージの誤解
「デルタがあると必ず性能が悪い」という誤解
デルタストレージは通常の書き込み処理に必要な領域です。デルタが存在すること自体が異常ではありません。問題は、変更量に対してデルタが過剰に増え続けているか、検索やメモリ使用量に実際の影響が出ているかです。
「頻繁に手動マージすればよい」という誤解
マージにはリソースが必要であり、過度な実行はCPU、メモリ、I/Oの競合を招きます。自動マージの挙動を理解し、業務負荷と合わせて実行計画を設計することが重要です。
「マージが完了すれば原因は解決する」という誤解
マージは蓄積した変更を統合する処理であり、更新量の多さ、長時間トランザクション、設計上の偏りを自動的に解消するものではありません。完了後もデルタ増加率や処理時間を観測し、根本原因を確認します。
「全テーブルに同じ対策を適用できる」という誤解
テーブルのサイズ、更新頻度、パーティション、業務時間帯はそれぞれ異なります。あるテーブルで有効だったスケジュールやしきい値が、別のテーブルでも適切とは限りません。
実務で使える確認チェックリスト
デルタマージの調査や定期レビューでは、次のチェックリストを利用できます。
- 対象テーブルとパーティションを特定したか
- デルタサイズと変更量の推移を確認したか
- 最終マージ時刻と処理時間を確認したか
- マージが実行中、待機中、失敗のどれかを区別したか
- メモリ、CPU、I/Oのピーク時刻を確認したか
- バックアップやロードなどの同時実行処理を確認したか
- 長時間トランザクションを確認したか
- アラート、トレース、エラーメッセージを確認したか
- 手動マージの影響とロールバック方針を確認したか
- 実施前後の結果を記録したか
この順番で確認すれば、いきなり手動マージを実行するのではなく、症状と原因の関係を整理できます。特に本番環境では、操作の実行者、承認、影響範囲、監視担当を明確にしてから作業します。
まとめ
SAP HANAのデルタマージは、デルタストレージに蓄積された変更をメインストレージへ統合する処理です。デルタは書き込みを効率化するために必要ですが、増加し続けると検索、メモリ、マージ時間に影響する可能性があります。
「SAP HANAのデルタマージが遅い」ときは、データ量だけでなく、メモリ、CPU、I/O、長時間トランザクション、パーティション、同時実行ジョブを確認します。手動マージは一時的な対処であり、実行前後の影響を測定し、根本原因の改善につなげることが大切です。
FAQ
デルタマージとは何ですか？
列ストアテーブルのデルタストレージに蓄積された変更を、メインストレージへ統合する処理です。書き込みを受け入れやすい領域と、読み取りに適した領域を整理する役割があります。
デルタストレージがあるのは異常ですか？
いいえ。通常の書き込み処理で使用されるため、デルタが存在すること自体は異常ではありません。増加が継続しているか、性能やメモリに影響しているかを確認します。
デルタマージは手動で実行すべきですか？
常に手動実行する必要はありません。自動マージの状況、システム負荷、対象テーブルの変更量を確認し、計画的に実施できる場合だけ検討します。
デルタマージが遅い場合、最初に何を見ますか？
対象テーブル、デルタサイズ、マージの開始と終了、メモリ、CPU、I/O、同時実行ジョブを確認します。長時間トランザクションやパーティションの偏りも重要です。
デルタマージとバックアップには関係がありますか？
両者は別の処理ですが、同じ時間帯に実行されるとメモリやI/Oの競合が発生する可能性があります。処理スケジュールとシステム負荷を合わせて確認してください。