ローカルエクステントマネージメントに関する検証 その9
~ローカルエクステントマネージメントに関する検証 その9 最終回~
ペンネーム ちゃむ
————————————————————————–
8iからの新機能ローカルエクステントマネージメントを以下「LOCAL」と呼ぶ。
従来のデータディクショナリーでエクステントを管理する方法を以下「DICTIONARY」
と呼ぶ。
————————————————————————–
前回は、「LOCAL」上に一時表領域を作成する方法と「LOCAL」に対して操作をする
DBMS_SPACE_ADMIN PACKAGEの一部を紹介した。
今回は、別のDBMS_SPACE_ADMIN PACKAGEについて説明する。
PL/SQLのマニュアルからは、次のようなプロシージャが確認できる。
TABLESPACE_MIGRATE_FROM_LOCAL、TABLESPACE_MIGRATE_TO_LOCALに関しては前回
説明した。今回は、それ以外のものに関して説明する。
上記のURLで確認していただいたであろうか?
「セグメントを破損または有効としてマークし、適切なエラーのリカバリを可能
にします。」
「現在破損としてマークされているセグメントを削除します(領域の再生なし)」
「表領域内のセグメントについて、ビットマップとエクステント マップが同期
していることを検証します。」
上記のように、障害やエラーを連想させることが記述されている。まさに「LOCAL」
に対して、不具合が起きたときに、これらのプロシージャを使用する。
不具合とは、例えば、ビットマップとエクステント マップに違いが生じることがある
ということである。では、具体的に私が遭遇したケースを紹介しよう。
(障害にはいろいろなケースがあると思う。あくまでも、私の遭遇した障害とい
う認識で読んでほしい。)
症状としては、以下のようなものがある。
症状1
user_tablesではTEST100MAN_Lは検索されるのにTEST100MAN_Lを直接検索する
とエラーがでる。
select table_name from user_tables where table_name = 'TEST100MAN_L' TABLE_NAME ------------ TEST100MAN_L SQL> select * from TEST100MAN_L; select * from TEST100MAN_L * エラー行: 1: エラーが発生しました。 ORA-08103: オブジェクトはもう存在しません。
症状2 以下のようにSQLPLUSからDESCコマンドを実行すると固まってしまう。
SQL> DESC test100man_lをすると固まる
<障害の発生方法>
今回は、次のような方法でこの障害を発生させた。(UNIXを使用)
SQLPLUSより100万件のデータをTRUNCATE処理している最中にCTR+で強制終了
<対処方法及びその過程の状態>
次にどのようにして、この障害を解決したのか説明しよう。
DBMS_SPACE_ADMIN PACKAGEを使用するのはいうまでもない。
1.症状1、2より、TEST100MAN_Lが中途半端な状態になっていることがわかるで
あろう。ということで、まずはDROP TABLEを行なう。
SQL> DROP TABLE TEST100MAN_L;
(私の検証では、この1のステップをとばしてしまうと、2以降の処理を行なっても、
エラーになったり、正常に動作しなかったりした。)
2.このときのDBA_FREE_SPACEの状態を見てみよう。実は100万件のTEST100MAN_L
がDROPしたのにもかかわらず、フリーブロックとして認識されていない。
SELECT TABLESPACE_NAME, BLOCK_ID,BYTES, BLOCKS FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='TESTL'; TABLESPACE_NAME BLOCK_ID BYTES BLOCKS --------------------------------------------- TESTL 25025 7536640 3680 TESTL 33 46071808 22496
3. ここで、DBMS_SPACE_ADMIN PACKAGEの登場である。
(プロシージャの引数などはPL/SQLマニュアル参照)
SELECT SEGMENT_NAME ,RELATIVE_FNO,HEADER_BLOCK FROM DBA_SEGMENTS WHERE TABLESPACE_NAME ='TESTL'; SEGMENT_NAME RELATIVE_FNO HEADER_BLOCK ---------------------------------------- TEST10MAN_L 17 33 17.35 17 35
このSEGMENT_NAMEが(17.35)のものが問題のセグメントだ。
(TEST10MAN_LとTEST100MAN_Lは別のテーブルなので注意 TEST100MAN_Lが問題
のテーブル)
4.破損セグメントとしてマークする。
EXECUTE DBMS_SPACE_ADMIN.SEGMENT_CORRUPT('TESTL',17,35,3);
(引数は4つ TABLESPACE_NAME,RELATIVE_FNO,HEADER_BLOCK及びOPTIONを指定)
(OPTION=3は、破損としてマーク OPTION=4は、有効としてマーク 今回はOPTION=3)
5.破損セグメントとしてマークしたセグメントを削除する。
EXECUTE DBMS_SPACE_ADMIN.SEGMENT_DROP_CORRUPT('TESTL', 17, 35);
(引数は4つ TABLESPACE_NAME,RELATIVE_FNO及びHEADER_BLOCK)
SELECT SEGMENT_NAME ,RELATIVE_FNO,HEADER_BLOCK FROM DBA_SEGMENTS WHERE TABLESPACE_NAME ='TESTL'; SEGMENT_NAME RELATIVE_FNO HEADER_BLOCK ---------------------------------------- TEST10MAN_L 17 33
ここで、問題のセグメントは削除された。しかし、空領域としてまだ認識されない。
6.ビットマップを再作成する。この現象は、そもそもビットマップとエクステント
マップが同期していないために起きている問題である。だから、問題のブロックを
削除した後に、次の処理をする必要がある。
EXECUTE DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_BITMAPS('TESTL');
ここで、フリーブロックを検索してみると...
SELECT TABLESPACE_NAME, BLOCK_ID,BYTES, BLOCKS FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='TESTL'; TABLESPACE_NAME BLOCK_ID BYTES BLOCKS ------------------------------------------- TESTL 35 58716160 28670 TESTL 33 46071808 22496
おー、ちゃんとTEST100MAN_Lで確保した分、解放されてフリーブロックとして
認識された。あー大変だった。
最後に
ローカルエクステントマネージメントは個人的な見解としては、以下のような
メリットがあるから積極的に使って良い思う。
1.パフォーマンスの向上(リカーシブ コールの減少 ビットマップを用いた
高速なエクステントのアルゴリズム)
2.競合を防ぐ(STエンキュー・コアレスなどの話)
ただし、今回のケースのように、障害があった場合は、ある程度、DBMS_SPACE_
ADMIN PACKAGEは使いこなして解決しなければならないのがデメリットであろうか。
(めったに起こらないとは思うけど)
最後の最後に
ローカルエクステントマネージメントの正式名は
「LOCALLY MANAGED TABLESPACES」らしい。なんかぜんぜん違う。今までごめんね。
今回でローカルエクステントマネージメントの話はおしまい。
来週から何にしようか、考え中。
12月14日(木)、15日(金)に開催されるORACLE OPEN WORLD(東京ドーム)へ
の出展が決まりました。当日は、おら!オラ!Oracleの号外版
「Oracleの知恵袋(仮名)」を無料で配布する予定です。この冊子の中には、
Oracle技術者にとって役立つ情報がぎっしりつまっています。数に限りがござ
いますので、是非この機会をお見逃しないように!また、当日は、
おら!オラ!Oracleの応援にビッグなゲストが登場します。ご期待下さい!!
ヒント → 「なんですかーそれはっ!!」
以上 先週、桑田圭介がユースケサンタマリアと札幌軒(ラーメン屋)に一緒
にきた茅ヶ崎にて