┏┏┏┏┏━━━━━━━━━━━━━━━━━━━━━━━━…・・ ┏━
┏┏┏┏┛ 2001.11.28 ┏┛┛
┏┏┏┛ ☆おら！オラ！Oracle -どっぷり検証生活-★ ┏┛┛┛
┏┏┛ ┏┛┛┛┛
┏┛・・…━━━━━━━━━━━━━━━━Vol.83━…・・ ┏┛┛┛┛┛
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
■□注意事項□■
本文中にテーブルが含まれていますので、お読みになる際はMSゴシッ
ク等、等幅フォントをお使いただくことをお勧めします。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 Oracle 検証生活 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜ ログマイナに関する検証 その四 ＞ ペンネーム チョビひげ
--- ログ・マイナーで索引構成表を見よう ---
前回はログ・マイナーで行連鎖を見た。
今回は索引構成表とクラスタを見てみたい。
索引構成表とは：
主キーを必ず指定しなければならず、B*ツリー索引におけるROW_IDの変わりに
非キー列(実際のデータ)がリーフエントリに格納される。つまり、ROW_IDを持
たない表である。
では、実際に以下の手順で索引構成表を作成し、データを挿入してみよう。
************************************************************
SQL> create table emp_ora (emp_no number, ename varchar2(40),
2 constraint emp_pk primary key (emp_no))
3 organization index
4 tablespace users;
SQL> insert into emp_ora values(1,'chigasaki_meijin');
SQL> commit;
***********************************************************
索引構成表へのデータのインサートがどのように表示されるか見てみよう。
***********************************************************
SQL> select scn, data_obj#, row_id, operation, sql_redo, sql_undo
from v$logmnr_contents
SCN DATA_OBJ# ROW_ID OPERATION SQL_REDO SQL_UNDO
------- ---------- ------------------- ---------- -------------------------- ------
687683 0 AAAAAAAAAAAAAAAAAA START set transaction read write;
687683 26055 AAAAAAAAAAAAAAAAAA INTERNAL
687684 0 AAAAAAAAAAAAAAAAAA COMMIT commit;
***********************************************************
索引構成表自体がROW_IDを持たず、ROW_IDの変わりに直接データを格納してい
るため、当然のようにv$logmnr_contents表のROW_IDにも何も入ってないことが
分かる。また、SQL_REDO列も空白である。
では、v$logmnr_contents表からセグメントの情報も検索してみよう。
***********************************************************
SQL> select scn, data_obj#, seg_name, seg_type_name, table_space from v$logmnr_contents;
SCN DATA_OBJ# SEG_NAME SEG_TYPE_NAME TABLE_SPACE
------- --------------- ---------- --------------- ------------
687683 0
687683 26055 EMP_PK INDEX SYSTEM
687684 0
***********************************************************
上記のようにセグメント名がEMP_PKで、セグメントタイプもINDEXになってい
る。これは索引構成表の segment が index 構造で作成されているためである。
通常セグメントタイプがINDEXのものはログ・マイナーでは表示されないが、
索引構成表では表示されている。
それにしても、なぜTABLESPACEは表領域USRESに作成したにもかかわらず、
TABLE_SPACE列がSYSTEMになっているのであろうか。
では、TABLESPACEに関する情報をもう少し調べてみたい。
どの表領域を使用しているかUSER_INDEXES表から検索してみよう。
***********************************************************
SQL> select table_name, index_name, tablespace_name
2 from user_indexes where table_name = 'EMP_ORA';
TABLE_NAME INDEX_NAME TABLESPACE_NAME
--------------- --------------- ------------------------------
EMP_ORA EMP_PK USERS
***********************************************************
テーブルを作成したときに指定した通りUSERSが検索される。
では、念のためUSER_TABLES表も検索してみよう。
***********************************************************
SQL> select table_name, tablespace_name
2 from user_tables where table_name = 'EMP_ORA';
TABLE_NAME TABLESPACE_NAME
--------------- ------------------------------
EMP_ORA
***********************************************************
TABLESPACE_NAMEが空白で検索されてしまう。
では、USER_EXTENTSを検索してみよう。
***********************************************************
SQL> select tablespace_name, bytes
2 from user_extents where segment_name='EMP_PK';
TABLESPACE_NAME BYTES
--------------- ----------
USERS 131072
***********************************************************
v$logmnr_contentsで表示されるTABLESPACEがなぜSYSTEMと表示されるかは不
明であるが、ログ・マイナー自体が索引構成表の操作をサポートしていないた
めなのかもしれない。
では、次にクラスタをログ・マイナーで見てみよう。
クラスタとは：
2つの表が1つの列(クラスタ・キー)を共有して結合し、同じデータブロックに
格納される。キーが共有されるため使用する記憶領域が少なくてすみ、クラス
タ化している表を結合する場合の処理時間も向上する。
では、クラスタを作成しデータを挿入後v$logmnr_contents表を見てみよう。
***********************************************************
SQL> create cluster emp_cluster (deptno number)
2 tablespace users;
SQL> create table emp_c (deptno number,
2 emp_name varchar2(20))
3 cluster emp_cluster(deptno);
SQL> create table dept_c (deptno number,
2 dept_name varchar2(20))
3 cluster emp_cluster(deptno);
SQL> create index emp_cluster_idx on cluster emp_cluster;
SQL> insert into emp_c values(1,'ichiro');
SQL> insert into dept_c values(1,'sales');
SQL> insert into emp_c values(2,'niro');
SQL> insert into dept_c values(3,'operation');
SQL> commit;
SQL> select scn, row_id, sql_redo from v$logmnr_contents;
SCN ROW_ID SQL_REDO
------- ------------------ --------------------------------
687795 AAAAAAAAAAAAAAAAAA set transaction read write;
687795 AAAGXJAAFAAASBDAAB insert into "UNKNOWN"."Objn:26058"("Col[1]")
values (HEXTORAW('69636869726f'));
687796 AAAGXJAAFAAASBDAAB insert into "UNKNOWN"."Objn:26059"("Col[1]")
values (HEXTORAW('73616c6573'));
687797 AAAGXJAAFAAASBEAAB insert into "UNKNOWN"."Objn:26058"("Col[1]")
values (HEXTORAW('6e69726f'));
687798 AAAGXJAAFAAASBFAAB insert into "UNKNOWN"."Objn:26059"("Col[1]")
values (HEXTORAW('6f7065726174696f6e'));
687800 AAAAAAAAAAAAAAAAAA commit;
***********************************************************
SQL_REDO列のオブジェクト名の変換がされてないのが分かる。
また、クラスタ索引が同じものでは同じデータ・ブロックに行が格納されるため、
ROW_IDが同じであることが分かる。
AAAGXJAAFAAASBDAAB ---- deptno=1
AAAGXJAAFAAASBDAAB ---- deptno=1
AAAGXJAAFAAASBEAAB ---- deptno=2
AAAGXJAAFAAASBFAAB ---- deptno=3
※deptnoはクラスタ索引
ROW_IDが同じであることによって、UNIQUEなクラスタ索引検索を行なった場合
に、ROWIDによるアクセスによって、同じブロックに格納されているクラスタ結
合された2つの表のデータにアクセスが可能であることが分かる。
v$logmnr_contens表とdba_objects表よりオブジェクト番号とオブジェクトが格
納されるセグメントの情報を検索してみよう。
***********************************************************
SQL> select scn, data_obj#, data_objd#, operation from v$logmnr_contents;
SCN DATA_OBJ# DATA_OBJD# OPERATION
------- ---------------- --------------- -----------
687795 0 0 START
687795 26058 26057 INSERT
687796 26059 26057 INSERT
687797 26058 26057 INSERT
687798 26059 26057 INSERT
687800 0 0 COMMIT
SQL> select owner, object_name, object_id, data_object_id, object_type
2 from dba_objects
3 where object_name in ('EMP_CLUSTER','EMP_C','DEPT_C');
OWNER OBJECT_NAME OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE
---------- --------------- ---------- -------------- ------------------
SCOTT DEPT_C 26059 26057 TABLE
SCOTT EMP_C 26058 26057 TABLE
SCOTT EMP_CLUSTER 26057 26057 CLUSTER
***********************************************************
OBJECT_IDはオブジェクトのオブジェクト番号である。
また、DATA_OBJECT_IDはオブジェクトを含むセグメントのオブジェクト番号で
ある違うオブジェクトである2つの表EMP_CとDEPT_Cは領域的には同じセグメン
ト(オブジェクトEMP_CLUSTER)に格納されていることが確認できる。
今回は、索引構成表とクラスタをログ・マイナーで対応していないということ
で取り上げたが、ログ・マイナー以外にも対応していない機能があるので注意
されたい。
以上、秋の海も最高！の茅ヶ崎にて
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 ＱＡについて 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜皆様からのＱＡを受付けております＞
皆様のＱＡにはできるだけ、お答えしたいと思っています。
すべてのＱＡにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非ＱＡをお寄せください。
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 編集者より 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
クリスマスが近いせいもあり、いろんなところで電飾を見かけるんです。家
の近所の木にもいくつか見かけて、綺麗だなぁーと思っていたんです。最近
そんな事を気にしながら歩いていたら、赤い線の光が見えたんです。赤は珍
しいなと思いつつ近づいて行ったら・・・。工事中の囲いの光でした・・。
工事はしていなかったし、人もいなかったし、周りは暗かったしで、近くに
行くまで全然わかりませんでした。一人で歩いてて良かったと、ホッとした
一瞬でしたっ！ by TI
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
登録・解除は以下のURLで行うことができます。
http://www.insight-tec.com/jp/html/ora3/ora3.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＜おら！オラ！Oracle−どっぷり検証生活−＞
発行／編集：株式会社インサイトテクノロジー
http://www.insight-tec.com
マガジンID：0000030093
本メールマガジンに掲載された記事を許可なく転載することを禁じます。
Copyright (c) 1996-2001, Insight Technology, Inc. All rights reserved.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Insight Technology, Inc
Japanese | English