パフォチュー日記&QA１ - InsightTechnology 旧ブログ

～読者からの「質mon」に関する検証～

前回に続きまして、読者の方々のご質問にお答えしていきたいと思います。
今回は久々のつけまいと、ちゃむが皆様の疑問にお答えします。

＜読者からの質問　その１＞

REDOログのI/Oを少なくするよう配慮することが、Oracleパフォーマンスで重要
なようですが、実場面では以下のような疑問点があります。

(1) REDOログは少容量のファイルだと思います。でも物理ディスクはどんどん
　　大規模化されており、REDOログ専用の物理ディスクを設けるのは難しいよ
　　うな気がしますが、他社事例では、REDOログはディスクの使用率を無視し
　　てでも専用ディスク割り当てにするケースが多いのでしょうか？
　　また、現在のディスク装置の性能から、そこまでI/Oに注意する必要がある
　　のでしょうか？実測値等の比較データがあれば教えてください。

(2) ディスク装置にはハードキャッシュが搭載されていますが、このキャッシュ
　　はI/O削減で活用すべきなのでしょうか？このキャッシュを活用すれば今回
　　のメール例のようにREDOログへのI/Oのことは気にする必要はないのでしょ
　　うか？

＜つけまい＞

まずは、(1)からお答えいたします。この場合、一概には言えません。ただ、REDO
の特性を考慮した上で、パフォーマンスを最優先させるために独立したディス
クに配置しているユーザは少なくありません。20Gのディスクに、500MのREDO
ログ・ファイルしか置いていないユーザもいるくらいです。
また、他のファイルと同居させる際は、ソースファイルの退避場所として扱う
など、アクセス頻度の低いものを配置するよう考慮する必要があります。

なお、残念ながら比較データはございませんが、ひっきりなしに書き込みが行
われていることを考えれば、リソースを無駄にしてでも、独立したディスクへ
配置することは、決して間違いではありません。
ただ、おっしゃる通り、現在のディスク性能を考えれば、必ずしも独立したデ
ィスクに配置しなくても、EMC社製のディスクなど、大量のハードキャッシュ
を内在し、ディスクがキャッシュ書き込みでWrite保障をするような場合など
は若干のメリットも考えられます。ただし、そのような場合でも返って高くつ
いてしまうので、繰り返しになりますが、REDOには独立型ディスクを割り当て
るという考え方が重要です。この部分に関しては、ディスクの性能に依存する
とお考え下さい。

ここで最も重要なのは、シークオーバヘッドを最小限に抑えるということです。
通常のデータファイル等と大きく違うのは、シーケンシャルライトのみのREDO
のアクセス効率は、シークが頻繁に起こらないようにディスクヘッドを固定さ
せることに意味があり、この点が通常のデータファイルのようにランダムリー
ドライト処理によるシークが頻繁に行われることが前提のI/Oと大きく違う点で
す。ですから、RAID０や５のようにランダムI/Oにメリットのあるディスクとは
考え方に大きな違いがあるのです。
また、LGWRのみから書き込みが行われる点も、RAID0や５のようなストライピン
グ能力重視の考え方とは変わってきます。もう一つ重要なこととして、ディス
クのキャッシュ性能に付いて挙げられます。REDOログへの書き込みは、キャッ
シュしないライトであるO_SYNC　Writeを使用しています。
キャッシュに書き込んだ時点でOKとしてしまえば、完全なリカバリが保障でき
なくなってしまうからです。ただし、この考え方はRAW　Deviceを使った場合に
はOSのファイルシステムのキャッシュを使用しない為当てはまりません。

続いて(2)にお答えいたします。キャッシュの役割から考えれば、その通りだと
思います。ただし、このことにつきましても、実測データが存在しないので、
断言することはできません。本メルマガは、検証結果に基づき、事実をお伝え
するものです。機会がありましたら、是非、トライしてみたいと思います。
繰り返しになってしまいますが、O_SYNC Writeを使用しているためREDOには、
この考え方は当てはまりません。

＜読者からの質問　その２＞

今回テンポラリテーブルスペースについてお尋ねしたいのですが、どうもごみ
みたいのが残っており（930MB）、アプリケーションがこけました。errorは
“temp領域のextentがとれませんでした。”と出力されていました。なお、前日
までは70MBぐらいしか使用してませんでした。スキーマーで確認してもSYSしか
使用しておりません。oracle本体を再起動してテンポラリテーブルスペースの
中身がclearされるのを期待したいのですが。一時的にテンポラリテーブルス
ペースを拡張してその場はしのいでおりますが、もしテンポラリテーブルスペ
ースの中身を削除できるコマンドはあるのでしょうか。またこういった現象は
あるのでしょうか？
ちなみにバージョンはoracle8.0.5.2.1です。

＜ちゃむ＞

お答えいたします。temp領域は、専用一時表領域と一時表領域つまり、
temporary属性の表領域とpermanent属性の表領域が2種類ありますが、そのど
ちらであれ、oracle本体を再起動した時点でクリアされてないといけません。

この辺のことは是非、メルマガの～ソートに関する検証　その４～
をご参照下さい。

ただ、ごみと言っている部分を、もう少し調査した方が良いかもしれません。
メルマガの～ソートに関する検証　その４～では以下のようなSQL文を発行し
ていますが、本当にソートで使用されているなら、SEGMENT_NAMEが10.2のよう
に数字になっているはずです。ここで、普通のオブジェクト名がついているの
なら、これは、ごみではなくオブジェクトが残っているということになります。

select SEGMENT_NAME,SEGMENT_TYPE,BLOCKS,HEADER_FILE,HEADER_BLOCK from
dba_segments where tablespace_name = 'TEMP';

SEGMENT_NAME    SEGMENT_TYPE          BLOCKS HEADER_FILE HEADER_BLOCK
--------------- ------------------ --------- ----------- ------------
10.2            TEMPORARY               5800          10            2

もし、ほんとに上記のようなSEGMENT_NAMEが検索されていて、oracle本体を再
起動した時点でクリアされないなら、ORACLEのバグの可能性がありますので、
オラクルのサポートに問い合わせることをお勧めいたします。

┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【パフォチュー・コンサル日記】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
第１回　ディスク装置の認識

データベースへのアクセスが過度なシステムではディスク装置自身がチューニ
ングのキーとなります。ディスク性能が十分に引き出せる環境を作り、ディス
クＩ／Ｏ待ちを最小限にするためにお客様に説明するポイントが「ディスク転
送スピード」です。

・ディスク転送スピードとは？

Oracleはデータベースバッファを使用して再利用性の高いデータをメモリ上で
処理してしまおうという「キャッシュ・メカニズム」を採用しています。毎回
ディスクから読み込んでくるより、メモリ上のデータブロックをアクセスした
ほうがはるかに高速なのです。

どのくらい高速化というと：

メモリのアクセス時間単位 = ナノセコンド (ns) = 10 の -9 乗
ディスクのアクセス単位 = ミリセコンド (ms) = 10 の -3 乗

この差は10 の 6 乗、すなわち100万倍の違いがあるということです。そこで
Oracleではデータベースバッファがあるのです。また、同じような理由からデ
ィスク・キャッシュが実装されたハードディスクが出回っています。しかし、
大量のデータ・ローディングなどでディスク・キャッシュがあふれてしまうよ
うな事になればディスクへの「転送スピード」が処理時間を大きく左右してし
まいます。
（でも、ギガ・キャッシュを積んだ高価なディスクは少し別格だけど）

・ディスク転送量を上げるためのＲＡＩＤディスクとは？

ＯＬＴＰ環境では同時に発生するディスクＩ／Ｏで待ちが起こらないように複
数の「物理ディスク」に書き込みを分散するＲＡＩＤディスク装置を導入する
のが一般的です。またバッチ処理で使用されるParallel Queryなども複数のＣ
ＰＵで同一テーブルを検索するためにＲＡＩＤによるＩ／Ｏ分散が必須です。

ＲＡＩＤとは：
Redundant Array of In-expensive Disksの略で1987年、米カリフォルニア大学
バークレーでの論文が起源となっています。
複数のハードディスクを接続してデータのＩ／Ｏ待ちを減らし、転送量を引き
出すための装置構成の事です。また、障害に強い構成とも言えます。なんたっ
てコンピュータ障害の内、群を抜いて多いのがディスク・クラッシュなのです！

・Oracleのサポートで使われるＲＡＩＤは？

以下の３種類です：

(A) ＲＡＩＤ０＋１（１＋０） ストライピング＋ミラーリング
(B) ＲＡＩＤ５               ストライピング（分散パリティ・ディスク方式）
(C) ＲＡＩＤ４               ストライピング（専用パリティ・ディスク方式）

・最強なのは？

一般的には（Ａ）と言って良いでしょう。ただし！！！ここで間違えやすいの
が物理ディスクの数です。私たち流に言うと「ディスクのタマの数」です。
ディスク・タマが４個しかないのに（Ａ）はあり得てはいけないのです。タマ
が４個だと２つのストライピングしかできなくなってしまいます。そんな場合
（タマの数がそれほど多くない場合）はＲＡＩＤ５を選択します。

・ハードウェアＲＡＩＤが（Ａ）しかサポートしていないからタマが４個でも
しかたない？

それも頷けます！だけど、高価なＲＡＩＤ装置を購入させてタマ４個の実装を
提案したベンダーに問題あるのかもしれません？？？
少なくとも４個以上のＣＰＵを実装したＳＭＰマシンで、ＲＡＩＤ装置を購入
したのならタマの数は必ずチェックしてください。多くのディスクにＩ／Ｏを
分散させるストライピングがスピードのカギです。

・パリティ情報からデータを保護する（Ｂ）（Ｃ）

パリティ情報とは排他的論理和（ＸＯＲ）で作成される情報です。排他的論理
和は２進数の論理演算の一つで、以下の４つのパターンがあります：

０＋０＝０、０＋１＝１、１＋０＝１、１＋１＝０

このパリティ情報を同時に記録する事により１台のディスク装置がクラッシュ
した場合でもデータを失う事が防げます。

例えば、３台のディスクで（実際は３台なんてストライピング度が低いのでお
勧めではありませんが）：

1台目のドライブ：0xFF
2台目のドライブ：0x77
3台目のドライブ：0x33

パリティは　0xFF XOR 077F XOR 0x33 = 0xBBとなります。もし、3台目のタマ
が故障しても、パリティをもとにXORで3台目のタマの値=0xFF XOR 0x77 XOR 0xBB = 0x33
で対応します。
このパリティ情報をそれぞれのタマに分散して持つのがＲＡＩＤ５（Ｂ）です。
対してＲＡＩＤ４（Ｃ）はパリティ情報専用のタマを実装しています。（Ｃ）
はパリティ情報専用ディスクにＩ／Ｏが集中してしまいボトルネックの要因と
なるため、今までは製品化されてこなかったのですが、ギガ・キャッシュ付き
装置とともに実装した製品が現れはじめました。

次号に続く、
茅ケ崎　フィッシャーマン