┏┏┏┏┏━━━━━━━━━━━━━━━━━━━━━━━━…・・ ┏━
┏┏┏┏┛ 2001.11.21 ┏┛┛
┏┏┏┛ ☆おら！オラ！Oracle -どっぷり検証生活-★ ┏┛┛┛
┏┏┛ ┏┛┛┛┛
┏┛・・…━━━━━━━━━━━━━━━━Vol.82━…・・ ┏┛┛┛┛┛
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ Oracle技術セミナー追加開催！ ◆
◇ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ◇
●≫≫≫≫≫≫≫≫≫≫ 最後のご案内です ！！≪≪≪≪≪≪≪≪≪≪≪●
◇ ご要望にお応えして「パフォーマンス悪化のケーススタディ」を ◇
◆ 株式会社システムコンサルタント主催の特別セミナー ◆
◇ において開催することが決定いたしました。 ◇
◆ 詳細とご登録は下記のURLから。 ◆
http://www.insight-tec.com/jp/html/topics/semi_information.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
■□注意事項□■
本文中にテーブルが含まれていますので、お読みになる際はMSゴシッ
ク等、等幅フォントをお使いただくことをお勧めします。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 Oracle 検証生活 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜ ログマイナに関する検証 その参 ＞ ペンネーム チョビひげ
--- ログ・マイナーで連鎖行を見る ---
ログ・マイナーでドロップしてしまったテーブルを復旧する前に注意しなけれ
ばいけないことは以下の操作対象をログ・マイナーがサポートしていないこと
である。(Oracle8i)
・連鎖行
・索引構成表
・クラスタ化表／索引
・非スカラー型
・ダイレクト・パス・インサート
・DDL文
では、ログ・マイナーを実行したときに連鎖行はどのように表示されるのか検
証してみよう。
行連鎖は行を挿入する際に、その行のデータが大きすぎて一つのブロック内に
収まらない場合に発生する。では実際に行連鎖を発生させ、どのようにログ・
マイナーで見られるのであろうか。
1.テーブル(DOCUMENT)に以下の1件のレコード(DOCUMENT_DATAに2458Byte)を挿入
*******************************************************
SQL> desc document;
Name Null? Type
--------------------------------------- -------- ---------------------
DOCUMENT_ID NUMBER
DOCUMENT_DATA VARCHAR2(4000)
SQL> insert into document values(1,'[n*2458]');
※[n*2458]はnが2458文字をあらわしてる
*******************************************************
以下の手順で実際に行連鎖されているか確認してみよう。
*******************************************************
# CHAINED_ROWS表を作成する為、UTLCHAIN.SQLを実行する
SQL> @utlchain.sql
Table created.
# ANALYZEコマンドをLIST CHAINED ROWSオプションで実行
SQL> analyze table document list chained rows;
Table analyzed.
# 上記のコマンドでCHAINE_ROWS表にデータが格納される
# 格納された行連鎖を検索
SQL> select table_name, head_rowid from chained_rows;
TABLE_NAME HEAD_ROWID
------------------------------ ------------------
DOCUMENT AAAGW4AAFAAAR+JAAA
********************************************************
AAAGW4AAFAAAR+JAAAが行連鎖していることが分かる。
上記の連鎖行のINSERT文に対するREDOレコードを見てみよう。
********************************************************
SQL> select scn, row_id, data_obj#, operation, sql_redo,
sql_undo from v$logmnr_contents;
SCN ROW_ID DATA_OBJ# OPERATION SQL_REDO SQL_UNDO
------- -------------------- ---------- ---------- ------------------------ ---------
687539 AAAAAAAAAAAAAAAAAA 0 INTERNAL
687539 AAAAAAAAAAAAAAAAAA 0 INTERNAL
687539 AAAAAAAAAAAAAAAAAA 0 START set transaction read write;
687539 AAAGW4AAFAAAR+IAAA 26040 INTERNAL
687539 AAAAAAAAAAAAAAAAAA 0 INTERNAL
687539 AAAGW4AAFAAAR+JAAA 26040 INTERNAL
687541 AAAAAAAAAAAAAAAAAA 0 COMMIT commit;
********************************************************
上記のようにSQL_REDO列、SQL_UNDO列と共に空白になっている事がわかる。
また、ROW_IDは以下の2つのレコードが見られる。
・AAAGW4AAFAAAR+JAAA
・AAAGW4AAFAAAR+IAAA
1つのROW_ID(AAAGW4AAFAAAR+JAAA)が先程検索した行連鎖を起こしているROW_ID
と一致している。
また、ROW_ID(AAAGW4AAFAAAR+IAAA)に行連鎖していることが想像できる。
では、行移行の場合はどうなっているのか見てみたい。
まずはテーブルを作成し、1600バイトのデータを挿入し、
その後、1行のデータのUPDATEを行い、行移行を発生さる。
********************************************************
# テーブルからすべてのデータを削除
SQL> truncate table document;
Table truncated.
# 2バイトの行データを800件挿入(document_id列は1〜800で一意)
SQL> begin
2 for i in 1 .. 800 loop
3 insert into document values(i,'n');
4 end loop;
5 end;
6 /
# document_id=2 の行のROW_IDを取得
SQL> select rowid from document where document_id=2;
ROWID
------------------
AAAGYRAAFAAAR+DAAB
# document_id=2 の行のデータを1001バイトのデータにUPDATE
SQL> update document set document_data = '[n*1000]' where document_id=2;
※[n*1000]はnが1000文字をあらわしてる
# 行連鎖と同じ手順で行移行を確認
SQL> select table_name, head_rowid from chained_rows;
TABLE_NAME HEAD_ROWID
------------------------------ ------------------
DOCUMENT AAAGYRAAFAAAR+DAAB
# v$logmnr_contents表を検索
SQL> select scn, seg_name, row_id, operation, sql_redo from v$logmnr_contents;
SCN SEG_NAME ROW_ID OPERATION SQL_REDO
-------- --------- ------------------- ---------- ----------------------
799084 AAAAAAAAAAAAAAAAAA START set transaction read write;
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 AAAAAAAAAAAAAAAAAA INTERNAL
799084 DOCUMENT AAAGYRAAFAAAR+IAAA INSERT
799084 DOCUMENT AAAGYRAAFAAAR+DAAB DELETE Unsupported (Chained Row)
799086 AAAAAAAAAAAAAAAAAA COMMIT commit;
********************************************************
結果を見るとDELETEの操作で、先程検索したdocument_idが2のデータのROW_ID
を削除しているのが分かる。また親切(？)にもサポートがされてないメッセー
ジもSQL_REDO列に表示されている。またOPERATION列がINSERTの行を見ると、
行の移行先のROW_IDにインサート処理を行なっている事が確認できる。
また、v$logmnr_contents表よりデータが含まれるデータファイルおよびブロッ
ク番号も確認できる。
では、ブロック番号を指定して行移行しているブロックのダンプを見てみよう。
********************************************************
SQL> select scn, row_id, operation, abs_file#,
data_blk# from v$logmnr_contents;
SCN ROW_ID OPERATION ABS_FILE# DATA_BLK#
------- ------------------ ------------ ----------- -----------------
799083 AAAAAAAAAAAAAAAAAA COMMIT 3 0
799084 AAAAAAAAAAAAAAAAAA START 0 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 73603
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAAAAAAAAAAAAAAAA INTERNAL 5 0
799084 AAAGYRAAFAAAR+IAAA INSERT 5 73608
799084 AAAGYRAAFAAAR+DAAB DELETE 5 73603
799086 AAAAAAAAAAAAAAAAAA COMMIT 3 0
# 行移行元のブロックダンプを作成
SQL> alter system dump datafile 5 block 73603;
# 結果
--- < 略 > ---
Block header dump: 0x01411f83
--- < 略 > ---
block_row_dump:
tab 0, row 0, @0x7b0
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 2] c1 02
col 1: [ 1] 6e
tab 0, row 1, @0x273
tl: 9 fb: --H----- lb: 0x1 cc: 0
nrid: 0x01411f88.0
tab 0, row 2, @0x7a0
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [ 2] c1 04
col 1: [ 1] 6e
--- < 略 > ---
********************************************************
ブロック・ヘッダー(Block header dump)を見てみると0x01411f83になっている。
また、ブロックの1行目(row 1)では列のデータが入っておらず、
nridが0x01411f88.0になっているのが分かる。
これはブロック・ヘッダーが0x01411f88の0行目(row 0)に移行していることを
指している。
では、行移行先のブロックダンプを見てみよう。
********************************************************
# 行移行先のブロックダンプを作成
SQL> alter system dump datafile 5 block 73608;
# 結果
--- < 略 > ---
Block header dump: 0x01411f88
--- < 略 > ---
block_row_dump:
tab 0, row 0, @0x3c2
tl: 1014 fb: ----FL-- lb: 0x1 cc: 2
hrid: 0x01411f83.1
col 0: [ 2] c1 03
col 1: [999]
6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e
6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e 6e
--- < 略 > ---
********************************************************
ブロックヘッダーは0x01411f88である。
ブロックの0行目(row 0)でhridが0x01411f83.1になっているのが分かる。
これはブロック・ヘッダーが0x01411f83の1行目(row 1)から移行されているこ
とを指している。
1行のデータを得るために2ブロックにアクセスする必要があるため、
パフォーマンスに悪影響を与えることがあらためて実感できる。
次回はログ・マイナーで索引構成表をみて見てみたい。
以上、サーフィン始めよう！の茅ヶ崎にて
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 Ｑ＆Ａ 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜Ｑ：読者からのご質問＞
昔（７．３の時代）から気になっていたのですが、ファンクションやプロシー
ジャは、そのソースをdba_sourceから簡単にSQL*Plus等で引き出せるのですが、
トリガーは引き出せそうで引き出せないんです。
ObjectBrowserとかでは出るのに・・・
＜Ａ：ちゃむ＞
そのとおりです。
トリガーのある環境でも以下の通りですよね。
（タイプがトリガーのものが検索されない。）
SQL> SELECT DISTINCT TYPE FROM DBA_SOURCE;
TYPE
------------
FUNCTION
PACKAGE
PACKAGE BODY
PROCEDURE
TYPE
＜Ｑ：読者からのご質問 続き＞
ObjectBrowserとかでは出るのに・・・
ちなみに8iDBA Studioでも出るような表示になっているのに出ません！それら
しいSQL文も無いような感じです。
all_trigers.trigger_bodyが怪しそうなんですが・・・
＜Ａ：ちゃむ＞
こちらもこの通りです！！
all_triggersでもuser_triggersでも構いませんので、以下では、user_triggers
でご説明いたします。
SQL> desc user_triggers
名前 NULL? 型
------------------------------ --------------------
TRIGGER_NAME VARCHAR2(30)
TRIGGER_TYPE VARCHAR2(16)
TRIGGERING_EVENT VARCHAR2(216)
TABLE_OWNER VARCHAR2(30)
BASE_OBJECT_TYPE VARCHAR2(16)
TABLE_NAME VARCHAR2(30)
COLUMN_NAME VARCHAR2(4000)
REFERENCING_NAMES VARCHAR2(128)
WHEN_CLAUSE VARCHAR2(4000)
STATUS VARCHAR2(8)
DESCRIPTION VARCHAR2(4000)
ACTION_TYPE VARCHAR2(11)
TRIGGER_BODY LONG
但し、注意点といたしましては、TRIGGER_BODY列は、LONG型なので、SQL*plus
を使用する場合は、以下のように大きい値を指定した方がよいでしょう。
SQL> SET LONG 10000
以下が簡単な出力例です。
TRIGGER_NAME
------------------------------
TRIGGER_BODY
------------------------------
AAAAAAA
begin
if (:new.COL2 is not null)
then
insert into BBBBBBBBB (COL1)
values('TEST');
end if;
end;
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 セミナー情報 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜パフォーマンス悪化のケーススタディ＞
Oracleデータベース・チューニングの方法論を明確にするために、チュ
ーニングポイントとなるシステムアーキテクチャの解説、さらに6つの
ケースを題材としてチューニングの基礎を徹底的に解説します。また
、当日はPerformance Insight 4 for Oracle 最新リリースの機能デモ
ンストレーションも行います。
●講師から
実は数年前に同じタイトルでセミナーを開き延べ約500名の方々にお話
をさせていただきました。予想を上回る人数に少々躊躇しておりました
が、お客様から”もう一度やって欲しい”というご意見をいただき、新
たな題材を集めております。役に立つ情報を満載したセミナーにするた
めにも、出席者の方々が抱えておりますご質問やお悩みなどの「議論の場」
となるような「会」になることを願っております。当日は、私（小幡）の他、
弊社コンサルタントも配備させますので、気兼ねなくお声を掛けてください。
題名 Oracleユーザーのための先進のパフォーマンス・運用管理ツール
「Performance Insight for Oracle」による特別セミナー
対象 Oracle DBA
日時 2001年 11月 22日（木）14：00〜17：00
会場 日本オラクル株式会社 本社 12Fセミナールーム
定員 120名 (定員に達し次第募集を締め切らせていただきます)
主催 株式会社システムコンサルタント
地図 日本オラクル株式会社 本社 12Fセミナールーム
http://www.oracle.co.jp/corp/office/
ご登録は下記のURLから
http://www.insight-tec.com/jp/html/topics/semi_information.html
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 ＱＡについて 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
＜皆様からのＱＡを受付けております＞
皆様のＱＡにはできるだけ、お答えしたいと思っています。
すべてのＱＡにお答えすることはできないかもしれませんが、
適宜メルマガ内でとりあげていく予定ですので、是非ＱＡをお寄せください。
┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 編集者より 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
ついこの間、病院に行って来たんです。呼ばれて診察室に入り、イスに座っ
ていたら・・。視界にやたら気になるものがあり、横を向いたら水槽にカメ
が３匹！！朝からレタスをガツガツ食べていたんですっっ！！先生に声をか
けられるまで、カメに見とれていました・・。おかげで、会社に来てからも
自然とカメの話題・・。しばらくは、カメで頭がいっぱいになりそうですぅ。
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