SAP HANA
SAP HANA開発者向け性能チューニング：SQLScriptとCalculation Viewの改善手順
SAP HANAオンプレミスで開発者が実践できる性能チューニング手順を解説。SQLの計測、SQLScript、Calculation View、テーブル関数、メモリ確認、リグレッション検証までを体系的に整理します。
SAP HANA開発者向け性能チューニングの基本
SAP HANAの開発性能を改善するときは、SQL文を単純に書き換えるのではなく、処理時間、読み取ったデータ量、メモリ消費量、並列実行の状態を分けて確認します。最初に遅い処理を特定し、変更前の実行結果を保存してから、1つずつ変更を加えて再計測する流れが安全です。
開発環境では短いデータ量で問題が見えなくても、本番相当の件数や選択性でボトルネックが現れます。代表的なデータ量と利用者が実行する条件をそろえ、同じ接続先と同じパラメータで比較します。
設計全体の確認には、まずSAP HANA開発の全体像を参照し、アプリケーション、永続化モデル、Calculation View、SQLScriptの境界を整理します。性能問題がデータモデルに起因する場合、SQLだけを修正しても改善が限定的です。
計測から始める性能分析
性能チューニングの開始点は、体感ではなく測定値です。SAP HANAデータベースエクスプローラーでSQLを実行し、実行時間、実行計画、処理対象の行数を確認します。SAP HANA cockpitでは負荷の高いサービスや時間帯を確認し、個別SQLの分析とシステム全体の監視を組み合わせます。
次の情報を変更前に記録します。
- SQL文とバインド値
- 実行時間と実行回数
- 結果セットの行数
- 実行計画で大きなコストを持つ演算子
- 同時実行中の処理とピーク時間
- 対象テーブルのレコード数とメモリ使用量
同じSQLでも、データ分布、統計情報、同時実行数によって結果が変わります。単発実行の最短時間だけで判断せず、複数回の実行と業務時間帯の負荷を比較します。
ホスト全体のメモリ状況は SYS.M_HOST_RESOURCE_UTILIZATION で確認できます。たとえば、次の列を使ってホストの使用量と割り当て上限を確認します。
SELECT HOST,
USED_PHYSICAL_MEMORY,
FREE_PHYSICAL_MEMORY,
ALLOCATION_LIMIT,
INSTANCE_TOTAL_MEMORY_USED_SIZE,
INSTANCE_TOTAL_MEMORY_ALLOCATED_SIZE
FROM SYS.M_HOST_RESOURCE_UTILIZATION;
サービス単位では SYS.M_SERVICE_MEMORY の TOTAL_MEMORY_USED_SIZE を確認します。SQL実行が遅い場合でも、メモリ圧迫やサービス間の競合が同時に発生していないかを切り分けます。
SQLの実行計画を読む
SQLチューニングでは、実行計画の上から順に読むのではなく、大量データを処理する演算子と結果を急激に増やす結合を探します。フィルタが遅いのか、結合が遅いのか、集約やソートが遅いのかを分けると、修正箇所を絞り込めます。
確認する観点は次のとおりです。
- 必要な列だけを読み取っているか
- 早い段階で条件を適用できているか
- 結合前にデータを適切に絞り込めているか
- 不要な重複排除、ソート、集約がないか
- 暗黙の型変換が条件や結合キーに発生していないか
- 結果を返す前に過剰な行を生成していないか
SELECT * は列追加の影響を受けやすく、転送量と後続処理量を増やします。画面やAPIが必要とする列だけを明示し、ページングや期間条件を業務要件に合わせて設計します。
結合では、結合キーのデータ型と意味をそろえます。文字列化した日付や数値を結合条件の中で変換すると、読みやすさだけでなく実行計画にも影響します。変換が必要な場合は、モデル層で統一された型を提供します。
SQLScriptのパフォーマンス改善
SQLScriptは、処理をデータベース内で実行できる利点を生かして設計します。行単位のループや一時的な中間結果を多用すると、列指向処理の利点が小さくなります。集合演算で表現できる処理は、可能な範囲でSQLの集合処理としてまとめます。
改善手順は、処理を小さな単位に分解して各文の入出力を測定することです。複数の中間テーブル変数を作る場合は、各段階で行数と列数を確認し、後続処理に不要なデータを早期に除外します。
SQLScriptの確認ポイント
- ループ内で同じSQLを繰り返していないか
- 条件分岐の前に不要な全件読み取りをしていないか
- 中間結果に不要な列や重複行が残っていないか
- 例外処理やログ出力が大量データで過剰になっていないか
- プロシージャ間で同じ集計を重複実行していないか
プロシージャの構造やデバッグ方法はSAP HANA SQLScriptプロシージャの実装ガイドで確認できます。性能検証では、処理の正しさを確認したテストデータを使い、入力件数を増やしたときの増加率も記録します。
Calculation Viewを高速化する設計
Calculation Viewでは、ノードを追加するたびにデータの流れと行数を確認します。不要なProjection、早期に適用できる条件、結合のカーディナリティ、集約の位置が主要な確認点です。
Projectionでは必要な列だけを残し、利用者の入力条件が下流まで伝わる構成を作ります。フィルタを最終出力付近に置くと、途中の結合や集約が大量行を処理することがあります。業務上安全な条件は、できるだけデータ量が少ない段階で適用します。
Joinでは、1対多や多対多の関係を正しく定義します。関係を誤って指定すると、結果行が意図せず増え、集計値も変わります。性能と結果の正確性を同時に確認するため、元データとの件数比較と代表キーの照合を行います。
Calculation Viewのノード構成やSQLベースの設計を比較するときは、Calculation Viewの種類と使い分けも役立ちます。既存ビューを改修する場合は、利用者、権限、依存するビューを確認してから変更します。
テーブル関数とデータモデルの見直し
テーブル関数は再利用しやすい一方、複雑な処理を一つに隠すと、呼び出し側からコストが見えにくくなります。入力条件を明確にし、必要な列と行だけを返す設計にします。複数の呼び出し元で異なる条件を使う場合は、関数内で条件が適切に適用されることを確認します。
テーブル関数の設計と利用場面はSAP HANAテーブル関数の実践ガイドで整理できます。関数を追加した後は、単体テストだけでなく、Calculation Viewやアプリケーションから呼び出したときの実行計画も確認します。
列ストアテーブルのサイズと件数は M_CS_TABLES の MEMORY_SIZE_IN_TOTAL と RECORD_COUNT で確認します。たとえば、対象テーブルの容量を調べるときは次のようにします。
SELECT SCHEMA_NAME,
TABLE_NAME,
MEMORY_SIZE_IN_TOTAL,
RECORD_COUNT
FROM M_CS_TABLES
WHERE SCHEMA_NAME = 'APP_SCHEMA';
大量の更新が続くテーブルでは、デルタ領域とメイン領域の状態も確認します。更新処理、読み取り処理、マージのタイミングが競合する場合は、業務時間帯の負荷と運用設定を合わせて評価します。
メモリと同時実行の切り分け
SQLが遅い原因がクエリ自体ではなく、同時実行やメモリ圧迫である場合があります。SAP HANA cockpitの監視画面で、問題発生時刻のホストメモリ、サービスメモリ、CPU、長時間実行処理を照合します。SAP HANAデータベースエクスプローラーでは、対象SQLの実行計画と実行履歴を確認します。
ホストのメモリ使用量が高い場合は、次の順に切り分けます。
- 同時刻に実行された高負荷SQLを特定する
SYS.M_HOST_RESOURCE_UTILIZATIONの使用量と割り当て量を確認するSYS.M_SERVICE_MEMORYのTOTAL_MEMORY_USED_SIZEをサービス別に確認する- 大きなCalculation View、集計、エクスポート処理を特定する
- 開発変更前後でメモリと処理時間を比較する
単一SQLの改善だけでなく、同時実行時の最大メモリと処理待ち時間も受け入れ基準に含めます。負荷試験では、通常時、ピーク時、長時間連続実行の3条件を分けると、短時間では見えない問題を検出できます。
変更後の検証と運用引き継ぎ
性能改善の変更は、結果の正確性、権限、同時実行、障害時の調査性を含めて検証します。実行時間が短くなっても、行の重複や欠落、NULLの扱い、集計境界が変わっていれば本番投入できません。
検証記録には、変更前後のSQLまたはモデル、入力件数、実行時間、結果件数、メモリ使用量、実行計画の差分を残します。SAP HANA cockpitで監視する指標とアラート条件も運用担当者に共有します。
アプリケーション側のテストやデバッグでは、SAP HANAアプリケーションのテストとデバッグを関連手順として参照できます。リリース後は、代表的な業務処理を定期的に再計測し、データ量の増加による性能劣化を早期に把握します。
性能チューニングは一度のSQL修正で完了する作業ではありません。計測、仮説、変更、検証、監視のサイクルを小さく回し、データモデルとアプリケーションの両方に改善結果を反映することが重要です。