スキーマ管理

次に例を示します。 RES表があり、次に示すように、索引を作成したと仮定します。

SQL> create index in_res_guest on res (guest_id);
                       

SQL> select * from res where guest_id = 101;
                       

Execution Plan
----------------------------------------------------------
Plan hash value: 1519600902
 
--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |     1 |    28 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| RES          |     1 |    28 |     3   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IN_RES_GUEST |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("GUEST_ID"=101)
                       

SQL> alter index in_res_guest invisible;
 
Index altered.
                       

SQL> select * from res where guest_id = 101
  2  /
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3824022422
 
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    28 |   140   (2)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| RES  |     1 |    28 |   140   (2)| 00:00:02 |
--------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("GUEST_ID"=101)
                       

SQL> select /*+ INDEX (res IN_RES_GUEST) */ res_id from res where guest_id = 101;

--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              |     1 |    28 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| RES          |     1 |    28 |     3   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IN_RES_GUEST |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
                       

一方、セッションレベルのパラメータを設定して非表示索引を使用することもできます。

SQL> alter session set optimizer_use_invisible_indexes = true;
                       

SQL> select visibility
  2  from user_indexes
  3 where index_name = 'IN_RES_GUEST';

VISIBILITY
---------
INVISIBLE
                       

ところで、この索引は厳密には、"何に"対する非表示なのでしょうか。 ユーザーに対する非表示ではありません。 オプティマイザだけに対する非表示です。 挿入、更新、削除などの通常のデータベース操作では、引き続き索引は更新されます。 非表示の索引を作成する際は注意してください。DML操作中に代償を払いながら、同時に索引によるパフォーマンスの向上を得るということはありません。

読取り専用表

ロビンが必要としているのは、スイッチのように動作して、表の更新を可能にしたり不可能にしたりすることです。 この操作の実装は、実際には非常に困難です。 ロビンにはどんな選択肢があるのでしょうか。

選択肢の1つは、 INSERT、 DELETE、および UPDATEの例外を発生させるトリガーを表に作成することです。 コンテキストの切替えを含むトリガーの実行は、パフォーマンスの面ではよくありません。 もう1つの選択肢は、"1=2"のような誤った文字列を常に返すVirtual Private Database（VPD）を作成することです。 表のVPDポリシーがこの機能を使用すると、FALSEを返してDMLは失敗します。 これはトリガーを使用する選択肢よりもパフォーマンスが高くなる可能性はありますが、"policy function returned error"のようなエラー・メッセージが表示されることが好ましくないのは明らかです。

しかし、Oracle Database 11g では、目的を達成するより優れた方法があります。 次のような読取り専用表を作るだけです。

SQL> alter table TRANS read only;
 
Table altered.
                       

これで、次に示すようなDMLの実行をユーザーが試行すると、

SQL> delete trans;
                       

Oracle Database 11g はすぐにエラーを返します。

delete trans
       *
ERROR at line 1:
ORA-12081: update operation not allowed on table "SCOTT"."TRANS"
                       

エラー・メッセージは文字通りには操作を反映していませんが、目的に沿ったメッセージを伝えています。トリガーまたはVPDポリシーのオーバーヘッドもありません。

更新可能な表が欲しい場合、次のように読取り/書込み可能にする必要があります。

SQL> alter table trans read write;
 
Table altered.
                       

これでDMLを実行しても問題ありません。

SQL> update trans set amt = 1 where trans_id = 1;
 
1 row updated.
                       

表が読取り専用モードのみである間、DMLは許可されません。すべてのDDL操作（索引の作成、パーティションの管理など）をおこなうことは可能です。 よって、この機能のとても有用な用途は表の管理となります。 表を読取り専用にして、必要なDDLを実行してから、再度読取り/書込み可能にすることができます。

表のステータスを確認するには、データ・ディクショナリ・ビューdba_tablesのread_only列を参照します。

SQL> select read_only from user_tables where table_name = 'TRANS';
 
REA
---
NO
                       

ファイン・グレイン依存性追跡

この機能は、例を用いると適切に説明できます。 次のように作成されたTRANSと呼ばれる表を考えてみましょう。

create table trans
(
    trans_id        number(10),
    trans_amt       number(12,2),
    store_id        number(2),
    trans_type      varchar2(1)
)
                       

ユーザーがこの表から直接データを取得することは想定していません。次に示すように作成されるVW_TRANSビューを使用して取得します。

create or replace view vw_trans
as
select trans_id, trans_amt  
from trans;
                       

このVW_TRANSビューはTRANS表に依存します。 次の問合せで依存性を確認できます。

select d.referenced_name, o.status 
from user_dependencies d, user_objects o
where d.name = o.object_name
and d.name = 'VW_TRANS'
/

REFERENCED_NAME                                                  STATUS
---------------------------------------------------------------- -------
TRANS                                                            VALID
                       

VW_TRANSビューのステータスは、次のとおりVALIDです。 次に、列の追加といった何らかの方法で、元の表を変更します。

alter table trans
add (trans_date date);
                       

このビューは変更された表に依存するので、Oracle Database 10g およびそれ以前のリリースでは、無効化されます。 前述の問合せで依存性と現在のステータスを確認できます。

REFERENCED_NAME                                                  STATUS
---------------------------------------------------------------- -------
TRANS                                                            INVALID
                       

ステータスはINVALIDと表示されています。 このビューを永続的に無効とするような根本的な変更は何もおこなわれていないので、次のように簡単に再コンパイルできます。

alter view vw_trans compile;
                       

それでは、なぜこの表は無効化されたのでしょうか。 答えは簡単です。 親オブジェクトが変更されると、子オブジェクトは自動的に監視下に置かれます。同様に何らかの変更が必要になる可能性があるからです。 しかしこの場合、変更とは新しい列の追加です。 ビューはその列を使用しないというのに、なぜ無効化されなければならないのでしょうか。

Oracle Database 11g では、無効化されません。 依存性は依然としてTRANSに設定されていますが、ステータスはINVALIDではなくVALIDです。

REFERENCED_NAME                                                  STATUS
---------------------------------------------------------------- -------
TRANS                                                            VALID
                       

ビューが無効化されないので、別のビュー、またはパッケージやプロシージャなど、ビューのすべての依存性オブジェクトも無効化されません。 この動作により、アプリケーションの可用性に大きな価値が付加され、スタック全体の可用性も高まります。 データベースの若干の変更にアプリケーションを停止する必要はありません。

TRANS_AMTなどのビューで使用される列を変更すると、ビューは無効化されます。 列の変更はビューに影響する可能性があるため、これも適切な動作です。

しかし、高可用性は、ビューや表だけに留まりません。プロシージャやパッケージなどのほかの保存されたオブジェクトに対しても必要です。 次のようなパッケージについて考えてみましょう。

create or replace package pkg_trans
is
        procedure upd_trans_amt
        (
                p_trans_id      trans.trans_id%type,
                p_trans_amt     trans.trans_amt%type
        );
end;
/

create or replace package body pkg_trans
is
        procedure upd_trans_amt
        (
                p_trans_id      trans.trans_id%type,
                p_trans_amt     trans.trans_amt%type
        ) is
        begin
                update trans
                set trans_amt = p_trans_amt
                where trans_id = p_trans_id;
        end;
end;
/
                       

トランザクションの量を指定した割合で増加するファンクションを作成すると仮定します。 このファンクションはpkg_transパッケージを使用します。

create or replace function adjust
(
        p_trans_id      number,
        p_percentage    number
)
return boolean
is
        l_new_trans_amt number(12);
begin
        select trans_amt * (1 + p_percentage/100)
        into l_new_trans_amt
        from trans
        where trans_id = p_trans_id;
        pkg_trans.upd_trans_amt (
                p_trans_id,
                p_percentage
        );
        return TRUE;
exception
        when OTHERS then
                return FALSE;
end;
/
                       

ファンクションのステータスを確認すると、VALIDとあります。

select status
from user_objects
where object_name = 'ADJUST'
/

STATUS
-------
VALID
                       

vendor_name列を更新する新しいプロシージャを追加して、pkg_transパッケージを変更すると仮定します。 次に新しいパッケージの定義を示します。

create or replace package pkg_trans
is
        procedure upd_trans_amt
        (
                p_trans_id      trans.trans_id%type,
                p_trans_amt     trans.trans_amt%type
        );
        procedure upd_vendor_name
        (
                p_trans_id      trans.trans_id%type,
                p_vendor_name   trans.vendor_name%type
        );
                
end;
/

create or replace package body pkg_trans
is
        procedure upd_trans_amt
        (
                p_trans_id      trans.trans_id%type,
                p_trans_amt     trans.trans_amt%type
        ) is
        begin
                update trans
                set trans_amt = p_trans_amt
                where trans_id = p_trans_id;
        end;
        procedure upd_vendor_name
        (
                p_trans_id      trans.trans_id%type,
                p_vendor_name   trans.vendor_name%type
        ) is
        begin
                update trans
                set vendor_name = p_vendor_name
                where trans_id = p_trans_id;
        end;
end;
                       

このパッケージを再コンパイルすると、adjustファンクションのステータスはどうなるでしょうか。 Oracle Database 10gおよびそれ以前のリリースでは、このファンクションは依存しているため、無効化されて次に示すステータスになります。

STATUS
-------
INVALID
                       

これを alter function ... recompileによりコンパイルすることは容易ですが、Oracle Database 11g では、このファンクションは無効化されません。

STATUS
-------
VALID
                       

これにより高可用性の概念は大幅に高まります。 adjustファンクションはpkg_transパッケージの変更された部分を呼び出さないので、このファンクションを無効化する必要はなく、Oracle Database 11gでは無効化されません。

ただし、常にそうとは限りません。 前述の例で示したように、新しいサブ・コンポーネントがパッケージの最後に追加されるような方法でパッケージが変更された場合、依存する保存されたコードは無効化されません。 しかし、次のようにサブ・コンポーネントが最初に追加された場合、

create or replace package pkg_trans
is
        procedure upd_vendor_name ...
        procedure upd_trans_amt ...
end;
                       

Oracle Database 10gおよびそれ以前の場合と同様、依存するadjustファンクションは無効化されます。 これが発生するのは、新しいプロシージャが既存のプロシージャの前に挿入され、パッケージのスロット番号が変更されたため、無効化がトリガーされたからです。 プロシージャが既存のプロシージャの後に挿入されたときは、パッケージのスロット番号は変更されず、新しいスロット番号が追加されただけでした。

次に、依存性に関係する無効化を減少させるための共通のガイドラインを示します。

• ファンクションやプロシージャなどのコンポーネントは、パッケージの最後に追加します。
• 無効化の原因としてよく見られるのはデータ型の変更です。 列名を指定しないとプロシージャはすべての列を想定するので、該当する列が使用されない場合でも、変更があればプロシージャは無効化されます。 たとえば、 select * from sometableを使用する場合、表のすべての列が想定されます。 列のリストが挙げられない、 select *のような構成、 sometable%rowtypeや insert into sometable values (...)のようなデータ型は避けてください。
• 可能であれば、保存されたコード内の表のビューを使用します。 これにより、保存されたコードが使用していない表に列を追加できます。 前述のように、ビューは無効化されないので、保存されたコードも同様に無効化されません。
• シノニムを作成する場合、以下の形式を利用し、

  create or replace synonym ...;
                             
  

  以下は、利用しないでください。。

  drop synonym ...;
  create synonym ...;
                             
  

  最初の形式では、プロシージャを無効化しません。

また、オンライン再定義を使用した場合、以前は再定義が依存性オブジェクトを無効化するのを見たかもしれません。Oracle Database 11g では、それは起こりません。 参照される列が同じ名前および型であるならば、オンライン再定義はオブジェクトを無効化しません。 再定義中に列が削除されてもプロシージャがその列を使用していなければ、プロシージャは無効化されません。

結論

ご覧のとおり、これまでのように労力のかかるコマンドが非常に簡単になっただけではなく、場合によっては、毎日の業務を改善し得る新しい手法が実現しました。

これまで、Oracleデータベースの機能における多くの変更を見てきましたが、ビジネスの方法を再定義するような画期的なものがいくつかありました。 ここで説明したものは、そのようなカテゴリに入ります。

"Oracle Database 11g ：DBAと開発者のための主要な機能"ホームページに戻る

---

Arup Nanda（ arup@proligence.com）は、Oracleデータベーステクノロジのあらゆる分野で12年以上の経験を持つ優秀なOracle DBAであり、2003年の『Oracle Magazine』で"DBA of the Year"に選ばれました。 Arupは、オラクル関連のイベントの講演や雑誌の寄稿を頻繁におこなっている Oracle ACE Directorです。 また、『 RMAN Recipes for Oracle Database 11g: A Problem Solution Approach』を含む4冊の書籍を共同で執筆しています。