Firebird Documentation IndexFirebird 2.5 リリースノートFirebird APIとODSの変更 → API(アプリケーションプログラミングインタフェース)の拡張
Firebird Home Firebird Home Prev: Firebird APIとODSの変更Firebird Documentation IndexUp: Firebird APIとODSの変更Next: 予約語とその変更

API(アプリケーションプログラミングインタフェース)の拡張

APIの機能でBLOBの変換が可能に
接続文字列とキャラクタ・セット
SQLSTATEコードのサポート
効率的なアンプリペア
オペレーション関数のキャンセル
シャットダウン関数
ヘッダレベルの変更に対する制御の厳格化
アプリケーション用の新しいトレースサービス
リモート・バックアップファイルによるバックアップとリストア
オンラインでの検証サービスの実行
他のサービスAPIの追加
新しいトレースAPI

追加されたFirebird APIは、以下の通り―

APIの機能でBLOBの変換が可能に

A. dos Santos Fernandes

トラッカー・リファレンス CORE-3446

BLOBと他のデータタイプとの双方向の変換がAPIの機能で可能になりました(XSQLVARまたはblr messages)。

  • BLOBから異なるタイプのデータへ、また、異なるタイプからBLOBへのデータの移動が、executeおよびfetchの呼び出しで可能になりました。

  • 入力パラメータに関しては、パラメータに文字列を置くことができるので、クライアント側からBLOBの作成・記入を行う必要がありません。

  • 出力(executeまたはfetch)に関しては、アプリケーションがそのデータを理解し、BLOBを最長の文字列として評価するのに役立ちます。

接続文字列とキャラクタ・セット

A. dos Santos Fernandes

以前のバージョンは、OSやファイルシステムで使用されるキャラクタ・セットと連携する手段を持っていませんでした。Firebird 2.5は、データベースその他のファイルの名称や文字列パラメータがAPI接続要求を通じてアクセスされたとき、および/または、API接続要求に渡されたとき、その全体を見て、“環境に応じた認識”がを行うようになりました。この変更により、FirebirdがASCIIサブセット以外のキャラクタを含むファイル名や他のパラメータを受け付け、それらを使用する性能は大幅に改善されました。

この機能をサポートするのはDPB接続のみ

現在の実装では、この機能をサポートしているのはDPB(データベースパラメータブロック)を通じた接続だけです。サービスAPI(isc_spb*)の機能はサポートされていません。

isc_dpb_utf8_filename

新しい接続オプションisc_dpb_utf8_filenameが導入され、これにより、Firebirdは、渡されているファイル名や他のキャラクタ・アイテムがUTF8(UTF-8)キャラクタ・セットであることを具体的に知ることができるようになりました。このオプションが使われない場合、デフォルトのキャラクタ・セットとしてOSのコードページが選択されます。

クライアントとサーバー間の互換性
新しいクライアント、古いサーバー

バージョン2.5以降のクライアントで2.5より前のバージョンのリモート・サーバーに接続する場合、isc_dpb_utf8_filenameオプションを使用すると、クライアントは、ファイル名をサーバーへ渡す前に、これをUTF-8からクライアントのコードページへと変換します。isc_dpb_utf8_filenameオプションはDPBから削除されます。

クライアントとサーバーのステーション間で同じコードページが使われている時、互換性は保証されます。

新しいクライアント、新しいサーバー、isc_dpb_utf8_filenameオプションなし

バージョン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オプション使用

isc_dpb_utf8_filenameが使用している場合は、クライアントはファイル名を変更せずにサーバーに渡します。クライアントは常にUTF-8のファイル名をisc_dpb_utf8_filenameオプションとともにサーバーに渡します。

コードページの変換

Windowsでは、変換に使われるコードページはWindows ANSIです。他の全てのプラットフォームではUTF-8が用いられています。

ファイル名にOSのコードページやUTF-8を用いるのは、必ずしもベストな選択とは言えません。例えば、スクリプトや他のテキストファイルを別の接続キャラクタ・セットを用いたisqlなどのスクリプト実行ツールで処理する場合、複数のキャラクタ・セット(コードページ)を使用していると、ファイルを正しく編集できないことがあります。

解決策:Unicodeコードポイントを使用します。これにより、クライアントのバージョンが2.5より前の場合でも、キャラクタの正しい解釈が可能になります。

Unicodeコードポイントの使用

接続文字列のファイル名にある任意のUnicodeキャラクタはエンコードによりASCIIキャラクタとして擬装できるようになりました。これは、Unicodeコードポイント番号(U+XXXXの表記法に似たhexadecimal形式で記述)にプレフィックスとしてシンボル#を付すことで実現されます。

#XXXXのように標記します。Xは0-9、a-f、A-Fです。

キャラクタの一つがリテラルな#だった場合、“二重の”ハッシュ・キャラクタ(##)か、またはコードポイント番号#0023を使用します。

Note

クライアントがバージョン2.5より古い場合でも、サーバーでのハッシュ・キャラクタの解釈にはこれら新しいセマンティクスが使われます。

SQLSTATEコードのサポート

W. Oliver

D. Yemanov

トラッカー・リファレンス 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の非推奨化

SQLCODEは非推奨となっており、代わりにSQLSTATEを使用すべき所ですが、FirebirdではSQLCODEもこの先しばらく使うことができます。WHEN SQLCODEの例外処理のようなAPI関数isc_sqlcode()はまだサポートされています。

付録A:SQLSTATEには、このリリースで使用できるSQLSTATEコードのリストと対応するメッセージ・テキストが挙げられています。

効率的なアンプリペア

W. Oliver

D. Yemanov

トラッカー・リファレンス 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
        

オペレーション関数のキャンセル

Alex Peshkov

新しいAPI呼び出しfb_cancel_operation()を使うことで、所与の接続中に、ある種のブロッキングAPI呼び出しが実行している現在のアクションをキャンセルすることができます。

構文

   ISC_STATUS fb_cancel_operation(ISC_STATUS* status_vector,
                                  isc_db_handle* db_handle,
                                  ISC_USHORT option);
        

パラメータ

status vector (ISC_STATUS* status_vector)

通常のステータスベクター・ポインタ構造体です。

db_handle (pointer to a isc_db_handle)

通常の、有効なデータベースハンドルです。アタッチメントを特定します。

option (unsigned short: symbol)

実行されるアクションを確定します。オプション・シンボルは以下の通り:

  • 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_disablefb_cancel_enableリクエストのサイクルは、必要な頻度で繰り返すことができます。エンジンがすでにリクエストされた状態にある場合は、例外は発生しません:単に無視されます。

長時間にわたるリクエストを停止する必要がある場合、通常、fb_cancel_raiseが呼び出されます。これは非同期シグナルに対して安全ではないため、シグナルハンドラからではなく、個別のスレッドから呼び出されます。

このAPI呼び出しが非同期な特性を持つことに注意して下さい!

非同期な実行の別の側面として、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"
          

シャットダウン関数

Alex Peshkov

このリリースでは、エンベデッドサーバー・アプリケーションで有用となる二つのfb_shutdown*関数が公開されました::fb_shutdown()fb_shutdown_callbackです。

関連する二つのfb_shutdown* 関数

このリリースでは、埋め込みサーバー・アプリケーションで有用となる二つの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()

fb_shutdown()はさまざまなFirebirdサブシステム(yValve、エンジン、リダイレクタ)をスマートにシャットダウンさせます。これは主に内部エンジンが使うために設計されたもので、現在のプロセスにのみ適用できます。これはAPIによってエンベデッドサーバー環境でユーザーアプリケーションに利用していただくことが可能です。

今はエンベデッドエンジンでしか使えませんが、この関数は、現在の全ての活動を停止し、実行中のトランザクションをロールバックし、アクティブなアタッチメントを遮断し、エンベデッドエンジン・インスタンスを穏やかにシャットダウンします。

アプリケーション開発者向けの注意

fb_shutdown()は、アプリケーションが同時にアタッチされる可能性があるリモートサーバーのシャットダウンを実行しません。実際に、Firebirdの全てのクライアント・ライブラリ—エンベデッドサーバーを含む—は、最低一つでもデータベースまたはサービスにクライアントがアタッチされていれば、これをexit()で自動的に呼び出します。

従って、リモートのアタッチメントの文脈では、これがクライアントによって呼び出されることは決してありません。

パラメータ

fb_shutdown()は二つのパラメータを取ります:

  1. ミリ秒でのタイムアウト

  2. シャットダウンの理由

    理由コード(const int reason)は負の値を取りますが、ibase.hにリストが挙げられています: fb_shutrsnで始まる定数を参照して下さい。

    Note

    プログラムからfb_shutdown()を呼び出す際には正の値を渡す必要があります。これは、適切なアクションがコーディングされたコールバック関数ルーチンを通じて、fb_shutdown_callback()に引数として渡されます。

戻り値

  • 戻り値ゼロはシャットダウンの成功を意味します。

  • ゼロ以外の戻り値は、シャットダウン中に何らかのエラーが発生したことを意味します。詳細はfirebird.logに書き込まれます。

fb_shutdown_callback()

fb_shutdown_callback()はシャットダウン中に呼び出されるコールバック関数を設定します。この呼び出しはほとんどの場合正常終了の値を返しますが、メモリ不足の状態などでエラーが返されることもあります。

パラメータ

fb_shutdown_callback()は四つのパラメータを取ります:

status vector (ISC_STATUS* status_vector)

通常のステータスベクター・ポインタ構造体です。

pointer to callback function (FB_SHUTDOWN_CALLBACK callback_function)

これは、コールバックが発生した時に取るべきアクション(あるならば)を実行するため記述しておいたコールバック関数を参照します。

コールバック関数は三つのパラメータを取ることができます。第一と第二のパラメータはコールバックの際に取るべきアクションを決めるのに役立ちます:

  1. シャットダウンの理由

    シャットダウンの理由として二つのものが特に重要です:

    • fb_shutrsn_exit_called:exit()により、またはクライアント/エンベデッドライブラリがアンロードされることにより、Firebirdは終了します。

    • fb_shutrsn_signal、POSIXのみ適用:SIGINTまたはSIGTERMシグナルを受信した場合です。

    Note

    Firebirdは常に負の理由コードを使いますが、ユーザーがfb_shutdown()そのものを呼び出す際には正の値を使用することが求められます。

  2. 呼び出しに用いられるマスクの実際の値

    このパラメータの用途は、コールバックを呼び出すのをエンジンのシャットダウンの前にするか後にするかを決めるのに役立つということです。

  3. ユーザーアプリケーションによってfb_shutdown_callback()に渡される引数

    これは任意の目的で使用でき、NULLにすることもできます。

 

コールバック関数からの戻り値

コールバック関数がゼロを返した場合、これはジョブが正常に終了したことを意味します。ゼロ以外の戻り値は、コールマスク(下記のパラメータに関する項目を参照)に従って解釈されます:

  • fb_shut_postproviders呼び出しの場合、何らかのエラーが発生してfb_shutdown()からゼロ以外の値が返されていることを意味します。エラー状態が返された正確な理由の通知はコールバック関数が担うことになります。

  • fb_shut_preprovidersコールの場合、シャットダウンが実行されないことを意味します。

    Tip

    exit()が呼び出されてシャットダウンが実行される場合、ゼロ以外の値を返すのは良い考えではありません! ;-)

コールマスク(const int mask)

以下のシンボル記号値を持つことができます:

  • fb_shut_preproviders:コールバック関数はエンジンがシャットダウンされる前に呼び出されます

  • fb_shut_postproviders:コールバック関数はエンジンがシャットダウンされた後に呼び出されます

  • 両者を論理和で結合した場合は、シャットダウンの前後に同じ関数が呼び出されます

コールマスクの値

fb_shut_confirmation

エンジンが質問:みんなシャットダウンの準備はできているかい?

fb_shut_preproviders

プロバイダが終了する前に実行されるアクション

fb_shut_postproviders

プロバイダが終了した時に実行されるアクション

fb_shut_finish

最終的なクリーンアップ

fb_shut_confirmationfb_shut_preprovidersではないのですが)に対してゼロ以外の値が返されることは、シャットダウンが実行されないことを意味します。

引数(void* arg)

これは、コールバック関数に渡される引数です。

fb_shutdown関数の使い方

以下に挙げたのは、シャットダウンとシャットダウンのコールバック機能の使用サンプルです。これは、データベースのアタッチメントがある時に誰かが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 ...
}
            

シャットダウン用の新しいisc_spb_prp_*定数

新しいデータベースシャットダウンモードをサービスAPIへの呼び出しを使って設定できるようになりました。いくつかの新しいisc_spb_prp_*定数を引数として利用できます。

isc_spb_prp_shutdown_mode と isc_spb_prp_online_mode

これらの引数は、それぞれ、データベースをシャットダウンするためと、オンラインに戻すために使用します。いずれも、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バイトの整数パラメータを取り、リクエストされたシャットダウン操作のタイムアウトを指定します。

Note

古いスタイルのパラメータもサポートされており、デフォルトのシャットダウン(現在は'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
                
今度は完全なシャットダウンモードに入り、60秒間、新しいアタッチメントを無効にする:
  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
                

ヘッダレベルの変更に対する制御の厳格化

Alex Peshkov

危険な抜け穴を閉じることにより、いくつかの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以外による接続をリジェクトするようになりました。

アプリケーション用の新しいトレースサービス

Vlad Khorsun

新しいユーザートレース・セッションの管理に関係する五つの新しいサービスがサービスマネージャに追加されました。いずれも対応するサービスAPIアクション関数を伴っています。

isc_action_svc_trace_start

ユーザートレース・セッションを開始します。

Parameter(s)

  isc_spb_trc_name : トーレスセッション名、文字列、オプション
  isc_spb_trc_cfg  : トレースセッションの設定、文字列、必須
          

必須パラメータは適切な設定用テキストを含む文字列です。この文字列の内容についてのガイドとして、テンプレートファイルfbtrace.confがFirebirdのルートディレクトリ内に提供されています。

Note

  1. システム監査セッションとは違い、ユーザーセッションはファイルから設定を読み取ることはしません。クライアント側でローカルに設定を保存し、実行時に使用するためにそれらを取得する仕組みを考える責任はアプリケーション開発者が担うことになります。

  2. 文字列内に余分なホワイトスペースがあっても問題ありません:単に無視されるだけです。

出力

  • 操作の状態を伝えるテキストメッセージは、次のいずれかとなります:

      トレースセッションを開始できません。トレースのプラグインがロードされていません。
    
                  

    または、

      トレースセッションID NNNが開始されました。
                  
  • 第二の場合、トレースセッションの結果がテキスト形式で続けられます。

isc_action_svc_trace_stop

指定されたトレースセッションを停止します。

パラメータ

  isc_spb_trc_id : トレースセッションID、整数、必須
          

出力

リクエストの結果(状態)を通知するテキストメッセージ:

  • トレースセッションID NNNが停止されました。

  • 他のユーザートレース・セッションを停止する権限がありません。

  • トレースセッションID NNNが見つかりません。

isc_action_svc_trace_suspend

指定されたトレースセッションを中断します。

パラメータ

  isc_spb_trc_id : トレースセッションID、整数、必須
          

出力

リクエストの結果(状態)を通知するテキストメッセージ:

  • トレースセッションIDが中断されました。

  • 他のユーザートレース・セッションを変更する権限がありません。

  • トレースのセッションID NNNが見つかりません。

isc_action_svc_trace_resume

指定されたトレースセッションを中断から再開します。

パラメータ

  isc_spb_trc_id : トレースセッションID、整数、必須
          

出力

リクエストの結果(状態)を通知するテキストメッセージ:

  • トレースセッションID NNNが再開されました。

  • 他のユーザートレース・セッションを変更する権限がありません。

  • トレースセッションID NNNが見つかりません。

isc_action_svc_trace_list

既存のトレースセッションの一覧

パラメータなし

出力

トレースセッションとその状態を一覧するテキストメッセージです:

  • セッションID:<番号>

  • 名前:<文字列>。空でない場合、トレースセッション名を表示します

  • ユーザー:<文字列>。トレースセッションを作成したユーザーのユーザー名を表示します

  • 日付:YYYY-MM-DD HH:NN:SS、ユーザーセッションの開始日時

  • フラグ:<文字列>、以下のものの一部または全部を含むコンマ区切りのセット:

    active | suspend

    セッションの起動状態

    admin

    管理者ユーザーがセッションを作成した場合はadminを表示。通常のユーザーがセッションを作成した場合は表示せず。

    system

    セッションがFirebirdエンジンによって作成された場合(システム監査セッション)はsystemを表示。通常のユーザーがセッションを作成した場合は表示せず。

    audit | trace

    セッションの種類を示す:エンジンが作成した監査セッションの場合はaudit、ユーザートレース・セッションの場合はtrace

    log full

    ユーザートレース・セッションでセッションログファイルが満杯の場合に条件付きで表示。

Note

いずれのサービスの出力も、通常は、定期的なisc_service_query呼び出しをisc_info_svc_lineまたはisc_info_svc_to_eofのいずれかの情報アイテムと一緒に使うことで得ることができます。

リモート・バックアップファイルによるバックアップとリストア

Alex Peshkov

バージョン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
          

Note

バックアップ実行時に“詳細表示”(-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バイト値が続き、クライアントから受け取る用意のあるバイト数を表します。(ゼロ値は現在これ以上のデータが必要ないことを意味します)。

Important

クライアントはサーバーからリクエストされた以上のデータを送信してはいけません:エラー“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にゼロ以外の値を返します。

Tip

リモートバックアップ用のサービスAPIの使い方のサンプルについては、fbsvcmgrのソースコードを参照して下さい。

オンラインでの検証サービスの実行

Vlad Khorsun

データベースの検証はオンディスク構造体の整合性に関する低レベルでのチェックを可能にし、小さな破損を修正することもできます。データベースの健康をを保つためにDBAが定期的に検証を行うことは、特に重要なデータベースを扱う上で推奨される手続きです。

これにはデータベースへの排他的なアクセスが必要です:検証作業中はその他のアクセスは禁止されます。時には、特に巨大で複雑なデータベースの場合、ユーザーのアクセスを遮断することで大規模な停滞が起こることがあります。

オンライン検証は新しい機能です。これにより、整合性チェックを排他的アクセスなしで実行できるようになります。

オンライン検証でできること

  • データベースの一部の(または全部の)ユーザーテーブルを検証する。

    システムテーブルは検証されません。

  • 一部の(または全部の)インデックスを検証する。

ヘッダ\PIP\TIP\ジェネレータの各ページのような、他のODSのチェックは実行されません。

オンライン検証中の保護

テーブル(および/または、そのインデックス)の検証作業中でも、ユーザーのアタッチメントはそのテーブルの読み取りを行うことができます。データの変更(INSERT\UPDATE\DELETE)については、検証の終了まで待機させられるか、ユーザートランザクションのロックタイムアウトに従ってロックタイムアウト・エラーが返されるか、いずれかとなります。

検証作業中のテーブルまたはそのインデックスのガベージコレクションは実行できません:

  • バックグラウンドモード、協調モードでのガベージコレクションは単にこのテーブルをスキップします。

  • スイープはエラーを発生させて停止します。

テーブルのチェックを開始すると、オンライン検証はデータの変更を防止する二つのロックを取得します:

  • PR(読み取り保護)モードでのリレーション・ロック

  • (新機能)PW(書き込み保護)モードでのガベージコレクション・ロック

いずれのロックも、ユーザー指定のロックタイムアウトを使うことで取得されます。ロック・リクエストが失敗した場合はエラーが報告され、そのテーブルはスキップされます。

一度ロックが取得されると、テーブルとそのインデックスは、完全な検証を実行した場合と同じ方法で検証されます。これが完了して同じ手続きが次のテーブルへと移行すると、ロックは解除されます。

新しいサービスAPIアクション:isc_action_svc_validate

オンライン検証は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 :
		ロックタイムアウト、整数、オプション

出力:
	オンライン検証プロセスの進行状況を示すテキストメッセージ
           

isc_action_svc_validateの対話的な使用

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は無期限待機

使用上の注意

  • パターンは正規表現、SIMILAR TO式と同じルールで処理されます。
  • データベースのダイアレクトに関わりなく、全てのパターンで大文字小文字は区別されます。
  • テーブル用のパターンが省略された場合、全てのユーザーテーブルは検証されます。
  • インデックス用のパターンが省略された場合、指定されたテーブルの全てのインデックスが検証されます。
  • システムテーブルは検証されません。
  • テーブルまたはインデックスのリストを指定するには:

    1. パイプ・キャラクタ'|'で名前を区切ります。
    2. スペースを入れないこと:TAB1 | TAB2は誤りです。
    3. コマンド・インタープリタを混乱させないように、ダブルクォートでリスト全体を囲います。

  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
                   
  2. テーブルTAB1とTAB2と、その全てのインデックスを検証。ロック待機のタイムアウトは10秒(デフォルト):

    fbsvcmgr.exe service_mgr user SYSDBA password masterkey
    		action_validate dbname c:\db.fdb
    		val_tab_incl "TAB1|TAB2"
                   
  3. val_XXXオプションのデフォルトの挙動:データベース'c:\db.fdb'の全てのユーザーテーブルとそのインデックスを検証。ロック待機はデフォルトの10秒:

    fbsvcmgr.exe service_mgr user SYSDBA password masterkey
                   action_validate dbname c:\db.fdb
                   

他のサービスAPIの追加

Alex Peshkov

他に追加されたサービスAPIには以下のものが含まれます:

サービスAPIでのロールRDB$ADMINのマッピング

セキュリティ・データベースへのアクセスをリクエストする際に権限のあるOSユーザーのロールRDB$ADMINを有効または無効にするため、サービスパラメータブロック(SPB)に二つのタグアイテムが追加されました。

Note

この機能は、新しい-mappingスイッチによってgsecユーティリティに実装されました。コマンドライン・ユーティリティの章の関連する節の注意事項を参照して下さい。

タグアイテムisc_action_svc_set_mapping

security2.fdbにアクセスするためのサービス・リクエスト用に、指定されたOSユーザーに対しロールRDB$ADMINを有効にします。

タグアイテムisc_action_svc_drop_mapping

security2.fdbにアクセスするためのサービス・リクエスト用に、指定されたOSユーザーのロールRDB$ADMINを無効にします。

パラメータisc_spb_sec_admin

新しいパラメータisc_spb_sec_adminは、SYSDBAまたは他の十分な権限を持つユーザーがセキュリティ・データベース(security2.fdb)のロールRDB$ADMINを通常のユーザーに対して付与したり削除したりできるようにするために導入された新しいDDL構文のSPB実装です。通常のユーザーがセキュリティ・データベースでユーザーを作成、変更、削除するには、このロールでSYSDBAと同じ権限を手にする必要があります。

isc_spb_sec_adminspb_long型で、値として0(REVOKE ADMIN ROLEを意味する)またはゼロ以外の数字(GRANT ADMIN ROLEを意味する)を取ります。

詳細は、データ定義言語の章のCREATE/ALTER/DROP USERの項を参照して下さい。

タグアイテムisc_spb_bkp_no_triggers

この新しいSPBタグは、データベースレベルやトランザクションレベルでのトリガがバックアップ・リストアの最中に起動するのを防ぐため、バージョン2.1でgbakユーティリティに導入された-nodbtriggersスイッチのサービスAPIとしての側面を表すものです。これは、isc_spb_bkp_ignore_limboなどのアイテムを含むオプション命令のセットisc_spb_optionsの中での使用が意図されています。

タグアイテムisc_spb_res_metadata_only

トラッカー・リファレンス 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に定数として追加されました。

nBackupのサポート

サービス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ユーティリティで新しいパラメータの使う例をいくつか挙げています。便宜上、ロングインはすでに確立しているものと仮定しています。いずれの例もページ幅に合わせて改行していますが、実際には一行のコマンドです。

レベル0バッックアップを作成:
  fbsvcmgr service_mgr action_nbak dbname employee
    nbk_file e.nb0 nbk_level 0
                    
レベル1バッックアップを作成:
  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
                   
ダイレクトI/O機能のサポート

isc_spb_nbk_direct on|off

新しいタグにより、コマンドラインからnbackup -D on|offを呼び出すのと同じアクションが可能となり、ダイレクトI/Oの強制的なオン・オフが行えます。これは他のnbackup関連のタグと同様に、action_nbakでのみ有効です。

Note

この機能の使用法については、ユーティリティの章の新しいnbackupのスイッチについての注意事項を参照して下さい。

サービスAPIでのFIX_FSS_DATAおよびFIX_FSS_METADATAオプションが可能に

A. Peshkov

トラッカー・リファレンス 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_dataisc_spb_res_fix_fss_metadataです。

新しいトレースAPI

作成中の新しいトレースAPIは、トレースされる任意のイベント発生時にエンジンから呼び出される外部プラグインモジュールとして実装可能なフックのセットを提供します。これはまだドキュメント化されておらず、今後のサブリリースで変更されることもあります。

これについてのより詳しい情報は、管理機能の章のトレースのプラグイン機能の項を参照して下さい。

Prev: Firebird APIとODSの変更Firebird Documentation IndexUp: Firebird APIとODSの変更Next: 予約語とその変更
Firebird Documentation IndexFirebird 2.5 リリースノートFirebird APIとODSの変更 → API(アプリケーションプログラミングインタフェース)の拡張