InsightTechnology 旧ブログ

今年最初のメルマガです。QAシリーズ第3回目です。

１．Oracleによるミラーリング機能があるファイルは：
(1)オンラインREDOログ
(2)アーカイブログ
(3)コントロールファイル
の３つです。

・上記(3)のコントロールファイルはOracleによるミラーリングがされている
場合が多いのですが、同じ物理ディスクにミラーリングをしているケース
が少なくありません。
ディスク障害による保護という観点から考えると「全く無意味」なミラー
リングです。
・上記(1)のオンラインREDOログのミラーリングも同様に同じ物理ディスクで
行っても意味がありません。また更新処理の多いサイトでは同じ物理ディ
スクに同時に書き込みが発生するため、I/O待ちによるパフォーマンス劣化
につながります。
・上記(2)のアーカイブログをミラーリングしているサイトはあまり見かけま
せん。せっかくアーカイブ運用を行ってもアーカイブログが壊れてしまっ
たらリカバリはできなくなる(元も子もない)ため、実装されている機能です。

２．Oracleによるミラーリングを行っている場合は：
上記(1)(2)(3)はミラーリングを行うために、それぞれ2本づつの物理ディ
スクを必要とします。ということは、これだけで6本のディスクが必要にな
るということになります。

３．RAID-1でミラーリングする場合は（Oracleによるミラーリングは使わない)：
理屈は同じです。したがって6本の物理ディスクをミラーリングして3つの
ロジカルボリュームにそれぞれを配置します。

４．パフォーマンスを考慮したデータファイルのストライピング：
(4)事実表
(5)参照表(*1)
(6)事実表のインデックス
(7)参照表のインデックス(*1)
(8)一時表
(9)ロールバックセグメント
(10)システム表

備考
*1 上記(5)(7)の参照表は通常は更新されないファイルかもしれませんが、今回
は夜間バッチなどで定期的に更新され、アーカイブ運用バックアップが必要
なものとして扱います。

５．RAID-0によるストライピング本数優先でミラーリング保護は必要ない：
Ｑ．上記(8)(9)はワークデータを書き出すだけなのでミラーリングして保護
する必要はないのではないでしょうか？
Ａ．上記(8)の一時表が格納されたディスクが壊れた場合を想定してみまし
ょう。例えば、データのソートマージジョイン中に一時表にアクセスが
できなくなってしまいました。SMJの結果をInsertするような処理であ
ったとしてもInsert文はエラーを返しRollback（各自のエラー処理で）
を発行します。したがって(8)の一時表が格納されたディスクが壊れて
も一時表として作成されたテーブルスペースであればデータの不整合や
リカバリの必要はありません。しかし、、、、、
一時表がなくなってしまうと後続するこれを必要とする処理が全てエラー
になってしまいます！
これを回避するためには急いで一時表を作るか、別に用意してあった一
時表を使うようにALTER USER xxx temporary tablespace xxxを急いで
投入しなければなりません。
それらを考慮するとワークデータを扱う(8)の一時表も処理の中断を防
ぐためにミラーリングを行うべきです。
また、(9)のロールバックセグメントのときはどうでしょう。
ロールバックセグメント用テーブルスペースが格納されたディスクが壊
れた場合はリカバリが必要になります。リカバリの最中はロールバック
セグメントを必要とする更新処理ができなくなるばかりか読み取り一貫
性を保障する検索処理もできなくなります。
その中断を回避するためにミラーリングを行うべきです。

Ｑ．上記(6)(7)はミラーリングしなくても大丈夫ではないか？
Ａ．ディスク本数を最小限にしたいからミラーリングしなくても構わない候
補としての提案だと思います。ギリギリの候補としてインデックス類、
特に今回の場合であれば(7)の参照表のインデックスをミラーリングしな
いというのは正しい選択かもしれませんね。
壊れてしまったインデックスはCREATEしな直せばよいのですから…。

６．それでは全てのデータファイルはRAID-1+0でミラーリング＋ストライピン
グを行いましょう：
Ａ．上記(4)～(10)を10本の物理ディスクでミラーリングして5本分のストラ
イピングに置いてください。なんて感じでエイヤッ！で決められる場合
が多いのですが、10本といった場合の背景は：
・実装されるCPUの数
・同時トランザクション数
・DSS系処理であれば（パラレルクエリーも使う)、同時アクセスによる
（一時表な ども含めた）ディスクI/O待ちを最小限に留める
と言ったところからｎｎ本のディスクでストライピングしましょう！
という答えになります。

Ｑ．今回「10本ぐらいを想定して」という事が前提でしたので、(1)～(10)
までで合計で16本も(！)ディスクが必要という事になってしまいます。
もう少し条件は？
Ａ．「前提条件が曖昧すぎます！」とか「こういった問題は、全体のバラン
スだと思います」などいうごもっともなお答えも沢山ありました。

16本も必要？
・複数CPUを実装したマシンでパラレルクエリーなどを行う、DSS系処理では、
最低でもこのくらいは必要です。
・もちろん、同時実行数や実装されるCPUの数が多ければ必要なディスクの
数も増えます。
・ディスクI/O待ちによるパフォーマンスの影響がどのくらい許容できるか
によりディスクの数は決定されます。

そもそもパラレルクエリーを使うようなお客様であれば複数CPUとディス
クストライピングは前提条件として考えているでしょうから、小・中規模
システムのOLTP系では？という課題に変更します。

以上を踏まえて投稿をお待ちしています。

・OLTP処理がメインではあるが、1時間に1回、500MB程度の全件検索処理が実行
される
・アーカイブ運用を行いリカバリには万全を期す
・バックアップの方法はオンラインバックアップを使用します
・オンラインREDOだけでなく、アーカイブログが壊れてしまったら元も子もな
くなるのでそれらもミラーリングして保護する
・内蔵２本・外付けを含めて合計で10本～20本に収めたい
・データ量は最大のデータファイルで2GB、全体のデータファイルの合計は30GB
程度２年後のデータ量も100GB以内

投稿の中から、採用させていただいた方々に対して抽選で当メルマガの書籍を
プレゼントいたします。(実名は載せません)

以上、今年もがんばるぞぉ。 Au-DBitマスター試験官

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

一緒に検証してみませんか？

TOP

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

┏─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┓
●【 セミナー案内 】 ●
┗─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━─━┛
Performance Insight Ver.5.2.3発表記念セミナーを開催します！！
★パフォーマンス悪化のケーススタディ　”現在、過去、そして未来”

日程：2004年1月27日 14:00～18:00
会場：日本オラクル 本社8F セミナールーム
講師：小幡　一郎
参加料：無料
定員：１００名様(事前申込制)

詳細＆お申し込みはこちら
https://www.insight-tec.com/html/seminar/pi523.html

皆様のお申込みお待ちしております！！