Firebird Documentation Index → Firebird 2.5 リリースノート → Firebird APIとODSの変更 → API(アプリケーションプログラミングインタフェース)の拡張 |
追加されたFirebird APIは、以下の通り―
トラッカー・リファレンス CORE-3446
BLOBと他のデータタイプとの双方向の変換がAPIの機能で可能になりました(XSQLVARまたはblr messages)。
BLOBから異なるタイプのデータへ、また、異なるタイプからBLOBへのデータの移動が、executeおよびfetchの呼び出しで可能になりました。
入力パラメータに関しては、パラメータに文字列を置くことができるので、クライアント側からBLOBの作成・記入を行う必要がありません。
出力(executeまたはfetch)に関しては、アプリケーションがそのデータを理解し、BLOBを最長の文字列として評価するのに役立ちます。
以前のバージョンは、OSやファイルシステムで使用されるキャラクタ・セットと連携する手段を持っていませんでした。Firebird 2.5は、データベースその他のファイルの名称や文字列パラメータがAPI接続要求を通じてアクセスされたとき、および/または、API接続要求に渡されたとき、その全体を見て、“環境に応じた認識”がを行うようになりました。この変更により、FirebirdがASCIIサブセット以外のキャラクタを含むファイル名や他のパラメータを受け付け、それらを使用する性能は大幅に改善されました。
現在の実装では、この機能をサポートしているのはDPB(データベースパラメータブロック)を通じた接続だけです。サービスAPI(isc_spb*)の機能はサポートされていません。
新しい接続オプションisc_dpb_utf8_filenameが導入され、これにより、Firebirdは、渡されているファイル名や他のキャラクタ・アイテムがUTF8(UTF-8)キャラクタ・セットであることを具体的に知ることができるようになりました。このオプションが使われない場合、デフォルトのキャラクタ・セットとしてOSのコードページが選択されます。
バージョン2.5以降のクライアントで2.5より前のバージョンのリモート・サーバーに接続する場合、isc_dpb_utf8_filenameオプションを使用すると、クライアントは、ファイル名をサーバーへ渡す前に、これをUTF-8からクライアントのコードページへと変換します。isc_dpb_utf8_filenameオプションはDPBから削除されます。
クライアントとサーバーのステーション間で同じコードページが使われている時、互換性は保証されます。
バージョン2.5以降のクライアントで、isc_dpb_utf8_filenameオプションを使用せずに、バージョン2.5以降のリモートサーバーに接続する場合、クライアントはファイル名をOSのコードページからUTF-8へと変換し、isc_dpb_utf8_filenameオプションをDPBに挿入します。
サーバーが受け取ったファイル名には特別な処理は施されません。しかし、古いクライアントの場合と違い、バージョン2.5のクライアントは、ファイル名を自動で変換し、DPBにisc_dpb_utf8_filenameオプションを自動で挿入します。いずれにせよ、ホストとクライアントが同じコードページを用いている場合には、互換性は保証されます。
isc_dpb_utf8_filenameが使用している場合は、クライアントはファイル名を変更せずにサーバーに渡します。クライアントは常にUTF-8のファイル名をisc_dpb_utf8_filenameオプションとともにサーバーに渡します。
Windowsでは、変換に使われるコードページはWindows ANSIです。他の全てのプラットフォームではUTF-8が用いられています。
ファイル名にOSのコードページやUTF-8を用いるのは、必ずしもベストな選択とは言えません。例えば、スクリプトや他のテキストファイルを別の接続キャラクタ・セットを用いたisqlなどのスクリプト実行ツールで処理する場合、複数のキャラクタ・セット(コードページ)を使用していると、ファイルを正しく編集できないことがあります。
解決策:Unicodeコードポイントを使用します。これにより、クライアントのバージョンが2.5より前の場合でも、キャラクタの正しい解釈が可能になります。
接続文字列のファイル名にある任意のUnicodeキャラクタはエンコードによりASCIIキャラクタとして擬装できるようになりました。これは、Unicodeコードポイント番号(U+XXXXの表記法に似たhexadecimal形式で記述)にプレフィックスとしてシンボル#を付すことで実現されます。
#XXXXのように標記します。Xは0-9、a-f、A-Fです。
キャラクタの一つがリテラルな#だった場合、“二重の”ハッシュ・キャラクタ(##)か、またはコードポイント番号#0023を使用します。
クライアントがバージョン2.5より古い場合でも、サーバーでのハッシュ・キャラクタの解釈にはこれら新しいセマンティクスが使われます。
トラッカー・リファレンス CORE-1761
新しいクライアントサイドAPI関数fb_sqlstate()は、エラーのステータスベクター・アイテムをSQL-2003標準の英数5文字のSQLSTATEコードへと変換するために利用できます。
SQLSTATEコードはSQL CLASSの2文字とSQL SUBCLASSの3文字を連結したものを表現しています。
SQL文がSQLSTATEコードを返すようになりました。
isqlユーティリティがエラーについてSQLCODEではなくSQLSTATEの診断を表示するようになりました。
SQLCODEでの診断は非推奨となっています—将来のリリースで廃止されます。
(バージョン2.5.1)PSQLにWHEN SQLSTATE型の例外処理構文が追加されました。
SQLCODEは非推奨となっており、代わりにSQLSTATEを使用すべき所ですが、FirebirdではSQLCODEもこの先しばらく使うことができます。WHEN SQLCODEの例外処理のようなAPI関数isc_sqlcode()はまだサポートされています。
付録A:SQLSTATEには、このリリースで使用できるSQLSTATEコードのリストと対応するメッセージ・テキストが挙げられています。
トラッカー・リファレンス CORE-1741
APIルーチンisc_dsql_free_statement()の新たなオプションDSQL_unprepare(数値4)を使うと、DSQL文ハンドルはプリペアドステートメントを“アンプリペア”のままにしておくことができます。
従来のisc_dsql_free_statement()関数は、DSQL_close(名前付きカーソルを閉じる)とDSQL_drop(文ハンドルを解放する)のみサポートしていました。
追加されたAPIは次の通り:
#define DSQL_close 1 #define DSQL_drop 2 #define DSQL_unprepare 4
新しいAPI呼び出しfb_cancel_operation()を使うことで、所与の接続中に、ある種のブロッキングAPI呼び出しが実行している現在のアクションをキャンセルすることができます。
構文
ISC_STATUS fb_cancel_operation(ISC_STATUS* status_vector, isc_db_handle* db_handle, ISC_USHORT option);
パラメータ
通常のステータスベクター・ポインタ構造体です。
通常の、有効なデータベースハンドルです。アタッチメントを特定します。
実行されるアクションを確定します。オプション・シンボルは以下の通り:
fb_cancel_raise:第二のパラメータで指定されたdb_handleに関連する任意のアクションをキャンセルします。この効果として、できるだけ早い時点でエンジンが継続中のリクエストを止め、中断されたAPI呼び出しのステータスベクターを介して呼び出し元に例外を返せるようになります。
“できるだけ早い時点”とは、通常は、次の再スケジューリング・ポイントのことです。
例
Thread1: Thread2: ------------------------------ ------------------------------ isc_dsql_execute(status, ....) ........ fb_cancel_operation(cancel_status, ...) status[1] == isc_cancelled; cancel_status[1] = 0;
fb_cancel_disable:指定されたアタッチメントに関するfb_cancel_raiseリクエストの実行を無効にします。例えばcleanupなど、プログラムが重要なオペレーションを実行している時に役立つ可能性があります。
fb_cancel_enable:前に無効化されたキャンセル実行の通知を再び有効にします。'cancel'状態はデフォルトで有効であり、アタッチメントが作成された時に初期化されます。
fb_cancel_abort;クライアント側で接続を強制的に閉じます。接続をすぐに閉じる必要がある場合は役に立ちます。サーバーは実行中の全てのトランザクションをロールバックします。'Success'の場合は常にアプリケーションに返されます。注意して使用して下さい!
fb_cancel_disableとfb_cancel_enableリクエストのサイクルは、必要な頻度で繰り返すことができます。エンジンがすでにリクエストされた状態にある場合は、例外は発生しません:単に無視されます。
長時間にわたるリクエストを停止する必要がある場合、通常、fb_cancel_raiseが呼び出されます。これは非同期シグナルに対して安全ではないため、シグナルハンドラからではなく、個別のスレッドから呼び出されます。
非同期な実行の別の側面として、API呼び出しの終了時にアタッチメントの活動がキャンセルされることもあれば、されないこともあり得ます。後者の可能性は常にあります。また、非同期性により、返されるステータスベクターがほとんどの場合FB_SUCCESSを返すことになります。とはいえ、例外が発生することはあります:ネットワークパケット・エラーなど。
例
Thread A: fb_cancel_operation(isc_status, &DB, fb_cancel_enable); isc_dsql_execute_immediate(isc_status, &DB, &TR, 0, "long running statement", 3, NULL); // waits for API call to finish... Thread B: fb_cancel_operation(local_status, &DB, fb_cancel_raise); Thread A: if (isc_status[1]) isc_print_status(isc_status); // will print "operation was cancelled"
このリリースでは、エンベデッドサーバー・アプリケーションで有用となる二つのfb_shutdown*関数が公開されました::fb_shutdown()とfb_shutdown_callbackです。
このリリースでは、埋め込みサーバー・アプリケーションで有用となる二つのfb_shutdown*関数が公開されました::fb_shutdown()とfb_shutdown_callbackです。
プロトタイプ
typedef int (*FB_SHUTDOWN_CALLBACK)(const int reason, const int mask, void* arg); int fb_shutdown(unsigned int timeout, const int reason); ISC_STATUS fb_shutdown_callback(ISC_STATUS* status_vector, FB_SHUTDOWN_CALLBACK callback_function, const int mask, void* arg);
fb_shutdown()はさまざまなFirebirdサブシステム(yValve、エンジン、リダイレクタ)をスマートにシャットダウンさせます。これは主に内部エンジンが使うために設計されたもので、現在のプロセスにのみ適用できます。これはAPIによってエンベデッドサーバー環境でユーザーアプリケーションに利用していただくことが可能です。
今はエンベデッドエンジンでしか使えませんが、この関数は、現在の全ての活動を停止し、実行中のトランザクションをロールバックし、アクティブなアタッチメントを遮断し、エンベデッドエンジン・インスタンスを穏やかにシャットダウンします。
fb_shutdown()は、アプリケーションが同時にアタッチされる可能性があるリモートサーバーのシャットダウンを実行しません。実際に、Firebirdの全てのクライアント・ライブラリ—エンベデッドサーバーを含む—は、最低一つでもデータベースまたはサービスにクライアントがアタッチされていれば、これをexit()で自動的に呼び出します。
従って、リモートのアタッチメントの文脈では、これがクライアントによって呼び出されることは決してありません。
パラメータ
fb_shutdown()は二つのパラメータを取ります:
ミリ秒でのタイムアウト
シャットダウンの理由
理由コード(const int reason)は負の値を取りますが、ibase.h
にリストが挙げられています: fb_shutrsnで始まる定数を参照して下さい。
プログラムからfb_shutdown()を呼び出す際には正の値を渡す必要があります。これは、適切なアクションがコーディングされたコールバック関数ルーチンを通じて、fb_shutdown_callback()に引数として渡されます。
戻り値
戻り値ゼロはシャットダウンの成功を意味します。
ゼロ以外の戻り値は、シャットダウン中に何らかのエラーが発生したことを意味します。詳細はfirebird.log
に書き込まれます。
fb_shutdown_callback()はシャットダウン中に呼び出されるコールバック関数を設定します。この呼び出しはほとんどの場合正常終了の値を返しますが、メモリ不足の状態などでエラーが返されることもあります。
パラメータ
fb_shutdown_callback()は四つのパラメータを取ります:
通常のステータスベクター・ポインタ構造体です。
これは、コールバックが発生した時に取るべきアクション(あるならば)を実行するため記述しておいたコールバック関数を参照します。
コールバック関数は三つのパラメータを取ることができます。第一と第二のパラメータはコールバックの際に取るべきアクションを決めるのに役立ちます:
シャットダウンの理由
シャットダウンの理由として二つのものが特に重要です:
fb_shutrsn_exit_called:exit()により、またはクライアント/エンベデッドライブラリがアンロードされることにより、Firebirdは終了します。
fb_shutrsn_signal、POSIXのみ適用:SIGINTまたはSIGTERMシグナルを受信した場合です。
Firebirdは常に負の理由コードを使いますが、ユーザーがfb_shutdown()そのものを呼び出す際には正の値を使用することが求められます。
呼び出しに用いられるマスクの実際の値
このパラメータの用途は、コールバックを呼び出すのをエンジンのシャットダウンの前にするか後にするかを決めるのに役立つということです。
ユーザーアプリケーションによってfb_shutdown_callback()に渡される引数
これは任意の目的で使用でき、NULLにすることもできます。
コールバック関数からの戻り値
コールバック関数がゼロを返した場合、これはジョブが正常に終了したことを意味します。ゼロ以外の戻り値は、コールマスク(下記のパラメータに関する項目を参照)に従って解釈されます:
fb_shut_postproviders呼び出しの場合、何らかのエラーが発生してfb_shutdown()からゼロ以外の値が返されていることを意味します。エラー状態が返された正確な理由の通知はコールバック関数が担うことになります。
fb_shut_preprovidersコールの場合、シャットダウンが実行されないことを意味します。
exit()が呼び出されてシャットダウンが実行される場合、ゼロ以外の値を返すのは良い考えではありません! ;-)
以下のシンボル記号値を持つことができます:
fb_shut_preproviders:コールバック関数はエンジンがシャットダウンされる前に呼び出されます
fb_shut_postproviders:コールバック関数はエンジンがシャットダウンされた後に呼び出されます
両者を論理和で結合した場合は、シャットダウンの前後に同じ関数が呼び出されます
エンジンが質問:みんなシャットダウンの準備はできているかい?
プロバイダが終了する前に実行されるアクション
プロバイダが終了した時に実行されるアクション
最終的なクリーンアップ
fb_shut_confirmation(fb_shut_preprovidersではないのですが)に対してゼロ以外の値が返されることは、シャットダウンが実行されないことを意味します。
これは、コールバック関数に渡される引数です。
以下に挙げたのは、シャットダウンとシャットダウンのコールバック機能の使用サンプルです。これは、データベースのアタッチメントがある時に誰かがCtrl-Cを押すことでプログラムが終了されてしまうことを防ぐためのものです。
#include <ibase.h> // callback function for shutdown static int ignoreCtrlC(const int reason, const int, void*) { return reason == fb_shutrsn_signal ? 1 : 0; } int main(int argc, char *argv[]) { ISC_STATUS_ARRAY status; if (fb_shutdown_callback(status, ignoreCtrlC, fb_shut_confirmation, 0)) { isc_print_status(status); return 1; } // your code continues ... }
新しいデータベースシャットダウンモードをサービスAPIへの呼び出しを使って設定できるようになりました。いくつかの新しいisc_spb_prp_*定数を引数として利用できます。
これらの引数は、それぞれ、データベースをシャットダウンするためと、オンラインに戻すために使用します。いずれも、gfix -shutの設定と正確に一致する、新しいシャットダウンモードを設定するシングルバイト・パラメータをも持ちます:
isc_spb_prp_sm_normal
isc_spb_prp_sm_multi
isc_spb_prp_sm_single
isc_spb_prp_sm_full
シャットダウンのリクエストでは、シャットダウンのタイプも指定する必要があります。以下の中のいずれかとなります。
isc_spb_prp_force_shutdown
isc_spb_prp_attachments_shutdown
isc_spb_prp_transactions_shutdown
いずれも4バイトの整数パラメータを取り、リクエストされたシャットダウン操作のタイムアウトを指定します。
古いスタイルのパラメータもサポートされており、デフォルトのシャットダウン(現在は'multi')とオンライン('normal')モードに入るために使います。
使用例
以下に、fbsvcmgrユーティリティで新しいパラメータの使う例をいくつか挙げています。便宜上、ログインはすでに確立しているものと仮定しています。いずれの例もページ幅に合わせて改行していますが、実際には一行のコマンドです。
fbsvcmgr service_mgr action_properties dbname employee prp_shutdown_mode prp_sm_single prp_force_shutdown 0
fbsvcmgr service_mgr action_properties dbname employee prp_online_mode prp_sm_multi
fbsvcmgr service_mgr action_properties dbname employee prp_shutdown_mode prp_sm_full prp_attachments_shutdown 60
fbsvcmgr service_mgr action_properties dbname employee prp_online_mode prp_sm_normal
危険な抜け穴を閉じることにより、いくつかのDPBパラメータに通常のユーザーからアクセスできなくなりました。それらの設定は、管理者の制御下で実行されたのでなければ、場合によっては、データベースヘッダの設定を変更し、破損を起こす可能性があるものです;つまり、それらは、本来ならSYSDBAに限定される操作を開始してしまうのです。すなわち─
isc_dpb_shutdown and isc_dpb_online
isc_dpb_gbak_attach, isc_dpb_gfix_attach と isc_dpb_gstat_attach
isc_dpb_verify
isc_dpb_no_db_triggers
isc_dpb_set_db_sql_dialect
isc_dpb_sweep_interval
isc_dpb_force_write
isc_dpb_no_reserve
isc_dpb_set_db_readonly
isc_dpb_set_page_buffers (スーパーサーバーで)
クラシックサーバーでは、パラメータisc_dpb_set_page_buffers
は、今でも通常のユーザーが使用できるようになっています。そのユーザーはそのセッションでのみ、一時的にバッファサイズを設定することができます。スーパーサーバーまたはクラシックサーバーでSYSDBAがこれを使用した場合は、データベースヘッダ内のバッファカウントが変更されます。つまり、デフォルトのバッファサイズは恒久的に変更されることになります。
この変更は、リストに挙げられたDPBパラメータで明示的に設定されたもののいずれかに影響します。これは、デフォルトプロパティの値によるDPB実装にそれらを含める、または、通常のユーザーとしてデータベースにアクセスするツールやアプリケーションでそれらを有効にする、いずれの方法で設定した場合も当てはまります。例えば、データベースのParamsプロパティに'RESERVE PAGE SPACE=TRUE'や'FORCED WRITES=TRUE'を含むDelphiアプリケーションで、Firebird 1.x、2.0.1、2.0.3、2.0.4また2.1.0/2.1.1に接続した場合には問題を起こさなかったものが、ISC ERROR CODE 335544788、“Unable to perform operation. You must be either SYSDBA or owner of the database.(操作を実行できません。あなたはSYSDBAまたはデータベースの所有者でなければなりません。)”のメッセージを出してSYSDBA以外による接続をリジェクトするようになりました。
新しいユーザートレース・セッションの管理に関係する五つの新しいサービスがサービスマネージャに追加されました。いずれも対応するサービスAPIアクション関数を伴っています。
ユーザートレース・セッションを開始します。
Parameter(s)
isc_spb_trc_name : トーレスセッション名、文字列、オプション isc_spb_trc_cfg : トレースセッションの設定、文字列、必須
必須パラメータは適切な設定用テキストを含む文字列です。この文字列の内容についてのガイドとして、テンプレートファイルfbtrace.conf
がFirebirdのルートディレクトリ内に提供されています。
システム監査セッションとは違い、ユーザーセッションはファイルから設定を読み取ることはしません。クライアント側でローカルに設定を保存し、実行時に使用するためにそれらを取得する仕組みを考える責任はアプリケーション開発者が担うことになります。
文字列内に余分なホワイトスペースがあっても問題ありません:単に無視されるだけです。
出力
操作の状態を伝えるテキストメッセージは、次のいずれかとなります:
トレースセッションを開始できません。トレースのプラグインがロードされていません。
または、
トレースセッションID NNNが開始されました。
第二の場合、トレースセッションの結果がテキスト形式で続けられます。
指定されたトレースセッションを停止します。
パラメータ
isc_spb_trc_id : トレースセッションID、整数、必須
出力
リクエストの結果(状態)を通知するテキストメッセージ:
トレースセッションID NNNが停止されました。
他のユーザートレース・セッションを停止する権限がありません。
トレースセッションID NNNが見つかりません。
指定されたトレースセッションを中断します。
パラメータ
isc_spb_trc_id : トレースセッションID、整数、必須
出力
リクエストの結果(状態)を通知するテキストメッセージ:
トレースセッションIDが中断されました。
他のユーザートレース・セッションを変更する権限がありません。
トレースのセッションID NNNが見つかりません。
指定されたトレースセッションを中断から再開します。
パラメータ
isc_spb_trc_id : トレースセッションID、整数、必須
出力
リクエストの結果(状態)を通知するテキストメッセージ:
トレースセッションID NNNが再開されました。
他のユーザートレース・セッションを変更する権限がありません。
トレースセッションID NNNが見つかりません。
既存のトレースセッションの一覧
パラメータなし
出力
トレースセッションとその状態を一覧するテキストメッセージです:
セッションID:<番号>
名前:<文字列>。空でない場合、トレースセッション名を表示します
ユーザー:<文字列>。トレースセッションを作成したユーザーのユーザー名を表示します
日付:YYYY-MM-DD HH:NN:SS、ユーザーセッションの開始日時
フラグ:<文字列>、以下のものの一部または全部を含むコンマ区切りのセット:
セッションの起動状態
管理者ユーザーがセッションを作成した場合はadminを表示。通常のユーザーがセッションを作成した場合は表示せず。
セッションがFirebirdエンジンによって作成された場合(システム監査セッション)はsystemを表示。通常のユーザーがセッションを作成した場合は表示せず。
セッションの種類を示す:エンジンが作成した監査セッションの場合はaudit、ユーザートレース・セッションの場合はtrace。
ユーザートレース・セッションでセッションログファイルが満杯の場合に条件付きで表示。
いずれのサービスの出力も、通常は、定期的なisc_service_query呼び出しをisc_info_svc_lineまたはisc_info_svc_to_eofのいずれかの情報アイテムと一緒に使うことで得ることができます。
バージョン2.5.2では、サーバー側でgbakを起動し、リモートのクライアントに置かれたgbakバックアップファイルから読み取る、またはそれに書き込む機能が導入されました。これはインターネット接続を介したバックアップ/リストアの方法として非常に効果的です。
この機能を使う最も簡単な方法は、コマンドラインツールfbsvcmgrを利用することです。これはサービスAPI呼び出し用のインターフェースをとりあえず提供してくれるので、クライアントアプリケーションを自分で書かずに済みます。
fbsvcmgrを使ってリモートのデータベースをバックアップするには、次のパターンでコマンドを入力します:
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX \ action_backup -dbname some.fdb -bkp_file stdout >some.fbk
fbsvcmgrを使ってリモートに置かれたバックアップファイルからデータベースをリストアするには、次のパターンでコマンドを入力します。
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX \ action_restore -dbname some.fdb -bkp_file stdin <some.fbk
バックアップ実行時に“詳細表示”(-v[erify])スイッチは使えません。これは、サーバーからクライアントへのデータチャンネルが、バックアップファイルからデータのブロックを転送するのに使われているためです。
データベースのリストア時には制限がなく、詳細表示モードが使えます。
リモートバックアップ/リストアを独自のプログラムで実行したい場合は、サービスAPIを利用して下さい。
バックアップは非常に単純です─isc_info_svc_to_eof
のタグを付したisc_service_query()
への呼び出しを繰り返すことで返されたデータがバックアップファイルのイメージを表すストリームとなります。isc_service_query()
呼び出しでisc_info_svc_to_eof
タグを使い、バックアップファイル名としてサーバーに“stdout”を渡して下さい。
リストアはやや複雑になります。クライアントはisc_service_query()
呼び出しでサーバーに新しいspbパラメータisc_info_svc_stdin
を送信します。サービスは、stdinのデータが必要な場合、クエリの結果としてisc_info_svc_stdin
を返します。これには4バイト値が続き、クライアントから受け取る用意のあるバイト数を表します。(ゼロ値は現在これ以上のデータが必要ないことを意味します)。
クライアントはサーバーからリクエストされた以上のデータを送信してはいけません:エラー“Size of data is more than requested”がスローされます。
データは次のisc_service_query()
呼び出しで、従来のisc_info_svc_line
タグの形式を使い、send_items
ブロックで送信されます:isc_info_svc_lineは2バイト長のデータです。次の部分が必要になると、サーバーは逆にisc_service_query()
からisc_info_svc_stdin
にゼロ以外の値を返します。
リモートバックアップ用のサービスAPIの使い方のサンプルについては、fbsvcmgrのソースコードを参照して下さい。
データベースの検証はオンディスク構造体の整合性に関する低レベルでのチェックを可能にし、小さな破損を修正することもできます。データベースの健康をを保つためにDBAが定期的に検証を行うことは、特に重要なデータベースを扱う上で推奨される手続きです。
これにはデータベースへの排他的なアクセスが必要です:検証作業中はその他のアクセスは禁止されます。時には、特に巨大で複雑なデータベースの場合、ユーザーのアクセスを遮断することで大規模な停滞が起こることがあります。
オンライン検証は新しい機能です。これにより、整合性チェックを排他的アクセスなしで実行できるようになります。
データベースの一部の(または全部の)ユーザーテーブルを検証する。
システムテーブルは検証されません。
一部の(または全部の)インデックスを検証する。
ヘッダ\PIP\TIP\ジェネレータの各ページのような、他のODSのチェックは実行されません。
テーブル(および/または、そのインデックス)の検証作業中でも、ユーザーのアタッチメントはそのテーブルの読み取りを行うことができます。データの変更(INSERT\UPDATE\DELETE)については、検証の終了まで待機させられるか、ユーザートランザクションのロックタイムアウトに従ってロックタイムアウト・エラーが返されるか、いずれかとなります。
検証作業中のテーブルまたはそのインデックスのガベージコレクションは実行できません:
バックグラウンドモード、協調モードでのガベージコレクションは単にこのテーブルをスキップします。
スイープはエラーを発生させて停止します。
テーブルのチェックを開始すると、オンライン検証はデータの変更を防止する二つのロックを取得します:
PR(読み取り保護)モードでのリレーション・ロック
(新機能)PW(書き込み保護)モードでのガベージコレクション・ロック
いずれのロックも、ユーザー指定のロックタイムアウトを使うことで取得されます。ロック・リクエストが失敗した場合はエラーが報告され、そのテーブルはスキップされます。
一度ロックが取得されると、テーブルとそのインデックスは、完全な検証を実行した場合と同じ方法で検証されます。これが完了して同じ手続きが次のテーブルへと移行すると、ロックは解除されます。
オンライン検証はFirebirdサービスとして実装されており、サービスAPIを通じてアクセスできます。そのため、これをgfixから起動することはできません。
この呼び出しは以下の要素を含みます:
アクション: isc_action_svc_validate パラメータ: isc_spb_dbname : データベースファイル名、文字列、必須 isc_spb_val_tab_incl, isc_spb_val_tab_excl, isc_spb_val_idx_incl, isc_spb_val_idx_excl : テーブル\インデックス名のパターン、文字列、オプション isc_spb_val_lock_timeout : ロックタイムアウト、整数、オプション 出力: オンライン検証プロセスの進行状況を示すテキストメッセージ
fbsvcmgrユーティリティは、この新しいサービスを完全にサポートしています。構文は次の通り:
fbsvcmgr [host:]service_mgr [user <...>] [password <...>] action_validate dbname <ファイル名> [val_tab_incl <パターン>] [val_tab_excl <パターン>] [val_idx_incl <パターン>] [val_idx_excl <パターン>] [val_lock_timeout <番号>]
このうち、
val_tab_incl | 検証の実行に含めるテーブル名のパターン |
val_tab_excl | 検証の実行から除外するテーブル名のパターン |
val_idx_incl | 検証の実行に含めるインデックス名のパターン。デフォルトは%、すなわち全インデックス |
val_idx_excl | 検証の実行から除外するインデックス名のパターン |
val_lock_timeout | ロックタイムアウト、検証するテーブルのロックの取得に使用される、秒単位、デフォルトは10秒、0は待機なし、-1は無期限待機 |
テーブルまたはインデックスのリストを指定するには:
例
データベース'c:\db.fdb'の、名前が'A'で始まる全てのテーブルを検証。インデックスは検証しない。ロックの待機は実行しない。
fbsvcmgr.exe service_mgr user SYSDBA password masterkey action_validate dbname c:\db.fdb val_tab_incl A% val_idx_excl % val_lock_timeout 0
テーブルTAB1とTAB2と、その全てのインデックスを検証。ロック待機のタイムアウトは10秒(デフォルト):
fbsvcmgr.exe service_mgr user SYSDBA password masterkey action_validate dbname c:\db.fdb val_tab_incl "TAB1|TAB2"
val_XXXオプションのデフォルトの挙動:データベース'c:\db.fdb'の全てのユーザーテーブルとそのインデックスを検証。ロック待機はデフォルトの10秒:
fbsvcmgr.exe service_mgr user SYSDBA password masterkey action_validate dbname c:\db.fdb
他に追加されたサービスAPIには以下のものが含まれます:
セキュリティ・データベースへのアクセスをリクエストする際に権限のあるOSユーザーのロールRDB$ADMINを有効または無効にするため、サービスパラメータブロック(SPB)に二つのタグアイテムが追加されました。
この機能は、新しい-mappingスイッチによってgsecユーティリティに実装されました。コマンドライン・ユーティリティの章の関連する節の注意事項を参照して下さい。
security2.fdbにアクセスするためのサービス・リクエスト用に、指定されたOSユーザーに対しロールRDB$ADMINを有効にします。
新しいパラメータisc_spb_sec_adminは、SYSDBAまたは他の十分な権限を持つユーザーがセキュリティ・データベース(security2.fdb)のロールRDB$ADMINを通常のユーザーに対して付与したり削除したりできるようにするために導入された新しいDDL構文のSPB実装です。通常のユーザーがセキュリティ・データベースでユーザーを作成、変更、削除するには、このロールでSYSDBAと同じ権限を手にする必要があります。
isc_spb_sec_adminはspb_long型で、値として0(REVOKE ADMIN ROLEを意味する)またはゼロ以外の数字(GRANT ADMIN ROLEを意味する)を取ります。
詳細は、データ定義言語の章のCREATE/ALTER/DROP USERの項を参照して下さい。
この新しいSPBタグは、データベースレベルやトランザクションレベルでのトリガがバックアップ・リストアの最中に起動するのを防ぐため、バージョン2.1でgbakユーティリティに導入された-nodbtriggersスイッチのサービスAPIとしての側面を表すものです。これは、isc_spb_bkp_ignore_limboなどのアイテムを含むオプション命令のセットisc_spb_optionsの中での使用が意図されています。
トラッカー・リファレンス CORE-3462
SPB中のリストアサービス・オプションにisc_spb_bkp_metadata_onlyタグを渡すと、metadata-onlyリストアが実行されます。Firebirdのfbsvcmgrを含む多くのツールでは、リストアのリクエストにバックアップ・オプションを指定することはできません。
(バージョン2.5.1)混乱を避けるため、単にisc_spb_bkp_metadata_onlyを再実装しただけのタグisc_spb_res_metadata_onlyがパブリックヘッダとfbsvcmgrに定数として追加されました。
サービスAPIでnBackupアクションをサポートするために三つのものが追加されました。
トラッカー・リファレンス CORE-1758
nBackupユーティリティは二つの論理グループの操作を実行します:データベースのロックとロック解除、そして、バックアップとリストアです。そのうち、ロック/ロック解除の操作にサービスアクションを提供する正当な理由はありません—SQL言語でALTER DATABASEのリクエストを使うことでリモートからのそれらのリクエストは可能です—一方で、バックアップ/リストア操作用のサービスAPIのインターフェースを正当化するのは簡単です。
バックアップとリストアはホストのステーションで実行する必要があります。それらにアクセスする唯一の方法は、nBackupを起動することでした。
以下の二つの新しいサービスアクションによって、サービスAPIを通じてnBackupによるバックアップとリストアをリクエストできるようになりました:
isc_action_svc_nbak - 増分バックアップ
isc_action_svc_nrest - 増分データベースリストア
パラメータ・アイテムは、以下の通り:
isc_spb_nbk_level - バックアップレベル(整数)
isc_spb_nbk_file - バックアップファイル名(文字列)
isc_spb_nbk_no_triggers - データベーストリガを抑制するためのオプション
使用例
以下に、fbsvcmgrユーティリティで新しいパラメータの使う例をいくつか挙げています。便宜上、ロングインはすでに確立しているものと仮定しています。いずれの例もページ幅に合わせて改行していますが、実際には一行のコマンドです。
fbsvcmgr service_mgr action_nbak dbname employee nbk_file e.nb0 nbk_level 0
fbsvcmgr service_mgr action_nbak dbname employee nbk_file e.nb1 nbk_level 1
fbsvcmgr service_mgr action_nrest dbname e.fdb nbk_file e.nb0 nbk_file e.nb1
isc_spb_nbk_direct on|off
新しいタグにより、コマンドラインからnbackup -D on|offを呼び出すのと同じアクションが可能となり、ダイレクトI/Oの強制的なオン・オフが行えます。これは他のnbackup関連のタグと同様に、action_nbakでのみ有効です。
この機能の使用法については、ユーティリティの章の新しいnbackupのスイッチについての注意事項を参照して下さい。
トラッカー・リファレンス CORE-2439
Firebird 2.1でgbak -restoreスイッチに実装されたFIX_FSS_DATAとFIX_FSS_METADATA関数はコアエンジンに実装され、サービスAPIのisc_action_svc_restore構造体に対応するタグ定数として公開されています。従って、開発者には、古いFirebirdデータベースから新しいオンディスク構造体への移行を自動化するアプリケーションを書く道が開かれています。
新しいSPBタグはisc_spb_res_fix_fss_dataとisc_spb_res_fix_fss_metadataです。
作成中の新しいトレースAPIは、トレースされる任意のイベント発生時にエンジンから呼び出される外部プラグインモジュールとして実装可能なフックのセットを提供します。これはまだドキュメント化されておらず、今後のサブリリースで変更されることもあります。
これについてのより詳しい情報は、管理機能の章のトレースのプラグイン機能の項を参照して下さい。
Firebird Documentation Index → Firebird 2.5 リリースノート → Firebird APIとODSの変更 → API(アプリケーションプログラミングインタフェース)の拡張 |