RDBMS + ILM ？

こんにちは、nagino です。

個人的になるほどな、と思った記事です。

http://www.atmarkit.co.jp/news/200906/16/oracle.html

Oracle が、データベースで ILM（Infomation Lifecycle Management） を実現したそうです。

SQL Server でも、パーティションテーブルとファイルグループを組み合わせることで、ひとつのテーブル内でデータを配置するストレージを使い分けることができますが、ILM となるためには情報の使用頻度に応じて自動的な再配置が必要です。

例えば登録日時を持つ列を作り、その日付を見て処理する日次バッチなどを作ることで、ルールベースで管理の自動化はできますが、使用頻度を DBMS が自動的に、というのは現状では無理だと思います。

近い仕組みですと、直近データのみ RDBMS に置き、月次バッチなどで過去データは DWH に移動してしまうという手もありかと思います。

ですが、RDBMS 自体で ILM が行えたら、運用や管理の面で楽そうなので、ちょっと興味深いなと思った次第でした。

アクセス回数とアクセス日時を記録する列を追加して、トリガなどで随時メンテナンスすれば、その列を元にしたルールでできなくも無いですが、パフォーマンスが悪そうです。

SQL Server で ILM が実装されたら面白そうなんですけどね。

追加コスト 0 で行う SQL Server のパフォーマンス改善・ボトルネック解消 おわりに

こんにちは、nagino です。

思いつくまま書き連ねた本シリーズですが、今のところぱっと思いつく事項を書きつくしたので、一旦 END とします。

重要性、汎用性、効果などを吟味せずに可能性があるものを連ねていったので、そのまま即使えるようなネタではありませんでしたが、検討する際の着眼点の参考にはなるかなと思います。

そのうち機会があれば、情報を整理してみたいと思います。

さて、最後に 1 つのツールを紹介しておきます。

SQL Server 2005 からになってしまいますが、データベースエンジンチューニングアドバイザです。

このツールは、インデックスやインデックス付きビューなどの作成・削除によるパフォーマンスの改善を自動的に分析してくれるツールです。

インデックス付きビューに対応していたり、削除による効果も検討してくれるなど、自動ツールといいつつかなり優秀です。

http://msdn.microsoft.com/ja-jp/library/ms173494.aspx

2000 のころのインデックスチューニングアドバイザよりも機能強化されています。

実際にパフォーマンスに問題がある場合は、以下の 3 択から、スキル、予算、時間に応じて選択することになります。

● チューニング

● サーバーリプレース

● 対処しない

チューニングはそれなりのスキルを要求しますので、先ほどのツールや業者に頼むと高くなりますし、自力で進めるには時間がかかったり予期しない副作用に遭遇したりとなかなかハードルが高いです。

ハードの性能は日々向上していますので、サーバーリプレースが実は安価だったりもします。

人件費はやはりそれなりの大きさがあります。

ここまでチューニングの話を書いておきながらですが、チューニングせずにサーバーリプレースないしは現状維持という選択肢も検討してみてください。

まあ、設計開発段階で予算が必要な事項について十分な性能を考慮しておいてくれれば、運用後にチューニングする必要なんてほとんどないのですけれども。。。

追加コスト 0 で行う SQL Server のパフォーマンス改善・ボトルネック解消 その11

こんにちは、nagino です。

そろそろ終わりかなという本シリーズですが、今回はカバリングインデックス（& 付加列インデックス）についてです。

私は、カバリングインデックスも付加列インデックスも、どちらも目的と手法が同じですので、あわせてカバリングインデックスと呼んでしまうのですが、SQL Server としては付加列インデックスは技術的に異なり、またセールスポイントでもあるため、区別して呼称するようです。

● カバリングインデックス

SELECT 文で使用する全ての列を含んだインデックスを作成することで、データページにアクセスすることなくインデックスページのみのアクセスで処理を行うことが出来、結果 Key Lookup によるアクセス（得てしてランダムアクセス）が省かれ、パフォーマンスが改善します。

● 付加列インデックス

条件式で使用する全ての列を含んだインデックスに、SELECT 句で取得する列を付加列として加えたインデックスを用意することで、カバリングインデックスと同様のパフォーマンス改善を図ります。

さらに、一部の列は付加列とすることでインデックスの中間ページに含まれるデータが減少し、結果インデックスのページ数が減少することで、カバリングインデックスよりパフォーマンスの改善を図ります。

パフォーマンスが問題になっている SELECT 文に対してこれらのインデックスを用意することで、検索処理のパフォーマンス改善を図ることが出来ます。

ただしインデックスが増えますので、その分更新処理のパフォーマンスは劣化します。

また、インデックスに含まれる列の順番や、付加列とするかどうかなどを誤ると、これらのインデックスが使用されないため、パフォーマンス改善に結びつかないことがあります。

トランザクションのテーブルがコメント情報などサイズが大きい列を含んでいて、またそのような列を含まない一覧画面などがあるといったように特定列のみを取得する処理が多い場合、これらの列を含むインデックスを用意しておくことでパフォーマンス改善を図れます。

追加コスト 0 で行う SQL Server のパフォーマンス改善・ボトルネック解消 その10

こんにちは、nagino です。

気が付くと二桁突入の本シリーズ、だんだんピーキーな設定項目の話になってきましたが、今回は多少汎用的な、復旧モデルです。

復旧モデルは以下の 3 種類があります。

● 完全

● 一括ログ

● 単純

ここではそれぞれの詳細には言及しませんが、通常本番環境では「完全」になっているかと思います。

# 障害発生時に、最終バックアップではなく、障害発生直前までデータを復元できるようにするため。

実は、「一括ログ」は一括ログ操作のパフォーマンスが優れています。

また、トランザクションログのバックアップが可能です。

これは、一括ログ操作時にその操作の詳細の記録を行わず、サマリだけを記録するためです。

一括ログ操作というのは、主に以下があります。

● bcp

● BULK INSERT

● SELECT INTO

● インデックスの再構築

詳細は以下にあります。

http://msdn.microsoft.com/ja-jp/library/ms191244.aspx

ここで、夜間バッチで一括ログ操作を大量に行っている場合、夜間バッチ処理中のみ復旧モデルを「一括ログ」に設定し、その前後で適宜バックアップ（トランザクションログバックアップでも可）を行うことで、夜間バッチのパフォーマンスを向上できる可能性があります。

また、システム立ち上げ時のデータ移行などの作業でも、その作業時間の短縮が期待できます。

もちろん、通常業務時間帯は「完全」に設定しなおしておく方がお勧めですが、上記作業での時間短縮が必要な場合は、その作業中のみ復旧モデルを切り替えるという手法の検討の余地があります。

おがわ先生引退

こんにちは、nagino です。

このブログでは珍しく、技術以外の雑ネタです。

私が勝手に心の師と思っている、おがわみつぎ先生が引退とのことです。

http://blogs.sqlpassj.org/mitsugi/archive/2009/06/17/26793.aspx

私が SQL Server をほとんど知らなかったときから、PASSJ のアフタースクールなどを通して色々と教えていただきました。

Microsoft MVP に認定いただけたのも、全てはおがわ先生（& 河端先生）に教えていただいたことがスタートでした。

非常に残念ですが、今後のご活躍をお祈りしたいと思います。