MicroKernel エンジンはファイルに情報を格納します。このファイルのサイズは、13.0 および 16.0 ファイル バージョンではテラバイト（9.5 バージョンでは 256 GB、9.x より前のバージョンでは 128 GB、それ以前のバージョンでは 64 GB）までです。各データ ファイル内には、データ バイトを収容するレコードがあります。1 つのファイルに数百京個のレコードを収容できます。

MicroKernel エンジンがレコード内で認識できる唯一の区別されている情報の部分は、キーです。キーは、レコードに対する高速な直接アクセスと、キー値によるレコードのソート手段を提供します。MicroKernel エンジンには各ファイル内のレコードの構造を理解する方法がないため、以下の項目を識別することによって各キーを定義します。

キーはいつでも作成または削除することができます。MicroKernel エンジンは、データ ファイルで定義されたキーごとにインデックスを作成します。インデックスは、データ ファイル自体の内部に格納されます。インデックスは、ファイル内の各キー値を実際のデータ内のオフセットへマップします。通常は、MicroKernel エンジンがデータのアクセスまたはソートを行う場合、ファイル内のすべてのレコードを検索しません。その代わり、インデックスを検索し、その後要求に合うレコードだけを処理します。

ファイルを作成した後に、外部インデックスを定義することもできます。外部インデックス ファイルは、指定するキーでソートされたレコードを含む標準データ ファイルです。各レコードは、以下の項目から成ります。

ファイルを作成すると同時にインデックスを作成する場合、MicroKernel エンジンはレコードがファイルに挿入された年代順に重複キー値を格納します。既に存在するファイルのインデックスを作成する場合、MicroKernel エンジンは、インデックス作成時の対応するレコードの物理順で重複キー値を格納します。MicroKernel エンジンがインデックスに重複キー値を格納する方法は、キーがリンク重複か繰り返し重複かによっても異なります。詳細については、重複可能性を参照してください。

キーの定義に関する具体的な情報については、データベースの設計を参照してください。

設定オプションの説明については、『Advanced Operations Guide』を参照してください。

ファイルは、一連のページから構成されています。ページとは、データベースがメモリとディスクの間で転送する記憶容量の単位です。ファイルは、以下のページ タイプから構成されています。

6.0 以降のすべてのファイルには、FCR ページと PAT ページがあります。標準ファイルにはデータ ページとインデックス ページも含まれており、オプションとして可変ページと ACS ページが含まれています。データオンリー ファイルにはインデックス ページが含まれていません。キーオンリー ファイルにはデータ ページが含まれていません。

ファイルを作成するときに固定ページ サイズを指定します。指定できるページ サイズやファイル オーバー ヘッドなどは、ファイル形式をはじめさまざまな要因によって異なります。ページ サイズの説明については、データベースの設計を参照してください。以下のセクションでは概要について説明します。

すべての要因を慎重に検討することによって、どのようなページ サイズにするのかに対する正しい答えを導くことができます。ページ サイズの選択の詳細については、ページ サイズの選択を参照してください。

MicroKernel エンジンがサポートするファイル サイズは、13.0 および 16.0 ファイル バージョンではテラバイト、9.5 バージョンでは 256 GB、9.x より前のバージョンでは 128 GB、それ以前のバージョンでは 64 GB までです。ただし、多くのオペレーティング システムでは、単一のファイルでこれだけの大きなサイズをサポートしていません。オペレーティング システムのファイル サイズの制限より大きいファイルをサポートするために、MicroKernel エンジンは大きなファイルをオペレーティング システムでサポートできるさらに小さなファイルに分割します。大きな論理ファイルは、拡張ファイルと呼びます。拡張ファイルを構成するさらに小さい物理ファイルは、エクステンション ファイルと呼びます。ベース ファイルは、大きすぎて 1 つの物理ファイルとしてサポートできなくなった元のデータ ファイルです。非拡張（非セグメント化）ファイルは、より効率的な I/O を提供するので、パフォーマンスが向上します。

9.x 以降の形式ファイルが自動的に 2 GB ごとに拡張されないようにすることができます。セグメント操作の設定を変更するには、『Advanced Operations Guide』の ZenCC での設定に記述されているように、Zen Control Center（ZenCC）の設定プロパティにアクセスします。ここで［セグメント サイズを 2 GB に制限］オプションを設定することができます。この設定は、13.0 および 16.0 のファイルには影響しません。これらのファイルはセグメント化されません。

拡張ファイルなどのファイルのバックアップについては、ファイルのバックアップを参照してください。

［スペースを含むファイル/ディレクトリ名］クライアント設定オプションが無効になっていない限り、ファイル名にはスペースを含めることができます。デフォルト設定は、オンです。『Advanced Operations Guide』の長いファイル名と埋め込みスペースのサポートを参照してください。

ラージ ファイルを使用する場合やアーカイブ ロギングまたは Continuous オペレーションの実行中など、MicroKernel エンジンが既存のファイル名に基づいて新しいファイルを作成する場合（『Advanced Operations Guide』のログ、バックアップおよび復元を参照）は、以下の例に示すように、新しいファイル名には元のファイル名のできるだけ多くの部分を含み、特有のファイル拡張子を使用します。

7.x 以降のファイル形式を使用する場合、キーを定義する際には以下のデータ型を使用できます。

詳細については、『SQL Engine Reference』のデータ型を参照してください。

キーは、各レコード内の 1 つ以上のセグメントから構成できます。レコード内の任意の連続バイトをセグメントとすることができます。キー タイプとソート順序は、キー内のセグメントごとに変えることができます。

インデックス セグメントと MicroKernel エンジンに関する詳細については、ステータス コード 26：指定されたキーの数が無効です。および 29：キー長が無効です。を参照してください。

セグメント化されたキーが重複不能キーである場合、セグメントを組み合わせて一意の値をつくる必要がありますが、個々のセグメントには重複を含めることができます。このタイプのセグメント化されたキーを定義する場合、たとえ特定セグメントに重複がある可能性があっても、各セグメントにはキー レベル属性として duplicates=no を持ちます。特定セグメントが常に一意であるようにするには、セグメント化されたキー定義の他に個別の重複不能キーとしてそのセグメントを定義します。

MicroKernel エンジン呼び出しを行う場合、キー バッファーの形式はキー番号で指定されるキーを収容できなければなりません。したがって、keynumber=0 を定義した場合、キー 0 が 4 バイト整数ならば、キー バッファー パラメーターは以下のいずれかにすることができます。

繰り返し重複キーでは、MicroKernel エンジンはインデックス ページの 1 つのポインターを使用して、データ ページの対応するレコードを識別します。キー値は、インデックス ページとデータ ページの両方に格納されます。重複キーの詳細については、重複キーを参照してください。

ヌル値を許可するフィールドを定義する元の方法は「擬似ヌル」または「レガシー ヌル」と呼びます。これは、フィールド全体が特定のバイト値、一般的には ASCII ゼロで埋められている場合に、そのフィールドをヌルと見なすという前提に基づいています。バイト値は、インデックス作成時に指定するキー定義に指定します。MicroKernel エンジンを使用する場合、MicroKernel エンジンがこの情報から行えることは、フィールドをインデックスに含めるか含めないかだけです。レガシー ヌルは、その特殊な意味にもかかわらず、その他すべての値とまったく同様にソートされる値であるため、特別なソート規則はありません。

Pervasive.SQL 2000 以降では、「真のヌル」と呼ぶ新しいタイプのヌル インジケーターが導入されています。

Create（14） または Create Index（31） オペレーションのキー定義で、ヌル値を許可する列の前にヌル インジケーター セグメント（NIS）を追加することによって、MicroKernel エンジンのキー内に真のヌル フィールドを定義することができます。真のヌル キーに関する規則については、真のヌル キーの規則を参照してください。

真のヌル フィールドの値は非決定です。言い換えると、その値は不明です。この定義によれば、どの 2 つのヌル値も互いに等しくなく、ほかのすべてのキー値とも等しくありません。それでも、MicroKernel エンジンはこれらのヌル値を 1 つにまとめる必要があり、ヌルに等しいキー値を見つけることができなければなりません。これを行うため、MicroKernel エンジンは比較の目的に合わせて、真のヌル値がそれぞれ等しいかのように解釈します。ソートしたり、インデックス内でヌル値の場所を検索したりする場合、真のヌル値は互いに等しいかのようにグループ化されます。しかし、重複のないインデックス内に値が既に存在するかどうかを判断しようとしているときは、真のヌルは互いに等しくなくなります。

Extended オペレーションのディスクリプターが不適切な形式あることにより発生するステータス 62 は、Zen イベント ログにシステム エラーを追加します。これらのシステム エラーは真のヌルと Extended オペレーションにリストされており、ステータス 62 の理由を識別するのに役立ちます。

例に示すオフセット 0x61～0x7A は、標準の ASCII 照合順序から変更されています。標準 ASCII では、オフセット 0x61 には値 0x61（小文字の a）が含まれています。UPPER ACS を使用してキーをソートする場合、MicroKernel エンジンは小文字の a（0x61）を、オフセット 0x61 の照合重みである 0x41 を使ってソートします。このように、小文字 a は大文字 A（0x41）であるかのようにソートされます。したがって、ソートの目的のために、UPPER はキーのソート時に、すべての小文字をそれらに相当する大文字に変換します。

次に示す 256 バイトの本体は、ASCII スペース（0x20）の前の ASCII 文字が他のすべての ASCII 文字の後にソートされる点を除き、UPPER.ALT の本体と同じ機能を果たします。

この本体では、別の照合重みが割り当てられているので、文字の重みがもう ASCII 値と同じではありません。たとえば、ASCII スペース文字を表すオフセット 0x20 の照合重みは 0x00 です。ASCII の大文字 A を表すオフセット 0x41 の照合重みは 0x21 です。

例については、インターナショナル ソート規則を使用した照合順序のサンプルを参照してください。

ほかの URI と同様に、ある特定の英数字以外の文字は URI 構文で特殊な意味を持ちます。そのような文字の 1 つを URI のいずれかの要素で使用する場合は、その文字が実際のテキストではなく特殊文字であると識別されるよう、エスケープ シーケンスを使用する必要があります。エスケープ シーケンスは、特殊文字に相当するプレーン テキストを表す、別の特殊文字または文字の組み合わせです。

空のユーザー名または空のパスワードは、ユーザー名やパスワードがないこととは異なるので注意してください。たとえば、btrv://@host/ には空のユーザー名が入っていますが、btrv://host/ にはユーザー名がありません。btrv://sam@host/?pwd= には、"sam" というユーザー名が入っており、パスワードは空です。

URI によっては user:password 構文を使用することもできます。ただし、ここで指定されるパスワードはその後クリア テキストとして転送されます。パスワードがクリア テキストとして転送されないようにするため、user:password 構文を使用してパスワードが提供された場合、Zen データベース URI はそのパスワードを無視します。pwd= パラメーターを使用してパスワードを提供してください。このパスワードは Zen クライアントによって転送される前に暗号化パスワードへ変更されます。

URI によっては、user@host:port 構文を使用するサーバー ベースの命名機関を可能にすることもできます。Zen データベース URI は port 要素の指定をサポートします。

『Getting Started with Zen』のドライブ ベースの形式を参照してください。

Zen は、ファイル パス内にシフト JIS（日本工業規格）でコード化されたダブルバイト文字を受け入れます（シフト JIS は、日本語のコンピューターに一般に使用されるコード化の手法です）。また、レコードにシフト JIS ダブルバイト文字を格納し、インターナショナル ソート規則で説明した日本語 ISR テーブルでそれらの文字をソートします。他のマルチバイト文字はレコードに格納できますが、ISR テーブルは文化的に正しい規則に従ってこれらのレコードをソートする目的には現在使用できません。ダブルバイト文字を使用しても、Zen アプリケーションのオペレーションに影響を与えません。

物理レコード長を算出するために論理レコード長に追加しなければならないオーバーヘッドのバイト数については、ディスク領域を最小限にするための最適なページ サイズおよびレコードの圧縮を使用した場合のレコード オーバーヘッドのバイト数を参照してください。

実行するオペレーションによって異なりますが、データ バッファーは各種情報の転送に使用する MicroKernel エンジン関数パラメーターです。データ バッファーには、レコード全体、レコードの一部、ファイル仕様などが含まれます。データ バッファーの詳細については、データベースの設計を参照してください。

非常に大きい可変長レコードを含むファイルについて、MicroKernel エンジンは多数の可変ページにまたがってレコードを分割し、可変長部と呼ぶリンク済みリストでこれらのページを接続します。アプリケーションがチャンク オペレーションを使用してレコードの一部にアクセスし、レコードの一部がレコード自体の先頭を越えたオフセットから始まる場合、MicroKernel エンジンはそのオフセットをシークするための可変長部リンク済みリストの読み取りにかなりの時間を費やすことがあります。そのようなシーク時間を制限するために、ファイルが VAT を使用するように指定できます。MicroKernel エンジンは可変ページに VAT を格納します。VAT を含むファイルでは、可変長部分を持つ各レコードにそれ自体の VAT があります。

アプリケーションが使用できないレコードに対するウェイト ロックを要求すると、MicroKernel エンジンはデッドロック状態の有無を確認します。デッドロック検出ステータス コードが返されるまで待機するように、MicroKernel エンジンを設定することができます。これを行うと、MicroKernel エンジンを内部的に待機させてアプリケーションにはオペレーションを再試行させないので、マルチユーザー環境におけるパフォーマンスを向上させます。

ファイルに対して行う変更が多く、また、これらの変更をすべて行うか、またはまったく行わないかを確実にしなければならない場合は、トランザクションでこれらの変更を行うためのオペレーションを取り込みます。明示的なトランザクションを定義すれば、MicroKernel エンジンに複数のオペレーションをアトミックな単位として処理させることができます。ほかのユーザーは、トランザクションが終了するまでファイルに対して行われた変更がわかりません。MicroKernel エンジンは、排他トランザクションと並行トランザクションの 2 種類のトランザクションをサポートします。

排他トランザクションでは、MicroKernel エンジンはデータ ファイルのレコードを挿入、更新、または削除するとき、そのデータ ファイル全体をロックします。ほかのアプリケーションや同じアプリケーションの別のインスタンスは、ファイルを開いてそのレコードを読み取ることはできますが、ファイルを変更することはできません。ファイルは、アプリケーションがトランザクションを終了または中止するまで、ロック状態のままになります。

並行トランザクションでは、MicroKernel エンジンは、実行するオペレーションによってファイル内のレコードまたはページをロックします。MicroKernel エンジンは、複数のアプリケーション（または同じアプリケーションの複数のインスタンス）が同じファイルの異なる部分に並行トランザクション内で変更を行えるようにしますが、それはこれらの変更が既にロックされているほかのファイル部分に影響を与えない場合に限られます。レコードまたはページは、アプリケーションがトランザクションを終了または中断するまで、ロック状態のままになります。並行トランザクションは、6.0 以降のファイルのみに使用できます。

たとえ要求されたレコードを並行トランザクションが既にロックしていても、クライアントはこれまでどおりレコードを読み取ることができます。ただし、これらのクライアントは排他トランザクション内から処理を行えません。また、要求されたレコードを含むファイルが排他トランザクションで現在ロックされているか、要求されたレコードを並行トランザクションが既にロックしている場合、クライアントは読み取り操作にロック バイアスを適用できません。

すべてのオペレーションを 1 つのトランザクション ログに記録することによって、トランザクション一貫性保持とアトミシティを保証するように MicroKernel エンジンを設定できます。トランザクション一貫性保持は、クライアントが End Transaction オペレーションを発行したときと、MicroKernel エンジンが正常終了したステータス コードをクライアントに返す前に、MicroKernel エンジンがログへの書き込みを終了することを保証する機能です。アトミシティは、特定のステートメントが終わりまで実行しない場合にそのステートメントがデータベース内に部分的または不明確な影響を残さないように保証し、それによってデータベースを安定した状態に保つことでデータベースの整合性を保証します。

トランザクション一貫性保持のオーバーヘッドなしでアトミシティが必要な場合は、Pervasive.SQL V8 以降のリリースのトランザクション ログ機能を使用することができます。トランザクション ログの詳細については、『Advanced Operations Guide』を参照してください。

デフォルトのインストールでは、トランザクション ログは C:\ProgramData\Actian\Zen\logs にあります。ログは、Zen エンジンと同じマシン上に存在しなければなりません。この場所は、ZenCC でトランザクション ログ ディレクトリ設定オプションを使用して変更できます。MicroKernel エンジンを右クリックし、［プロパティ］>［ディレクトリ］の順に選択すると表示されます。

特定ファイルのパフォーマンスを向上させるために、アクセラレイティド モードでファイルを開くことができます（バージョン 6.x MicroKernel エンジンはアクセラレイティド オープン要求を受け入れましたが、それらの要求をノーマル オープン要求と解釈していました）。アクセラレイティド モードでファイルを開くと、MicroKernel エンジンは、そのファイルに対するトランザクション ログを実行しません。

Zenは、7.x トランザクション ログ ファイル形式を使用します。MicroKernel エンジンがファイルでトランザクションのログを記録するには、MicroKernel エンジンがログ内のレコードを追跡する際に使用できる重複のない（重複不可能）キーであるログ キーがファイルに含まれている必要があります。1 つ以上の重複のない（重複不可能）キーを持つファイルの場合、MicroKernel エンジンはファイルで既に定義されている重複のないキーのうちの 1 つを使用します。

重複のないキーを持たないファイルの場合、MicroKernel エンジンはファイル作成時にシステム データを含めることができます。MicroKernel エンジンはファイルが 7.x 以降のファイル形式を使用しており、かつ、ファイルの作成時にシステム データを含めるように MicroKernel エンジンが設定されている場合にのみ、ファイルにシステム データを含めます。システム データは、8 バイトのバイナリ値としてキー番号 125 で定義されます。ファイルに重複のないユーザー定義キーがある場合でも、ユーザーによるインデックスの削除に備えるために、システム データ（システム定義のログ キーとも呼ばれます）を使用することができます。

ファイルがシステム データを使用しており、レコード長がレコード長で説明されている制限を超える場合、データベース エンジンではそのファイルに対し、データ圧縮を行います。

MicroKernel エンジンがシステム データを追加するのはファイル作成時だけです。既存のファイルにシステム データを追加する場合は、［システム データの作成］設定オプションをオンにした後、データ ファイルの変換の説明に従って Rebuild ツールを使用します。

MicroKernel エンジンは、シャドウ ページングを使用して、システム障害が発生した場合に 6.0 以降のファイルが破壊されないようにします。クライアントがトランザクションの内部または外部のページの変更を要求すると、MicroKernel エンジンはデータ ファイル自体の空いた未使用の物理位置を選択し、シャドウ ページと呼ぶ新しいページ イメージをこの新しい場所に書き込みます。1 回の MicroKernel エンジンの操作で、MicroKernel エンジンは元の論理ページとすべて同じサイズの複数のシャドウ ページを作成することがあります。

ファイルのバックアップの詳細については、『Advanced Operations Guide』のログ、バックアップおよび復元を参照してください。

詳細については、『Advanced Operations Guide』のメッセージ ログの見直しを参照してください。

パフォーマンスを向上し、データの回復を支援するために、MicroKernel エンジンは 1 つまたは複数のコミットされたオペレーション（トランザクションと非トランザクションの両方）をシステム トランザクションと呼ぶオペレーションのまとまりに入れます。MicroKernel エンジンは、ファイルごとにシステム トランザクションを作成します。システム トランザクションには、同じエンジンで動作する 1 つまたは複数のクライアントからのオペレーションとユーザー トランザクションを含めることができます。

Zen は、アクセラレイティド モードで開いたファイルを除くすべてのログ記録可能なファイルのトランザクション一貫性保持を保証します。（ファイルに少なくとも 1 つの重複のない重複不能キーが含まれている場合は、そのファイルをログに記録することができます。キーはシステム定義とすることができます。）トランザクション一貫性保持は、MicroKernel エンジンが End Transaction に対し正常終了のステータス コードをクライアントに返す前にトランザクション ログへの書き込みを終了することを保証する機能です。アクセラレイティド モードでファイルを開くと、MicroKernel エンジンはファイルをログに記録しません。したがって、MicroKernel エンジンはファイルにエントリを記録しません。したがって、MicroKernel エンジンはそのファイルのトランザクション一貫性保持を保証できません。

到達するとシステム トランザクションが起動される制限には、オペレーション バンドル制限、起動時間制限、キャッシュ サイズの 3 つがあります。これらの制限に達すると、MicroKernel エンジンはシステム トランザクションを起動します。この設定の詳細については、『Advanced Operations Guide』を参照してください。

キャッシュは、読み取るページをバッファーするために MicroKernel エンジンが予約するメモリ領域です。アプリケーションがレコードを要求すると、MicroKernel エンジンはまず、そのレコードを含むページが既にメモリ内にあるかどうかを確認するためにキャッシュを調べます。そうであれば、MicroKernel エンジンはレコードをキャッシュからアプリケーションのデータ バッファーに転送します。ページがキャッシュ内になければ、MicroKernel エンジンはページをディスクからキャッシュ バッファーに読み取ってから要求されたレコードをアプリケーションに転送します。MicroKernel エンジン キャッシュはローカル クライアントにより共有され、複数のオペレーション間で使用されます。

Pervasive.SQL V8 以降のリリースでは、2 番目の動的 L2 キャッシュも使用できます。この動的キャッシュの設定は、［MicroKernel エンジンの最大メモリ使用量］（v9.1 以降では［MicroKernel の最大メモリ使用量］）で行います。これらの設定の詳細については、『Advanced Operations Guide』を参照してください。

ページ プリアロケーションは、MicroKernel エンジンがディスク領域を必要とするときにそのスペースを使用できるようにします。データ ファイルがディスク上の連続する領域を占有する場合、ファイル操作を高速化することができます。速度の向上は、非常に大きなファイルで最も顕著です。この機能の詳細については、ページ プリアロケーションを参照してください。

これらのオペレーションの詳細については、複数レコード オペレーションを参照してください。

この機能の詳細については、レコード圧縮を参照してください。

ブランク トランケーションはディスク容量を節約します。可変長のレコードを許し、かつデータ圧縮機能を使用しないファイルにのみ適用できます。この機能の詳細については、ブランク トランケーションを参照してください。