データベースを変更するときのタスクは、 データベースを作成するときのタスクと同じほど多くあります。 これらのタスクは、 以前に作成されたデータベースのある性質を更新したり除去したりします。 タスクには以下のものがあります。
データベース内の一部のオブジェクトは変更可能ですが、 データベースそのものを変更することはできません。 変更するためには、データベースを除去して再作成しなければなりません。 データベースを除去することは、データベース内のすべてのオブジェクト、 コンテナー、関連ファイルが削除されるため、広範囲に及ぶ影響があります。 データベースを除去すると、 そのデータベースはデータベース・ディレクトリーから除去 (アンカタログ) されます。
コントロール・センターを使用してデータベースを除去するには、以下のようにします。
|
コマンド行を使用してデータベースを除去するには、以下のように入力します。
DROP DATABASE <name>
次のコマンドは、SAMPLE というデータベースを削除するものです。
DROP DATABASE SAMPLE
注: | SAMPLE データベースについての実験を続けるつもりであるなら、 このデータベースは削除しないでください。 SAMPLE データベースを削除した後で再び必要であることが分かった場合には、 これを再作成できます。 |
ノードグループの変更についての詳細は、 FORM='TEXTONLY'.を参照してください。
ノードを追加または除去したら、ノード・グループ内の新しいノードのセットにわたって、 現行データを再分配しなければなりません。 これを行うためには、REDISTRIBUTE NODEGROUP コマンドを使用します。 このトピックについての詳細は FORM='TEXTONLY'.を参照してください。 また、も参照してください。
データベースを作成するときに、少なくとも 3 つの表スペースを作成します。 それらの表スペースは、カタログ表スペース (SYSCATSPACE)、 ユーザー表スペース (省略時の名前は USERSPACE1)、 およびシステム一時表スペース (省略時の名前は TEMPSPACE1) です。 これらの表スペースのそれぞれのうちの少なくとも 1 つは保持しなければなりません。 必要なら、さらにユーザー表スペースと一時表スペースを余分に追加することができます。
注: | カタログ表スペース SYSCATSPACE は除去することはできず、 また常に少なくとも 1 つのシステム一時表スペースが必要です。 表スペースのページ・サイズやエクステント・サイズを、 作成後に変更することもできません。 |
この節では、以下のように、表スペースの変更方法について説明します。
表スペースの設計情報については、 FORM='TEXTONLY'.を参照してください。
DMS 表スペース (つまり、MANAGED BY DATABASE 文節を使用して作成されたもの) のサイズは、 1 つ以上のコンテナーを表スペースに追加することによって増やすことができます。
すべてのコンテナーにわたって表スペースの内容のバランスが再調整されます。 バランスの再調整中も、表スペースへのアクセスは制限されません。 複数のコンテナーを追加する必要がある場合は、 それらを同時に追加しなければなりません。
コントロール・センターを使用して DMS 表スペースをコンテナーに追加するには、以下のようにします。
|
コマンド行を使用して DMS 表スペースをコンテナーに追加するには、以下のようにします。
ALTER TABLESPACE <name> ADD (DEVICE '<path>' <size>)
以下の例は、UNIX ベースのシステム上にある表スペースに対して、 2 つの新しい装置コンテナー (それぞれが 10 000 ページのもの) を追加する方法を示したものです。
ALTER TABLESPACE RESOURCE ADD (DEVICE '/dev/rhd9' 10000, DEVICE '/dev/rhd10' 10000)
ALTER TABLESPACE ステートメントを使用すると、 パフォーマンスに影響を及ぼす可能性のある、表スペースの他の特性を変更することができます。 詳細は、 FORM='TEXTONLY'. を参照してください。
DMS 表スペース中のコンテナー (つまり、 MANAGED BY DATABASE 文節を使用して作成されたもの) のサイズは、 1 つ以上のコンテナーをサイズ変更したり、 表スペースに関連した 1 つ以上のコンテナーを拡張することによって増やすことができます。
コマンド行を使用して DMS 表スペース中の 1 つ以上のコンテナーをサイズ変更するには、 以下のようにします。
ALTER TABLESPACE <name> RESIZE (DEVICE '<path>' <size>)
以下の例は、UNIX ベースのシステム上の表スペース中にある、 2 つの装置コンテナー (それぞれが 1 000 ページのもの) のサイズを増やす方法を示したものです。
ALTER TABLESPACE HISTORY RESIZE (DEVICE '/dev/rhd7' 2000, DEVICE '/dev/rhd8' 2000)
このアクションを実行すると、 2 つの装置は 1 000 ページから 2 000 ページにサイズが増えます。 新しいコンテナーを追加する場合と同様に、 すべてのコンテナーにわたって表スペースの内容のバランスが再調整されます。 バランスの再調整中も、表スペースへのアクセスは制限されません。
コマンド行を使用して DMS 表スペース中の 1 つ以上のコンテナーを拡張するには、 以下のようにします。
ALTER TABLESPACE <name> EXTEND (DEVICE '<path>' <size>)
以下の例は、UNIX ベースのシステム上の表スペース中にある、 2 つの装置コンテナー (それぞれが 1 000 ページのもの) のサイズを増やす方法を示したものです。
ALTER TABLESPACE HISTORY EXTEND (DEVICE '/dev/rhd11' 1000, DEVICE '/dev/rhd12' 1000)
このアクションを実行すると、 2 つの装置は 1 000 ページから 2 000 ページにサイズが増えます。 新しいコンテナーを追加する場合と同様に、 すべてのコンテナーにわたって表スペースの内容のバランスが再調整されます。 バランスの再調整中も、表スペースへのアクセスは制限されません。
注: | コンテナーのサイズを小さくすることはできません。 |
ALTER TABLESPACE ステートメントを使用すると、 パフォーマンスに影響を及ぼす可能性のある、表スペースの他の特性を変更することができます。 詳細は、 FORM='TEXTONLY'. を参照してください。
既存の表スペースに、 その中の個々のオブジェクトとは関係のない名前を新たに付けることができます。 表スペースの名前を変更すると、 その表スペースを参照するカタログ・レコードもすべて変更されます。
SYSCATSPACE 表スペースの名前を変更することはできません。
「ロールフォワード保留」または「ロールフォワード進行中」状態の表スペースの名前を変更することはできません。
バックアップを取った後に名前変更した表スペースを復元する際には、 RESTORE DATABASE コマンド中で新しい表スペースの名前を使用しなければなりません。 変更前の表スペース名を使用しても、検出されません。 同様に、 ROLLFORWARD DATABASE コマンドを使用して表スペースをロールフォワードする場合も、 必ず新しい名前を使用するようにしてください。 変更前の表スペース名を使用しても、検出されません。
ユーザー表スペースを除去するときには、その表スペース内のすべてのデータを削除し、 コンテナーを解放し、カタログ項目を除去し、そして、 その表スペースの中に定義されたすべてのオブジェクトを除去するか無効のマークを付けます。
表スペースを除去することによって、 空の表スペース内のコンテナーを再使用することができますが、 コンテナーを再使用する前に、 DROP TABLESPACE コマンドを COMMIT しなければなりません。
該当する単一ユーザー表スペース内の索引および LOB データを含むすべての表データが入ったユーザー表スペースを除去できます。 また、いくつかの表スペースにわたる表を持つようなユーザー表スペースも除去できます。 つまり、1 つの表スペースに表データ、別の表スペースに索引、 3 番目の表スペースに LOB を持つ場合があります。 表データがある表スペースを最初に除去すれば、個々の表スペースは別々に除去できます。 あるいは、単一のステートメントで 3 つの表スペースすべてを同時に除去することができます。 スパンされる表が入った表スペースはすべて、 この単一ステートメントの一部にする必要があります。 さもなければ、除去要求は失敗します。 スパンされる表データが入った表スペースを除去する方法についての詳細は、 を参照してください。
コントロール・センターを使用してユーザー表スペースを除去するには、以下のようにします。
|
コマンド行を使用してユーザー表スペースを除去するには、以下のように入力します。
DROP TABLESPACE <name>
以下の SQL ステートメントは、表スペース ACCOUNTING を除去します。
DROP TABLESPACE ACCOUNTING
データベースは常に少なくとも 1 つのシステム一時表スペースを持っていなければならないため、 まずシステム一時表スペースをもう 1 つ作成してからでなければ、 システム一時表スペースを除去することはできません。 たとえば、SMS 一時表スペースにコンテナーを追加したければ、 まず新しいシステム一時表スペースを追加してから、 古いシステム一時表スペースを除去しなければなりません。
コントロール・センターを使用してシステム表スペースを除去するには、以下のようにします。
|
システム一時表スペースが 1 つしかない場合は、 その表スペースを削除する前に、 システム一時表スペースをもう 1 つ作成しなければなりません。 これは、コマンド行を使用し、以下のように入力すると実行できます。
CREATE SYSTEM TEMPORARY TABLESPACE <name> MANAGED BY SYSTEM USING ('<device>')
続いて、コマンド行を使用してシステム表スペースを除去するには、 以下のように入力します。
DROP TABLESPACE <name>
以下の SQL は、 TEMPSPACE2 と呼ばれる新しいシステム一時表スペースを作成します。
CREATE SYSTEM TEMPORARY TABLESPACE TEMPSPACE2 MANAGED BY SYSTEM USING ('d')
TEMPSPACE2 が作成されれば、以下のコマンドを使用して、 元のシステム一時表スペース TEMPSPACE1 を除去することができます。
DROP TABLESPACE TEMPSPACE1
表スペースを除去することによって、 空の表スペース内のコンテナーを再使用することができますが、 コンテナーを再使用する前に、 DROP TABLESPACE コマンドを COMMIT しなければなりません。
ユーザー一時表スペースを除去できるのは、 その表スペースに定義されている、宣言済みの現行の表がない場合に限ります。 表スペースを除去するときに、 その表スペース内の宣言済み一時表の除去が試みられることはまったくありません。
注: | 一時表を宣言しているアプリケーションがデータベースから切断されると、 宣言された一時表は暗黙的に除去されます。 |
スキーマを除去する前に、そのスキーマの中にあったオブジェクト自体をすべて除去するか、 別のスキーマに移動しなければなりません。 DROP ステートメントを試みているときには、スキーマ名がカタログの中になければなりません。 そうでないと、エラーが戻されます。
コントロール・センターを使用してスキーマを除去するには、以下のようにします。
|
コマンド行を使用してスキーマを除去するには、以下のように入力します。
DROP SCHEMA <name>
以下の例では、"joeschma" というスキーマが除去されます。
DROP SCHEMA joeschma RESTRICT
RESTRICT キーワードは、 データベースから削除するよう指定されたスキーマにはオブジェクトを定義できないという規則を、 強制的に実行します。
表の構造と内容を修正するために必要なタスクには、次の事柄が含まれます。
表に対するトリガーは変更できないことに注意してください。 適切でなくなったトリガーを除去して (トリガーの除去を参照)、 その代わりのものを追加 (トリガーの作成を参照) しなければなりません。
列定義には、列名、データ・タイプ、および必要な制約が含まれます。
既存の表に新しい列を追加する場合、 システム・カタログの表記述を修正するだけなので、 表へのアクセス時間はすぐには影響を受けません。 UPDATE ステートメントによって修正される時点まで、 既存のレコードが物理的に変更されることはありません。 表から既存の行を取り出すと、 新しい列には、列の定義にしたがってヌル値か省略時値かが入れられます。 表が作成された後に追加された列は、NOT NULL として定義することはできません。 NOT NULL WITH DEFAULT として、 またはヌル値可能としてのいずれかで定義しなければなりません。
コントロール・センターを使用して既存の表に列を追加するには、以下のようにします。
|
コマンド行を使用して既存の表に列を追加するには、以下のようにします。
ALTER TABLE <table_name> ADD <column_name> <data_type> <null_attribute>
列の追加は、SQL ステートメントを使ってもできます。 次のステートメントは、ALTER TABLE ステートメントを使って、 EMPLOYEE 表に 3 つの列を追加するものです。
ALTER TABLE EMPLOYEE ADD MIDINIT CHAR(1) NOT NULL WITH DEFAULT ADD HIREDATE DATE ADD WORKDEPT CHAR(3)
既存の VARCHAR 列の長さを長くすることによって、列の特性を修正できます。 文字数は、使用されるページ・サイズに従属する値まで増やすことができます。
コントロール・センターを使用して既存の表の列を修正するには、以下のようにします。
|
コマンド行を使用して既存の表の列を修正するには、 以下のように入力します。
ALTER TABLE ALTER COLUMN <column_name> <modification_type>
たとえば、4000 文字まで増やすには、次のような形式で指定します。
ALTER TABLE ALTER COLUMN COLNAM1 SET DATA TYPE VARCHAR(4000)
タイプ付き表の列を変更することはできません。 しかし、効力範囲がまだ定義されていない既存の参照タイプ列に、 効力範囲を追加することは可能です。 次に例を示します。
ALTER TABLE ALTER COLUMN COLNAMT1 ADD SCOPE TYPTAB1
ALTER TABLE ステートメントについての詳細は、を参照してください。
制約は、それらを除去した後、代わりに新しいものを追加することによってのみ変更できます。 詳細については、以下の部分を参照してください。
制約について詳しくは、制約の定義を参照してください。
ALTER TABLE ステートメントを使用して制約を追加します。 このステートメント (構文を含む) についての詳細は、 を参照してください。
制約について詳しくは、制約の定義を参照してください。
固有制約を既存の表に追加することができます。 制約名は、ALTER TABLE ステートメント内に指定した他のどの制約とも同じにすることはできず、 その表内で固有なものでなければなりません (これには、 定義されたすべての参照保全制約の名前も含まれます)。 ステートメントの完了前に、既存のデータが新しい条件に照らして検査されます。
以下の SQL ステートメントは、 表内の従業員を固有なものとして識別するための新しい方法を表す、 EMPLOYEE 表に対する固有制約を追加します。
ALTER TABLE EMPLOYEE ADD CONSTRAINT NEWID UNIQUE(EMPNO,HIREDATE)
大きな表に制約を追加する場合は、まず表を検査保留状態にし、制約を追加してから、 表を検査して違反行の統合リストを求めるのが効率的です。 明示的に検査保留状態を設定するには、SET INTEGRITY ステートメントを使います。 表が親表の場合は、すべての従属表および子孫表に対しても暗黙のうちに検査保留が設定されます。
コントロール・センターを使用して基本キーを追加するには、以下のようにします。
|
コマンド行を使用して基本キーを追加するには、以下のように入力します。
ALTER TABLE <name> ADD CONSTRAINT <column_name> PRIMARY KEY <column_name>
外部キーが表に追加される場合、 以下のステートメントが含まれるパッケージまたはキャッシュに入った動的 SQL は、 無効のマークが付けられます。
詳しくは、オブジェクトを変更する場合のステートメントの従属関係を参照してください。
コントロール・センターを使用して外部キーを追加するには、以下のようにします。
|
コマンド行を使用して外部キーを追加するには、以下のように入力します。
ALTER TABLE <name> ADD CONSTRAINT <column_name> FOREIGN KEY <column_name> ON DELETE <action_type> ON UPDATE <action_type>
以下の例は、 表に基本キーと外部キーを追加するための ALTER TABLE ステートメントを示しています。
ALTER TABLE PROJECT ADD CONSTRAINT PROJECT_KEY PRIMARY KEY (PROJNO) ALTER TABLE EMP_ACT ADD CONSTRAINT ACTIVITY_KEY PRIMARY KEY (EMPNO, PROJNO, ACTNO) ADD CONSTRAINT ACT_EMP_REF FOREIGN KEY (EMPNO) REFERENCES EMPLOYEE ON DELETE RESTRICT ADD CONSTRAINT ACT_PROJ_REF FOREIGN KEY (PROJNO) REFERENCES PROJECT ON DELETE CASCADE
検査制約は、ALTER TABLE ステートメントを使用して既存の表に追加することができます。 制約名は、ALTER TABLE ステートメント内に指定した他のどの制約とも同じにすることはできず、 その表内で固有なものでなければなりません (これには、 定義されたすべての参照保全制約の名前も含まれます)。 ステートメントの完了前に、既存のデータが新しい条件に照らして検査されます。
大きな表に制約を追加するには、表を検査保留状態にし、制約を追加してから、 表を検査して制約に違反する行の統合リストを求めるのが効率的です。 明示して検査保留状態を設定するには、SET INTEGRITY ステートメントを使用します。 表が親表である場合、検査保留は、すべての従属表と子孫表にも暗黙に設定されます。
表検査制約が追加された場合、 表の挿入または更新を行うパッケージおよびキャッシュに入った動的 SQL は、 無効のマークが付けられます。 詳しくは、オブジェクトを変更する場合のステートメントの従属関係を参照してください。
コントロール・センターを使用して表検査制約を追加するには、以下のようにします。
|
コマンド行を使用して表検査制約を追加するには、以下のように入力します。
ALTER TABLE <name> ADD CONSTRAINT <name> (<constraint>)
次の SQL ステートメントは、 各従業員の給与と歩合給の合計が $25,000 を超えなければならないという制約を EMPLOYEE 表に追加するものです。
ALTER TABLE EMPLOYEE ADD CONSTRAINT REVENUE CHECK (SALARY + COMM > 25000)
ALTER TABLE ステートメントを使用して制約を除去します。 このステートメント (構文を含む) についての詳細は、 を参照してください。
制約について詳しくは、制約の定義を参照してください。
ALTER TABLE ステートメントを使用して、明示的に固有制約を除去することができます。 表上のすべての固有制約の名前は、SYSCAT.INDEXES システム・カタログ視点の中にあります。
以下の SQL ステートメントは、EMPLOYEE 表から固有制約 NEWID を除去します。
ALTER TABLE EMPLOYEE DROP UNIQUE NEWID
この固有制約を除去すると、 その制約を使用しているすべてのパッケージまたはキャッシュに入った動的 SQL を無効にします。
コントロール・センターを使用して基本キーを除去するには、以下のようにします。
|
コマンド行を使用して基本キーを除去するには、以下のように入力します。
ALTER TABLE <name> DROP PRIMARY KEY
外部キーが除去されると、 以下のものを含むパッケージまたはキャッシュに入った動的 SQL ステートメントは、 無効のマークが付けられます。
詳細は、オブジェクトを変更する場合のステートメントの従属関係を参照してください。
コントロール・センターを使用して外部キーを除去するには、以下のようにします。
|
コマンド行を使用して外部キーを除去するには、以下のように入力します。
ALTER TABLE <name> DROP FOREIGN KEY <foreign_key_name>
以下の例は、 ALTER TABLE ステートメントの DROP PRIMARY KEY および DROP FOREIGN KEY 文節を使用して、 表の基本キーと外部キーを除去します。
ALTER TABLE EMP_ACT DROP PRIMARY KEY DROP FOREIGN KEY ACT_EMP_REF DROP FOREIGN KEY ACT_PROJ_REF ALTER TABLE PROJECT DROP PRIMARY KEY
ALTER TABLE ステートメントについての詳細は、を参照してください。
表検査制約を明示的に除去または変更するには、ALTER TABLE ステートメントを使います。 また、DROP TABLE ステートメントを使うと、暗黙のうちに検査制約が除去されます。
表検査制約を除去すると、その表上で INSERT または UPDATE 依存関係を持つすべてのパッケージおよびキャッシュに入った動的 SQL ステートメントは、無効にされます。 (詳しくは、オブジェクトを変更する場合のステートメントの従属関係を参照してください。) 表内のすべての検査制約の名前は、SYSCAT.CHECKS カタログ視点の中にあります。 名前がシステム生成である表検査制約の除去を試行する前に、 SYSCAT.CHECKS カタログ視点でその名前を探してください。
コントロール・センターを使用して表検査制約を除去するには、以下のようにします。
|
コマンド行を使用して表検査制約を除去するには、以下のようにします。
ALTER TABLE <table_name> DROP CHECK <check_constraint_name>
次の SQL ステートメントは、 EMPLOYEE 表から REVENUE という表検査制約を除去するものです。
ALTER TABLE EMPLOYEE DROP CHECK REVENUE
生成列は基礎表に定義されます。 生成列に格納される値は、式を使って計算された値です。 挿入操作や更新操作で指定された値ではありません。 生成列は、表を作成する時、または既存の表を修正する時に作成できます。
生成列を定義するには、以下のステップを実行します。
SET INTEGRITY FOR t1 OFF
ALTER TABLE t1 ADD COLUMN c3 DOUBLE GENERATED ALWAYS AS (c1 + c2), ADD COLUMN c4 GENERATED ALWAYS AS (CASE WHEN c1 > c3 THEN 1 ELSE NULL END))
COMMIT
続いて db2gncol ユーティリティーを使用し、 生成列を設定する必要があります。 このユーティリティーは、 sqllib ディレクトリー中の bin サブディレクトリーにあります。 以下のようにこのユーティリティーを使用します。
db2gncol -d <dbname> -s <schema> -t <table_name> -c <commitcount>
dbname は、表のあるデータベースの別名を指定します。 schema は、表のスキーマ名を指定し、 大文字小文字の区別があります。 table_name は表を指定します。 その表の列のために、新しい値が式で計算して生成されます。 schema と table_name は両方とも大文字小文字の区別があります。 commitcount は、 ログをクリーンアップするための内部コミットから、 次の内部コミットまでの間に処理される行数です。 このパラメーターは、 列値の生成を実行するのに必要なログ・スペースのサイズに影響します。
前述の例には示されていないオプション・パラメーターが 2 つあります。 それは -u <username> と -p <password> で、 ユーザーとパスワードを識別します。 ユーザーには、SYSADM または DBADM 権限が必要です。 ユーザーとパスワードを識別しないと、 現行のユーザー ID が使用されます。
このユーティリティーに関するヘルプ情報が必要な場合は、 以下のように入力します。
db2gncol -h
ヘルプ・パラメーターを使用すると、 他のパラメーターはすべて無視されます。
表は、検査保留状態にある場合でも、プロセス全体のためにロックされます。 その理由は、検査保留状態の表にアクセスできる他のユーティリティーがあるからです。 ロックにより、この種のユーティリティーと競合しないようにされます。
SET INTEGRITY FOR t1 IMMEDIATE CHECKED FORCE GENERATED
注: | この時点で例外表を使用できます。 |
LOCK TABLE t1
SET INTEGRITY FOR t1 ALL IMMEDIATE UNCHECKED
UPDATE t1 SET (c3, c4) = (DEFAULT, DEFAULT) WHERE <predicate>
SET INTEGRITY FOR t1 OFF SET INTEGRITY FOR t1 IMMEDIATE CHECKED
COMMIT
ALTER TABLE t1 ACTIVATE NOT LOGGED INITIALLY
SET INTEGRITY FOR t1 IMMEDIATE CHECKED FORCE GENERATION
COMMIT
等価性の検査制約のように、式を適用することによって、 生成列の値に単純な検査を加えることもできます。
SET INTEGRITY FOR t1 IMMEDIATE CHECKED
生成列に (たとえば LOAD を使用して) 値を入れ、 かつその値が、生成された式に一致することが分かっている場合、 値の検査または割り当てを行わずに、表を検査保留状態から解除することができます。
SET INTEGRITY FOR t1 GENERATED COLUMN IMMEDIATE UNCHECKED
生成列を定義できるのは、 等価性の比較が定義されているデータ・タイプだけです。 生成列を定義できないデータ・タイプとしては、 構造型、LOB、 CLOB、DBCLOB、LONG VARCHAR、LONG VARGRAPHIC、 およびこれらのデータ・タイプを使用して定義したユーザー定義のタイプがあります。
制約、固有索引、参照制約、基本キー、 およびグローバル一時表には生成列を使用できません。 LIKE を使用して作成した表と、具体化した視点は、 生成列の特性を継承しません。
キーワード DEFAULT を指定しないと、 生成列を挿入したり更新したりできません。 挿入の際に DEFAULT を使用すると、 列リストに列を列挙する必要がなくなります。 代わりに値リストの中で生成列を DEFAULT に設定できます。 更新の際に DEFAULT を使用すると、 SET INTEGRITY によって検査抜きでオンラインで配置された生成列を再計算できます。
トリガー処理の順序の関係上、BEFORE トリガーのヘッダー (更新前) または本体が、 生成列を参照するようになっていてはなりません。 処理の順序としては、 生成列は BEFORE トリガーの後に処理されます。
db2look ユーティリティーは、 生成列によって生成される検査制約を考慮に入れません。
複製を使用する際には、 ターゲット表のマッピングに生成列を使用してはなりません。 複製する際には 2 つの選択肢があります。
生成列を処理する際には複数の制約事項があります。
揮発性 表は、 実行時にその内容が空であるものから内容が非常に大きなものに至るまで、 さまざまな内容を持つ表として定義されます。 この種の表には揮発性、つまり極端な変更の可能性があるため、 RUNSTATS が収集する統計の信頼性が不確かなものになります。 統計は一時点で収集され、表面的なものにすぎません。 揮発性表を使用するアクセス・プランを生成しても、 実行プランが不正確または貧弱なものになる可能性があります。 たとえば、揮発性表が空のときに統計を収集すると、最適化プログラムの傾向として、 索引走査ではなく表走査を使って揮発性表にアクセスするほうが優先されます。
この傾向を回避するには、ALTER TABLE ステートメントを使って、 表を揮発性として宣言することを考慮してください。 表を揮発性として宣言すれば、 最適化プログラムは表走査ではなく索引走査の使用を考慮します。 宣言された揮発性表を使用するアクセス・プランは、該当する表の既存統計には依存しません。
コントロール・センターを使用して表の揮発性を宣言するには、以下のようにします。
|
コマンド行を使用して表の揮発性を宣言するには、以下のように入力します。
ALTER TABLE <table_name> VOLATILE CARDINALITY
表を "揮発性"として宣言するには、次のようにします。
ALTER TABLE TABLENAME VOLATILE CARDINALITY
単一区画ノード・グループ内の表の区分化キーのみを変更することができます。 まず既存の区分化キーを除去してから、別の区分化キーを作成してください。
以下の SQL ステートメントは、MIXREC 表から区分化キー MIX_INT を除去します。
ALTER TABLE MIXREC DROP PARTITIONING KEY
詳しくは、の ALTER TABLE ステートメントの説明を参照してください。
複数データベース区画ノード・グループの中の表の区分化キーは、変更できません。 この区分化キーを除去しようとすると、エラーが戻されます。
複数データベース区画ノード・グループの区分化キーを変更するには、 以下のどちらかを実行します。
これらの方法はいずれも、大きなデータベースの場合は現実的ではありません。 このため、大きなデータベースの設計を実現する前に、 適切な区分化キーを定義しておくことがもっとも重要です。
データ取り込みオプション、各ページでの空きスペースのパーセンテージ (PCTFREE)、 ロック・サイズ、または追加モードなどの表属性を変更する必要があるかもしれません。
表の各ページに残す空きスペースの量は、PCTFREE によって指定しますが、 これはクラスター索引を効果的に使用するための重要な考慮事項です。 指定する量は、既存のデータと予想される将来のデータの性質によって決まります。 PCTFREE の指定は、LOAD と REORG については有効ですが、 挿入、更新、およびインポート活動では無視されます。
PCTFREE を大きな値に設定すると、クラスター化を長い期間保つことができますが、 ディスク・スペースもより多く必要となります。
LOCKSIZE パラメーターを使用して、 表がアクセスされるときに使用されるロックのサイズ (細分性) を指定できます。 表が作成されるとき、省略時には行レベルのロックが定義されます。 表レベルのロックを使用すると、獲得し解放する必要のあるロックの数を限定することによって、 照会のパフォーマンスが向上します。
APPEND ON を指定すると、全体のパフォーマンスを向上させることができます。 これによって、より速い挿入が可能となり、 一方では空きスペースについての情報が除去されます。
クラスター化索引のある表は、追加モードをオンにするように変更することはできません。 同様に、追加モードの表でクラスター化索引を作成することはできません。
多少の制約事項はありますが、 要約表を正規表に変更したり、正規表を要約表に変更したりできます。 他の表タイプは変更できません。 変更できるのは正規表と要約表だけです。 たとえば、複製要約表から正規表に (あるいはその逆に) 変更することはできません。
正規表を要約表に変更すると、その表は検査保留状態になります。 このように変更した場合、 要約表の定義を全選択したものは変更前の表の定義と一致していなければなりません。 つまり、以下の点を満たしていなければなりません。
元の表に定義されている要約表を、要約表に変更することはできません。 元の表にトリガー、検査制約、参照制約、 または定義済みの固有索引がある場合、 その表を要約表に変更することはできません。 要約表を定義するために表の特性を変更する場合、 同じ ALTER TABLE ステートメントを使って、別の方法で表を変更することはできません。
正規表を要約表に変更する場合、要約表の定義の全選択では、 元の表を直接、あるいは視点、別名、または要約表を介して間接的に参照することはできません。
要約表を正規表に変更するには、以下のようにします。
ALTER TABLE sumtable SET SUMMARY AS DEFINITION ONLY
正規表を要約表に変更するには、以下のようにします。
ALTER TABLE regtable SET SUMMARY AS <fullselect>
正規表を要約表に変更する際の全選択に関する制約事項は、 CREATE SUMMARY TABLE ステートメントを使用して要約表を作成する際の制約事項に大変類似しています。
CREATE SUMMARY TABLE ステートメントの詳細については、 を参照してください。
REFRESH TABLE ステートメントを使用して、 1 つまたは複数の要約表のデータを最新表示できます。 このステートメントは、アプリケーション・プログラムに組み込むこともできますし、 動的に出すこともできます。 このステートメントを使用するには、SYSADM または DBADM 権限か、 更新する表に対する CONTROL 特権が必要です。
以下の例は、要約表のデータを最新表示する方法を示したものです。
REFRESH TABLE SUMTAB1
REFRESH TABLE ステートメントの詳細については、を参照してください。
構造型の作成後に、 その構造型に関連した属性を追加または削除しなければならないことに気付くことがあるでしょう。 これは、ALTER TYPE (構造化) ステートメントを使用して行われます。 構造型に関する必要なすべての情報については、 を参照してください。
検索済み DELETE ステートメントか、 位置決め済み DELETE ステートメントのいずれかを使用して、 行をタイプ付き表から削除できます。 検索済み UPDATE ステートメントか、 位置決め済み UPDATE ステートメントのいずれかを使用して、 タイプ付き表の行を更新できます。 タイプ付き表に関する必要なすべての情報については、 を参照してください。
スキーマ内の既存の表に新しい名前を与え、 オリジナルの表に作成されていた許可と索引はそのまま維持することができます。
名前変更する既存の表は、表を識別する別名であっても構いません。 名前変更する既存の表は、カタログ表、要約表、タイプ付き表、 または表か別名以外のオブジェクトの名前であってはなりません。
既存の表は、以下のいずれでも参照できません。
また、表内に検査制約があったり、 識別列以外の生成列があったりしてはなりません。 オリジナルの表に依存するパッケージまたはキャッシュに入った動的 SQL ステートメントは、 すべて無効にされます。 オリジナルの表を参照している別名は修正されません。
名前変更している表が、これらの制約事項のいずれの影響も受けないようにするために、 該当のシステム・カタログ表を検査することを考慮する必要があります。
名前が変更されたばかりの表をパッケージが参照する場合は、 そのパッケージを再バインドしなければなりません。 以下のいずれかの場合には、パッケージは暗黙に再バインドすることができます。
暗黙または明示の再バインドを試みる前に、 上記の 2 つのいずれかを選択していなければなりません。 どちらも選択していないと、再バインドは失敗します。
コントロール・センターを使用して既存の表の名前を変更するには、以下のようにします。
|
コマンド行を使用して既存の表の名前を変更するには、 以下のように入力します。
RENAME TABLE <schema_name.<table_name> TO <new_name>
下記の SQL ステートメントは、 COMPANY スキーマ内の EMPLOYEE 表の名前を EMPL に変更します。
RENAME TABLE COMPANY.EMPLOYEE TO EMPL
RENAME TABLE ステートメントの詳細については、を参照してください。
表を除去するには、DROP TABLE SQL ステートメントを使います。
表が除去されると、その表についての情報が含まれる SYSCAT.TABLES カタログの中の行が除去され、 その表に依存する他のオブジェクトがあれば、影響を受けます。 次に例を示します。
コントロール・センターを使用して表を除去するには、以下のようにします。
|
コマンド行を使用して表を除去するには、以下のように入力します。
DROP TABLE <table_name>
次のステートメントは、DEPARTMENT という表を除去するものです。
DROP TABLE DEPARTMENT
個々の表に副表がある場合、その表は除去できません。 ただし、次の例に示すとおり、表階層内の表はすべて、 単一の DROP TABLE HIERARCHY ステートメントを使って除去できます。
DROP TABLE HIERARCHY person
DROP TABLE HIERARCHY ステートメントでは、 除去する階層のルート表を指定しなければなりません。
表階層の除去と特定表の除去を比較した場合、次のような相違があります。
DROP ステートメントの詳細については、を参照してください。
ユーザー定義一時表 (DECLARE GLOBAL TEMPORARY TABLE ステートメントを使用して作成した表) を除去する際には、 いくつかの考慮事項に注意する必要があります。
この種の表を除去する際には、 表名がスキーマ名 SESSION で修飾されていなければならず、 その表を作成したアプリケーション中になければなりません。
パッケージはこのタイプの表に従属できないので、 この種の表を除去しても無効になりません。
活動状態の作業単位や保管ポイントより前に作成したユーザー定義一時表を除去すると、 その表は機能的に除去され、 アプリケーションはその表にアクセスできなくなります。 しかし、その表のスペースは依然として表スペース中に予約されているため、 その作業単位がコミットされるか保管ポイントが終了するまで、 ユーザー一時表スペースは除去できません。
DROP ステートメントの詳細については、を参照してください。
トリガー・オブジェクトは DROP ステートメントを使用して除去できますが、 この手順によって、以下のように従属パッケージに無効のマークが付けられます。
パッケージは、アプリケーション・プログラムが明示的にバインドまたは再バインドされるか、 あるいは、そのパッケージが実行され、 データベース・マネージャーが自動的に再バインドを行うかするまで、無効のままとなります。
ユーザー定義関数 (UDF)、関数テンプレート、または関数マッピングは、 DROP ステートメントを使って除去することができます。
マッピング・オプション DISABLE を指定すれば、 関数マッピングを使用不可にすることができます。 実行方法についての詳細は、を参照してください。
ある UDF に視点、トリガー、表検査制約、または別の UDF が従属している場合、 その UDF は除去できません。 CREATE DISTINCT TYPE ステートメントによって暗黙的に生成された関数は除去できません。 SYSIBM スキーマまたは SYSFUN スキーマのいずれかの中にある関数は、除去できません。
他のオブジェクトを 1 つの関数または関数テンプレートに従属させることができます。 関数を除去する前に、そのような従属関係 (関数マッピングを含む) を除去しておかなければなりません。 ただし、作動不能のマークが付いているパッケージは例外です。 このようなパッケージは、暗黙には再バインドされません。 パッケージは、BIND または REBIND コマンドを使用して再バインドされるか、 あるいは、PREP コマンドを使用して準備されていなければなりません。 上記のコマンドについての詳細は、を参照してください。 UDF を除去すると、 それを使用していたパッケージまたはキャッシュに入った動的 SQL ステートメントをすべて無効にします。
関数マッピングを除去すると、パッケージに無効のマークが付けられます。 自動再バインドが実行され、最適化プログラムはローカル関数を使用しようとします。 ローカル関数がテンプレートである場合、暗黙的な再バインドは失敗します。
(詳細については、オブジェクトを変更する場合のステートメントの従属関係を参照してください。)
ユーザー定義タイプ (UDT) またはタイプ・マッピングは、 DROP ステートメントを使って除去することができます。 以下のように UDT が使用されている場合には UDT を除去できません。
省略時のタイプ・マッピングは除去できません。 別のタイプ・マッピングを作成して指定変更することしかできません。
データベース・マネージャーはこの特殊タイプに依存する関数をすべて除去しようとします。 UDF を除去できなければ、UDT を除去できません。 ある UDF に視点、トリガー、表検査制約、または別の UDF が従属している場合、 その UDF は除去できません。 UDT を除去すると、 それを使用していたパッケージまたはキャッシュに入った動的 SQL ステートメントをすべて無効にします。
UDT 用の変換を作成し、UDT の除去を計画している場合は、 変換を除去する必要があるかどうかを考慮してください。 これは、DROP TRANSFORM ステートメントを使って実行されます。 このステートメントの詳細については、を参照してください。 管理者または他のアプリケーション開発者によって定義された変換だけを除去できる点に注意してください。 組み込み変換とその関連グループの定義を除去することはできません。
ユーザー定義タイプについての詳細は、 および を参照してください。
ALTER VIEW ステートメントは、 効力範囲を追加するよう参照タイプ列を変更することによって、既存の視点を変更します。 視点に加えるその他の変更では、視点を除去した後に再作成する必要があります。
視点を変更するときには、効力範囲がまだ定義されていない既存の参照タイプ列に、 効力範囲を追加することが必要です。 さらに、列はスーパー表から継承したものであってはなりません。
ALTER VIEW ステートメントの列名のデータ・タイプは、 REF (タイプ付き表名またはタイプ付き視点名のタイプ) でなければなりません。
パッケージ、またはキャッシュに入った動的ステートメントに無効のマークが付けられても、 表および索引のような他のデータベース・オブジェクトは影響されません。 詳しくは、オブジェクトを変更する場合のステートメントの従属関係を参照してください。
ALTER VIEW ステートメントの詳細については、を参照してください。
コントロール・センターを使用して視点を変更するには、以下のようにします。
|
コントロール・センターを使用して視点を除去するには、以下のようにします。
|
コマンド行を使用して視点を除去するには、以下のように入力します。
DROP VIEW <view_name>
以下の例は、EMP_VIEW を除去する方法を示したものです。
DROP VIEW EMP_VIEW
除去する視点に依存する視点があれば、それらは作動不能になります。 (詳しくは、作動不能視点の回復を参照してください。)
表階層の場合と同様、階層のルート視点を指定しても、 次の例に示すとおり、1 つのステートメント内で視点階層全体を除去することはできません。
DROP VIEW HIERARCHY VPerson
視点の除去と作成についての詳細は、を参照してください。
視点は、基礎表での SELECT 特権を取り消されると、 作動不能 になります。
次のステップは、作動不能視点を回復するのに役に立ちます。
作動不能視点を回復したくない場合は、 DROP VIEW ステートメントを使用してその視点を明示的に除去するか、 または同じ名前と別の定義を使用して新規の視点を作成することができます。
作動不能視点は、SYSCAT.TABLES および SYSCAT.VIEWS カタログ視点にしか項目がありません。 SYSCAT.VIEWDEP、SYSCAT.TABAUTH、SYSCAT.COLUMNS、 および SYSCAT.COLAUTH カタログ視点のすべての項目が除去されます。
要約表は変更できませんが、除去することはできます。
この表を参照しているすべての索引、基本キー、外部キー、および検査制約が除去されます。 この表を参照するすべての視点およびトリガーは、作動不能になります。 除去されたオブジェクトまたは作動不能とマークされたオブジェクトに依存するすべてのパッケージは、 無効になります。 パッケージの従属関係の詳細については、オブジェクトを変更する場合のステートメントの従属関係を参照してください。
コントロール・センターを使用して要約表を除去するには、以下のようにします。
|
コマンド行を使用して要約表を除去するには、以下のように入力します。
DROP TABLE <table_name>
次の SQL ステートメントは、要約表 XT を除去するものです。
DROP TABLE XT
要約表は、基礎表での SELECT 特権を取り消されると、 作動不能 になります。
次のステップは、作動不能要約表を回復するのに役に立ちます。
作動不能要約表を回復したくない場合は、 DROP TABLE ステートメントを使用してその要約表を明示的に除去するか、 または同じ名前と別の定義を使用して新規の要約表を作成することができます。
作動不能要約表は、SYSCAT.TABLES および SYSCAT.VIEWS カタログ視点にしか項目がありません。 SYSCAT.VIEWDEP、SYSCAT.TABAUTH、 SYSCAT.COLUMNS、および SYSCAT.COLAUTH カタログ視点のすべての項目が除去されます。
DROP ステートメントを使うと、データベースからラッパーを除去することができます。 以下の例は、DRDA ラッパーを除去する方法を示したものです。
DROP WRAPPER DRDA
除去されるラッパーに従属するサーバー、タイプ・マッピング、関数マッピング、 ユーザー・マッピング、およびニックネームは除去されます。 ラッパーを除去する場合は、特に注意してください。
DROP ラッパーに対する SYSADM または DBADM 権限のいずれかを持っている必要があります。
ラッパーの除去についての詳細は、を参照してください。
ALTER SERVER ステートメントは、 統合データベース・カタログ内の既存サーバー定義を修正します。 このステートメントは、次の目的で使用します。
このステートメントを使って、 dbname または node サーバー・オプションを修正することはできません。
次の例は、ORA1 サーバーの変更方法を示しています。
ALTER SERVER ORA1 OPTIONS (SET CPU_RATIO '5.0')
サーバーは統合データベースから除去することができます。
次の例は、ORALOC01 サーバーを除去する方法を示しています。
DROP SERVER ORALOC01
除去されるサーバーに従属するタイプ・マッピング、関数マッピング、 ユーザー・マッピング、およびニックネームは除去されます。 サーバーを除去する場合は、注意が必要です。
ALTER または DROP サーバーに対する SYSADM または DBADM 権限のいずれかを持っている必要があります。
サーバーの除去および変更についての詳細は、を参照してください。
ALTER NICKNAME を使うと、 データ・ソース表または視点に関してローカルに保管された情報を更新することができます。 たとえば、このステートメントを使って列のローカル名を変更したり、 列データ・タイプを別のデータ・タイプにマップしたりすることができます。 このステートメントは列オプションを追加する場合にも使用できます。 ALTER NICKNAME 構文についての詳細は、を参照してください。
ニックネームが除去されると、そのニックネームに関して作成された視点には作動不能のマークが付けられます。 ニックネームが視点内で参照されているときにニックネームの列名やデータ・タイプを変更することはできません。
SYSADM または DBADM 権限の 1 つか、 ニックネームに対する CONTROL および ALL データベース特権のいずれか、 または ALTERIN (現行スキーマの場合) スキーマ特権を持っているか、 あるいはニックネームの定義者でなければ、 統合データベースでこのステートメントを使用することはできません。
次の例は、ニックネーム TESTNN を変更して、 COL1 から列のローカル名を NEWCOL に変更する方法を示しています。
ALTER NICKNAME TESTNN ALTER COLUMN COL1 LOCAL NAME NEWCOL
次の例は、ニックネーム TESTNN を除去する方法を示しています。
DROP NICKNAME TESTNN
列オプション というパラメーターに割り当てる値の形式で列情報を指定します。 これらの値は、大文字でも小文字でも指定できます。 『環境についての考慮事項』という章の末尾にある 『後入れ先出しの機械に影響するニックネーム特性』という節で、 『列のオプション』という節を参照してください。 各値の説明と追加情報が記されています。
索引定義、索引の拡張、または索引の指定の文節は変更できません。 索引や索引の拡張を除去してから再び作成してください。 (索引または索引の指定を除去しても、他のオブジェクトが除去されることはありません。 しかし、場合によっては一部のパッケージが無効になることがあります。)
コントロール・センターを使用して索引、索引の拡張、
または索引の指定を除去するには、以下のようにします。
|
コマンド行を使用して索引、索引の拡張、 または索引の指定を除去するには、以下のように入力します。
DROP INDEX <index_name>
次の SQL ステートメントは、PH という索引を除去するものです。
DROP INDEX PH
次の SQL ステートメントは、IX_MAP という索引の拡張を除去するものです。
DROP INDEX EXTENSION ix_map RESTRICT
索引の拡張の名前は、 カタログ中に記述されている索引の拡張を識別するものでなければなりません。 RESTRICT 文節は、 索引の拡張の定義に従属する索引は定義できないという規則を施行します。 基礎となる索引がこの索引の拡張に従属していると、除去は失敗します。
基本キーまたは固有キーの索引 (索引の指定でない場合に限る) は、 明示的に除去することはできません。 索引を除去するには、次の方法のいずれかを使用してください。
その索引に依存するパッケージ、およびキャッシュに入った動的 SQL ステートメントには、 無効のマークが付けられます。 詳しくは、オブジェクトを変更する場合のステートメントの従属関係を参照してください。 アプリケーション・プログラムは、索引の追加や除去による変更事項には影響されません。
ステートメントの従属関係には、パッケージ、 およびキャッシュに入った動的 SQL ステートメントが含まれます。 パッケージ とは、 データベース・オブジェクトの 1 つで、データベース・マネージャーが、 特定のアプリケーション・プログラムにとって最も効率的な方法でデータにアクセスするのに必要な情報が入れられたものです。 バインド とは、データベース・マネージャーが、 アプリケーションの実行時にデータベースにアクセスするのに必要なパッケージを作成するプロセスです。 に、パッケージの作成方法についての詳細な説明があります。
パッケージおよびキャッシュに入った動的 SQL ステートメントは、 さまざまなタイプのオブジェクトに従属することができます。 これらのオブジェクトの全リストについては、を参照してください。
そうしたオブジェクトは、明示的に参照できます。 SQL SELECT ステートメントに含める表やユーザー定義関数などはその例です。 また、暗示的に参照できるオブジェクトもあります。 たとえば、親表の行の削除時に、 参照制約の違反がないかどうかの検査が必要な従属表がそうです。 パッケージはさらに、パッケージ作成者に付与される特権にも依存しています。
パッケージ、またはキャッシュに入った動的 SQL ステートメントがオブジェクトに依存しており、 そのオブジェクトが除去された場合は、 そのパッケージまたはキャッシュに入った動的 SQL ステートメントは、「無効」状態になります。 パッケージがユーザー定義関数に従属し、その関数が除去されると、 パッケージは「作動不能」状態になります。
キャッシュに入れられた動的 SQL ステートメント (無効状態) は再び、 次の使用に関して自動的に最適化されます。 ステートメントに必要なオブジェクトが除去されている場合に動的 SQL ステートメントを実行すると、 失敗してエラー・メッセージが表示されることがあります。
無効状態にあるパッケージは、次の使用に関して暗黙的に再バインドされます。 そのようなパッケージは明示的に再バインドすることもできます。 トリガーが除去されたためにパッケージに無効のマークが付けられた場合、 再バインド・パッケージはトリガーを呼び出さなくなります。
無効状態のパッケージは、明示的に再バインドした後でなければ使用できません。 パッケージのバインドおよび再バインドについての詳細は、 を参照してください。
統合データベースのオブジェクトには、同様の従属関係があります。 たとえば、サーバーを除去すると、 そのサーバーに関連付けられたニックネームを参照するパッケージ、 またはキャッシュに入れられた動的 SQL は無効になります。
ある場合には、パッケージを再バインドできないことがあります。 たとえば、表が除去されたのに再作成されない場合は、パッケージを再バインドできません。 この場合、オブジェクトを再作成するか、 除去されたオブジェクトをアプリケーションが使用しないようにアプリケーションを変更しなければなりません。
その他のほとんどの場合、たとえば、制約の一部が除去された場合は、 パッケージを再バインドすることが可能です。
以下のシステム・カタログ視点は、 パッケージの状態およびパッケージの従属関係を判別するのに役立ちます。
オブジェクトの従属関係について詳しくは、 の DROP ステートメントの説明を参照してください。