| Firebird Documentation Index → Firebird 2.5 リリースノート → Firebirdエンジンの変更 → 改善点 |
|
|
|
実装された改善点は以下の通り：
クラシックサーバーが、クライアントの切断によって壊れたサーバーのプロセスを、すぐに検出できるようになりました。これに対し、未完了の活動を終了させたり、アクティブなトランザクションをロールバックしたり、ネットワークの接続を閉じたりといった対応をします。
トラッカー・リファレンス CORE-818
重要な最適化は以下の通り：
最適化により、どのフィールドもアクセスされていないテーブルについて、データ取得のパフォーマンスが改善されました。これは、例えば、SELECT COUNT(*)型のクエリに適用されます。
トラッカー・リファレンス CORE-1598
この改善の狙いは、“careful write”による更新手続きの際にエンジンが優先的に行う書き込みの量を減らすことでした。従来の手続きでは、大規模な更新、特に同一のトランザクションで同一のレコードへの複数回の更新を行う“updates-in-place”のパフォーマンスに目立った影響が出ていました。最悪の場合には、更新の際に生成された全ての単一の新しいレコードのバージョンのために、ディスクにページが書き込まれることもありました。
内部で何が起きているのかについての簡単な技術的解説は、トラッカー・リファレンス (CORE-2672)を参照して下さい。
この解決策では、正しい優先順位を維持するためレコードの新バージョンと旧バージョンとが置かれたページ間で起きる循環参照から、書き込み操作を保護することに関わるプロセスで多大な時間を要する可能性があったという事態に対処しています。
トラッカー・リファレンス CORE-1687
以前の64bit版Firebirdサーバーでは、64bitアドレス空間の恩恵が受けられず、データベースのキャッシュを2GB（16K * 128K）以上に設定することができませんでした。この問題は今回のバージョンで修正されました。64bit版Firebirdでは、リソースが利用可能な場合、RAM内に5〜10GBのデータベースに完全に対応できる十分な大きさのキャッシュを設定することが可能になりました。
Firebirdのキャッシングは、ファイルシステムのキャッシュから多くの恩恵を受けることができますが、このことは、主に読み取りに負荷がかかる高スループット・システムにとって、おそらく重要な機能となっています。x64版Firebirdサーバーでのキャッシュの理論上の上限は2^31 -1（2,147,483,647）ページとなっています。
トラッカー・リファレンス CORE-1643
設定パラメータDatabaseAccessに、さらに多くの“意味”が付け加えられました。特に指定がない場合、エンジンは、“Restrict”リスト内のDatabaseAccessで最初に登録された配置場所を、新規にデータベースを作成する際や、接続パラメータによってエイリアスもフルパスも指定されていないデータベースを見つけるための、デフォルトの配置として受け取ります。
この探索ロジックは、RestrictリストからExternalFileAccessパラメータに渡されて、外部テーブルを見つけるために使われるのと同様のものです。すなわち、
Restrctリスト内の全てのディレクトリが最初に探索されます。
指定されたデータベースが見つからない場合：
CREATE DATABASEが含まれる場合、Restrictリスト内の最初の配置場所が使われます。
そうでない場合、アタッチは期待通りには行なわれません。
この機能は、直接ローカル接続するために指定されたデータベース・ファイルの暗黙の配置場所として現在の作業ディレクトリを使用することを禁ずるものではありません。これらの場合には、従来とまったく同様に、Y-valveがパス解決を処理します。
データベースがどこに“ある”のか確かめる方法がないからといって、リモート・サブシステムを介して稼働中のスタンドアロンのサーバーが、パスの記述がないデータベース・ファイル名を使って接続しようとするというのは、まずありえない状況ですが、推奨されません。例えば、Windows版では、こうした状況での現在の作業ディレクトリは%system%となります。
アプリケーション構成のインストール時に、いわゆる“DLL地獄”に陥った場合に共通して起こる問題を避けるため、Windows版エンベデッドエンジン向けのルート決定メカニズムが変更されました。以前には、ユーザーアプリケーションのメインの実行ファイルを含むディレクトリが暗黙のルートディレクトリとなっていました。今後は、リネームされたfbembed.dllライブラリが置かれているディレクトリとなります。
トラッカー・リファレンス CORE-1814
Firebirdの以前のバージョンでは、外部テーブルを使用する際に32bit I/Oを使っていたため、外部ファイルのサイズは2GB未満に制限されていましたが、64bit I/Oがサポートされるファイルシステム上では、外部テーブルメカニズムがこれを利用するよう拡張されたことで、2GBの制限は事実上撤廃されました。
トラッカー・リファレンス CORE-2492
トラッカー・リファレンス CORE-2619
Firebirdの以前のバージョンでは、メモリその他の統計が64bit値を適切に処理していませんでした。このイシューには二つの要素があります：
エンジンが統計に64bit整数を使えるように、AtomicCounterの内部が変更されました。
isqlおよびqliのツールを64bit値に見合った動作をするよう改良する必要がありました。
32bitのツールが64bitのサーバーで正しく動作するため、いくつかの新しい内部API機能（struct perf64やperf64_xxx）を導入し、またそれらを使用するisqlやqliを変更する必要がありました。このことは、バージョン2.5のisqlとqliのプログラムが古いFirebirdクライアントとの互換性を持たないことを意味します。
トラッカー・リファレンス CORE-1937
Firebirdサーバーがアクセスしているのと同じランタイムによって割り当てられていないポインタを返すような文字列UDFが書かれている場合、その宣言中のFREE_ITキーワードの存在が、メモリを汚染し、サーバーをクラッシュさせます。そのような異常なUDFに対するセーフガードとして、エンジンは…
そのようなUDFを検出し、例外をスローします。
エンベデッド版を含む全てのサーバー・モデルで、更新されたib_utilライブラリがパスの中に存在するか否かに依存します。
TPBの内容に不正がある場合の診断とエラーレポートが改善されました。新たなTPB検証ロジックは、以下のものをリジェクトします：
同じカテゴリの中で明らかに矛盾するオプション。例えば、一緒に指定された{WAIT}と{NOWAIT}、あるいは、{READ COMMITTED}と{SNAPSHOT}、あるいは、{READ ONLY}と{WRITE}。
無意味なオプション。例えば、SNAPSHOT分離モードに指定された[NO] RECORD VERSION。
テーブル予約オプションの誤った命令。例えば、{READ <TABLE> PROTECTED}と間違えて{PROTECTED READ <TABLE>}。
トラッカー・リファレンス CORE-1600
トラッカー・リファレンス CORE-2587
エンジンがWindowsの他のセッションで別のエンジンのプロセスによってすでにマッピングされた共有メモリを作成できない場合の診断メッセージが、少しだけユーザーフレンドリーになりました。従来は次のようなメッセージでした：
The requested operation cannot be performed on a file with a user-mapped section open.（要求された操作はユーザーマップセクションで開いたファイルでは実行できません。）
これが、次のようなメッセージとなります：
Database is probably already opened by another engine instance in another Windows session.（データベースはおそらく他のWindowsセッションの他のエンジンのインスタンスによりすでに開かれています。）
システムテーブルRDB$CHARACTER_SETS内のRDB$DEFAULT_COLLATE_NAMEの現在の値がバックアップ／リストアのサイクルの中で維持されるように改善されました。このカスタマイズのためのメカニズムが新しいALTER CHARACTER SETコマンドです。
トラッカー・リファレンス CORE-789
|
| Firebird Documentation Index → Firebird 2.5 リリースノート → Firebirdエンジンの変更 → 改善点 |