その4前回に引き続き、QAシリーズ第4回目です。投稿してくださった方々、有難うございます。当メルマガの書籍をお送りいたします。一時表、ロールバックセグメント(Raid0)上記に加えてOLTPの場合、一時表の物理位置は別でも良いと思います。DSSの場合、テーブルとインデックスは同一のエリアでも良いと思います。上記の解答がどうであるかもさることながら、上記解答の場合、最低でも物理ディスクが33個(ストライプされたディスクは3個と仮定)必要です。以下は解答例(1)を筆者が勝手に(解答をいただいた方になりきって)補足しました。(解答を頂いた方の意図が変ってしまっていたらゴメンナサイ):パフォーマンスを前提に考えると、アーカイブ運用に対する考慮を抜かして考えてもざっと33個必要になるという概算です。non-uniqueなインデックスの場合DBキャッシュ上に存在するリーフブロックで条件に一致したデータ分(2)を繰り返す。上記(1)~(3)の繰り返しを同じ物理ディスクで行うとデータファイルのシークが余計なオーバヘッドとなります。したがって、最低でも33個必要となるのです。I/Oの機能をフルに発揮するため・パラレル・クエリで各slave間でI/O待ちを起こさないためストライピング数が3というのであれば(1)を考慮すると、実装CPU数が3個である!ということになりますが、折角ストライピングするんだから最低3個はないと意味がない。・ルール3:システム表領域は同時アクセスは多いが、DBキャッシュ上に載っている本番運用中のシステム表領域の「同時更新」は多くない。したがって、ストライピング対象から外す事ができる。A.自ら加筆しておいて答えを書くのは気が引けます。実は頂いた解答の最後は「33個が多すぎる場合、どういう順序でトレードオフを検討すればよいのか?」という質問で結ばれています。一時表、ロールバックセグメントもミラーリングする必要があるので+3個されて最低でも36個必要という事になってしまいます。同時トランザクションが少なくないサイトで、SMPなどの複数CPUを搭載したマシンでDBを構築すると最低でも36個のディスクを実装しないとパフォーマンスを考慮した環境を構築できない!という意見は間違ったものではありません。それに、アーカイブ運用するのであれば、+2個も考えなければならないかもしれません。Raid0+1は厳密にRaid1+0と区別して記載しておりません。一般的にはRaid1+0でミラー&ストライプを適用します。参照表は小さいものから大きなものまで多数ある上記(1)~(7)は、事実表、参照表に対する「一般的」な見解です。条件はアプリケーションにより様々であることは認識しているのですが、ある程度一般的にしないと話が進みそうもないのでご了承ください。参照表、参照表インデックス、およびシステム表は同時更新に対する考慮が必要ない。したがって、同一の論理ボリューム入れる候補となりやすい→ルール1が適応されない(*3)(*3)ディスクアクセスでReadとWriteを比べるとWriteの方が重い。多少のReadのI/O待ちを許容する。ロールバックセグメントはReadと比べて負荷の高いWriteが多く、同時アクセスも多いので、ストライピング対象とする。上記(a)~(d)をルール2に当てはめると、4x3x2=24個のディスクが必要となる。REDOと制御ファイル、およびアーカイブファイルを考慮すると、+6個(前回のメルマガ)必要となります。解答例(1)ではREDOと制御ファイルを同居させていますので+4個で合計28個、それにOSの分で30個が合計数となり、38個から比べると8個減らせた事になります。当然ですが、もっと減らしたい。ストライピング数を減らせば、I/O待ちがパフォーマンスに影響します。どのくらい影響度があるかは、実装されるメモリとDBキャッシュの割り当て可能量に左右されます。上記(e),(f)をルール2に当てはめると、2x3x2=12個とそれ以外で18個が必要です。この場合、システムをモニタリングしてみると事実表インデックスのI/O待ちが発生しています!などというのが検出され、Au-DBit的に言うと(手前味噌ですが):重要度3:「ディスクI/O待ちがパフォーマンスに影響しています。」という警告が報告されます。それでも18個も有るんです。全て3個のRAID1+0で合計6個そうすれば、その他と合わせて合計12個Au-DBit的メッセージでは:重要度2:「ディスクI/O待ちがパフォーマンスに大きく影響しています。」という1ランク上の警告になります。A.その通り!でも、そのヒット率を上げるために「メモリを1GB追加しました!」なんて聞くと疑問に思います。メモリの値段が安くなったので1GBぐらいは大した事ないのですが、それでも大型機になるとウン百万円もします。あるエピソード:あるお客様でデータベースバッファを3GBに設定していました。実メモリも3GB以上実装していて、メモリは十分足りています。データベースバッファのヒット率は97%強を常に維持しています。そのお客様では、日中のOLTP処理はのレスポンスよりも夜間のデータ再構築処理のスループットが問題になっています。ディスクはというと、、、物理ディスク3個でRAID-5です...。アンバランスですよね!しかも、実装したメモリの金額よりもディスクの金額の方が断然安い!。OLTP処理メインの話から脱線するので、ここで止めますが、このお客様では数本のディスク追加とRAID-1+0の移行で、今まで4時間以上かかっていた処理を1時間以下に減らす事がでました。6.投稿【解答例(3)】1つ疑問に思いましたので、なんらかの回答をいただければ幸いです。コントロールファイルのミラーリングについてです。立した専用のディスクを2本も用意するのは冗長ではないでしょうか?コントロールファイルはI/Oも少なく、小さなファイルです。他のファイルが存在するディスクに間借りするだけで十分と思えるのですが。ミラーリングされ、異なるディスクが用意されているアーカイブログファイルと共存でも良いのかと思います。A.コントロールファイルはI/Oの少ないファイルでは有りません。CKPTプロセスは3秒に1回スリープから目覚めてコントロールファイルにアクセスします。heartbeatと呼びます(v$event_nameでみてください)。そこで、SCNが更新されていると、すなわち更新処理が発生しているとコントロールファイルに書き込みを行います。1.5014E+10(*)上記のリストでSID=4はCKPTプロセスです。→「アーカイブログファイルと共存でも良いのかと思います」という部分には賛成です。コントロールファイルの書きこみ待ちは許容できる時間内であることが多いからです。オンラインREDOと同居はあまりお勧めしません。無駄なseekの連続とreadより負荷の高いwrite処理を大量に重複させる事はデータ保護の観点からも良くないからです。以上、まだまだ続きます。reserved.トップページ企業概要プライバシーポリシ。