このページは、以下の英語ページの抄訳です。最新の情報については、
英語ページを参照してください。
最近リリースされた SQL Anywhere 17 には、様々な側面からのパフォーマンスの強化、データベースサーバーやクライアントのセキュリティや堅牢性強化のための幅広い新機能、そして開発生産性向上のための新たなツールが含まれています。バージョン17の概要については
こちらをご参照ください。
これから、version 17の変更のメリットをお客様に活用していただくため、いくつかの機能をピックアップして、以前のバージョンと詳細に比較分析した結果について掲載していきたいと思います。
新しいバージョンにおける変更点や改善点にハイライトをあてつつ、それについて可能であればベストプラクティスを提供するつもりです。
最初に選択したトピックは、
autocommit です。
Auto-commit は、トランザクションで commit が発行された場合に適用されるデータベースクライアント接続オプションです。SQL Anywhere におけるベストプラクティスとしては、auto-commit は可能であればどこも無効にすることをお奨めします。なぜならば、commit のオペレーションには、IOが発生するからです。
IO は、一般的な RDBMS において最も expensive なものです。一般的には、auto-commit を使わない方が、commit の数は少なくなり、データベースサーバーのパフォーマンスは、より高速になります。さらに、ビジネスプロセスと同調するトランザクションを作成・管理することで、commit が発生した時もコントロールしやすく、ビジネスルールとも連動する、より一貫性のあるデータベースにすることができます。
auto-commit を使用しない方が望ましいにもかかわらず、多くのアプリケーションは実際 auto-commit を有効にして構築されています。これには理由がいくつかあります。オペレーションごとに commit する方が簡単であることが多かったり、データベースの変更が成功しているかどうかすぐにフィードバックを得られる方が開発者にとっては魅力的だからです。さらに、多くのデータベースインターフェースでは、デフォルトでは auto-commit が有効になっているため、アプリケーション開発者はデフォルトでは auto-commit のアプリケーションを開発しています。
しかしながら、アプリケーションが一旦構築されてしまうと、明示的な commit を行うようにアプリケーションを再構築するのは非常に困難であることがよくあります。
version 17 より前のバージョンの SQL Anywhere では、アプリケーションで auto-commit がONになっている場合、クライアントのAPI (例えば ODBC, JDBC, etc…) は、データベースのリクエストごとに、明示的な “COMMIT” を発行していました。
version 17 では、このサーバーとの余計なコミュニケーションを避け、全体パフォーマンスを改善するために (驚くなかれ!) auto_commit という新しいオプションが追加されました。
このオプションは、デフォルトでは OFF になっており、接続が継続している間のみローカルで設定できます (つまり、PUBLIC auto_commit オプションは設定できません)。アプリケーションが auto_commit オプションを ON に設定した場合には、SQL Anywhere サーバーが、リクエストごとに、自動的に commit します。
また、この新しいオプションのメリットを自動的に享受できるよう、全ての SQL Anywhere クライアントインターフェースを更新しました。
version 17 の SQL Anywhere ODBC、 JDBC、OLEDB ドライバーは、version 17 サーバーに接続した場合、アプリケーションが相応する AutoCommit API コールをそれぞれのドライバーに対して発行した時に、自動的に新しい auto_commit オプションを設定します。
ターゲットサーバーが version 16 以前のものの場合には、これらのドライバーは、クライアントサイドに auto commit をハンドリングするよう戻します。
(例えばESQL のような) 以前は autocommit がサポートされていなかった API でも、これらのアプリケーションで新しい auto_commit オプションを使用して、必要であればそれぞれの実行ごとにサーバーに自動的に commit させることができます。
パフォーマンス
以下の例は、リクエストごとにサーバーが auto commit することを示しています。
SET TEMPORARY OPTION auto_commit = ‘ON’
このオプションのパフォーマンスへのインパクトをみるために、SQL Anywhere に同梱されている PerformanceInsert サンプルを使用して単純なテストを実行してみました。私のノートPCで、単一の integer primary key のテーブルを使用し、100000行挿入してました。
CREATE TABLE ins( c1 integer NOT NULL PRIMARY KEY );
最初に、1 commit (テストの最後に) でテストしてみました。:
instest -cdba,sql -o ins.out -r 100000 -x -v 1
2番目のテストでは、ローごとに commit しました。
instest -cdba,sql -o ins.out -r 100000 -x -v 1 -m 1
3番目のテストでは、ソースコードを instest に変更し、データベース接続後に auto_commit を ON にするコマンドを追加しました。
EXEC SQL EXECUTE IMMEDIATE 'SET TEMPORARY OPTION auto_commit=ON';
…そして、明示的な commit なしにテストを実行しました。
instest -cdba,sql -o ins.out -r 100000 -x -v 1
結果は以下のとおりです。
ご覧のとおり、オペレーションごとに commit しないことで、パフォーマンスには大きなインパクトがあります。
しかしながら、アプリケーションが、同じマシンの接続ごしに、auto_commit を使用する場合、このテストでは、クライアントにオペレーションごとに commit を発行させるのと、サーバーにオペレーションごとに自動的に commit させるのとでは、パフォーマンスにおいて ~13% の違いを示しました。
ネットワークサーバーと TCPIP を使用する場合、この違いはさらに明白で、パフォーマンスにおいて、~17% の違いを示しました。 (下の表参照)
*サーバーが commmit のオペレーションを実行しているので、intest プログラムは commit とインサートの実行時間を分けることができません。
ラボで行った他のシナリオのテストでは(より多くの負荷アクティビティをミックス）、クライアントベースの auto_commit オペレーションに対して、サーバーサイドの auto_commit オペレーションが使用されている場合、commit オペレーションのパフォーマンスにおいて 25-30% もの改善を示しました。
最後に - Chained vs. Autocommit
auto_commit オプションは、データベースの chained オプションとは大きく異なります。
chained=OFF に設定すると、サーバーに対して、1つのプロシージャー内の個々のステート文を
含め、それぞれのステートメント文がサーバーで実行された後に、commitするよう強制します。
それに対して、auto_commit を ON に設定すると、サーバーはクライアントからのそれぞれのステートメント文の実行ごとにのみ commitするよう強制されます。プロシージャーの場合には、 auto_commit が ON の場合、
全てのプロシージャーが実行完了した後に、commit が行われます。
===
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」
を入力してください。
不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。
======================
ご購入に関するお問い合わせ
こちらよりお問い合わせください。
