コードジンのヘッダーが入ります
アイエニウェア・ソリューションズ エンジニアリング統括部 システムエンジニアチーム 課長の磯辺 信雄氏は、RDB製品「SQL Anywhere」の導入・開発支援の現場で実際に経験してきたシステムトラブルなどをベースにした、4つのケーススタディを紹介。
1つ目は、スタンドアロンで数百台稼働しているPOSシステムのうち、1日あたり数台が特定の処理でフリーズしてしまうという事例だ。このシステムでは.NETのマルチスレッドプログラムでコネクションプーリングを使用しており、特定の処理のみトランザクション分離レベルを変更していたが、.NETの仕様上、プールされているコネクションは直前に使用された分離レベルを継承する。詳細は割愛するが、障害の原因はそのトランザクション分離レベルの設定にあった。磯辺氏は、「処理開始・終了時に必ずトランザクション分離レベルの設定を行うことが重要」と指摘。また、Oracleが実装する読み取り一貫性、SQL ServerやSQL Anywhereのスナップショット分離レベルなどについても補足した。
2つ目の事例は、月別の売上件数を表形式に表示する処理のパフォーマンスが出ないというもの。これは、「表形式でカラム単位の集計をしてほしい」という要求仕様をそのままプログラム化したSQLの書き方に原因があった。当初は集計のために12×9回のSQLが実行されていたが、集計方法を見直してSQLを修正したところ、9回のSQL+結果セットからのフェッチで同じ集計結果を得られるようになり、パフォーマンスが改善されたという。「要求仕様を単純にSQLに置き換えるのは危険。常に効率のよいSQLを検討する必要がある」と、磯辺氏は注意を促した。
3つ目のケーススタディのテーマは、Viewの使用について。「Viewは非常に便利だが、使い方によっては、気づかずにパフォーマンスを低下させることがある。特に、集合関数や集合演算子を使ったViewは注意が必要」として、Viewを使わないほうが高速に処理できる実例などを紹介。対策例の1つとして、磯辺氏はマテリアライズド・ビュー(SQL Serverではインデックス付きビューに相当)の利用を挙げた。マテリアライズド・ビューは、実データを保持するのでパフォーマンスがよく、集合関数・集合演算子を使用するようなViewと親和性が高い。また、オプティマイザの機能によってマテリアライズド・ビューを使用するかどうかを自動的に判断させることも可能で、既存のSQLを変更せずにパフォーマンスを向上することができる。
4つ目に取り上げたのは、「マルチコアCPUが有効利用されていない」という事例。CPUのマルチコア化に伴い、RDBでもクエリ間並列処理、クエリ内並列処理など、マルチCPU構成を有効に利用できるアーキテクチャの実装が進んでいる。しかし、特に小規模なDBサーバ環境では、こうした並列処理がなかなか有効に機能しないケースも多いという。その原因について、磯辺氏は「ディスクI/Oがボトルネックになっていることが多い」と説明。有効な対策としては、キャッシュサイズを増やすこと、高速なディスクの採用、データベースを複数の物理ディスクに分散配置することなどを挙げた。
磯辺氏は最後に、同社のSQL Anywhereについて紹介。省リソースでの軽快な動作、既存DBとのデータ同期やデータ移行の容易性、管理の自動化といった主要機能を説明し、SQL Anywhere Developer Edition(開発者バージョン)の利用を呼びかけた。なお、Developer Editionは、日数制限なしで製品版と同様の機能が利用可能。アイエニウェア・ソリューションズのWebサイトより無料でダウンロードできる。