SET INTEGRITY ステートメント

SET INTEGRITY ステートメントは、表を SET INTEGRITY ペンディング状態に設定したり、表をフルアクセス状態にしたり、1 つ以上のステージング表のコンテンツを整理したりする場合に使用します。

SET INTEGRITY ステートメントで、以下の操作を実行できます。
  • 1 つ以上の表に対して必要な整合性処理を実行することによって、それらの表の SET INTEGRITY ペンディング状態 (以前の「チェック・ペンディング状態」) を解除する。
  • 1 つ以上の表に対して必要な整合性処理を実行せずに、それらの表の SET INTEGRITY ペンディング状態を解除する。
  • 1 つ以上の表を SET INTEGRITY ペンディング状態にする。
  • 1 つ以上の表をフル・アクセス状態にする。
  • 1 つ以上のステージング表の内容を整理する。

表のロード後またはアタッチ後に表の整合性処理を実行するためにこのステートメントを使用する場合、システムでは、制約違反の検査を追加部分だけに実行する、増分的な表の処理が可能です。 サブジェクト表がマテリアライズ照会表かステージング表であり、 その基礎表でロード、アタッチ、またはデタッチの操作が実行される場合、 システムは基礎表の差分部分だけを使用して、マテリアライズ照会表の増分的リフレッシュまたはステージング表への増分的伝搬を行えます。 ただし、システムがそのような最適化を実行できず、代わりに、 データ整合性を確保するために完全整合性処理を実行する場合もあります。 完全整合性処理は、制約違反がないか表全体を検査すること、マテリアライズ照会表の定義を再計算すること、またはステージング表を不整合としてマーク付けすることで行われます。 この 3 つ目の方法の場合、関連するマテリアライズ照会表のフル・リフレッシュが必要であることを意味します。 また、INCREMENTAL オプションを指定して、増分処理を明示的に要求できる場合もあります。

SET INTEGRITY ステートメントは、トランザクションの制御下にあります。

呼び出し

このステートメントは、アプリケーション・プログラムに組み込んだり、動的 SQL ステートメントを使用して発行したりすることができます。 これは、DYNAMICRULES の実行動作がパッケージに効力を持つ場合にのみ、動的に準備できる実行可能ステートメントです (SQLSTATE 42509)。

許可

SET INTEGRITY ステートメントの実行に必要な特権は、以下のリストに概要を示すように、目的によって異なります。

  • 必要な整合性処理を実行して、表の SET INTEGRITY ペンディング状態を解除する場合。
    ステートメントの許可 ID によって保持されている特権には、少なくとも以下のいずれかが含まれていなければなりません。
    • 以下に対する CONTROL 特権
      • 整合性処理が実行される表および、例外表がこのような表の 1 つ以上に用意されている場合、それらの例外表に対する INSERT 特権
      • ステートメントによって暗黙的に SET INTEGRITY ペンディング状態にされる、下層外部キー表、下層即時マテリアライズ照会表、および下層即時ステージング表のすべて。
    • LOAD 権限 (条件付き)。 適切な特権を与えるものとして LOAD 権限を考慮するには、以下の条件のすべてが満たされる必要があります。
      • 必要な整合性処理に以下のアクションが関係しない。
        • マテリアライズ照会表のリフレッシュ
        • ステージング表への伝搬
        • 生成列または ID 列の更新
      • 例外表が 1 つ以上の表に対して用意されている場合、整合性処理が実行される表および関連する例外表への整合性処理の間、必要なアクセスが与えられる。 すなわち、
        • 整合性処理が実行されるそれぞれの表に対する SELECT および DELETE 特権、および
        • 例外表に対する INSERT 特権
    • DATAACCESS 権限
  • 必要な整合性処理を実行しないで、表の SET INTEGRITY ペンディング状態を解除する場合。
    ステートメントの許可 ID によって保持されている特権には、少なくとも以下のいずれかが含まれていなければなりません。
    • 処理対象表に対する CONTROL 特権。ステートメントによって暗黙的に SET INTEGRITY ペンディング状態にされるそれぞれの下層外部キー表、下層即時マテリアライズ照会表、下層即時ステージング表に対する CONTROL 特権。
    • LOAD authority
    • DATAACCESS 権限
    • DBADM 権限
  • 表を SET INTEGRITY ペンディング状態にする場合。
    ステートメントの許可 ID によって保持されている特権には、少なくとも以下のいずれかが含まれていなければなりません。
    • 以下に対する CONTROL 特権
      • 指定された表
      • ステートメントによって SET INTEGRITY ペンディング状態にされる下層外部キー表
      • ステートメントによって SET INTEGRITY ペンディング状態にされる下層即時マテリアライズ照会表
      • ステートメントによって SET INTEGRITY ペンディング状態にされる下層即時ステージング表
    • LOAD authority
    • DATAACCESS 権限
    • DBADM 権限
  • 表をフル・アクセス状態にする場合。
    ステートメントの許可 ID によって保持されている特権には、少なくとも以下のいずれかが含まれていなければなりません。
    • フル・アクセス状態にする表に対する CONTROL 特権
    • LOAD authority
    • DATAACCESS 権限
    • DBADM 権限
  • ステージング表を整理する場合。
    ステートメントの許可 ID によって保持されている特権には、少なくとも以下のいずれかが含まれていなければなりません。
    • 整理する表に対する CONTROL 特権
    • DATAACCESS 権限

構文

構文図を読む構文図をスキップするSETINTEGRITYFOR,table-nameOFFaccess-mode-clausecascade-clauseFULL ACCESSPRUNEFOR,table-nametable-checked-options IMMEDIATE CHECKEDcheck-optionsFOR,table-nametable-unchecked-optionsIMMEDIATE UNCHECKED
access-mode-clause
構文図を読む構文図をスキップするNO ACCESSREAD ACCESS
cascade-clause
構文図を読む構文図をスキップするCASCADE IMMEDIATEto-descendent-typesCASCADE DEFERRED
to-descendent-types
構文図を読む構文図をスキップするTO ALL TABLESTO,MATERIALIZED QUERY TABLESFOREIGN KEY TABLESSTAGING TABLES
table-checked-options
構文図を読む構文図をスキップする,online-optionsGENERATE IDENTITYquery-optimization-options
online-options
構文図を読む構文図をスキップするALLOW NO ACCESSALLOW READ ACCESSALLOW WRITE ACCESS
query-optimization-options
構文図を読む構文図をスキップするALLOW QUERY OPTIMIZATIONUSING REFRESH DEFERRED TABLESWITH REFRESH AGE ANY
check-options
構文図を読む構文図をスキップする●incremental-options●FORCE GENERATED ●PRUNE●FULL ACCESS ● exception-clause
incremental-options
構文図を読む構文図をスキップするINCREMENTALNOT INCREMENTAL
exception-clause
構文図を読む構文図をスキップするFOR EXCEPTION,in-table-use-clause
in-table-use-clause
構文図を読む構文図をスキップするINtable-nameUSEtable-name
table-unchecked-options
構文図を読む構文図をスキップする,integrity-optionsFULL ACCESS
integrity-options
構文図を読む構文図をスキップするALL,FOREIGN KEYCHECKMATERIALIZED QUERYGENERATED COLUMNSTAGING

説明

FOR table-name
整合性処理を行う表 (複数可) を指定します。 これは、カタログに記述されている表でなければならず、 ビュー、カタログ表、または型付き表を対象にすることはできません。
オフ
表を SET INTEGRITY ペンディング状態にすることを指定します。 SET INTEGRITY ペンディング状態にある表に対しては、極めて限定されたアクティビティーのみが許されます。
access-mode-clause
SET INTEGRITY ペンディング状態のときの表の読み取り可否を指定します。
NO ACCESS
表を SET INTEGRITY ペンディング・アクセスなし状態にすることを指定します。この状態では、 表への読み取りまたは書き込みアクセスは許可されません。
READ ACCESS
表を SET INTEGRITY ペンディング読み取りアクセス状態にすることを指定します。この状態では、表の追加部分以外への読み取りアクセスが許可されます。 このオプションは、SET INTEGRITY ペンディング・アクセスなし状態の表に対しては許可されません (SQLSTATE 428FH)。
cascade-clause
SET INTEGRITY ステートメントで参照される表の SET INTEGRITY ペンディング状態を下層表にすぐにカスケードするかどうかを指定します。
CASCADE IMMEDIATE
SET INTEGRITY ペンディング状態を下層表にすぐに適用することを指定します。
to-descendent-types
SET INTEGRITY ペンディング状態をすぐにカスケードする下層表のタイプを指定します。
TO ALL TABLES
SET INTEGRITY ペンディング状態を呼び出しリストにある表のすべての下層表に対してすぐにカスケードすることを指定します。 下層表には、呼び出しリストの表の下層である、あるいは下層外部キー表の下層である、 すべての下層外部キー表、即時ステージング表、および即時マテリアライズ照会表が含まれます。

TO ALL TABLES を指定することは、TO FOREIGN KEY TABLES、TO MATERIALIZED QUERY TABLES、TO STAGING TABLES をすべて同じステートメントに指定することと等価です。

TO MATERIALIZED QUERY TABLES
TO MATERIALIZED QUERY TABLES だけを指定する場合、SET INTEGRITY ペンディング状態は、 すぐに、下層即時マテリアライズ照会表に対してだけカスケードされます。 他の下層表は、表の SET INTEGRITY ペンディング状態が解除されたときに、必要に応じて後で SET INTEGRITY ペンディング状態になる場合があります。 TO FOREIGN KEY TABLES と TO MATERIALIZED QUERY TABLES の両方を指定する場合、SET INTEGRITY ペンディング状態はすぐに、 すべての下層外部キー表、呼び出しリストにある表のすべての下層即時マテリアライズ照会表、下層外部キー表の下層であるすべての即時マテリアライズ照会表にカスケードされます。
TO FOREIGN KEY TABLES
SET INTEGRITY ペンディング状態を下層外部キー表にすぐにカスケードすることを指定します。 他の下層表は、表の SET INTEGRITY ペンディング状態が解除されたときに、必要に応じて後で SET INTEGRITY ペンディング状態になる場合があります。
TO STAGING TABLES
SET INTEGRITY ペンディング状態を下層ステージング表にすぐにカスケードすることを指定します。 他の下層表は、表の SET INTEGRITY ペンディング状態が解除されたときに、必要に応じて後で SET INTEGRITY ペンディング状態になる場合があります。 TO FOREIGN KEY TABLES と TO STAGING TABLES の両方を指定する場合、SET INTEGRITY ペンディング状態はすぐに、 すべての下層外部キー表、呼び出しリストにある表のすべての下層即時ステージング表、下層外部キー表の下層であるすべての即時ステージング表にカスケードされます。
CASCADE DEFERRED
呼び出しリストに含まれる表だけを SET INTEGRITY ペンディング状態にすることを指定します。 下層表の状態は未変更のままになります。 下層外部キー表は、その親表の制約違反を検査するときに、暗黙的に SET INTEGRITY ペンディング状態になる場合があります。 下層即時マテリアライズ照会表と下層即時ステージング表は、基礎表のいずれかで整合性違反を検査するときに、暗黙的に SET INTEGRITY ペンディング状態になる場合があります。 照会のアクセス先が、指定された表ではなく、SET INTEGRITY ペンディング状態にない適格なマテリアライズ照会表である場合は、SET INTEGRITY ペンディング状態の表の照会が成功することがあります。
cascade-clause を指定しない場合は、SET INTEGRITY ペンディング状態がすぐにすべての下層表にカスケードされます。
IMMEDIATE CHECKED
必要な整合性処理を表に対して実行することによって、表の SET INTEGRITY ペンディング状態を解除することを指定します。 これは、SYSCAT.TABLES カタログ・ビューの STATUS 列と CONST_CHECKED 列に設定されている情報に基づいて行われます。 すなわち、
  • 表が、リストで指定された表の下層外部キー表、下層マテリアライズ照会表、または下層ステージング表であり、SET INTEGRITY ペンディング状態にあり、さらにその中間上層もリストに含まれるのでない限り、STATUS 列の値は「C」(表は SET INTEGRITY ペンディング状態にあるという意味) でなければなりません。そうでない場合は、エラーが戻されます (SQLSTATE 51027)。
  • 検査する表が SET INTEGRITY ペンディング状態にある場合、CONST_CHECKED の値は、どの整合性オプションを検査するかを示します。

表の SET INTEGRITY ペンディング状態が解除されたときに、その下層表は、必要に応じて SET INTEGRITY ペンディング状態になります。 下層表が SET INTEGRITY ペンディング状態になったことを示す警告が戻されます (SQLSTATE 01586)。

表がシステムによって保守されるマテリアライズ照会表であれば、照会に基づいてデータが検査され、必要に応じてリフレッシュされます。 (IMMEDIATE CHECKED は、ユーザーが保守するマテリアライズ照会表には使用できません。) 表がステージング表であれば、その照会定義に基づいてデータが検査され、必要に応じて伝搬されます。

子表の整合性を検査する場合、以下のいずれかの要件を満たしている必要があります。
  • どの親も SET INTEGRITY ペンディング状態であってはなりません。
  • それぞれの親は、同じ SET INTEGRITY ステートメントで制約違反を検査される必要があります。
即時マテリアライズ照会表がリフレッシュされる場合、 あるいは差分がステージング表に伝搬される場合、以下のいずれかの要件を満たしている必要があります。
  • どの基礎表も SET INTEGRITY ペンディング状態であってはなりません。
  • それぞれの基礎表は、同じ SET INTEGRITY ステートメントで検査される必要があります。
これ以外の場合には、エラーになります (SQLSTATE 428A8)。
table-checked-options
online-options
処理中の表のアクセス可能性を指定します。
ALLOW NO ACCESS
他のユーザーは、非コミット読み取り分離レベルを使用している場合を除き、処理中の表にアクセスできないことを指定します。
ALLOW READ ACCESS
他のユーザーは処理中の表に対して読み取り専用アクセスができることを指定します。
ALLOW WRITE ACCESS
他のユーザーは処理中の表に対して読み取り/書き込みアクセスができることを指定します。
GENERATE IDENTITY
表に ID 列が含まれている場合に、SET INTEGRITY ステートメントによって値を生成することを指定します。 GENERATE IDENTITY オプションを指定した場合、デフォルトでは、SET INTEGRITY ステートメントによって ID 列の値が生成されるのはアタッチされた行だけです。 表のすべての行 (アタッチされた行、ロードされた行、および既存の行) の ID 列の値を SET INTEGRITY ステートメントによって生成するには、GENERATE IDENTITY オプションと一緒に NOT INCREMENTAL オプションを指定する必要があります。 GENERATE IDENTITY オプションを指定しない場合は、表のすべての行の現在の ID 列の値が未変更のままになります。表がシステム期間テンポラル表である場合、GENERATE IDENTITY に NOT INCREMENTAL オプションを指定できるのは、最初に ALTER TABLE ステートメントに DROP VERSIONING 節を指定して発行する場合のみです (SQLSTATE 428FH)。
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 マテリアライズ照会表は、常に照会の最適化のときに考慮されます。
check-options
incremental-options
INCREMENTAL
表の追加部分 (もしあれば) に対して整合性処理を適用することを指定します。 この要求が満たされない場合 (つまり、システムが表全体でデータ整合性検査を実行する必要があると判断する場合) は、エラーが戻されます (SQLSTATE 55019)。
NOT INCREMENTAL
表全体に対して整合性処理を適用することを指定します。 表がマテリアライズ照会表である場合、マテリアライズ照会表定義が再計算されます。 表に少なくとも 1 つの制約が定義されている場合、このオプションを指定すると、 下層外部キー表と下層即時マテリアライズ照会表が完全処理されます。 表がステージング表の場合は、不整合状態に設定されます。
incremental-options 節を指定しない場合、システムは増分処理が可能かどうかを判断します。それが可能でなければ、表全体が検査されます。
FORCE GENERATED
表に式生成列が含まれている場合は、式に基づいてその値が計算され、列に保管されます。 このオプションを指定しない場合は、等価チェック制約が有効であるかのように、現行値が式の算出値と比較されます。 表の整合性が増分的に処理される場合、生成列は追加部分についてのみ計算されます。表がシステム期間テンポラル表である場合、FORCE GENERATED オプションが許可されるのは、DROP VERSIONING 節を指定して ALTER TABLE ステートメントを事前に実行していた場合のみです (SQLSTATE 428FH)。
PRUNE
このオプションは、ステージング表の場合にのみ指定できます。 ステージング表の内容を整理すること、ステージング表を不整合状態にすることを指定します。 table-name リストに含まれている表がステージング表でなければ、 エラーが戻されます (SQLSTATE 428FH)。 INCREMENTAL 検査オプションも指定されている場合、エラーが戻されます (SQLSTATE 428FH)。
FULL ACCESS
SET INTEGRITY ステートメントの実行後に表を完全にアクセス可能にすることを指定します。

呼び出しリストにある基礎表 (従属即時マテリアライズ照会表または従属即時ステージング表を持つ基礎表) が増分的に処理される場合、その基礎表は、SET INTEGRITY ステートメントの実行後に、必要に応じてデータ移動なし状態になります。 増分的にリフレッシュ可能なすべての従属の即時マテリアライズ照会表とステージング表の SET INTEGRITY ペンディング状態が解除されると、基礎表は、自動的にデータ移動なし状態からフル・アクセス状態になります。 IMMEDIATE CHECKED オプションと一緒に FULL ACCESS オプションを指定すると、基礎表は、データ移動なし状態をバイパスして、直接にフル・アクセス状態になります。 FULL ACCESS オプションを指定した場合、従属表と基礎表の間の従属関係のみが除去されます。 非同期パーティション・デタッチ・タスクがデータ・パーティション・デタッチ・プロセスを完了するまでは、基礎表の使用不可状態が続きます。

リフレッシュされていない従属即時マテリアライズ照会表は、後続の REFRESH TABLE ステートメントですべてが再計算される可能性があり、表の追加部分が伝搬されていない従属即時ステージング表は、不整合としてフラグが設定される可能性があります。

呼び出しリストにある基礎表が、完全処理を必要とするか、従属即時マテリアライズ照会表または従属即時ステージング表を持たない場合、その基礎表は、FULL ACCESS オプションが指定されているかどうかに関係なく、SET INTEGRITY ステートメントの実行後に直接にフル・アクセス状態になります。

exception-clause
FOR EXCEPTION
チェック対象の制約に違反している行を例外表に移動することを指定します。 エラーが検出されても、表の SET INTEGRITY ペンディング状態は解除されます。 1 つ以上の行が例外表に移されたことを示す警告が戻されます (SQLSTATE 01603)。

FOR EXCEPTION 節の指定がない場合に、制約違反が生じると、最初に検出された違反だけが戻されます (SQLSTATE 23514)。 表のいずれかに違反がある場合は、すべての表が SET INTEGRITY ペンディング状態のままになります。

制約違反をチェックする場合は、違反が検出された場合に SET INTEGRITY ステートメントがロールバックされる事態を回避するために、常に FOR EXCEPTION オプションを使用することをお勧めします。

IN キーワードの後に指定する表がシステム期間テンポラル表である場合、FOR EXCEPTION オプションが許可されるのは、DROP VERSIONING 節を指定して ALTER TABLE ステートメントを事前に実行していた場合のみです (SQLSTATE 428FH)。

IN table-name
制約違反行の移動元の表を指定します。 検査される各表ごとに、1 つの例外表を指定する必要があります。 この節は、マテリアライズ照会表またはステージング表には指定できません (SQLSTATE 428A7)。
USE table-name
エラー行の移動先にする例外表を指定します。
FULL ACCESS
ステートメントの唯一の操作として FULL ACCESS オプションを指定すると、表は整合性違反の再チェックなしでフル・アクセス状態になります。 ただし、リフレッシュされていない従属即時マテリアライズ照会表は、後続の REFRESH TABLE ステートメントですべての再計算が必要になる可能性があり、表の差分部分が伝搬されていない従属即時ステージング表は、不完全状態に変更される可能性があります。 このオプションは、データ移動なし状態またはアクセスなし状態でありながら、SET INTEGRITY ペンディング状態ではない表にのみ指定できます (SQLSTATE 428FH)。
PRUNE
このオプションは、ステージング表の場合にのみ指定できます。 ステージング表の内容を整理すること、ステージング表を不整合状態にすることを指定します。 table-name リストに含まれている表がステージング表でなければ、 エラーが戻されます (SQLSTATE 428FH)。
table-unchecked-options
integrity-options
表の SET INTEGRITY ペンディング状態を解除するときにバイパスする、必要な整合性処理のタイプを定義するために使用します。
ALL
すべての必要な整合性処理を実行しないで、表の SET INTEGRITY ペンディング状態をすぐに解除します。
FOREIGN KEY
必要な外部キー制約検査を実行しないで、表の SET INTEGRITY ペンディング状態を解除します。
CHECK
必要なチェック制約検査を実行しないで、表の SET INTEGRITY ペンディング状態を解除します。
MATERIALIZED QUERY
必要なマテリアライズ照会表のリフレッシュを実行しないで、表の SET INTEGRITY ペンディング状態を解除します。
GENERATED COLUMN
必要な生成列制約検査を実行しないで、表の SET INTEGRITY ペンディング状態を解除します。
STAGING
必要なステージング表へのデータ伝搬を実行しないで、表の SET INTEGRITY ペンディング状態を解除します。

特定タイプの整合性処理がバイパス対象として設定された後に、表に対する他の整合性処理が必要なければ、表の SET INTEGRITY ペンディング状態はすぐに解除されます。

FULL ACCESS
SET INTEGRITY ステートメントの実行後に表が完全にアクセス可能になることを指定します。

呼び出しリストにある基礎表が増分的に処理され、従属即時マテリアライズ照会表または従属即時ステージング表を持つ場合、その基礎表は、SET INTEGRITY ステートメントの実行後に、必要に応じてデータ移動なし状態になります。 増分的にリフレッシュ可能なすべての従属の即時マテリアライズ照会表とステージング表の SET INTEGRITY ペンディング状態が解除されると、基礎表は、自動的にデータ移動なし状態からフル・アクセス状態になります。 IMMEDIATE UNCHECKED オプションと一緒に FULL ACCESS オプションを指定すると、基礎表は、データ移動なし状態をバイパスして、直接にフル・アクセス状態になります。 リフレッシュされていない従属即時マテリアライズ照会表は、後続の REFRESH TABLE ステートメントですべてが再計算される可能性があり、表の追加部分が伝搬されていない従属即時ステージング表は、不整合としてフラグが設定される可能性があります。

FULL ACCESS オプションを指定した場合は、従属表と基礎表の間の従属関係のみが除去されます。 非同期パーティション・デタッチ・タスクがデータ・パーティション・デタッチ・プロセスを完了するまでは、基礎表の使用不可状態が続きます。

呼び出しリストにある基礎表が、完全処理を必要とするか、従属即時マテリアライズ照会表または従属即時ステージング表を持たない場合、その基礎表は、FULL ACCESS オプションが指定されているかどうかに関係なく、SET INTEGRITY ステートメントの実行後に直接にフル・アクセス状態になります。

IMMEDIATE UNCHECKED オプションと一緒に FULL ACCESS オプションを指定した場合に、ステートメントが表の SET INTEGRITY ペンディング状態を解除しなければ、エラーが戻されます (SQLSTATE 428FH)。

IMMEDIATE UNCHECKED
以下のいずれかを指定します。
  • 必要な整合性処理をいずれも実行しないで、表の SET INTEGRITY ペンディング状態をすぐに解除すること。
  • IMMEDIATE CHECKED オプションを使用した後続の SET INTEGRITY ステートメントで表の SET INTEGRITY ペンディング状態を解除するときに、表に必要な整合性処理のうち、1 つ以上のタイプの処理をバイパスすること。

このオプションを使用する前に、このオプションがデータ整合性に対して持つ意味合いをよく検討してください。 『注』のセクションを参照してください。

注

  • SET INTEGRITY に関連した制限状態のいずれかが表に及ぼす影響:
    • 読み取りアクセス状態またはアクセスなし状態の表については、INSERT、UPDATE、DELETE を実行できません。 さらに、そのような状態の表にその種の変更を加える必要のあるステートメントはリジェクトされます。 例えば、アクセスなし状態にある従属表にカスケードする親表の行の削除は実行できません。
    • アクセスなし状態の表については、SELECT を実行できません。 さらに、アクセスなし状態の表への読み取りアクセスが必要なステートメントはリジェクトされます。
    • 表に新しく追加される制約は、通常、ただちに適用されます。 ただし、表が SET INTEGRITY ペンディング状態の場合は、表の SET INTEGRITY ペンディング状態が解除されるまで、新しい制約の検査は据え置かれます。 表が SET INTEGRITY ペンディング状態にある場合に、新しい制約を追加すると、データの妥当性がリスクにさらされるので、表は SET INTEGRITY ペンディング・アクセスなし状態になります。
    • CREATE INDEX ステートメントでは、読み取りアクセス状態またはアクセスなし状態にある表を参照できません。 同様に、主キー制約またはユニーク制約を追加する ALTER TABLE ステートメントでは、読み取りアクセス状態またはアクセスなし状態にある表を参照できません。
    • 読み取りアクセス状態またはアクセスなし状態の表については、IMPORT ユーティリティーを実行できません。
    • EXPORT ユーティリティーは、アクセスなし状態の表については実行できませんが、読み取りアクセス状態の表については実行できます。 表が読み取りアクセス状態の場合、EXPORT ユーティリティーは、追加部分以外のデータだけをエクスポートします。
    • 読み取りアクセス状態、アクセスなし状態、データ移動なし状態の表については、表の中でのデータ移動を伴う可能性がある操作 (REORG、REDISTRIBUTE、分散キーの更新、マルチディメンション・クラスタリング・キーの更新、範囲クラスタリング・キーの更新、表パーティション・キーの更新など) を実行できません。
    • LOAD、BACKUP、RESTORE、UPDATE STATISTICS、RUNSTATS、REORGCHK、LIST HISTORY、ROLLFORWARD の各ユーティリティーは、フル・アクセス状態、読み取りアクセス状態、アクセスなし状態、データ移動なし状態の表に対して実行できます。
    • ALTER TABLE、COMMENT、DROP TABLE、CREATE ALIAS、CREATE TRIGGER、CREATE VIEW、GRANT、REVOKE、SET INTEGRITY の各ステートメントでは、フル・アクセス状態、読み取りアクセス状態、アクセスなし状態、データ移動なし状態の表を参照できます。 ただし、結果的に表がアクセスなし状態にされる場合もあります。
    • アクセスなし状態の表に従属しているパッケージ、ビュー、およびその他のオブジェクトは、実行時にその表がアクセスされると、エラーを戻します。 読み取りアクセス状態の表に従属しているパッケージは、実行時にその表に対して挿入、更新、削除の操作が試行されると、エラーを戻します。
    • 表のデータベース・パーティション・キー、表パーティション・キー、マルチディメンション・クラスタリング・キー、または範囲クラスタリング・キーが、ALTER TABLE ステートメントによって式を変更された生成列を参照している場合には、ALL または GENERATED COLUMN オプションを IMMEDIATE UNCHECKED オプションと一緒に指定することはできません。

    SET INTEGRITY ステートメントによる違反行の除去は、削除イベントではありません。 したがって、SET INTEGRITY ステートメントによってトリガーが起動されることはありません。 同様に、FORCE GENERATED オプションを使用して生成列を更新しても、トリガーは起動されません。

  • IMMEDIATE UNCHECKED 節の使用に関する警告 :
    • この節は、ユーティリティー・プログラムで使用することを意図しているので、 アプリケーション・プログラムによる使用はお勧めしません。 表に定義されている整合性仕様を満たさないデータが存在する場合に、IMMEDIATE UNCHECKED オプションを使用すると、正しくない照会結果が戻されることがあります。
      必要な整合性処理を実行しないで表の SET INTEGRITY ペンディング状態を解除したという事実は、カタログに記録されます (SYSCAT.TABLES ビューの CONST_CHECKED 列の関連バイトが "U" に設定されます)。これは、特定の制約に関するデータ保全の責任はユーザーにあることを示しています。 この値は、以下のいずれかの場合まで変更されません。
      • OFF オプションを指定した SET INTEGRITY ステートメントで表を参照することによって、表を SET INTEGRITY ペンディング状態に戻した場合。その時点で、CONST_CHECKED 列にある "U" 値が "W" 値に変更されます。これは、データ整合性の責任が以前はユーザーにあったと見なされていたのに対し、現在はシステムがデータを検査する必要があることを示しています。
      • 表の、検査されていないすべての制約をドロップした場合。

      "W" 状態は "N" 状態と違って、整合性が以前はユーザーによって検査されていたが、システムによってはまだ検査されていないことを記録します。 ユーザーが NOT INCREMENTAL オプションを指定した SET INTEGRITY ... IMMEDIATE CHECKED ステートメントを発行すると、 システムは、表全体のデータ整合性を再検査 (または、マテリアライズ照会表で完全リフレッシュを実行) してから、 "W" 状態を "Y" 状態に変更します。IMMEDIATE UNCHECKED が指定されるか、NOT INCREMENTAL が指定されない場合、 "W" 状態は変更されて "U" 状態に戻され、一部のデータがまだシステムで検査されていないことを記録します。 後者の場合 (NOT INCREMENTAL が指定されない場合) は、警告が戻されます (SQLSTATE 01636)。

      基礎表の整合性が IMMEDIATE UNCHECKED 節を使用して検査された場合、基礎表の CONST_CHECKED 列にある "U" の値は、以下の表の対応する CONST_CHECKED 列に伝搬されます。
      • 従属即時マテリアライズ照会表
      • 従属据え置きマテリアライズ照会表
      • 従属ステージング表

      従属即時マテリアライズ照会表の場合、この伝搬は、基礎表の SET INTEGRITY ペンディング状態が解除されるとき、 およびマテリアライズ照会表がリフレッシュされるときに必ず行われます。 従属据え置きマテリアライズ照会表の場合、この伝搬は、 マテリアライズ照会表がリフレッシュされるときに必ず行われます。 従属ステージング表の場合、この伝搬は、基礎表の SET INTEGRITY ペンディング状態が解除されるときに必ず行われます。 従属のマテリアライズ照会表とステージング表の CONST_CHECKED 列に示される、これらの伝搬された "U" の値は、これらのマテリアライズ照会表とステージング表が、IMMEDIATE UNCHECKED オプションによって必要な整合性処理がバイパスされた基礎表に従属することを記録しています。

      マテリアライズ照会表の場合、基礎表によって伝搬された CONST_CHECKED 列の "U" の値は、 マテリアライズ照会表が完全にリフレッシュされ、 すべての基礎表の対応する CONST_CHECKED 列に "U" の値がなくなるまで、そのまま変わりません。 リフレッシュが行われたら、マテリアライズ照会表の CONST_CHECKED 列にある "U" の値は、 "Y" に変更されます。

      ステージング表の場合、基礎表によって伝搬された CONST_CHECKED 列の "U" の値は、ステージング表の対応する据え置きマテリアライズ照会表がリフレッシュされるまで、そのまま変わりません。リフレッシュが行われたら、ステージング表の CONST_CHECKED 列にある "U" の値は、"Y" に変更されます。

    • 子表とその親表が IMMEDIATE CHECKED オプションを指定した同じ SET INTEGRITY ステートメントで検査される場合に、親表で制約を完全に検査する必要があれば、子表の外部キー制約の CONST_CHECKED 列に "U" の値があるかどうかに関係なく、子表では外部キー制約が検査されます。
  • 表がデータ・パーティション化されており、保守する非パーティション索引 (XML 列パス索引を除く) がある場合、単一のターゲット表が指定されている場合の IMMEDIATE UNCHECKED 動作は、ALLOW WRITE ACCESS オプションを指定した IMMEDIATE CHECKED 動作と同じです。すべての整合性処理が実行され、結果として生成されるエラーがあれば返されます。 ステートメントが複数のターゲット表を参照する場合、エラーが返されます (SQLSTATE 428FH)。
  • LOAD INSERT または ALTER TABLE ATTACH を使用してデータを追加した後、IMMEDIATE CHECKED オプションを指定した SET INTEGRITY ステートメントによって表の制約違反を検査します。 表に対する増分処理が可能かどうかは、システムが判断します。 可能な場合には、追加部分だけが整合性違反を検査されます。 不可能な場合には、システムは、表全体の整合性違反を検査します。
  • 次のステートメントについて考慮します。 
       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 オプションを指定しなければ、システムは追加部分だけの整合性検査 (マテリアライズ照会表の場合は増分リフレッシュ) を実行しようとします。
  • 整合性処理の過程でエラーが発生すると、 (元の表からの削除や例外表への挿入を含め) すべての処理結果がロールバックされます。
  • FORCE GENERATED オプションを指定して発行された SET INTEGRITY ステートメントが、ログ・スペースの不足のために失敗する場合、使用できるアクティブなログ・スペースを増やし、 SET INTEGRITY ステートメントを再発行してください。 あるいは、GENERATED COLUMN オプションと IMMEDIATE UNCHECKED オプションを指定した SET INTEGRITY ステートメントを使用して、表の生成列の検査をバイパスできます。 その後、IMMEDIATE CHECKED オプションを指定し FORCE GENERATED オプションを指定しない SET INTEGRITY ステートメントを実行して、表に他の整合性違反 (該当する場合) があるかどうかを検査し、表の SET INTEGRITY ペンディング状態を解除してください。 表の SET INTEGRITY ペンディング状態が解除されたら、UPDATE ステートメントのキーワード DEFAULT を生成列に代入することによって、生成列をそのデフォルト値 (生成値) に更新できます。 このことは、範囲に基づく複数の検索更新ステートメントを使用する方法 (それぞれの後にコミットする) と、断続的なコミットを使用したカーソル・ベースによる方法のいずれかを使用することで、実現されます。 カーソル・ベースによる方法を使用した断続的なコミットの後で、ロックを保存する場合には、 WITH HOLD カーソルを使用する必要があります。
  • SET INTEGRITY ステートメントまたは LOAD コマンドの CASCADE DEFERRED オプション、または ATTACH 節を指定した ALTER TABLE ステートメントによって SET INTEGRITY ペンディング状態にされ、SET INTEGRITY ステートメントの IMMEDIATE CHECKED オプションによって整合性違反を検査される表については、その下層外部キー表、下層即時マテリアライズ照会表、下層即時ステージング表が必要に応じて SET INTEGRITY ペンディング状態にされます。
    • 表全体の整合性違反が検査される場合は、その下層外部キー表、下層即時マテリアライズ照会表、下層即時ステージング表が SET INTEGRITY ペンディング状態にされます。
    • 表の整合性違反が増分的に検査される場合は、その下層即時マテリアライズ照会表とステージング表が SET INTEGRITY ペンディング状態にされ、その下層外部キー表は元の状態のままになります。
    • 表を検査する必要がまったくない場合、その下層即時マテリアライズ照会表、下層ステージング表、 および下層外部キー表は、元の状態のままにされます。
  • SET INTEGRITY ステートメントまたは LOAD コマンドの CASCADE DEFERRED オプションによって SET INTEGRITY ペンディング状態にされ、SET INTEGRITY ステートメントの IMMEDIATE UNCHECKED オプションによって SET INTEGRITY ペンディング状態を解除される表については、その下層外部キー表、下層即時マテリアライズ照会表、下層即時ステージング表が必要に応じて SET INTEGRITY ペンディング状態にされます。
    • 表が REPLACE モードでロードされた場合は、その下層外部キー表、下層即時マテリアライズ照会表、下層即時ステージング表が SET INTEGRITY ペンディング状態にされます。
    • 表が INSERT モードでロードされた場合は、その下層即時マテリアライズ照会表とステージング表が SET INTEGRITY ペンディング状態にされ、その下層外部キー表は元の状態のままになります。
    • 表がロードされていない場合、その下層即時マテリアライズ照会表、下層ステージング表、 および下層外部キー表は、元の状態のままにされます。
  • 通常、SET INTEGRITY ステートメントの実行には長い時間がかかります。 したがって、ロック・タイムアウトが原因でステートメント全体がロールバックされるリスクを軽減するために、まず WAIT オプションを指定した SET CURRENT LOCK TIMEOUT ステートメントを実行してから SET INTEGRITY ステートメントを実行し、トランザクションのコミット後にその特殊レジスターを元の値にリセットできます。 ただし、CURRENT LOCK TIMEOUT 特殊レジスターは、特定セットのロック・タイプだけに影響を与えます。
  • 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 つの SET INTEGRITY ステートメントを使用する場合は、MQT1 を最初に保守するのが正しい順序になります。
  • SET INTEGRITY ステートメントを使用して、ロードまたはアタッチされた基本表の整合性処理を実行する場合、従属の REFRESH IMMEDIATE マテリアライズ照会表と PROPAGATE IMMEDIATE ステージング表を同じ SET INTEGRITY ステートメントで処理することによって、SET INTEGRITY 処理の終わりにそれらの従属表が SET INTEGRITY ペンディング・アクセスなし状態になるのを回避することをお勧めします。 ただし、従属の REFRESH IMMEDIATE マテリアライズ照会表と PROPAGATE IMMEDIATE ステージング表を多数抱えている基本表の場合は、メモリー制約のために、基本表と同じステートメントですべての従属表を処理することが不可能な場合もあります。
  • FORCE GENERATED オプションまたは GENERATE IDENTITY オプションを指定した場合、生成される列がユニー ク索引の一部になっていれば、ユニー ク索引の中で重複キーを検出したときに、SET INTEGRITY ステートメントはエラーを戻し (SQLSTATE 23505)、処理をロールバックします。 このエラーは、処理対象表に例外表がある場合でも戻されます。
    このシナリオは、以下の状況で発生する可能性があります。
    • SET INTEGRITY ステートメントは表に対する LOAD コマンドの後に実行され、ロード操作に GENERATEDOVERRIDE または IDENTITYOVERRIDE ファイル・タイプ修飾子が指定される。 このシナリオを回避するために、ファイル・タイプ修飾子として GENERATEDOVERRIDE の代わりに GENERATEDIGNORE または GENERATEDMISSING、IDENTITYOVERRIDE の代わりに IDENTITYIGNORE または IDENTITYMISSING を使用することをお勧めします。これらの推奨修飾子を使用すれば、SET INTEGRITY ステートメントの実行時に、式生成列または ID 列の処理が必要なくなります。
    • SET INTEGRITY ステートメントは式生成列の式を変更する ALTER TABLE ステートメントの後に実行される。
    このようなシナリオが発生した後に、表の SET INTEGRITY ペンディング状態を解除するには、以下のようにします。
    • 列値を再生成するために FORCE GENERATED オプションまたは GENERATE IDENTITY オプションを使用しないでください。 その代わりに、IMMEDIATE CHECKED オプションと FOR EXCEPTION オプションを併用して、生成列の式に違反している行を例外表に移動します。 その後、それらの行を例外表から対象表に挿入し直せば、正しい式が生成され、ユニーク・キーの検査が実行されます。 こうすると、再処理の必要があるのは生成列の式に違反していた行だけなので、表全体を再処理せずに済みます。
    • 処理対象表にパーティションがアタッチされている場合は、前項で説明した操作を行う前に、まずそれらのパーティションをデタッチします。 その後、それらのパーティションを再アタッチしてから、SET INTEGRITY ステートメントによって、アタッチしたパーティションの保全性処理を別途実行します。
  • 保護対象表に SET INTEGRITY ステートメントを例外表と共に指定する場合は、表に関する以下のすべての基準を満たす必要があります。そうでなければ、エラーが戻されます (SQLSTATE 428A5)。
    • 両方の表が同じセキュリティー・ポリシーによって保護されている必要があります。
    • 保護対象表の列のデータ・タイプが Db2SECURITYLABEL の場合は、例外表の対応する列のデータ・タイプも Db2SECURITYLABEL でなければなりません。
    • 保護対象表の列がセキュリティー・ラベルによって保護されている場合、例外表の対応する列も同じセキュリティー・ラベルで保護されている必要があります。
  • システム期間テンポラル表で検査されている整合性に違反する行は、例外表に移動できません。 違反している行を例外表に移動する必要がある場合、FOR EXCEPTION 節を指定する SET INTEGRITY ステートメントを発行する前に、その表を変更してバージョン管理をドロップする必要があります。

例

  • 例 1: 以下は、表の SET INTEGRITY ペンディング状態と、SET INTEGRITY に関連したアクセス制限状態についての情報を提供する照会の例です。 SUBSTR を使用して、SYSCAT.TABLES の CONST_CHECKED 列の個々のバイトを抽出しています。 第 1 バイトは外部キー制約、第 2 バイトはチェック制約、第 5 バイトはマテリアライズ照会表の整合性、第 6 バイトは生成列制約、第 7 バイトはステージング表の整合性、第 8 バイトはデータ・パーティション制約をそれぞれ表します。 STATUS は SET INTEGRITY ペンディング状態を示し、ACCESS_MODE は SET INTEGRITY に関連したアクセス制限状態を示します。 
       SELECT TABNAME, STATUS, ACCESS_MODE,
     SUBSTR(CONST_CHECKED,1,1) AS FK_CHECKED,
     SUBSTR(CONST_CHECKED,2,1) AS CC_CHECKED,
     SUBSTR(CONST_CHECKED,5,1) AS MQT_CHECKED,
     SUBSTR(CONST_CHECKED,6,1) AS GC_CHECKED,
     SUBSTR(CONST_CHECKED,7,1) AS STG_CHECKED,
     SUBSTR(CONST_CHECKED,8,1) AS DP_CHECKED
   FROM SYSCAT.TABLES
  • 例 2: PARENT 表を SET INTEGRITY ペンディング・アクセスなし状態にして、すぐに SET INTEGRITY ペンディング状態を下層表にカスケードします。 
       SET INTEGRITY FOR PARENT OFF
     NO ACCESS CASCADE IMMEDIATE
  • 例 3: PARENT 表を SET INTEGRITY ペンディング読み取りアクセス状態にしますが、すぐには SET INTEGRITY ペンディング状態を下層表にカスケードしません。 
       SET INTEGRITY FOR PARENT OFF
     READ ACCESS CASCADE DEFERRED
  • 例 4: FACT_TABLE という名前の表の整合性を検査します。 整合性違反が検出されなければ、表の SET INTEGRITY ペンディング状態は解除されます。 整合性違反が検出されれば、ステートメント全体がロールバックされ、表は SET INTEGRITY ペンディング状態のままになります。 
       SET INTEGRITY FOR FACT_TABLE IMMEDIATE CHECKED
  • 例 5: SALES 表と PRODUCTS 表の整合性を検査し、整合性に違反している行を SALES_EXCEPTIONS および PRODUCTS_EXCEPTIONS という名前の例外表にそれぞれ移動します。 整合性違反があってもなくても、SALES 表と PRODUCTS 表の両方の SET INTEGRITY ペンディング状態が解除されます。 
       SET INTEGRITY FOR SALES, PRODUCTS IMMEDIATE CHECKED
     FOR EXCEPTION IN SALES USE SALES_EXCEPTIONS,
     IN PRODUCTS USE PRODUCTS_EXCEPTIONS
  • 例 6: IMMEDIATE UNCHECKED オプションによって、MANAGER 表の FOREIGN KEY 制約検査および EMPLOYEE 表の CHECK 制約検査をバイパスすることを指定します。 
       SET INTEGRITY FOR MANAGER FOREIGN KEY,
     EMPLOYEE CHECK IMMEDIATE UNCHECKED
  • 例 7: 2 つの ALTER TABLE ステートメントを使用して、 チェック制約と外部キーを EMP_ACT 表に追加します。 OFF オプションを指定した SET INTEGRITY ステートメントによって表を SET INTEGRITY ペンディング状態にすると、2 つの ALTER TABLE ステートメントの実行時に制約検査がすぐに行われることはなくなります。 IMMEDIATE CHECKED オプションを指定した 1 つの SET INTEGRITY ステートメントを使用して、追加した両方の制約を表の 1 回のパススルーによって検査します。 
       SET INTEGRITY FOR EMP_ACT OFF;
   ALTER TABLE EMP_ACT ADD CHECK
     (EMSTDATE <= EMENDATE);
   ALTER TABLE EMP_ACT ADD FOREIGN KEY
     (EMPNO) REFERENCES EMPLOYEE;
   SET INTEGRITY FOR EMP_ACT IMMEDIATE CHECKED
     FOR EXCEPTION IN EMP_ACT USE EMP_ACT_EXCEPTIONS
  • 例 8: 生成列を正しい値で更新します。 
       SET INTEGRITY FOR SALES IMMEDIATE CHECKED
     FORCE GENERATED
  • 例 9: REFRESH IMMEDIATE マテリアライズ照会表 (SALES_SUMMARY) の基礎表 (SALES) に (LOAD INSERT を使用して) いくつかのソースからデータを追加します。 SALES のデータ整合性を増分的に検査し、SALES_SUMMARY を増分的にリフレッシュします。 このシナリオで SALES の整合性検査と SALES_SUMMARY のリフレッシュが増分的に行われるのは、システムが増分的な処理を選択するからです。 SALES 表については、ALLOW READ ACCESS オプションを使用して、表のロード部分の整合性検査中にも既存データの並行読み取りを可能にします。 
       LOAD FROM 2000_DATA.DEL OF DEL
     INSERT INTO SALES ALLOW READ ACCESS;
   LOAD FROM 2001_DATA.DEL OF DEL
     INSERT INTO SALES ALLOW READ ACCESS;
   SET INTEGRITY FOR SALES ALLOW READ ACCESS IMMEDIATE CHECKED
     FOR EXCEPTION IN SALES USE SALES_EXCEPTIONS;
   REFRESH TABLE SALES_SUMMARY;
  • 例 10: SALES という名前のデータ・パーティション表に新しいパーティションをアタッチします。 SALES 表の追加データの制約違反を増分的に検査し、従属の SALES_SUMMARY 表を増分的にリフレッシュします。 両方の表で ALLOW WRITE ACCESS オプションを使用して、整合性検査中にも並行更新を可能にします。 
       ALTER TABLE SALES
     ATTACH PARTITION STARTING (100) ENDING (200)
     FROM SOURCE;
   SET INTEGRITY FOR SALES ALLOW WRITE ACCESS, SALES_SUMMARY ALLOW WRITE ACCESS
     IMMEDIATE CHECKED FOR EXCEPTION IN SALES
     USE SALES_EXCEPTIONS;
  • 例 11: SALES という名前のデータ・パーティション表からパーティションをデタッチします。 従属の SALES_SUMMARY 表を増分的にリフレッシュします。 
       ALTER TABLE SALES
     DETACH PARTITION 2000_PART INTO ARCHIVE_TABLE;
   SET INTEGRITY FOR SALES_SUMMARY
     IMMEDIATE CHECKED;
  • 例 12: 新しいユーザー管理マテリアライズ照会表の SET INTEGRITY ペンディング状態を解除します。
       CREATE TABLE YEARLY_SALES
     AS (SELECT YEAR, SUM(SALES)AS SALES
     FROM FACT_TABLE GROUP BY YEAR)
     DATA INITIALLY DEFERRED REFRESH DEFERRED MAINTAINED BY USER

   SET INTEGRITY FOR YEARLY_SALES
     ALL IMMEDIATE UNCHECKED
  • 例 13 SALES という名前のデータ・パーティション表に新しいパーティションをアタッチします。 この表には非パーティション・ユーザー索引がないと仮定します。 また、範囲妥当性検査およびその他の制約検査を含むデータ整合性検査は (データ・サーバーとは独立したアプリケーション・ロジックを使用して) 既に実行されていると想定します。 SET INTEGRITY... ALL IMMEDIATE UNCHECKED ステートメントを使用して範囲と制約の違反検査をスキップすることにより、データ・ロールイン・プロセスを最適化します。 
       ALTER TABLE SALES
     ATTACH PARTITION STARTING (300) ENDING (400)
     FROM SOURCE_TABLE;
   SET INTEGRITY FOR SALES ALL IMMEDIATE UNCHECKED;
    SALES 表は SET INTEGRITY ペンディング状態が解除され、アプリケーションでは新しいデータを即時に使用できるようになります。