その3今年最初のメルマガです。QAシリーズ第3回目です。1.Oracleによるミラーリング機能があるファイルは:(1)オンラインREDOログ(2)アーカイブログ(3)コントロールファイルの3つです。・上記(3)のコントロールファイルはOracleによるミラーリングがされている場合が多いのですが、同じ物理ディスクにミラーリングをしているケースが少なくありません。ディスク障害による保護という観点から考えると「全く無意味」なミラーリングです。・上記(1)のオンラインREDOログのミラーリングも同様に同じ物理ディスクで行っても意味がありません。更新処理の多いサイトでは同じ物理ディスクに同時に書き込みが発生するため、I/O待ちによるパフォーマンス劣化につながります。・上記(2)のアーカイブログをミラーリングしているサイトはあまり見かけません。アーカイブ運用を行ってもアーカイブログが壊れてしまったらリカバリはできなくなる(元も子もない)ため、実装されている機能です。2.Oracleによるミラーリングを行っている場合は:上記(1)(2)(3)はミラーリングを行うために、それぞれ2本づつの物理ディスクを必要とします。いうことは、これだけで6本のディスクが必要になるということになります。3.RAID-1でミラーリングする場合は(Oracleによるミラーリングは使わない):理屈は同じです。したがって6本の物理ディスクをミラーリングして3つのロジカルボリュームにそれぞれを配置します。上記(5)(7)の参照表は通常は更新されないファイルかもしれませんが、今回は夜間バッチなどで定期的に更新され、アーカイブ運用バックアップが必要なものとして扱います。5.RAID-0によるストライピング本数優先でミラーリング保護は必要ない:Q.上記(8)(9)はワークデータを書き出すだけなのでミラーリングして保護する必要はないのではないでしょうか?A.上記(8)の一時表が格納されたディスクが壊れた場合を想定してみましょう。データのソートマージジョイン中に一時表にアクセスができなくなってしまいました。SMJの結果をInsertするような処理であったとしてもInsert文はエラーを返しRollback(各自のエラー処理で)を発行します。したがって(8)の一時表が格納されたディスクが壊れても一時表として作成されたテーブルスペースであればデータの不整合やリカバリの必要はありません。xxxを急いで投入しなければなりません。それらを考慮するとワークデータを扱う(8)の一時表も処理の中断を防ぐためにミラーリングを行うべきです。(9)のロールバックセグメントのときはどうでしょう。ロールバックセグメント用テーブルスペースが格納されたディスクが壊れた場合はリカバリが必要になります。性を保障する検索処理もできなくなります。その中断を回避するためにミラーリングを行うべきです。補としての提案だと思います。今回の場合であれば(7)の参照表のインデックスをミラーリングしないというのは正しい選択かもしれませんね。壊れてしまったインデックスはCREATEしな直せばよいのですから...。6.それでは全てのデータファイルはRAID-1+0でミラーリング+ストライピングを行いましょう:A.上記(4)~(10)を10本の物理ディスクでミラーリングして5本分のストライピングに置いてください。含めた)ディスクI/O待ちを最小限に留めると言ったところからnn本のディスクでストライピングしましょう!という答えになります。Q.今回「10本ぐらいを想定して」という事が前提でしたので、(1)~(10)までで合計で16本も(!)ディスクが必要という事になってしまいます。条件は?A.「前提条件が曖昧すぎます!」とか「こういった問題は、全体のバランスだと思います」などいうごもっともなお答えも沢山ありました。最低でもこのくらいは必要です。・もちろん、同時実行数や実装されるCPUの数が多ければ必要なディスクの数も増えます。・ディスクI/O待ちによるパフォーマンスの影響がどのくらい許容できるかによりディスクの数は決定されます。そもそもパラレルクエリーを使うようなお客様であれば複数CPUとディスクストライピングは前提条件として考えているでしょうから、小・中規模システムのOLTP系では?という課題に変更します。以上を踏まえて投稿をお待ちしています。投稿の中から、採用させていただいた方々に対して抽選で当メルマガの書籍をプレゼントいたします。(実名は載せません)以上、今年もがんばるぞぉ。reserved.トップページ企業概要プライバシーポリシ。