インメモリコンピューティングのセキュリティ
SAP HANA インメモリデータベースでは、パフォーマンスを最大限に高めるために大半のデータがメモリ内に保持されます。しかしそれでも、障害の場合にフォールバックを提供するために、永続ストレージが使用されます。データおよび UNDO ログ情報 (データの一部) は定期的なセーブポイントで自動的にディスクへ保存されますログでは、すべての変更が REDO ログとしてキャプチャされます。これらの変更は、データベーストランザクションによって COMMIT が実行されるたびに (ディスク書込操作の終了を待ってから)、ディスクに継続的かつ同期的に保存されます。
電源障害後、データベースはディスクベースのデータベースと同じように再起動することができます。
SAP HANA データベースの起動
SAP HANA システムの再起動シーケンスを通じて、システムが完全な稼働状態にすばやく復元されます。
注記
システムの再起動後に、メインメモリにただちにロードされるテーブルは、デフォルトでは一部のみです。
システムは通常の方法で再起動されます (再起動時間を短くするためにテーブルを "レイジー" に再ロード)。
システムは直近の整合性のある状態に復帰します (直近のセーブポイント以降の REDO ログを再生)。
再起動プロセス
データベースの再起動時 (クラッシュ後など) には、直近に完了したセーブポイントからのデータをデータボリュームから読み込むことができます。また、直近のセーブポイント以降に書き込まれた REDO ログエントリは、ログボリュームから読み込まれます。
再起動時には、データページのセーブポイントバージョンからシステムが復元されます。この方法では、直近のセーブポイント以降に書き込まれたすべてのデータ変更が自動的にロールバックされます。セーブポイントが復元された後、直近のコミットされた状態を復元するためにログが再生されます。
起動時には、直近のセーブポイントの一部として保存された未コミット状態の変更もロールバックする必要があります。これらの変更を元に戻す際には、UNDO 情報はセーブポイントの一部として保存されます。これは、UNDO レコードを書き込むためのインタフェースを提供する UNDO マネージャによって実行されます。UNDO 情報は、トランザクションごとに 1 つの仮想 UNDO ファイルに書き込まれます。仮想 UNDO ファイルは、データボリュームに保持されるデータページで構成されます。つまり、UNDO エントリは最初にページバッファを通過し、次のセーブポイントまで保持されます。
起動プロセス: パーシスタンスレイヤアクティビティ
注記
注記
通常のシャットダウンではセーブポイントが書き込まれるため、通常のシャットダウン後に処理が必要な再生ログエントリはありません。
ローストアについては常にそのすべてがロードされますが、メモリにロードされるのは、必須となるカラムテーブルの列のみです。他の列については、要求された場合にロードされます。
たとえば、クエリがあるテーブルの一部の項目 (列) のみを使用する場合、その項目のみがクエリ実行時にメモリにロードされます。すべてのローベーステーブル (通常はシステムテーブル) は、メインメモリで利用可能です。そのテーブルのサイズは、データベースの起動に必要な時間に大きく影響します。起動時間に影響するその他の要因については、図 "SAP HANA 起動プロセス" を参照してください。
起動プロセス
起動パフォーマンスの重要な要因
インメモリデータベースが統合されている SAP HANA システムを起動するために必要な時間は、複数の要因の影響を受けます。以下の一覧は、最も重要な要因の特定に役立ちます。
再生するログの量 (ロールフォワード)
コミットされていないトランザクションによる変更の量 (ロールバック)
ログボリューム (ディスク) の読込パフォーマンス
データボリューム (ディスク) の読込/書込パフォーマンス
レイアウト設計: ログとデータのディスク領域の分離 (論理的だけでなく物理的)
起動プロセス: テーブル
SAP HANA の通常運用時には、現在ロードされているカラムテーブルの一覧が追跡されます (1 日 1 回)。再起動時にメインメモリにロードする必要があるテーブルは、この一覧に基づくことになります。こうした方法でカラムテーブルを再ロードすることにより、データベースをより早く完全に稼働状態に復元することができます。ただし、これによりパフォーマンスオーバーヘッドが発生します。また、この方法は非本稼働システムでは不要な場合があります。再ロード機能を無効にするには、indexserver.ini ファイルの sql セクションの reload_tables パラメータを false に設定します。さらに、indexserver.ini の parallel セクションで tables_preloaded_in_parallel パラメータを使用して、属性が並列にロードされるテーブルの数を設定することができます。
注記
個別の列も全カラムテーブルも、プリロードの対象として設定できます。
Preload チェックボックスを選択すると、インデックスサーバの起動後にテーブルが自動的にメモリにロードされます。Preload チェックボックスの現在のステータスは、システムテーブル TABLES の PRELOAD 列に表示されます。この列が取る値は、FULL、PARTIALLY、NO です。また、システムテーブル TABLE_COLUMNS の PRELOAD 列の値については、TRUE または FALSE を取ることができます。
注記
大きなカラムテーブルの項目がメインメモリにない場合、テーブルへの最初のアクセスが大幅に遅くなる可能性があります。これは、クエリを実行する前に、要求されたすべての列がメインメモリにロードされるためです。これは、単独レコードを選択した場合においても当てはまります。
- プリロードされるテーブルの一覧に関する情報を表示します (プリロードフラグに関連する列ではありません)。 Code Snippet1hdbcons "tablepreload i"
- 全コンテンツを表示します (テーブル一覧)。 Code Snippet1hdbcons "tablepreload c -f"
- データボリューム内の仮想ファイルに追加のプリロード情報を書き込みます。 Code Snippet1hdbcons "tablepreload w -s"
- ヘルプの完全な一覧を表示します。 Code Snippet1hdbcons help[Enter]
特定のコマンドに関する hdbcons ヘルプを表示します。
Code Snippet1hdbcons "help tablepreload"
注意
初期クエリを高速化する目的で、単純にすべてのテーブルをプリロード対象として選択すると、起動時間が非常に遅くなることがあります。Preload チェックボックスはチューニングオプションの 1 つであり、個別のシナリオおよび要件に従い、慎重に使用する必要があります。
