港的
「IT　人には聞けない、チョット良い話」

DBにOracleを使用しているなら、インスタンスチューニングという方法もあります。 これは、Oracleを十分理解してないと手を出せないと思っているかも知れませんが、実はそうでもないのです。 Oracle10gのOracleDarabaseManagerは、結構使い勝手が良くなってきており、チューニングする為の情報満載です。 中小規模のシステムでは、基本的にSGAに関しては自動拡張モードで問題はありませんが、例に漏れず 「痒いところには手が届きません」 の様です。 ※DBの設計次第というところもありますが。。。 ここでチョット注意事項・・・ インスタンスをチューニングする際は、一気にやらない。 あらかじめサイズをきちんと見積り、電卓片手に微調整をする。 特に、何が遅いのか（例えば、ソートが遅いとか、FullScanが多いとか）を把握しておく。 そもそも、OLAP的な要素が強いのか、DWH的な要素が強いのか、日常業務用なのかを理解しておく。 チューニングしたからには、最後まで責任を持つ あと、本番機をチューニングする場合は、作業時間の調整を十分して下さい。 実際にパラメータを変更したら、Oracleを立ち上げ直す必要もあります。 他の作業をしている人もいるので、もめ事のネタに挙げられます。 なので・・・ 作業時間はあらかじめ調整しておく。（毎日又は毎週〇曜日の〇時から作業します！って感じ） 夜間作業や早朝作業になるケースがあるので、体調は常に整えておく。 必ずバックアップをとっておき、すぐに元通りに戻せる様にしておく。 友人・知人のDBAとは仲良く、常にコンタクトを取っておく。（他人の知恵も重要） では、次回は、具体的なチューニングを・・・

まずは、H/Wのチューニング。 簡単なところからいくと・・・ 1.CPUの増強 　*　数を増やす 2.メモリの増設 　*　近頃価格も安くなってきているので・・・ 3.HDD 　*　RAIDがソフトウェアRAIDならハードウェアRAIDにできないか 　*　RAID０（ストライピング）にできないか 4. 「システムのプロパティ」-「パフォーマンスオプション」の設定。 *　プロセッサのスケジュールがバックグラウンド優先にする。 *　適切な仮想メモリの容量を確保する。 5.パフォーマンスモニターで、不要なサービスを調べて、不要なサービスは起動しない。 6.ネットワークトラフィックの分散 　*　ツール（Freeソフトでも多く出てます）を利用して、ネットワークの負荷を調査し、 　　　ボトルネックとなるセグメントを調整する。 7.64Bit対応のOSを利用する。 　*　アプリが確保できるメモリが32Bitの倍（4G）確保できます。 　　　ただ、設定する時は、Boot.iniを修正したり、Oracleをメモリに 　　　常駐（LOCK_SGAの設定）させることができません。 H/Wチューニングは、下記の様にも思えます。 「H/Wでチューニングする」＝「簡単」＝「お金がかかる」 また、H/Wをチューニングしても、パフォーマンスが出ないケースもあります。 大きなデータに頻繁にアクセスする場合 アプリケーションが競合する場合 なので、H/Wチューニングは、現実的には「最後の手段」的なとこもあります・・・

問題点の抽出は、そんなに難しくはないです。 How To ? 「計れば良い」 のです。 機能単位、画面単位、くくりはどうでも良い。 測定した時間を書きこむシートの項目さえ、気をつければ良いのです。 必須項目は・・・ 画面（処理や機能） アクセスする表 時間 ソートやグループ化（サマリ）の有無 これを、単純作業で記入していく。 これを、システムの全機能に対して実施する。 集めたデータを睨みつければ、いやでも傾向が見えてくる。 後は、気付き。 H/Wなのか DataBaseなのか オブジェクトなのか プログラムの構造なのか SQLなのか・・・ この並び・・・ チューニングやったことがある人は、気付くはずです。 この並びが、チューニングのやり方なのです。 では、次回は、チューニングのやり方について

チューニングの際に、よく依頼者から言われることは、 「DATA BASEをチューニングして下さい」とか 「速くなるSQLの文法を教えて下さい」とか 「このSQLが遅いんですけど・・・」 が、結構多いのです。 しかし、依頼者には残念な事に、私の回答は一律下記なのです。 「まずは、調査が先です」 こて先のチューニングをしても不幸な結果になる事が多く、 又責任を転換される可能性も高いので、簡単に作業には入れません。 まずは、 「計る事」 それから、実態を調査します。 ※測定と実態調査は並行して行ってもOK 調査の時に重要な事項は、不具合（バグ）の収束率です。 不具合があるシステムは、いくらチューニングしても無意味です。 ※チューニングする箇所に多くは不具合も集中するので・・・ チューニングの考え方の順序は、いたってシンプルです。 計る 実態の調査 問題点の抽出 課題の抽出 課題消化の優先順位付け 課題消化 NO３以降は、各機能毎やアプリケーション毎に抽出を行います。 つまり、やらなければいけない事を明確にする事が一番大切なのです。 結構、切羽詰まった時に思い出される事がチューニングですので、 目先の事に目が行くのは当然ですが、 まずは、 「問題点を抽出する為に、システムを計り、現状を知る」 これに尽きます。 では、次回は、「問題点の抽出」について、考えてみます。

通常は、システムを発注しが方から言わせれば・・・ 「画面でないじゃない・・・」 「うっ、画面が白い。」 「遅いから×ボタン！」 表向きは、こういう感じですが、内心は・・・ 「今頃、何してんだ！」 「使えないなぁ、今度は別の会社にお願いしよう」 「つきあえない・・・」 顧客にしてみれば、お金払ってるだからまともなモノをつくれよ！って言うのが本音です。 顧客によっては、「シメシメ・・・これをネタに金払うまい」って気持ちにもなります。 なので、性能に関しては事前に取り決めが必要なのです。 最低限の取り決めは下記。 画面の表示速度を決めておく。（例えば、ボタン押下後、3秒以内に表示） バックグラウンドで実行するバッチ等の実行開始時間と実行時間見積 顧客からすれば、応答時間が早い方が良い訳で、ハードウェアの性能が上がってきている近年、とくにシステムリプレースなんて早くで当たり前って意識です。 性能に関する事項は、業務要件をまとめる際に決めておくべき事です。 顧客（発注者）側の方へ 性能は日常業務に支障をきたす事がらです。 システムを発注する際は、できるだけシステムコンサルタントの方と事前に相談の上、見積もり条件を提示しましょう。 では、次回は開発者側の視点で、対応策を提案していきます。

しばらくお休みしてましたこのブログ。 再開でっす！ 色々と書きたい事はありますが、やはり少しだけ役立つ事を中心につらつらと・・・ 再開、第１弾として、近頃マイブームとなっているシステムの性能改善について書いてみましょう。 システムの性能を改善する方法として、一般的なデータベースに絡んだチューニングを中心に書いていきます。 まずは、システムを仮定しなければなりませんね。 諸元を下記に仮定します。 System： 　販売管理 DB： 　RDBMS（Oracle社を前提にします。） アーキテクチャ： 　Windows　ServerによるWeb型システム 　Memoryは8G搭載の64bitマシン 　（贅沢でしょうか・・・） 　しっかりとデータはクラスタで管理されております。 システム開発の状況： 　淡々と開発は進み、ゴール直前にパフォーマンスがヨロシクナイと指摘され 　さぁ～大変。 こんなとこから、はじめたいと思います。 まずは、顧客側（システムを発注した側）からのアプローチを書きましょう。 では、次回．．．