絵で見てわかるシステム構築のためのOracle設計 (DB Selection)
- 作者: 加藤健,前島裕史,岡田憲昌,有滝永,草薙康裕,小田圭二
- 出版社/メーカー: 翔泳社
- 発売日: 2012/02/21
- メディア: 単行本（ソフトカバー）
- 購入: 10人 クリック: 146回
- この商品を含むブログ (2件) を見る
絵で見てわかるOracleの仕組み (DB Magazine SELECTION)
絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection)
などの「絵で見てわかる〜」シリーズの小田圭二さん*1監修です。
現場のエンジニアが Oracle Database の設計をするときに困るのは、製品マニュアル*2を読んでもよくわからない、本を読んである程度理解したが、結局、設定値をどうすればよいかわからないといったところではないかと思います。この本では、設計や設定にどういう選択肢があり、それぞれのメリット・デメリットは何か、さらによくわからない場合はこの辺の設定値にして様子を見るとよいといった具合に書かれていて、現場で設計で悩んでいるエンジニアが手元に置いておくと役に立つ一冊だと思います。
CHAPTER5 高可用性設計、CHAPTER6 クラスタ設計、CHAPTER7 スタンバイ設計はかなり深い内容まで踏み込んで書かれており、RAC、Data Guard を使われているエンジニアには必携の書だと思います。
Amazon では、
ベストセラーの著者率いる最強コンサルタント軍団が執筆！図解が多くてわかりやすいと好評の「絵で見てわかる」シリーズに新刊が登場します。今回のテーマは「高可用性・耐障害性・高性能なシステム」です。
（中略）
また、システム構築の流れを一気通貫で見せながら、各フェーズごとに詳しく解説。もちろん図解も多用しているので、実務経験の浅い読者でも読み進められる内容になっています。
と紹介されています。全文は Amazon でご覧いただくとして、少しだけ内容を紹介します。
RPO・RTO・RLOとは
P.33
業務停止を伴う障害が発生した場合に、どの時点まで（目標復旧地点：RPO）、どれくらいの時間で（目標復旧時間：RTO）、どのレベルまで（目標復旧レベル：RLO）復旧させるかの目標を確認する項目です。
絵にするとわかりやすいですね。さすがイケメンコンサル岡田さん。絵もイケてます。
バックアップ方式のメリット・デメリット
P.58 表 3.2 各案の比較表（例）
バックアップ取得方式の違いによるメリット・デメリットの考え方が説明されています。日次フルバックアップにするか、週次フルバックアップで日次差分バックアップにするか、バックアップの保存先をディスクにするかテープにするかなどこのようにメリット・デメリットを整理して考えると、そのシステムにどの方式が適しているのかわかりやすくなります。
システム規模に応じた SGA のバッファキャッシュや共有プールなどのサイズの目安値
「ふむふむ、バッファキャッシュはデータブロックをおいている領域で、共有プールはライブラリキャッシュ（SQLや実行計画など）やディクショナリキャッシュ（表や索引の定義などの管理情報）などをおいている領域か、で、どりあえずどれくらいの値にしておいたらいいの？」というときはココ。
P.105 表4.9 SGAのコンポーネント別サイズ例
筆者は表4.9のサイズを基に、要件による見直しや性能試験の結果でチューニングすることを現場でお勧めしています。表4.9の値は最低値であることや、システムの特性によって必要なサイズは異なるため、必ず性能試験時にサイズが不足していないかを確認して、チューニングを行いましょう。
自動共有メモリ管理機能／自動メモリ管理機能と各コンポーネントの最低値を指定する合わせワザ
P.107
SGA_TAERGET を設定した場合、各コンポーネントのサイズ指定は必須ではありませんが、設定することで各コンポーネントの最小値を設定することができます。これにより急激なサイズ変動を防ぐことができ、安定したパフォーマンスを出せるようになるため、SGA_TARGETだけでなく各コンポーネントのサイズも指定することをお勧めします。
SGA_TARGET や MEMORY_TARGET を使って SGA や SGA + PGA 全体のサイズを指定する方式と、バッファキャッシュや共有プールなど個別に指定する方式があります。さらにその折衷案で、SGA_TARGET や MEMORY_TARGET を使いつつ、バッファキャッシュや共有プールなどの最小値を指定して良いとこどりをする合わせワザもあります。P.108 の表4.11 SGAの設計タイプに3つのタイプのメリット・デメリットが説明されています。物理設計は加藤健さん*3ががっつり書かれています。
Data Guard での各プロセスの役割と相関関係
P.207 図5.10 同期モードのREDO転送設定下でのコミット時の動き
これは Data Guard の REDO 転送において、同期（SYNC）モードを使用した場合の動きの説明です。commit を発行するとサーバープロセスがLGWRプロセスにREDOログバッファの書き出しを依頼し、NSSプロセスがREDOログのデータをスタンバイ側のRFSプロセスに転送し、RFSプロセスはREDOログに書き込み、MRPプロセスがREDOログを読んでデータファイルに変更を反映している絵です。市販されている書籍でここまでわかりやすく説明されている絵は初めて見ました。さすが、コンサル内で Data Guard の神と呼ばれている前島さん*4。
ASMのストライプサイズ
ASM についてもわかりやすく解説されています。
P.280 図6.31 ストライプサイズ
ストライプサイズとは、データがストライピング配置される際の領域割当の単位です。データファイル、アーカイブログファイル、一時ファイルについてはAU=Allocation Unit（割当ユニット）単位での割当が行われますが、REDOログ、制御ファイルといった待機時間を短く抑える必要のあるファイルについては、128KB単位での割当が行われます（図6.31）。
ここは私が入社してから、いろいろ助けていただいた草𦿶さんが書かれたパートです*5。
Data Guard を使う時の初期化パラメータや listener.ora、tnsnames.ora のパラメータの相関関係
P.308 図7.11 REDO 転送関連パラメータの関連図
この絵も Data Guard の神こと前島さんの力作です*6。例えば、初期化パラメータ fal_server はプライマリから受取るREDOログのアーカイブにギャップが発生している場合に、スタンバイデータベースからプライマリデータベースに問い合わせするために使う tnsnames.ora のNetサービス名を指定します。つまり、fal_server には tnsnames.ora に存在するNetサービス名を指定する必要があります。fal_server の説明については KROWN#71938 でわかりやすく説明されていますが、この絵を見ると一目瞭然です。何度か紙に絵を書いて説明したことがありますが、今度からこの本の絵を使って説明しようと思っています（笑
「CPU使用率が高い＝悪」か？
P.324
筆者は現場の担当者より「CPU使用率が高いからCPUリソースが足りない状況だと考えていますが正しいですか」と質問されたことがあります。これはデータベースサーバのCPU使用率が90%前後をしばらく推移しているときに質問されたことですが、CPU使用率が高くてもほかの処理に影響が発生していなければCPUリソースが足りていないとは限らず、問題かどうかは判断できません。
（中略）
ここで、ほかの処理に影響しているか判断する指標としてはランキューを確認します。
ランキューはCPUの割当てを待っているプロセスの数です。WindowsであればperfmonのProcessor Queue Lengthの値、Linuxであればvmstatのr値を確認します（図8.5参照）。
これは、↑で「質問されたことがあります」と書かれている通り、意外と知られていないのではないかと思います*7。この話は上級者向けの分厚い本*8には結構書かれていると思いますが、初心者向けにここまで易しく書かれているのは珍しいと思います。さらに実際に運用監視でどうしたら良いかというところまで書かれているとなるとさらに珍しいのではないかと思います。自分がいつか本を書く時に書きたいと思っていたネタですが、自分が考えていたよりわかりやすく的確に書かれていました。有滝さん、まいりました。
I/Oボトルネックの見方
P.331
I/O待ちキュー数
（中略）
WinodwsでAvg.Disk Queue Lengthの値が2未満であることが理想です。Linuxの場合はI/O待ちキューはavgqu-szになりますが、この値に対してしきい値を設定して運用しているところは少ないです。 avgqu-szの使い方としては通常時より大きな値であるかなどの傾向確認の指標として利用することが多く、I/Oボトルネックの確認には、併せて%utilの値を確認します。%utilが100に近くavgqu-szの量も普段より多いという状況であれば、そのとき発生している処理についてはI/Oボトルネックにて影響を受けている可能性が高いといえます。
こちらもCPU使用率と同じくいつか書きたいと思っていたネタです。有滝さん。。。降参です（笑
最後に、著者紹介から
岡田 憲昌（おかだ のりまさ）
（中略）
プライベートでは、イクメンとイケメンの両立について日々研究中。
研究成果が出版されるのを楽しみにしています。
*2:Oracle Database のマニュアルはよくできていると思います。「Oracle Database概要 11gリリース2(11.2) B56306-03」 http://docs.oracle.com/cd/E16338_01/server.112/b56306/title.htm とか見ていただけるとわかりますが、意外と？わかりやすくて面白いですよ。
*3:http://oracletech.jp/products/pickup/000188.html
*4:ココは怒られたら消す
*6:ココも怒られたら消す
*7:ご存知の方には常識的な話ですが
*8:この本も薄くはないですねw
