REFRESH TABLE ステートメント

REFRESH TABLE ステートメントは、マテリアライズ照会表内のデータをリフレッシュします。

呼び出し

このステートメントは、アプリケーション・プログラムに組み込んだり、動的 SQL ステートメントを使用して発行したりすることができます。 このステートメントは、動的に作成できる実行可能ステートメントです。

許可

ステートメントの許可 ID によって保持されている特権には、少なくとも以下のいずれかの権限が含まれていなければなりません。
  • 表に対する CONTROL 特権
  • マテリアライズ照会表が含まれるスキーマに対する DATAACCESS 権限
  • DATAACCESS 権限

構文

構文図を読む構文図をスキップするREFRESH TABLE ,table-nameonline-optionsquery-optimization-options INCREMENTALNOT INCREMENTAL
online-options
構文図を読む構文図をスキップするALLOW NO ACCESSALLOW READ ACCESSALLOW WRITE ACCESS
query-optimization-options
構文図を読む構文図をスキップするALLOW QUERY OPTIMIZATIONUSING REFRESH DEFERRED TABLESWITH REFRESH AGE ANY

説明

table-name
リフレッシュする表を指定します。
名前 (暗黙的または明示的なスキーマ名を含む) は、 現行サーバーに既に存在する表を指定していなければなりません。 表は、REFRESH TABLE ステートメントを許可していなければなりません (SQLSTATE 42809)。 これには、次のステートメントで定義したマテリアライズ照会表が含まれます。
  • REFRESH IMMEDIATE
  • REFRESH DEFERRED
online-options
処理中の表のアクセス可能性を指定します。
ALLOW NO ACCESS
他のユーザーは、非コミット読み取り分離レベルを使用している場合を除き、更新中の表にアクセスできないことを指定します。
ALLOW READ ACCESS
他のユーザーは更新中の表に対して読み取り専用アクセスを持つことを指定します。
ALLOW WRITE ACCESS
他のユーザーは更新中の表に対して読み取り/書き込みアクセスを持つことを指定します。
ALLOW READ ACCESS オプションまたは ALLOW WRITE ACCESS オプションを使用する場合は、ロック・タイムアウトが原因でステートメント全体がロールバックされる事態を避けるために、REFRESH TABLE ステートメントを実行する前に、SET CURRENT LOCK TIMEOUT ステートメントを (WAIT オプションを指定して) 実行することによって、後でその特殊レジスターを元の値にリセットすることをお勧めします。 ただし、CURRENT LOCK TIMEOUT レジスターは、すべてのロック・タイプではなく、特定セットのロック・タイプだけに影響を与えます。
query-optimization-options
REFRESH DEFERRED マテリアライズ照会表のリフレッシュに関する照会最適化オプションを指定します。
ALLOW QUERY OPTIMIZATION USING REFRESH DEFERRED TABLES WITH REFRESH AGE ANY
CURRENT REFRESH AGE 特殊レジスターが「ANY」に設定されている場合に、table-name のリフレッシュで REFRESH DEFERRED マテリアライズ照会表を使用することによって、table-name のリフレッシュに使用する照会を最適化できるようにすることを指定します。 table-name が REFRESH DEFERRED マテリアライズ照会表でない場合は、エラーが戻されます (SQLSTATE 428FH)。 REFRESH IMMEDIATE マテリアライズ照会表は、常に照会の最適化のために考慮されます。
INCREMENTAL
基礎表のデルタ部分 (ある場合) か、 関連したステージング表の内容 (この表があり、内容が一貫している場合) だけを考慮する方法での、 表の増分リフレッシュを指定します。 この要求が満たされない場合 (例えば、 システムがマテリアライズ照会表定義を完全に再計算する必要があると判断する場合)、 エラー (SQLSTATE 55019) が戻されます。
NOT INCREMENTAL
マテリアライズ照会表の定義を再計算する方法での、表のフル・リフレッシュを指定します。

INCREMENTAL と NOT INCREMENTAL をどちらも指定しない場合、 システムは増分処理が可能かどうかを判断します。 それが可能でなければ、フル・リフレッシュが実行されます。 リフレッシュ対象のマテリアライズ照会表に関するステージング表がある場合に、 ステージング表がペンディング状態のため増分処理ができないと、エラーが戻されます (SQLSTATE 428A8)。 ステージング表かマテリアライズ照会表が不整合な状態の場合は、フル・リフレッシュが実行されます。 不整合でない場合は、ステージング表の内容を使用して増分処理が行われます。

規則

  • 1 つ以上のニックネームを参照するマテリアライズ照会表に対して REFRESH TABLE を実行する場合は、データ・ソースの表から、またはデータ・ソースの表のすべてのスキーマから選択する権限がステートメントの許可 ID になければなりません (SQLSTATE 42501)。
  • システム保守のカラム・オーガナイズ MQT に対して REFRESH TABLE を実行する場合は、NOT INCREMENTAL 節を指定する必要があります。

注

  • このステートメントを使用して、 基礎表のロード、アタッチ、またはデタッチが行われた REFRESH IMMEDIATE マテリアライズ照会表をリフレッシュする場合には、 基礎表のデルタ部分を使用してマテリアライズ照会表の増分リフレッシュを行うことをシステムが選択する場合があります。 このステートメントを使用して、 ステージング表をサポートしている REFRESH DEFERRED マテリアライズ照会表をリフレッシュする場合には、 ステージング表にキャプチャーされた基礎表のデルタ部分を使用してマテリアライズ照会表の増分リフレッシュを行うことをシステムが選択する場合があります。 ただし、データの整合性を保証するために、この最適化を実行できずにフル・リフレッシュ (つまり、 マテリアライズ照会表の定義の再計算) を行う必要が生じる場合もあります。 INCREMENTAL オプションを指定して増分保守を明示的に要求することもできます。 この最適化を実行できない場合は、システムはエラーを戻します (SQLSTATE 55019)。
  • ALLOW QUERY OPTIMIZATION USING REFRESH DEFERRED TABLES WITH REFRESH AGE ANY オプションを使用する場合は、REFRESH DEFERRED マテリアライズ照会表のリフレッシュの順序が正しいことを確認してください。 例えば、2 つのマテリアライズ照会表 MQT1 と MQT2 があり、それぞれのマテリアライズ照会が同じ基礎表を共有するとします。 MQT2 に対するマテリアライズ照会は、基礎表ではなく MQT1 を使用して計算される場合があります。 この 2 つのマテリアライズ照会表をリフレッシュするために別々のステートメントを使用し、MQT2 を最初にリフレッシュする場合、システムは、MQT2 のリフレッシュのために、まだリフレッシュされていない MQT1 の内容を使用することを選択する可能性があります。 その場合、MQT1 には現在のデータが入りますが、両方のリフレッシュをほとんど同時に実行したとしても、MQT2 には失効したデータが入る可能性があります。 1 つではなく 2 つの REFRESH ステートメントを使用する場合は、MQT1 を最初にリフレッシュするのが正しい順序になります。
  • マテリアライズ照会表にステージング表が関連付けられている場合、 リフレッシュが正常に実行されるとそのステージング表は整理されます。
  • 基本表またはマテリアライズ照会表に対するラベル・ベースのアクセス制御は、リフレッシュ処理を妨げることはありません。 まるでラベル・ベースのアクセス制御が存在しないかのように、リフレッシュが発生します。 作成時にマテリアライズ照会表に関連付けられる自動保護により、基本表からマテリアライズ照会表に渡されるデータは継続的に保護されます。
  • マテリアライズ照会表に限り、SET INTEGRITY FOR mqt_name IMMEDIATE CHECKED は REFRESH TABLE mqt_name と同じです。
  • マテリアライズ照会表の使用のリフレッシュ: REFRESH TABLE ステートメントの処理中、マテリアライズ照会表は select-statement を評価するためには使用されません。
  • 分離レベルのリフレッシュ: select-statement を評価するために使用される分離レベルは、select-statement の isolation-level 節に対して指定された分離レベルです。 あるいは、isolation-level 節が指定されていない場合、CREATE TABLE または ALTER TABLE を発行したときに記録されたマテリアライズ照会表の分離レベルを使用して select-statement を評価します。
  • 次のステートメントについて考慮します。 
       SET INTEGRITY FOR T IMMEDIATE CHECKED
    以下のシナリオでは、T (T がマテリアライズ照会表 (MQT) またはステージング表の場合) に対する INCREMENTAL 検査オプションも増分リフレッシュもサポートされていません。
    • T が SET INTEGRITY ペンディング状態になっている間に、T に新しい制約が追加された場合。
    • T、その親、またはその基礎表に対する LOAD REPLACE 操作が行われた場合。
    • T、その親、またはその基礎表に対する最後の整合性検査の後に、 NOT LOGGED INITIALLY WITH EMPTY TABLE オプションがアクティブ化された場合。
    • 完全処理のカスケード効果により、T の親 (T がマテリアライズ照会表かステージング表である場合には、 基礎表) について、増分的ではない方法で整合性が検査された場合。
    • 表またはその親 (またはマテリアライズ照会表またはステージング表の基礎表) を含む表スペースが、 ある時点までロールフォワードされ、 表およびその親 (表がマテリアライズ照会表またはステージング表の場合は基礎表) が別の表スペースに存在する場合。
    • T が MQT で、最後のリフレッシュ後に、T に対する LOAD REPLACE 操作または LOAD INSERT 操作が直接行われる場合。
  • 増分処理の方が効率的であるため、可能な場合には増分処理が使用されます。 INCREMENTAL オプションは多くの場合必要ありません。 ただし、整合性検査が実際に増分に対して行われるようにすることが必要です。システムが、データ整合性を確保するために完全処理が必要だと判断すると、エラーが戻されます (SQLSTATE 55019)。
  • 上記の箇条書きの完全処理の条件が満たされなかった場合、ユーザーがステートメント SET INTEGRITY FOR T IMMEDIATE CHECKED に NOT INCREMENTAL オプションを指定していなければ、システムは増分リフレッシュを実行します (マテリアライズ照会表の場合)。