このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。
https://blogs.sap.com/2013/05/29/the-dba-will-be-obsolete/
この記事のオリジナルは、Glenn Paulley が sybase.com に 2008 年 4 月に掲載したものです。その中で、Glenn は 一般的なデータセンター外で稼働するアプリケーションを開発する人すべてに関連する、SQL Anywhere のエンジニアリングチームの長く変わらない設計思想について述べています。
自己（自動）管理、自己（自動）チューニングのシステム (IBM 用語では autonomic computing - 自律型コンピューティング）の 「The holy grail (至高の目標)」 は、完全に独立した、自己（自動）管理型のオペレーションです。つまり、パフォーマンスチューニングやシステム設定なし、手作業の介入なし。システムがそれ自身で動くものです。
自己（自動）管理型データベースシステムのテクノロジーは、IEEE で最近発足した Self-managing Database Systems (
IEEE Workgroup on Self-managing Database Systems) のワークグループのトピックで、毎年開催される IEEE Data Engineering カンファレンスのワークショップはすでに 3 回開催されています。そして 4 回目のワークショップが今週、本年度の Data Engineering カンファレンス（in Cancun, Mexico）で開催される予定です。
ゼロ管理のゴールが今日存在する製品の
どれもまだ完全に実現できていないことは、世界中のシステム管理者やデータベース管理者が知っています。
しかしながら、製品によって、例えば SQL Anywhere は、他の製品よりもこの理想に近いところに達しています。
最先端データベースシステムにおける「自己（自動）管理）」のイニシアティブは、2つのカテゴリに分類することができます。
a) 1 つ目は、データベース管理者が、広範囲のチューニングパラメーターの仕様などデータベースサーバーのオペレーション環境を設定する支援をするツールを開発することです。
ほとんどのメジャーな商用 DBMS システムが提供しているインデックスやマテリアライズドビュー選択ツールのようなデータベースの物理設計ツール（SQL Anywhere のインデックスコンサルタントや、IBM DB2 の Index Advisor、Microsoft の Autoadmin ツール）が、この種のツールの良い例です。
データベースの物理設計において、自動のインデックスやマテリアライズドビューの作成（そして代替や削除）は複雑であるがゆえに、それを
自動的にかつ
保証した結果として行うことは、非常に難しい領域であり続けることは変わりません。
とはいえ、先にリストしたツールは、データベース管理者が物理設計において正しい判断をする役に立ちます。インデックス選択の問題を最適に解決するのは、 それ自体
NP困難です。それでもツールが使用する近似値が、役に立つことにかわりはありません。
b) 2 つ目は、結果として自己（自動）管理オペレーションとなる、データベースサーバー自体の内部に埋め込まれるテクノロジーを開発することです。
例としては、動的キャッシュサイジングや、自動統計情報収集とそのメンテナンスなどです。
これらのパイオニアが、SQL Anywhere 製品です。
先の動的キャッシュサイジングは、バージョン 7 で（1999年）、そして自動統計情報収集とそのメンテナンスは 1992 年にリリースされたバージョン 3.2 で実装されました。
他のテクノロジーとして、自動の動的ワーキングメモリー割り当て、動的マルチプログラミングレベル調整、動的タスクプライオリティ付け、代替クエリープロセッシングストラテジーの動的選択、動的 I/O コストモデル調整、検出されたものと最適化時または実行時に発見された不正確なヒストグラム修正の双方に対するヒストグラムメンテナンスの向上などがあります。
上にリストしたような自己（自動）管理テクノロジーがパーフェクトなものになれば、ワークロードに左右される、うんざりするパフォーマンスチューニングは必要なくなり、データベース管理者の仕事を変えてしまうことになるでしょう。
例えば、ある商用 DBMS では一つのカラムヒストグラムのバケット数を特定しますが、それは本当に意味があるのでしょうか。実際のデータベースに格納されている値の分散をベースに、サーバーが
自動的にバケットを増やしたり、減らしたりすべきではないでしょうか。
あるいは他の例として、あるシステムで、データベース管理者がソートに専念しているバッファープールの（固定した）サイズを特定するのは、なぜ必要なのでしょうか？刻々とワークロードが変化すると何が起こるでしょうか？現在のオペレーティングワークロードをベースにサーバーがソートの要求を決定すべきではないでしょうか？
しかし、誤解のないよう述べておきますが、自己（自動）管理のパフォーマンスが
（最近リリースされた DB2 のバッファープール設定ツールのような設定ツールを使用しようがしまいが）、エキスパートが、マニュアル作業でチューニングしたシステムと常に同じである、と言っているわけでは
ありません。
私が主張したいポイントは、
(a) 概して、設定ツールはよく知られている、コンスタントに発生するワークロードには役に立ちます。
ワークロードが時間とともに変化する動的な環境では、データベースシステム自身に何をすべきか理解させ、実行する方が理にかなっていると考えてます。
SQL Anywhere は、今日すでに、広範囲なシナリオで、マニュアル作業の介入なしに実行することができます。このため、SQL Anywhere は、データベース管理者がいないためシステムを「注意深くケアすることができない」ような、管理が限定された環境で使用するデータベースとして理想的なのです。
(b) 自己（自動）管理は、総合的な問題です。自己（自動）管理テクノロジーは、サーバーの基礎となるコンポーネントであり、サーバーのオペレーションの設定においてデータベース管理者を支援する単なる管理的なアドオンではありません。
特に、これらのテクノロジーは、データベース埋め込み型のアプリケーションソフトウェアが必要とする自己（自動）管理と adaptiveness (適応性）のレベルを提供するために協調して作用することが重要です。
我々はこれらのテクノロジーのそれぞれが分離していては、効果的な自己（自動）管理には到達できないと考えています。
自己（自動）管理は、我々エンジニアリングチームが SQL Anywhere に追加機能を開発する場合に常に考慮している設計基準です。
今後も追加の自己（自動）管理テクニックを開発し、SQL Anywhere に実装していきます。SQL Anywhere の自己（自動）管理はパーフェクトの域には達していません。例えば、
グラフィカルなクエリー実行プランや
アプリケーションプロファイリングなどのパフォーマンス診断ツールを追加する必要があると考えています（注：最新のversion 17 ではすでに実装済です）。
SQL Anywhere の自己（自動）管理のテクノロジーの詳細については、
SQL Anywhere: A Holistic Approach to Database Self-management IEEE SMDB Workshop paper from 2007 を参照してください。
===2013年追記===
>例えば、ある商用 DBMS では一つのカラムヒストグラムのバケット数を特定しますが、それは本当に意味があるのでしょうか。実際のデータベースに格納されている値の分散をベースに、サーバーが自動的にバケットを増やしたり、減らしたりすべきではないでしょうか。
2008 年以降追加された SQL Anywhere の自己（自動）管理機能として、例えば SQL Anywhere 12 以降、上で Glenn が述べている統計的な問題に対処するため
統計ガバナー の機能がビルトインされました。
マニュアルの以下を参照ください。
http://dcx.sap.com/index.html#1201/ja/dbusage/ug-optimizer-statistics-governor.html
また動的ワークロードによりよく対応するためにサーバーの
ワーカースレッドの自動自己チューニングが実装されました。
こちらはマニュアルの以下を参照ください。
http://dcx.sap.com/index.html#1201/ja/dbadmin/running-s-3713576.html
===
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」
を入力してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。
