論文治療クリニック（外来）

次の患者さんは。Kennyさんですね。

エーロン先生、こんにちは。
なかなか勉強が捗らない、Kennyです。
やっと（＾＾；毎日、少しづつ書き上げた論文です。
お忙しいところ申し訳ありませんが、見ていただけませんでしょうか？
内容は、データベース設計ではなく、平成10年問3「性能改善について」です。
次回は、データベース関連について書きたいと思います。
何卒厳しい論評、よろしくお願い申しあげます。

性能改善といえば、ドクターが論文医師国家試験に合格したH10のメモリアルテーマですね。ですからここは思い入れがありますよ。ＮＡＯＫＩ医師の「正規化関係のデータベース設計」と同じですね。思い入れのあるテーマは、おのずと診断が厳しくなりますよ。

＞やっと（＾＾；毎日、少しづつ書き上げた論文です。

最初は仕方がありませんが、今回の診断の結果を良く理解して、次からは制限時間を意識して必ず手書きしてから、その後電子データ化して送付してください。

問３　性能改善について

　適用業務システムの性能目標は、業務要件や運用要件に基づいて、スループット、ターンアラウンドタイム、レスポンスタイムなどの具体的な数値として設定される。
　開発が進みテストを行った結果、性能目標が達成できていなければ、ネットワーク監視ツール、パフォーマンスモニタ、トレースツールなどによって原因を調査・分析し、性能改善を実施する。
　具体例としては、次のような性能改善のための対策が挙げられる。

1.    チューニング

oバッファサイズ、実行優先順位、処理多重度などのシステムパラメタの変更

oデータベースのインデックスの見直し、排他制御方式の見直し

oプログラムロジックの変更

2.    設計レベルの見直し

oサーバの分割・統合

oデータベースの物理構造の見直し

oプログラム構造の見直し

3.    リソースの追加

oメモリ、ディスクなどのハードウェアの増設、ネットワークの高速化

これらの対策を実施するに当たっては、期間、コストなどの検討も必要である。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

では、論文見せてください。

Ｈ１０−問3 「性能改善について」
−−−−５−−−−10−−−−15−−−−20−−−−25
1-1.システム概要
　私は、メーカー系ソフトウェア開発会社に勤務するシ
ステムエンジニアである。今回、私は、年間推定500万
件の廃家電品を処理する家電リサイクルの管理会社Ｒ社
の情報システム構築プロジェクトにアプリケーションエ
ンジニアとして、参加することになった。
　Ｒ社は、2001年4月より家電リサイクル法施行に先立
って設立された会社であり、引取業者による廃家電品の
引取実績情報をもとにリサイクル料金の請求支払いを代
行する会社である。消費者が排出する廃家電品には、Ｋ
社が発行するバーコード付リサイクル券が貼付されてお
り、引取業者は、このバーコードを読み込み、Ｋ社に引
取情報として送信することになっている。
　Ｒ社では、法施行に伴う設立により、業務フロー等が
確立されておらず、さらに情報システムをどう活用して
いくのか、といったビジョンも明確化されていない状態
で、本システムにおける運用要件も特に定められていな
かった。
1-2.テストで発生した性能上の問題点
私は、このような状況の中、K社からの引取実績デー
タ受信可能時刻や本システムの運用開始時刻、データバ
ックアップ時間帯等を勘案し、日次で行う引取実績集計
バッチ処理時間の目標値を2時間に設定した。
　開発が進み、運用テストに入った頃は、データ件数が
少なかったこともあり、上記の目標値は、クリアされて
いた。しかし、それから1ヶ月ほど経過した頃、上記の
目標値は、大幅に上回り、12時間という処理時間となっ
てしまった。
　私は、この問題点を解決するために、以下に述べる方
法で原因を調査・分析し、対策を実施した。


2-1.性能上の問題点の原因究明方法
　この引取実績集計バッチ処理は、データベース上のス
トアドプロシージャであるため、ネットワークの負荷増
大に起因するものでないことは明白だったので、以下の
4項目を調査するように開発担当者に指示した。
(1) CPU負荷状況の確認
サーバ自身のCPU負荷状況、およびバッチ処理が動作
しているときの他プロセスを含めた動作状況をサーバの
パフォーマンスモニタにより確認する。
(2) 処理時間の確認
　バッチ処理には、さらにデータ取込み処理、データ更
新処理、およびデータ集計処理と分かれており、どの処
理に時間がかかっているか、ストアドプロシージャのト
レースログを採取し、把握する。
(3) インデックスの確認
　さらにトレースログから、データベースアクセスに際
して設定されているインデックスが有効か、データベー
ス内の特定のテーブルをフルスキャンしていないかを確
認する。
(4) 処理内容の確認
　ストアドプロシージャのソースプログラムを机上にお
いて再レビューし、処理効率を妨げる記述がないか確認
する。再レビューには、私と開発担当者の他、実際にデ
ータベースの詳細な設定を行ったデータベースエンジニ
アにも参加を要請した。
2-2.性能的課題の検討内容と解決策の実施
　上述のような調査をした結果、以下のようなことが判
明した。
　(1)当該サーバにおいて、バッチ処理稼動時間帯では、
データベース関連プロセスしかほとんど動作していない。
　(2) バッチ処理のうち、データ更新処理とデータ集計
処理で処理時間が増大している。
　(3) それらの処理の中で、テーブルをフルスキャンし
ている個所がいくつか見られた。
　これらの調査結果から以下のような解決策を見出した。
　(1) 設定したインデックスを見直すとともに、再設定
したインデックスが有効になるようにプログラムロジッ
クを変更し、テーブルフルスキャンを回避する。
　(2) 上記(1)案だけでは、将来的（半年も経たないうち）
に性能目標の2時間を超えてしまうことが予想されたの
で、更にデータ集計処理のために、予め更新対象の更新
前データと更新後データを中間ファイルに格納しておき、
集計対象の抽出を行うことにより、データ集計処理の高
速化を図る。
　解決策の実施に当たっては、本番稼動のスケジュール
とプログラムロジック変更に伴う工数を考慮した結果、
今回は上記(1)案のみ実施し、(2)案については、本番稼
動後に行うことをR社に提案した。なお、格納した引取
実績データは2年経過したものについては、バックアッ
プ媒体にバックアップを行い、データベース上から削除
してもらうことをR社に再確認した。
提案はスムーズに了承が得られ、解決策の実施に当た
った。
3-1.性能改善結果の自己評価
　(1)案を実施した結果、バッチ処理時間は、10分とな
り、応急措置としては、納得のいくものであった。しか
しながら、現在、本番稼動後5ヶ月が経過しようとして
おり、バッチ処理時間は、1時間と当初の予想通り目標
値に迫ってきている。近日中に(2)案の解決策を実施する
予定である。
3-2.性能改善を効果的に行うための方法
　最後に私が考える性能改善の効果的手法について述べ
る。
　性能要件は、適切な業務要件が有って初めて目標値を
設定できる。そのため、我々アプリケーションエンジニ
アは、如何にお客様から業務内容を引き出し、業務分析
を行うことによって的確な性能要件を設定できるかにか
かっている。
　そして、テストにおいては、性能要件を満たすべく適
切なテスト環境・項目の設定を行い、テストを実施し問
題が発生したときの迅速に対策を実施する手順と体制を
予め明確にしておく必要があると考える。

とりあえず、最後に「以上」が抜けていますね。このようなケアレスミスはいけませんねえ。では中身のほうを・・・NAOKI医師の見立てをどうぞ

前回の見立てで、厳しさのあまりみなさん引いてしまった感のあるNaokiです。
厳しい中にもやさしさが見える見立てを目指します。いざ

（０）全体的、題意にも沿わせようと意図がみられます。本筋はこれでよいと思います。以下の点を中心にブラッシュアップしてください。

（１）設問アで「業務要件が不明確」と書いては、減点されてしまう可能性があります。たとえ本当のことでも、書かない方が良いです。

（２）キーワードを有効活用しましょう。
　　データベースの細かな内容を緻密に書くよりも、問題文にあるキーワードを踏まえて、十分消化した主張を展開できるようしてください。
　　キーワードはマージャンでいうドラだと思ってください。絡めたほうが得点が高いです。キーワードだけ書いてもだめですけど．．．

（３）設問イで、テーブル集計処理の対策はありますが、更新処理の対策はどこかへいってしまったのでしょう。書きましょう。
　　（私が見落としているだけかもしれませんが）

　　対策１．プログラムロジックとインデックスを見直しテーブルフルスキャンを回避
　　対策２．更新前テーブルと更新後テーブルを分割して集計対象の抽出を行うことによりデータ集計処理の高速化を図る

（４）設問ウは、案(2)を済ましたあとのハッピーエンドと行きたかったです。やはり５ヶ月で６倍の処理時間になる状況は異常に思えます。
　　他に問題があるのでは？と
　　そこで、数ヶ月後案(2)とデータの退避も行ったところ、ずーっと処理時間は１時間になった。これで安定運用です。
　　としていただいた方が読んでいる側からすると安心します。
　　安定運用していることがシステムとして前提ですから、たとえ完全な対応をまだしていないとしても、見積もり予定でも実績として書いてはどうでしょうか？

（１）と（４）
はうそを書けと聞こえますが、実際起こった、起こっている事実は変えられません。そのまま書くことが正直でよいと思われるかもしれませんが、それを間違っていることだからこうした、こうする方が良いだから論文にはそう書いた。ということは良いと思います。だってそれがあなたの実力だからです。

（２）と（３）を実施するにあたって、エーロン氏もＨ１３年予想「データ分析」要注目ということでしたね。

　私も来年はテクニカルエンジニアデータベースの雪辱をはらすために勉強がてらデータベースの性能改善についての対策思い出しかいてみました。参照、集計、更新、追加、削除ごとにまとめてみました。
（適当に書いています。誤記もきっとあります！！。）
間違い探しだと思って、みなさん参考書等とあわせて確認してみてください。

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
（ア）参照・集計系　
(1)インデックスの見直し
使われているか
使わない方が早いか確認
　インデックスをアクセスする分遅いなんてケースもある。
(2)オプティマイザ
ルールベースかコストベースか、意図したとおりに動作しているか？
コストベースならば統計情報は定期的に更新されているか？
(3)バッファの見直し
シーケンシャル読みとランダム読みのバッファ上限値を設定する。
シーケンシャル読みでバッファを全て使ってしまわないように、
ランダム読みのバッファヒット率をあげる。
(4)物理的配置の見直し、
テーブルの分割
処理件数の減少
年月でテーブルを分けるなど処理対象を減らす
テーブル統合
結合処理の回避、ディスクアクセスの減少
ブロック内で行移行が発生していないか
行移行が発生した場合１レコードを読み込むのに、
読み込みが２回発生する。
（イ）更新系
(1)物理配置の見直し
テーブルの分割
別ディスクに配置することで同時に書き出し
排他制御の回避
ブロック内で行移行が発生していないか
新規ブロックの生成が発生
(2)インデックスの見直し
（ウ）追加系
(1)インデックスを削除する。
インデックスの再編成（再構成？）にオーバーヘッドがかかるため。
(2)物理設計の見直し
大量データの追加の場合一度に領域を確保するブロック数を
増やすなど
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Kennyさんお子さんもおられるそうで、大変でしょうが頑張ってください。

では　お大事に