最近のトラックバック

最近のコメント

2017年3月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
無料ブログはココログ

« バッファ・キャッシュ関連のラッチ(Latch) | トップページ | ダイレクト・ロード・インサート »

2008年5月27日 (火)

NOLOGGING属性(ロギング属性)

使い始めのときはちょい心配しましたが、たとえばテーブルを作成するときにNOLOGGING属性を指定したとして、
・NOLOGGINGを指定したCREATE TABLEの処理自体はロギングされない(正確には最低限のログのみ書かれる)
・NOLOGGING属性を指定したテーブルに対して、通常のupdate/insertを行った場合、普通どおりロギングされる(REDOログは普通どおり発生する)
・ただし、NOLOGGING属性を指定して作成されたテーブルは、メディアリカバリを行うために必要なログ情報を(たとえCREATE以後のDMLに対してはロギングしていても、一番最初のCREATE処理については)記録していないので、データファイルを戻して復旧するようなケースの場合、エラーとなる
 →ただし、エラーになるのはこのテーブルのみ。他のテーブルは復旧できる
・NOLOGGING属性を指定したテーブルに、ダイレクト・ロード・インサートを実行した場合、そのインサート処理はロギングされない(正確には最低限のREDOログのみ発生する)
 →LOGGING属性だと、普通にREDOが発生する。利点はバッファをバイパスするってことだけとなる
・INDEXに対するNOLOGGING指定は、INDEXに対するDDL文において有効となる。ある表に対してダイレクト・ロードインサート等が実行され、その表に設定されているINDEXがNOLOGGING指定であっても、INDEX操作に関するREDOは生成されるそうな

なので、NOLOGGING属性を指定する場合は、読み取り専用テーブルとか、一日一回バッチでデータがイチから再作成されるようなテーブルとかに限定するのが妥当だと思います。

« バッファ・キャッシュ関連のラッチ(Latch) | トップページ | ダイレクト・ロード・インサート »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/181317/41341806

この記事へのトラックバック一覧です: NOLOGGING属性(ロギング属性):

« バッファ・キャッシュ関連のラッチ(Latch) | トップページ | ダイレクト・ロード・インサート »