このページは、以下の英語ページの抄訳です。最新の情報については、
英語ページを参照してください。
この記事のオリジナルは、Glenn Paulley が sybase.com に2008年6月に掲載したものです。自己管理型データベースとは、SQL Anywhere が成功を収めてきた要の基本理念であり、 また、ほとんど無限に存在するオペレーティング環境のセットがデータベースの世界とはアンマッチである中で、単に「正しいことをする」という我々の意思と能力のあらわれです。
最近私は、SQL Anywhere に限定したことではなく、もっと一般的なこととして、ソフトウェア（DBMS）の自己管理をゴールとすることに対して質問/批判を受けました。
その議論とは、つまり、自己管理が価値のあるビジョンである一方で、達成不可能なユートピアであるというのです。
ここで暗に示されているものは、このユートピアのビジョンは、実装不可能であるが故に、自己管理への努力は全て価値がない、ということです。
私は、自分の生涯の間にこのユートピアに到達できると信じるほどナイーブではありませんが、自己管理への努力が価値がないということには同意できません。
私は、ソフトウェアのユーザビリティーは非常に大きなことで、ソフトウェアパッケージの管理/設定を低減する努力は全て、価値があることであると信じています。
このゴールは、データベース管理システムだけではなく、全てのソフトウェア製品にあてはまると言えるでしょう。
データベース管理システムにおいて、自己管理を考えた場合には、主に自分たちがすでに解決方法を知っている問題に対するソリューションを実装することになります。
動的バッファープール管理、動的アクセスプラン変更、セルフチューニングヒストグラムなど、これらは何年にもわたって研究されてきたもので、この機能の動作変更を実装するベストな場所は、データベースサーバーなのです。
ヒストグラムが、良い例です。値の数とその分散を考慮すると、サーバーこそがあらゆる特定のヒストグラムに必要なバケットの数を決定するベストポジションにあります。
データベース管理者が決定する必要など、全くありません。 「良い」決定をするために必要なノウハウのレベルに達しているデータベース管理者は、ほとんどいません。
要するに、自己管理テクノロジーのゴールは、最高レベルのout-of-the-box （箱から出してすぐの状態、デフォルト） のパフォーマンスを成し遂げることであり、それこそが価値のあるゴールなのです。
しかしながら、自己管理テクノロジーは、それ自体が容量計画や、パフォーマンス分析、問題検知などの必要性をなくすものではありません。
自己管理が行うものは、データベース管理者が、より大きな問題にフォーカスすることができるようにすることなのです。
それらは例えば、以下のようなものです。
- end-to-end アプリケーション内のどこの場所に特定の機能を置くのか特定する。クライアント内、中間層、またはサーバー自体なのか。
- アプリケーションスケーラビリティーの問題を特定して解決する。
- 容量計画を非常に簡単にする。
- 論理的そして物理的スキーマ設計をサポートする。
- アプリケーション開発者の生産性を向上する。
データベース業界の人間として、私たちはサーバー内の特定の自己管理アルゴリズムの基本的な問題の先を行かなければなりません。
そして、これらのより大きな問題に対処するツールやテクニックの考察を始める必要があると考えています。
===
SAP SQL Anywhere に関する詳細情報は、<英語> を参照してください。
上記のコミュニティーに掲載されている技術情報は、順次
SQL Anywhere 日本語コミュニティ
に掲載しています。
SQL Anywhere に関してはまずは
こちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。
SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「Ask a Question」機能をご利用ください。
Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択
User Tagに「sql anywhere」「sql anywhere Japanese question」
を入力してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。
