読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

IPA/SEC情報処理システム高信頼化教訓がバージョンアップ

Project Management

以前にこのブログで紹介したこともあるIPA/SECさんの「情報処理システム高信頼化教訓」がバージョンアップして、都度アップデートされるWebコンテンツになった(以前は分厚い報告書体裁のPDFだった)。これは何ぞと言うと「トラブルの原因や防止策が業界内で共有できていないやんけ!」という突っ込みに対する対策である。隣家の障害は蜜の味・・・じゃなかった、教訓だけではなくてトラブル事例そのものも共有されていて勉強になるので一読をオススメ。

http://www.flickr.com/photos/27458630@N03/4622386383
photo by dren88

今回追加された新ネタ「RDBMSのクエリ最適化機能に関する教訓」を読んでみる。

さて、2015年12月に新たに「RDBMSのクエリ最適化機能に関する教訓」というものが追加されたので読んでみた。
詳細は上記リンクから辿っていただきたいが、こんな事例である。

  • 安定運用されていたシステムで、ある時点からタイムアウトが頻発して使い物にならなくなる
  • データ蓄積量が増大するに従ってDBの性能が劣化していくことは予測できていたが、それより早い段階で急速に性能劣化が発生
  • DBの統計情報は日次で更新されていた
  • 原因は、ある時点でRDBMSの選択する実行計画がフルスキャンを行うものに切り替わったことによるもの
  • 対策は「インデックス追加」「一部統計情報の凍結」「全統計情報の凍結」でメリット、デメリットを比較して決定

個人的には上記のような状況に当たったことは(幸運にも)無い。システム設計をする際にも性能が線形劣化するのか、非線形劣化するのかを検証することはあるけど、RDBMSの実行計画の切替までは意識することはあまり無い印象。というわけで個人的にはこの追加事例はとても勉強になった。知っていると、実際に問題に当たったときの初動は相当にラクになるだろうと思う。

統計情報の設計については、以前に読んだ「達人に学ぶDB設計 徹底指南書」が詳しかったと記憶している。読み返してみようかな・・・

では、どのような場合に、統計情報の凍結を行うのが望ましいのでしょうか?それは、現状のものから実行計画を変化させたくない場合です。現在使われている経路が、将来にわたってもデータへの最短ルートであり、現状維持が最適な選択だ、とわかっている、そういう場合に、統計情報を凍結します。具体的には、システムのサービス終了時のデータを想定した状態での統計情報が存在する場合です。
達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書