advanced operations guideadvanced operations guide procedures and references for advanced users...

Pervasive PSQL v11

Advanced Operations GuideProcedures and References for Advanced Users

免責事項 Pervasive Software Inc. は、本ソフトウェアおよびドキュメントの使用を、利用者また

はその会社に対して「現状のまま」で、かつ同梱の使用許諾契約書に記載の契約条件によってのみ許諾するものです。 Pervasive Software Inc. は、いかなる場合にも本ソフ

トウェアおよび本マニュアルに記載された内容に関するその他の一切の保証を、明示的にも黙示的にも行いません。 Pervasive Software Inc. は、市場性、権利、特定の目的

に対する適合性、あるいは一連の取引業務や職業的な使用に関する問題などに対し、一切の保証を行わないことを明示するとともに、利用者およびその会社がこれに同意したものとします。

商標 Btrieve、 Client/Server in a Box、 Pervasive、 Pervasive Software および Pervasive Software のロゴは、 Pervasive Software Inc. の登録商標です。

Built on Pervasive Software、 DataExchange、 MicroKernel Database Engine、 MicroKernel Database Architecture、 Pervasive.SQL、 Pervasive PSQL、 Solution Network、 Ultralight、 ZDBA は Pervasive Software Inc. の商標です。

Microsoft、 MS-DOS、 Windows、 Windows 95、 Windows 98、 Windows NT、 Windows Me、Windows 2000、 Windows 2003、 Windows 2008、 Windows 7、 Windows 8、 Windows Server 2003、Windows Server 2008、 Windows Server 2012、 Windows XP、 Win32、 Win32s、および Visual Basic は、 Microsoft Corporation の登録商標です。

NetWare および Novell は Novell, Inc. の登録商標です。 NetWare Loadable Module、 NLM、 Novell DOS、 Transaction Tracking System、 TTS は、 Novell, Inc. の商標です。

Sun、 Sun Microsystems、 Java、および Sun、 Solaris、 Java を含むすべての商標やロゴは、 Sun Microsystems の商標または登録商標です。すべての会社名および製品名は各社の商標または登録商標です。

© Copyright 2013 Pervasive Software Inc. All rights reserved. このマニュアルの全文、一部に関わり

なく複製、複写、配布をすることは、前もって発行者の書面による同意がない限り禁止します。

本製品には、 Powerdog Industries により開発されたソフトウェアが含まれています。

© Copyright 1994 Powerdog Industries.All rights reserved. 本製品には、 KeyWorks Software により開発されたソフトウェアが含まれています。

© Copyright 2002 KeyWorks Software.All rights reserved. 本製品には、 DUNDAS SOFTWARE により開発されたソフトウェアが含まれています。

© Copyright 1997-2000 DUNDAS SOFTWARE LTD. All rights reserved. 本製品には、 Apache Software Foundation Foundation （http://www.apache.org/）により開発された

ソフトウェアが含まれています。本製品ではフリーソフトウェアの unixODBC Driver Manager を使用しています。これは Peter Harvey （[email protected]）によって作成され、 Nick Gorham （[email protected]）に

より変更および拡張されたものに Pervasive Software が一部修正を加えたものです。 Pervasive Software は、 unixODBC Driver Manager プロジェクトの LGPL 使用許諾契約書に従って、このプ

ロジェクトの現在の保守管理者にそのコード変更を提供します。 unixODBC Driver Manager の Web ページは www.unixodbc.org にあります。このプロジェクトに関する詳細については、現在

の保守管理者である Nick Gorham （[email protected]）にお問い合せください。

GNU Lesser General Public License （LGPL）は本製品の配布メディアに含まれています。LGPL は www.fsf.org/licensing/licenses/lgpl.html でも見ることができます。

Advanced Operations Guide2014 年 5 月138-004434-004

目次

このマニュアルについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiこのマニュアルの読者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiこのマニュアルの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii表記上の規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

1 Pervasive PSQL データベース . . . . . . . . . . . . . . . . . . . . . . . . . . 1オブジェクト名、名前付きデータベースおよび DSN の詳細

Pervasive PSQL データベースの概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2名前付きデータベース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2メタデータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2識別子とオブジェクト名 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2デフォルトのデータベースと現在のデータベース . . . . . . . . . . . . . . . . . . . . . . . . . . 5ファイル構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6アクセス方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9クライアント / サーバー通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9データベースコードページ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10ODBC DSN 作成オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10idshosts ファイルの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 データベース管理の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13データベース管理について

設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

データベースセキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

データの保存と復元 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

トラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

有用なユーティリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Pervasive コンポーネントのアーキテクチャについて . . . . . . . . . . . . . . 19アーキテクチャ機能の説明

Pervasive PSQL データベースエンジン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20共通アドレス空間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20行レベルのロック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20MicroKernel Database エンジン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20SQL Relational Database エンジン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

リレーショナルアーキテクチャの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Pervasive PSQL リレーショナルアーキテクチャ：サーバー . . . . . . . . . . . . . . . . . . . . . 23

エラーコード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Pervasive Auto-Reconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 設定リファレンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Pervasive PSQL で使用できる構成方法および設定

設定の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28設定の変更が有効になっていることを確認する . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

iii

目次

別のマシンに接続する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

PCC による設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

CLI ユーティリティによる設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30構成の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30コマンド構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

設定のプロパティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

サービス設定プロパティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

サーバー設定プロパティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36アクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37通信プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43ファイル互換性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45データ整合性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46デバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50ディレクトリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53メモリの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53パフォーマンスチューニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Windows クライアント設定プロパティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61アクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 キャッシュエンジン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63キャッシュエンジンのデバッグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65通信プロトコル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66パフォーマンスチューニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 セキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67アプリケーションの特性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Linux クライアント設定プロパティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70設定値での大文字小文字の区別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70ローカル設定（［Local］）によって影響を受けるクライアントのパフォーマンス . . . . . . . . 70埋め込みスペースを含むファイル名 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70設定リファレンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Access （アクセス） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Communication Protocols （通信プロトコル） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Application Characteristics （アプリケーションの特性） . . . . . . . . . . . . . . . . . . . . . . . . 72

5 パフォーマンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73データベースパフォーマンスの分析およびチューニング

パフォーマンスの分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74インストール時の登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74データコレクターセット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Windows パフォーマンスモニターの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

パフォーマンスチューニング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84パフォーマンスのボトルネックを見極める . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84設定プロパティを変更する前に . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85初期接続時間を小限にする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85ランタイムのスループットを大にする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87大きいシステムキャッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

ハイパーバイザー製品でのパフォーマンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

iv

目次

Xtreme I/O ドライバー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94留意点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94システム要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95XIO メモリキャッシュ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95よく寄せられる質問 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97各種ユーティリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98除外ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Pvsw.log のメッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101イベントログメッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102XIO のトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6 参照整合性の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105参照整合性の構造について

参照整合性（RI）の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106キーおよび規則について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

主キーの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109テーブル作成中に主キーを作成する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109既存のテーブルに主キーを追加する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

外部キーの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110テーブル作成中に外部キーを作成する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110既存のテーブルに外部キーを追加する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Btrieve およびリレーショナル制約間の相互作用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111バウンドデータベースと整合性の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112関連項目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7 Pervasive PSQL セキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . 115トランザクショナルおよびリレーショナルインターフェイスのためのセキュリティに関する概念と作業

データベースセキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Master ユーザー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116ユーザーとグループ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

セキュリティモデルと概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117リレーショナルインターフェイスで使用可能なモデル . . . . . . . . . . . . . . . . . . . . . . . 117トランザクショナルインターフェイスで使用可能なモデル . . . . . . . . . . . . . . . . . . . . 118オーナーネーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120複数のデータベースのデータにアクセスする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

トランザクショナルインターフェイスのセキュリティ計画 . . . . . . . . . . . . . . . . . . . . . . . . 123使用可能なオプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123ポリシーの選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123セキュリティを設定するための準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124処理の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

トランザクショナルインターフェイスセキュリティのクイックスタート . . . . . . . . . . . . . . . 127

セキュリティの作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

データの暗号化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130ワイヤ暗号化の設定プロパティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130暗号化の注意 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

v

目次

暗号化の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130暗号化の影響 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132オーナーネームの暗号化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

8 ログ、バックアップおよび復元 . . . . . . . . . . . . . . . . . . . . . . . . . . 133ログ、バックアップおよびデータの復元について

トランザクションログおよびトランザクション一貫性保守 . . . . . . . . . . . . . . . . . . . . . . . . 134これらの機能の使用法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134機能の比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134どちらの機能を使用するか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135ログの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135関連項目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

アーカイブログおよび Continuous オペレーションについて . . . . . . . . . . . . . . . . . . . . . . . . 138アーカイブログとトランザクションログの違い . . . . . . . . . . . . . . . . . . . . . . . . . . . 138ファイルの復元が必要になったら . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

アーカイブログの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140全般的な手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140アーカイブログの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141ロールフォワードコマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Continuous オペレーションの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Continuous オペレーションの開始と停止 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144BUTIL を使用してデータベースのバックアップを行う . . . . . . . . . . . . . . . . . . . . . . . 145Continuous オペレーション使用時のデータファイルの復元 . . . . . . . . . . . . . . . . . . . . . 147

Backup Agent および VSS Writer によるデータバックアップ . . . . . . . . . . . . . . . . . . . . . . . . 148Pervasive Backup Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Pervasive PSQL VSS Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

9 高可用性のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151可用性の高い環境での Pervasive PSQL の使用

技術の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152高可用性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152フォールトトレランス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152障害回復 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153ハードウェア要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

フェールオーバークラスタリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Windows Server 2008 以上を対象とした Microsoft フェールオーバークラスタリング . . . . . . 154Windows Server 2003 用の Microsoft Cluster Service . . . . . . . . . . . . . . . . . . . . . . . . . . 157Linux Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160クラスター環境における Pervasive PSQL の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

マイグレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

フォールトトレランス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

障害回復 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

10 ワークグループエンジンの詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . 169ワークグループエンジンの技術的な詳細および高度な処理

ネットワーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

vi

目次

NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170MicroKernel のルーター決定アルゴリズム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

サーバーとワークグループの技術的な相違 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171プラットフォーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171ユーザーインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171認証と Btrieve セキュリティポリシー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171ゲートウェイのサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171非同期 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171デフォルトの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Xtreme I/O （XIO）のサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172ライセンスモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

ワークグループの問題のトラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173初の接続での待ち時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

ステータスコード 116 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

ロケーターファイルのリダイレクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175リダイレクトロケーターファイルの要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175リダイレクトロケーターファイルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

11 データベースリソースの監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Monitor を使用してデータベースリソースを調べる

Monitor の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180インターフェイスの各種バージョン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Monitor のグラフィカルユーザーインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Monitor の起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Monitor のオプション設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181トランザクショナルインターフェイスリソースの監視 . . . . . . . . . . . . . . . . . . . . . . . 182リレーショナルインターフェイスリソースの監視 . . . . . . . . . . . . . . . . . . . . . . . . . 190

Monitor のコマンドラインインターフェイス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192構成ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192監視の出力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192コマンド構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

12 Btrieve オペレーションのテスト . . . . . . . . . . . . . . . . . . . . . . . . . . 195Function Executor ユーティリティで Btrieve オペレーションを実行する方法

Function Executor の概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Function Executor でできること . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Function Executor の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Function Executor の自動モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200詳細情報を入手するには . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Function Executor のグラフィカルユーザーインターフェイス . . . . . . . . . . . . . . . . . . . . . . . 201 アプリケーションウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202メインウィンドウ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205ログインおよびログアウト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207［ファイルのオープン］ダイアログ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Btrieve ファイルの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

vii

目次

ファイルの作成用ダイアログ GUI のリファレンス（高度） . . . . . . . . . . . . . . . . . . . . . 210トランザクション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211ファイル統計情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212履歴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Function Executor での作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Function Executor での作業の開始 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215オペレーション作業の実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215ファイルを開く作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Btrieve ファイルを作成する作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217履歴の作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

13 Maintenance を使用した Btrieve データファイルの操作 . . . . . . . . . . . . . 221Maintenance ユーティリティを使用した Btrieve データファイルの操作

Maintenance ユーティリティの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

対話型 Btrieve Maintenance ユーティリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223拡張ファイルのサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223長いファイル名と埋め込みスペースのサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . 223レコードおよびページ圧縮 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Btrieve Maintenance ユーティリティのインターフェイス . . . . . . . . . . . . . . . . . . . . . . . 225

ファイル情報エディター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227［ファイル情報エディター］ダイアログの項目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227重複キーの操作方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231情報エディターでの作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

オーナーネーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239オーナーネームの作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

情報レポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241情報レポートの作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

インデックス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243インデックスの作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

データ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245ASCII ファイル形式のインポートとエクスポート . . . . . . . . . . . . . . . . . . . . . . . . . . 245データに関する作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Btrieve コマンドライン Maintenance ユーティリティ（butil） . . . . . . . . . . . . . . . . . . . . . . . . 249リターンコード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249コマンド構文の表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250コマンド形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250コマンドファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250ディスクリプションファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251拡張ファイルのサポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251オーナーネーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251エラーメッセージのリダイレクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252ASCII ファイル形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252異なるプラットフォームでのファイル名指定の規則 . . . . . . . . . . . . . . . . . . . . . . . . . 252

データのインポートとエクスポート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253COPY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253LOAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

viii

目次

RECOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255SAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

データファイルの作成と変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259CLONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259CLROWNER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260CREATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261DROP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263SETOWNER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264SINDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Btrieve データファイルのコンパクト化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

データファイル情報の表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267STAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Btrieve インターフェイスモジュールのバージョンの表示 . . . . . . . . . . . . . . . . . . . . . . . . . 270VER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Btrieve インターフェイスとリクエスターのアンロード（DOS のみ） . . . . . . . . . . . . . . . . . . . 271STOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Continuous オペレーションの実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

アーカイブログの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

14 データファイルの変換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Pervasive PSQL ファイル互換性を維持する

Rebuild ユーティリティの概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278サポートされるプラットフォーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278ファイル形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279テンポラリファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Rebuild 処理の適化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280ログファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Rebuild ユーティリティの GUI のリファレンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285ファイルオプションの画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Rebuild オプションの画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Rebuild 進行状況画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Rebuild ユーティリティの作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289GUI 操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289CLI 操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290コマンドラインパラメーター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

A ディスクリプションファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . 297ディスクリプションファイルを使用して Btrieve ファイル情報を保存する

ディスクリプションファイルの規則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

ディスクリプションファイルの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

ディスクリプションファイルの要素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

ix

目次

x

このマニュアルについて

このマニュアルでは、高度な操作の説明と上級ユーザーのための技術情報を提供します。

このマニュアルの情報には、お使いのプラットフォームや製品には適用されないものも含まれています。たとえ

ば、ゲートウェイエンジン設定に関する情報はサーバーエンジンには適用されません。そのような情報は区別

できるよう明記しています。

xi

このマニュアルの読者

このマニュアルは上級ユーザー向けに提供されています。上級ユーザーは Pervasive PSQL ベースアプリケーショ

ンの基盤にあるオペレーティングシステムについて深く理解していることが前提とされます。上級ユーザーは、

オペレーティングシステムの構成をスムーズに行うことができ、多くの場合データベースエンジンを構成する管

理者権限を持っている必要があります。上級ユーザーとは、以下のような方が該当します。

1 つ以上の Pervasive PSQL ベースアプリケーションがインストールされているネットワークの管理者

Pervasive PSQL ベースアプリケーションの付加価値再販業者

Pervasive PSQL ベースアプリケーションの開発者

xii

このマニュアルの構成

このマニュアルの各章について簡単に説明します。

第 1 章「Pervasive PSQL データベース」

この章では、データベースに関する概念情報および、データベースの作成方法、データベースのプロパティ

の設定方法について説明します。

第 2 章「データベース管理の概念」

この章では、データベース管理の基本概念およびデータベース管理に伴う操作について簡単に紹介します。

第 3 章「Pervasive コンポーネントのアーキテクチャについて」

この章では、 Pervasive PSQL を構成する主なコンポーネントの詳細およびユニークな機能について説明しま

す。

第 4 章「設定リファレンス」

この章では、設定プロパティのアクセス方法について説明し、エンジンおよびクライアントに設定可能なす

べてのオプションについて詳細に説明します。

第 5 章「パフォーマンス」

この章では、 Xtreme I/O ドライバーのチューニングおよび使用などのさまざまな手段を用いてデータベース

のパフォーマンスを向上させる方法について説明します。

第 6 章「参照整合性の設定」

この章では、関連するデータの内部的な整合性を確実にするため、参照整合性規則を設定する方法について

説明します。

第 7 章「Pervasive PSQL セキュリティ」

この章では、 Btrieve セキュリティおよび SQL セキュリティについて説明します。

第 8 章「ログ、バックアップおよび復元」

この章では、データの保護を確実にするための定期バックアッププロシージャを開発する方法、および必要

な場合にバックアップから復元する方法を説明します。

第 9 章「高可用性のサポート」

この章では、 Pervasive PSQL が、フェイルオーバークラスタリングをどのようにサポートするかを説明しま

す。

第 10 章「ワークグループエンジンの詳細」

この章では、ワークグループエンジンに関する技術の詳細および高度な操作を説明します。

第 11 章「データベースリソースの監視」

この章では、グラフィカルなユーティリティである Monitor を使用してデータベースに接続しているユー

ザー、ファイルの使用状況、およびリソースの使用状況を表示する方法を説明します。

第 12 章「Btrieve オペレーションのテスト」

この章では、 Function Executor ユーティリティを使用してトランザクショナルインターフェイスの個々のオ

ペレーションを実行する方法を説明します。

第 13 章「Maintenance を使用した Btrieve データファイルの操作」

この章では、 Maintenance ユーティリティの使用法を説明します。

第 14 章「データファイルの変換」

この章では、 Rebuild ユーティリティの使用法を説明します。

xiii

付録 A 「ディスクリプションファイル」

この付録では、作成した Btrieve データファイルの情報を保存するディスクリプションファイルの使用方法

について説明します。

xiv

表記上の規則

特段の記述がない限り、コマンド構文、コード、およびコード例では、以下の表記が使用されます。

大文字小文字の

区別

通常、コマンドと予約語は、大文字で表記されます。本書で

別途記述がない限り、これらの項目は大文字、小文字、ある

いはその両方を使って入力できます。たとえば、 MYPROG、myprog、または MYprog と入力することができます。

太字太字で表示される単語には次のようなものがあります。メ

ニュー名、ダイアログボックス名、コマンド、オプション、

ボタン、ステートメントなど。

固定幅フォント固定幅フォントは、コマンド構文など、ユーザーが入力する

テキストに使われます。

[ ] 省略可能な情報には、［log_name］のように、角かっこが使

用されます。角かっこで囲まれていない情報は必ず指定する

必要があります。

| 縦棒は、［file name ｜ @file name］のように、入力する情報

の選択肢を表します。

< > ＜＞は、 /D=<5|6|7> のように、必須項目に対する選択

肢を表します。

変数 file name のように斜体で表されている語は、適切な値に置き

換える必要のある変数です。

. . . ［parameter. . .］のように、情報の後に省略記号が続く場合は、

その情報を繰り返し使用できます。

::= 記号 ::= は、ある項目が別の項目用語で定義されていること

を意味します。たとえば、 a::=b は、項目 a が b で定義され

ていることを意味します。

xv

1
Pervasive PSQL データベース
オブジェクト名、名前付きデータベースおよび DSN の詳細

この章では、以下の項目について説明します。

「Pervasive PSQL データベースの概念」

1


Pervasive PSQL データベースの概念

「名前付きデータベース」

「メタデータ」

「識別子とオブジェクト名」

「デフォルトのデータベースと現在のデータベース」

「ファイル構造」

「アクセス方法」

「クライアント / サーバー通信」

「データベースコードページ」

「ODBC DSN 作成オプション」

「idshosts ファイルの使用」

名前付きデータベース

名前付きデータベース（DBname とも呼ばれます）は、論理名を持ち、この名前によって、データベースが実際

に存在する場所を知らなくても、そのデータベースを識別することができます。 Pervasive PSQL では、すべての

データベースが名前付きデータベースである必要があります。データベースに名前を付ける際は、その名前を特

定の辞書ディレクトリのパスおよび 1 つまたは複数のデータファイルのパスに関連付けるようにします。

名前付きデータベースへは、さまざまなアクセス方法で接続されます。たとえば、 ODBC アクセスの場合は名前

付きデータベースを指すデータソース名（DSN）を設定する必要があります。複数の DSN が同じ名前付きデー

タベースを指すことができます。『SQL Engine Reference』の「ODBC データベースアクセス」を参照してくださ

い。その他のアクセス方法の場合、アプリケーション開発者が、それぞれのアクセス方法の API を使用して名前

付きデータベースに接続することができます。 Pervasive PSQL ドキュメントの開発者向けガイドを参照してくだ

さい。

メモ名前付きデータベースを使用する場合、管理者レベルまたは Pervasive_Admin セキュリティグループの

メンバーであるオペレーティングシステムのユーザー名で、データベースエンジンが存在するコンピュー

ターにログインする必要があります。

名前付きデータベースを作成するも簡単な方法は、 Pervasive PSQL Control Center を使用することです。

『Pervasive PSQL User's Guide』の「新規データベースを作成するには」を参照してください。アプリケーション開

発者は別のアクセス方法の API を用いて名前付きデータベースを作成することもできます。たとえば、 SQL の場

合は「CREATE DATABASE」、 DTI の場合は「PvCreateDatabase()」、 ADO.NET の場合は「Data Access ApplicationBlocks」を参照してください。

メタデータ

リレーショナルインターフェイスは、バージョン 1 （V1）とバージョン 2 （V2）という 2 つのバージョンのメタ

データをサポートします。メタデータバージョン 2 では、多くの識別子に大 128 バイトの名前を付けることが

でき、ビューおよびストアドプロシージャを許可し、メタデータバージョン 2 固有の DDF （データ辞書ファイ

ル）を持つことができます。

『SQL Engine Reference』の「メタデータのバージョン」を参照してください。

識別子とオブジェクト名

識別子は、データベースの名前、またはデータベース内の列、テーブル、プロシージャやその他名前付きオブジェ

クトの名前です。識別子は、通常の識別子またはデリミター（区切り記号）付きの識別子として指定されます。

2


通常の識別子

通常の識別子とは、二重引用符で囲まれていない識別子のことです。通常の識別子は大文字または小文字の文字

で始まる必要があります。識別子の残りの部分は大文字または小文字の文字、数字、および有効な文字の任意の

組み合わせで構成されます。

通常の識別子に予約語を使用することはできません。

通常の識別子は大文字小文字を区別しません。

デリミター付き識別子

デリミター付き識別子とは、二重引用符で囲まれた識別子のことです。デリミター付き識別子は、有効な文字か

ら成る任意の文字列と、それを囲む二重引用符で構成されます。

推奨できる使用法ではありませんが、デリミター付き識別子には予約語も使用できます。たとえば、 INSERT は通常の識別子としての使用は許可されませんが、 "INSERT" はデリミター付き識別子としては許可されます。識

別子がキーワードでもある場合は二重引用符で囲む必要があります（たとえば、 SELECT "password" FROMmy_pword_tbl となります。 "password" は SET PASSWORD ステートメントのキーワードなので二重引用符で囲み

ます）。

識別子の制限

上に挙げた全般的な制限以外に、各種の識別子に特有の制限を次の表に一覧表示します。

表 1 識別子の種類別の制限

識別子長さ制限

（バイト単位）

無効な文字 1 注記

V12 V23

列 20 128 \ / : * ? " < > | 先頭は文字でなければなりません

ヌルにすることはできません

データベース 20 20 ` ~ ! @ # $ % ^ & * ( ) _ - + = } ] { [ | \ : ; " <, ' > . ? /

先頭は文字でなければなりません

関数（ユーザー

定義）

30 128 通常の識別子の場合：` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < ,' > . ? /

文字、数字、およびアンダースコア（"_"）が有効です


デリミター付き識別子の場合：

なし

名前を二重引用符で囲む必要があります

グループ 30 128 \ / : * ? " < > | （および空白文字） MASTER にすることはできません

インデックス 20 128 \ / : * ? " < > | （および空白文字） Pervasive PSQL Control Center （PCC）でイ

ンデックスを作成する場合、先頭に UK_を付けてはいけません

PCC 外で UK_ で始まるインデックスを作

成した場合、そのインデックスは PCC で編集できません

キー

（外部または主）

20 128 \ / : * ? " < > | （および空白文字）先頭は文字でなければなりません

同一テーブル内で、外部キーとインデック

スに同じ名前を付けることはできません

3


パスワード 8 128 ; ? " ' 先頭を空白（空白として使用される文字）

にすることはできません

ヌルにすることはできません

［無効な文字］列に挙げられている文字以

外の、あらゆる表示可能な文字が指定でき

ます

プロシージャ

（ストアド）

30 128 通常の識別子の場合：` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < ,' > . ? /




なし


テーブル 20 128 \ / : * ? " < > | （および空白文字）

# ##4無効な文字は、通常とデリミター付きの両

方の識別子に適用されます

トリガー 30 128 通常の識別子の場合：` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < ,' > . ? /




なし


ユーザー 30 128 \ / : * ? " < > | （および空白文字） MASTER または PUBLIC にすることはで

きません

ビュー 20 128 通常の識別子の場合：` ~ ! @ # $ % ^ & * ( ) - + = } ] { [ | \ : ; " < ,' > . ? /




なし


1 特に示されていない限り、無効な文字は通常の識別子とデリミター付き識別子の両方に適用されます。

2 バージョン 1 （V1）メタデータに適用。『SQL Engine Reference』の「メタデータのバージョン」を参照してください。

3 バージョン 2 （V2）メタデータに適用。『SQL Engine Reference』の「メタデータのバージョン」を参照してください。

4 テンポラリテーブルの名前の先頭は # または ## で始まります。このため、 # と ## は永続テーブルの名前の先頭文字とし

ては無効です。『SQL Engine Reference』の「CREATE （テンポラリ） TABLE」を参照してください。

表 1 識別子の種類別の制限

識別子長さ制限

（バイト単位）

無効な文字 1 注記

V12 V23

4


ユニークなスコープ

通常、識別子は一定のスコープ内でユニークである必要があります。つまり、同じ名前を使用する同一タイプの

オブジェクトのインスタンスは同一領域内では使用できません。表 2 は、オブジェクト名がどのような領域また

はスコープ内でユニークである必要があるかを表します。

デフォルトのデータベースと現在のデータベース

既存のアプリケーションで、Btrieve ファイルを作成したり開いたりする際にデータベース名を指定していないア

プリケーションをサポートするために、 Pervasive PSQL では、トランザクショナルデータベースエンジンごとの

デフォルトデータベースという概念が維持されています。デフォルトデータベースは、 "DefaultDB" という名前

であらかじめ定義されているデータベースです。アプリケーションコードを変更しないで新しいセキュリティモデルを使うようにするには、 Btrieve データディレクトリをデフォルトデータベースと関連付けてから、それら

のディレクトリにあるデータファイルへのアクセスを制御するよう、デフォルトデータベースでユーザーおよび

権限を設定します。

また、データベースエンジンは、クライアント接続ごとの現在のデータベースという概念も理解しています。

Btrieve の Login （78）、 Create （14）、または Open （0）オペレーションでデータベース名が指定されていない場

合、トランザクショナルエンジンは、そのオペレーションは現在のデータベースに関連するものであると見なし

ます。現在のデータベースとは、各クライアントで、一番近 Login （78）オペレーション（明示的ログイン）が

発生したデータベースを指します。クライアントコンピューターが明示的なログイン操作を要求していない場合

は、一番近 Create （14）または Open （0）オペレーション（暗黙ログイン）が発生したデータベースが現在の

データベースとなります。明示的にも暗黙的にもログインが発生していない場合は、前の段落で説明したデフォ

ルトデータベースが現在のデータベースとなります。クライアントが明示または暗黙のログインを実行した場

合、あるいは後のファイルハンドルを閉じることによって "DefaultDB" が現在のデータベースとなった場合に

は常に、現在のデータベースが変わる可能性があることに注意してください。各クライアントの現在のデータベー

スは、ほかのクライアントの動作とは関係ありません。

表 2 共通識別子のユニーク性の適用範囲

このタイプのオブジェクトの名前 ... この範囲内でユニーク

データベーステーブルストアドプロ

シージャ

その他

データベース一定のデータベースエンジンによって

ホストされるすべてのデータベース

テーブル ○

トリガー、ストアドプロシージャ、

ユーザー定義関数

○

ユーザーまたはグループ ○

ビュー ○

制約 ○

列 ○

インデックス ○ 外部キーと同じ名前を持つことはでき

ません

キー（外部） ○ インデックスと同じ名前を持つことは

できません

カーソル ○

5


既存のアプリケーションに新しいセキュリティモデルを構成するも簡単な方法は、すべての Btrieve データ

ディレクトリをデフォルトデータベースと関連付け、このデータベース内で PUBLIC グループの権限を設定する

ことです。 PUBLIC グループは、データベースのセキュリティを有効にしたとき、 Master ユーザーと共に自動的

に作成されます。「トランザクショナルインターフェイスセキュリティのクイックスタート」を参照してくださ

い。

ファイル構造

すべての Pervasive PSQL データベースは共通のデータ形式を使用します。このファイル形式の共有により、同一

データのアクセスにトランザクショナル、リレーショナルなどの異なるアクセス方法を使用することができます。

すべてのアクセス方法が機能するために使用するデータベース管理システムは MicroKernel Database エンジン

（MKDE）と呼ばれます。

各 Pervasive PSQL データベーステーブルは別個のファイルで、デフォルトで拡張子 MKD を持ちます。ただし、開

発者は独自のファイル名拡張子を指定することができます。MicroKernel ファイルはデータとインデックスの両方

を持ち、さまざまなタイプのページで構成されます。MicroKernel ファイルは共通のデータ形式でデータを格納し

ます。

各 Pervasive PSQL データベースには、拡張子 DDF のデータ辞書ファイル一式も含まれます。 DDF ファイルには

データベーススキーマが含まれます。メタデータバージョン 1 とメタデータバージョン 2 の DDF は異なるファ

イル名を使用します。『SQL Engine Reference』の「システムテーブル」を参照してください。

MKDE は、キーフィールドは別として、データのスキーマにはまったく無頓着です。ただし、参照整合性の規定

または SQL 経由のアクセスではスキーマの知識が必要です。

Pervasive PSQL データベースの名前とロケーションは dbnames.cfg という名前のバイナリファイルに格納されま

す。 Pervasive PSQL ファイルのデフォルトの保存場所については、『Getting Started with Pervasive PSQL』の

「Pervasive PSQL ファイルはどこにインストールされますか？」を参照してください。

Pervasive PSQL データベースに関連するすべてのファイルはオペレーティングシステムから表示させることがで

きます。表 3 は関連するファイルを要約したものです。

ファイルサイズ

サイズの制限はファイルバージョンやページサイズ、および 1 ページあたりのレコード数によって異なるため、

次の表にまとめました。

ファイルバージョン 9.5 以上

データファイルの大サイズは 256 GB です。単一ファイルのサイズが 128 GB を超える場合は、 9.5 以上のファ

イル形式を使用する必要があります。

表 3 Pervasive PSQL データベースに関連するファイル

タイプ説明

データベース名の構成 dbnames.cfg ファイル。 Pervasive PSQL データベースの名前とロケーションを含むバイナリ

ファイルです。

データ（共通データ形式）ファイル名は、リレーショナルデータベースの場合デフォルトで、テーブル名 .MKD です。

データベーステーブルごとに対応する MicroKernel ファイルがあります。トランザクショナ

ルデータファイルでは、各ファイル名はアプリケーションが指定します。

データ辞書拡張子が DDF のファイル。『SQL Engine Reference』の「システムテーブル」を参照してくだ

さい。

6


次の表は、ファイルのレコードに圧縮が設定されていないことを前提にしています。レコード圧縮を使用する場

合は、 1 ページあたりに格納されるレコードがさらに増えることを考慮してください。『Pervasive PSQLProgrammer's Guide』の「ページサイズの選択」および「ファイルサイズの予測」を参照してください。

ファイルバージョン 9.0 以下

データファイルの大サイズは 128 GB です。単一ファイルのサイズが 64 GB を超える場合は、 9.0 以上のファ

イル形式を使用する必要があります。

次の表は、ファイルのレコードに圧縮が設定されていないことを前提にしています。レコード圧縮を使用する場

合は、 1 ページあたりに格納されるレコードがさらに増えることを考慮してください。『Pervasive PSQLProgrammer's Guide』の「ページサイズの選択」および「ファイルサイズの予測」を参照してください。

表 4 ファイルバージョン 9.5 以上のファイルサイズおよびページサイズの比較

1 ページあたりの

レコード数

大ページ数

（100 万単位）

各ページサイズ（バイト）に対するファイルサイズ（GB）

1,024 2,048 4,096 8,192 16,384

1 - 15 256 256 GB 256 GB 256 GB 256 GB 256 GB

16 - 31 128 128 GB 256 GB 256 GB 256 GB 256 GB

32 - 63 64 64 GB 128 GB 256 GB 256 GB 256 GB

64 - 127 32 32 GB 64 GB 128 GB 256 GB 256 GB

128 - 255 16 16 GB 32 GB 64 GB 128 GB 256 GB

256 - 511 8 N/A1 16 GB 32 GB 64 GB 128 GB

512 - 1023 4 N/A1 N/A1 16 GB 32 GB 64 GB

1024 - 2047 2 N/A1 N/A1 N/A1 16 GB 32 GB

2048 - 4095 1 N/A1 N/A1 N/A1 N/A1 16 GB

1 N/A は「適用外」を意味します。

表 5 ファイルバージョン 9.0 以下のファイルサイズおよびページサイズの比較

ファイルバージョン

1 ページあたり

のレコード数

大ページ数

（100 万単位）


512 1024 1536 2048 2560 3072 3584 4096 8192

9.0 1 - 15 256 128 128 128 128 128 128 128 128 128

9.0 16 - 31 128 64 128 128 128 128 128 128 128 128

9.0 32 - 63 64 32 64 96 128 128 128 128 128 128

9.0 64 - 127 32 16 32 48 64 80 96 112 128 128

9.0 128 - 255 16 N/A1 16 24 32 40 48 56 64 128

8 任意 16 8 16 24 32 40 48 56 64 N/A1

7 任意 16 8 16 24 32 40 48 56 64 N/A1

6 任意 16 4 4 4 4 4 4 4 4 N/A1

7


ファイルのセグメント化

デフォルトでは、データファイルは、オペレーティングシステムのファイルセグメントである 2 GB の限界を超

えるごとに自動的に分割されます。［セグメントサイズを 2 GB に制限］設定プロパティを使用すると、ファイル

を 2 GB のセグメントに分割するか、セグメント化しない 1 つのファイルとするかを指定することができます。セ

グメント化されていない大きなファイルを使用する利点は、ディスク I/O が効率的であるということです。この

ため、パフォーマンスの向上が期待できます。

この設定オプションはデータベースエンジンのパフォーマンスチューニング用プロパティの 1 つです。「PCC でエンジンの設定にアクセスするには」および「セグメントサイズを 2 GB に制限」を参照してください。

このプロパティはデフォルトでオンに設定されており、以前のリリースと同様 2 GB の限界でファイルはセグメ

ント化されます。このプロパティをオフに設定すると、ファイルは 2 GB の限界を超えて増大します。設定プロ

パティの追加情報については、「ファイルバージョンの自動アップグレード」も参照してください。

セグメントされていないファイルは、お使いのオペレーティングシステムによって指定されているファイルサイ

ズの制限を受けます。たとえば、 FAT32 ファイルシステムで［「セグメントサイズを 2 GB に制限」］の設定をオ

フにしてサイズの大きなファイルを作成すると、倍の 4 GB ファイルに拡張されます。以前作成したファイルが

既にセグメント化されている場合、そのセグメントはファイル上でそのまま残ります。

ファイルバージョンの自動アップグレード

設定プロパティの［作成ファイルのバージョン］に 9.0 以上が設定されている場合、バージョン 8.x ファイルはそ

のファイルサイズの限界（64 GB）に達すると自動的にバージョン 9.0 ファイルに変換されます。次の表に、こ

の動作をまとめて示します。

たとえば、バージョン 8.x ファイルでサイズが 5 GB の場合は、既に 2 GB 単位のセグメント化が行われています。

このファイルは既にセグメント化されているので、そのセグメントはファイルに存在し続けます。このようなファ

イルはその後もセグメント化が続行され、自動アップグレードが起こるサイズ 64 GB までそのサイズを増大させ

ることができます。この動作は、ファイルが既にセグメント化されているため、設定プロパティがオンまたはオ

フのどちらであっても同じです。ファイルのサイズが 64 GB を超えると、バージョン 9.0 ファイルの大許容サ

イズ 128 GB に達するまでセグメント化が続けられます。

バージョン 8.x ファイルでサイズが 1.5 GB の場合は、そのサイズを 2 GB まで増大させることができます。設定

プロパティがオフの場合、このファイルサイズが 2 GB になった時点で自動アップグレードが起こります。この

ファイルは非セグメント化ファイルとして、そのサイズをバージョン 9.0 ファイルの大許容サイズ 128 GB まで

増大させることができます。設定プロパティをオンに設定すると、 2 GB 単位のファイルのセグメント化が続行さ

れ、そのサイズを 64 GB のサイズまで増大させることができます。バージョン 8.x ファイル用の大許容サイズ

5 任意 16 4 4 4 4 4 4 4 4 N/A1

1 N/A は「適用外」を意味します。

［作成ファイルのバージョン］

設定プロパティの設定［セグメントサイズを 2 GB に制限］設定

プロパティの設定ファイルバージョンの自動アップグレードが

起こるファイルサイズ

9 （デフォルト）オン（デフォルト、オプションがチェッ

クされている）

64 GB （バージョン 8.x ファイルの大サイズ）

9 （デフォルト）オフ（オプションがチェックされていな

い）

2 GB（バージョン 8.x ファイルのセグメントの

サイズ）

表 5 ファイルバージョン 9.0 以下のファイルサイズおよびページサイズの比較


1 ページあたり

のレコード数

大ページ数

（100 万単位）


512 1024 1536 2048 2560 3072 3584 4096 8192

8


64 GB になった時点で、バージョン 9.0 への自動アップグレードが起こります。ファイルのサイズが 64 GB を超

えると、バージョン 9.0 ファイルの大許容サイズ 128 GB に達するまでセグメント化が続けられます。

［作成ファイルのバージョン］オプションは、データベースエンジンのファイル互換性用プロパティの 1 つです。

「PCC でエンジンの設定にアクセスするには」を参照してください。

メモファイルバージョンの自動アップグレードが動作するのは、 8.x ファイル形式から 9.0 ファイル形式と

いうパターンのみです。これ以外のファイルバージョンの組み合わせの場合、この自動アップグレードは動

作しません。たとえば、 8.x ファイル形式から 9.5 ファイル形式、あるいは 7.x ファイル形式から 9.0 ファイ

ル形式という組み合わせではアップグレードは起こりません。

アクセス方法

Pervasive PSQL データベースのデータにアクセスする 2 つの主な方法は、トランザクショナルおよびリレーショ

ナルアクセスです。

トランザクショナルでは、アプリケーションプログラムはデータレコード内を物理的と論理的のどちらの順序に

従ってでも自由に移動することができます。トランザクショナル API を使用することで、アプリケーションプロ

グラムは直接制御を備え、開発者はデータの基本構造の知識に基づいてデータアクセスを適化することができ

ます。 Btrieve は、トランザクショナルデータベースエンジンの 1 つです。

リレーショナルとは、データがテーブル、行、列の集まりとして表されるアクセス方法です。リレーショナルモデルは、開発者を基となるデータ構造から切り離し、データを単純な表形式で表します。 ODBC はリレーショナ

ルアクセス方法の 1 例です。

単一のアプリケーションが両方のタイプのアクセスを含むこともあります。たとえば、データの追加と変更には

トランザクショナルアクセスを使用し、データの照会およびレポート作成にはリレーショナルアクセスを使用す

ることができます。

アプリケーションプログラムが使用するアクセス方法を知っておく必要があります。これはインストールされる

Pervasive PSQL によって異なります。アクセス方法によって設定が異なります。特定のアクセス方法を適化す

るために設定をカスタマイズする必要があります。

利用するアプリケーションが使用するアクセス方法を知っていれば、トラブルシューティングも容易になります。

たとえば、アプリケーションプログラムが ODBC 経由でリレーショナルアクセスを使用している場合、データ

ベース管理システムではなく ODBC レベルの問題を解決する必要がある可能性があります。

設定のカスタマイズに関する作業とリファレンスについては、「設定リファレンス」を参照してください。

クライアント / サーバー通信

MKDE は、ローカルおよびクライアント / サーバーの 2 種類の処理モードをサポートします。ローカルモードで

データベースにアクセスするアプリケーションは、ローカルにある MKDE にアクセスします。ローカルの MKDEは、ローカルまたはネットワークのハードディスクの I/O を実行するワークステーションのオペレーティングシステムに要求を出します。

クライアント / サーバーモードでは、共有ファイルサーバー上で実行されるサーバー MKDE を使用します。ア

プリケーションプログラムがクライアント / サーバーモードでデータベースエンジンにアクセスしているとき

は、リクエスターがリモート MKDE に接続します。このリクエスターは、オペレーティングシステムがサポー

トするネットワークプロトコルを使用して、トランザクションレベルのリクエストおよびデータレコードを、ア

プリケーションプログラムおよびサーバー MKDE 間で受け渡しします。ファイル I/O 機能は、クライアント /サーバーモードのサーバー MKDE によって完全に処理され、ワークステーションには共有データファイルのた

めのオペレーティングシステムのハンドルは割り当てられません。データベース操作は、各ワークステーション

に代わってサーバーベースの MKDE によって実行されます。

処理モードは、アプリケーションプログラムそのものではなく、ワークステーションの設定によって決定される

ことに注意してください。つまり、アプリケーションはローカルとクライアント / サーバー、どちらのデータベー

9


スエンジンにもアクセスできます。アプリケーションプログラムは、ローカルモードからクライアント / サー

バーモードに切り替える際に再コンパイルする必要はありません。

ワークグループおよびサーバーエンジンはどちらのモードでも動作します。データベースエンジンと同一マシン

上のアプリケーションがエンジンにアクセスする場合、ローカルモードで動作します。データベースエンジンと

異なるマシン上のアプリケーションがエンジンにアクセスする場合、クライアント / サーバーモードで動作します。

クライアント / サーバーの設定は、 Pervasive PSQL のワークグループおよびサーバーバージョン用にカスタマイ

ズできます。スタンドアロンでもクライアント / サーバーでも、その設定を容易にするための構成の設定プロパ

ティが Pervasive PSQL Control Center （PCC）に含まれています。

クライアント / サーバー通信およびデータベースエンジンの設定に関する作業とリファレンスについては、「設

定リファレンス」を参照してください。

データベースコードページ

エンコードは文字セットを表す標準規格です。文字データは、コンピューターがデジタル処理できる標準形式に

変換する、つまりエンコードする必要があります。エンコードは、 Pervasive PSQL データベースエンジン（サー

バー）と Pervasive PSQL クライアントアプリケーションとの間で規定する必要があります。互換性のあるエン

コードを使用すれば、サーバーとクライアントでデータが正しく変換されます。

エンコードのサポートは、データベースコードページとクライアントエンコードに分割されています。この 2種類のエンコードは、別個のものですが相互に関係しています。説明を簡単にするために、データベースコード

ページとクライアントエンコードを一緒に説明します。『Getting Started with Pervasive PSQL』の「クライアント

用のネットワーク通信の設定」を参照してください。

ODBC DSN 作成オプション

『SQL Engine Reference』の「DSN と ODBC アドミニストレーター」を参照してください。このセクションでは

ODBC 接続文字列についても説明しています。

idshosts ファイルの使用

一般的には、アプリケーションは独自のファイルの場所情報を指定します。別の方法として、テキストファイル

idshosts の情報に基づいてファイル場所のマッピングを指定することができます。

idshosts ファイルは Pervasive PSQL （IDS）の一部でした。 IDS はコア製品から取り除かれましたが、 idshosts ファ

イルの設定は依然として可能です。

作成したアプリケーションでは idshosts によるマッピング機能を使用しないという場合は、［IDS の使用］設定を

オフにします。あるいは、既に idshosts を使用していたり、この代替方法を使用してファイルの場所をマップし

たいと考えている場合には、［IDS の使用］設定をオンにします。「IDS の使用」を参照してください。

idshosts ファイルを使用する場合は、ファイルにアクセスして内容を読み取る時間が必要となるため、パフォーマ

ンスが低下することに注意してください。

idshosts ファイルは、 Windows または Linux クライアントリクエスターでのみ使用できます。クライアントは

Windows または Linux 上の Pervasive PSQL サーバーと通信できます。

メモ［IDS の使用］をオンに設定するには、Pervasive PSQL 8.5 以降が必要です。リクエスターはデータベー

ス URI を使用して IDS 情報を示します。データベース URI は Pervasive PSQL 8.5 で追加されました。開発者

リファレンス『Pervasive PSQL Programmer's Guide』の「データベース URI」を参照してください。

［IDS の使用］にオンを設定した場合、［リモート MicroKernel エンジンの使用］もオンに設定する必要があ

ります。［リモート MicroKernel エンジンの使用］はデフォルトでオンです。

「IDS の使用」および「リモート MicroKernel エンジンの使用」を参照してください。

10


idshosts エントリの形式

idshosts ファイル内のエントリの形式については、ファイル自体のコメントを参照してください。コメントには

マッピングの例も提供されています。デフォルトで、 Windows プラットフォームの場合には、 idshosts ファイル

はデータベースクライアントのインストールディレクトリ下の \bin ディレクトリにインストールされます。

Linux の場合には、idshosts ファイルはデータベースクライアントのインストールディレクトリ下の \etc ディレ

クトリにインストールされます（例： /user/local/psql/etc）。

11


12

2
データベース管理の概念
データベース管理について

Pervasive PSQL v11 SP3 は、 Pervasive Software の MicroKernel Database エンジンを中心に構成された総合的なデー

タベース管理システムです。 Pervasive PSQL により、インストールおよび管理が容易になり、高度な信頼性とパ

フォーマンスが実現します。 Pervasive PSQL は事実上メンテナンスなしで何か月も何年も実行できますが、その

ユニークな機能を理解し、役に立つタスクの実行方法を学ぶことにより、そのすべてを自分のものにすることが

できます。このマニュアルでは、 Pervasive PSQL エンジンと関連するデータベースのチューニング、構成および

管理の方法を説明します。

「設定」

「データベースセキュリティ」

「データの保存と復元」

「トラブルシューティング」

「有用なユーティリティ」

13


設定

データベースエンジンのサーバーとクライアントそれぞれについて別個に構成することができます。この設定に

より、ビジネスの要件に基づいて、エンジンのパフォーマンスを適化することができます。

下図は、オペレーティングシステムでのアプリケーションプログラムからデータベースファイルへのフローを

示しています。データベースエンジンはアプリケーションプログラムとデータファイルの間に存在します。

図 1 データベースエンジン設定の概念図

サーバーに設定可能な項目は以下のとおりです。

アクセス

通信プロトコル

互換性（以前のバージョンの MKDE との互換性）

データの整合性

デバッグ

ディレクトリ

メモリの使用

パフォーマンス

クライアントに設定可能な項目は以下のとおりです。

アクセス



セキュリティ

アプリケーションの特性

これらの構成は PCC を使用して行います。設定に関する作業とリファレンスについては、「設定リファレンス」

を参照してください。

14

データベースセキュリティ


Pervasive PSQL データベースへのアクセスはいくつかの方法で保護されています。管理レベルのセキュリティは

オペレーティングシステムを介して設定されます。オペレーティングシステムのネイティブなセキュリティメカニズムを使用して、 Pervasive PSQL データベースを誰が管理できるかを制御することができます。

Pervasive PSQL はユーザーおよびグループレベルの関連するセキュリティも提供します。誰がどのような資格で

データにアクセスできるかを制御することができます。たとえば、 Pervasive PSQL データベース内の各テーブル

で、ユーザーまたはグループがテーブルに対し、 SELECT、 UPDATE、 INSERT、 DELETE、 ALTER TABLE を実

行できるかどうかを指定することができます。

データベース全体に対しパスワードを設定してセキュリティを確立することができます。この時点で、データベー

スにアクセスする権限を与えられたユーザーのみが Master という名前のデフォルトユーザーとなります。その

後、ユーザーやグループを追加することができます。

セキュリティは PCC 内で設定することができます。また、 GRANT および REVOKE の 2 つの SQL （StructuredQuery Language ：構造化照会言語）ステートメントもサポートされています。 GRANT および REVOKE を使用す

ると、列レベルでセキュリティを設定することもできます。

GRANT 構文はトランザクショナルオーナーネームと統合され、リレーショナルアクセスの場合にもオーナー

ネームを使用することができます。

セキュリティ、オーナーネーム、ユーザーおよびグループに関する詳細は、第 7 章を参照してください。

15


データの保存と復元

データのバックアップはデータベースの保護とトラブル復旧を確実にするための重要な手順です。 PervasivePSQL データベースをバックアップおよび復元するにはいくつかの方法があります。

Pervasive PSQL データベースにアクセスするアプリケーションを停止することができる仕事の場合、オペレー

ティングシステムやサードパーティ製ソフトウェアを使ってデータベースファイルをバックアップおよび復元

することができます。

アーカイブログはオペレーティングシステムのユーティリティを補完するのに使用できるもう 1 つのバック

アップ方法です。アーカイブログを使用すると、後のバックアップ以降のすべてのデータベース操作のログを

保存することができます。システム障害が発生した場合、バックアップからデータファイルを復元し、ログファ

イルから変更をロールフォワードして、データベースをシステム障害発生前の状態に戻すことができます。

Continuous オペレーションを使用すると、データベースエンジンが実行中でユーザーが接続中でも、データベー

スファイルのバックアップを行うことができます。Continuous オペレーションの開始後、データベースエンジン

はアクティブなデータファイルを閉じ、すべての変更をテンポラリデータファイル（デルタファイルと呼びま

す）に格納します。バックアップが完了したら、 Continuous オペレーションを解除します。データベースエンジ

ンはデルタファイルを読み込み、元のデータファイルにすべての変更を適用します。

データベースのバックアップおよび復元に関する追加情報については、「ログ、バックアップおよび復元」を参照

してください。

16

トラブルシューティング

トラブルシューティング

『Pervasive PSQL User's Guide』および『Getting Started with Pervasive PSQL』マニュアルには、トラブルシューティ

ングに関する情報が含まれています。『Getting Started with Pervasive PSQL』マニュアルには Pervasive PSQL 製品

のインストールに関するトラブルシューティングの情報が記載されています。『Pervasive PSQL User's Guide』には

FAQ のリストに加えて一般的なトラブルシューティングの情報が記載されています。

そのほかに使用できるトラブルシューティングの情報源には、顧客の実際の解決方法や一般的な問題に基づいた

Pervasive Software ナレッジベース、および Pervasive Software Web サイトのテクニカルサポートがあります。

17


有用なユーティリティ

Pervasive PSQL には、データベースの制御および管理に役立つようデザインされたさまざまなユーティリティが

付属しています。 Pervasive PSQL の主なユーティリティの一覧については、『Pervasive PSQL User's Guide』を参照

してください。カスタムインストールを実行した場合は、インストールされないユーティリティもあることに注

意してください。『Getting Started with Pervasive PSQL』を参照してください。

18

3
Pervasive コンポーネントのアーキテクチャについて
アーキテクチャ機能の説明

この章では、インストールや重要なアプリケーションの実行で問題が起こらない環境を提供するために設計され

た機能について説明します。以下の項目について説明します。

「Pervasive PSQL データベースエンジン」

「リレーショナルアーキテクチャの概要」

「エラーコード」

「Pervasive Auto-Reconnect」

19


Pervasive PSQL データベースエンジン

Pervasive PSQL のエンジンは、以下の 2 つのデータベースサブエンジンから構成されています。

MicroKernel Database エンジン（MKDE）。これは Pervasive PSQL アプリケーションをサポートする Btrieve/MicroKernel API を提供します。

SQL Relational Database エンジン（SRDE）。これは Pervasive PSQL アプリケーションをサポートする ODBC/SQL API を提供します。

共通アドレス空間

Pervasive PSQL は適化されたメモリアーキテクチャを使用し、トランザクショナルアクセスとリレーショナル

アクセスの両方に高いパフォーマンスを提供します。MKDE および SRDE は、共に同一プロセスアドレス空間で

動作し、それらの間の通信にかかる CPU 時間を小限にします。

行レベルのロック

同時にたくさんの更新や書き込みが行われたり、長時間に渡ってトランザクションが開かれたままになる複数

ユーザー環境では、行レベルのロックによってデータベースエンジンのパフォーマンスが向上します。

トランザクションはページ全体ではなく直接影響する行のみをロックします。クライアントはあるページのレ

コードの変更を、他のクライアントが同一ページの別のレコードを変更するのと同時に行うことができます。 2番目のアプリケーションは、初のアプリケーションが現在ロックしているのとまったく同じレコードを変更し

ようとしたときにのみ、待つことが必要になります。したがって、行レベルのロックは複数ユーザー環境で総体

的な待ち時間を減少させ、パフォーマンスを向上させます。

この機能は MicroKernel Database エンジン内で完全に透過です。この機能は常に動作していて、サポートされる

すべてのオペレーティングシステムプラットフォームと同様、サーバー、ワークグループでサポートされます。

この機能は、データファイル形式 v6.x 以降でサポートされます。

行レベルのロックはデータページに実装され、部分的にはキーページにも実装されます。可変ページには行レベ

ルのロックは適用されません。キーページの一部分の変更によって、キーエントリが別のページに移動すること

があります。その例として、キーページが分割または結合されるときがあります。これらの変更では、トランザ

クションが完了するまで完全なページロックが継続します。

MicroKernel Database エンジン

MicroKernel Database エンジン（MKDE）は、 Pervasive PSQL アプリケーションの Btrieve および MicroKernel APIをサポートしています。Pervasive PSQL Sever および Pervasive PSQL Workgroup は共に、エンジンと同じコンピュー

ター上で実行されるローカルアプリケーションをサポートします。サーバーの MKDE は、ローカルアプリケー

ションとリモート（クライアント / サーバー）アプリケーションの両方をサポートします。ワークグループの

MKDE は、リモートマシンで実行されるアプリケーションにも対応し、リモートマシン上の別のピアワークグ

ループエンジンによるリクエストを処理します。

MicroKernel エンジンには、 2 つのバージョンがあります。サーバーエンジンは、 Linux および Windows サーバー

上で実行可能です。ワークグループエンジンは Windows 上でのみ実行できます。また、このエンジンはシング

ルユーザーや小規模のワークグループ構成向けに設計されています。

デフォルトでは、ワークグループエンジンは Windows のログイン時に起動されるよう設定されています。ファ

イルが既にエンジンによって開かれている場合、ワークグループエンジンは、別のピアエンジンによるリクエス

トを処理できます。特定のマシンを設定してデータベースエンジンをゲートウェイとして使用することもでき、

ほかのワークグループエンジンがファイルを開くことを回避します。

Windows のサーバーエンジンは、インストールされると Windows のサービスとして実行されます。ワークグルー

プエンジンは、インストールされるとアプリケーションまたはサービスとして実行されます。アプリケーション

としてインストールされた場合は、ワークグループ MKDE の実行中は、それを表すトレイアイコンが表示され

ます。ワークグループ MKDE を実行していない場合、トレイアイコンは表示されません。サーバーエンジンの

20

Pervasive PSQL データベースエンジン

場合、またはワークグループエンジンがサービスとしてインストールされた場合、トレイアイコンは表示されま

せん。「サーバーとワークグループの技術的な相違」も参照してください。

Pervasive PSQL の Btrieve および ODBC API を使用することにより、アプリケーションからのローカルまたはリ

モートのデータベースエンジンへの接続情報が表示されない、分散型データベースアプリケーションを作成でき

ます。このアーキテクチャを使用すると、アプリケーションは共存するデータ、つまりアプリケーションと同じ

コンピューターで実行されているデータにアクセスすると同時に、リモートコンピューターのデータにもアクセ

スできます。さらに、 SQL データベースは、ローカルの MicroKernel Database エンジンによって処理される DDF（データ辞書ファイル）、およびリモートの MicroKernel Database エンジンによって処理されるデータファイル

（テーブル）を作成することにより、分散化が可能です。ローカルの MicroKernel Database エンジン以外のエンジ

ンにも処理されるこのような SQL データベースは、「混合アクセスデータベース」と呼ばれます。

混合アクセスデータベースには、以下の制約があります。

以下の機能はサポートされません。参照整合性（RI）、バウンドデータベース、トリガー、分散されたトラ

ンザクションアトミシティ（2 段階のコミットが必要）。

DDF にアクセスするには、 SRDE および MicroKernel Database エンジンを同じコンピューター上で実行する


RI の関係に関連するテーブルのデータファイル、トリガーが定義されているテーブル、またはバインドされ

た名前付きデータベースにあるテーブルは、リモートの MicroKernel Database エンジンによって開くことが

できません。

ファイルを開く際、SRDE は、リクエストを処理する MicroKernel Database エンジンのバージョンを確認しま

せん。バージョン 6.30 以降の MicroKernel Database エンジンの API サポート（たとえば、共有ロックなど）

を必要とするオペレーションが、バージョン 6.30 より前の MicroKernel Database エンジンに対して発行され

た場合は、エラーコードが返されます。 DDF を開く際、または DDF ファイルやデータファイルをバインド

しようとする際に、SRDE では、ローカルの MicroKernel Database エンジンがリクエストを処理していること

を確認します。

非同期 I/Oサーバー版の Windows 用 MicroKernel エンジンは、ページをディスクに書き込む際に非同期 I/O を使用します。

この機能はパフォーマンスを向上させます。 MicroKernel は直ちに Windows システムキャッシュまたは

MicroKernel のキャッシュにページを書き込みます。次に、 Windows はページがディスク上にあると信号を送っ

て、 MicroKernel が効率的に書き込み操作を行えるようにします。

MicroKernel でたくさんの並行オペレーションが同時に行われる場合、特にデータセットがストライプセットの

ディスクドライバー上にある場合には、読み込みパフォーマンスも向上しています。各読み込みは、ページが利

用可能になるまでワーカスレッドを待機させます。非同期 I/O では、オペレーティングシステムは複数の読み込

み要求の作業をプールして、読み込み操作をより効率的に行います。

SQL Relational Database エンジン

Pervasive PSQL Relational Database エンジン（SRDE）には、 Pervasive PSQL アプリケーション用の ODBC サポー

トが用意されています。

ODBC クライアントのプラットフォームには、Windows プラットフォームがあります。SRDE へのリモート ODBCアプリケーションアクセスには、 ODBC クライアントがインストールされている必要があります。これは、ネッ

トワーク上でクライアント側の ODBC 呼び出しを ODBC 通信サーバーに転送する専用 ODBC ドライバーです。

SRDE には以下のような機能が含まれています。

アトミックステートメント

双方向カーソル（ODBC カーソルライブラリを使用）

外部結合への対応

更新可能なビュー

ODBC のデータ型への対応

21


テーブル内の複数の可変長列

ODBC 通信サーバーは、以下の機能を実行します。

ODBC クライアント用ネットワーク通信のサポート

サーバー側 ODBC ドライバーマネージャーへの ODBC 呼び出しの転送（ODBC 呼び出しは SRDE に転送）

SQL および ODBC の詳細については、『SQL Engine Reference』の「SQL の概要」および「DSN と ODBC アドミ

ニストレーター」を参照してください。

22

リレーショナルアーキテクチャの概要

リレーショナルアーキテクチャの概要

下図は、サーバ版 Pervasive PSQL のリレーショナル ODBC インターフェイスのアーキテクチャコンポーネント

を示したものです。 SQL 接続マネージャーは、 MKDE および SRDE と同じプロセスアドレス空間で起動し実行

します。

Pervasive PSQL リレーショナルアーキテクチャ：サーバー

SQL 接続マネージャーは、大 2000 までの同時接続をサポートしており、 ODBC ドライバーマネージャーを使

用して SQL Relational Database エンジン（SRDE）を呼び出します。エンジンは MicroKernel の上に置かれます。

図 2 は、Pervasive PSQL のクライアント / サーバーリレーショナルアーキテクチャを示します。クライアントは、

TCP/IP を介してサーバーの SQL 接続マネージャーに接続します。このアーキテクチャは、サーバーエンジンお

よびワークグループエンジン（ローカルワークグループエンジンからリモートワークグループエンジンへの接

続にクライアント DSN を使用する場合）に適用されます。

図 2 クライアント / サーバーリレーショナルアーキテクチャ

23


図 3 は、ローカルワークグループエンジンからリモートデータベースへの接続に DSN を使用する場合のワーク

グループリレーショナルアーキテクチャを示します。リモートワークグループエンジンはリモートデータへの

ゲートウェイとなっていることを想定しています。

図 3 ワークグループリレーショナルアーキテクチャ

24

エラーコード

エラーコード

Pervasive PSQL の多くの上位コンポーネントは、その下の階層のコンポーネントからのエラーコードがそのま

ま渡されるため、呼び出し元アプリケーションまたはログファイルでエラーの実際の原因を明確に特定できるよ

うになりました。エラーコードがさまざまな状況に該当する可能性がある場合は、 Pervasive PSQL イベントログ

内の具体的な情報により、そのエラーの根本的な原因が特定されます。『Pervasive PSQL User's Guide』の「PervasivePSQL メッセージログ」を参照してください。

25


Pervasive Auto-Reconnect自動再接続機能の Pervasive Auto-Reconnect （PARC）を使用すると、クライアント / サーバーまたはワークグルー

プアプリケーションは、一時的なネットワークの中断時にも現在のデータベースオペレーションを中止しませ

ん。 Pervasive PSQL がネットワークの中断を検出すると、設定可能な指定時間ごとに自動的に再接続を試行しま

す。この機能はクライアントのコンテキストも維持するので、通信が再確立されたとき、ネットワークの中断が

起こったときとまったく同じようにデータベースアクセスが継続されます。

この機能は、アプリケーションのコンテキストを維持し、ネットワーク通信が中断されたときにクライアントま

たはサーバーがその時点でデータを送信しようとしていたかどうかにかかわらず、再接続を試行します。

ネットワークが中断したとき、一定の待ち時間の経過ごとに再接続が試行されます。すべての接続で、 0.5、 1、 2、4、 8 秒ごとに継続的に再接続が試行され、その後、自動再接続タイムアウトの値に達するまで 8 秒ごとに試行さ

れます。大待ち時間に達しても接続に成功しない場合、現在のオペレーションは失敗し、クライアントの接続

はリセットされます。大の待ち時間は 45 秒から 65,635 秒の間に設定できます。

この機能はデフォルトで使用不可になっています。この機能を動作させるには、クライアントとサーバーの両方

の設定で、「自動再接続の有効化（Windows のみ）」を選択する必要があります。待ち時間の値は、サーバー設定

の「自動再接続タイムアウト」を使って行うことができます。

備考

この機能は、 Btrieve、 ODBC、および DTI 接続でサポートされています。

Btrieve 通信サーバーは、トランザクションログディレクトリに *.PAR または *.SAR ファイルを書き込むことが

あります。これらは、サーバーがクライアントに送信しようとした新のアイテムのコンテキストを含むテンポ

ラリファイルです。再接続が行われると、クライアントはデータの再送信を要求します。サーバーはこれらの

ファイルを読んで適切なデータを取得します。これらのファイルは、データが読み取られたあと、接続が終的

に終了するときにサーバーが削除します。

26

4
設定リファレンス
Pervasive PSQL で使用できる構成方法および設定


「設定の概要」

「PCC による設定」

「CLI ユーティリティによる設定」

「設定のプロパティ」

「サービス設定プロパティ」

「サーバー設定プロパティ」

「Windows クライアント設定プロパティ」

「Linux クライアント設定プロパティ」

27


設定の概要

設定は、データベースエンジンとクライアントの設定を指定することができるプロセスです。設定は、 PervasivePSQL Control Center （PCC）を使用するか、またはコマンドラインインターフェイス（CLI）ユーティリティを

使用して指定できます。

PCC では、設定はエンジンまたはクライアントのプロパティです。「PCC でエンジンの設定にアクセスするには」

および「PCC でローカルクライアントの設定にアクセスするには」を参照してください。

コンポーネントの設定は任意です。設定を行わない場合は、各コンポーネントにはデフォルトの構成が読み込ま

れます。よい結果を得るためには、クライアントとエンジンコンポーネントで同じバージョンの PCC を使用し

てください。

設定を使用できるのは、以下の理由からです。

システムまたは Pervasive PSQL アプリケーションが、設定の変更を必要とするため。お使いのアプリケー

ションのマニュアルで、推奨される値を確認してください。複数のアプリケーションを同時に起動する場合

は、それぞれに推奨されている値の合計を使用します。複数のアプリケーションを順次起動する場合は、推

奨されているも高い値を使用します。

設定を適化して Pervasive PSQL が必要以上にメモリを使用せずにサービスを提供できるようにするため

（マニュアルに記述されている必要メモリは、コンピューターのリソースを大限に活用するためのガイドラ

インとなります）。

設定自体の説明は、「設定リファレンス」にあります。

設定の変更が有効になっていることを確認する

エンジンの設定によっては、設定内容の変更後にデータベースエンジンの再起動が必要になります。エンジンを

再起動することにより、設定が有効になります。この章の各設定の説明では、データベースエンジンの再起動が

必要かどうかを明示しています。また、設定の変更によりエンジンの再起動が必要な場合は、 PCC によりポップ

アップメッセージが表示されます。

CLI ユーティリティも、入力ファイルを使用しないでコマンドラインから設定を変更した場合には通知を行いま

す。入力ファイルを使用した場合は、常にエンジンの再起動が要求されます。「CLI ユーティリティによる設定」


コマンドラインからサーバーデータベースエンジンの停止および起動を行う場合は、『Pervasive PSQL User'sGuide』の以下のトピックを参照してください。

「Windows サーバー上でのサーバーエンジンの起動と停止」

「Linux 上でのデータベースエンジンの起動と停止」

ワークグループエンジンの停止および起動を行う場合は、『Pervasive PSQL User's Guide』の「Windows 上での

ワークグループエンジンの起動と停止」を参照してください。

さらに、クライアントプロパティを変更すると、クライアントを再起動する必要がある場合があります。クライ

アントの再ロードは、 Pervasive PSQL に依存するすべてのアプリケーションを終了して再起動するだけです。

別のマシンに接続する

ローカルクライアントのコンポーネントだけでなく、ローカルエンジンおよびリモートエンジンの構成も行え

ます。ただし、エンジンはそれぞれ個別に構成する必要があります。「PCC による設定」および「CLI ユーティ

リティによる設定」を参照してください。

PCC を使ってリモートマシンに接続しているときは、エンジンコンポーネントのみを表示および変更できます。

クライアントのコンポーネント（ワークグループエンジン、ワークステーションエンジン、クライアントマシ

ンなど）は、各マシンでローカルに設定する必要があります。

28

PCC による設定

PCC による設定

PCC では、設定はエンジンまたはクライアントのプロパティです。登録済みのエンジンはすべて Pervasive PSQLエクスプローラーの中にノードとして現れ、プロパティを介して設定を構成できます。 Pervasive PSQL エクスプ

ローラーにはローカルクライアントのみが現れます。

クライアントの設定は、各クライアントマシンで設定します。デフォルトで、 PCC はクライアントコンポーネ

ントと共にインストールされます。

PCC でエンジンの設定にアクセスするには

1 Pervasive PSQL エクスプローラーで、ツリーのエンジンノードを展開します（ノードの左の展開アイコンを

クリックします）。

2 設定を指定するデータベースエンジンを右クリックします。

3 ［プロパティー］をクリックします。

4 ツリー内で目的のオプションカテゴリをクリックし、そのカテゴリに含まれるオプションの設定内容を表示

します。

5 オプションで、 Shift+F1 を押すと、当該設定のヘルプを表示できます。

PCC でローカルクライアントの設定にアクセスするには

1 Pervasive PSQL エクスプローラーで、ツリーのローカルクライアントノードを展開します（ノードの左の展

開アイコンをクリックします）。

2 ［MicroKernel ルーター］を右クリックします。


4 ツリー内で目的のオプションカテゴリをクリックし、そのカテゴリに含まれるオプションの設定内容を表示

します。

5 オプションで、 Shift+F1 を押すと、当該設定のヘルプを表示できます。

29


CLI ユーティリティによる設定

設定のコマンドラインインターフェイス（CLI）バージョンは、 Pervasive PSQL Control Center のプロパティダイ

アログボックスと同様の設定機能を提供します。CLI 設定は、Pervasive PSQL v11 SP3 でサポートされる Windowsおよび Linux プラットフォームでのみ動作します。

Windows では、実行可能プログラムは bcfg.bat で、デフォルトで Program Files ディレクトリにインストールされ

ます。

Linux では、実行可能プログラムの名前は bcfg といい、デフォルトでは /usr/local/psql/bin ディレクトリ

にあります。 Linux 上で bcfg を起動するには、以下の条件に合致する必要があります。

Linux で bcfg を実行する要件に合致しているのに、実行に問題がある場合は、以下のトラブルシューティングガイドを参考にしてください。

構成の設定

設定は、コマンドラインから一度に 1 つずつ設定するか、入力ファイルに 1 つ以上を指定して設定することがで

きます。

ヒント入力ファイルを作成する便利な方法は、初に出力ファイルを作成することです。その後、出力ファ

イルを編集して、その編集したものを入力ファイルとして使用できます。編集が許可される種類については、

「入力ファイルの編集」を参照してください。

表 6 Linux での bcfg の実行要件

要件説明

Java Runtime Environment （JRE） bcfg を実行するために必要な JRE コンポーネントは、 Pervasive PSQL の一部としてイ

ンストールされます。 bcfg は、 Pervasive PSQL の一部としてインストールされる JREの「ローカル」バージョンを使用します。

Pervasive PSQL のサーバーまたは

クライアント

同一マシンに互換性のある Pervasive PSQL Server または Client が既にインストールさ

れている必要があります。『Getting Started with Pervasive PSQL』の「Pervasive PSQL Serverおよび Client （Linux 版）のインストール」を参照してください。

表 7 Linux での bcfg の実行に関するトラブルシューティングガイド

トラブルシューティングする状態説明

"java.lang.UnsatisfiedLinkError"というエラーを受け取った。

このエラーは、ファイルブラウザーアプリケーションを使用してスクリプトファイルを

ダブルクリックして bcfg を起動しようとしたときに、よく起こります。コマンドプロン

プトから bcfg を起動してください。

このエラーは、 LD_LIBRARY_PATH 変数が設定されていない場合に発生します。ユーザー

"psql" として bcfg を実行している場合、この変数は psql のプロファイルに設定されます。

この変数は、以下のコマンドを使用して明示的に設定することもできます。

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/psql/lib

以下のエラーメッセージが返

された。

" データベースエンジンに接

続できません。ターゲットマシンがアクセス可能で、かつ

エンジンが実行されているこ

とを確認してください。 "

このエラー状況は、ローカルサーバーを管理しようとした場合に発生します。

ローカルサーバーを管理するには、 pvsw グループのメンバーであるか root ユーザーであ

る必要があります。

『Getting Started with Pervasive PSQL』の「Linux での Pervasive PSQL のアカウント管理」も

参照してください。

30


エンジンの再起動

入力ファイルを使用した場合、 bcfg ユーティリティはファイルの処理後、データベースエンジンを再起動する

よう促します。再起動は、入力ファイル内の設定に関係なく適用されます。エンジンを停止して起動することに

より、その設定が有効になります。

コマンドラインから構成を行った場合は、 bcfg はその設定が再起動を要求する場合にのみ、データベースエン

ジンの再起動を促します。

エンジンの再起動方法については、「設定の変更が有効になっていることを確認する」を参照してください。

シナリオの例：コマンドラインから単一の設定を構成する

ネットワークが停止した場合に、クライアントがサーバーに再接続するかどうかに関係する設定をオンにしたい

とします。しかし、その設定の完全な名前がわかりません。その場合は、次の手順を踏みます。

1 コマンドプロンプトで「bcfg -H 再接続」と入力し、 Enter キーを押します。 Linux 版の場合は " 再接続 "の部分を "reconnect" に置き換えてください。

ユーティリティによって、文字列 " 再接続 " を含んでいるすべての設定がレポートされます。Linux の場合は

英語でレポートされます。

ID 設定名

-----------------------------

29 自動再接続の有効化

148 自動再接続の有効化

149 自動再接続タイムアウト

29 と 148 の 2 つが目的の設定であるようですが、必要な設定は一体どちらなのでしょうか？

2 「bcfg 29」と入力して、 Enter キーを押します。

ユーティリティは、設定 ID 29 について次のようにレポートします。

=====================

自動再接続の有効化

=====================

ID: 29

値 :Off

オプション :On Off

デフォルト値 :Off

説明 :< クライアント設定 > ネットワーク停止の場合に、クライアントがサーバーへの再接続を試みるかど

うかを指定します。再接続されたクライアントは、エラーに遭遇しなかったかのように処理を続行します。

説明によると、この設定はクライアントに適用されるものであり、現在 "Off" に設定されているということ

です。

3 「bcfg 29 on」と入力して、 Enter キーを押します。

ユーティリティは、システム設定 29 が更新されたことを知らせます。

4 設定が "On" になっていることを確認したい場合は、「bcfg 29」と入力して Enter キーを押します。

ユーティリティは、設定 ID 29 について次のようにレポートします。

=====================


=====================

31


ID: 29

値 :On





値が "On" に設定されていることに注目してください。

入力ファイルの編集

入力ファイルには、少なくとも 1 つの設定に対する完全なレコードが 1 つは含まれていなければなりません。出

力ファイルを基に入力ファイルを作成する場合、一部の設定を削除する際には、残す設定のレコードは完全な状

態であるようにしてください。

完全なレコードには、 ID と値のペアが少なくとも 1 つ含まれます。しかし、見やすくするために、先頭行の設定

の見出しから設定の説明までを含めることをお勧めします。たとえば、以下は「自動再接続の有効化」に関する

レコードの、推奨される小レコードです。

=====================


=====================

ID: 29

値 :On





入力ファイルに設定レコードを含めるという制限以外に、唯一変更が許可されるのは値の割り当てです。割り当

ては、オプションまたは範囲によってどのような値でも指定できます。

コマンド構文bcfg -I inputfile [-S server] [-U username]

[-P password] [-E]

または

bcfg -O outputfile [-S server] [-U username] [-P password] [-E]

または

bcfg ID [value] [-S server] [-U username] [-P password]

または

bcfg -H <keyword | ''keyword with spaces''> [-S server][-U username] [-P password]

32


オプション

-I ユーティリティに入力ファイルを渡す場合の必須パラメーター。

inputfile 指定したサーバーに関する 1 つまたは複数の設定のレコードと、各設定に割り当てる値を含んでいる

テキストファイル。

入力ファイルを作成する便利な方法は、初に出力ファイルを作成することです。その後、設定値を

必要に応じて編集し、その編集したものを入力ファイルとして使用できます。編集が許可される種類

については、「入力ファイルの編集」を参照してください。

-O ユーティリティ実行の出力結果をテキストファイルに送る場合の必須パラメーター。

outputfile ユーティリティの実行結果として、指定されたサーバーの現在の設定を含んでいるテキストファイル。

ID 設定を示す、一意な 2 桁または 3 桁の整数。

設定のいくつかは、設定を有効にするためにデータベースエンジンの再起動を必要とします。再起動

が必要な場合は、 bcfg が再起動を促します。「エンジンの再起動」を参照してください。

value 設定に割り当てる値。有効な値は、設定レコードの「オプション」または「範囲」に示されています。

Value を省略した場合、ユーティリティは現在の設定を返します。

Value を記述した場合、ユーティリティは値の割り当てを基に設定を変更します。

「シナリオの例：コマンドラインから単一の設定を構成する」を参照してください。

-H keyword 用のヘルプ検索オプション（つまり、 keyword 用のヘルプ）。Keyword を含む設定を検索するた

めのユーティリティで、 ID および設定名を返すか、あるいは " 一致する項目なし " を返します。次の

行を参照してください。

keyword ALLOW CLIENT-STORED CREDENTIALS や SUPPORTED PROTOCOLS など、設定の名前。

keyword は大文字小文字を区別しないことに注意してください。ただし、 keyword にスペースを入れる

場合は、文字列を二重引用符で囲む必要があります。

ユーティリティは、部分的なキーワードを基にヘルプを表示できます。たとえば、「-H クライアント」

と指定した場合は、設定名の一部に " クライアント " という語を含んでいるすべての設定が返されま

す。Linux 版の場合は設定名が英語なので " クライアント " の部分を "client" に置き換えてください。「-H a」と指定した場合は、設定名に "a" を含んでいるすべての設定が返されます。

-S 設定がリモートサーバー（ローカルサーバー以外のサーバー）に適用される場合の必須パラメーター。

server データベースエンジンを含んでいるリモートサーバーの名前、または IP アドレス。

-U server へのアクセスにユーザー名が必要な場合の必須パラメーター。

username server に接続するユーザー名。「Pervasive PSQL セキュリティ」も参照してください。

server がローカルマシンの場合、以下の条件を満たしていれば username と password は必要ありません。

管理者として、あるいは Pervasive_Admin グループのメンバーとしてローカルマシンにログインし

ている。

ローカルマシンがターミナルサービスを実行していない。

-P server へのアクセスにパスワードが必要な場合の必須パラメーター。

password server へ接続する username と一緒に使用するパスワード。「username」を参照してください。「PervasivePSQL セキュリティ」も参照してください。

-E inputfile の読み取り時、あるいは outputfile への書き込み時のエラーを無視します。

33


設定のプロパティ

各設定のプロパティを表形式で一覧表示します。

表 8 設定プロパティの表形式

表形式の列説明

名前プロパティの名前

データ型値のデータ型を定義します。データ型は次のとおりです。

Numeric

Bool(ean)

String

複数選択 - リストからいくつかの値を選択します。

単一選択 - リストから 1 つの値を選択する必要があります。

値現在の設定を示します。

単位値が数値の場合、必要に応じてこのフィールドに単位（KB、秒など）が示されます。

34

サービス設定プロパティ

サービス設定プロパティ

Windows サーバー環境では、 Pervasive PSQL Server はサービスとして起動します。サービスはインストール処理

の一部としてロードされ、完全インストールであれば常に使用可能な状態に設定されます。

PCC 内でサービスの起動ポリシーを構成することができます。

PCC を使ってサービスの起動ポリシーを設定するには

1 オペレーティングシステムの［スタート］メニューまたはアプリ画面から Control Center にアクセスします。

2 Pervasive PSQL エクスプローラーでサービスノードを展開します（下位ノードを表示するには、ノードの左

にある展開アイコンをクリックします）。

3 目的のサービス、 Pervasive PSQL （relational）または Pervasive PSQL （transactional）を右クリックします。


5 希望の起動ポリシーをクリックします。

6 ［OK］をクリックします。

ポリシー説明

手動サービスは、オペレーティングシステムの起動時に自動的に開始されません。オペレーティング

システムの起動後または再起動後に、サービスを手動で開始する必要があります。

自動サービスは、オペレーティングシステムの起動時または再起動時に自動的に開始されます。

無効サービスは、起動ポリシーが［手動］または［自動］に再設定されるまで機能しなくなります。

35


サーバー設定プロパティ

各 Pervasive PSQL データベースエンジンには、独自のサーバー設定オプションがあります。このセクションで

は、エンジンで使用可能な設定オプションについて説明します。

Windows および Linux プラットフォームで、グラフィカルなユーティリティ Pervasive PSQL Control Center を使用

して Pervasive PSQL サーバーを構成することができます。 bcfg コマンドラインインターフェイスユーティリ

ティを使用することもできます。 PCC については、『Pervasive PSQL User's Guide』の「Pervasive PSQL ControlCenter の使用」を参照してください。 bcfg については、「CLI ユーティリティによる設定」を参照してください。

次の表は、サーバー設定オプションとその設定項目の一覧を示します。

表 9 サーバー設定オプションおよび設定項目

設定オプション設定項目名

「アクセス」「リモートリクエストの受付」

「キャッシュエンジン接続の許可」

「クライアント保持の資格情報の容認」

「Authentication （Linux エンジンのみ）」

「Configuration File （Linux エンジンのみ）」

「クライアント資格情報の入力要求」

「ワイヤ暗号化」

「ワイヤ暗号化レベル」

「通信プロトコル」「自動再接続タイムアウト」

「自動再接続の有効化（Windows のみ）」

「リッスン IP アドレス」

「NetBIOS ポート（ワークグループエンジンのみ）」

「サポートプロトコル」

「TCP/IP マルチホーム」

「TCP/IP ポート」

「ファイル互換性」「作成ファイルのバージョン」

「システムデータ」

「データ整合性」「選択ファイルのアーカイブロギング」

「起動時間制限」

「オペレーションバンドル制限」

「トランザクション一貫性保守」

「トランザクションログ」

「ウェイトロックタイムアウト」

36


アクセス

［アクセス］には次の設定が含まれています。

「リモートリクエストの受付」

「キャッシュエンジン接続の許可」


「Authentication （Linux エンジンのみ）」

「Configuration File （Linux エンジンのみ）」

「デバッグ」「データバッファーのバイト数」

「キーバッファーのバイト数」

「トレースするオペレーションの選択」

「トレースファイルのロケーション」

「トレースオペレーションの実行」

「ディレクトリ」「DBNames 設定ファイルのディレクトリ」

「トランザクションログのディレクトリ」

「作業ディレクトリ」

「情報」サーバー名（表示のみ）

エンジンのバージョン（表示のみ）

エンジンのタイプ（表示のみ）

「メモリの使用」「起動時のリソース割当」

「非アクティブ時、小の状態に戻す」

「小の状態に戻す待ち時間」

「ソートバッファーサイズ」

「システムキャッシュ」

「パフォーマンスチューニング」「キャッシュ割当サイズ」

「通信スレッド数」

「ファイルの拡張係数」

「インデックスバランスの実行」

「セグメントサイズを 2 GB に制限」

「ログバッファーサイズ」

「MicroKernel の大メモリ使用量」

「I/O スレッド数」

「トランザクションログサイズ」

表 9 サーバー設定オプションおよび設定項目

設定オプション設定項目名

37


「クライアント資格情報の入力要求」



リモートリクエストの受付

この設定は、通信マネージャーが、リモートサーバーやクライアントワークステーションからのリクエストを受

け付けるかどうかを指定します。このオプションをオンにすると、通信マネージャーは、ネットワークでの存在

を通知します。

キャッシュエンジン接続の許可

クライアントがキャッシュエンジンを使用してサーバーに接続することをサーバーがサポートするかどうかを

指定します。オフに設定してもクライアントはサーバーに接続はできますが、キャッシュエンジンを使用するこ

とはできません。

クライアント保持の資格情報の容認

この設定をオンにした場合、データベースエンジンはクライアントに保管されているユーザー資格情報を受け付

けます。保管方法および場所は、クライアントのオペレーティングシステムによって異なります。

Windows クライアント：資格情報は Windows レジストリに格納されています。［クライアント資格情報の入

力要求］がオンに設定されている場合は、ポップアップダイアログで［ユーザー名とパスワードを保存］

チェックボックスをオンにすることによって、資格情報を保存できるようになります。代わりの方法として、

pvnetpass コマンドラインユーティリティを使用すると、保管されている資格情報を管理することができ

ます。

Linux クライアント：資格情報は、pvnetpass ユーティリティによって Pervasive レジストリに格納されます。

この設定をオフにした場合、データベースエンジンはクライアントに対し、資格情報が必要なデータベース操作

の対象から保管されている資格情報は強制的に除外します。このような資格情報は、アプリケーションから、ま

たはログインダイアログで提供する必要があります。この設定がオフであっても、ログインダイアログを使用し

て指定されれば、ログインダイアログはクライアント保持の資格情報を書き込もうとします。ただし、これは受

け入れられません。

クライアント保持の資格情報が認められている場合は、資格情報を知らなくても、誰でもその特定クライアント

のコンピューターの前に座り、保管されている資格情報を使ってデータベースにログインすることができます。

この動作は、個々のユーザーの厳密な認証は重要でない環境、たとえば、すべてのユーザーが同レベルのアクセ

ス権限を持っている、物理的にセキュリティ保護されているような環境では便利です。一方、権限のない人が存

データ型範囲デフォルト単位エンジン再起動の必要性

Boolean オン

オフ

オンなし必要


Boolean オン

オフ

オンなし必要


Boolean オン

オフ

オンなし不要

38


在したり、権限のあるユーザーがアクセス権限のレベルを変更しているような環境では、この設定はオフにして

おく必要があります。

関連項目：「クライアント資格情報の入力要求」

ログイン動作のまとめ

Authentication （Linux エンジンのみ）

以下のオプションは、サーバーエンジンへのアクセスに使用する認証のタイプを指定します。使用可能なオプ

ションは次のとおりです。

Emulate Workgroup Engine （ワークグループエンジンのエミュレート）。 Samba を使用してシステムのユー

ザーアクセスを認証する場合、この値を使用します。オペレーティングシステムによるセキュリティを回避

し、レジストリに RTSS パスワードを保存したくない場合は、［Emulate Workgroup Engine］を使用します。

Proprietary Authentication （using btpasswd）（専用認証（btpasswd の使用））。認証に Samba を使用せず、

ユーザーがサーバーにアカウントを持っていない場合、この値を使用します。 Linux システムへの接続に個

別のパスワードファイルを使用できます。

Linux サーバーで BTPASSWD の認証を使用する場合、クライアントからこのサーバーに接続するユーザー名

とパスワードを設定する必要があります。Pervasive PSQL Control Center または pvnetpass ユーティリティを使

用します。『Pervasive PSQL User's Guide』の「グループ、ユーザー、およびセキュリティ」および「pvnetpass」を参照してください。

Proprietary Authentication は、サーバーにより高いセキュリティ強度が必要で、 Linux サーバーで使用される

ユーザー認証方式と異なるユーザー名とパスワードが必要な場合に使用します。

表 10 ログイン設定動作のまとめ

クライアント資格

情報の入力要求

クライアント保持

の資格情報の容認

動作

オフオフ Pervasive PSQL クライアントは、ユーザーに入力を求めることも保管されている

資格情報を使用することもしないため、クライアントアプリケーションが

Btrieve オペレーションで資格情報を提供する必要があります。

オフオン資格情報がクライアントアプリケーションの Btrieve オペレーションで提供され

ない場合、クライアントは、ログインダイアログまたは pvnetpass によって保管

されている資格情報を利用できる場合は、それを使用します。どちらの方法でも

資格情報が提供されない場合は、接続に失敗します。ログインダイアログは表

示されません。

オンオフ資格情報がクライアントアプリケーションの Btrieve オペレーションで提供され

ない場合、クライアントはユーザーにログインダイアログを表示し、 Linux クラ

イアントはアクセス許可エラーを示すステータスコードを返します。ログイン

ダイアログまたは pvnetpass によって保管された資格情報は使用しません。

オンオン資格情報がクライアントアプリケーションの Btrieve オペレーションで提供され

ない場合は、保管されている資格情報を使用します。利用できる資格情報が保管

されていない場合、クライアントはユーザーにログインダイアログを表示し、

Linux クライアントはアクセス許可エラーを示すステータスコードを返します。


単一選択 3 つのオプションが

あります。次の解説を

参照。

Emulate Workgroup Engine（ワークグループエンジン

のエミュレート）

なし必要

39


Standard Linux Authentication （標準 Linux 認証）。認証に Samba を使用せず、ユーザーが Linux システムに

アカウントを持っている場合、この値を使用します。

PAM では、 Linux の標準認証が使用されます。 PAM は、 Linux サーバーで既存のユーザー名とパスワードを

使用したい場合に使用します。 pvnetpass ユーティリティを使用してクライアントからユーザー名とパス

ワードを指定することができます。 PAM は非常に柔軟で、 Linux 用のカスタムモジュールを多数提供してい

ます。詳細については、 PAM に関する Web サイトを確認ください。

Pervasive PSQL のインストールで PAM が検出された場合、 PAM を使用できるようインストールの設定を整

えます。 Pervasive PSQL のインストール後に PAM をインストールし、 PAM による標準認証を使用する場合

は、 Pervasive PSQL を再インストールする必要があります。これは、 PAM のインストールでファイルのコ

ピー、各種設定ファイルの作成、権限の設定、およびリンクの作成を行っているためです。 Pervasive PSQL を再インストールして PAM を検出し、その PAM 設定を正しく完了させる必要があります。

Pervasive PSQL をアンインストールし、再度インストールし直します。アンインストールとインストールの

手順については、『Getting Started with Pervasive PSQL』の「Pervasive PSQL Server および Client （Linux 版）の

インストール」の章を参照してください。

Samba と認証

上記の 3 種類の認証方法に加え、使用可能な場合は、 Samba を使用することもできます。サーバーは、 Samba を介して既知の FIFO 共有を作成します。 FIFO は、 $PVSW_ROOT/etc/pipe/mkde.pip に作成されます。

$PVSW_ROOT/etc/pipe は、 PVPIPE$ として Samba が共有する必要があります。

メモ末尾の $ は、この共有が非表示になることを意味します。 Pervasive PSQL クライアントコンポーネン

トが、 \\< サーバー >\PVPIPE$\mkde.pip （大文字小文字区別なし）として自動的にこのパイプへのアク

セスを処理します。明示的な処理を実行したり、このパイプにアクセスするようにアプリケーションを変更

したりする必要はありません。唯一の例外は、 Samba または Pervasive PSQL の設定のトラブルシューティン

グを行う場合です（後述の「トラブルシューティング」のセクションを参照）。

クライアントがリモートエンジンに接続し、エンジンがバージョンブロックで "Unix" と返した場合、まずレジ

ストリ（RTSS 設定）で認証情報を確認します。ユーザー名とパスワードがレジストリ内で見つからなかった場

合、クライアントは上記のパイプに接続し、サーバーからクライアント認証情報を受け取り、検証します。

認証されるためには、共有に接続し、パイプを読み取ることができる必要があります。これは、エンジンを使用

できるユーザーと使用できないユーザーを指定する一つの方法です。も簡単な方法は、 smb.conf （Samba の設

定ファイル）内の Samba の「valid users」の設定を使用する方法です。クライアントが認証されなかった場合、ス

テータス 3119 が返されます。

サーバーに Samba をインストールする場合は、インストールプログラムによって Samba 共有が設定されます。

Pervasive パイプの設定例を以下に示します。 ###################################################

[PVPIPE$]

comment = Pervasive pipes

path = /usr/local/psql/etc/pipe

force group = pvsw

# force group pvsw when accessing pipe - will be

# useful if primary group for this user is not pvsw

valid users = @pvsw

# only members of group pvsw will have access

oplocks = False

# Absolutely necessary - prevents caching on the client

40


###################################################

Samba を通じて共有されるファイルへのアクセスを構成する方法については、 Samba のマニュアルを参照してく

ださい。

メモ PVPIPE$ へのクライアントの読み取りアクセスを許可すると、そのクライアントはリモートでエンジ

ンへのアクセスが許可されます。

クライアントが正しく認証されることを確認するには、コマンドプロンプトで「\\< サーバー

>\pvpipe$\mkde.pip」と入力します。多数の疑問符（印刷不可能なシンボル）といくつかの印刷可能な文字

が表示され、警告音が鳴ります。表示されなかった場合、 Samba の設定で、このパイプを読み取る権限があるか

どうかを確認します。権限があるのにエラー 94 または 3119 が発生する場合は、 Pervasive PSQL Control Center でエンジンの設定プロパティを使用して、または pvnetpass を使用して、 RTSS 設定を確認します。

Configuration File （Linux エンジンのみ）

この設定は、 Linux で、ローカルファイルシステムの Windows クライアントへのエクスポートに使用される

smb.conf ファイルのロケーションを指定します。エンジンでは、リモートシステムの UNC パスを、正しいデー

タベースファイルへのローカル呼び出しに変換するときに、このファイルが必要です。

デフォルト値は /etc/smb.conf です。Samba の設定ファイルを別のロケーションにインストールした場合、正しい

パスとファイル名を入力します。

クライアント資格情報の入力要求

この設定は、ユーザー認証を必要とするデータベース操作中に利用できる資格情報がない場合、Windows PervasivePSQL クライアントがユーザーにログイン資格情報の入力を求めるかどうかを決定します。

この設定をオンにした場合、ほかの認証資格情報がないときには、ユーザーにログインダイアログを表示するよ

う、エンジンが Windows クライアントに要求します。この設定は、混合またはデータベースセキュリティが有

効になっている場合にのみ適用されます。ただし、いかなる状況下でも Linux クライアントには適用されません。

有効な資格情報が別の手段、たとえば、明示的な Btrieve Login （78）オペレーションやクライアントに保管され

ている資格情報によって提供される場合は、ログインダイアログは表示されません。

ユーザー資格情報を必要とする操作で、エンジンにデータベースコンテキストが指定されていない場合、エンジ

ンは、ユーザーは現在のデータベースヘのログインを試みていると見なします。

この設定をオフにして、新しいセキュリティモデルのいずれかを使用している場合は、ユーザー資格情報をプロ

グラムから提供する（クライアントに保管されている資格情報を提供するか、 Btrieve の Login （78）、 Open （0）、または Create （14）オペレーションによって提供する）必要があります。そうしないと、ログインの試行は認証

エラーで失敗します。

関連項目



String 適用外 /etc/smb.conf なし必要


Boolean オン

オフ

オフなし不要

41


ワイヤ暗号化

このプロパティは、指定されたクライアントまたはサーバーがネットワーク通信で暗号化を使用するかどうかを

指定します。デフォルト値は " 必要な場合 " です。これは、クライアントまたはサーバーは、通信ストリームの

相手側が暗号化を要求している場合にのみ暗号化を使用するという意味です。たとえば、サーバー A は［ワイヤ

暗号化］値を " 常時 " に設定しており、サーバー B は " しない " に設定しているとします。クライアントはこの

値を " 必要な場合 " に設定しています。この場合、クライアントはサーバー A と通信する場合には暗号化を使用

しますが、サーバー B と通信する場合には暗号化を使用しません。

次の表は、クライアント値とサーバー値の考えられる組み合わせを基に動作をまとめています。

ワイヤ暗号化レベル

この設定では、暗号化された通信で使用する暗号化キーの長さを指定します。次のレベルを使用できます。

128 ビット長のキーを使用する暗号化は、一般に「高度」暗号化と認められています。ほかの設定は、そのレベ

ルに応じて保護力は低下しますが、パフォーマンスは向上します。ある程度のレベルの暗号化は必要であるが、

より良いパフォーマンスを得るために、抑止レベルが低下することを受け入れるつもりである場合に適していま

す。


単一選択しない

必要な場合

常時

必要な場合なし必要

表 11 クライアント / サーバーのワイヤ暗号化組み合わせの結果

クライアント

設定

サーバー設定： " しない " サーバー設定： " 常時 " サーバー設定： " 必要な場合 "

しない暗号化を使用しません。ステータスコード 5001 暗号化を使用しません。

常時ステータスコード 5000 暗号化を使用します。レベルは、クラ

イアントとサーバー間でも高い［ワ

イヤ暗号化レベル］設定によって決定

されます。

暗号化を使用します。レベルは、クラ

イアントの［ワイヤ暗号化レベル］設

定によって決定されます。

必要な場合暗号化を使用しません。暗号化を使用します。レベルは、サー

バーの［ワイヤ暗号化レベル］設定に

よって決定されます。

暗号化を使用しません。


単一選択低

中

高

中なし必要

表 12 暗号化レベル値の意味

値説明

低 40 ビット暗号化キーを使用します

中 56 ビット暗号化キーを使用します

高 128 ビット暗号化キーを使用します

42


クライアントとサーバーの両方が暗号化を要求し、一方が他方よりも強度の高い暗号化レベルを指定した場合、2つのエンティティは強度の高いレベルを使って通信します。クライアントとサーバーの両方が暗号化を要求し、

一方が他方よりも強度の高い暗号化レベルを指定した場合、 2 つのエンティティは強度の高いレベルを使って通

信します。


［通信プロトコル］には次の設定が含まれています。

「自動再接続タイムアウト」

「自動再接続の有効化（Windows のみ）」

「リッスン IP アドレス」

「NetBIOS ポート（ワークグループエンジンのみ）」


「TCP/IP マルチホーム」

「TCP/IP ポート」

自動再接続タイムアウト

この設定は、接続不能となる前にクライアントがサーバーにどれだけの時間接続を試行するかを指定します。自

動再接続が有効になっているクライアントが、初に自動再接続が有効なサーバーに接続すると、サーバーはこ

の値をクライアントに通知し、両方のコンポーネントがネットワーク中断イベントでどれだけの時間再接続を試

行するかがわかるようにします。

自動再接続の有効化（Windows のみ）

この設定は、ネットワークの中断時にクライアントが再接続を試行することをサーバーにサポートさせるかどう

かを指定します。オンに設定すると、自動再接続が有効になります。

自動再接続は、この設定をクライアント側の設定でも有効にしておかない限り、そのクライアント接続では有効

になりません。

接続不能となる前にクライアントがサーバーにどれだけの時間再接続を試行するかを指定します。前述の「自動

再接続タイムアウト」を参照してください。


Numeric 45 - 65535 180 秒必要


Boolean オン

オフ

オフなし必要

43


リッスン IP アドレス

このオプションは、［TCP/IP マルチホーム］がオフの場合に MicroKernel が受信待ちする IP アドレス（1 つまた

は複数）を指定します。このオプションは、［TCP/IP マルチホーム］がオンの場合は無視されます。

複数の IP アドレスを指定できますが、その場合は各アドレス間をカンマで区切る必要があります。このアドレス

文字列は IPv4 アドレスと IPv6 アドレスの組み合わせも可能です。 Pervasive PSQL でサポートされる IPv6 アドレ

ス形式が使用できます。『Getting Started with Pervasive PSQL』の「ドライブベースの形式」を参照してください。

NetBIOS ポート（ワークグループエンジンのみ）

このオプションは、MicroKernel が受信待ちをする NetBIOS ポートを指定します。サーバーエンジンでは NetBIOSをサポートしません。

サポートプロトコル

この設定では、データベースエンジンがクライアント接続の受信待ちをするプロトコルを指定します。 2 つ以上

のプロトコルを指定した場合、エンジンは指定したすべてのプロトコルで接続の受信待ちをします。デフォルト

は TCP/IP です。使用可能なオプションは次のとおりです。

TCP/IP

SPXII

NetBIOS

サーバーとクライアントの両方で有効なプロトコルが低 1 つないと、通信を行うことができません。

Pervasive PSQL Workgroup

NetBIOS が有効なのは Pervasive PSQL Workgroup のみで、 Pervasive PSQL Server では無効です。

Linux

Linux プラットフォームで動作する Pervasive PSQL でサポートされるプロトコルは TCP/IP のみです。したがって、

サポートプロトコルの設定は、 Linux では使用できません。


String 有効な IP アドレス（単独または複数）。複数の

アドレスの場合は各アドレス間をカンマで区切

ります。

0.0.0.0 なし必要


Numeric 33 ～ 254 66 なし必要


複数選択次の解説を

参照。

TCP/IP なし必要

44


TCP/IP マルチホーム

このオプションは、データベースエンジンがすべてのネットワークインターフェイスでクライアント接続の受信

待ちをするかどうかを指定します。オンに設定した場合、データベースエンジンはすべてのネットワークイン

ターフェイスで受信待ちをし、［リッスン IP アドレス］オプションの IP アドレスは無視されます。この設定をオ

フにすると、クライアント通信に使用するデータベースエンジンへのアドレスを［リッスン IP アドレス］に指

定する必要があります。

TCP/IP ポート

これは、リレーショナルインターフェイスで使用されるポート番号を設定します。

このポート番号は、このサーバーを指定するクライアント DSN に定義されたものと同じ番号である必要がありま

す。クライアント DSN でポート番号を変更する方法については、『SQL Engine Reference』の「クライアント DSN用の詳細な接続属性」を参照してください。

ポートに関する詳細については、『Getting Started with Pervasive PSQL』の「デフォルトの通信ポートの変更」を参

照してください。

ファイル互換性

［ファイル互換性］には次の設定が含まれています。

「作成ファイルのバージョン」

「システムデータ」

作成ファイルのバージョン

この設定は、新しく作成されるすべてのファイルの形式を指定します。 10.x のデータベースエンジンは、既存の

ファイル形式を使用してファイルに書き込みができます。つまり、書き込みを行うとき、バージョン 7.x のファ

イルにはバージョン 7.x のファイル形式、バージョン 8.x のファイルにはバージョン 8.x のファイル形式、という

ように適切なファイル形式を使用します（10.x のデータベースエンジンは、 5.x、 6.x、 7.x、 8.x および 9.x バー

ジョンで作成されたファイルの読み取りが可能です。）

バージョン 6.x、 7.x、または 8.x は、旧バージョンの MicroKernel と互換性を保つ必要がある場合にのみ指定しま

す。以前のファイルバージョンを指定しても、既存の 9.x ファイルには影響しません。

メモ辞書ファイル（DDF）は 6.x またはそれ以降のファイル形式で作成する必要があります。データベース

の新規作成ウィザードは［作成ファイルのバージョン］設定を使用します。データファイルは、サポートさ

れている以前のファイル形式のいずれでもかまいません。 DDF だけは 6.x またはそれ以降のファイル形式を

使用する必要があります。


Boolean オン

オフ

オンなし必要


Numeric 256 ～ 65535 1583 なし必要


単一選択 6.x -9.x 9.x なし不要

45


システムデータ

システムデータは各レコード内の隠されている重複のないキーを参照します。 MicroKernel はトランザクション

一貫性保守を確実にするのに行を一意に識別できることが必要なため、ファイルは重複のないキーを定義するか

またはシステムデータを含める必要があります。デフォルト値は［必要な場合］です。使用可能な値は、次のと

おりです。

［なし］。デフォルトでは、システムデータはファイル作成時に追加されません。 Create オペレーションを使

用するアプリケーション開発者はこの設定を無効にして変更することができます。

［必要な場合］。ファイルが、重複のないキーを持たない場合、ファイル作成時にそのファイルにシステム

データが追加されます。

［常時］。ファイルが、重複のないキーを持つかどうかに関係なく、システムデータが、ファイル作成時に常

に追加されます。

メモシステムデータ設定は既存のファイルには影響しません。この設定は新規ファイルがどのように作成

されるかにのみ影響します。

［システムデータの作成］を有効にしないで作成され、重複のないキーを持たないファイルにトランザクショ

ン一貫性保守を適用したい場合は、［システムデータの作成］を［常時］または［必要な場合］に設定した

後、ファイルを再作成する必要があります。

SRDE は常に、システムデータを含むファイルを作成します。この情報は、 SQL、 OLE-DB、 JDBC、また

Btrieve API 以外のあらゆる方法で作成されたファイルに当てはまります。

インデックスはユーザーによって削除されることがあるため、ファイルが重複のないキーを持っている場合でも、

システムデータを追加したい場合があります。

データ整合性

［データ整合性］には次の設定が含まれています。

「選択ファイルのアーカイブロギング」

「起動時間制限」

「オペレーションバンドル制限」



「ウェイトロックタイムアウト」

選択ファイルのアーカイブロギング

この設定は、ファイルのバックアップを容易にするアーカイブログを MicroKernel に実行させるかどうかを指定

します。システム障害が発生した場合、アーカイブログファイルおよび BUTIL -ROLLFWD コマンドを使用し


単一選択次の解説を

参照。

必要な場合なし不要


Boolean オン / オフオフなし必要

46


て、後にバックアップを取ったときからシステム障害が発生するまでの間にファイルに加えられた変更を修復

できます。

MicroKernel にアーカイブログを実行させるには、アーカイブログを実行するファイルのあるボリュームにアー

カイブログ設定ファイルを作成し、エントリを追加することによりファイルを指定する必要があります。アーカ

イブログの詳細については、「アーカイブログおよび Continuous オペレーションについて」を参照してください。

起動時間制限

この設定は、システムトランザクションを起動させるタイムリミットを指定します。 MicroKernel は、［オペレー

ションバンドル制限］か［起動時間制限］のいずれかで設定された値に達した場合、またはキャッシュの再利用

が必要な場合に、システムトランザクションを起動します。

オペレーションバンドル制限

このオプションは、システムトランザクションを起動するのに必要なオペレーション（1 つの任意のファイルで

実行）の大数を指定します。 MicroKernel は、［オペレーションバンドル制限］か［起動時間制限］のいずれか

で設定された値に達した場合、またはキャッシュの再利用が必要な場合に、システムトランザクションを起動し

ます。

MicroKernel Database エンジンでは、各ユーザートランザクション（Begin Transaction から End Transaction または

Abort Transaction まで）が 1 つのオペレーションとして扱われます。たとえば、 Begin Transaction オペレーション

と End Transaction オペレーションの間に 100 の Btrieve オペレーションがある場合、 Begin Transaction オペレー

ションと End Transaction オペレーションを含む 102 の Btrieve オペレーションが、1 つのオペレーションとして扱

われます。

トランザクション一貫性保守

トランザクション一貫性保守は、システム障害時に正常終了していたトランザクションがデータファイルにコ

ミットされることを保証する点以外はトランザクションログと同じです。

トランザクションログとトランザクション一貫性保守の詳細については、「トランザクションログおよびトラン

ザクション一貫性保守」を参照してください。

メモ［トランザクション一貫性保守］をオンにしている場合、一部のファイルで、トランザクションの一

貫性が保守されないことがあります。ファイルは、少なくとも 1 つは重複のないキーを含んでいるか、ファ

イル作成時に［システムデータ］設定が " 常時 " または " 必要な場合 " に設定されている必要があります。

そうしないと、ファイルに対する変更はトランザクションログに書き込まれません。トランザクション一貫

性保守およびシステムデータの詳細については、開発者リファレンスの『Pervasive PSQL Programmer's Guide』を参照してください。


Numeric 1 - 1800000 10000 ミリ秒不要


Numeric 1 ～ 65535 65535 なし不要


Boolean オン

オフ

オフなし必要

47


システムデータは既存のファイルには影響しないため、重複のないキーを持たず、［システムデータの作成］

を有効にしないで作成したファイルは再作成する必要があります。これらのファイルを再作成する前に［シ

ステムデータの作成］を必ず有効にしてください。

注意ゲートウェイロケーターファイルにより、同一ファイルサーバー上の異なるディレクトリにある複

数のファイルを異なるエンジンが管理することができます。データベースが異なるディレクトリにある複数

のファイルを含んでいる場合は、データベース内のすべてのデータファイルを同一データベースエンジンで

管理する必要があります。同一データベース内のファイルを複数のデータベースで管理する場合、データベー

スの整合性およびトランザクションアトミシティは保証されません。起こり得る問題を回避する方法につい

ては、「ロケーターファイルのリダイレクト」を参照してください。

関連する設定

詳細については、「トランザクションログ」にある同様の「関連する設定」を参照してください。

トランザクションログ

この設定は、データファイルに影響するすべてのオペレーションをログに記録することにより、 MicroKernel がトランザクションのアトミシティを確実にするかどうかを制御します。

関連する［トランザクション一貫性保守］の設定がオンになっている場合、ロギングは自動的に行われ、［トラン

ザクションログ］設定は無視されます。

トランザクションログとトランザクション一貫性保守の詳細については、「トランザクションログおよびトラン

ザクション一貫性保守」を参照してください。

メモ［トランザクションログ］をオンにしている場合、一部のファイルで、トランザクションの一貫性が

保守されないことがあります。ファイルは、少なくとも 1 つは重複のないキーを含んでいるか、ファイル作

成時に［システムデータ］設定が " 常時 " または " 必要な場合 " に設定されている必要があります。そうし

ないと、ファイルに対する変更はトランザクションログに書き込まれません。トランザクション一貫性保

守およびシステムデータの詳細については、開発者リファレンスの『Pervasive PSQL Programmer's Guide』を参照してください。

システムデータは既存のファイルには影響しないため、重複のないキーを持たず、［システムデータの作

成］を有効にしないで作成したファイルは再作成する必要があります。これらのファイルを再作成する前に

［システムデータの作成］を必ず有効にしてください。

注意使用するデータベースがデータファイル間のトランザクションアトミシティを必要としない場合を除

いては、トランザクションログの設定をオフにしないでください。トランザクションログがオフに設定され

ている場合、複数ファイルのデータベースのデータの整合性は保証されません。


Boolean オン

オフ

オンなし必要

48


［トランザクションログ］の設定をオフにすることを、使用するアプリケーションのベンダーがサポートし

ていない場合は、オフにしないでください。

関連する設定

サーバー設定の［トランザクション一貫性保守］はトランザクションログに似ていますが、より高レベルのデー

タ安全性を提供し、パフォーマンスは低レベルとなります。サーバーの設定にある［ログバッファーサイズ］お

よび［トランザクションログサイズ］はトランザクションログと関連しています。［ログバッファーサイズ］

を使用すると、トランザクション一貫性保守とパフォーマンスとのバランスを構成することができます。ログ

バッファーが大きいほどディスクに書き込まれる回数が少ないため、パフォーマンスが向上します。ただし、ロ

グバッファー内のデータベースの変更はシステム障害が起こった場合保守されません。

「トランザクションログサイズ」は、新しいセグメントを開始する前に各ログファイルセグメントがどれだけの

サイズになることができるかを制御します。

Btrieve または SQL トランザクションが使用されない場合は、これらすべての設定は無視されることに注意して

ください。

ウェイトロックタイムアウト

レコードロックの競合が発生した場合、データベースエンジンとそのクライアントは同等の再試行メカニズムを

使用します。エンジンは、ウェイトロックタイムアウト時間内に要求されたレコードのロックを取得できなかっ

た場合には、該当するステータスコードと共に制御をアプリケーションに返します。

ウェイトロックタイムアウト設定は、ロックの競合が発生した場合に次のような利点をもたらします。

データベースエンジンは、ロックの解除を待つ間にほかのリクエストの処理を続行できる

複数のスレッドがロックされたリソースを待っている場合、スレッドキューの能力が向上する

ネットワークトラフィックが軽減することによって、ネットワークのパフォーマンスが向上する

ウェイトロックタイムアウトは、次のような状況の場合にのみ適用されます。

リレーショナルインターフェイスを使用するアプリケーション。

Windows アプリケーション。このようなアプリケーションは、ウェイトロックタイムアウトの設定にかか

わらず、 1 秒以内でロックエラーを受け取ります。

ウェイトロックタイムアウトは、 Windows または Linux 上の Pervasive クライアントを介してトランザクショナ

ルインターフェイスを使用するアプリケーションには適用されません。このようなアプリケーションは、ロック

の競合が検出された直後にロック競合エラーを受け取るか、あるいはロックが解放されるのを待ち続けるかのい

ずれかです。その時点で、アプリケーションは競合の処理方法（再試行、待機など）を決定します

トランザクショナルインターフェイス API は、レコードロック状況を処理するための制御を提供します。詳し

い解説は Pervasive PSQL ソフトウェア開発キット（SDK）の開発者リファレンス『Btrieve API Guide』を参照し

てください。ここでは、制御のメカニズムを簡単に説明します。

明示的レコードロック - 読み取り操作にロックバイアス（100、 200、 300 または 400）を加えると、レコー

ドの読み取り時にウェイトするかどうかを指定できます。

トランザクション中の暗黙ページロック - ほとんどのページロックの競合は低レベルなロックであるため

に回避されますが、ロックバイアス 500 を加算すれば、トランザクションがページロックの発生によって

ウェイト状態になることを避けられます。

排他ファイルロック - 明示的ファイルロックを避けるために並行トランザクションを使用します。ファイル

を排他的に開けなかった場合、リクエストは常に直ちに返されます。


Numeric 0 - 2147483647 15000 ミリ秒必要

49


デバッグ

［デバッグ］には次の設定が含まれています。

「データバッファーのバイト数」





データバッファーのバイト数

この設定は、 MicroKernel がトレースファイルに書き込むデータバッファーのサイズを指定します。この設定を

使用するには、［トレースオペレーションの実行］設定をオンにしておく必要があります。指定するサイズは、

必要とするトレースのレベル（データ全体のバッファーの内容を確認する必要があるのか、またはあるレコード

を特定できるだけのバッファー内容があれば十分なのかなど）に左右されます。

キーバッファーのバイト数

この設定は、 MicroKernel がトレースファイルに書き込むキーバッファーのサイズを指定します。この設定を使

用するには、［トレースオペレーションの実行］設定をオンにしておく必要があります。指定するサイズは、必

要とするトレースのレベル（キー全体のバッファー内容を確認する必要があるのか、またはあるキーを特定でき

るだけのバッファー内容があれば十分なのかなど）に左右されます。

トレースするオペレーションの選択

トレースされる Btrieve インターフェイスのオペレーションコードにはチェックマークが付けられています（選

択されています）。リストからトレースするオペレーションを選択します。


Numeric 0 - 65535 128 バイト不要


Numeric 0 - 255 128 バイト不要



参照。

すべてなし不要

Abort Transaction (21) Get Position (22)

Begin Transaction (19) Get Previous (7)

Clear Owner (30) Get Previous Extended (37)

Close (1) Insert (2)

Create （14） Insert Extended (40)

Create Index (31) Open (0)

50


トレースファイルのロケーション

この設定は、 MicroKernel がトレース情報を書き込むトレースファイルを指定します。ファイル名には、ドライ

ブまたはボリュームの指定およびパスが含まれていること、もしくは UNC パスを使用していることが必要です。

トレースファイルをデフォルトのロケーションに配置しない場合は、別のパスやファイル名を入力します。

Pervasive PSQL ファイルのデフォルトの保存場所については、『Getting Started with Pervasive PSQL』の「PervasivePSQL ファイルはどこにインストールされますか？」を参照してください。

メモ ODBC トレースと MicroKernel トレースに同じトレースファイル名を使用しないでください。

Delete (4) Reset (28)

Drop Index (32) Set Directory (17)

End Transaction (20) Set Owner (29)

Extend(16) Stat (15)

Find Percent (45) Step First (33)

Get By Percent (44) Step Last (34)

Get Direct/Chunk (23) Step Next (24)

Get Directory (18) Step Next Extended (38)

Get Equal （5） Step Previous

Get First （12） Stop (25)

Get Greater (8) Step Previous Extended (39)

Get Greater or Equal (9) Unlock (27)

Get Last （13） Update (3)

Get Less or Equal (11) Update Chunk (53)

Get Less Than (10) Version (26)

Get Next (6)

Get Next Extended (36)


String 適用外 file_path\PSQL\bin\mkde.tra なし不要

51


トレースオペレーションの実行

この設定は、各 Btrieve インターフェイス呼び出しをトレースし、その結果をファイルに保存することを可能にす

るトレース機能を有効にするかどうかを指定します。開発者は、トレース機能を使用するとアプリケーションの

デバッグができます。 MicroKernel は、強制書き込みモードを使用してトレースファイルに書き込みを行うため、

MicroKernel が正常にアンロードされなかった場合でも、データがファイルに書き込まれます。 MicroKernel のパ

フォーマンスは、リクエストを受け取る頻度によって大幅に影響を受けることがあります。このオプションを有

効にする場合は、［トレースファイルのロケーション］を指定してください。

メモトレースを開始または終了するためにエンジンを再起動する必要はありません。トレースのオン / オフ

は実行中に行ってエンジンに直接変更を適用することができます。 PCC から、変更を有効にするためにエン

ジンを再起動するようにメッセージが表示されても、この設定については無視してかまいません。

ディレクトリ

［ディレクトリ］には次の設定が含まれています。

「DBNames 設定ファイルのディレクトリ」


「作業ディレクトリ」

DBNames 設定ファイルのディレクトリ

この設定は、データベース名設定ファイルの別のロケーションへのパスを指定します。

サーバーエンジンの場合、ディレクトリパスではなくローカルファイルのパスです。ワークグループエンジン

の場合、ワークグループ MicroKernel にアクセス可能なリモートパスを指定できます。デフォルト値は、エンジ

ンのプラットフォームによって異なります。

Windows プラットフォーム： application_data_directory\

Linux サーバー： /usr/local/psql/etc

設定ファイルをデフォルトのロケーションに配置しない場合は、有効なパスを入力します。

トランザクションログのディレクトリ

この設定は、 MicroKernel が、トランザクションログを保存するために使用するロケーションを指定します。パ

スは有効なパスであり、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。デフォ

ルト値は、オペレーティングシステムによって異なります。


Boolean オン

オフ

オフなし不要


String 適用外環境によるなし必要


String 適用外環境によるなし必要

52


エンジンは、「トランザクション一貫性保守」または「トランザクションログ」の設定がオンでない場合、この

設定を無視します。

注意複数のデータベースエンジンで同一のディレクトリを使用してはいけません（たとえば、 2 つ以上の

ワークグループエンジンの［トランザクションログのディレクトリ］にリモートサーバーのディレクトリ

を指定するなど）。このような環境では、各エンジンはログのロールフォワードが必要になった場合に、ど

のトランザクションログセグメントを使用するかを決定できません。

データベースエンジンの使用率が高い場合には、データファイルが存在するのとは物理的に別のボリュームにト

ランザクションログが保持されるようにシステムを構成する必要があります。高負荷の下では、単一ドライブで

I/O 帯域幅を競う代わりに、ログの書き込みとデータファイルの書き込みを別のドライブに分ける方が一般的に

パフォーマンスがよくなります。トランザクションログの詳細については、「トランザクションログおよびトラ

ンザクション一貫性保守」を参照してください。

作業ディレクトリ

この設定は、多数のインデックスを作成するようなオペレーションで、テンポラリファイルを保存するために使

用される MicroKernel 作業ディレクトリのロケーションを指定します。ディスク容量に制限がある場合は、この

オプションを使用して十分な空き容量があるボリュームに作業ディレクトリを指定できます。

デフォルト値はありません。ただし、作業ディレクトリを指定しない場合、データファイルのロケーションがデ

フォルトになります。作業ディレクトリを指定するには、［作業ディレクトリ］フィールドにパスを入力します。

パスには、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。

情報

情報には、次のような表示のみの項目が示されます。

メモリの使用

［メモリの使用］には次の設定が含まれています。

「起動時のリソース割当」




「システムキャッシュ」


String 適用外データファイルと

同一ディレクトリ

なし必要

表示のみの項目説明

サーバー名データベースエンジンが実行されているマシンの名前。

エンジンのバージョンデータベースエンジンのリリースバージョン。

エンジンの種類データベースエンジンの製品カテゴリ。たとえば、「サーバー」や「ワークグループ」。

53


起動時のリソース割当

この設定は、 MicroKernel の起動時に、スレッドやメモリバッファーを含むリソースを割り当てるように

MicroKernel に指示します。起動時のリソース割り当てには L1 キャッシュに加えてバックグランドスレッドも含

まれます。 Pervasive PSQL コンポーネントは必要に応じてリソースを自動的に割り当てます。このため、ほとん

どの場合、この設定はオフ（デフォルト）にすることができます。

この設定がオフの場合、初のオペレーションが要求されるまでリソースが割り当てられません。お使いのシス

テムが多数のユーザーをサポートする場合は、この設定をオンにする方が適切です。

この設定を初めてオンにしたときに、 Windows の動作方法のため、メモリの割り当てに顕著な違いが見られない

かもしれません。MicroKernel がその L1 キャッシュを割り当てる場合、Windows オペレーションシステムは単に

メモリのページを確保するだけで、実際にそれらを MicroKernel にはコミットしまません。その後、 MicroKernelが実際にキャッシュメモリにアクセスすると、Windows は実際の物理ページをコミットするので、Pervasive PSQLコンポーネント（ntdbsmgr や w3dbsmgr など）のメモリ使用が増加します。

Windows タスクマネージャーで " 仮想メモリサイズ " を見ると、 L1 キャッシュがアクセスされたときにメモリ

の値が変化することがわかります。バックグランドスレッドがアクセスされたときにスレッド数が変わることも

わかります。

非アクティブ時、小の状態に戻す

この設定により、アクティブなクライアントが存在しない状態で一定の時間が過ぎると、 MicroKernel は、大部分

のメモリ容量およびスレッドリソースをシステムに解放し、小の状態に戻ります。その時間は、［小の状態

に戻す待ち時間］の値で設定します。ほかのクライアントがアクティブになった場合は、 MicroKernel により、リ

ソースが再度割り当てられます。

小の状態に戻す待ち時間

この設定は、 MicroKernel が小の状態に戻る前に非アクティブ状態でどれだけ待機するかを指定します。（小

の状態とは、 MicroKernel 起動時の初期状態です。） MicroKernel を小の状態に戻すと、大部分の容量のメモリと

スレッドリソースがシステムに解放されます。 MicroKernel を小の状態に戻したくない場合もあります。たと

えば、繰り返し MicroKernel を使用するバッチファイルを使用中の場合などです。ほかのクライアントがアクティ

ブになった場合は、 MicroKernel により、リソースが再度割り当てられます。

この設定は、［非アクティブ時、小の状態に戻す］にオフ（デフォルト）が設定されている場合は無視されます。


Boolean オン

オフ

オフなし必要


Boolean オン

オフ

オフなし必要


Numeric 0 - 2147483647 300000 ミリ秒必要

54


ソートバッファーサイズ

この設定は、ランタイムでインデックスを作成中に MicroKernel がソートのために動的に割り当てる、または割

り当てを解除するメモリの大容量（キロバイト単位）を指定します。

ソート用に指定されたサイズ以上のメモリが必要な場合、または利用可能な処理メモリの 60 % 以上を占める場

合は、 MicroKernel により、テンポラリファイルが作成されます。処理に必要な利用可能メモリの量は、動的な

値で、システムの設定や負荷によって変化します。 0 キロバイトを指定すると、 MicroKernel は、利用可能なメモ

リのうち大 60 % まで、必要なだけのメモリを割り当てます。

システムキャッシュ

このオプションは、 MicroKernel が、 MicroKernel 自体の「キャッシュ割当サイズ」に加え、設定プロパティで指

定したシステムキャッシュを使用するかどうかを指定します。

L2 キャッシュを使用している場合は、［システムキャッシュ］をオフに設定する必要があります。「MicroKernelの大メモリ使用量」の設定を確認してください。［MicroKernel の大メモリ使用量］にゼロより大きい値が設

定されている場合は、 L2 キャッシュを使用しています。

L2 キャッシュを使用していない場合は［システムキャッシュ］をオンにすると、パフォーマンスが向上します。

MicroKernel は書き出すページを構成したりグループ化するのにシステムキャッシュを使用します。システム

キャッシュがより効果的にページをディスクに書き出せるようにフラッシュを十分に遅らせます。ただし、サー

バーにキャッシュ付きのディスクアレイがある場合は［システムキャッシュ］の設定をオフにすることにより、

より良いパフォーマンスを得られることがあります。

Windows サーバーの場合のみ、 Windows パフォーマンスモニターユーティリティのページングファイルおよび

プロセスオブジェクトを使用して Windows のシステムキャッシュが効率的に使用されているかをチェックでき

ます。 NTDBSMGR インスタンスの場合は、ページファイルオブジェクトの［% 使用］および［% 大使用］を

モニターし、プロセスオブジェクトの［Page Fault/sec］および［Page File Bytes］をモニターします。

パフォーマンスチューニング

［パフォーマンスチューニング］には次の設定が含まれています。

「キャッシュ割当サイズ」

「通信スレッド数」

「ファイルの拡張係数」

「インデックスバランスの実行」

「セグメントサイズを 2 GB に制限」



「I/O スレッド数」

「トランザクションログサイズ」


Numeric 0 - メモリによって

制限される

0 バイト必要


Boolean オン / オフオフ（サーバーエンジン）

オン（ワークグループエンジ

ン）

なし必要

55


キャッシュ割当サイズ

この設定は、MicroKernel によって割り当てられるレベル 1 キャッシュのサイズを指定します。MicroKernel では、

すべてのデータファイルへのアクセスにこのキャッシュが使用されます。

ごく一般的に言うと、［キャッシュ割当サイズ］の値がシステム上の物理メモリの 40 % より小さく、設定情報の

［MicroKernel の大メモリ使用量］が 40% より大きい値に設定されている場合に、全体のパフォーマンスは高

になります。適な設定は、データファイルのサイズ、システム上で実行されるほかのアプリケーションの数、

およびコンピューターにインストールされているメモリの量によって変わります。

サーバーエンジン

Windows では、この設定は、データベースエンジンが初めて起動されたときに物理メモリの 20% に設定され、そ

の値がレジストリに書き込まれます。その後は、エンジンが起動するたびにレジストリから値を読み取ります。

設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取

り除いたりした場合には、新しく使用可能になったメモリを大限活かせるようにこの設定を変更する必要があ

ります。

パフォーマンスを適化するには、使用中のファイルの合計サイズより小さいサイズをキャッシュに割り当てま

すが、特に、サーバーがほかのアプリケーションを実行しているときは、利用可能なメモリをすべてキャッシュ

に割り当ててしまわないように注意します。必要以上に大きい値を指定しても、メモリを無駄に使用するだけで、

パフォーマンスの向上を図ることはできません。

ワークグループエンジンおよびクライアントキャッシュ

データベースエンジンは、初めて起動されたときにこの値を設定し、レジストリに書き込みます。この初期値に

は物理メモリの 20% が設定されます。キャッシュの大サイズはシステムのメモリの容量に応じて異なります

が、データベースエンジンは 64 MB を初期大値に設定します。レジストリ設定が初期化されると、エンジン

は起動されるたびにレジストリからこの値を読み取ります。エンジンがこの設定を再計算することはありません。

設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取

り除いたりした場合には、新しく使用可能になったメモリを大限活かせるようにこの設定を手動で変更する必

要があります。

クライアントキャッシュ

設定の［キャッシュエンジンの使用］がオンに設定されている場合、この情報はクライアントソフトウェア（ク

ライアントキャッシュ）にも適用されます。

メモ Pervasive PSQL v10 より前の Pervasive PSQL クライアントを使用する場合、キャッシュ割当サイズの値

はバイト単位で指定する必要があります。小の 64KB （65,536 バイト）が指定されます。大値はメモリ

容量によって制限されます。


Numeric 1 メガバイトからメモリに

よって制限される量

（後述の「メモ」を参照して

ください）

初の起動時に動的

に初期化される

メガバイト

（後述の「メモ」

を参照してくだ

さい）

必要

56


通信スレッド数

この設定は、リモートクライアントからのリクエストを処理するために MicroKernel が初に作成するスレッド

の数を指定します。通信スレッドは、リクエストを行うクライアントプロセスに代わって、実際に Btrieve オペ

レーションを実行する要素です。このように、通信スレッドはワーカスレッドによく似ています。通信スレッド

は許容される大範囲まで、必要に応じて動的に増加します。大値は、 256 です。

通信スレッドの設定は、ある特定の状況下における改善に役立ちます。たとえば、 1 つのファイルに対して多く

のクライアントが操作（主に書き込み）を行うような場合、より低い値を設定すればスケーラビリティが向上す

るはずです。スレッド数の値をより低くすると、システムリソースでコンテキストスイッチを行わないようにし

ます。このほか、大量のワーカースレッド間でスラッシングによって速度低下が発生する状況も、この通信ス

レッドの設定によって改善する可能性があります。ワーカースレッドは、既存の全スレッドがレコードまたは

ファイルのロックで待機している場合にのみ動的に作成されます。

ファイルの拡張係数

この値は、バージョン 8.x 以降の形式のデータファイル内に保持する空きページの概算パーセントを指定します。

この設定は、旧バージョンの形式のファイルには適用されません。 MicroKernel では、この値を使用して、ファイ

ルを拡張するか空きページを初に使用するかを決定します。データベースエンジンは Turbo Write Accelerator を使用するので、ディスク書き込みのパフォーマンスは、ファイル内の空きページ数が増加するにつれて向上しま

す。これは、そのデータベースエンジンが複数の連続したファイルページをディスク上に書き込むことができる

からです。したがって、ディスク書き込みのパフォーマンスとファイルのサイズは互いに相殺関係にあります。

ただし、ファイルに空きページが多すぎると実際には全体のパフォーマンスを落とします。

データファイル内に一定の連続した空きページを保持するためには、データベースエンジンが定期的にそのデー

タファイルを拡張する必要があります。この設定がファイルのサイズに影響があることを覚えておいてくださ

い。たとえば、空きページのないファイルで作業するときに、［ファイルの拡張係数］の値に 50% を指定した場

合、そのファイルのサイズは終的に 2 倍になります。［ファイルの拡張係数］の値に 75% を指定した場合、そ

のファイルのサイズは 4 倍になります。 90% を指定した場合、そのサイズは 10 倍近くになります。

完全に使用しないページのみが空きページとみなされることに注意してください。ページのなかには途中までし

か使用していないページもあるので、15% の空きページといった場合、ファイルの 15% が使用されないという意

味ではありません。

この値は MicroKernel への単なる指示です。ファイルが更新される度合いによって、実際の空き領域のパーセン

テージはいつでも小さくすることができます。

この設定は、バージョン 8.x より前の形式のファイルには適用できません。旧バージョンの形式のファイルにも

空きページがあり、そのファイルの動作状況によって空きページのパーセンテージは異なります。


Numeric プロセッサの

コア数～ 256プロセッサのコア数。このプロセッサのコア数

は、データベースエンジンが起動しているマ

シンのプロセッサ数です。

なし必要


Numeric 0-100 15 パーセント必要

57


インデックスバランスの実行

この設定は、 MicroKernel が、インデックスバランスを実行するかどうかを制御します。インデックスバランス

により、読み取りオペレーションのパフォーマンスは向上しますが、このオプションを有効にすると、時間がさ

らにかかり、挿入、更新、削除オペレーション時にさらにディスクの I/O が必要な場合があります。インデック

スバランスの詳細については、開発者リファレンス『Pervasive PSQL Programmer's Guide』を参照してください。

セグメントサイズを 2 GB に制限

これを指定すると、データファイルは、オペレーティングシステムのファイルセグメントである 2 GB の限界を

超えるごとに自動的に分割されます。オンに設定した場合、データファイルは 2 GB のセグメントに分割されま

す。オフに設定した場合、データファイルはセグメント化されず単一のファイルのままです。セグメント化され

ていない大きなファイルを使用する利点は、ディスク I/O が効率的であるということです。このため、パフォー

マンスの向上が期待できます。

セグメントされていないファイルは、お使いのオペレーティングシステムによって指定されているファイルサイ

ズの制限を受けます。以前作成したファイルが既にセグメント化されている場合、そのセグメントはファイル上

でそのまま残ります。

「ファイルバージョンの自動アップグレード」の関連情報も参照してください。

ログバッファーサイズ

この設定は、 MicroKernel によって使用されるトランザクションログバッファーおよびアーカイブログバッ

ファーのサイズを指定します。ログバッファーのサイズを増やすことにより、 MicroKernel がログ情報をディス

クに書き込む回数が減るため、パフォーマンスの向上が図れます。

メモ［ログバッファーサイズ］に［トランザクションログサイズ］より大きい値を設定すると、MicroKernelは［トランザクションログサイズ］の値を［ログバッファーサイズ］に指定した値に自動的に変更します。


Boolean オン

オフ

オフなし必要


Boolean オン

オフ

オンなし必要


Numeric 262144 - メモリに

よって制限される

次の値のうち、小さい方の値： (MB 単位の物理メモリ / 256)または 8 MB

バイト必要

58


MicroKernel の大メモリ使用量

この設定は、総物理メモリに対して MicroKernel が消費できるメモリの割合を指定します。MicroKernel による L1、L2 およびその他すべてのメモリの使用量が含まれます（SRDE は含まれません）。データベースエンジンは、指

定した割合が必要でないか使用できない場合は、これより少ないメモリを使用します。

値にゼロ（0）を指定すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、

［キャッシュ割当サイズ］で指定したサイズになります。データベースサーバー専用のマシンを使用している場

合、［MicroKernel の大メモリ使用量］を大値に設定するか、オペレーティングシステムが占有しないメモリ

の割合を指定します。データベースサーバーでほかのアプリケーションが実行され、これらすべてとパフォーマ

ンスのバランスをとる必要がある場合は、低い値を設定して、データベースキャッシュが利用可能なメモリを使

用する場合に、ほかのアプリケーションと競合しないようにする必要があります。

メモ［キャッシュ割当サイズ］に［MicroKernel の大メモリ使用量］の値よりも大きな物理メモリ量を設

定した場合は、［キャッシュ割当サイズ］の値が優先されます。たとえば、物理メモリが 1 GB のマシンで、

［キャッシュ割当サイズ］に 600 MB、［MicroKernel の大メモリ使用量］に 40% を設定したとします。 L1キャッシュには 600 MB のメモリが割り当てられます。［キャッシュ割当サイズ］の値の方が大きいので、そ

の値が優先され、 L1 キャッシュに割り当てられるメモリ量は［MicroKernel の大メモリ使用量］に指定さ

れた値よりも大きくなります。

次の方程式を使用して MicroKernel 大メモリ使用量の近似値を割り出します。

(L1 キャッシュサイズ + 内部割り当て + L2 キャッシュサイズ / 物理メモリのサイズ ) * 100

この場合、

L1 キャッシュサイズ：「キャッシュ割当サイズ」

内部割り当て： L1 キャッシュの約 25% のサイズ

L2 キャッシュサイズ：システムのメモリロードに基づいて拡大および縮小するメモリ容量

物理メモリサイズ：マシンにインストールされているメモリ容量

パフォーマンスチューニングの詳細については、「パフォーマンスチューニング」を参照してください。

I/O スレッド数

この設定は、 MicroKernel が起動するバックグラウンドの I/O スレッドの数を指定します。これらのスレッドは、

MicroKernel のキャッシュからディスク上のファイルへすべてのページをアトミックかつ調和のとれた方法で書

き出す責任を果たします。また、初にファイルを開いてファイルコントロールレコードの読み込みも行いま

す。その他のほとんどの読み込みはローカルワーカスレッドおよび通信スレッドが行います。 MicroKernel が、

データファイルを更新、またはデータファイルに書き込みを行うと、各ファイルは、指定された I/O スレッドに

シーケンシャルに割り当てられます。後のスレッドに達すると、すべてのデータファイルがバックグラウンド

スレッドに割り当てられるまで、 MicroKernel は、処理をやり直します。 MicroKernel では、必要に応じて追加の

I/O スレッドを作成しないため、必要と思われる I/O スレッドの数を予想して大数を指定します。

適なパフォーマンスを実現するには、［大オープンファイル数］に基づいた値を指定します。 Monitor ユー

ティリティは開いているファイル数の現在値とピーク値を表示します。データベースに平均 256 個のファイルが


Numeric 0-100 60 パーセント不要


Numeric 1 ～ 1024 32 なし必要

59


ある場合、デフォルトの 32 I/O スレッドでは各スレッドが 8 ファイルを受け持つことになります。実際に即した

方法として、 I/O スレッドごとに、およそ 8 ファイルを持つようにします。たとえば、オープンファイル数の平

均が 400 の場合、およそ 50 個の I/O スレッドを使用します。 64 より大きい値を指定するとパフォーマンスが損

なわれることがありますが、これはシステムの能力によります。

メモこの設定は、マシンの特性、 OS の設定およびデータベースエンジンの作業負荷に影響されるため、適

切な I/O スレッド数を正確に計算することはできません。

トランザクションログサイズ

この設定は、トランザクションログセグメントの大サイズを指定します。ログファイルが制限されたサイズ

に達すると、 MicroKernel は、古いログセグメントファイルを閉じ、新しいファイルの使用を開始します。トラ

ンザクションログセグメントのサイズを制限することにより、 MicroKernel が一時的に使用するディスク容量を

少なくできるため、これを行いたいと思われるでしょう。しかし、サイズを制限すると、ログセグメントを頻繁

に閉じて作成することが必要になるため、MicroKernel の処理量が増え、パフォーマンスが低下する可能性があり

ます。

メモこのオプションに［ログバッファーサイズ］で指定した値よりも小さい値を設定すると、データベー

スエンジンは［トランザクションログサイズ］の設定を自動的に［ログバッファーサイズ］の値に合わせ

ます。


Numeric 65536 - ディスク容量に

よって制限される


の 2 倍バイト必要

60

Windows クライアント設定プロパティ


クライアントの設定オプションは、それぞれのインストレーションで設定が可能です。これらのオプションは、

ワークステーションとして機能するサーバーを含め、ワークステーションごとに個別に設定する必要があります。

グラフィカルユーティリティの Pervasive PSQL Control Center やコマンドラインインターフェイスユーティリ

ティの bcfg を使って、クライアントを構成することができます。PCC については、『Pervasive PSQL User's Guide』の「Pervasive PSQL Control Center の使用」を参照してください。 bcfg については、「CLI ユーティリティによる

設定」を参照してください。

次の表は、使用可能なクライアント設定オプションとその設定の対応を示します。

表 13 クライアントの設定

設定オプションプロパティ名

「アクセス」「ゲートウェイ一貫性保守」

「ロード再試行回数」

「IDS の使用」

「ローカル MicroKernel エンジンの使用」

「リモート MicroKernel エンジンの使用」



「キャッシュエンジン」「起動時のリソース割当」





「キャッシュエンジンのデバッグ」［キャッシュエンジンのデバッグ］で使用できる設定は、サーバー構成にあ

る類似した設定と同様の機能をクライアントキャッシュに対して実行しま

す。「デバッグ」の関連するサーバー設定を参照してください。

「通信プロトコル」「自動再接続の有効化」


「接続タイムアウト」

「パフォーマンスチューニング」「キャッシュエンジンの使用」

「セキュリティ」「ランタイムサーバーサポート」

「アプリケーションの特性」「スペースを含むファイル / ディレクトリ」

「キー長の検証」

「スプラッシュスクリーン」

61


アクセス

［アクセス］には次の設定が含まれています。

「ゲートウェイ一貫性保守」

「ロード再試行回数」

「IDS の使用」

「ローカル MicroKernel エンジンの使用」

「リモート MicroKernel エンジンの使用」

ゲートウェイ一貫性保守

このオプションは、 MicroKernel ルーターが、 Pervasive PSQL が動作していないコンピューターのリストをレジス

トリに保存する必要があるかどうかを指定します。レジストリに保存すると、ゲートウェイエンジンの検索に必

要な時間を短縮できます。ワークグループに新しいエンジンを追加するときは、このオプションをオフに設定す

る必要があります。

ロード再試行回数

この設定は、 MicroKernel ルーターが、ターゲットエンジンに対して接続を再試行する回数を指定します。

IDS の使用

この設定は主に、 Pervasive PSQL （IDS）を使用するレガシーアプリケーションで使用されます。 IDS 機能はコア

製品に統合されたため、 IDS を単独のインストール済みコンポーネントとして使用することはできなくなりまし

た。 IDS の統合は、クライアント / サーバー環境の再構成を必要とします。

一般的には、アプリケーションは独自のファイルの場所情報を指定します。別の方法として、 IDS は、テキスト

ファイル idshosts の情報に基づいてファイル場所のマッピングを指定します。

アプリケーションが idshosts によるマッピング機能を使用しない場合は、パフォーマンスを向上させるために

［IDS の使用］をオフにします。

アプリケーションが既に idshosts を使用している場合、あるいはこの代替方法を使用してファイルの場所をマッ

プしたいと考えている場合は、［IDS の使用］をオンにします。「idshosts ファイルの使用」を参照してください。

メモ［IDS の使用］にオンを設定した場合や、レガシーアプリケーションがファイルの場所情報を PIDSURL の形式で渡す場合には Pervasive PSQL 8.5 以降が必要です。リクエスターは IDS 情報を表すのにデータ

ベース URI を使用します。データベース URI は Pervasive PSQL 8.5 で追加されました。開発者リファレンス

『Pervasive PSQL Programmer's Guide』の「データベース URI」を参照してください。


Boolean オン

オフ

オフなし適用外


Numeric 0 ～ 65536 5 なし適用外


Boolean オン

オフ


62


ローカル MicroKernel エンジンの使用

この設定は、ローカルアプリケーションがローカルエンジンに接続を試みるかどうかを指定します。オフに設定

すると、ローカルエンジンへの接続は試行されません。

リモート MicroKernel エンジンの使用

この設定は、 MicroKernel ルーターが、リモートサーバーで動作している MicroKernel サーバーまたはワークグ

ループエンジンへのアクセスを許可するかどうかを指定します。この設定をオンにし、［ローカル MicroKernel エンジンの使用］の設定をオンにした場合、まずリモートサーバーへの接続が試行されます。

ワイヤ暗号化

「ワイヤ暗号化」を参照してください。

メモクライアント側のワイヤ暗号化設定は Pervasive JDBC および ADO.NET アクセス方法では使用されま

せん。クライアント側のワイヤ暗号化設定の場合、暗号化は接続文字列を使用して指定できます。『JDBCDriver Guide』の「接続文字列の概要」、および『Pervasive Data Provider for .NET Guide and Reference』の「基

本的な接続文字列の定義」を参照してください。

ワイヤ暗号化レベル

「ワイヤ暗号化レベル」を参照してください。




キャッシュエンジン

これらの設定は、キャッシュエンジンが実行されている場合にのみ適用されます。ワークグループエンジンは

キャッシュエンジンを兼ねています。ただし、データベースサーバーエンジンが実行されている場合にはキャッ

シュエンジンは使用されないことに注意してください。

［キャッシュエンジン］には次の設定が含まれています。

「起動時のリソース割当」





Boolean オン

オフ

オンなし適用外


Boolean オン / オフオンなし適用外

63



起動時のリソース割当

この設定は、キャッシュエンジンの起動時に、スレッドやメモリバッファーを含むリソースを割り当てるように

キャッシュエンジンに指示します。

このオプションをオフにすると、初のオペレーションが要求されるまでリソースが割り当てられません。必要

に応じて、 Pervasive PSQL コンポーネントにより、自動的にリソースが割り当てられます。したがって、多くの

場合、このリソース割り当てを自分で行う必要はありません。

非アクティブ時、小の状態に戻す

この設定は、ワークグループエンジンが実行されている場合にのみ表示されます。

この設定により、アクティブなクライアントが存在しない状態で一定の時間が過ぎると、キャッシュエンジンは

大部分のメモリ容量およびスレッドリソースをシステムに解放し、小の状態に戻ります。その時間は、［小

の状態に戻す待ち時間］の値で設定します。ほかのクライアントがアクティブになった場合は、キャッシュエン

ジンにより、リソースが再度割り当てられます。



すべてのデータファイルへのアクセスにこのキャッシュが使用されます。

ごく一般的に言うと、［キャッシュ割当サイズ］の値がシステム上の物理メモリの 40 % より小さく、設定プロパ

ティの［キャッシュエンジンの大メモリ使用量］が 40% より大きい値に設定されている場合に、全体のパ

フォーマンスは高になります。適な設定は、データファイルのサイズ、システム上で実行されるほかのアプ

リケーションの数、およびコンピューターにインストールされているメモリの量によって変わります。

データベースエンジンは、初めて起動されたときにこの値を設定し、レジストリに書き込みます。この初期値に

は物理メモリの 20% が設定されます。レジストリ設定が初期化されると、エンジンは起動されるたびにレジスト

リからこの値を読み取ります。エンジンがこの設定を再計算することはありません。設定プロパティを使用して

値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取り除いたりした場合には、

新しく使用可能になったメモリを大限活かせるようにこの設定を手動で変更する必要があります。

データ型範囲デフォルト単位データベースエンジン再起動の必要性

Boolean オン

オフ



Boolean オン

オフ


データ型範囲デフォルト単位データベースエンジン

再起動の必要性

Numeric 1 メガバイトからメモリによって制

限される量

（後述の「メモ」を参照してください）

初の起動時に

動的に初期化さ

れる

メガバイト

（後述の「メモ」を

参照してください）

適用外

64


メモ Pervasive PSQL v10 より前の Pervasive PSQL クライアントを使用する場合、キャッシュ割当サイズの値

はバイト単位で指定する必要があります。小の 64KB （65,536 バイト）が指定されます。大値はメモリ

容量によって制限されます。


この設定は、総物理メモリに対してキャッシュエンジンが消費できるメモリの割合を指定します。キャッシュエンジンによって使用されるメモリには、 L1、 L2、およびその他すべてのメモリが含まれます。データベースエン

ジンは、指定した割合が必要でないか使用できない場合は、これより少ないメモリを使用します。

値にゼロ（0）を指定すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、

［キャッシュ割当サイズ］で指定したサイズになります。

パフォーマンスのチューニングについては、「パフォーマンスチューニング」を参照してください。

小の状態に戻す待ち時間

この設定は、ワークグループエンジンが実行されている場合にのみ表示されます。

この設定は、キャッシュエンジンが小の状態に戻る前に非アクティブ状態でどれだけ待機するかを指定しま

す。（小の状態とは、キャッシュエンジン起動時の初期状態です。）キャッシュエンジンを小の状態に戻す

と、大部分の容量のメモリとスレッドリソースがシステムに解放されます。キャッシュエンジンを小の状態に

戻したくない場合もあります。たとえば、繰り返しキャッシュエンジンを使用するバッチファイルを使用中の場

合などです。ほかのクライアントがアクティブになった場合は、キャッシュエンジンにより、リソースが再度割

り当てられます。

この設定は、［非アクティブ時、小の状態に戻す］にオフ（デフォルト）が設定されている場合は無視されます。

キャッシュエンジンのデバッグ

これらの設定は、キャッシュエンジンが実行されている場合にのみ適用されます。ワークグループエンジンは

キャッシュエンジンを兼ねています。ただし、データベースサーバーエンジンが実行されている場合にはキャッ

シュエンジンは使用されないことに注意してください。

［キャッシュエンジンのデバッグ］で使用できる設定は、［サーバー｜デバッグ］にある類似した設定がメインの

データベースエンジンに対して実行するのと同様の機能を、クライアントキャッシュに対して実行します。各設

定の詳細については、関連するサーバー設定を参照してください。

「データバッファーのバイト数」






Numeric 0-100 60 パーセント適用外


Numeric 0 - 2147483647 300000 ミリ秒適用外

65



［通信プロトコル］には次の設定が含まれています。

「自動再接続の有効化」


「接続タイムアウト」


この設定は、ネットワークの中断時にクライアントが自動再接続を試行するかどうかを指定します。オンに設定

すると、自動再接続が有効になります。

自動再接続は、この設定をサーバーの設定でも有効にしておかない限り、有効になりません。

サポートプロトコル

この設定は、クライアントが使用するプロトコルを指定します。複数のプロトコルを指定した場合、クライアン

トは、使用可能なすべてのプロトコルで接続を試行します。初に接続できたプロトコルは、そのセッションの

間使用されます。使用可能なオプションは次のとおりです。

TCP/IP

SPXII

NetBIOS

メモサーバーとクライアントの両方で有効なプロトコルが低 1 つないと、通信を行うことができません。

NetBIOS が有効なのは Pervasive PSQL Workgroup のみで、 Pervasive PSQL Server では無効です。 Linux プラッ

トフォームで動作する Pervasive PSQL でサポートされるプロトコルは TCP/IP のみです。したがって、サポー

トプロトコルの設定は、 Linux では使用できません。

接続タイムアウト

この設定の値は、クライアントがリモートデータベースエンジンを検索または接続するまで待つ時間を指定しま

す。この値の設定が小さ過ぎると、接続が完了する前にタイムアウトになるため、サーバーが見つからないとい

う擬似エラーがクライアントに返されます。この値の設定が大き過ぎると、クライアントが接続不可能なサーバー

へ接続しようとした場合、エラーが返されるまでに著しく時間がかかる可能性があります。一般的に、ほとんど

のネットワークでは 15 秒から 30 秒の間の値が妥当です。「サーバーが見つかりません」というエラーが頻発する

場合は、より高い値を設定してください。

この設定は、以前は通信リクエスターの TCP/IP 接続タイムアウトと呼ばれていました。


Boolean オン

オフ




参照。

下記の 3 つの選択肢が

あります

なし適用外


Numeric 1 ～ 2147483647 15 秒適用外

66



［パフォーマンスチューニング］には次の設定が含まれています。

「キャッシュエンジンの使用」

キャッシュエンジンの使用

この設定は、クライアントのキャッシュを使用するかどうかを指定します。この設定がオフの場合、クライアン

トワークステーション上の比較的小さな固定サイズのキャッシュに、単一レコードをキャッシュします。この設

定がオンになっていると、クライアントはキャッシュエンジンがメモリにロードされていればこれを使用しま

す。キャッシュエンジンがロードされていない場合は、この設定はなんの効果もありません。

クライアントキャッシュは、いろいろな意味でワークグループエンジンと似ています。デフォルトでは、アプリ

ケーションが初にデータベースにアクセスしたときにクライアントキャッシュはメモリに自動的にロードさ

れ、そのアプリケーションを終了すると数分後にアンロードされます。

クライアントキャッシュを常にメモリに保持して、各使用セッションがキャッシュを再配置するパフォーマンス

コストを回避したい場合もあるでしょう。クライアントキャッシュをロードしたままにする場合は、コマンドプロンプトから次のコマンドを実行してください。

file_path\PSQL\bin\w3dbsmgr -btrv

Pervasive PSQL ファイルのデフォルトの保存場所については、『Getting Started with Pervasive PSQL』の「PervasivePSQL ファイルはどこにインストールされますか？」を参照してください。「キャッシュ割当サイズ」でクライア

ントキャッシュに関する説明も参照してください。

キャッシュエンジンが開始するとトレイアイコンが表示され、 Windows タスクバーからクライアントキャッ

シュを制御できます。クライアントキャッシュを停止するには、クライアントキャッシュトレイアイコンを右

クリックし、［エンジンを停止して終了］を選択します。

メモ Pervasive PSQL は、クライアントキャッシュと、データベースエンジンキャッシュやほかのクライア

ントキャッシュとの同期をとります。この動作は完全に自動的かつ透過的に行われます。ただし、データ

ベースエンジンでデータベースの変更が発生し、その変更がすべてのクライアントキャッシュに反映される

までの間には大 5 秒の遅延が生じます。お使いのシステムで、クライアントキャッシュにそのような古い

ページが大 5 秒間存在することが許容されない場合は、キャッシュエンジンを使用しないでください。

以下の操作はクライアントキャッシュには格納されません。

トランザクション内にあるすべての操作

ロックバイアスのかかった操作

Insert、 Update、 Delete などの書き込み操作

Open および Close 操作

セキュリティ

［セキュリティ］には次の設定が含まれています。

「ランタイムサーバーサポート」


Boolean オン

オフ


67


ランタイムサーバーサポート

この設定は、ランタイムサーバーサポートを制御します。この設定が "Yes" （有効）場合は、現在使用中のドラ

イブのユーザー名が使用されます。別のユーザー名で RTSS を有効にするには、「ユーザー名 , パスワード」を入

力します。

「CN= ユーザー名 .O= 組織 , パスワード」の形式で、完全修飾された NDS ユーザー名を使用できることに注意し

てください。ユーザー名はシンプルなバインダリ名であってもかまいません。バインダリコンテキスト一覧の

初のエントリはシンプルな名前である必要があります。そうしないと、 NDS のログインが失敗します。シンプル

な名前で NDS ログインが失敗した場合は、バインダリログインが試行されます。バインダリログインは、ログ

イン試行を処理している間、進行を妨げることがあります。

SUPERVISOR および ADMIN は、正しいパスワードと一緒に入力しても、有効なユーザー名ではありません。リ

クエスターが、SUPERVISOR または ADMIN 以外のログインユーザー名を検出できない場合は、ログインを試行

しません。

アプリケーションの特性

［アプリケーションの特性］には次の設定が含まれています。

「スペースを含むファイル / ディレクトリ」

「スプラッシュスクリーン」

「キー長の検証」

スペースを含むファイル / ディレクトリ

このオプションは、トランザクショナルインターフェイスオペレーションに指定するファイル名でスペースを使

用できるように、トランザクショナルインターフェイスに指示します。

スプラッシュスクリーン

この設定は、トランザクショナルインターフェイスのスプラッシュスクリーンを表示させるかどうかを制御しま

す。スプラッシュスクリーンは、初にクライアントリクエスターがロードされるときに表示されます。


String YesNoユーザー名 , パスワード

Yes なし適用外


Boolean オン

オフ



Boolean オン

オフ


68


キー長の検証

このオプションを従来の Btrieve アプリケーションで使用すると、クライアントリクエスターに渡されたイン

デックスのキー長がキーに対して十分なサイズであるかどうかが、リクエスターで検証されなくなります。この

オプションをオフに設定することで、アプリケーションはステータス 21 のエラーを回避できるようになります。

注意ただし、オフに設定した場合、このオプションはメモリの上書きを防ぐための Pervasive リクエスター

によるチェックを無効にします。メモリの上書きにより生じる状況で、望ましくない状況はいくつかありま

すが、中でも一般保護エラー（GPF）が発生する可能性があります。


Boolean オン

オフ


69


Linux クライアント設定プロパティ

Pervasive PSQL のクライアントおよびサーバーは、どちらもグラフィカルユーティリティの Pervasive PSQLControl Center やコマンドラインインターフェイスユーティリティの bcfg を使って構成することができます。

PCC については、『Pervasive PSQL User's Guide』の「Pervasive PSQL Control Center の使用」を参照してください。

bcfg については、「CLI ユーティリティによる設定」を参照してください。

設定値での大文字小文字の区別

Linux クライアントは設定値の確認または変更を行う場合、大文字小文字を区別しません。たとえば、設定値に

"Yes" または "yes" を入力した場合、 Linux クライアントではこれらを同一の値であると解釈します。

ローカル設定（［Local］）によって影響を受けるクライアントのパフォーマンス

Linux クライアントインターフェイスが初めて呼び出されたときには、そのデフォルトの設定値が Pervasive レジ

ストリに設定されます。 Pervasive PSQL Client は、自身のインストールにサーバーエンジンが含まれているかど

うかを認識しません。そのため、ローカル設定（［Local］）を有効（"Yes"）にします。これは Linux クライアン

トのパフォーマンスに影響を及ぼす可能性があります。

クライアントを使用しているコンピューターにサーバーエンジンがない場合は、ローカル設定（［Local］）を無

効（"No"）にします。「Use Local MicroKernel Engine（ローカル MicroKernel エンジンの使用）」を参照してください。

埋め込みスペースを含むファイル名

デフォルトで、 Linux クライアントインターフェイスはスペースを含むファイル名をサポートします。

たとえば、次のようにします。

/mymount/usr/gary/file with spaces.mkd

スペースを含まないファイル名を使用したい場合は、［スペースを含むファイル / ディレクトリ］（［EmbeddedSpaces］）設定を変更する必要があります。「Embedded Spaces （スペースを含むファイル / ディレクトリ）」を参照


設定リファレンス次の表は、 Linux クライアントの設定オプションの一覧を示します。

表 14 Linux クライアントの設定

設定オプションプロパティ名

「Access （アクセス）」「Use Local MicroKernel Engine （ローカル MicroKernel エンジンの使用）」

「Use Remote MicroKernel Engine （リモート MicroKernel エンジンの使用）」

「Use IDS （IDS の使用）」

「Wire Encryption （ワイヤ暗号化）」

「Wire Encryption Level （ワイヤ暗号化レベル）」

「Communication Protocols （通信プロトコル）」「Enable AutoReconnect （自動再接続の有効化）」

「Application Characteristics （アプリケーション

の特性）」

「Embedded Spaces （スペースを含むファイル / ディレクトリ）」

「Verify Kye Length （キー長の検証）」

70

Linux クライアント設定プロパティ

Access （アクセス）

［Access］には次の設定が含まれています。

「Use Local MicroKernel Engine （ローカル MicroKernel エンジンの使用）」

「Use Remote MicroKernel Engine （リモート MicroKernel エンジンの使用）」

「Use IDS （IDS の使用）」

「Wire Encryption （ワイヤ暗号化）」

「Wire Encryption Level （ワイヤ暗号化レベル）」

Use Local MicroKernel Engine （ローカル MicroKernel エンジンの使用）

「ローカル MicroKernel エンジンの使用」を参照してください。

Use Remote MicroKernel Engine （リモート MicroKernel エンジンの使用）

「リモート MicroKernel エンジンの使用」を参照してください。

リモートエンジンと UNC パス

UNC パスがクライアントから正しく動作するようにするには、以下のこと行う必要があります。

アクセスしようとするファイルと同じコンピューターにあるエンジンを実行している必要があります。

［リモート MicroKernel エンジンの使用］をオンに設定しておきます。

メモローカルの Linux マシンを指す UNC パスを使って送信することはできません。ただし、次のような

UNC スタイルのパスは使用することができます。 //localhost/usr/local/psql/data/samples/sample.btr

ファイルサーバーにエンジンが不要の場合（つまり、クライアントのローカルエンジンが欲しい場合）、クライ

アントのリモートファイルシステムをマウントし、 UNC 形式ではなく " ネイティブ形式 " のパスになるようパ

スを変更する必要があります。たとえば、次のパスは Linux のネイティブな形式です。

/mnt/myremotedata/sample.btr

Use IDS （IDS の使用）

「IDS の使用」を参照してください。

Wire Encryption （ワイヤ暗号化）

「ワイヤ暗号化」を参照してください。




Wire Encryption Level （ワイヤ暗号化レベル）

「ワイヤ暗号化レベル」を参照してください。

71





Communication Protocols（通信プロトコル）

［Communication protocols］には次の設定が含まれています。

「Enable AutoReconnect （自動再接続の有効化）」

Enable AutoReconnect （自動再接続の有効化）

この設定は、ネットワークの中断時にクライアントが自動再接続を試行するかどうかを指定します。オンに設定

すると、自動再接続が有効になります。

自動再接続は、この設定をサーバーの設定でも有効にしておかない限り、有効になりません。

メモ Pervasive Linux クライアントはこの Auto-Reconnect （自動再接続）機能をサポートしますが、Linux サー

バーではサポートしません。このため、 Linux クライアントから AutoReconnect （PARC）機能を使用した場

合のみ Windows サーバーに接続することができます。

Application Characteristics （アプリケーションの特性）

［Application characteristics］には次の設定が含まれています。

「Embedded Spaces （スペースを含むファイル / ディレクトリ）」

「Verify Kye Length （キー長の検証）」

Embedded Spaces （スペースを含むファイル / ディレクトリ）

「スペースを含むファイル / ディレクトリ」を参照してください。

Verify Kye Length （キー長の検証）

「キー長の検証」を参照してください。


Boolean オン

オフ


72

5
データベースパフォーマンスの分析およびチューニング


「パフォーマンスの分析」

「パフォーマンスチューニング」

「ハイパーバイザー製品でのパフォーマンス」

「Xtreme I/O ドライバー」

73


パフォーマンスの分析

Pervasive PSQL Server の Windows 版では Windows パフォーマンスモニターで使用するパフォーマンスカウン

ターを提供します。 Pervasive PSQL のパフォーマンスカウンターがサポートされるのは、 Windows Vista 以上の

Windows オペレーティングシステムのみです。パフォーマンスカウンターはデータベースエンジンの状態や動

作を測定します。これによりアプリケーションのパフォーマンスを分析することができます。 Windows パフォー

マンスモニターは、指定の時間間隔でパフォーマンスカウンターの現在の値を要求します。

Pervasive PSQL は、パフォーマンスモニターで表示するためだけにデータを提供しており、カウンターのプロパ

ティは変更できません。パフォーマンスモニターは以下のアイテムを制御します。

データの表示形式。折れ線グラフ（デフォルト）、ヒストグラムおよびテキストレポートの 3 種類の形式で

表示されます。

表示フィールド。［新］、［平均］、［小］および［大］というラベルが付けられています。

値の表示用のスケール。 Pervasive PSQL は各カウンターに対してデフォルトのスケールを提供します。パ

フォーマンスモニターを使用すれば、個々のカウンターのスケールを変更することができます。「カウンター

のスケールを変更するには」を参照してください。

カウンターの値は、呼び出し元を問わず、データベースエンジンへのすべての呼び出しを反映します。つまり、

トランザクショナルインターフェイス、リレーショナルインターフェイス、ネイティブな Btrieve アプリケーショ

ン、ユーティリティなど、すべてがカウンターの値の一因となります。カウンターの値はすべてのファイルを対

象に収集されます。ファイルごとのカウンターは現在サポートされていません。

パフォーマンスカウンターの使用は、主にアプリケーション開発者およびその他の技術スタッフ向けの高度な機

能です。 Windows パフォーマンスモニターおよび一般的なカウンターの使用の詳細については、 Microsoft の関

連ドキュメントを参照してください。

インストール時の登録

デフォルトで、 Pervasive PSQL のインストールでは Pervasive PSQL パフォーマンスカウンターをパフォーマンス

モニターに登録します。このカウンターはインストール完了後に使用できるようになります。

お客様のニーズへの対応のため、本章で説明されていない Pervasive PSQL コレクターセットまたはカウンターを

追加インストールすることになる可能性もあります。そのような場合は、Windows パフォーマンスモニターで提

供されるコレクターセットまたはカウンターの説明を参照してください。「カウンターセットまたは個別のカウ

ンターをモニターへ追加する」を参照してください。

データコレクターセット

データコレクターセットは、複数のカウンターを 1 つのコンポーネントにまとめています。このコンポーネント

を使用してパフォーマンスを再確認したり記録したりすることができます。 Pervasive PSQL では以下のデータコレクターセットを提供します。

「Pervasive PSQL MicroKernel Btrieve Operations」

「Pervasive PSQL MicroKernel Cache」

「Pervasive PSQL MicroKernel I/O」

「Pervasive PSQL MicroKernel Locks and Waits」

「Pervasive PSQL MicroKernel Transactions」

Pervasive PSQL MicroKernel Btrieve Operations

これらのカウンターは、トランザクショナル（Btrieve）インターフェイスに関するクライアントアプリケーショ

ンの動作の特徴を示すために役立ちます。カウンターは、指定した時点にデータベースエンジンで処理されたオ

ペレーションの種類を報告します。

『Btrieve API Guide』の「Btrieve API オペレーション」も参照してください。

74


Pervasive PSQL MicroKernel Cache

データベースエンジンは 2 つのレベルのメモリキャッシュシステムを使用してデータ操作のパフォーマンスを

向上させます。 2 つのキャッシュは「L1 （レベル 1）キャッシュ」と「L2 （レベル 2）キャッシュ」と呼ばれます。

ユーザーの要求に応じエンジンがディスクからページを読み取る頻度が高くなるほど、パフォーマンスは低下し

ます。これらのカウンターを使用すると、データベースエンジンによるディスク読み込みの回避状況をまとめて

表示し、キャッシュサイズの設定に対してなんらかの変更が必要かどうかを判断することができます。

すべてのデータが L1 キャッシュに格納された場合は高のパフォーマンスが得られます。ただし、データファ

イルのサイズによっては、 L1 キャッシュにすべてのデータページを保持できないこともあります。このため、

データベースエンジンは第 2 レベルのキャッシュ（L2 キャッシュ）も使用します。 L2 キャッシュのページは圧

縮形式で格納されるため、より多くのページをメモリに入れることができます。そのため、 L1 キャッシュよりも

パフォーマンスは低下しますが、データベースエンジンがディスクからページを読み込む状況と比べればパ

フォーマンスは高くなります。

「データベースのメモリキャッシュの理想的なサイズを計算するには」も参照してください。

表 15 MicroKernel Btrieve オペレーション用のカウンター

カウンター説明典型的な使用法

Btrieve Close Operations/sec 1 秒あたりの Btrieve Close オペレーション数。クライアントアプリケー

ションの動作を調査しま

す。問題を解決する初の

ステップとして、 Btrieve オペレーションに関するアプ

リケーション動作の分析に

役立つ可能性があります。

Btrieve Get/Step Operations/sec 1 秒あたりの Btrieve Get および Step オペレーション数。

各種 Get および Step オペレーションについては、『BtrieveAPI Guide』の「Btrieve API オペレーション」を参照して

ください。

Btrieve Open Operations/sec 1 秒あたりの Btrieve Open オペレーション数。

Btrieve Records Deleted/sec 1 秒あたりの Btrieve レコード削除数。

Btrieve Records Inserted/sec 1 秒あたりの Btrieve レコード挿入数。

Btrieve Records Updated/sec 1 秒あたりの Btrieve レコードアップデート数。

Change Operations/sec 1 秒あたりのデータファイルを変更する Btrieve オペレー

ション数。

Operations/sec 1 秒あたりのオペレーション数。

Page Server Requests/sec 1 秒あたりのリモートキャッシュエンジンからのページ

リクエスト数。

75


表 16 MicroKernel キャッシュ用のカウンター


Level 1 Cache Dirty Percentage ダーティページを含む使用

中の L1 キャッシュの割合

(%)。

頻繁にアクセスされるページが継続的にキャッシュの

外へ出されるかどうかを判断するのに役立ちます。そ

のようなページが継続的にキャッシュの外へ出される

とパフォーマンスが低下する可能性があります。

ディスクへ書き込まれていない変更を含むダーティ

ページは、 L1 キャッシュに存在しているだけかもしれ

ません。大量に書き込みが行われる状況下では、 L1キャッシュにダーティページが含まれる可能性が高く

なります。これによってページが強制的に L1 キャッ

シュから出され、 L2 キャッシュを設定していれば L2キャッシュへ入れられます。 L2 キャッシュを設定して

いなければ L1 キャッシュの外へ完全に出されてしま

います。

データベースエンジンは、指定した間隔で、または L1キャッシュがほぼいっぱいになったときにダーティ

ページをディスクへ書き込みます。ページが頻繁に

ディスクへ書き込まれると、パフォーマンスに悪影響

を及ぼす可能性があります。

L1 キャッシュのサイズを調整してダーティページの

割合が高くならないようにすれば、パフォーマンスを

向上させることができます。「キャッシュ割当サイズ」

も参照してください。

Level 1 Cache Hits/sec 1 秒あたりの L1 キャッシュ

ヒット数。

データベースエンジンが、要求されたページを L1キャッシュで見つけることができたかどうかを判断す

るのに役立ちます。ヒット率が高くなると、データベー

スエンジンが L2 キャッシュまたは物理記憶域へアク

セスすることなく L1 キャッシュでページを見つけて

いることを示します。

Level 1 Cache Hit Ratio L1 キャッシュアクセスの

ヒット率 (%) 。

MicroKernel が有効である間

だけ割合が表示されます。

Level 1 Cache Misses/sec 1 秒あたりの L1 キャッシュ

失敗数。

Level 1 Cache Usage 現在使用中の L1 キャッシュ

の割合 (%)。L1 キャッシュのサイズをアプリケーションに応じて調

整する場合に役立ちます。たとえば、サイズが小さな

データファイルまたは主に読み取り専用のデータファ

イルを使用するアプリケーションの場合、デフォルト

で設定された L1 キャッシュはそのデータファイルだ

けではいっぱいにならないかもしれません。 L1 でメモ

リが使用されなくても、オペレーティングシステムま

たはその他のアプリケーションがその未使用分のメモ

リを使用することはできません。

L1 キャッシュサイズを適宜変更すれば、メモリをオペ

レーティングシステムへ解放することができます。逆

に、データベース全体をメモリに入れておきたい場合

は、L1 キャッシュサイズの設定が妥当かどうかを知る

ためにこの値を監視することができます。

76


Pervasive PSQL MicroKernel I/O

このセットのカウンターは、データベースエンジンによる、物理記憶域へのデータの読み取りおよび書き込み状

況を把握するのに役立ちます。カウンターによって報告されるページとはデータファイルページです。これらの

カウンターでは、アーカイブログまたはトランザクションログ向けに使用されるファイルのページ用のデータは

報告しません。

『Pervasive PSQL Programmer's Guide』の「ページ」も参照してください。

Level 2 Cache Hits/sec 2 秒あたりの L1 キャッシュ

ヒット数。

データベースエンジンが、要求されたページを L2キャッシュで見つけることができたかどうかを判断す

るのに役立ちます。ヒット率が高くなると、データベー

スエンジンが物理記憶域へアクセスすることなく L2キャッシュでページを見つけていることを示します。

Level 2 Cache Hit Ratio L2 キャッシュアクセスの

ヒット率 (%) 。

MicroKernel が有効である間

だけ割合が表示されます。

Level 2 Cache Misses/sec 1 秒あたりの L2 キャッシュ

失敗数。

Level 2 Cache Raw Size L2 キャッシュの現在のサイ

ズ ( バイト )。任意指定の L2 キャッシュサイズを決定するために役

立ちます。

L2 キャッシュは「MicroKernel の大メモリ使用量」用

に設定される要素の 1 つです。その設定は、総物理メ

モリに対してデータベースエンジンが消費できるメモ

リの割合を指定します。これには、データベースエン

ジンによる、L1 キャッシュ、L2 キャッシュおよびその

他すべてのメモリの使用量が含まれます

「MicroKernel の大メモリ使用量」の設定が 0 以外の

場合、 L2 キャッシュのサイズはその設定によるメモリ

制限内に収まります。 L2 キャッシュはシステムのメモ

リ消費を監視し、必要に応じて自身のサイズを変更し

ます。 L2 キャッシュによって使用されるメモリは、オ

ペレーティングシステムによってスワップアウトされ

ることもあります。

Level 2 Cache Raw Usage 現在使用中の L2 キャッシュ

の量 ( バイト )。

Level 2 Cache Size Relative toMemory

物理メモリに対する L2キャッシュサイズの割合

(%)。

システムメモリに対する L2 キャッシュの使用割合を

示します。

Level 2 Cache Usage 現在使用中の L2 キャッシュ

の割合 (%)。現時点における L2 キャッシュの使用割合を示します。

表 17 MicroKernel 入力 / 出力用のカウンター


Pages Read/sec 1 秒あたりのディスクからの読み取り

ページ数。

データベースエンジンによる、物理記憶域

へのデータの読み取りおよび書き込み状況

を測定します。Pages Written/sec 1 秒あたりのディスクへの書き込み

ページ数。

表 16 MicroKernel キャッシュ用のカウンター


77


Pervasive PSQL MicroKernel Locks and Waits

クライアントの要求は、リソースが使用可能になるのを待つため遅延することがあります。これらのカウンター

を使用すれば、リソースが使用可能になるまでクライアント要求を待つ必要があるデータベースリソースのタイ

プを特定することができます。同様に、これらのカウンターでは複数のクライアントがリソースへアクセスした

ときのデータベースエンジンの動作を観察することができます。値がクライアント数に近いまたは等しい場合

は、同じリソースに対して競合している可能性があることを示しています。これらの競合を低減するための是正

措置を行えば、反応性を改善することができます。

「Waits on Page Buffers」および「Waits on Page Reads」カウンターはグローバルリソースを待機します。その他の

カウンターはすべて複数のクライアントに適用しますが、各クライアントはそれぞれ異なるリソースを待機して

いる場合があります。

『Pervasive PSQL Programmer's Guide』の「データの整合性」および「複数のクライアントのサポート」を参照し

てください。

表 18 MicroKernel ロックおよび待機用のカウンター


Client Record Locks クライアントによって明示的にロックされた

レコード数。

クライアントアプリケーションの作業負

荷を調査します。

Waits on Active Reader Lock アクティブなリーダーロックを待機中のクラ

イアント数。複数のクライアントが同時にアク

ティブなリーダーロックを保持できます。ただ

し、アクティブなリーダーロックとアクティブ

なライタロックは排他的に使用されます。その

ため、 1 つのクライアントがアクティブなリー

ダーロックを保持すると、どのクライアントも

アクティブなライタロックを取得することは

できません。 1 つのクライアントがアクティブ

なライタロックを保持すると、複数のクライア

ントがアクティブなリーダーロックを取得す

ることはできません。各ファイルがそれ自身の

リーダー（およびライタ）ロックを持っていま

す。

「Waits on Active Writer Lock」カウンターも参照


Waits on Active Writer Lock アクティブなライタロックを待機中のクライ

アント数。一度に 1 つのクライアントだけがア

クティブなライタロックを保持できます。各

ファイルがそれ自身のライタ（およびリー

ダー）ロックを保持します。

「Waits on Active Reader Lock」カウンターも参照


Waits on File Locks 現在ファイルロックで待機中のクライアント数。

78


Pervasive PSQL MicroKernel Transactions

これらのカウンターは、トランザクションに関するクライアントアプリケーションの動作を理解するために役立

ちます。たとえば、変更が多く処理に長時間かかる少数のトランザクションと、短時間で処理が完了する多くの

トランザクションとでは動作が異なります。

『Btrieve API Guide』の「Begin Transaction （19 または 1019）」、「End Transaction （20）」および「Abort Transaction（21）」、また『Pervasive PSQL Programmer's Guide』の「トランザクショナルインターフェイスの基礎」も参照し

てください。

Waits on Page Buffers ページバッファーが利用可能になるのを待機

中のクライアント数。もしページがリクエスト

に応じるためにアクセス可能でない場合は、リ

クエストは MicroKernel が 1 ページを提供する

ことが可能になるまでブロックします。

データベースエンジンが、キャッシュの

ページバッファーを使用できるかどうか

を示します。この値をメモリキャッシ関

連のカウンターと一緒に使用して、キャッ

シュのサイズが作業負荷に対して適切か

どうかを確認します。キャッシュサイズ

を大きくすると使用可能な総ページ数も

増えます。これにより、ページバッファー

への待機を減らすことができます。

キャッシュにページがない場合は、以下の

3 つ状況によってこの値が急増する可能

性があります。

データファイルが近開かれた

データページへ初めてアクセスする、

またはそのデータページへアクセス

することがほとんどない

メモリキャッシュが、頻繁にアクセス

および変更されるすべてのページを含

めることができないほど小さい可能性

がある

1 番目と 2 番目の項目によって値が急増す

るのは、ファイルへのアクセスが初めてで

あるため回避することはできません。 3 番目の状況はキャッシュサイズを大きくす

ることで回避できます。キャッシュがいっ

ぱいでキャッシュ失敗数が多くなると、メ

モリキャッシュが小さすぎて、頻繁にア

クセスおよび変更されるすべてのページ

を含めることができない可能性がありま

す。

「MicroKernel キャッシュ用のカウンター」

も参照してください。

Waits on Page Locks 現在ページロックで待機中のクライアント数。クライアントアプリケーションの作業負


Waits on Page Reads ディスクからページ読み取りを待機中のクラ

イアント数。 1 つのクライアントが既にページ

の読み取り処理を行なっている場合、ほかのク

ライアントは処理中の読み取りが完了するま

で待機しなければなりません。

同時に同じファイルの同じページへの読

み取りを試みるクライアント数を測定し

ます。

Waits on Record Locks 現在レコードロックで待機中のクライアント数。クライアントアプリケーションの作業負


表 18 MicroKernel ロックおよび待機用のカウンター


79


Windows パフォーマンスモニターの使用

このセクションでは、 Windows パフォーマンスモニターの基本的な使用手順について説明し、 Pervasive PSQL パフォーマンスカウンターを使用できるようにします。 Windows パフォーマンスモニターの使用に関する詳細に

ついては、 Microsoft のドキュメントを参照してください。

以下に示す手順は、 Pervasive PSQL のインストールによって Pervasive PSQL パフォーマンスカウンターが

Windows パフォーマンスモニターに登録されていることを前提としています。

Pervasive PSQL データコレクターセットを表示する

1 Windows パフォーマンスモニターを起動します。このユーティリティの起動手順はオペレーティングシス

テムによって異なりますが、一般的には［コントロールパネル］の［管理ツール］から起動することができ

ます。また、［ファイル名を指定して実行］ウィンドウ（［スタート］メニューから［ファイル名を指定して

実行］を選択）で、「perfmon」と入力し［OK］をクリックして起動することもできます。

2 左ペインのツリーから［パフォーマンスモニター］をクリックし、右ペイン上部のツールバーにあるプラス

記号（＋）をクリックします。

3 ［使用可能なカウンター］セクションのカウンターリスト内で、 Pervasive PSQL データコレクターセットへ

スクロールします。

表 19 MicroKernel トランザクション用のカウンター


System Transactions in Progress 進行中のシステムトラン

ザクション数。システム

トランザクションはデー

タファイルの変更を準備

し、その変更をファイルに

保持し続ける特殊なタイ

プのトランザクションで

す。

システムトランザクションの発生頻度が高すぎるまたは低

すぎるかどうかを判断するために役立ちます。

データベースエンジンは、システムトランザクション中に

変更をデータファイルへ書き込みます。システムトランザ

クションが発生する頻度は、「起動時間制限」および「オペ

レーションバンドル制限」という 2 つのサーバー設定パラ

メーターによって決められるか、あるいは L1 キャッシュの

空き領域が少ないことが影響します。

通常、システムトランザクションの実行頻度が高すぎたり低

すぎたりするとパフォーマンスに悪影響を及ぼします。一般

的には、 1 秒あたりのページ書き込み数が増加し、レコード

を変更する Btrieve オペレーション数は減少し、またアクティ

ブなライタロックを待機するクライアント数は増加する可

能性があります。これは特定の作業負荷に対する理想的な間

隔を測定するための実験が必要となることもあります。

Transaction Commits/sec 1 秒あたりに実行された

コミット数。

アプリケーショントランザクションのコミット数を測定し

ます。『Btrieve API Guide』の「End Transaction （20）」も参照


80


カウンターセットまたは個別のカウンターをモニターへ追加する

1 以下の手順のいずれかを実行します。

a. カウンターセットとしてまとめて追加するには、［使用可能なカウンター］リストから希望のカウン

ターセット項目をクリックします。

b. カウンターを個別に追加するには、そのカウンターが属するカウンターセットを展開し（カウンター

セットの項目をダブルクリック、または右端の下矢印をクリック）、その中から対象のカウンターをク

リック（複数クリック）します。

カウンターの説明を見るには、［説明を表示する］オプションを選択してください。

81


2 ［追加］をクリックしてから［OK］をクリックします。

カウンターのスケールを変更するには

1 作業対象のカウンターを右クリックし、［プロパティ］をクリックします。

2 ［データ］タブで、［スケール］ドロップダウンリストから希望の値をクリックします。

同じグラフ上に 2 つ以上のカウンターを表示する場合に、それらカウンターの出力数値の差が非常に大きい

場合は、適切に表示されるようスケールを調整する必要があるかもしれません。データがグラフ化される前

に、カウンターの出力値にスケール値を掛けます。たとえば、 1 番目のカウンターの出力値が 53 と 99、 2 番目のカウンターの出力値が 578 と 784 であるとします。 1 番目のカウンターのスケールに 10 を設定すること

で、 530 および 990 と出力されるようにするこができます。これにより、両カウンターのデータをより同等

（530、 990、 578 および 784）に見ることができます。


82


［スケール］フィールドの値は、元の値（この例では 1）から新しい値（この例では 10）に変更されています。

4 ［グラフ］タブで、［垂直スケール］セクションの［大］および［小］フィールドに必要な値を設定します。

グラフ化される対象が非常に小さい（または非常に大きい）場合は垂直スケールを変更することができるの

で、グラフが見やすくなります。たとえば、カウンターの出力値が常に 20 未満の場合は、垂直スケールの

大を 20、小を 0 に変更することができます。


83



このセクションでは、データベース初期接続および実行時オペレーションでパフォーマンスを大にするための

一般的なヒントをいくつか提供します。一般的なガイドラインをいくつか示しますが、特定のアプリケーション

のパフォーマンスは、以下に挙げる要因だけに限らず、非常に多くの要因によって変わります。

ネットワークの帯域幅および使用率

アプリケーションでのコーディング技法

使用可能な物理記憶域

使用可能なメモリ

プロセッサの速度

アプリケーションでの使用パターン（大量の書き込み、大量の読み込み、トランザクションの使用 / 不使用、

レコードサイズの大小、複雑または単純なクエリ、 ODBC、 Btrieve のみ、など）

CPU サイクルで競合する無関係なアプリケーション

データベースエンジン設定

ご覧のように、エンジンの設定は一定のアプリケーションの全体のパフォーマンスの中では比較的限定的な役割

を果たします。さらに、データベースエンジンは使用パターンに基づいてさまざまなリソースを動的に管理しま

す。データベースエンジン自体が、必要に応じ環境に合わせてチューニングします。以下のセクションで提供す

るのは、有用なガイドラインにすぎず、特定のレベルのパフォーマンスを保証するものではありません。

パフォーマンスのボトルネックを見極める

Monitor ユーティリティを使用すると、特定のデータベースエンジンの設定オプションに関連するパフォーマン

スのボトルネックを明らかにすることができます。オペレーティングシステムの［スタート］メニューまたはア

プリ画面から、あるいは Pervasive PSQL Control Center の［ツール］メニューから Monitor を起動します。

Monitor の表示と設定オプション

Monitor のメニューにある 2 つの選択肢によって、設定オプションに関連するパフォーマンスの値が表示されま

す。

MicroKernel ｜リソース使用状況

MicroKernel ｜通信

次の表に示すように、データベースエンジンは複数のサーバー設定オプションを動的に管理します。

表示および動作の解釈

Monitor に表示される情報を活用することができます。 Monitor はリソースのタイプごとに 3 つの情報を表示しま

す。たとえば、リモートセッション総数には次のように表示されます。

表 20 Monitor で表示される、動的に管理されている設定

動的に管理される設定リソース使用状況ウィンドウに

表示される値

通信統計情報ウィンドウに

表示される値

ファイル数 ○

ハンドル数 ○

クライアント数 ○

ワーカスレッド数 ○

リモートセッション総数 ○

84


現在値。実際に動作しているリモートセッションの現在の数。

ピーク値。エンジンが開始されてから実際に使用されたリモートセッションの大数。

大値。リモートセッションの使用可能な大数。

リソースのピーク値と大値が同じ場合には、そのリソースの大値を増やすように設定プロパティを設定すれ

ば、データベースエンジンは、必要な場合に特定のリソースの追加のインスタンスを割り当てることができます。

設定プロパティを変更する前に

以下のセクションでは、次のことを前提とします。

1 Pervasive PSQL Control Center (PCC）が既に開いていること。

このタスクについての説明が必要な場合は、『Pervasive PSQL User's Guide』の「Windows での PCC の起動」


2 構成しようとするエンジンが既に登録済みであること（可能な場合）。

このタスクについての説明が必要な場合は、『Pervasive PSQL User's Guide』の「リモートサーバーエンジン

を登録するには」を参照してください。

3 所定のエンジンを構成するには、オペレーティングシステムの適切な権限が必要です。

このタスクについての説明が必要な場合は、『Pervasive PSQL User's Guide』の「データベースエンジンの管

理者権限の許可」を参照してください。

4 一部のエンジン設定については、設定を変更した後にデータベースエンジンの再起動が必要になります。

初期接続時間を小限にする

短接続時間の基礎を成す理論は、 3 つの必要条件を中心に展開します。これらの必要条件についての要約は次

のようになり、詳細についてはその後で説明します。

既知の通信プロトコル。クライアントまたはサーバーが、その環境でサポートされていないプロトコルを介

して接続を試行するために余計な時間を費やすことは望ましくありません。クライアント / サーバーが使用

できないプロトコルを削除することにより、ネットワークコンポーネントがそれらの使用を試行することを

防げます。

既知のデータベースエンジンのロケーション。クライアントが存在しないエンジンへの接続を試行すること

は望ましくありません。ワークグループのみのサポート、またはサーバーのみのサポートを適切に指定する

ことにより、クライアントが存在しない接続でタイムアウトになることを防ぐことができます。非共有およ

び共有データベースの両方がある環境では、ゲートウェイの一貫性保守を使用して、データベースエンジン

がデータベースエンジンの実行されていないマシンを常に知ることができ、これにより、これらのマシン上

のエンジンへの接続を試行せず、別の方法でデータにアクセスします。

実行準備の整ったデータベースエンジン。休止しているエンジンが新しい接続リクエストを受け取ると、リ

ソースの再割り当ておよび実行時の状態に戻るのに時間がかかります。接続スピードがサーバー上のリソー

ス使用量より重要な場合は、サーバーエンジンが使用されていないときにも休止しないようにすることがで

きます。

クライアントのプロパティ

クライアントのプロパティの変更は、そのクライアントマシンで行う必要があります。設定を変更したい各ワー

クステーションでプロパティを変更する必要があります。

クライアント側の接続待ち時間を小限にするには

1 Pervasive PSQL エクスプローラーで、ツリーのローカルクライアントノードを展開します（ノードの左の展

開アイコンをクリックします）。

2 ［MicroKernel ルーター］を右クリックします。

85



4 プロパティツリーで［通信プロトコル］をクリックします。

5 ［サポートプロトコル］で、必要なプロトコルにはチェックマークが入って選択されており、使用されない

プロトコルのチェックマークは外されているようにします。

6 ［適用］をクリックします。

これで、クライアントが、使用されていないプロトコルと通信しようとするのを妨ぐことができるようにな

りました。

7 プロパティツリーで［アクセス］をクリックします。

8 リモートサーバーまたはリモートワークグループエンジンのみを使用している場合は、［ローカル

MicroKernel エンジンの使用］のチェックマークを外すようにします（つまり、オフに設定します）。

ローカルワークグループエンジンのみを使用している場合は、［リモート MicroKernel エンジンの使用］の

チェックマークを外すようにします（つまり、オフに設定します）。

ワークグループエンジンを使用することもあり、また、サーバーエンジンまたはリモートワークグループ

エンジンへ接続することもある場合には、両方の設定をオンにして（チェックを入れて）おく必要があります。

このような共有と非共有データの混合環境では、各クライアントで［ゲートウェイ一貫性保守］をオンに設

定しておくことができます。この設定によって、データベースエンジンに接続することができないすべての

マシンの名前のリストを強制的にクライアントソフトウェアに保持させます。クライアントソフトウェア

が、指定されたコンピューターにはエンジンが存在しないことを判定するには、すべてのネットワークプロ

トコルのリクエストがタイムアウトになるまで待ちます。

Pervasive データベースエンジンを持たないサーバーにデータが格納されていて、［リモート MicroKernel エンジンの使用］の設定がオンの場合、クライアントはそのマシンにエンジンがないことを知るために少なく

とも 1 度はタイムアウトを待たなければなりません。ゲートウェイ一貫性保守を使用すると、アプリケーショ

ンがそのデータに初にアクセスしたときのみにこのタイムアウトが起きるようにできます。

メモゲートウェイ一貫性保守を使用すると、ネットワークトポロジを固定します。後に、リモートコン

ピューターにサーバーまたはワークグループエンジンをインストールする場合、各クライアントで［ゲート

ウェイ一貫性保守］をオフにして、データベースエンジンを持たないコンピューターのリストが削除される

ようにする必要があります（これにより新しいデータベースエンジンに接続できるようになります）。［ゲー

トウェイ一貫性保守］に戻ると、リストは空になっています。


これで、クライアントが、使用されていないデータベースエンジンに接続しようとするのを防ぐことができ

ます。

サーバーのプロパティ

サーバー側の接続待ち時間を小限にするには



2 設定を指定するデータベースエンジンを右クリックします。


4 ［サポートプロトコル］で、必要なプロトコルにはチェックマークが入って選択されており、使用されない

プロトコルのチェックマークは外されているようにします。

5 ［適用］をクリックします。

86


これで、サーバーが、使用されていないプロトコルと通信しようとするのを防ぐことができます。

メモサーバーの設定で選択したプロトコルの少なくとも 1 つが、クライアントの設定で選択されたものと

同一であることを確認してください。サーバーとクライアントは同じプロトコルを使用しなければ通信でき

ません。

6 プロパティツリーで［メモリの使用］をクリックします。

7 ［起動時のリソース割当］をクリックして、値をオンに設定します（チェックボックスを選択）。

このオプションは、データベースエンジンが必要なすべてのメモリを割り当てるタイミングを、初の接続

要求が入ってきたときではなく、起動時とします。この値を選択すると、より多くのメモリが必要ですが、

クライアントから見ると、エンジンの処理速度が速くなります。

8 ［非アクティブ時、小の状態に戻す］をオフに設定します（チェックボックスをクリア）。

このオプションは、データベースエンジンが非アクティブなときにも、リソースを解放してオペレーティン

グシステムに戻さないことを指定します。すべてのリソースは割り当てられたままで、次のクライアント接

続に備えられます。


10 これらの変更を有効にするために、［はい］をクリックしてエンジンを再起動します。

ランタイムのスループットを大にする

大スループットを得るための原理は、ここに挙げる非常に多くの要因に依存します。も重要な要因のいくつ

かを挙げます。

十分な物理メモリ。ホストシステムの RAM が少なすぎる場合、異なるユーザーおよびプロセスが限られた

リソースを競い合うと、システムはその時間と CPU サイクルのほとんどをメモリとディスクのスワップに費

やすことになります。

十分な CPU 能力。 CPU が、データ処理リクエストの流入量について行けなくなると、アプリケーションの

パフォーマンスが悪影響を受けます。

十分なネットワーク帯域幅。ネットワークが遅かったり、高いコリジョン率によって悪影響を受けている場

合、データベースエンジンはデータアクセスのリクエスト間で休止状態になり、各クライアントでは低いパ

フォーマンスを示します。

小限のディスク I/O。ディスク I/O は、メモリ I/O より著しく速度低下を招きます。十分なキャッシュを確保して、できる限りディスクにアクセスすることを避けます。

十分なリソース割り当て。大きな物理メモリが使用可能であっても、データベースエンジンの設定プロパ

ティが人為的に低く設定されている場合には、データベースのパフォーマンスは悪くなります。

結局、適化されたパフォーマンスは、ネットワークのボトルネック、ディスク I/O のボトルネック、メモリの

ボトルネック、および CPU のボトルネックの間を綱渡りすることで実現しています。このセクションでは、メモ

リおよびディスク I/O のボトルネックを減少させる方法のガイドラインをいくつか示します。

速いディスクと速い CPUハードウェアへの投入費用に対しパフォーマンス向上の効果を大にしたければ、既存のパフォーマンスの制約

を理解する必要があります。データベースが非常に大きくて、データベースの主要な部分をキャッシュに入れる

ための十分なメモリを購入してインストールするのが妥当でない場合、パフォーマンスはディスク I/O によって

制約を受けがちです。これらの状況では、速い RAID ディスク配列に費用をかけてディスク I/O のパフォーマン

スを大にします。

さらに、アプリケーションが SRDE を使用していて一時ファイルを頻繁に作成する場合、これらのファイルが作

成されるディレクトリが速いディスクドライブであることを望むでしょう。このディレクトリの場所および一時

87


ファイルを作成するクエリのタイプの詳細については、『SQL Engine Reference』の「テンポラリファイル」を参


データベースが小さくてメモリに全部またはほとんどがキャッシュできる場合、速いディスク配列の追加では著

しいパフォーマンス向上を得る可能性はありません。このような状況下では、CPU をアップグレードするか CPUを追加することにより高のパフォーマンス改善値が得られます。

十分な物理メモリとデータベースキャッシュを確保する

Pervasive.SQL バージョン 8 以降を使用する場合、データベースエンジンは設定プロパティで設定したキャッシュ

割当サイズのレベル 1 キャッシュに加え、レベル 2 動的キャッシュを提供します。 MicroKernel の大メモリ使

用量にゼロを設定してレベル 2 動的キャッシュを無効にしないとすれば、レベル 1 キャッシュサイズを手動で調

整するのは、以前のリリースよりずっと楽です。これを念頭において、このセクションでは、データベースエン

ジンの適なパフォーマンスのための十分なメモリを確実に利用できるようにする方法を説明します。

理想的には、データベースエンジンが十分なメモリを割り当てることができ、管理する各データベースの完全な

コピーをキャッシュできれば、ディスク I/O を大限避けることができます。 1 つまたは複数のデータベース全

体をキャッシュするのは状況によって、特にデータベースサイズが非常に大きい場合には、明らかに実用的では

ありません。さらに、既存のシステムリソースが通常の使用でも大きな負荷がかかっている場合、パフォーマン

スを向上させる対策はマシンに RAM を追加することだけです。

データベースエンジンは初に起動されたときに動的にレベル 1 キャッシュ値を選択します。ただし、この値は

使用可能なメモリに基づいていて、その環境で理想的なキャッシュ量になるとは限りません。

データベースのメモリキャッシュの理想的なサイズを計算するには

1 まず、データベースエンジンがサービスするすべてのデータベースファイルのサイズを合計します。

メモエンジンがサービスするデータベースが 2 つ以上あっても、同時に使用されない場合は、大きい方の

サイズだけを加算します。

たとえば、サーバー上に 2 つのデータベースがあり、それらのサイズは以下のとおりで、ユーザーが同時に

両方のデータベースにアクセスするとします。

これらすべてのファイルの合計は 1,430 MB です。

今得た値は、データベースエンジンがホストするすべてのデータをキャッシュした場合に使用するメモリの

大量です。この数値を MaxCache と呼びます。

キャッシュ割当サイズに、これより大きい値を指定しようとは考えないでしょう。そうすることは、データ

ベースエンジンにまったく使用しないと思われるメモリを割り当てることになるからです。実際の運用に妥

当なのは、キャッシュ割当サイズに MaxCache の 20% から 70% を設定することです。この範囲中で低い値は

読み取り処理の多いアプリケーションに適で、高い値は書き込み処理の多いアプリケーションに適です。

それは、すべての書き込み / 更新操作はレベル 1 キャッシュで行われるからです。

データベース A データベース B

file1.mkd 223 MB Afile.mkd 675 MB

file2.mkd 54 MB Bfile.mkd 54 MB

file3.mkd 92 MB Cfile.mkd 318 MB

file4.mkd 14 MB

88


メモファイルページは、アクセスされたときにのみデータベースキャッシュに書き込まれます。したがっ

て、データベースエンジンはデータベースのすべてのページがアクセスされるたびに MaxCache を必要とし

ます。この評価方式により、長期間安定した状態でデータベース処理を行うことができます。データベース

エンジンを毎晩または毎週停止する場合、一定の稼働時間内にデータベースエンジンが、データベースのす

べてのページにアクセスすることはあまりありません。

このような状況の場合、一定の稼動期間にアプリケーションが別個のページに平均何回アクセスするかを見

積もり、ページサイズを掛けて、特定の稼動期間のより現実的な MaxCache の値を求めたいでしょう。

「MicroKernel キャッシュ用のカウンター」も参照してください。

Windows 32 ビットオペレーティングシステムでは、すべてのユーザープロセスのメモリは 2GB に制限されてい

ます。MaxCache の計算値が 2 GB より大きく、データベースエンジンが 32 ビット Windows オペレーティングシステム上で実行される場合、 MaxCache に 2 GB の値を使用します。

必要な物理メモリ総量を決定するには

次の方程式を使用して、データベースエンジンで必要とされる総物理メモリ量の近似値を割り出します。

データベースの大メモリ使用量 = L1 キャッシュサイズ + 内部割り当て + L2 キャッシュサイズ

各項目の説明は次のとおりです。

L1 キャッシュサイズ：「キャッシュ割当サイズ」

内部割り当て： L1 キャッシュの約 25% のサイズ

L2 キャッシュサイズ：システムのメモリロードに基づいて拡大および縮小するメモリ容量

以下の点に注意してください。

L1 キャッシュは「キャッシュ割当サイズ」に基づく固定サイズです。このサイズはデータベース操作に

よって拡大したり縮小したりすることはありません。アプリケーションで多数の書き込み操作を行う場

合は、この L1 キャッシュをできるだけ増やしてください。

すべてのデータを L1 キャッシュに収容することができれば、高のパフォーマンスが得られます。す

べてのデータが L1 キャッシュに収容されない場合は、「キャッシュ割当サイズ」および「MicroKernelの大メモリ使用量」を調整して妥当なシステムメモリ量を使用します。

L2 キャッシュは、システムのメモリロードに基づいて拡大および縮小します。たとえば、ほかのアプ

リケーションでより多くのメモリが必要となった場合、L2 キャッシュは縮小します。十分なメモリが使

用可能であれば、 L2 キャッシュは上記の方程式に基づいて大量に達します。 L2 キャッシュの拡大や

縮小はパフォーマンスに影響します。縮小した場合は、データページが L2 キャッシュから除去される

などの事象が起こります。ディスクストレージからのデータページの読み取りは、キャッシュに保持さ

れたデータページの読み取りと比べ、より時間がかかります。

L2 キャッシュには圧縮データページが含まれます（少ないスペースにより多くのページが収まります）。

L2 キャッシュからのページアクセスは、L1 キャッシュからのページアクセスよりも時間がかかります

が、ディスクストレージからのページアクセスに比べれば処理が速くなります。多数の読み取り操作を

実行するアプリケーションで L2 キャッシュは役立ちますが、すべての読み取りデータページを L1キャッシュに収容することはできません。

ディスク I/O を小限にする

ディスクからの読み込みおよびディスクへの書き込みは、メモリに対するそれよりずっと時間がかかります。し

たがって、パフォーマンスを適化する 1 つの方法はディスクの動作を小限にすることです。

ディスク I/O を小化する上での重要な考慮点はデータの回復の可能性です。ディスク I/O は、トランザクショ

ン一貫性および回復可能性に対する直接的な交換条件です。変更のログをディスクに書き込むための停止なしで

データをメモリに保持するほど、データベースのパフォーマンスは速くなります。一方、変更のログをディスク

89


に書き込むための停止を行わずにデータをメモリに保持するほど、システムに異常をきたした場合に失うデータ

が増えます。

ディスク I/O を減少させるには

1 前のサブセクション、「十分な物理メモリとデータベースキャッシュを確保する」で説明したように、も

重要な考慮点の 1 つは、ディスクおよびキャッシュ間のデータページの頻繁なスワップを避けるために十分

なデータベースメモリキャッシュを確保することです。詳細については、そのセクションを参照してくださ

い。

ディスク I/O を減らす良の方法の 1 つは、動的なレベル 2 キャッシュを必ずオンにすることです。レベル

2 キャッシュはキャッシュ要求がレベル 1 固定キャッシュの容量を超えたとき、アプリケーションの使用量

の変化によってサイズを動的に調整して可能な限り多くのデータをメモリに格納し、それによりディスク I/O を減らします。デフォルトで、レベル 2 キャッシュはオンになっています。データベースエンジンがレベ

ル 2 キャッシュを使用していることを確認するには、設定プロパティの［MicroKernel の大メモリ使用量］

を調べます（「MicroKernel の大メモリ使用量」を参照してください）。

2 次に、システム異常の場合に、どれだけのロギングが必要で、どれだけのデータベースオペレーションを

失ってもかまわないかを考慮します。失ってもかまわない変更が多いほど、パフォーマンスの向上を追求す


「アーカイブログの使用」、「トランザクション一貫性保守」、および「トランザクションログ」はすべてロ

グファイルを必要とします。デフォルトで、アーカイブロギングはオフになっています。定期的なバック

アップを実行し、システム異常の時点のデータに回復する能力を必要とする場合にのみこれをオンにします。

ログの対象とするファイルを指定するときには、完全にログを必要とするファイルのみを指定するようにし

てください。詳細については、第 8 章の「ログ、バックアップおよび復元」を参照してください。

デフォルトで、トランザクションログはオンになっています。トランザクションログをオフにすると、パ

フォーマンスは若干向上しますが、複数ファイルの一貫性とトランザクションアトミシティは保証されませ

ん。トランザクションログをオフにする前に、アプリケーションがこの機能を使用しないで実行できるかど

うかをベンダーに確認してください。

注意トランザクションログが無効な場合、複数ファイルのデータベースの整合性は保証されません。

デフォルトで、トランザクション一貫性保守はオフになっています。アプリケーションでシステムクラッ

シュが起きてもトランザクション処理が完了することを必要とする場合は、この機能を有効にします。トラ

ンザクション一貫性保守を使用すると、パフォーマンスにも高いペナルティが課されますが、引き換えに

完了したトランザクションの高の安全性を引き出します。

3 いずれかのロギング機能をオンにしている場合、エンジンがディスクに書き込む前にどれだけのデータを保

存するかを指定することができます。変更データは繰り返し作成されるので、この機能は重要です。メモリ

に構築するログデータの許容量が多いほど、ディスク書き込みの頻度は減ります。

［ログバッファーサイズ］設定は、エンジンがデータベース操作をログファイルに書き出す前に、メモリに

格納しておくバイト数を指定します（サーバーのプロパティツリーで［パフォーマンスチューニング］を


システム異常の場合、ログバッファー内のデータは失われます。

4 トランザクション一貫性保守をオンにしている場合、ディスク上のログセグメントの大サイズを指定する

ことができます。小さいログセグメントは作成と閉じることを繰り返すので、大きなログセグメントサイ

ズを指定すると、若干パフォーマンスを向上させることができます。

［トランザクションログサイズ］設定は、ログセグメントを閉じて新しいログセグメントを開くまでにロ

グセグメントに格納できる大バイト数を指定します（サーバーのプロパティツリーで［パフォーマンス

チューニング］をクリックします）。

90


5 データベースの使用率が高い場合には、データファイルが存在するのとは物理的に異なるボリュームにログ

が保持されるようシステムを構成する必要があります。一般的に高負荷の下では、単一ドライブで I/O 帯域

幅を競う代わりに、ログファイルへの書き込みとデータファイルへの書き込みを別々のドライブに分ける方

がパフォーマンスがよくなります。全体的なディスク I/O は減少しませんが、ロードはディスクコントロー

ラー間で効率よく分散されます。

6 アプリケーションの使用方法がデータベース読み取り処理に重点を置いている場合、［インデックスバラン

スの実行］を調整することにより、パフォーマンスを向上させることができます（サーバーのプロパティツリーで［パフォーマンスチューニング］をクリックします）。インデックスバランスは通常のインデックス

ページのノード数を増やし、読み込みオペレーションを速くします。ただし、 Insert、 Update、および Deleteオペレーションでは、エンジンは隣接ページにまたがってインデックスノードのバランスをとるため、ディ

スク I/O 時間が余計に必要になることがあります。

7 MicroKernel および ODBC レベルの両方でトレースを必ずオフにしてください。トレースは、多くのディス

ク I/O を引き起こすため、パフォーマンスを著しく低下させます。

ODBC のトレースがオフであることを確認するには、Pervasive PSQL Control Center から ODBC アドミニスト

レーターを起動します。 ODBC アドミニストレーターで［トレース］タブをクリックします。トレースがオ

フの場合、［トレースの開始］と表示されたボタンがあるので、［キャンセル］をクリックします。トレース

がオンの場合は、［トレースの停止］ボタンをクリックし、［OK］をクリックします。

MicroKernel のトレースがオフであることを確認するには、設定プロパティの［トレースオペレーションの

実行］がオフに設定されている（チェックされていない）かを調べます（サーバーのプロパティツリーで

［デバッグ］をクリックします）。

十分なリソース割り当てを確保する

データベースサーバープラットフォームに十分なメモリおよび CPU パワーがある場合は、データベースエンジ

ンが複数クライアントおよび複数データファイルをも効果的にサービスできるよう、ハードウェアリソースを

大限利用できるようにしてください。

複数クライアントおよび複数ファイルを扱えるように設定するには

1 ［I/O スレッド数］設定により、ファイル操作の処理に利用できるスレッド数を指定することができます（サー

バーのプロパティツリーで［パフォーマンスチューニング］をクリックします）。

ガイドラインとして、この設定の値は、アプリケーションが平均的に開くファイル数のおよそ 1/8 にします。

たとえば、アプリケーションがたいてい 40 ファイルを開く場合、 I/O スレッドに 5 を設定します。

Monitor を使用して、メニューから［MicroKernel ｜リソースの使用状況］を選択します。ウィンドウが開き、

ファイル数に開いているファイル数の現在値とピーク値が表示されています。何度か現在値を記録して平均

表示度数を出すことができます。その平均値に基づいて、 I/O スレッド数に適切な設定をしてください。

大きいシステムキャッシュ

Windows オペレーティングシステムによっては " 大きいシステムキャッシュ " 設定を提供しています。これを使

用すれば、システムが空きメモリを利用して近アクセスしたデータをキャッスすることができます。一部の

Windows サーバーではデフォルトでこの設定がオンになっています。これは、単純なファイル共有には都合がよ

く、積極的にシステムキャッシュを増加させます。

ファイルキャッシュ用のメモリを積極的に使用すると、 Pervasive PSQL をスワップアウトすることがあります。

これによってデータベースに伴う多くのパフォーマンス問題が発生する可能性があります。 " 大きなシステム

キャッシュ " をオンにし、 Pervasive PSQL の設定である［システムキャッシュ］の設定もオン（明示的、または

［MicroKernel の大メモリ使用量］をゼロに設定）にすると、パフォーマンスが低下する可能性があります。デー

タベースのパフォーマンスを向上させるために考えられる解決策は、この " 大きなシステムキャッシュ " をオフ

にすることです。

91


この設定をオフにするには、（コントロールパネルまたはマイコンピューターのプロパティから）システムプロ

パティにアクセスします。［詳細設定］タブをクリックし、［パフォーマンス］セクションの［設定］ボタンをク

リックします。［パフォーマンスオプション］ダイアログで［詳細設定］タブをクリックします。

［メモリの使用量］セクションで、［システムキャッシュ］オプションが選択されている場合は、大きなシステム

キャッシュがオンになっています。これをオフにするには、［メモリの使用量］のもう 1 つのオプションである "プログラム " を選択します。［OK］をクリックし、開いていた一連のダイアログを閉じ、オペレーティングシス

テムを再起動します。このオペレーティングシステムの設定を反映させるには再起動する必要があります。

Xtreme I/O ドライバーについては、「システム要件」も参照してください。

92

ハイパーバイザー製品でのパフォーマンス

ハイパーバイザー製品でのパフォーマンス

Pervasive PSQL Vx Server は、ハイパーバイザー製品や仮想マシン環境用のデータベース製品です。Pervasive PSQLVx Server で高のパフォーマンスを実現するには、以下の事項を順守してください。

ハイパーバイザーベンダーからのパフォーマンス良実施例に従うこと。

Pervasive PSQL Vx Server をホストする仮想マシンに十分なメモリ（RAM）が確保されていること。

ハイパーバイザーホストには十分な数の仮想 CPU があり、同じマシン上の全仮想マシンの中で仮想 CPU の競合を小化します。これにより、Pervasive PSQL Vx Server を実行する仮想マシンとの競合が避けられます。

共通（アフィニティ）規則を使用する場合は、必ずすべてのコアを同じソケットで実行するようにしてくだ

さい。

Pervasive PSQL Vx Server データファイルは高速な物理ストレージに存在し、物理ストレージデバイスに対

するスピンドルの競合およびコントローラーの競合を小化します。

93


Xtreme I/O ドライバー

Pervasive PSQL 32 ビットサーバー製品（Windows 版）には、 Xtreme I/O （XIO）と呼ばれるデータベースアクセ

ラレータがオプションで含まれています。 XIO の使用するための低限のシステム要件を満たしていれば、カス

タムインストールを使用してこのオプションをインストールできます。 XIO は Pervasive PSQL データファイルの

ディスクアクセスを加速させることによってデータベースのパフォーマンスを向上させます。

XIO とデータベースエンジンは共同してパフォーマンスを高めます。データファイルが開かれると、エンジン

は XIO に通知します。その時点から、XIO はそのデータファイルへのディスクアクセスを加速させます。 XIO は透過的に動作し、ユーザーやアプリケーションの介入は必要ありません。

XIO では、アクセスを加速したくないデータファイルを除外することができます。除外を指定するのは簡単で、

テキストファイルを更新してデータベースエンジンを再起動するだけです。

以下のトピックでは、 XIO の追加情報を提供します。

「留意点」

「システム要件」

「XIO メモリキャッシュ」

「よく寄せられる質問」

「各種ユーティリティ」

「除外ファイル」

「Pvsw.log のメッセージ」

「イベントログメッセージ」

「XIO のトラブルシューティング」

Pervasive の Web サイトの Pervasive PSQL 技術白書で XIO の技術白書も参照してください。この白書では、技術

的な説明をこのセクションより詳細に行っています。

留意点

一般的に、 XIO は、サイズの大きなデータセットを使用するほとんどのアプリケーションのパフォーマンスを向

上させます。 XIO の使用上の留意点を次の表に示します。

表 21 XIO 使用上の留意点

条件説明

アプリケーションはデータに対してランダムアクセ

スを使用する（データアクセスの傾向はシーケン

シャルではない）

このようなパターンは、データベース管理システムを使用するアプ

リケーションの特徴です。

データセットは Windows システムキャッシュに完

全に収まらないほど大きい

Windows システムキャッシュのサイズと比べてデータセットサイ

ズが大きければ大きいほど、ディスクの読み取りと書き込みはより

頻繁に行われます。 XIO は、このようなときに読み取りと書き込み

をキャッシュすることができます。

データが Windows システムキャッシュに完全に収まっている場

合、 XIO は読み取りや書き込み要求を処理しません。

アプリケーションは頻繁にディスクアクセス操作

（読み取りおよび書き込み）を実行する

ディスクアクセスは、多くの場合アプリケーションのも速度の

遅い局面です。

既にサードパーティ製のディスク入出力を加速する

プログラムを使用している

ディスク I/O を加速するプログラムを複数使用することは、お勧め

できません。このようなプログラムは互いに干渉し、予測不能な結

果を生みます。

この理由により、XIO のみをディスク I/O プログラムとして実行し

てください。

94


システム要件

XIO は、以下の要件を満たすプラットフォームにのみインストールすることができます。

Windows サーバークラス 32 ビットオペレーティングシステム（XIO は 64 ビットプラットフォームではサ

ポートされません）。

Windows Server 2008 RTM （6.0.6001）または Service Pack 2 （SP2, 6.0.6002）、またはそれ以上

Windows Server 2003 （新の Service Pack を適用）

CPU は Pentium III 以上である必要があります。

低 4 GB 利用可能なシステム RAM。 XIO は実行時のメモリ要件もチェックするので注意してください。実

行時でメモリが 4 GB に満たない場合、 XIO は実行しません。

Pervasive PSQL データファイルは、 NTFS ファイルシステムに存在する必要があります。 FAT32 ファイルシステムのデータファイルはサポートされません。ファイルシステムの詳細についてはオペレーティングシステムのマニュアルを参照してください。

XIO をインストールしたら、システムの設定を以下のようにする必要があります。

オペレーティングシステムのラージシステムキャッシュはオフにする必要があります。つまり、 Windowsレジストリのラージシステムキャッシュ設定にゼロを設定してください。 XIO がインストールされている

場合は、 Pervasive PSQL インストールプログラムがラージシステムキャッシュをオフに設定します。

Pervasive PSQL の L2 キャッシュはオフにする必要があります。つまり、［MicroKernel の大メモリ使用量］

にゼロを設定してください。「MicroKernel の大メモリ使用量」を参照してください。 XIO がインストール

されている場合は、 Pervasive PSQL インストールプログラムが L2 キャッシュをオフに設定します。

XIO メモリキャッシュ

XIO はブロックレベルのキャッシングを使用しますが、これはデータベースエンジンが速度向上を必要とする

特定のファイルに対してのみです。 XIO のメモリキャッシュは、 Pervasive PSQL データファイル専用です。たと

えば、 XIO を非 Pervasive ファイルの汎用ディスクアクセラレータとして使用することはできません。

XIO は、高度な追跡およびキャッシュアルゴリズムを使用してキャッシュを管理します。このアルゴリズムにつ

いては、このセクションで説明する範囲を超えていますので、解説しません。ただし、 XIO のメモリの使用方法

を知ることにより、このドライバーがどのように機能するかをよりよく理解することができます。

メモリの使用

XIO は拡張メモリ、標準メモリ、またはその両方を使用します。

拡張メモリ

XIO は、拡張メモリが使用可能な場合、まず拡張メモリをキャッシュに使用します。拡張メモリは、物理アドレ

ス拡張（PAE）メモリとも呼ばれます。拡張メモリは、 4 GB を超えた RAM です。

XIO は、大 MaxPAEMemMB レジストリに指定された値まで、オペレーティングシステムが許す限り大きな拡

張メモリを予約します。「レジストリ設定」を参照してください。 XIO は拡張メモリをシステムがシャットダウ

ンするまで保持します。つまり、キャッシュ全体が拡張メモリに保持されれば、キャッシュサイズは変化せず、

縮小または拡張します。

標準メモリ

拡張メモリが存在しない場合、XIO は標準メモリからキャッシュを取得します。標準メモリは、4 GB までの RAMです。標準メモリでは、 XIO はデータベースエンジンのメモリ要求とシステム全体のメモリ要求のバランスをと

ります。 XIO のキャッシュは、ほかのシステムリソースがメモリを取得および開放するように、縮小および拡張

します。

95


MaxCacheSizeMB のレジストリ値が -1 （デフォルト）の場合、 XIO は現在のシステムの状態に基づいてキャッ

シュサイズを増加または減少させて調整を行います。この場合の大キャッシュサイズは、物理メモリのおよそ

80% です。

MaxCacheSizeMB が数メガバイトに設定されている場合、 XIO はオペレーティングシステムが許可するその値ま

でしか拡張しません。

MaxCacheSizeMB にインストールされているメモリを超えた値を設定すると、Windows イベントログにエラーが

書き出され、ドライバーは読み込まれません。「イベントログメッセージ」を参照してください。

MaxCacheSizeMB は、標準メモリと PAE メモリ（存在する場合）との組み合わせに基づいたキャッシュの大サ

イズです。キャッシュは、メモリがどこにあろうと MaxCacheSizeMB の値を超えて大きくなることはできません。

「レジストリ設定」を参照してください。

メモリの組み合わせ

拡張メモリが存在してもオペレーティングシステムが MaxPAEMemMB に指定された値のメモリを割り当てられ

ない場合、 XIO は拡張メモリと標準メモリを組み合わせて使用します。 XIO は、 4 GB に満たない標準メモリを使

用する前に、オペレーティングシステムから利用可能な 4 GB を超える拡張メモリを使用して MaxCacheSizeMB設定を実現します。標準メモリに存在する XIO キャッシュは必要に応じて縮小および拡大します。

レジストリ設定

Windows のレジストリには XIO の設定パラメーターが含まれています。パラメーターの大多数は予約されていて

変更できません。

ただし、 MaxCacheSizeMB および MaxPAEMemMB レジストリエントリは設定可能です。

注意上の表に挙げられている以外の XIO レジストリエントリは変更しないでください。予測不能な結果を

招きます。

レジストリの編集は高度な操作です。誤って編集すると、オペレーティングシステムが起動しなくなる恐れ

があります。必要であれば、経験豊富な技術者に依頼して編集を行ってもらってください。

レジストリキー 1 用途有効な値説明

MaxCacheSizeMB XIO が使用する物理メモリの

大量をメガバイト（MB）で

指定します。

-1 または使用する値

を MB 単位で指定し

ます。

デフォルト： -1

この設定は、 PAE メモリが存在する場合

には、標準メモリと PAE メモリを組み合

わせた大値です。

-1 を指定すると、 XIO は必要に応じ標準

メモリ内でキャッシュを動的に増大また

は縮小します。

Pervasive では MaxCacheSizeMB に -1 を設

定して XIO がキャッシュを動的に調整で

きるようにすることを推奨します。

MaxPAEMemMB XIO がキャッシュに使用する

物理アドレス拡張（PAE）メモ

リの大値をメガバイト単位

で指定します。

0 または使用する値

を MB 単位で指定し

ます。

デフォルト： 8192

PAE メモリは、4 GB を超えた RAM です。

1HKEY_LOCAL_MACHINE\SOFTWARE\PERVASIVE SOFTWARE\XIO

96


よく寄せられる質問

このセクションでは、 XIO に関する一般的な質問について説明します。

質問回答

XIO をクラスター環境で使用

できますか？

いいえ。 Pervasive PSQL をクラスター環境で使用する場合は、 Xtreme I/O をインストー

ルしてはいけません。マシンがフェールオーバーによってオンラインになり、共有記憶

域をアクセスできないままにしておくと、ノードに XIO がインストールされている場

合、そのノードがハングすることがあります。

そのため、 Pervasive PSQL インストールの［セットアップタイプ］ダイアログでは、［カ

スタム］を選択してください。使用可能なインストールオプションとして［PervasiveXtreme I/O］が表示される場合は、そのオプションをクリックして、［この機能は使用で

きなくなります。］を選択します。

Pervasive PSQL インストールの残りを完了します。これ以上のカスタマイズは必要あり

ません。

XIO を仮想マシンで使用でき

ますか？

いいえ。 Pervasive PSQL を仮想マシンで使用する場合は、 Xtreme I/O をインストールし

てはいけません。

Pervasive PSQL Vx Server には

XIO が含まれていますか？

いいえ。 Pervasive PSQL Vx Server は物理マシンにインストールすることはできますが、

これは主に仮想環境向けに用いられるものです。 XIO は仮想環境で使用できないので、

Pervasive PSQL Vx Server には含まれていません。

XIO がインストールされてい

るかどうかは、どうしたらわか

りますか？

pvsw.log ファイルの XIO メッセージをチェックしてください。「Pvsw.log のメッセージ」


あるいは、コマンドプロンプトで xiomgr というコマンドを実行します。オペレーティ

ングシステムが xiomgr のヘルプ情報を表示すれば、 XIO ドライバーがインストールさ

れています。

XIO が有効かどうかは、どうし

たらわかりますか？

xiomgr -query のように、 xiomgr ユーティリティに "query" オプションを付けて実行しま

す。

このユーティリティは XIO の現在の状態（有効または無効）および実行中かどうかを表

示します。「Xiomgr」を参照してください。

さらに、 pvsw.log ファイルの XIO メッセージをチェックすることができます。「Pvsw.logのメッセージ」を参照してください。

XIO が実行中かどうかは、どう

したらわかりますか？

XIO キャッシュがメモリをど

れだけ使用しているかは、どう

したらわかりますか？

Xiostats ユーティリティを実行します。

" キャッシュサイズ " 統計情報に XIO キャッシュのサイズがメガバイト（MB）単位で

示されます。「Xiostats 統計情報」も参照してください。

XIO キャッシュがどれくらい

有効かは、どうしたらわかりま

すか？

一般的に、 " 読み取りヒット率 " 統計情報のパーセンテージをチェックします。パーセ

ンテージが大きいほど XIO はキャッシュを多く使用しており、 XIO はより効果的にパ

フォーマンスを向上させています。

より範囲を狭めるには、" キャッシュ可能な IO %" 統計情報を調べることもできます。こ

れは、 Pervasive PSQL データのみに関連するすべての I/O リクエストのパーセンテージ

を示します。高いパーセンテージは、ディスクアクセスリクエストの大多数が PervasivePSQL データに関連していることを示します。

「Xiostats 統計情報」も参照してください。

97


各種ユーティリティ

XIO は、ドライバーに関する 2 種類のユーティリティ xiomgr と xiostats を提供します。

Xiomgr

適用

説明

Xiomgr は XIO ドライバーを管理します。

概要

xiomgr -<query | start | stop | enable | disable | help>

オプション

XIO キャッシュにどのファイ

ルがキャッシュされているか

は、どうしたらわかりますか？

Xiostats ユーティリティを実行します。［表示｜開いているファイル］をクリックします。

「機能の全容」も参照してください。

" 開いているキャッシュファ

イル " 統計情報の値は、自分で

開いたと思っているファイル

数より多かったり少なかった

りするのはなぜですか？

データベースエンジンはファイルを開いて閉じることがあります。このような場合は "開いているキャッシュファイル " にはカウントされません。 4 つにセグメント化された

Pervasive PSQL ファイルを開くと、 1 つだけではなく 4 つのファイルが開いていると表

示されます。データベースエンジンはセグメントごとに Open オペレーションを実行し

ます。システムファイルおよびデータ辞書ファイルも開かれ、これらも合計に含まれま

す。

「Xiostats 統計情報」も参照してください。

Windows （32 ビット） Linux クライアントサーバーデータベースエンジン

Yes No No Yes

-query XIO ドライバーの現在の状態を報告します。たとえば、実行中であるとか、有効であるな

どです。

-start XIO ドライバーを起動します。

xiomgr -stop コマンドの後で実行する場合は、まず、データベースエンジンが開始している

ことを確認してください。「XIO のトラブルシューティング」も参照してください。

-stop XIO ドライバーを停止します。

まず、データベースエンジンサービスを停止する必要があります。「XIO のトラブルシュー

ティング」も参照してください。

-enable オペレーティングシステムが起動したときに XIO ドライバーを起動します。

enable オプションは、次にオペレーティングシステムを起動したときに有効になります。

-disable オペレーティングシステムが起動したときに XIO ドライバーが起動しないようにします。

disable オプションは、次にオペレーティングシステムを起動したときに有効になります。

-help ユーティリティの使用法に関する情報を表示します。

質問回答

98


Xiostats

このユーティリティは XIO キャッシュに関する統計情報を表示します。

Xiostats は、本来、統計情報とグラフ化データの調査を十分に理解しているユーザー向けの高度なユーティリティ

です。そうであっても、このユーティリティではいくつかの基本的な統計情報を提供します。 Xiostats に関する

一般的なヒントについては、「よく寄せられる質問」を参照してください。

統計情報

Xiostats の主な目的は、XIO および XIO キャッシュに関する統計情報を提供することです。この情報は、このユー

ティリティのメインウィンドウにマトリックスとして表示されます。次の表では統計情報について説明します。

表 22 Xiostats 統計情報

統計情報説明

時間システム日付および時刻。

経過秒数 Xiostats が起動されてから経過した秒数。つまり、どれだけの時間実行されたかを秒数

で示します。

物理メモリ MB そのマシンの拡張メモリを含む物理メモリの合計の概算。

キャッシュサイズ XIO キャッシュのサイズ（メガバイト単位）。この値は、キャッシュがどのメモリを使

用するかによって異なります。「メモリの使用」を参照してください。

開いているキャッシュファイル開いていて、実際にキャッシュされている（ファイルが読み取られているかまたは書

き込まれている） Pervasive PSQL ファイルの数。

開いているキャッシュファイルの合計数は、自分で開いていると思っている数と異な

ることがあります。 1 つのファイルを開くことによって、複数の物理ファイルが開か

れることがあります。たとえば、 4 つにセグメント化された Pervasive PSQL ファイル

では、 1 つだけではなく 4 つのファイルが開いていると表示されます。データベース

エンジンはセグメントごとに Open オペレーションを実行します。

圧縮率キャッシュによって実行されるデータ圧縮の量。

たとえば、圧縮率が 8 （8 が 1 になることを意味します）であると仮定します。キャッ

シュのサイズが 1 GB で圧縮率が 8 の場合、キャッシュには 8 GB のデータが格納され

ます。

この比率は、データの特性によって異なります。データによっては圧縮可能ですが、

圧縮できないものもあります。

読み取りヒット率 " ヒット " は、XIO が物理ディスクではなくキャッシュから読み取るデータを対象とし

ます。

一般的に、このパーセンテージが高いほど XIO が効率的に実行されています。

メモ：データが全部 Windows システムキャッシュに収まっている場合、XIO は読み取

り要求を処理しません。

ダーティバッファー % キャッシュに既に書き込まれて、まだディスクには書き込まれていないキャッシュ内

のデータ量。

キャッシュ可能な IO % Pervasive PSQL データのみに関連するすべての I/O リクエストのパーセンテージ（XIOは、すべてのディスクアクセス要求を認識しますが、 Pervasive PSQL データに関連す

るもののみに動作します）。

サーバーが Pervasive PSQL 専用である場合、キャッシュ可能な IO % は高いパーセン

テージを示します。これは、ディスクアクセス要求の大多数が Pervasive PSQL データ

に関連するためです。

99


機能の全容

次の表は、統計情報のレポートをサポートする本ユーティリティの機能の簡単な説明です。

除外ファイル

XIO には xioexclude.lst というテキストファイルが含まれており、これを使用してアクセスを加速したくないデー

タファイルを指定することができます。一般的には、除外ファイルを追加する必要はありません。除外ファイル

を選択する場合には、以下の手順に従います。

1 このファイルをテキストエディターで開きます。

デフォルトで、このファイルは %allusersprofile% の下の Pervasive Software\PSQL にあります。デフォルトで、

オペレーティングシステムは %allusersprofile% の下のいくつかのフォルダーを隠しフォルダーにするため、

隠しファイルを検索するようにしてください。

キャッシュ読み取りバイト数キャッシュから読み込まれたバイト数。

キャッシュ書き込みバイト数キャッシュに書き込まれたバイト数。

機能説明

オプションオプションダイアログを使用すると、 Xiostats がキャッシュをポーリングする間隔など、ユー

ティリティの機能の一定の部分をカスタマイズすることができます。［オプション］コマンドは、

［ファイル］メニューから使用できます。

パラメーターパラメーター一覧は、 Xiostats のさまざまなレジストリ設定を示します。これらの設定の 2 つだ

けがカスタマイズできます。「レジストリ設定」を参照してください。

「レジストリ設定」に挙げられている 2 つ以外の XIO レジストリエントリは変更しないでくだ

さい。予測不能な結果を招きます。

［パラメーター］コマンドは、［表示］メニューから使用できます。

開いているファイル数開いているファイルの一覧は、現在どのファイルが開かれ、キャッシュされているかを表示す

るのに便利です。

［開いているファイル］コマンドは、［表示］メニューから使用できます。

パフォーマンス［パフォーマンス］コマンドを使用すると、 PerfMon ユーティリティのカウンターに簡単にアク

セスできます。 PerfMon ユーティリティは、 Windows オペレーティングシステムの一部として

含まれています。このカウンターの使用については、そのマニュアルを参照してください。

グラフ［グラフ］コマンドを使用すると、統計情報をグラフ化してさまざまな方法で表示することがで

きます。データは、変数、微分、積分のグラフとして表示することができます。

Xiostats ログに保存された統計情報データもグラフ化することができます。 Xiostats のログは、

スプレッドシートプログラムで表示可能なカンマ区切り（CSV）形式で保存されたテキスト

ファイルです。

［ファイル］メニューのコマンドを使用して、ログファイル（CSV ファイル）を開いたり閉じ

たりします。

ログファイルログファイルコマンドを使用すると、統計情報のログへの記録を開始および停止したり、ログ

のスケジュールを設定することができます。

Xiostats のログは、スプレッドシートプログラムで表示可能なカンマ区切り（CSV）形式で保存

されたテキストファイルです。

［ファイル］メニューのコマンドを使用して、ログファイル（CSV ファイル）を開いたり閉じ

たりします。

メモ：ログ間隔が非常に短い場合、ログファイルのサイズは短期間で非常に大きくなります。

表 22 Xiostats 統計情報

統計情報説明

100


2 xioexclude.lst の指示に従ってファイル名を追加します。

3 オペレーティングシステムを再起動します。

Pvsw.log のメッセージ

データベースエンジンのインストール時に、XIO がインストールされ、データベースエンジンが XIO キャッシュ

にファイルをキャッシュすることができれば pvsw.log ファイルにメッセージが書き込まれます。このログファイ

ルには次のようなメッセージが書き込まれます。

MicroKernel は XIO キャッシュドライバーへのアクティブなリンケージを確保しました。

メモ XIO がインストールされているが、pvsw.log にこのメッセージが含まれていない場合は、データベース

エンジンが XIO と通信することができず、ファイルはキャッシュされません。これを修正するための処置

は、トランザクショナルサービスをいったん停止して再開することです。『Pervasive PSQL User's Guide』の

「Windows サーバー上でのサーバーエンジンの起動と停止」を参照してください。サービスを再開したこと

によって、データベースエンジンが XIO と通信できるようになると、このメッセージが pvsw.log に書き込

まれます。

101


イベントログメッセージ

XIO は、次の表に示すようにエラーメッセージを Windows イベントログに書き込みます。

表 23 Xiostats イベントログメッセージ

メッセージ対処方法

XIO started. 不要。

XIO did not shut down properly. このエラーが連続して発生する場合は、 Pervasive のテクニカルサポートにお問い合わせください。

XIO failed to load because a memory allocation of %2 bytesfor %3 failed.

インストールされているシステムメモリ量と、「MaxCacheSizeMB」および「MaxPAEMemMB」の設定を確認してください。

XIO detected insufficient RAM (%2MB).It requires %3MBto operate.

システム RAM を低限必要な 2 ギガバイト（GB）に増やしてく

ださい。

XIO encountered an unrecoverable system error. %2. Pervasive のテクニカルサポートにお問い合わせください。

XIO detected the parameter %2 has an invalid value %3.

The legal range is %4 to %5.

The current setting has been coerced to the default value%6.

パラメーターを正しい範囲内の値に設定してください。

NT OS Version %2.%3 is not a Server Build.

XIO detected the parameter %2 has an invalid value %3.

The legal range is %4 to %5.

The current setting has been coerced to the minimum value%6.

パラメーターを正しい範囲内の値に設定してください。

XIO detected that the installed memory size changed from%2MB to %3MB.

インストールされているメモリを調べ、低量の 2GB が使用可能

であることを確認してください。

The maximum cache size parameter (%4MB) may needadjustment.

「MaxCacheSizeMB」の設定を調べ、システムメモリとデータセッ

トの量に基づいて必要な量に調整してください。

102


XIO のトラブルシューティング

このセクションでは、 XIO の使用中に問題が発生した場合の対処方法について提案します。

表 24 XIO トラブルシューティング

状況説明

XIO が有効であるのに、システム起動

時にロードされない。

1. オペレーティングシステムをセーフモード（一般的にシステム起動時に F8キーを押す）で起動します。

2. XIO ドライバーが読み込まれないように、コマンドプロンプトで xiomgr -disable というコマンドを実行します。

デフォルトで、 xiomgr は、 Program Files ディレクトリの下の Pervasive ツリーの

PSQL\bin\ ディレクトリにあります。『Getting Started with Pervasive PSQL』の

「Pervasive PSQL ファイルはどこにインストールされますか？」も参照してくだ

さい。

3. オペレーティングシステムを再起動すると、 XIO を開始せずにロードされま

す。

XIO キャッシュがデータベースエンジ

ンの読み書きに応答しない。

この状況は、データベースエンジンおよび XIO キャッシュ間の通信がリンクさ

れなくなった場合に起こります。以下の手順を使用して、データベースエンジ

ンと XIO キャッシュ間の通信を再確立してください。

1. Pervasive PSQL サービスを停止します。

2. Xiomgr -stop コマンドを実行します。

3. Xiomgr -start コマンドを実行します。

4. Pervasive PSQL サービスを開始します。

リンクの切断は、以下のように間違った順序で動作を行った場合に発生します。

A. Pervasive PSQL サービスを停止する。

B. Xiomgr -stop コマンドを実行する。

C. Pervasive PSQL サービスを開始する。

D. Xiomgr -start コマンドを実行する。

問題は、手順 C と D の順序が逆であることです。 Xiomgr -stop コマンドに続い

て、まず Xiomgr -start コマンドを実行し、次に Pervasive PSQL サービスを開始

する必要があります。

103


104

6
参照整合性の設定
参照整合性の構造について

参照整合性（RI）は、テーブルと関連するデータの同期を確実にするためにデータベースに作成することのでき

る、チェックおよびバランスのシステムです。

「参照整合性（RI）の概念」

「主キーの設定」

「外部キーの設定」

「Btrieve およびリレーショナル制約間の相互作用」

105


参照整合性（RI）の概念

参照整合性（RI）を使用すると、同一のフィールド値がそのテーブルまたはほかのテーブルに存在するかどうか

に基づき、データの変更または、変更や追加や削除の禁止を行うことができます。

定義

いくつかの重要な用語を明確にすることにより、 RI がよく理解できます。

規則

規則は、原因とその効果の単純なステートメントで、データベースに定義された RI システムによって実行されま

す。

例 A

たとえば、削除規則によって、主キーを持つレコードが削除されたときに、外部キーを持つレコードに何が起き

るかが次のように定義されているとします。「'Bhargava Building' を含むレコードが削除されたとき、そのレコー

ドを参照するテーブル A のすべての行は削除される。」

削除規則は、主キー値を参照する外部キーがある場合、その主キー値を含む行が削除されるのを禁止することも

できます。

例 B

更新規則は、ユーザーがレコードを更新またはレコードを追加しようとしたときに、外部キーを含むレコードに

何が起こるかを定義したもので、次のようなものです。「ユーザーがテーブル B に新しいレコードを追加しよう

としたとき、ビル名がテーブル C に存在しなければ、追加することを拒否する。」

主キー

主キーは規則が従属する 1 つまたは複数の列です。どのテーブルでも主キーは 1 つだけ許可されており、重複値

は許可されていません。更新規則では、主キーというのは、レコードの更新または追加が許可されるかどうかを

判断するために、更新または追加した列と比較される列のことです。

「例 A」では、 "Bhargava Building" を含む列が主キーです。

「例 B」では、テーブル C のビル名を含む列が主キーです。

外部キー

外部キーは、処理方法を決定するために主キーと比較される 1 つまたは複数の列です。

前述の「例 A」では、テーブル A の "Bhargava Building" を含む列が主キーです。

前述の「例 B」では、テーブル B のビル名を含む列が外部キーです。

カスケード

カスケード規則は、データベースがある操作が起こることを許可し、ほかのテーブルまたは行を初の操作と同

期をとるように変更することによって RI を確実にする規則です。たとえば、カスケード削除規則が定義されてい

ると、主キーテーブルでのレコードの削除により、データベースは削除された行の主キーと同じ値の外部キーを

持つデータベース中のすべての行を検索して削除します。

制限

制限規則は、データベースに既に存在する値に基づく操作を許可するかどうかをデータベースが決定するのに使

用する規則です。たとえば、更新制限規則が定義されている場合、外部キーを含む行をテーブルに追加しようと

106

参照整合性（RI）の概念

すると、データベースエンジンは外部キーフィールドの値を主キーの値と比較します。同じ値の主キーを持つ行

が存在しない場合、その行を外部キーテーブルに追加することは許可されません。

キーおよび規則について

このセクションでは、主キーおよび外部キーの概念についてより詳細に説明します。

上記の例では、テーブル A の student_ID （A.student_ID）は IDENTITY データ型で、 2 つの行が同じ値を

持つことを許可していません。学生はそれぞれユニークな ID 番号を持ちます。 student_ID をテーブル A の主

キーとして定義します。

それから、テーブル B の stud_ID （B.stud_ID）を A.student_ID を参照する外部キーとして定義します。

stud_ID のデータ型は、 IDENTITY と比較できる INTEGER などのデータ型である必要があります。主キーと外

部キーのデータ型には互換性が必要です。参照整合性を確実にするために、必要なだけの外部キーをいくつでも

設定することができます。複数の外部キーは同一の主キーを参照することができます。

主キーを持つテーブルは親テーブルと呼ばれ、外部キーを持つテーブルは子テーブルと呼ばれます。いったんキー

が定義されると、表 26 に示すように選択できる動作の範囲が限られます。必要なだけ規則を定義することができ

ますが、タイプごとには 1 つしか定義できません。たとえば、削除制限規則を定義した場合、同じキーにカスケー

ド削除規則を定義することはできません。これは、 2 つの動作が相互に排他的であるためです。

更新制限

前述の例で説明すると、更新制限規則を設定することにより、新規または更新された行の B.stud_ID の値は必

ず A.student_ID にも存在していることが保証されます。テーブル B に行を追加できるようにするには、その

前に、テーブル A に行があることが必要です。言い方を変えると、子行を作成する前に少なくとも 1 つの親行を

作成する必要があります。

削除制限

例では、削除制限規則を設定することにより、テーブル A の行は、テーブル B のいずれかの行がその行を参照し

ている場合は削除できないことが保証されます。 Name の値が "John" である行は、 John の student_ID がテーブル

B で参照されているため、削除できません。

John の student_ID を参照するテーブル B の行がすべて削除されたら、テーブル A から John の行を削除すること

ができます。

表 25 主キーおよび外部キー

テーブル A テーブル B

student_ID Name stud_ID Class

20543 John 20543 ENG -101

20577 Mary 20543 AST-202

表 26 RI 規則の選択

行いたい動作 ... 定義する規則

B.stud_ID の値が A.student_ID のいずれかの値に一致しなければ、テーブル B に行が追

加されたり更新されたりすることを許可しない。

更新制限

B.stud_ID の値がその行と一致しなければ、テーブル A の行を削除することを許可し

ない。

削除制限

テーブル A から行が削除された場合、その削除された A.student_ID の値に一致する

B.stud_ID のすべての行をテーブル B から削除する。

削除カスケード

107


削除カスケード

例では、削除カスケード規則を設定することにより、 Name 値が "John" の行が削除された場合、テーブル B の両

方の行が削除されることを保証します。

Pervasive PSQL では、自己参照するテーブルに対し、循環するカスケード削除を使用できます。このため、削除

カスケードは慎重に使用してください。親テーブル、子テーブル、または両テーブルのすべてのレコードを不用

意に削除しないようにしてください。

このようなカスケード削除がどのようにして発生するかをわかりやすくするために例を示します。 2 つの列を持

つテーブル d3 を作成するとします。

CREATE TABLE d3 (c1 INT PRIMARY KEY, c2 INT)INSERT INTO d3 VALUES (2.2)INSERT INTO d3 VALUES (3.2)INSERT INTO d3 VALUES (1.3)INSERT INTO d3 VALUES (4,1)

次に、外部キーを追加し、カスケード削除規則を設定するようにテーブルを変更します。

ALTER TABLE d3 ADD FOREIGN KEY (c2) REFERENCES d3 ON DELETE CASCASE

次のステートメントにより、テーブル内のすべての行が削除されます。

DELETE FROM d3 WHERE c1 = 2

c1 = 2 の行だけでなく、すべての行が削除されるのはなぜでしょう ?

削除カスケードは、削除された主キーと同じ値の外部キーを持つすべての行を削除します。 2 番目の行は初の

行と外部キー関係があります。同様に、 3 番目の行は 2 番目の行と、 4 番目の行は 3 番目の行と外部キー関係があ

ります。外部キー関係があることで、すべての行に渡ってカスケード削除規則が適用されるため、 1 行目により

2 行目が、 2 行目により 3 行目が、そして 3 行目により 4 行目が削除されることになります。

Pervasive PSQL は、相互に参照するテーブルでの循環削除カスケードを許可していません。たとえば、テーブル

d1 と d2 があるとして、次のようなシナリオを考えます。

CREATE TABLE d1 (c1 INT PRIMARY KEY, c2 INT)CREATE TABLE d2 (e1 INT PRIMARY KEY, e2 INT)

次の変更ステートメントは許可されます。

ALTER TABLE d1 ADD FOREIGN KEY (c2) REFERENCES d2 ON DELETE CASCADE

次の変更ステートメントは許可されません。テーブル d1 と d2 には既に削除カスケードの関係があるからです。

ALTER TABLE d2 ADD FOREIGN KEY (e2) REFERENCES d1 ON DELETE CASCADE

108

主キーの設定

主キーの設定

主キーは、 SQL ステートメントまたは Pervasive PSQL Control Center を使用して作成することができます。

『Pervasive PSQL User's Guide』の「列のタスク」を参照してください。

テーブル作成中に主キーを作成する

CREATE TABLE ステートメントで PRIMARY KEY キーワードを使用して、テーブル作成時に主キーを作成する

ことができます。主キーは 1 つまたは複数の列で構成されます。次の例では id が作成され、主キーに指定され

ることを示しています。

CREATE TABLE mytable (id INTEGER,

myname CHAR(20),

PRIMARY KEY(id))

次の例は複数の列を使ってユニークな値を持つ主キーを作成する方法を示しています。

CREATE TABLE mytable (id INTEGER,

myname CHAR(20),

PRIMARY KEY(id, myname))

主キーに指定した単一または複数の列に UNIQUE 属性を指定したかどうかに関わらず、データベースエンジン

はその列に重複値とヌル値を許可しないインデックスを自動的に作成します。どのような場合もキー列にヌル値

は許可されません。すべての主キー値はユニークです。

ほかの例については、『SQL Engine Reference』の「CREATE TABLE」を参照してください。

既存のテーブルに主キーを追加する

PCC を使用して、または ADD PRIMARY KEY を使った ALTER TABLE ステートメントによって、既存のテーブ

ルに主キーを追加することができます。『Pervasive PSQL User's Guide』の「列に主キーを設定または削除するに

は」および「SQL Editor」を参照してください。

主キーは重複およびヌル値を許可しない列にしか作成することができません。

必要な場合には、列属性を変更し、その列を主キーに設定することを同時に行うことができます。 SQL を使った

例を示します。

ALTER TABLE mytable MODIFY id INTEGER UNIQUE NOT NULL PRIMARY KEY

複数の列から成る主キーを追加したい場合は、キーを分けて追加する必要があります。

ALTER TABLE mytable ADD PRIMARY KEY(id, myname)

ほかの例については、『SQL Engine Reference』の「ALTER TABLE」を参照してください。

109


外部キーの設定

外部キーは、SQL ステートメントまたは Pervasive PSQL Control Center を使用して作成することができます。外部

キーを作成するときに、同時に関連する規則も定義できます。同一のキーに複数の規則を定義することができま

す。関連する規則を指定しないで外部キーを作成した場合、更新と削除はどちらもデフォルトの参照整合性によっ

て制限されます。

テーブル作成中に外部キーを作成する

列の定義で REFERENCES キーワードを使用して、テーブル作成時に外部キーを作成することができます。外部

キーは 1 つまたは複数の列で構成されます。列のデータ型は、この外部キーが参照する主キーと同じでなければ

なりません。次の例では your_id が作成され、 mytable.id を参照する外部キーに指定されることを示してい

ます。

CREATE TABLE yourtable (your_id INTEGER REFERENCES mytable(id) ON DELETE CASCADE, yourname CHAR(20))

ステートメントの後に外部キーの指定を追加することもできます。キーに複数列を使用する場合、この技法を

使う必要があります。

CREATE TABLE yourtable (your_id INTEGER,

yourname CHAR(20),

FOREIGN KEY(your_id, yourname) REFERENCES

mytable(id, myname) ON DELETE CASCADE)

外部キーを作成すると、データベースエンジンは指定された列にインデックスを追加します。

ほかの例については、『SQL Engine Reference』の「CREATE TABLE」を参照してください。

既存のテーブルに外部キーを追加する

PCC を使用して、または ADD FOREIGN KEY を使った ALTER TABLE ステートメントによって、既存のテーブ

ルに外部キーを追加することができます。『Pervasive PSQL User's Guide』の「外部キーのタスク」および「SQLEditor」を参照してください。

次の例ではこの外部キーに削除規則と更新規則の 2 つの規則が定義されています。

ALTER TABLE yourtable ADD FOREIGN KEY (your_id,yourname) REFERENCES mytable(id,myname) ON DELETE CASCADE ON UPDATE RESTRICT

DELETE CASCADE は慎重に使用してください。「削除カスケード」に記載されている例を参照してください。

ほかの例については、『SQL Engine Reference』の「ALTER TABLE」を参照してください。

110

Btrieve およびリレーショナル制約間の相互作用


Pervasive PSQL は、リレーショナルインターフェイスとトランザクショナルインターフェイスの両方を介して同

一データへの同時アクセスをサポートするように設計されていますが、リレーショナル（SQL）データベース

アーキテクチャの機能によって、リレーショナルアクセスを妨げるものがあります。たとえば、参照整合性（RI）のようなリレーショナルアクセスを制限するように設計された機能は、データ整合性という点では Btrieve アク

セスも制限します。

整合性の設定、バウンドデータベース、 ODBC/SQL セキュリティ、トリガー、参照整合性、およびオーナーネー

ムなどの機能をトランザクショナル（Btrieve）アプリケーションが使用するデータベースに実装するには、あら

かじめこれらの機能について完全に理解している必要があります。ほとんどの場合、一挙両得のデータベースアクセスを得られますが、セキュリティ、参照整合性、およびトリガーはアクセスやオペレーションに制約を設け

るため、一部の Btrieve オペレーションは、それらの実装によって制限されたり妨害されたりする場合があります。

整合性の設定、バウンドデータベース、セキュリティ、トリガー、または参照整合性を使用している場合には、

データまたはファイルへの Btrieve アクセス時、そのデータに設定されているバインドおよび制約に違反すると、

Btrieve アクセスが制限されたりアクセスできなくなったりすることがあります。トリガーと RI は主として

Btrieve API を介したデータの操作能力を制限します。

セキュリティとオーナーネームは、適切なアカウント、アクセス権、およびパスワードを持たないデータへのア

クセスまたは操作能力を制限する場合があります。これらの機能について考えられるさまざまな組み合わせはた

くさんあるので、も一般的な組み合わせのみを以下に一覧表示します。

（1）データベースにバウンドデータベースが設定されているかどうかに関係なく、データベースエンジンは、

データファイルにトリガーある場合、外部キーがある場合、あるいは外部キーで参照される主キーがある場合に

は、自動的にデータファイルをバウンドとしてスタンプします。バウンドデータベースやファイルの詳細につい

ては、「バウンドデータベース」を参照してください。

表 27 リレーショナル制約と Btrieve アクセス間の相互作用

条件結果

DDF の有無

整合性の

設定

バウンドデータ

ベース

リレーショナルセキュリティの

使用

トリガー

の使用

RI の使用 Btrieveアクセス可能

SQL/ODBCアクセス可能

No - - - - - Yes No

Yes No No No No - Yes Yes

Yes No No (1) No Yes (2) - Yes (2) Yes

Yes Yes No No No No Yes Yes

Yes Yes No Yes No No Yes (3) Yes (3)

Yes Yes No (1) Yes No Yes Yes (4) Yes (3) (4)

Yes Yes No (1) Yes Yes (2) No Yes (1) Yes (3)

Yes Yes Yes No No No Yes Yes

Yes Yes Yes Yes No No Yes (3) Yes (3)

Yes Yes Yes (1) Yes No Yes Yes (2) (4) Yes (3) (4)

Yes Yes Yes (1) Yes Yes (2) No Yes (2) (3) Yes (3)

111


（2）テーブルにトリガーを追加すると、 Btrieve インターフェイスはトリガーの実行を引き起こすあらゆるオペ

レーションについて、そのファイルへのアクセスが妨げられます。トリガーは Btrieve インターフェイスを介した

データベース操作には作用しないため、このロックアウト動作によってデータの一貫性が保持されます。詳細に

ついては、「バウンドデータベースと整合性の設定」を参照してください。

（3）データベースまたはファイルがセキュリティで保護されている場合、ユーザーがそのファイルに対する権限

（リレーショナルユーザー名とパスワード、または有効な Btrieve オーナーネーム）を持っているのであれば、ア

クセスは許可されます。セキュリティで保護されたデータベース内にあるがオーナーネームが設定されていない

ファイルには、 Btrieve ユーザーはアクセスできません。 Btrieve オーナーネームが既に設定されているファイル

にリレーショナルセキュリティを初に設定するとき、 Master ユーザーがオーナーネームを使ってユーザーに

リレーショナル権限を付与する必要があります。詳細については、「Pervasive PSQL セキュリティ」を参照してく

ださい。

（4）テーブルに参照整合性制約が含まれており、そのデータベースで整合性の設定が有効になっている場合、制

約に違反する Btrieve および SQL 操作は共に行えません。このメカニズムにより、アクセス方法に関係なくデー

タの整合性が保たれます。

バウンドデータベースと整合性の設定

名前付きデータベースに［整合性の設定］属性を指定しない場合、データベースエンジンは参照整合性、トリ

ガー、セキュリティ規則のいずれも強制しません。名前付きデータベースに［整合性の設定］属性を指定すると、

データのアクセスに使用する方法とは無関係に、MicroKernel はデータベースの定義済みセキュリティ、参照整合

性（RI）およびトリガーを設定できます。 MicroKernel は以下のようにこれらの規則を設定します。

Btrieve ユーザーはリレーショナルセキュリティの制約を受けません。ファイルにオーナーネームが設定さ

れている場合、それは有効なままです。ファイルにオーナーネームがない場合、 Btrieve ユーザーはリレー

ショナルセキュリティ制約に関係なくデータにアクセスできます。 Btrieve オペレーションは RI やそれ以外

のデータベースに定義されているすべての制約に加え、以下に示すトリガー制限の影響を受けます。

ファイルに制約が存在する場合、 Btrieve アクセスは以下のように許可されます。

バウンドファイルに複数の制約が存在する場合、アクセスレベルは大限の制約または制約の組み合わせに従い

ます。たとえば、ファイルに INSERT トリガーと UPDATE トリガーが定義されている場合、 Btrieve ユーザーは

読み取り専用および削除アクセスのみが行えます。

「整合性の設定」が直接「バウンドデータベース」に関連付けられていません。データベースは整合性の設定な

しでバインドされるか、データベースはバインドされずに整合性の設定を設定されます。

バウンドデータベース

名前付きデータベースに「バインド」属性を指定した場合、そのデータベースの DDF およびデータファイルは

ほかのデータベースとは関連付けることができません。また、バウンドデータファイルを、データベース内の複

数のテーブル定義と関連付けることもできません。新しいテーブルまたは DDF をバウンドデータベースに追加

すると、データベースエンジンが自動的に新しいオブジェクトのバインドを行います。この動作により、予測で

きない動作やデータ整合性を壊すことになる矛盾を防ぎます。たとえば、同じデータベース内の 2 つの異なるテー

ブル定義に同じデータファイルを使用した場合、一方のテーブルに RI 規則を定義し、もう一方には定義しない

表 28 Btrieve アクセスの制限－整合性の設定

ファイルの制約 Btrieve を使ったアクセスで許可されるレベル

RI 制約の定義ありユーザーはデータのアクセス、および RI 制約の範囲内でのオペレーション

の実行が可能です。

INSERT トリガーの定義あり読み取り専用、更新、および削除オペレーションが許可されます。

UPDATE トリガーの定義あり読み取り専用、挿入、および削除オペレーションが許可されます。

DELETE トリガーの定義あり読み取り専用、更新、および挿入オペレーションが許可されます。

112


でおくことができます。この場合、RI 規則を持たないテーブルに行を挿入することは、もう一方のテーブルの RI規則に違反することになります。データファイルと DDF をバインドすることによりこのような矛盾を防ぎます。

DDF およびデータファイルは、個々にバインドできます。データファイルにトリガーがある場合、外部キーが

ある場合、または外部キーで参照される主キーがある場合、データベースエンジンは自動的にそのデータファイ

ルをバインドデータファイルとして特徴付けます。これらのファイルは別のデータベースと共有できず、複数の

テーブル定義に関連付けられることもできません。

データファイルがバインドされていることは、そのデータファイルへの Btrieve アクセスには直接影響しません。

ただし、バインドされたファイルには Btrieve アクセスを制限するほかの制約があることがあります。

関連項目

データベースへの「整合性の設定」および「バウンドデータベース」設定の使用法については、「データベース

の新規作成 GUI リファレンス」を参照してください。

113


114

7
Pervasive PSQL セキュリティ
トランザクショナルおよびリレーショナルインターフェイスのためのセキュリティに関する概念と作業

Pervasive PSQL は、 Btrieve や SQL ベースのアプリケーションで使用できる完全なリレーショナルデータベース

セキュリティを提供します。この章では、これら 2 つの関係および、互いにどのように動作するのかについて説

明します。

「セキュリティモデルと概念」

「トランザクショナルインターフェイスのセキュリティ計画」

「トランザクショナルインターフェイスセキュリティのクイックスタート」

「セキュリティの作業」

「データの暗号化」

115



Pervasive PSQL v11 SP3 で新しいデータベースを作成したとき、デフォルトでは、データベースセキュリティは

オフになっています。これは、"Master" ユーザーのパスワードを指定することによってオンになります。パスワー

ドに関する制約については、「識別子の種類別の制限」の表を参照してください。

Master ユーザー

データベースセキュリティは、セキュリティをオンにしたときに、データベースヘのフルアクセス権を持つ

"Master" という名前のデフォルトユーザーが存在するかどうかに基づきます。デフォルトでは、 Master ユーザー

のパスワードは設定されていません。 Master ユーザーのパスワードを指定すると、セキュリティが有効、つまり

オンになります。

Master ユーザーは、グループやほかのユーザーを作成したり、作成したグループやユーザーにデータアクセス権

限のセットを定義することができます。ユーザーやグループは、 SQL ステートメントを使用して、あるいは

Pervasive PSQL Control Center （PCC）を使用して追加できます。

特殊な PUBLIC グループ

すべてのユーザーに同様のアクセス権を付与したい場合は、それらのアクセス権を "PUBLIC" という名前の特殊

なグループに付与することができます。初、 PUBLIC には何のアクセス権も割り当てられていません。

PUBLIC はすべてのユーザーおよびグループにデフォルトのアクセス権を与えることから、特殊なグループと呼

ばれます。データベースエンジンは常に、まず PUBLIC に割り当てられているアクセス権を調べます。 PUBLICのアクセス権の適用方法をわかりやすくするために 2 つの例を示します。

PCC で、 PUBLIC に CREATE TABLE 権限を割り当てるとします。次に、 PCC で "myuser" という名前のユーザー

を作成しますが、ユーザーのアクセス権にテーブルを作成するための個別の権限は含めないものとします。デー

タベースエンジンは初に PUBLIC のアクセス権を調べるため、この場合、テーブル作成の権限は PUBLIC から

付与されることになり、 myuser はテーブルを作成できます。

逆に言えば、 PUBLIC にアクセス権が付与されていない場合は、個々のユーザーまたはグループに付与されてい

るアクセス権が適用されます。たとえば、 PCC で、 PUBLIC に CREATE TABLE 権限を割り当てないとします。

ユーザーまたはユーザーが属するグループのアクセス権がテーブルの作成を許可しない限り、どのユーザーも

テーブルを作成できません。

ユーザーとグループ

データベースセキュリティをオンにしたら、グループとユーザーを定義することができます。 PCC の PervasivePSQL エクスプローラーにグループおよびユーザーのノードが現れます。『Pervasive PSQL User's Guide』の「ユー

ザーとグループの作業」を参照してください。

制限

ユーザーは、複数のグループのメンバーになることはできません。

グループ内のすべてのユーザーは、そのグループに定義された権限と完全に同じ権限を持ちます。グループ

のメンバーであるユーザーに個別に権限を許可したり取り消したりすることはできません。

グループを別のグループに追加することはできません。

116

セキュリティモデルと概念


このセクションでは、 SQL （リレーショナル）および Btrieve （トランザクショナル）で使用できるセキュリティ

モデルについて説明します。両方のインターフェイスは、ユーザーに権限を割り当てる方法の選択に際して、同

レベルの精度を共有しています。どちらのインターフェイスもデータベースセキュリティをサポートします。ト

ランザクショナルインターフェイスには、アクセス許可の方法を決定するセキュリティポリシーが追加されてい

ます。リレーショナルインターフェイスは列レベルのセキュリティをサポートしています。

メモトランザクショナルインターフェイスのセキュリティポリシーを指定しても、リレーショナルイン

ターフェイスのセキュリティには何ら影響ありません。しかし、説明上、トランザクショナルインターフェ

イスセキュリティで説明されている「データベース」ポリシーと、リレーショナルインターフェイスのセ

キュリティは同じタイプであると考えてください。 2 つのインターフェイスのセキュリティにおける主な違

いは、リレーショナルインターフェイスのセキュリティポリシーを変更できないことです。セキュリティは

オンかオフのいずれかです。オンの場合、セキュリティはトランザクショナルインターフェイス用のデータ

ベースポリシータイプのセキュリティに類似しています。

リレーショナルインターフェイスで使用可能なモデル

リレーショナルインターフェイスの場合、セキュリティはオンかオフのいずれかです（上記の「メモ」を参照し

てください）。デフォルトで、セキュリティはオフになっています。セキュリティは、 Master ユーザーのパスワー

ドを指定することによってオンになります。

セキュリティをオンにしたら、 PCC を使って低でも、データベースヘのログインを許可するユーザーを定義す

る必要があります。ユーザーごとにオブジェクトの権限を設定することができます。さらに、ユーザーのグルー

プを定義したり、各グループにオブジェクトの権限を設定することもできます。

『SQL Engine Reference』では、以下の内容がリレーショナルインターフェイス用のセキュリティに適用されます。

「ビューおよびストアドプロシージャに対する権限」

「ALTER GROUP」

「ALTER USER」

「CREATE GROUP」

「CREATE USER」

「DROP GROUP」

「DROP USER」

「GRANT」

「REVOKE」

「SET PASSWORD」

「SET SECURITY」

「psp_groups」

「psp_procedure_rights」

「psp_table_rights」

「psp_view_rights」

「psp_users」

117


複数のデータベースのデータは、データベースが同じマシン上に存在するのであれば、アクセスできます。ただ

し、一度に 1 つのデータベースにしかログインできません。各データベースのセキュリティを基に、適用される

データベースアクセスの状況を示します。

これ以降のセキュリティについての説明は、トランザクショナルインターフェイスにのみ当てはまります。リ

レーショナルインターフェイス以外の説明が不要であれば、「データの暗号化」へ進んでください。

トランザクショナルインターフェイスで使用可能なモデル

トランザクショナルインターフェイスで使用可能な認証および許可モデルには、次のモデルがあります。

「クラシック」

「混合」

「データベース」

このセクション、およびこれ以降のセキュリティについて説明は、トランザクショナルインターフェイスのみを

使用するアプリケーションに当てはまります。「資格情報」、「ログイン資格情報」、または「ユーザー資格情報」

は、有効なユーザー名とパスワードの一組を指します。

Pervasive PSQL v11 SP3 では、 OS に依存しないデータベース認証および許可の機能がトランザクショナルイン

ターフェイスで利用できます。従来の（オペレーティングシステム）認証モデルは本リリースでも今までどおり

使用できますが、Btrieve のユーザーおよび権限がファイルシステムのユーザーおよび権限から派生されない場合

に、モデルを選択できるようになりました。ユーザーにデータファイルへのオペレーティングシステムアクセ

スが許可されていなくても、そのユーザーにデータベースヘのアクセスを許可できます。

現在ある Btrieve アプリケーションは、アプリケーションコードに何ら変更を加える必要なく、新しいセキュリ

ティモデルを利用することができます。

クラシック

クラシックセキュリティは、本製品の以前のリリースで提供された Btrieve セキュリティモデルです。 Btrieveユーザーの場合、認証はオペレーティングシステムによって実行され、データアクセス権限は当該ユーザーの

ファイルシステム権限によって決定されます。オペレーティングシステムに依存しないデータベースエンジン

で提供される唯一の許可機能は Btrieve オーナーネームで、これは実質的にはファイルアクセスパスワードです。

このセキュリティモデルでは、オペレーティングシステムによって認証されるユーザーはみな、オペレーティン

グシステムを介してデータファイルを読み書きする必要があるため、 Btrieve を介してデータにアクセスする場

合も同様の権限を持ちます。Btrieve オーナーネームはこの規則の例外で、付加的な許可レベルを提供するもので

す。ただし、この許可レベルはユーザーの ID とは関連付けられません。アプリケーションまたはユーザーが指

定されたファイルにオーナーネームを供給できるかどうかということとのみ関連付けられます。

Btrieve オーナーネームの詳細については、「オーナーネーム」を参照してください。

クラシックセキュリティの設定

クラシックセキュリティでは、データベースのユーザーおよびアクセス権限の設定は、オペレーティングシステ

ムでユーザーを作成し、ファイル権限を割り当てることによって行います。データベースエンジンを構成するた

めに実行する別の操作はありません。

ログインしているデータベース

のセキュリティ

ログインしていないデータベース


説明

オンオフアクセスのすべての権利が付与されます。

オンオンユーザー名とパスワードが、両方のデータベースでまった

く同じでなければなりません。

オフオンアクセスは拒否されます。

118


ユーザーアカウントの設定方法および権限の割り当て方法についての説明は、オペレーティングシステムに付属

のドキュメントを参照してください。

混合

混合セキュリティモデルでは、データベースログインの発生時、データベースエンジンはユーザーが入力した

ユーザー名とパスワードをオペレーティングシステムの認証サービスに渡します。オペレーティングシステムが

ユーザー名とパスワードを認証した場合、データベースエンジンはデータベースのユーザーおよび権限テーブル

を使って、当該ユーザーの具体的なアクセス権を決定します。したがって、各ユーザーのデータアクセス権限を

データベース内に定義しておく必要があります。言い換えると、データベースエンジンは、当該ユーザーのデー

タファイルに対するファイルシステム権限に関係なく、定義されている権限を適用します。

Btrieve アプリケーションのデータベース許可は、リレーショナルインターフェイスのセキュリティモデルを拡

張することによって提供されているため、 Btrieve アプリケーションでも使用できます。ユーザーを定義し権限を

設定する機能は、 PCC によって、また、 GRANT、 REVOKE、 ALTER GROUP、 CREATE USER、 ALTER USER、DROP USER などの SQL ステートメントによっても提供されます。

混合セキュリティモデルでは、データベースに定義されているユーザー名はすべて、オペレーティングシステム

に定義されているユーザー名と完全に一致していなければなりません。データベースログイン中は、データベー

スエンジンはユーザーが入力したユーザー名とパスワードを単にオペレーティングシステムの認証モジュール

に渡すだけです。オペレーティングシステムが資格情報を認証した場合、データベースは自身のユーザーおよび

権限テーブルを使って、当該ユーザーの具体的なアクセス権を決定します。各ユーザーをデータベースに追加す

る必要があります。各ユーザーのアクセス権を個別に定義する代わりに、デフォルトグループの PUBLIC を使っ

て 1 度にアクセス権を定義することができます。有効なユーザーは、 PUBLIC グループに付与されているアクセ

ス権を自動的に継承します。

混合セキュリティ環境を設定する詳細な手順については、「混合およびデータベースセキュリティの設定」を参


データベース

データベースセキュリティモデルでは、データベースエンジンが Btrieve データファイルのユーザーの認証と許

可を行います。ユーザーがデータに接続しアクセスする能力は、そのユーザーがアプリケーションを実行するコ

ンピューターに正常にログインできる限りは、オペレーティングシステムのアカウント識別情報やファイルシス

テム権限とは関係ありません。

Btrieve アプリケーションのデータベース認証および許可は、リレーショナルインターフェイスのセキュリティ

モデルを拡張することによって提供されているため、 Btrieve アプリケーションでも使用できます。ユーザーを定

義し権限を設定する機能は、 PCC によって、また GRANT や REVOKE などの SQL ステートメントによって提供

されます。

メモ新しいデータベースを作成する場合は、今までどおり、ユーザーはオペレーティングシステムで管理

者レベルの権限を持っている必要があります。

データベースセキュリティ環境を設定する詳細な手順については、「混合およびデータベースセキュリティの設

定」を参照してください。

混合およびデータベースセキュリティモデルでの注意事項

データベースごとにユーザーのセットを定義する必要があり、ユーザーごとにアクセス権限のセットを定義する

必要があります。アクセス権を割り当てるも簡単な事例は、特殊なグループの PUBLIC にアクセス権を割り当

てることです。すべてのユーザーは PUBLIC からデフォルトのアクセス権を継承します。また、当該データベー

スのメンバーであると判断される必要のあるデータファイルが格納されているファイルシステムディレクトリ

を指定する必要があります。

119


データベースエンジン（または、混合セキュリティの場合はオペレーティングシステム）は、ディレクトリツリー内にあるデータファイルへのアクセスが試行されるたびに、ユーザー認証および許可を実行します。データ

ベースとディレクトリ間のこの関連付けがないと、Btrieve アプリケーションが特定のデータファイルを開こうと

したとき、データベースエンジンには定義済みのユーザーおよび権限の適切なセットを判断するためのデータ

ベースコンテキストがありません。

混合またはデータベースセキュリティモデルは、当該データベースに属するものとして定義されているディレク

トリに存在する Btrieve データファイルでのみ使用できます。このデータベースには、「デフォルトのデータベー

スと現在のデータベース」に記載されているデフォルトデータベース DefaultDB も含まれます。データベースと

関連付けられていないディレクトリにあるデータファイルは、クラシックセキュリティモデルでのみアクセス

できます。

これらのモデルの主な利点の 1 つは、オペレーティングシステムユーザーのデータファイルへのアクセスを制

限する一方で、データベースエンジンを介したデータアクセスにはフルアクセスを許可できることです。対照

的にクラシックモデルでは、データファイルへのレコードの追加が許可されているユーザーは、必ずオペレー

ティングシステムからもデータファイルのコピー、削除ができなければなりません。

メモワークグループエンジンはオペレーティングシステム認証を実行しないため、ワークグループエンジ

ンを使用している場合の、クラシックおよび混合セキュリティポリシーの動作は同じです。ワークグループ

エンジンを使って Btrieve データベースをセキュリティで保護したい場合は、データベースセキュリティポリシーを使用する必要があります。

混合およびデータベースセキュリティの設定

混合セキュリティまたはデータベースセキュリティに移行するには、多数の選択を行った上、慎重に計画を立て

る必要があります。既に確立している環境では、お使いの製品環境が混乱しないように、 Btrieve ファイルをデー

タベースにまとめる方法を考え、移行の予定を立てる必要があるかもしれません。

クラシックセキュリティから混合またはデータベースセキュリティへの変換方法に関する情報については、「セ

キュリティの作業」を参照してください。次のセクションでは、「セキュリティの作業」で取り上げる題材の概要

について簡単に説明します。

オーナーネーム

オーナーネームは、 Btrieve ファイルのアクセスを得るために必要なパスワードです。オーナーネームとシステ

ムユーザー名あるいはリレーショナルデータベースユーザー名との間に関連はありません。オーナーネームは、

ファイルパスワードと考えてください。

短いオーナーネームは半角 8 文字までの範囲で指定できます。長いオーナーネームは半角 24 文字までの範囲で

指定できます。ただし、長いオーナーネームを指定した場合、そのデータファイルは Pervasive PSQL v10 SP1 より前のデータベースエンジンで読み取ることができないので注意してください。また、長いオーナーネームを使

用したデータファイルは、v9.5 より前のファイル形式にリビルドしようとする場合、そのオーナーネームを初

に削除しておかないとリビルドすることができません。オーナーネームは、長いものでも短いものでも、その

大長（8 または 24 バイト）に満たない部分は空白が埋め込まれます。

PCC では現在、ファイルのセキュリティプロパティを介してオーナーネームを指定する方法は提供していませ

ん。ただし、 PCC の SQL Editor で GRANT ステートメントを使ってオーナーネームを設定することができます。

『SQL Engine Reference』の「オーナーネーム」を参照してください。 Maintenance ユーティリティまたは FunctionExecutor ユーティリティを使用して、ファイルのオーナーネームを設定またはクリアすることもできます。

「Maintenance を使用した Btrieve データファイルの操作」を参照してください。

120


オーナーネームには、表 29 に示すように、いくつかの属性があります。

備考

ファイルに暗号化を指定したオーナーネームを初に設定したときに、データベースエンジンはファイル全体を

暗号化します。この処理はファイルが大きいほど時間がかかります。

暗号化されたファイルに対するデータアクセス操作は通常のファイルに比べて時間がかかります。データベース

エンジンは、ディスクからページを読み込むと暗号化された各ページを元に戻して解読し、ディスクに書き戻す

ときに再度暗号化します。

注意暗号化が設定されている場合には特に、ファイルのオーナーネームを忘れないよう記録しておいてく

ださい。オーナーネームを見つける方法はありませんし、オーナーネームなしでデータにアクセスする方法

もありません。

オーナーネームおよびセキュリティ

保護されたデータベース内のテーブルであるファイルに Btrieve オーナーネームが設定されている場合、データ

ベースの Master ユーザーは、そのテーブルに対する権限を任意のユーザー（Master ユーザーを含む）に与える場

合、 GRANT ステートメントでオーナーネームを使用する必要があります。

あるユーザーのためにオーナーネームを含む GRANT ステートメントを発行すると、そのユーザーはデータベー

スにログインすることにより、毎回オーナーネームを指定することなく、指定されたテーブルにアクセスするこ

とができます。

Master ユーザーが GRANT ステートメントで正しいオーナーネームを使ってテーブルに対する権限をあるユー

ザーに許可していなければ、そのユーザーが ODBC 経由でそのテーブルにアクセスを試みた場合、アクセスは許

可されません。

テーブルが読み取り専用属性のオーナーネームを持っている場合、 Master ユーザーはオーナーネームを使って

自分自身に SELECT 権を特に許可しなくても、自動的に SELECT 権限を持ちます。

データファイルにオーナーネームが設定されていない場合、そのファイルのリレーショナルセキュリティを有

効にすると、ファイルへの Btrieve アクセスは許可されなくなります。ファイルのアクセス時にオーナーネーム

の指定が可能なユーザーが Btrieve アクセスを回復できるように、そのファイルにオーナーネームを設定する必

要があります。この動作により、デフォルトの Btrieve ユーザーはリレーショナルセキュリティを迂回できなく

なります。

表 29 オーナーネームのオプション

オプション説明

読み取り専用パスワードを指定しなくても、ユーザーはデータファイルの変更を行わないデータアクセス

操作を行うことができます。

読み取り専用、

暗号化

パスワードを指定しなくても、ユーザーはデータファイルの変更を行わないデータアクセス

操作を行うことができます。このオプションを設定すると、データベースエンジンはオー

ナーネームをキーに使用してファイルの全レコードを暗号化します。後から追加されるレ

コードも暗号化されます。

ノーマルパスワードを指定しないと、ユーザーはファイルアクセス操作を一切行うことができません。

暗号化のみパスワードを指定しないと、ユーザーはファイルアクセス操作を一切行うことができません。

追加または変更されたレコードは、パスワードを使用して暗号化されます。このオプション

を設定すると、データベースエンジンはオーナーネームをキーに使用してファイルの全レ

コードを暗号化します。後から追加されるレコードも暗号化されます。

121


例

Btrieve オーナーネームを使用してファイルへのアクセスを許可する例については、『SQL Engine Reference』の

「GRANT」を参照してください。

複数のデータベースのデータにアクセスする

複数のデータベースのデータは、データベースが同じマシン上に存在するのであれば、アクセスできます。ただ

し、一度に 1 つのデータベースにしかログインできません。各データベースのセキュリティを基に、適用される

データベースアクセスの状況を示します。

表 30 セキュリティ設定に基づくデータベースのアクセス権

ログインしているデータベース


ログインしていないデータベース


説明

有効（混合またはデータベースセキュリティモデルのいずれか）

なしアクセスのすべての権利が付与されます。



ユーザー名とパスワードが、両方のデータベー

スでまったく同じでなければなりません。

なし有効（混合またはデータベースセキュリティモデルのいずれか）

アクセスは拒否されます。

122

トランザクショナルインターフェイスのセキュリティ計画


Pervasive PSQL v11 SP3 をインストールした後も、セキュリティのデフォルトの動作は以前のリリースと変わりま

せん。つまり、データベースエンジンは「クラシック」、すなわち OS ベースの認証および許可を使用します。オ

ペレーティングシステムを通して特定データファイルへのアクセスが許可されているユーザーは、 Btrieve オー

ナーネームを使ってデータファイルへのアクセスが制限されていない限り、ファイルに対する権限と同レベルの

権限をファイルに含まれているデータレコードに対しても持ちます。

このセクションでは、デフォルトデータベースや許可されたユーザー、および Btrieve セキュリティポリシーの

その他の側面を設定するために必要な手順について説明します。

使用可能なオプション

使用できるセキュリティオプションは 3 つあります。適なオプションを選択するための手助けとなるよう、こ

れらのオプションの機能を以下に示します。暗号化はどの設定でも任意です。

データベースのセキュリティの下では、データベースのユーザーアカウントは OS のユーザーアカウントとは

まったく無関係です。

対照的に、クラシックセキュリティでは、コンピューターへのログインに成功したユーザーは、データを含んで

いるファイルに対してユーザーに割り当てられているファイルシステム権限のレベルに従った、そのデータベー

スコンテンツへのアクセス権を持ちます。

後に、混合セキュリティポリシーは、ほかの両方のポリシーの側面を持っています。この方式では、ユーザー

は OS のユーザー名とパスワードを使ってログインしますが、データに対するユーザーのアクセス権はデータ

ベースに設定されているユーザー権限によって決定されます。

ポリシーの選択

このセクションでは、複数のセキュリティポリシーの中から 1 つを選び出す上での主な判断材料をいくつかを述

べます。

表 31 セキュリティ設定の機能比較

機能クラシック混合データベース

管理者がユーザーごとにオペレーティングシステム（OS）とデータベース

のユーザーアカウントを別々に設定する必要があります。

○ ○

データベースのユーザーアカウントは OS のユーザーアカウントから直接

派生します。

○ ○

ユーザーのデータアクセス権は、ユーザーのファイルシステムの権利とは

関係がありません。管理者はデータベースを介して各ユーザーにデータアクセス権を割り当てる必要があります。

○ ○

ユーザーのデータアクセス権は、 OS ユーザーのファイルシステム権限か

ら直接派生されます。

○

Pervasive ベースの Windows アプリケーションから、データベースのユー

ザー名とパスワードを入力する自動ログインダイアログを表示できます。

○ 1 ○ 1 ○

データベースは OS のログインの成功を有効なデータベースユーザーとし

て受け入れます。

○ ○

ユーザーは、コンピューターにログインするのとは別にデータベースにログ

インする必要があります。

○

1 ログインダイアログは、リクエスターがオペレーティングシステムを介して ID を決定できない場合に現れます。

123


クラシックを選択する理由

ユーザーがデータファイルへのファイルシステムアクセス権を持っていることを安心して受け入れられ

る。たとえば、データファイルからレコードを削除する権限を持っているユーザーは、オペレーティングシステムからそのファイル自体を削除することもできます。

管理上の面倒な作業は小限にしたい。各ユーザーの OS ユーザーアカウントと、少なくとも 1 つのデータ

ベースアカウントの両方を設定することはしたくない。

各ユーザーのファイルシステム権限によって異なる、さまざまなデータアクセス権を持つ必要がない。

ユーザーにデータベースのログインを個別に行わせたくない。

混合を選択する理由

ユーザーにデータベースのログインを個別に行わせたくない。

有効なデータベースユーザーには、オペレーティングシステムにおけるデータファイルへのいかなる権限

も持たせないようにしたい。たとえば、データベースに対するあらゆる権限を持っているユーザーに、オペ

レーティングシステムからデータファイルを削除する権限を持たせないようにすることができます。

OS のユーザーアカウントと同じユーザー名のデータベースユーザーアカウントを設定するつもりである。

また、データベースユーザーごとに権限を割り当てるつもりである。選択すれば、特殊グループの PUBLICから権限を継承することによって、すべてのユーザーが同レベルの権限を持つことができます。

データベースを選択する理由

ユーザーにデータベースのログインを個別に行わせたい。つまり、オペレーティングシステムへのログイン

後、ユーザーはもう一度データベースにログインする必要があります。この動作は、権限を与えられたコン

ピューターユーザーの一部にはデータベースヘのアクセスが許可されているが、一部には許可されていない

場合に有用です。

有効なデータベースユーザーには、オペレーティングシステムにおけるデータファイルへのいかなる権限

も持たせないようにしたい。たとえば、データベースに対するあらゆる権限を持っているユーザーに、オペ

レーティングシステムからデータファイルを削除する権限を持たせないようにすることができます。これ

は、混合セキュリティポリシーを使っても実現できます。

データベースのユーザーアカウントには、オペレーティングシステムのアカウントとは異なる名前を使いた

い。たとえば、オペレーティングシステムのユーザー "jsmith" が "john" としてデータベースにログインする

ことを要求されるかもしれません。

ユーザーとその権限は、サーバーやマシンでなくデータベースの下にある。これにより、データベースのユー

ザーやユーザーの権限を再作成しなくても、データベースをあるマシンから別のマシンへ移動することがで

きます。

セキュリティを設定するための準備

トランザクショナルインターフェイスのセキュリティ設定は 1 つの簡単な処理ですが、この処理には十分な柔軟

性があるため、いくつかの準備を必要とします。このセクションでは、 Btrieve セキュリティの設定を開始する前

に知っておくべき情報について説明します。

データベースの数

混合またはデータベースセキュリティの場合は、すべてのユーザーに同レベルの権限を割り当てるか、もしくは

データベースごとに定義済みユーザーのセットを作成する必要があります。

まったく関連のないデータの本体を含んでいる Btrieve データファイルが 2 つ以上ある場合は、別個のデータベー

スを 2 つ以上設定し、それぞれに固有の許可されたユーザーのセットを持ちたいと思われるかもしれません。し

かし、一般的に言えば、定義済みユーザーのセットを複数作成して管理する必要がないよう、別々にするデータ

ベースの数は小限にしたいでしょう。ほとんどの場合は、 1 つのデータベースで十分です。データベースにお

124


けるユーザー権限では、各ユーザーのデータベースへのアクセスを規制できるため、ある特定のユーザーのアク

セスを制限するためだけに別のデータベースを作成する必要はありません。

1 つのデータベースのみが必要であると判断した場合は、既存のデータベース DefaultDB を Btrieve ファイルと関

連付けられているデータベースとして使用することができます。そうではなく、独自の名前を付けたデータベー

スを設定することもできます。

データファイルの場所

名前付きデータベースのデータディレクトリに、データファイルが格納されているディレクトリを指定するこ

とによって、 Btrieve データファイルをデータベースと関連付けます。そのため、データベースと関連付けるすべ

てのデータファイルが格納されているディレクトリを知っておく必要があります。データファイルがすべて特定

のディレクトリ内のサブディレクトリツリーに存在する場合は、トップレベルのディレクトリのパス名さえわ

かっていれば十分です。ハードディスクドライブ上のすべてのデータファイルを含めたい場合は、 "C:\" を使用

することもできます。

ユーザー名とは ?混合セキュリティを使用する予定ならば、すべてのユーザーに同一の権限を割り当てるか、もしくは異なる権限

を持つユーザーのユーザーアカウントを設定する必要があります。個々のユーザーを設定するつもりならば、

データベースユーザー名にしたいオペレーティングシステムユーザー名の一覧が必要です。設定するデータ

ベースユーザー名は、オペレーティングシステムユーザー名と完全に一致している必要があります。後からユー

ザー名を追加することはいつでもできますが、一度に複数のユーザーを作成した方がより効率的です。

セキュリティポリシーとは ?セキュリティを設定する前に、使用する予定のポリシーがどういうものであるかを知っておく必要があります。

セットアップ処理はポリシーによって若干異なります。ポリシーを選択する上での考慮点は、「ポリシーの選択」

に記載されています。

処理の概要

このセクションでは、データベースのセキュリティの設定に使用される高レベルな手順の概要を示します。より

詳細な作業手順の説明については後述のセクションで提供されています。

1 準備をします。上記の「セキュリティを設定するための準備」で示されたとおり、必要な情報を収集し、開

始するために必要な決定を行います。データベースの数はいくつにしますか？Btrieve ファイルが保存されて

いる場所は？ユーザー名は何ですか？どのセキュリティポリシーを使用しますか？

2 Btrieve ファイルとともに使用するデータベースを選択し、そのデータベースにデータファイルの場所を示す

データディレクトリを設定します。この手順は、混合またはデータベースセキュリティでのみ必要となりま

す。

この手順の詳細については、『Pervasive PSQL User's Guide』の「定義済みの DefaultDB も含め、既存のデータ

ベースを Pervasive PSQL ファイルと使用するには」を参照してください。

3 セキュリティをオンにします。

この手順の詳細については、『Pervasive PSQL User's Guide』の「Pervasive PSQL エクスプローラーを使って

セキュリティをオンにするには」を参照してください。

4 ユーザーおよび権限を作成します。 SQL ステートメントまたは PCC を使用して、ユーザーアカウントおよ

び当該ユーザーの権限を作成します。この手順は、混合またはデータベースセキュリティでのみ必要となり

ます。

ユーザーのアクセス権を付与するも簡単な方法については、『Pervasive PSQL User's Guide』の「PervasivePSQL エクスプローラーを使用してすべてのユーザーに権限を割り当てるには」を参照してください。

5 データベースの Btrieve セキュリティに［混合］または［データベース］を設定します。

125


この手順の詳細については、『Pervasive PSQL User's Guide』の「データベースのセキュリティポリシーを設

定または変更するには」を参照してください。

6 オペレーティングシステムでデータファイルをセキュリティ保護します。混合またはデータベースセキュ

リティの場合、これでユーザーは、オペレーティングシステムにおけるデータファイルへのアクセス権を何

も持っていなくても、データにアクセスできるようになります。ファイルへのセキュリティ保護されたアク

セスに関する情報は、オペレーティングシステムのドキュメントを参照してください。

トランザクショナルインターフェイスセキュリティの作業の概要次の表は、異なるセキュリティモデルを使用するために必要となる作業の基本レベルを示しています。セキュリ

ティモデルを実装するために必要な作業については、「セキュリティの作業」を参照してください。

表 32 セキュリティのセットアップ作業の概要

セキュリティモデル

認証 / 許可動作および高レベルセットアップ作業の概要

クラシックオペレーティングシステム /オペレーティングシステム

ユーザーにすべてのデータベースファイルへのファイルアクセス権限

を付与します。

よりアクセスを制限するために、 Btrieve ファイルにオーナーネームを

追加します（任意）。

混合オペレーティングシステム /データベース

このセキュリティモデルは、ワークグループエンジンを使用している

場合はクラシックモデルと同様の動作をすることに注意してください。

オペレーティングシステムでユーザーを設定します。ユーザーはこの

ユーザー名およびパスワードと対照して認証されます。

個別でユーザーにセキュリティを設定したい場合は、 Pervasive PSQLControl Center を使って、データベースセキュリティで同じ名前付けを

したユーザーを設定します。認証は OS レベルで発生しますが、データ

ベース権限はデータベースに保存されるため、オペレーティングシステ

ムのユーザー名とデータベースのユーザー名は一致していなければな

りません。

Pervasive PSQL Control Center または SQL ステートメントを使って、ユー

ザーのデータベース権限を定義します。もう 1 つの方法として、PUBLICグループに権限のセットを定義します。グループ PUBLIC から権限を継

承する、認証されたすべての OS ユーザーは、 PUBLIC と同じ権限を持

ちます。どのユーザーも、 PUBLIC に与えられた権限より低い権限を持

つことはありません。

データベースデータベース /データベースオペレーティングシステムのユーザー名とパスワードは、 PervasivePSQL データベースセキュリティとは関係ありません。

Pervasive PSQL Control Center ユーティリティまたは SQL ステートメン

トを使って、ユーザーを設定します。

Pervasive PSQL Control Center または SQL ステートメントを使って、デー

タベース権限を定義します。

Pervasive PSQL Control Center の設定プロパティを使って、認証資格情報

の渡し方を指定します。この手順は、新しい設定プロパティの「クライ

アント資格情報の入力要求」および「クライアント保持の資格情報の容

認」を参照します。

126

トランザクショナルインターフェイスセキュリティのクイックスタート

トランザクショナルインターフェイスセキュリティのクイックスタート

このセクションでは、オペレーティングシステムで Btrieve データファイルをセキュリティ保護する一方、デー

タベースユーザーには引き続きデータへのアクセスを許可するための、も簡単な方法についての手順を説明し

ます。

この手続きが完了したら、アプリケーションを介してデータにアクセスするためのデータベースユーザー権利に

影響を与えることなく、データファイルに対するオペレーティングシステムユーザー権利を取り消すことがで

きます。

メモデータベースエンジンがインストールされているコンピューターに、管理者権限を持つオペレーティ

ングシステムユーザーとして、または Pervasive_Admin セキュリティグループのメンバーであるユーザーと

してログインする必要があります。

1 Pervasive PSQL Control Center （PCC）を起動します。 PCC の起動方法については、『Pervasive PSQL User'sGuide』の「Windows での PCC の起動」を参照してください。

2 作業したいデータベースエンジンが PCC に登録されていない場合は、直ちに登録します。データベースエンジンの登録方法については、『Pervasive PSQL User's Guide』の「リモートサーバーエンジンを登録するに

は」を参照してください。

3 登録されているエンジンのデータベースを展開します（ノードの左にある展開アイコンをクリックします）。

4 PCC で、データベース DefaultDB を右クリックしてから［プロパティー］をクリックします。

5 ディレクトリノードを選択し、［新規］ボタンをクリックします。

6 Btrieve ファイルのパスを入力したら［OK］をクリックし、その後［適用］をクリックします。

ファイルが複数のディレクトリに散在している場合は、ファイルすべてに共通の上位ディレクトリを指定し

ます。必要であればルートレベルを指定することもできますが、そうすると、ルートレベルとその下位ディ

レクトリにあるすべての Btrieve ファイルが DefaultDB に含まれてしまいます。たとえば、Windows の場合の

ルートレベルは C:\ となります。『Pervasive PSQL User's Guide』の「定義済みの DefaultDB も含め、既存の

データベースを Pervasive PSQL ファイルと使用するには」を参照してください。

すべてのディレクトリを入力する必要はありません。データベースに含めたい Btrieve ファイルすべてに共通

する下位のディレクトリのみ入力します。

7 DefaultDB のセキュリティを有効にします。プロパティダイアログボックスのツリーで［セキュリティ］ノー

ドをクリックします。

8 ［データベースセキュリティ］タブをクリックします。

9 ［セキュリティを有効にする］をクリックします（オンにします）。

10 Master ユーザーに使用するパスワードを入力します。指示に従って、 2 回入力します。［OK］をクリックし

ます。

これでセキュリティは有効になりました。しかし、ユーザーは現在のところ以前と同様のアクセス権を持っ

ているため、デフォルトでは OS のユーザー権利に基づいてアクセスが行われます。次の段階では、この状

況に対処します。

パスワードは大 8 バイトに制限されているので注意してください。パスワードには、セミコロン（;）と疑

問符（?）以外のあらゆる表示可能な文字を使用できます。

11 ［OK］をクリックして、［プロパティ］ダイアログを閉じます。

12 DefaultDB 下の［グループ］を展開（ノードの左にある展開アイコンをクリック）し、グループ PUBLIC を右クリックします。

127


13 ［プロパティー］をクリックした後、ツリーで［権限］をクリックします。

14 ［データベース］タブをクリックします。

15 必要な権限をクリックします。

たとえば、すべての認証ユーザーに読み取り専用の権限を付与したい場合は、［選択］をオンにします。この

オプションにより、データの読み取り専用の権限がすべてのユーザーに与えられます。すべてのユーザーに

更新権限を付与する場合は［更新］をオンにし、その他同様に行います。

ユーザーによって異なる権限を付与する場合は、グループアカウント（必要な場合）および個々のユーザー

アカウントを作成する必要があります。これは、 SQL で GRANT ステートメントを使用するか、または PCCを使用して行います（「セキュリティの作業」を参照してください）。


17 データベース DefaultDB を右クリックしてから［プロパティー］をクリックします。

18 ［セキュリティ］をクリックし、［Btrieve セキュリティ］タブをクリックします。

19 ［混合］をクリックし、［OK］をクリックします。

メモ手順 15 を指示どおりに完了するまでは、［Btrieve セキュリティ］のポリシー設定を変更してはいけま

せん。ユーザーアカウントを作成していなかったり、グループ PUBLIC に権限を付与していなかったりする

と、セキュリティポリシーの変更によって、すべてのユーザーがデータにアクセスできなくなります。

以上の手順により、オペレーティングシステムによって認証されているユーザーにのみログインアクセス権

が許可され、それらのユーザーのアクセス権は、データベースでそのユーザーに付与した権限によって定義

されるようになりました。

20 お使いのオペレーティングシステムの手順に従って、オペレーティングシステムでデータファイルをセ

キュリティ保護します。これで、データベースエンジンを介してデータにアクセスする能力に影響を与える

ことなく、オペレーティングシステムユーザーがデータファイルに対するあらゆる権限も持つことを拒否

できるようになりました。

注意必ずオペレーティングシステムでデータファイルをセキュリティ保護してください。この手順を実行

しないと、ユーザーは依然としてこの処理より前の段階と同じレベルの権限によって、オペレーティングシステムからファイルにアクセスできてしまいます。ユーザーが直接ファイルを変更、削除できないようにす

るには、ユーザーのデータファイルに対するオペレーティングシステム権限を取り消す必要があります。

128

セキュリティの作業

セキュリティの作業

『Pervasive PSQL User's Guide』の「セキュリティの作業」を参照してください。

129


データの暗号化

Pervasive PSQL v11 SP3 には、 Pervasive PSQL 使用時に発生するデータベース関連のネットワークトラフィック

を暗号化する機能があります。この種の暗号化は、多くの場合「ワイヤ暗号化」と呼ばれます。これは、データ

がネットワークワイヤ上、あるいはワイヤレスも含め、あらゆる介在するネットワークインフラストラクチャ上

を通るときに保護されるからです。ワイヤ暗号化の使用が要求されていないときは、アプリケーションによって

ネットワーク上で送信されるデータへの不正アクセスに対する追加の抑止力を提供します。

この暗号化機能は、セキュリティモデルとは直接関係ありません。どのセキュリティモデルも、ワイヤ暗号化を

オンにして、またはオンにしないで使用できます。

ワイヤ暗号化の設定プロパティ

ワイヤ暗号化に関連する 2 つの設定があります。これらの設定は、サーバーはもちろん、各クライアントマシン

で設定する必要があります。これらの設定の詳細については以下を参照してください。



ワイヤ暗号化の設定にアクセスするには

1 PCC の Pervasive PSQL エクスプローラーで、次のいずれかを実行します。

a. サーバーの場合は、［エンジン］ノードの下にあるサーバー名を右クリックします（ノードを展開する

には、プラス（+）記号をクリックします）。

b. クライアントの場合は、［ローカルクライアント］ノードの下にある［MicroKernel ルーター］を右ク

リックします（ノードを展開するには、プラス（+）記号をクリックします）。


3 ツリーで［アクセス］をクリックします。

暗号化の注意

製品の本リリースは、ネットワークを通じてデータを渡す前に、 "Blowfish" というよく知られた、実績のあるパ

ブリックドメインの暗号化アルゴリズムを使って暗号化を実行しています。

40 ビットキーを使用する暗号化では、少量の保護がデータに提供されます。 56 ビットキーを使用する暗号化

では、解析がより困難になります。後に、 128 ビットキーを使用する暗号化は、一般にも解析が困難である

と見なされています。

メモ暗号化を使用すると、データのネットワークスループットが低下します。

以前のバージョンとの互換性

以前のバージョンの Pervasive PSQL はワイヤ暗号化をサポートしていなかったため、これらは、本リリースの暗

号化を要求するクライアントまたはサーバーと通信することができません。暗号化をサポートしていないクライ

アントまたはサーバーは、暗号化を要求するクライアントまたはサーバーに接続しようとすると、エラーを返し

ます。

暗号化の設定

お使いの環境で暗号化の設定をオンにする前に、まず、暗号化の必要性について考慮してください。状況に応じ

て、さまざまな方法で暗号化環境を設定することができます。次の 4 つの一般的な方式を設定できます。

暗号化なし

130

データの暗号化

すべての通信を暗号化

特定のクライアントとの通信を暗号化

特定のサーバーとの通信を暗号化

暗号化なし

まず初に、そのデータに暗号化が必要であると考えられる特性があるかどうかを検討します。データは機密か？

権限のないユーザーの管理下にあって利用価値のあるデータか？組織に危害を加えるために利用することができ

るか？これらの質問やその他類似する質問の答えが「いいえ」である場合は、データを暗号化する必要はまった

くなさそうです。このような状況では、暗号化の代償にパフォーマンスの低下を受け入れるメリットがありませ

ん。確信が持てない場合は、データセキュリティのエキスパートにご相談ください。

データを保護する必要があるとしても、まだ暗号化する必要はない可能性があります。アプリケーションを LAN上で単独に実行しており、ネットワークインフラストラクチャの物理的なセキュリティに満足しているのであれ

ば、暗号化は必要ありません。

特定のクライアントとの通信を暗号化

次に、あなたのデータベースに接続する大口の取引先がリモートサイトにあるとします。リモートクライアント

との通信でのみ暗号化を使用したいと思われるかもしれません。これは、リモートクライアントの［ワイヤ暗号

化］を［常時］に設定し、そのリモートクライアントがアクセスするサーバー値を［必要な場合］に設定するこ

とによって実現できます。内部クライアントはすべて［しない］に設定します。このようにして、サーバーは、

暗号化を要求するリモートクライアントと通信する場合にのみ暗号化を使用するようになります。

特定のサーバーとの通信を暗号化

立場が逆転して、お使いの環境に 1 つ以上のリモートサーバーが入っており、それらのサーバーはあなたが 100%信頼していないネットワークインフラストラクチャによってアクセスされているものとします。この場合は、そ

れらのサーバー値を［常時］に設定し、ローカルクライアント値を［必要な場合］に設定することができます。

そうすると、暗号化を要求するリモートサーバーとの通信のみが暗号化されます。

すべての通信を暗号化

後に、 Pervasive ベースのアプリケーションをほとんどの場合 WAN や VPN、またはその他の 100% 信頼してい

ない外部ネットワーク上で実行している場合は、データベース通信を 100% 暗号化したいと思われるかもしれま

せん。この状況では、すべてのクライアントとサーバーで、ワイヤ暗号化に［常時］を設定します。

暗号化レベルの選択

クライアントおよびサーバーは暗号化された通信を必要とするという結論に達したら、どの抑止レベルが要望に

沿うかを決定する必要があります。

Pervasive Software Inc. は、お客様の特定の要望に沿った暗号化レベルについてアドバイスすることはできません

ので、お客様が適切なデータセキュリティエキスパートを交えて検討される際に情報提供できるよう、いくつか

のガイドラインを用意しています。これらのガイドラインは、暗号化されたデータを第三者から読み取られたり

デコードされたりしないことを Pervasive が保証するものではありません。あらゆる暗号化方式と同様に、「解読

できない」コードの類はありません。暗号化の種類によって解析する難易度が変化するだけです。Pervasive PSQLの 128 ビット暗号化は、極めて専門的な個人ハッカーが持てる技術と設備をもってしても、デコードすることが

「非常に困難」であると認められています。

低度（40 ビット）暗号化

データが渡ってはいけない人の手に渡ってしまったとしても、そのデータによって組織や顧客が被る被害レベル

がそれほど深刻でない場合には、この暗号化レベルの使用を検討してください。低度の暗号化を検討するもう 1つの判断材料は、単純に、データがワイヤを通っている中に不用意なネットワーク監視者にデータを読み取ら

れたくないかどうかということです。

131


中度（56 ビット）暗号化

セキュリティに無頓着な監視者に備えてもっと強力な保護が何か必要であると確信しているが、強レベルのセ

キュリティが必要だとは思わないような状況では、この暗号化レベルの使用を検討してください。

高度（128 ビット）暗号化

データにクレジットカード番号、社会保障番号、金融口座番号、または法律で保護されているその他の情報など、

非常に秘匿性の高い情報が含まれているような状況では、この暗号化レベルの使用を検討してください。特に、

お使いのデータベースが、インターネットショッピング Web サイトやオンライン証券会社 Web サイトなど、慎

重を期するデータを含んでいることで知られるネットワークのエンティティと関連付けられている場合には、こ

の暗号化レベルを考慮してください。また、所属する組織が以前にデータセキュリティを解析されそうになった

ことがある場合には、この暗号化レベルを検討してください。

暗号化の影響

暗号化を使用すると、クライアント / サーバーのパフォーマンスは低下します。暗号化をオンにした場合は、送

信側でデータの各断片を暗号化し、受信側でそれをデコードする必要があります。暗号化なしで同様の操作を実

行した場合と比べ、この処理には余分な CPU サイクルが必要となります。暗号化のレベルはパフォーマンスに影

響しません。暗号化の使用によるパフォーマンスの低下は、 3 つの暗号化レベルのうちどれを選択しても、おお

よそ同じです。

オーナーネームの暗号化

Pervasive PSQL は、ディスク上のデータファイルの暗号化をサポートします。データファイルがディスクに書き

込まれる際に暗号化を必要とする場合、各ファイルにオーナーネームを設定する必要があります。

詳細については、「オーナーネーム」を参照してください。

132

8
ログ、バックアップおよび復元
ログ、バックアップおよびデータの復元について

Pervasive PSQL には、データ整合性を確実にし、オンラインバックアップおよびデータ被害の復旧をサポートす

るいくつかの強力な機能があります。

「トランザクションログおよびトランザクション一貫性保守」

「アーカイブログおよび Continuous オペレーションについて」

「アーカイブログの使用」

「Continuous オペレーションの使用」

「Backup Agent および VSS Writer によるデータバックアップ」

133


トランザクションログおよびトランザクション一貫性保守

Pervasive PSQL はトランザクションに関わるデータベースオペレーションのデータ整合性を「トランザクション

ログ」および「トランザクション一貫性保守」の 2 つのレベルで保証します。

ここでは、以下の項目について説明します。

「これらの機能の使用法」

「機能の比較」

「どちらの機能を使用するか」

「ログの機能」

「関連項目」

これらの機能の使用法

これらの機能はいずれも、 Pervasive PSQL Control Center 内の設定を使用して、または Distributed Tuning Interfaceを使用してプログラムから、データベースエンジン内で有効または無効にすることができます。「トランザクショ

ン一貫性保守」および「トランザクションログ」を参照してください。

「トランザクション一貫性保守」のデフォルト値はオフで、「トランザクションログ」のデフォルト値はオンです。

機能の比較

これらの機能は共に複数ファイルのトランザクションアトミシティを提供し、確実にデータファイルの一貫性を

保ち、未完了のトランザクションはどのデータファイルにも絶対に書き込まれないようにします。

アトミシティとは、トランザクション内のあるデータオペレーションが完了しなかった場合にはトランザクショ

ン内のどのオペレーションも完了させないことを意味します。アトミックな変更はデータベースに部分的または

あいまいな変更を残しません。個々のファイルに対する変更は、トランザクションログおよびトランザクション

一貫性保守がオンでもオフでも、常にアトミックです。ただし、トランザクションでは、複数ファイルへの変更

をグループ化して 1 つのアトミックグループにすることができます。これら複数ファイルのトランザクションの

アトミシティは、アプリケーション内でトランザクションを使用し、トランザクションログまたはトランザク

ション一貫性保守がオンに設定されている場合にのみ、 MicroKernel が保証します。

これらの利点に加え、「トランザクション一貫性保守」はシステム障害時に、障害前にアプリケーションに正常終

了のステータスコードを返したトランザクションの結果がすべてデータファイルに含まれていることを保証し

ます。

高パフォーマンスが求められる場合には、「トランザクションログ」はこの保証を提供できません。「トランザク

ション一貫性保守」は、エンジンが正常終了のステータスコードを返す前に完了したトランザクションを完全に

トランザクションログに書き出すことを確実にするため、トランザクションログはロガースレッドがログバッ

ファーをディスクにフラッシュするように指示されるとすぐに正常終了のステータスコードを返します。

［トランザクションログ］は［トランザクション一貫性保守］のサブセットです。つまり、［トランザクション一

貫性保守］の設定をオンにすると、ロギングが行われ、［トランザクションログ］の設定はデータベースエンジ

ンによって無視されます。

［トランザクションログ］と［トランザクション一貫性保守］の主な違いを次の表で示します。

表 33 ［トランザクションログ］と［トランザクション一貫性保守］：利点

機能複数ファイル間でのデータの整合性と

トランザクションアトミシティの保証

正常終了のステータスコードを返したすべての完

了済みトランザクションに対するコミットの保証

トランザクションログ可不可

トランザクション一貫性保守可可

134


どちらの機能を使用するか

高のパフォーマンスを得るためには、トランザクションの安全性のニーズに合った低レベルのロギングを使

用することができます。適切なロギングレベルを決定するには、アプリケーションベンダーに確認することが

良の方法です。同じコンピューター上の Pervasive PSQL を使用する複数のアプリケーションがある場合は、それ

らアプリケーションのなかで要求される高レベルのロギングを使用する必要があります。

データファイルが 1 つのみであるか、複数データファイルによるトランザクションを行うアプリケーションがな

い場合は、一般的に「トランザクション一貫性保守」または「トランザクションログ」を使用する必要はありま

せん。このような状況下では、 Pervasive PSQL はログの有無に関わらず、各データファイルの内部的な整合性を

保証します。

トランザクションログ Pervasive PSQL アプリケーションのうち 1 つでも複数データファイル間でトランザクションを行うアプリケー

ションがある場合は、［トランザクションログ］をオンにします。「トランザクションログ」を使用しないと、

Pervasive PSQL ではトランザクションの複数ファイルのアトミシティまたは複数ファイルのデータ整合性を保証

することはできません。

システム障害が発生した場合、このレベルのロギングでは、完了した各トランザクションがデータファイルに書

き込まれることが保証されません。

トランザクション一貫性保守 Pervasive PSQL アプリケーションのうち 1 つでも、複数データファイル間の完了したトランザクションが確実に

データファイルに書き込まれるよう保証することが必要な場合は、「トランザクション一貫性保守」をオンに設

定します。

システム障害が発生した場合、このレベルのロギングは正常終了した各トランザクションがデータファイルに書

き込まれることを保証します。

ログの機能

これらの機能は、オペレーションではなくトランザクションのアトミシティを確実にするものであることに注意

してください。SQL を使用する場合、トランザクションは BEGIN ステートメントまたは START TRANSACTIONステートメントと END または COMMIT ステートメントの間にある一連のオペレーションと定義されます。

Btrieve を使用する場合、トランザクションは Start Transaction オペレーションと End Transaction オペレーション

の間にある一連のオペレーションと定義されます。

すべてのデータファイルの追加および更新はログバッファーに格納されます。トランザクションが完了するか

（トランザクション一貫性保守）、バッファーがいっぱいになるか、「起動時間制限」に達する（トランザクション

一貫性保守またはトランザクションログ）と、バッファーはトランザクションログファイルに書き込まれ（フ

ラッシュされ）ます。

表 34 トランザクションログとトランザクション一貫性保守：機能

機能ログバッファーをディスクに書き込むタイミング

トランザクションログログバッファーがいっぱいになったとき、または［起動時間制限］の設定値に達したときに、

ログバッファーはログファイルに書き込まれます。各 End Transaction オペレーションの正常

終了を示すステータスコードは、ロガ－スレッドがバッファーをディスクにフラッシュする

ように指示されるとすぐにアプリケーションに返されます。

トランザクション一貫性保守 End Transaction オペレーションごとに、ログバッファーはトランザクションログファイルに

書き込まれます。各 End Transaction オペレーションの正常終了を示すステータスコードは、

ログのディスク書き込みが正常終了するまでアプリケーションに返されません。トランザク

ションには含まれない Insert または Update オペレーションの場合は、ログバッファーがいっ

ぱいになったとき、または［起動時間制限］の設定値に達したときにログバッファーがログ

ファイルに書き込まれます。

135


トランザクションログの場合、エンジンがトランザクション終了のオペレーションを受け取り、ロガースレッド

にログバッファーをディスクにフラッシュする指示を出すことに成功した場合、エンジンはアプリケーションに

正常終了のステータスコードを返しトランザクションが開始します。トランザクション一貫性保守の場合、エン

ジンはロガースレッドがバッファーをディスクに書き込むことに成功したことを示すまで正常終了のステータ

スを返しません。

トランザクションログファイルセグメントは「トランザクションログのディレクトリ」に設定したロケーショ

ンに保存されます。ログセグメントは *.LOG という名前で、 00000001 から FFFFFFFF までのプレフィックスが

付きます。

メモトランザクションログまたはトランザクション一貫性保守が有効な場合、すべてのオペレーションは、

トランザクション内で行われたかどうかに関わらず、ログファイルに書き込まれます。ただし、トランザク

ション内で実行されたオペレーションのみがアトミックであることが保証されます。システム障害が発生し、

トランザクションログがロールフォワードされる場合、完了したトランザクションのみがデータファイル

にコミットされます。対応する End Transaction オペレーションを持たないオペレーションは拒否され、デー

タファイルにコミットされません。

ヒントデータベースの使用率が高い場合には、データファイルが存在するのとは物理的に異なるボリュー

ムにトランザクションログが保持されるようにシステムを構成する必要があります。一般的に高負荷の下で

は、単一ドライブで I/O 帯域幅を競う代わりに、ログファイルへの書き込みとデータファイルへの書き込み

を別々のドライブに分ける方がパフォーマンスがよくなります。全体的なディスク I/O は減少しませんが、

ロードはディスクコントローラー間で効率よく分散されます。

設定プロパティの［トランザクションログのディレクトリ］設定を使用して、トランザクションログのロ

ケーションを指定することができます。

システム障害の発生時期が、ログファイルが書き込まれた後で、コミットされたオペレーションがシステムトラ

ンザクション内でデータファイルにフラッシュされる前であれば、コミットされたオペレーションが失われるこ

とはありません。コミットされたオペレーションをフラッシュするには、影響を受けるファイルをシステム障害

後に開き、オペレーションを実行する必要があります。ファイルを開いてオペレーションの実行を試みると、シ

ステム障害の発生時点で影響を受けていたファイルにデータがロールフォワードされます。単にデータベースエンジンを再起動すると、ロールフォワードは呼び出されず、データの一貫性が保たれません。

メモロールフォワードされたファイルに関連付けられているログファイルは自動的に削除されません。こ

れは、ログファイルが 2 つ以上のデータファイルに関連付けられている可能性があるからです。

この機能により、個々のクライアントトランザクションは、成功を示すステータスコードをすばやく受け取るこ

とが可能になると同時に、複数のクライアントトランザクションをグループにまとめてデータファイルに順次書

き出すことでパフォーマンスが向上するという利点が得られます。

データベースサーバーのデータファイルが格納されているボリュームのディスクに障害が発生し、アーカイブ

ログからデータを復元する必要がある場合、エンジンはトランザクションログファイルをロールフォワードし

ません。アーカイブログにはトランザクションログのすべてのオペレーションが含まれているため、トランザク

ションログをロールフォワードする必要がありません。

ヒントシステム障害後、すべてのデータファイルを開き、それらのファイルに対して Stat オペレーション

または読み取りオペレーションを実行してください。すべてのデータが復元されていることを確認できたら、

古いログファイルは安全な場所に保管してもかまいません。

136


関連項目

詳細については、以下を参照してください。




137


アーカイブログおよび Continuous オペレーションについて

この製品は、オンラインバックアップおよびデータ被害復旧をサポートするための相互に排他的な 2 つの機能を

提供します。

アーカイブログを使用すると、後のバックアップ以降のデータベースオペレーションのログを保存すること

ができます。システム障害が発生した場合、バックアップからデータファイルを復元し、ログファイルから変更

をロールフォワードして、システムをシステム障害発生前の状態に戻すことができます。

注意アーカイブロギングは、アーカイブログからの復元後、すべてのデータファイルが一貫性のある状

態になることを保証しません。速度向上のために、データベースエンジンはログ関数から成功を示すステー

タスコードが返されるのを待たずに、ログバッファーを空にします。そのため、ディスクフルやオペレー

ティングシステムの書き込みエラーなどのめったに起こらない状況において、データファイルで正常に行わ

れた更新がアーカイブログに記録されないことがあります。また、アーカイブログではすべてのファイルの

ログをとる必要がないため、複数のファイルの更新を行うトランザクションがあるとき、そのうち一部のファ

イルのログしかアーカイブしていない場合は、トランザクションがアーカイブログに完全に記録されないこ

とがあります。結果として、あるファイルがほかのファイルと矛盾する可能性があります。トランザクショ

ンを使用しており、複数ファイルのトランザクションアトミシティが必要な場合は、「トランザクションログおよびトランザクション一貫性保守」を参照してください。

Continuous オペレーションを使用すると、データベースエンジンが実行中でユーザーが接続中でもデータベー

スファイルのバックアップを行うことができます。Continuous オペレーションの開始後、データベースエンジン

はアクティブなデータファイルを閉じ、すべての変更をテンポラリデータファイル（デルタファイルと呼びま

す）に格納します。 Continuous オペレーションが機能している間に、データファイルのバックアップを実行しま

す。バックアップ中にデータファイルに対して行われた変更はすべてデルタファイルに記録されます。

バックアップが完了したら、Continuous オペレーションを解除します。データベースエンジンはデルタファイル

を読み込み、元のデータファイルにすべての変更を適用します。このデルタファイルは、 Continuous オペレー

ション中に多くの変更が行われた場合、元のデータファイルのサイズを超えることがあります。

Continuous オペレーションが設定されているデータファイルは、リレーショナルインターフェイスからトランザ

クショナルインターフェイスに至るまで削除が行えません。さらに、このファイルはキーの変更などファイル構

造の変更も受け付けません。

メモアーカイブログおよび Continuous オペレーションは相互に排他的な機能で、同時に使用することはで

きません。

アーカイブログとトランザクションログの違い

トランザクションログは、システム障害時のデータの完全性を守るためにデザインされたもう 1 つの機能です

が、アーカイブログとは直接関連を持ちません。トランザクションログは、アーカイブログまたは Continuousオペレーションのいずれかと同時に機能させることができます。トランザクションログは、短期間のログファイ

ルを使用して、トランザクションが確実にディスクに書き込まれるようにします。トランザクションログは、シ

ステムトランザクションのために、完了したクライアントトランザクションが物理データファイルへ移行する

ときに、頻繁にリセットされます。システム障害が発生すると、データベースエンジンが再起動されたときにト

状況 ... 使用する機能

バックアップ実行中もデータベースアプリケーションを実行し続ける必要がある。 Continuous オペレーション

バックアップを実行するのにエンジンをシャットダウンすることができる。アーカイブログ

138

アーカイブログおよび Continuous オペレーションについて

ランザクションログを読み込み、システム障害より前に完了していたトランザクションをデータファイルにいっ

きに移します。

アーカイブログは、各システムトランザクションの完了時に書き込まれるので、システムトランザクション中

にシステム障害が起こらない限り、アーカイブログおよびトランザクションログは適切に同期しています。

トランザクションログの詳細については、「トランザクションログおよびトランザクション一貫性保守」を参照


ファイルの復元が必要になったら

バックアップからデータファイルを復元する必要のあるシステム障害が発生した場合、アーカイブログを使って

バックアップから復元してデータベースの動作状態をシステム障害の時点に回復することができます。

アーカイブログを使用せずに同様の障害が起きた場合（たとえば、バックアップの実行に Continuous オペレー

ションを使用していた場合）、後のバックアップからシステム障害の間のデータベースの動作を回復することは

できません。

この章では、これ以降、アーカイブログおよび Continuous オペレーションに関連するオプションと手順について

説明します。

表 35 システム障害後のデータ回復の限界

アーカイブログ ... 障害後に回復できないデータ

オン障害時に未完了のトランザクション

オフデータファイルの後のバックアップ以降に起きたすべてのデータベース

オペレーション

139


アーカイブログの使用

このセクションでは、アーカイブログの設定、データファイルのバックアップおよび復元を行う方法について説

明します。この章は、以下のトピックに分かれています。

「全般的な手順」

「アーカイブログの設定」

「ロールフォワードコマンド」

全般的な手順

アーカイブログが適切に動作するためには、明確に定義された手順に従って設定する必要があり、バックアップ

からの復元が必要になった場合には別の手順が必要です。

注意この手順のいずれかの段階が省かれたり、十分でない場合、障害発生前の状態にデータを復元するこ

とができません。

アーカイブログを適切に使用するには

1 まだ動作していない場合は、アーカイブログをオンにします。設定の詳細については「アーカイブログの設

定」を参照してください。

2 データベースエンジンをシャットダウンします。

3 データファイルをバックアップします。

4 バックアップに成功したら、既存のアーカイブログをすべて削除します。

注意データファイルでの作業再開前にそれぞれのログファイルを削除します。バックアップデータファ

イルとそのログファイルが同期していることは、回復作業を成功させるための重要事項です。

5 データベースエンジンを再起動します。

バックアップからデータファイルを復元し、アーカイブログの変更を適用するには

メモハードディスクがクラッシュし、アーカイブログおよびデータファイルの両方がそのディスク上に

あった場合は、この手順でアーカイブログをロールフォワードすることはできません。

1 システム障害後コンピューターを再起動したら、データベースエンジンが実行中でないことを確認し、復元

しようとしているデータファイルにほかのデータベースエンジンがアクセスしていないことを確認してく

ださい。

2 バックアップからデータファイルを復元します。

3 データベースエンジンを起動し、どのようなアプリケーションもエンジンに接続していないことを確認しま

す。

注意アーカイブログがデータファイルに適用される前にデータベースアクセスが行われないようにする

ことは重要です。ほかのデータベースエンジンがファイルにアクセスしていないことを確認してください。

システム障害にあったのと同じエンジンを使用してアーカイブログをロールフォワードする必要がありま

す。

140


4 「ロールフォワードコマンド」に説明されているロールフォワードコマンドを発行します。

5 ロールフォワードが正常に完了したら、データベースエンジンを停止し、データファイルの新しいバック

アップを作成します。

6 データファイルが正常にバックアップできたら、アーカイブログファイルを削除します。これで、データ

ベースエンジンを再起動し、アプリケーションがデータファイルにアクセスできます。

アーカイブログの設定

アーカイブログの設定には 2 つの段階があります。

アーカイブログ機能を有効にする

アーカイブするファイルとそれぞれのログファイルを指定する

メモこれらの処理を行うには、データベースエンジンが起動しているコンピューターに対し管理者権限を

持っているか、データベースエンジンが起動しているコンピューター上の Pervasive_Admin グループのメン

バーである必要があります。

アーカイブログを有効にするには

1 オペレーティングシステムの［スタート］メニューまたはアプリ画面から Control Center にアクセスします。



3 アーカイブログを指定するデータベースエンジンを右クリックします。


5 ツリー内で［データ整合性］をクリックし、そのカテゴリに含まれるオプションの設定内容を表示します。

6 ［選択ファイルのアーカイブロギング］チェックボックスをクリックします。


設定を有効にするにはエンジンの再起動が必要であることを知らせるメッセージが表示されます。

8 ［はい］をクリックして、エンジンを再起動します。

アーカイブするファイルを指定するには

アーカイブログを実行するファイルは、そのファイルを含むボリュームに作成したアーカイブログ設定ファイル

に、エントリを追加することによって指定します。設定ファイルは、以下の方法で設定します。

1 ログを行う対象のデータファイルが存在する物理ドライブのルートディレクトリに、 \BLOG ディレクトリ

を作成します。（マップされたルートディレクトリは使用しないでください）。ファイルが複数のボリューム

に分かれている場合は、その各ボリュームに \BLOG ディレクトリを作成します。

たとえば、 C:\ および D:\ にデータファイルが存在し、どちらのドライブもデータベースと同じコンピュー

ター上に存在する物理ドライブである場合、次のように 2 つの BLOG ディレクトリを作成します。

C:\BLOG\

D:\BLOG\

メモ Linux では、ログディレクトリの名前は blog で、PVSW_ROOT 環境変数で指定したディレクトリ（デ

フォルトでは /usr/local/psql）に作成する必要があります。

141


2 各 \BLOG ディレクトリに、空の BLOG.CFG ファイルを作成します。 BLOG.CFG の作成には、メモ帳のよう

な任意のテキストエディターを使用してください。 Linux では、ファイルは blog.cfg （小文字）である必

要があります。

3 各 BLOG.CFG ファイルに、そのドライブ上にあるアーカイブログを実行するデータファイルのエントリを

入力します。エントリの入力には、以下の形式を使用します。

\ パス 1\ データファイル 1[=\ パス 2\ ログファイル 1]

エントリにはスペースを使用せず、 1 行以内に収める必要があります。（各行大で半角 256 文字）余裕があ

れば同一行に複数のエントリを置くことができます。エントリはスペースで区切ります。

注意ログをとるデータファイルすべてに異なるログファイルを使用する必要があります。 2 つ以上のデー

タファイルに同一のログファイルを使用すると、 MicroKernel はロールフォワードが必要になったときにそ

のログファイルを使用できません。

ログファイルの名前を入力しない場合は、ログファイルを初に開いた際に、元のファイル名に拡張子 .LOGを付けたファイル名が割り当てられます。たとえば、ファイル B.BTR では、ログファイルに B.LOG が割り

当てられます。

注意データベースのすべてのファイルのログをとる必要はありません。ただし、データベースに参照整合

性（RI）規則が指定されている場合は、各 RI の関係に含まれるすべてのファイルのログを指定するかまたは

1 つも指定しないでください。 RI の関係に含まれるファイルのサブセットのみのログを指定すると、システ

ム障害後にアーカイブログをロールフォワードするとき、 RI 規則違反となります。

例

以下は、ドライブ C 上にある BLOG.CFG のエントリの例です。すべてのエントリは、同じ結果になります。

C:\DATA\B.BTI の処理は、 C:\DATA\B.LOG に記録されます。

\data\b.bti

\data\b.bti=\data\b.log

\data\b.bti=c:\data\b.log

次の例では、 C:\DATA\B.BTI の処理が、ログファイル D:\DATA\B.LGF に記録されます。これは、アーカイブ

ログファイルが、データファイルと同じドライブ上に存在する必要がなく、拡張子が「.LOG」である必要もな

いことを表します（拡張子「.LOG」はデフォルト）。

\data\b.bti=d:\data\b.lgf

パス 1 ログを行う対象のデータファイルのパス。パスには、ドライブ名は含めません。

データファイル 1 ログを行う対象のデータファイルの名前。

パス 2 ログファイルのパス。ログファイルとデータファイルは、異なるドライブ上に存在する場合があ

るため、必要に応じてパスにドライブ名を追加します。

ログファイル 1 ログファイルの名前。名前を指定しない場合、デフォルト値はデータファイルと同じディレクト

リとファイル名ですが、拡張子は ".log" に置き換えられます。ログとデータファイルを同じドライ

ブに置かないように、異なる物理ドライブを指定することができます。ログをとるデータファイ

ルごとに別々のログファイルが必要です。

142


ヒント同じコンピューターの異なる物理ドライブにログを書き込むことをお勧めします。ログファイルを

異なる物理ドライブに置けば、ハードディスクがクラッシュした場合にデータファイルといっしょにログ

ファイルも失うことを防げます。

次に、 MicroKernel が複数のファイルのログを異なるドライブ（ドライブ D:）に作成するようにする BLOG.CFGの例を示します。 BLOG.CFG ファイルはドライブ C: にあるものとします。

\data\file1.mkd=d:\backup\

\data\file2.mkd=d:\backup\file2.log

\data\file3.mkd=d:\backup\file3.log

ロールフォワードコマンド

Btrieve Maintenance ユーティリティ（GUI またはコマンドラインの BUTIL）は、アーカイブログファイルをデー

タファイルにロールフォワードするコマンドを提供します。「アーカイブログの使用」を参照してください。

143


Continuous オペレーションの使用

Continuous オペレーションは、データベースアプリケーションが実行中でユーザーが接続されている間にデータ

ファイルのバックアップを行う機能を提供します。ただし、ハードドライブ障害の場合、 Continuous オペレー

ションを使用してバックアップを作成していた場合には、後のバックアップ移行のデータの変更はすべて失わ

れます。アーカイブログおよび Maintenance ユーティリティのロールフォワードコマンドを使用して終バック

アップ後に起こったデータファイルへの変更を復元することはできません。

Pervasive PSQL には Continuous オペレーションのためのバックアップコマンド BUTIL があります（また、

Pervasive PSQL は製品として Pervasive Backup Agent を提供し、 Continuous オペレーションを設定および管理しま

す。詳細については、その製品で提供されるマニュアル『Pervasive Backup Agent Guide』を参照してください）。

メモ Continuous オペレーションが設定されているデータファイルは、リレーショナルインターフェイスか

らトランザクショナルインターフェイスに至るまで削除が行えません。さらに、このファイルはキーの変更

などファイル構造の変更も受け付けません。

このセクションは、以下のトピックに分かれています。

「Continuous オペレーションの開始と停止」

「BUTIL を使用してデータベースのバックアップを行う」

「Continuous オペレーション使用時のデータファイルの復元」

Continuous オペレーションの開始と停止

このセクションでは、「STARTBU」および「ENDBU」コマンドの詳細について説明します。

注意 Continuous オペレーションモードによって作成されたテンポラリデルタファイルは対応するデータ

ファイルと同じ名前ですが、拡張子 ".^^^" を使用します。同じディレクトリに、ファイル名が同一で拡張子

のみが異なるようなファイルを置かないでください。たとえば、データファイルに INVOICE.HDR および

INVOICE.DET というような名前の付け方をしないでください。もしそうした場合、 MicroKernel はステータ

スを返し、ファイルは Continuous オペレーションに入れられません。

Continuous オペレーションモードは、 MicroKernel のパフォーマンスにほとんど影響を与えませんが、ファイル

のバックアップにサーバーを使用した場合は、影響が出ることがあります。

Continuous オペレーションを使用してデータの消失を防止するには

1 STARTBU コマンドを使用し、ファイルに Continuous オペレーションを適用します。 butil のコマンド構文の

説明については、「STARTBU」を参照してください。

2 データファイルをバックアップします。

表 36 Continuous オペレーションの開始と停止を行うコマンド

コマンド説明

「STARTBU」バックアップを対象として定義されたファイルの Continuous オペレーション

を開始します。（BUTIL）

「ENDBU」バックアップを対象として定義されたファイルの Continuous オペレーション

を停止します。（BUTIL）

144


3 ENDBU コマンドを使用し、ファイルに対する Continuous オペレーションを解除します。 butil のコマンド構

文の説明については、「ENDBU」を参照してください。

BUTIL を使用してデータベースのバックアップを行う

このセクションでは、 butil コマンドの「STARTBU」および「ENDBU」を使用したデータベースのバックアップ

に関する詳細について説明します。

STARTBU

butil STARTBU コマンドは、バックアップの目的でファイル（複数可）の Continuous オペレーションを開始します。

形式

butil -startbu <sourceFile | @listFile> [/UID<name> </PWD<word>> [/DB<name>]]

メモこの startbu コマンドは、指定したファイルのみに対して Continuous オペレーションを開始します。

startbu コマンドでは、ワイルドカードは使用できません。

Linux ディストリビューションの場合、すべての "/" パラメーターはスラッシュの代わりにハイフン（"-"）を使用します。たとえば、 /DB パラメーターは -DB です。

ファイルに関する考慮点

バックアップ対象のファイルを選択する場合、 Continuous オペレーションモードによって作成されるテンポラリ

デルタファイルは除外することをお勧めします。これらのファイルは、バックアップ時に開かれ使用中だからで

す。デルタファイルがバックアップに含まれる場合、データの復元後、これらのファイルはデータベースエンジ

ンが起動する前に削除しておく必要があります。

sourceFile バックアップのために Continuous オペレーションを開始するデータファイルのフルパス名（Windowsプラットフォームのドライブ指定を含む）。

この完全に修飾された名前は、butil を実行しているのと同じマシン上に存在している必要があります。

STARTBU コマンドではマップドライブは使用できません。

listFile Continuous オペレーションを開始するファイルの、フルパス名を含むテキストファイルの名前。これ

らのファイル名は、キャリッジリターン / ラインフィードで区切ります。ファイル名は、スペースで

区切ることもできますが、 Pervasive PSQL の新しいバージョンでは、ファイル名にスペース文字が使

用できるようになる可能性もあるため、 Pervasive PSQL の将来のバージョンとの互換性を保つために、

区切り文字にはキャリッジリターン / ラインフィードを使用してください。

指定したすべてのファイルを対象に Continuous オペレーションを行えない場合、ユーティリティによ

るファイルへの Continuous オペレーションは一切行われません。

/UID<name>/UIDuname

セキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定しま

す。

/PWD<word>/PWDpword

uname で識別されるユーザーのパスワードを指定します。 uname が指定された場合、 pword は必ず指定


/DB<name>/DBdbname

セキュリティが設定されたデータベース名を指定します。省略した場合はデフォルトのデータベース

と解釈されます。

145


Windows サーバーの例

例 A 初の例は、 COURSE.MKD の Continuous オペレーションを開始します。

Windows サーバーの場合

butil -startbu file_path\PSQL\Demodata\course.mkd


例 B 以下の例は、STARTLST.FIL にリストされているすべてのファイルに対して Continuous オペレーションを開

始します。

butil -startbu @startlst.fil

STARTLST.FIL は、以下のようなエントリで構成されます。

file_path\PSQL\Demodata\course.mkdfile_path\PSQL\Demodata\tuition.mkdfile_path\PSQL\Demodata\dept.mkd

ENDBU

ENDBU コマンドは、バックアップのために事前に定義したデータファイル（複数可）に対する Continuous オペ

レーションを終了します。このコマンドは、 startbu コマンドを使用して Continuous オペレーションを開始し、

バックアップを実行した後に使用します。

形式

butil -endbu </A | sourceFile | @listFile> [/UID<name> </PWD<word>> [/DB<name>]]

/A /A を指定した場合は、 startbu で初期化され、現在 Continuous オペレーションモードにあるすべての

データファイルに対する Continuous オペレーションが停止します。

sourceFile Continuous オペレーションを終了するデータファイルのフルパス名（Windows プラットフォームのド

ライブ指定を含む）。

この完全に修飾された名前は、 butil を実行しているのと同じマシン上に存在している必要があります。

endbu コマンドではマップドライブは使用できません。

@listFile Continuous オペレーションを終了するデータファイル名のリストを含むテキストファイルの名前。こ

のテキストファイルには、各データファイルのフルパス名が、キャリッジリターン / ラインフィード

で区切られて入力されている必要があります。ファイル名は、スペースで区切ることもできますが、

Pervasive PSQL の新しいバージョンでは、ファイル名にスペース文字が使用できるようになる可能性も

あるため、Pervasive PSQL の将来のバージョンとの互換性を保つために、区切り文字にはキャリッジリターン / ラインフィードを使用してください。

通常、このデータファイルのリストは、「STARTBU」コマンドで使用するリストと同じものになります。

/UID<name>/UIDuname

セキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定しま

す。

/PWD<word>/PWDpword

uname で識別されるユーザーのパスワードを指定します。 uname が指定された場合、 pword は必ず指定


/DB<name>/DBdbname

セキュリティが設定されたデータベース名を指定します。省略した場合はデフォルトのデータベースと

解釈されます。

146


メモ Linux ディストリビューションの場合、すべての "/" パラメーターはスラッシュの代わりにハイフン（"-"）を使用します。たとえば、 /A パラメーターは -A で、 butil -endbu -A のようになります。

Windows サーバーの例

以下の例では、 COURSE.MKD の Continuous オペレーションを終了します。

butil -endbu file_path\PSQL\Demodata\course.mkd

ここでは、現在のディレクトリが f:\demodata の場合、フルパスを省略して butil -endbu course.mkd とすることもできます。

Continuous オペレーション使用時のデータファイルの復元

バックアップの方法として Continuous オペレーションを使用している場合、後のバックアップ以降の変更を回

復するためのリカバリログはありません。後のバックアップ以後のデータベースの変更はすべて失われます

が、残っている可能性があるのは、トランザクションログに残されたトランザクションだけです。このようなト

ランザクションは、データベースエンジンの再起動時に自動的にロールフォワードされます。

データとデータベースオペレーションを復元するには

1 エラーを解決します。

障害が起きたコンピューターを再起動するのに必要な保守を行います。

2 バックアップからデータファイルを復元するか、バックアップからハードドライブイメージを復元するか

適切な方法をとります。

3 ディスクイメージの一部として Pervasive PSQL が復元されなかった場合は、再インストールします。

注意デルタファイルがバックアップファイルに含まれる場合、これらのファイルは、次の手順でデータ

ベースエンジンが起動する前に削除しておく必要があります。

4 データベースエンジンを再起動します。

後のバックアップ以後に実行されたデータベースオペレーションを再度実行する必要があります。

147


Backup Agent および VSS Writer によるデータバックアップ

この章で今まで説明されてきたトピックに加え、 Pervasive PSQL Server SP2 および Pervasive PSQL Vx Server では

データのバックアップに対して以下のソリューションも適用します。

「Pervasive Backup Agent」

「Pervasive PSQL VSS Writer」

ご自分のバックアップソフトウェアが Microsoft のボリュームシャドウコピーサービス（VSS）を認識しない場

合は、Pervasive Backup Agent をご自分のバックアップソフトウェアと連携して使用することができます。VSS フレームワークは Windows Server 2003 以上のオペレーティングシステムに含まれています。

バックアップソフトウェアが VSS を認識する場合は、 VSS によるバックアップ時に Pervasive PSQL VSS Writerが自動的に起動します。バックアップソフトウェアが既に VSS を認識している場合は、 Pervasive Backup Agentを使用する必要はありません。

Pervasive Backup Agent および Pervasive PSQL VSS Writer は併用できますが、それに伴う利点は特にありません。

どちらか一方の方法を選択すれば、バックアップ処理はより簡潔になります。

Pervasive Backup AgentPervasive Backup Agent は Pervasive PSQL v11 SP3 Server に含まれるオプション製品です。 Pervasive Backup Agent はPervasive PSQL Workgroup には含まれていません。 Backup Agent は単独製品として購入できるよう提供していま

すので、 Pervasive PSQL Workgroup でも使用することができます。

Pervasive Backup Agent はデフォルトではインストールされません。 Pervasive PSQL Server のインストール後に、

Pervasive PSQL v11 SP3 のメディアからインストールする必要があります。インストール選択ダイアログで

Pervasive Backup Agent を選択してください。

Pervasive PSQL v11 SP3 Server がインストールされている同じマシンに Pervasive Backup Agent v3.1 をインストー

ルする場合、別個のライセンスは必要ありません。これは、 Pervasive PSQL v11 Server または v11 SP1 Server をPervasive PSQL v11 SP3 Server にアップグレードする場合にも適用されます。

Pervasive Backup Agent を使用すれば、Pervasive PSQL データベースファイルに対する Continuous オペレーション

の設定と管理を簡単かつ迅速に行うことができます。 Continuous オペレーションの設定と管理は、Pervasive PSQLデータベースのバックアップを行う際の重要な部分です。これには Microsoft のボリュームシャドウコピーサー

ビス（VSS）を使用しません。 Backup Agent は開いているファイルに対する Continuous オペレーションの設定と

管理を処理し、バックアップ中でもアプリケーションからデータを利用できるようにします。バックアップ作業

が完了すると、 Backup Agent は自動的に Continuous オペレーションからファイルを取り出し、バックアップ中に

キャプチャされたすべての変更をロールインします。

Pervasive Backup Agent は、市販されている多くのバックアップアプリケーションと互換性があります。そのバッ

クアップアプリケーションでは、ほかのアプリケーションを開始および停止できるコマンドを発行できる必要が

あります（そのコマンドで Pervasive Backup Agent を開始および停止できます）。

Pervasive Backup Agent の詳細については、『Pervasive Backup Agent Guide』を参照してください。これは弊社 Webサイト（http://www.agtech.co.jp/download/manual/）から入手可能です。

Pervasive PSQL VSS WriterMicrosoft のボリュームシャドウコピーサービス（VSS）は、ライター、プロバイダーおよびリクエスターコン

ポーネントで構成されています。 Pervasive PSQL v11 SP3 はライターコンポーネントである Pervasive PSQL VSSWriter のみで VSS をサポートします。

Pervasive PSQL VSS Writer はデータベースエンジンの機能であり、 Pervasive PSQL v11 SP3 Server で使用可能で

す。 Pervasive PSQL VSS Writer は、この製品のインストール後に使用できるようになります。 Pervasive PSQL VSSWriter は現時点で Pervasive PSQL Workgroup では使用できません。

Pervasive PSQL VSS Writer は Windows オペレーティングシステムでのみ使用可能です。ボリュームシャドウコピーサービスの詳細については、 Microsoft Web サイトのテクニカルドキュメント「SQL Server バックアップアプリケーションベンダ向けガイド」を参照してください。

148

http://www.agtech.co.jp/download/manual/

Backup Agent および VSS Writer によるデータバックアップ

概要

VSS によるスナップショット時、 Pervasive PSQL VSS Writer は Pervasive PSQL データおよびトランザクションログファイルすべてに対し、それらが存在するボリュームに関係なく、すべてのディスク I/O 書き込み動作を停止

します。スナップショットの作成後、 Pervasive PSQL VSS Writer はすべてのディスク I/O を再開させます。これ

には停止中に遅延された書き込みも含まれます。

Pervasive PSQL VSS Writer はディスク I/O 読み取り動作を停止することはありません。書き込みが不要である限

り停止中に通常のデータベース処理を継続させることができます。 Pervasive PSQL VSS Writer は、 VSS サービス

および VSS リクエスターのバックアップ動作によりパフォーマンスが低下するかもしれませんが、バックアップ

フェーズ時は正常に動作します。

Microsoft ボリュームシャドウコピー機能を使用すれば、バックアップおよび復元製品はバックアップ用にシャ

ドウコピーを作成することができます。それに含まれるファイルは次のいずれかの状態になります。

1 定義済みで、かつ整合状態にある

2 "crash-consistent state" （クリーンリストアに適さない可能性があります）

以下の条件をすべて満たせば、 VSS スナップショットのファイルは定義済み、かつ整合性のとれた状態になりま

す。

1 ファイルのライターが VSS 対応である

2 バックアップおよび復元製品が VSS 対応ライターを認識し、そのライターにスナップショットの準備を通知

する

3 VSS 対応ライターはスナップショットの準備に成功する

条件を満たさない場合、ライターのファイルは "crash-consistent state" でバックアップされます。

VSS Writer の詳細

ここでは、 Pervasive PSQL VSS Writer の仕様について説明します。

サポートされるオペレーティングシステム

Pervasive PSQL Server 製品がサポートされる Windows オペレーティングシステムは Pervasive PSQL VSSWriter もサポートします。 VSS フレームワークは Windows Server 2003 以上のオペレーティングシステムに

含まれています。

Pervasive PSQL VSS Writer は、マシンのオペレーティングシステムおよびインストールされている PervasivePSQL Server 製品と同じビット数に対応して機能します。Pervasive PSQL VSS Writer の 32 ビット版は 32 ビッ

トマシンのみでサポートされ、 64 ビット版は 64 ビットマシンのみでサポートされます。ビット数が一致し

ない場合、 Pervasive PSQL は正しく機能しますが VSS Writer は利用できません。

サポートされるバックアップの種類

Pervasive PSQL VSS Writer はデータボリュームの手動バックアップまたは自動バックアップをサポートしま

す。Pervasive PSQL VSS Writer は完全ボリュームバックアップおよびコピーボリュームバックアップに対応

し、増分、差分およびログバックアップはサポートされません。 VSS は Pervasive PSQL VSS Writer をコン

ポーネントとして認識します。ただし、Pervasive PSQL VSS Writer はコンポーネントのバックアップをサポー

トしません。VSS リクエスターがコンポーネントのバックアップで Pervasive PSQL VSS Writer を呼び出すと、

VSS Writer は完全ボリュームバックアップまたはコピーボリュームバックアップでの同じアクションを実

行します。

仮想化環境のサポート

Pervasive PSQL VSS Writer は仮想化環境で VSS バックアップをトリガーする VSS リクエスターをサポートし

ます。仮想マシンのスナップショットを実行しても VSS バックアップは起動しません。

マルチボリューム Pervasive PSQL データファイル

149


Pervasive PSQL ファイルおよびトランザクションログが複数のボリューム上に存在することもあります。

Pervasive PSQL ファイルをバックアップする場合、ほかのボリューム上にあるトランザクションログと関連

ファイルは同時にバックアップすることを覚えておいてください。互いに独立しているファイルは、関連す

る Pervasive PSQL ファイルと同時にバックアップする必要はありません。

バックアップソリューションの互換性

特定のバックアップ製品が Pervasive PSQL VSS Writer を認識するかどうか、スナップショットの準備をライ

ターに通知するかどうかを判断するためには、その製品でバックアップを開始します。バックアップ処理の

進行中に、PVSW.LOG で PSQL VSS Writer が Frozen または Thawed 状態を記録するかどうかを調べます。バッ

クアップおよび復元製品が、バックアップの準備を PSQL VSS Writer へ通知しなかった場合は別のソリュー

ションを使用する必要があります。たとえば、 Pervasive PSQL Backup Agent を使用すれば PSQL データファ

イルを定義済み、かつ整合性のとれた状態でバックアップできます。

Pervasive PSQL VSS Writer と復元操作

バックアップソフトウェアで復元操作を実行する前に Pervasive PSQL サービスを停止してください。これを

行わないと、 VSS Writer が VSS リクエスターに対し、復元に参加できないことを通知します。データの整合

性を保証するためには、トランザクションログがデータファイルと共に復元される必要があります。

Pervasive PSQL が実行している間に Pervasive PSQL データとトランザクションログファイルが復元された場

合、その復元結果は予測不能でデータの破損を招く恐れがあります。

Pervasive PSQL VSS Writer および Pervasive Continuous オペレーション

もう既に Pervasive Continuous オペレーションまたは Pervasive Backup Agent を使用する既存のバックアップ

処理を利用されている場合もあるでしょう。そのバックアップ処理を Pervasive PSQL および Pervasive PSQLVSS Writer でも引き続き使用することができます。 Pervasive PSQL VSS Writer は Continuous オペレーション

や Backup Agent の機能を妨げることはありません。ただし、 Pervasive PSQL VSS Writer と Continuous オペ

レーション（または Backup Agent）を併用しても利点はありません。どちらか一方の方法を選択すれば、バッ

クアップ処理はより簡潔になります。

Pervasive PSQL VSS Writer が呼び出されたときにファイルが Continuous オペレーションモードに置かれてい

る場合、 VSS Writer はすべての Continuous オペレーションから独立して動作します。 VSS バックアップが進

行中にファイルが Continuous オペレーションモードに置かれた場合は、バックアップが完了した後に

PVSW.LOG を見てください。 Frozen および Thawed 状態が問題なく完了していること、またデータが定義済

みかつ整合状態にあることを確認してください。

Pervasive PSQL VSS Writer は Microsoft VSS フレームワークも必要とします。Backup Agent では Microsoft VSSフレームワークを使用しません。したがって、 Microsoft VSS フレームワークが Pervasive PSQL VSS Writer を呼び出し、 I/O 操作が停止された場合でも、 Backup Agent はバックアップに参加しません。 Backup Agent はバックアップ処理に個別に追加する必要があります。そのバックアップ処理は Backup Agent の開始と停止を

行う必要もあります。

Pervasive PSQL VSS Writer および Xtreme I/O ドライバー

32 ビット版の Pervasive PSQL VSS Writer は、 Pervasive PSQL Server 32 ビットおよびデータベースアクセラ

レータ Xtreme I/O （XIO）と併用できます。『Advanced Operations Guide』の「Xtreme I/O ドライバー」を参照


150

9
高可用性のサポート
可用性の高い環境での Pervasive PSQL の使用


「技術の概要」

「フェールオーバークラスタリング」

「マイグレーション」

「フォールトトレランス」

「障害回復」

151


技術の概要

Pervasive PSQL は、物理環境および仮想環境において稼働時間を大化する数々のソリューションと互換性があ

ります。そのようなソリューションは絶えず進化し続けていますが、通常、そのタイプは高可用性、フォールト

トレランスおよび障害回復に分類されます。

高可用性

「高可用性」の定義は、高可用性ソリューションを提供するソフトウェアベンダーによって異なる可能性があり

ます。一般的には、ハードウェア障害やソフトウェア障害、または必要なメンテナンスの発生にかかわらず、稼

働し続ける時間の基準レベルに対するシステム設計手法を指します。

物理環境において高可用性を保証するための一般的な手法はフェールオーバークラスタリングです。仮想マシン

環境において高可用性を保証するための一般的な手法はマイグレーション（移行）です。

フェールオーバークラスタリング

Pervasive PSQL はフェールオーバークラスター環境のリソースとして機能するよう設計されています。この環境

では一度に 1 つのサーバーノードのみが共有記憶域サブシステムにアクセスします。プライマリノードがエラー

になった場合は、セカンダリノードへのフェールオーバー（切り替え）が発生します。フェールオーバークラス

タリングを使用すると、ソフトウェアのアップグレードやハードウェアのメンテナンスの実行時にもシステムを

利用可能な状態にしておくことができます。

Pervasive PSQL は Microsoft フェールオーバークラスターサービスおよび Linux Heartbeat と互換性があります。

フェールオーバークラスタリングの定義および実装については、各ベンダーのドキュメントを参照してくださ

い。Pervasive PSQL Server は、フェールオーバークラスターが物理ノードを使用する場合に推奨される製品です。

Pervasive PSQL Vx Server は、仮想マシンノードを使用するクラスター用に推奨される製品です。

「フェールオーバークラスタリング」を参照してください。

マイグレーション

一般論として、マイグレーションとは、実行している仮想マシンまたはアプリケーションを、クライアントやア

プリケーションを切断することなく異なる物理マシン間で移動させることです。通常は、仮想マシンのメモリ、

記憶域およびネットワーク接続が移行先に移行されます。

Pervasive PSQL Vx Server は Microsoft Hyper-V、 VMware vSphere および Citrix XenServer で提供されるマイグレー

ション機能と互換性があります仮想 MAC アドレスとホスト名が仮想マシンの移動後も同じままであれば、PSQLVx Server は正常に動作し続けます。マイグレーションの定義および実装については、各ベンダーのドキュメント


「マイグレーション」を参照してください。

フォールトトレランス

高可用性が稼働時間の予測可能な基準レベルを目指すのに対し、フォールトトレランスはコンポーネントに障害

が発生してもシステムを中断することなく稼働させることを目的としています。フォールトトレランスでは同期

された共有記憶域が必要です。仮想化環境では、障害が発生した仮想マシンと、置き換わる仮想マシンは異なる

物理ホスト上に存在している必要があります。

フォールトトレランスは物理マシンのみを使用して実現します。ただし、仮想環境は、互いに足並みを揃えた仮

想サーバーを保持することが容易であるため、物理環境のみという状況は次第に少なくなっています。 PervasivePSQL Server は物理環境のみでのフォールトトレランス機能と互換性があります。

仮想環境の場合、Pervasive PSQL Vx Server は VMware vSphere や Citrix XenServer で提供されるフォールトトレラ

ンス機能と互換性があります。フォールトトレランスの定義および実装については、各ベンダーのドキュメント


「フォールトトレランス」を参照してください。

152

技術の概要

障害回復

障害回復では、大きな障害の発生後にコンピューター操作の復元が必要となります。通常、これには日常的なオ

フサイトのデータバックアップや新しい場所で主要な情報システムをアクティブ化する手続きが含まれます。

Pervasive PSQL Vx Server は、バックアップ物理マシンまたは仮想マシンを初期化する障害回復技術をサポートす

る主要なハイパーバイザーと互換性があります。すべての仮想 MAC アドレスとホスト名が仮想マシンの移動後

も同じままであれば、 PSQL Vx Server は正常に動作し続けます。これにより、短時間でのサーバー置換および回

復が可能です。Pervasive PSQL Server は、物理マシン上での障害回復技術をサポートする主要なハイパーバイザー

と互換性があります。

障害回復の定義および実装については、各ハイパーバイザーベンダーのドキュメントを参照してください。

障害回復のために Pervasive PSQL が提供するもう 1 つの機能は Pervasive PSQL Insurance です。 Pervasive PSQLInsurance を使用すれば、直ちにオンラインに戻し業務を続行することができます。その間に元の Pervasive PSQLライセンスを復元できます。 Pervasive PSQL Insurance は、 3 回の認証が可能で、 Windows および Linux の 32 ビッ

トまたは 64 ビット環境で利用可能な 14 日間限定の一時ライセンスを提供します。詳細については、 http://www.agtech.co.jp/products/pervasive/ をご覧ください。

「障害回復」を参照してください。

ハードウェア要件

このセクションで述べているすべての技術を利用する場合、 Pervasive Software では、ベンダーが提供するハード

ウェア互換性リストで挙げられているサーバー、ディスクサブシステムおよびネットワークコンポーネントを選

択することをお勧めします。 Pervasive Software でも、ベンダーの製品との互換性テストを行う際にはベンダー提

供のハードウェア要件に従っています。

153

http://www.agtech.co.jp/products/pervasive/




フェールオーバークラスタリングは、複数の物理サーバー（ノード）が、1 つ以上のファイル共有またはボリュー

ムを持つ、共通の共有記憶域サブシステムにアクセスする機能を提供します。このフェールオーバーサービスで

は、一度に 1 つのサーバーだけがファイル共有またはボリュームを制御します。共有記憶域サブシステムの制御

は、障害により停止したサーバーからクラスター内の次のスタンバイサーバーへ自動的に渡されます。

Pervasive PSQL はデータベースエンジンをインストールしたクラスターノード単位で個別にライセンスされて

いる必要があります。これはそのノードが物理マシンまたは仮想マシンのどちらでも同じです。『Pervasive PSQLUser's Guide』の「ライセンスモデル」も参照してください。（ここで説明しているフェールオーバークラスタリ

ングは、 Microsoft フェールオーバークラスタリングまたはクラスターサービス、および Linux Heartbeat を対象

としています。仮想マシンベースのクラスターを取り入れるようなその他の高可用性ソリューションとは異なり

ます）。


「Windows Server 2008 以上を対象とした Microsoft フェールオーバークラスタリング」

「Windows Server 2003 用の Microsoft Cluster Service」

「Linux Heartbeat」

「クラスター環境における Pervasive PSQL の管理」

Windows Server 2008 以上を対象とした Microsoft フェールオーバークラスタリング

ここではフェールオーバークラスタリングへの Pervasive PSQL サービスの追加について説明します。これは次の

ことを前提とします。

フェールオーバークラスタリングのインストールおよび構成方法を知っていること。また、 Pervasive PSQLサービスを追加および管理するための情報が必要であること。

Pervasive PSQL および Pervasive PSQL Control Center （PCC）などの主要ユーティリティの使用法をよく理解

していること。

ODBC アドミニストレーターを使用して DSN を設定できること。

Windows サーバーのバージョン間の違い

基本的に、フェールオーバークラスタリングは Windows Server 2008、 Windows Server 2008 R2 および WindowsServer 2012 で同じです。

Windows Server 2012 では次の点が異なることに留意してください。

フェールオーバークラスターマネージャーで、" サービスとアプリケーション " は " ロール " と呼ばれます。

レジストリレプリケーションは、汎用サービスにはサポートされません。「PCC を使ってデータベースエン

ジンのプロパティを設定する」で説明されているとおり、すべてのノードで Pervasive PSQL データベースエンジンが手動設定されている必要があります。

事前要件

Pervasive PSQL サービスを追加する前に、フェールオーバークラスタリングが正常に機能していることが必須で

す。たとえば、フェールオーバーを実行し、すべてのリソースが利用可能になっていることを確認してください。

この操作を、フェールオーバーを開始した初のノードに戻るまで繰り返し行います。フェールオーバークラス

タリングのセットアップ方法については、 Microsoft のドキュメントを参照してください。

ほかのサービスの場合と同様に、 Pervasive PSQL サービスを追加する前には必須のクラスタリングコンポーネン

トを設定します。コンポーネントを設定する際に、以下の点を確認してください。

154


Pervasive PSQL データを置く共有ディスクに対し、必要であれば NTFS ユーザー権限を編集します。通常、

Pervasive PSQL トランザクショナルおよびリレーショナルサービスは、ローカルシステムアカウント下で

実行されます。ローカルシステムアカウントには必ず共有ディスクへの読み取り / 書き込み権限を持たせる


共有プロトコルに "SMB" 選択し、必要であれば SMB 権限を編集します。

［DFS 名前空間への発行］を省略します。 Pervasive PSQL サービスに DFS は必要ありません。

コンポーネントを設定したら、 Pervasive PSQL クライアントをインストールしているマシンがクライアントアク

セスポイントと通信できることを検証するのが得策です。また、マシンが共有名を参照できることを確認してく

ださい。

推奨されるインストール手順

次の表では、 Windows Server 2008 のクラスターサービスに Pervasive PSQL を追加する際の推奨手順を説明して

います。 Windows Server 2012 向けの手順は基本的には同じですが、先に述べた相違点があります。

表 37 Windows Server 2008 以上のクラスターサービスへの Pervasive PSQL の追加

操作説明

クラスターノードへ

Pervasive PSQL をイン

ストールする

各クラスターノードに Pervasive PSQL Server をインストールし、それらすべてに同一のオプショ

ンを選択します。

Pervasive PSQL データが存在するクラスター共有記憶域には Pervasive PSQL をインストールし

ないでください。

XIO （Xtreme I/O）という Pervasive PSQL コンポーネントはインストールしないでください。マ

シンがフェールオーバーによってオンラインになり、共有記憶域をアクセスできないままにし

ておくと、ノードに XIO がインストールされている場合、そのノードがハングすることがあり

ます。

インストール後、 Pervasive PSQL トランザクショナルサービスとリレーショナルサービスは共に

オペレーティングシステムの起動時に自動的に開始されるよう設定されます。スタートアップの

種類を手動に変更します。

通常、 Pervasive PSQL トランザクショナルおよびリレーショナルサービスは、ローカルシステム

アカウント下で実行されます。 Pervasive PSQL のインストールで問題が起きた場合は、クラスター

ノードアカウントのドメインの権限を調べてください。

155


Pervasive PSQL 用のク

ラスターリソースを追

加し、プロパティを設

定する

クラスターリソースとして、Pervasive PSQL トランザクショナルサービスは必ず必要です。リレー

ショナルサービスはオプションで、アプリケーションがリレーショナルインターフェイスを使用

する場合のみ必要です。

クラスターリソース用のプロパティを指定する際は以下のことを実施してください。

［ネットワーク名をコンピューター名として使う］オプションを選択します。

トランザクショナルサービスの場合、ルートレジストリキーの Software\Pervasive Software を使用します。

リレーショナルサービスを含める場合は、レジストリキー用のデータソース名（DSN）の操作方

法を決定します。以下の手順のいずれかを実行します。

そのクラスターノードにインストールされているすべての ODBC データソースおよび ODBC プロバイダーに影響を与える場合は、 SOFTWARE\ODBC キーを指定します。オペレーティン

グシステムのアーキテクチャに応じて、以下のキーを追加します。

Software\ODBC\ODBC.INI （Windows 32 ビット用）または Software\Wow6432Node\ODBC\ODBC.INI （Windows 64 ビット用）

個別の DSN を指定する場合、レジストリでキーは追加しないでください。その代わり、初に

PCC でデータベースエンジンを設定する必要があります（「PCC を使ってデータベースエンジ

ンのプロパティを設定する」を参照）。その後、アクティブなクラスターノードに DSN を作成

し、障害を発生させて、同じ DSN をスタンバイノードに作成することが必要です。これを、す

べてのクラスターノードに DSN が含まれるまで繰り返します。

メモ：依存関係があるため、Pervasive PSQL リソースは初に Pervasive PSQL トランザクショナル

エンジン、次に Pervasive PSQL リレーショナルエンジンという順序でオンラインにし、停止する

場合はこの逆の順序で停止するようにしてください。

必要なファイルとディ

レクトリを共有記憶域

に置く

通常、 Pervasive PSQL トランザクショナルおよびリレーショナルサービスは、ローカルシステム

アカウント下で実行されます。ローカルシステムアカウントには必ず共有ディスクへの読み取り

/ 書き込み権限を持たせる必要があります。

Pervasive PSQL をインストールしたアクティブノードのアプリケーションデータ領域にある

DBNAMES.CFG ファイルを、共有記憶域上の任意のディレクトリにコピーします。

同じノード上のアプリケーションデータ領域にある以下のディレクトリを、共有記憶域上の同じ

ディレクトリにコピーします。便宜上、 DBNAMES.CFG と同じディレクトリにこれらをコピーで

きますが、別の場所でもかまいません。

defaultdb

Demodata

tempdb

Transaction Logs

Pervasive System Analyzer を使用してトランザクショナルテストまたはリレーショナルテストを行

う場合は、 Pervasive Software\PSQL\Samples ディレクトリもコピーする必要があります。


操作説明

156


Windows Server 2003 用の Microsoft Cluster Serviceここではフェールオーバークラスタリングへの Pervasive PSQL サービスの追加について説明します。これは次の

ことを前提とします。

クラスターサービスのインストールおよび構成方法を知っていること。また、 Pervasive PSQL をクラスター

サービスグループに追加するための情報が必要であること。



ODBC アドミニストレーターを使用して DSN を設定できること。

事前要件

Pervasive PSQL を追加する前に、クラスターサービスが正常に機能していることが必須です。たとえば、フェー

ルオーバーを実行し、すべてのリソースが利用可能になっていることを確認してください。この操作を、フェー

ルオーバーを開始した初のノードに戻るまで繰り返し行います。クラスターサービスの設定、動作確認、タス

クの実行方法の詳細については、 Microsoft のドキュメントを参照してください。

ほかのアプリケーションの場合と同様に、 Pervasive PSQL を追加する前には必須のクラスターコンポーネントを

設定します。コンポーネントを設定するときは、 Pervasive PSQL データを置く共有ディスクに対し、必要であれ

ばユーザー権限を編集します。通常、Pervasive PSQL トランザクショナルおよびリレーショナルサービスは、ロー

カルシステムアカウント下で実行されます。ローカルシステムアカウントには必ず共有ディスクへの読み取り

/ 書き込み権限を持たせる必要があります。

PCC を使ってデータ

ベースエンジンのプロ

パティを設定する

Pervasive PSQL Control Center （PCC）でデータベースエンジンを設定して、特定の構成設定をレジ

ストリに追加します。クラスター内のアクティブノードのエンジンを設定した後、障害を発生さ

せてクラスター内の次のノードにその設定を移行します。

PCC で、ディレクトリに関する以下のエンジンプロパティを設定します。 PCC でサービスの再開

始を促された場合は、［いいえ］を選択します。

［トランザクションログのディレクトリ］には、 Transaction Logs ディレクトリをコピーする共

有ディスク上の場所を指定します。

［DBNames 設定ファイルのディレクトリ］には、 DBNAMES.CFG ファイルをコピーする共有

ディスク上の場所を指定します。

フェールオーバークラスター管理コンソールで、 Pervasive PSQL リソースを一旦オフラインにし、

オンラインに戻します。

PCC で、データベースに関する以下のエンジンプロパティを設定します。

DEFAULTDB では、［辞書のロケーション］に、 DEFAULTDB ディレクトリをコピーする共有

ディスク上の場所を設定します。［データディレクトリ］では、 DEFAULTDB ディレクトリを

コピーする共有ディスク上の場所を追加し、デフォルトのデータディレクトリを削除します。

DEMODATA および TEMPDB データベース用の［辞書のロケーション］と［データディレク

トリ］には、それらのディレクトリをコピーする共有ディスク上の場所を設定します。

DEMODATA の場合、［辞書のロケーション］および［データディレクトリ］には "Demodata"を指定します。 TEMPDB の場合、［辞書のロケーション］および［データディレクトリ］には

"tempdb" を指定します。

データベースエンジン

の設定を移行する

データベースエンジンの設定をクラスター内のほかのノードへ移行します。フェールオーバークラスター管理コンソールで、サービスまたはアプリケーションの移動アクションを実行し、

Pervasive PSQL サービスをクラスター内の別のノードへ移動させます。

たとえば、フェールオーバーを実行し、すべてのリソースが利用可能になっていることを確認して

ください。サービスをさらに別のノードへ移動させ、すべてのリソースが利用可能であることを確

認します。この操作をフェールオーバーが初のノードに戻るまで行います。

これで、 Pervasive PSQL はフェールオーバークラスター用に構成されます。


操作説明

157


コンポーネントを設定したら、 Pervasive PSQL クライアントにアクセスし、クラスター共有記憶域と通信できる

ことを確認します。 Pervasive PSQL クライアントは、クラスターノードのフェールオーバーの前および後に、ク

ラスター共有記憶域と通信できる必要があります。フェールオーバーの前後で、 Pervasive PSQL クライアントコンピューターから共有記憶域サブシステム上でコマンドが実行できれば、クラスターは正常に機能しています。


次の表では、 Windows Server 2003 のクラスターサービスに Pervasive PSQL を追加する際の推奨手順を説明して

います。

表 38 Windows Server 2003 のクラスターサービスへの Pervasive PSQL の追加

操作説明

Pervasive PSQL 用のクラ

スターグループを追加

する

Microsoft クラスターアドミニストレーターで、 Pervasive PSQL リソースを追加するクラスター

グループを作成します。クラスターグループ内のリソースはすべて同時に失敗する（機能しな

くなる）ので、Pervasive PSQL 用に単独のクラスターグループを作成することをお勧めします。

これは必須ではありませんが、適切な管理手法です。

Pervasive PSQL のクラスターグループには、少なくとも以下のリソースが含まれるようにして

ください。

共有記憶域サブシステムの IP アドレス

ネットワーク名（共有記憶域サブシステムの名前）

物理ディスク（Pervasive PSQL データベースを含むディスクサブシステム）共有記憶域は

マップされたドライブではなく、マウントされたドライブにしてください。 Pervasive PSQLサービスはデフォルトで「ローカルシステムアカウント」に設定されます。このアカウン

トの場合、別のユーザーアカウントでマップしたマップドライブにはアクセスできません。

データーファイル用のファイル共有

さらに、グループに対してフェールバックを可能にしたり、優先する実稼働ノードを指定した

りすることができます。「Pervasive PSQL のエラー時の動作」も参照してください。

クラスターノードへ Pervasive PSQL をインス

トールする

各クラスターノードに Pervasive PSQL Server をインストールし、それらすべてに同一のオプ

ションを選択します。

Pervasive PSQL データが存在するクラスター共有記憶域には Pervasive PSQL をインストール

しないでください。

XIO （Xtreme I/O）という Pervasive PSQL コンポーネントはインストールしないでください。

マシンがフェールオーバーによってオンラインになり、共有記憶域をアクセスできないまま

にしておくと、ノードに XIO がインストールされている場合、そのノードがハングするこ

とがあります。

通常、 Pervasive PSQL トランザクショナルおよびリレーショナルサービスは、ローカルシステ

ムアカウント下で実行されます。 Pervasive PSQL のインストールで問題が起きた場合は、クラ

スターノードアカウントのドメインの権限を調べてください。

158


Pervasive PSQL トランザ

クショナルサービスを

クラスターグループに

追加する

クラスターリソースとして、 Pervasive PSQL トランザクショナルサービスは必ず必要です。

Microsoft クラスターアドミニストレーターで、新しいリソースを追加し、［リソースの種類］

に " 汎用サービス " を指定します。対象とするグループを選択します。［別のリソースモニター

でこのリソースを実行する］オプションはチェックしないでください。

リソースの実行可能な所有者として機能するノードを指定します。

依存関係用に、リソースの依存関係リストには以下の項目を追加してください。

IP アドレス

ネットワーク名

ファイル共有

［汎用サービスパラメーター］にはサービス名に "Pervasive.SQL (transactional)" を指定します。

［起動パラメーター］は空白のままにしておきます。［ネットワーク名をコンピューター名とし

て使う］オプションを選択します。これにより、 Pervasive PSQL は共有記憶域上でファイルを

直接開くことができます。

レジストリキーには、 "SOFTWARE\Pervasive Software" を追加します。

リソースを追加したら、そのプロパティを選択します。［再開する］オプションおよび［グルー

プに適用する］オプションが選択してください。オプションで、しきい値と期間を設定するこ

とができます。

任意で、 Pervasive PSQLリレーショナルサービ

スをクラスターグルー

プに追加する

リレーショナルサービスはオプションで、アプリケーションがリレーショナルインターフェイ

スを使用する場合のみ必要です。

次の例以外は、「Pervasive PSQL トランザクショナルサービスをクラスターグループに追加す

る」と同じ手順に従ってください。

依存関係用に、［利用できるリソース］リストで "Pervasive PSQL トランザクショナルリソース

" を選択します。リソースの IP アドレスおよびファイル共有はトランザクショナルリソースの

依存関係なので、これらを追加する必要はありません。

［汎用サービスパラメーター］にはサービス名に "Pervasive.SQL (relational)" を指定します。

レジストリのレプリケーションは、レジストリキー用のデータソース名（DSN）の操作方法を

決定します。以下の手順のいずれかを実行します。

そのクラスターノードにインストールされているすべての ODBC データソースおよび ODBC プロバイダーに影響を与える場合は、 SOFTWARE\ODBC キーを指定します。オペ

レーティングシステムのアーキテクチャに応じて、以下のキーを追加します。

Software\ODBC\ODBC.INI （Windows 32 ビット用）または Software\Wow6432Node\ODBC\ODBC.INI （Windows 64 ビット用）

個別の DSN を指定する場合、レジストリでキーは追加しないでください。その代わり、

初に PCC でデータベースエンジンを設定する必要があります（「PCC を使ったエンジンの

設定」を参照）。その後、アクティブなクラスターノードに DSN を作成し、障害を発生さ

せて、同じ DSN をスタンバイノードに作成することが必要です。これを、すべてのクラス

ターノードに DSN が含まれるまで繰り返します。

クラスターアドミニス

トレーターを使って

PSQL サービスをオンラ

インにする

インストール後、トランザクショナルおよびリレーショナルサービスは共にオペレーティング

システムの起動時に自動的に開始されるよう設定されます。オペレーティングシステムから、

両方のサービスを停止し、そのスタートアップの種類を手動に変更します。

オペレーティングシステムでサービスを停止した後、クラスターアドミニストレーターを使用

してそのサービスをオンラインにします。


操作説明

159


Linux HeartbeatHeartbeat プログラムは Linux-HA （High-Availability Linux Linux）プロジェクトの中心的なコンポーネントの 1 つです。 Heartbeat はあらゆる Linux プラットフォームで動作し、 1 つのプロセスで停止ノードの検出、通信および

クラスター管理を行います。 Pervasive PSQL Server は、 Heartbeat クラスターが物理ノードを使用する場合に推奨

される製品です。Pervasive PSQL Vx Server は、仮想マシンノードを使用するクラスター用に推奨される製品です。

ここでは Linux Heartbeat への Pervasive PSQL サービスの追加について説明します。これは次のことを前提としま

す。

Heartbeat プログラムのインストールおよび構成方法を知っていること。また、 Pervasive PSQL をクラスター

サービスグループに追加するための情報が必要であること。

必要なファイルとディレ

クトリを共有記憶域に置

く

通常、 Pervasive PSQL トランザクショナルおよびリレーショナルサービスは、ローカルシステ

ムアカウント下で実行されます。ローカルシステムアカウントには必ず共有ディスクへの読

み取り / 書き込み権限を持たせる必要があります。

Pervasive PSQL をインストールしたアクティブノードのアプリケーションデータ領域にある

DBNAMES.CFG ファイルを、共有記憶域上の任意のディレクトリにコピーします。

同じノード上のアプリケーションデータ領域にある以下のディレクトリを、共有記憶域上の同

じディレクトリにコピーします。便宜上、 DBNAMES.CFG と同じディレクトリにこれらをコ

ピーできますが、別の場所でもかまいません。

defaultdb

Demodata

tempdb

Transaction Logs

Pervasive System Analyzer を使用してトランザクショナルテストまたはリレーショナルテスト

を行う場合は、 Pervasive Software\PSQL\Samples ディレクトリもコピーする必要があります。

PCC を使ったエンジンの

設定

Pervasive PSQL Control Center （PCC）でデータベースエンジンを設定して、特定の構成設定を

レジストリに追加する必要があります。クラスター内のアクティブノードのエンジンを設定し

た後、障害を発生させてクラスター内の次のノードにその設定を移行します。

PCC の Pervasive PSQL エクスプローラーで新しいサーバーを作成し、そのサーバー名に対しク

ラスター共有記憶域のネットワーク名を指定します。

追加したサーバーのプロパティにアクセスし、［ディレクトリ］を選択します。

［DBNames 設定ファイルのディレクトリ］に、クラスター共有ドライブ上の場所を指定しま

す。これは手順「必要なファイルとディレクトリを共有記憶域に置く」でリストされたファ

イルをコピーした場所です。共有記憶域はマップされたドライブではなく、マウントされた

ドライブにしてください。 Pervasive PSQL サービスはデフォルトで「ローカルシステムアカウント」に設定されます。このアカウントの場合、別のユーザーアカウントでマップし

たマップドライブにはアクセスできません。

［トランザクションログのディレクトリ］に、クラスター共有ドライブ上の、ログを置きた

い場所を入力します。

［通信プロトコル］では、［TCP/IP マルチホーム］がオンになっていることを確認してくだ

さい。

クラスターアドミニストレーターで、Pervasive PSQL トランザクショナルサービスをオフライ

ンにすると、 Pervasive PSQL リレーショナルサービスもオフラインになります。両方のサービ

スをオンラインにします。

クラスターアドミニストレーターで、障害を発生させて次のスタンバイノードがクラスターの

新しい実稼動ノードになるようにします。この動作を繰り返して、すべてのクラスターノード

で障害を発生させます。

これで、 Pervasive PSQL はフェールオーバークラスター用に構成されます。


操作説明

160




事前要件

Pervasive PSQL をクラスターに追加する前に、 Linux Heartbeat が正常に機能していることが必須です。 Heartbeatのインストール、動作確認、タスクの実行方法については、「The High Availability Linux プロジェクト」（http://www.linux-ha.org/ja/HomePage_ja）ドキュメントを参照してください。

ほかのアプリケーションの場合と同様に、 Pervasive PSQL を追加する前には必須のクラスターコンポーネントを

設定します。


次の表では、 Linux Heartbeat に Pervasive PSQL を追加する際の推奨手順を説明しています。

表 39 Linux Heartbeat への Pervasive PSQL の追加

操作説明

クラスターノードへ Pervasive PSQL をインス

トールする

各クラスターノードに Pervasive PSQL Server をインストールし、それらすべてに同一のオプ

ションを選択します。 Pervasive PSQL データベースが存在するクラスター共有記憶域には

Pervasive PSQL をインストールしないでください。

インストールが完了すると、オペレーティングシステムの起動時にデータベースエンジンが自

動的に起動するよう設定されます。ただし、クラスタリングでは、Linux Heartbeat がデータベー

スエンジンの起動と停止を制御します。クラスターの実稼動ノードがエンジンを起動し、それ

以外のノードはエンジンを起動しません。

Pervasive PSQL Server をインストールしたら、 "pvsw" および "pvsw-adm" 用のグループ ID と "psql" 用のユーザー ID がすべてのノードにおいて一致していることを確認してください。 ID が一致していなければ、同一になるよう変更します。

共有記憶域を構成する共有記憶域は、 Pervasive PSQL データベースが存在する場所です。 Heartbeat の共有記憶域はさ

まざまな方法で実装できます。このマニュアルではその数多くの実装方法のすべてを説明する

ことはできません。このセクションでは、 NFS マウントが使用されていると仮定します。

共有記憶域上で、データベースを配置する場所を作成します。この場所は自由に選択できます。

ユーザー psql がその場所に対して読み取り、書き込みおよび実行権限を持っていることを確認


共有記憶域に 2 つのグループと 1 人のユーザーを作成し、各クラスターノードがデータベース

ファイルにアクセスできるようにします。

pvsw グループおよび pvsw-adm グループはそれぞれ、クラスターノード上の pvsw グループ

ID および pvsw-adm グループ ID と一致している必要があります。

ユーザー psql は、クラスターノード上の psql ユーザー ID と一致している必要があります。

共有記憶域マウント用の

ディレクトリを作成する

クラスターノードごとに、ユーザー psql としてログインし、共有記憶域へマウントされるディ

レクトリを作成します（ユーザー psql にはパスワードがありません。 su コマンドを使用した "root" アカウントによるアクセスのみを行うことができます）。ディレクトリ名は自由に選択で

きます。

Heartbeat サーバーを構成

する

Pervasive PSQL データベースエンジンを制御するノードごとに Heartbeat サーバーを構成しま

す。次のような構成を行います。

ノード。クラスターに参加させるすべてのノードを追加します。

認証。ノード間のネットワーク通信に使用する認証のタイプを指定します。

媒体。 Heartbeat がノード間の内部的な通信に使用する方法を指定します。

スタートアップ。Heartbeat サーバーの起動のタイミングについての設定を指定します。これ

をオンに設定すると、 Heartbeat サーバーはブート時に起動するようになります。

161


Heartbeat ユーザーのパス

ワードを割り当てる

Linux Heartbeat では Heartbeat Management Client へログインする際のデフォルトのユーザー名と

して hacluster を提供します。 Heartbeat Management Client を実行するノードごとに、ユーザー

hacluster のパスワードを割り当てます。

Pervasive PSQL 用のリ

ソースグループを追加す

る

root としてログインし、クラスターノードの 1 つで Heartbeat Management Client を開始します。

ユーザー hacluster としてログインし、新しいグループを追加します。［ID］には、Pervasive PSQLグループの名前を指定します。［Ordered］と［Collocated］には "true" を設定します。

リソースをグループに追

加する

次の 3 つのリソースを Pervasive PSQL グループに追加します。

IPaddr （IP アドレス）

Filesystem （ファイルシステム）

Psql （OCF リソースエージェント）

IPaddr （IP アドレス）

Heartbeat Management Client で、新しい "native" 項目を追加します。［Belong to group］には、

Pervasive PSQL 用に追加したグループを選択します。［Type］には "IPaddr" を選択します。

追加したリソースで、 IP の値に対してクラスターの IP アドレスを指定します。 Linux Heartbeatがインストールされ構成されたときには、（ノードではなく）クラスターに割り当てられた IPアドレスを使用します。

Filesystem （ファイルシステム）

新しい "native" 項目をもう 1 つ追加します。［Belong to group］には、 Pervasive PSQL 用に追加し

たグループを選択します。

［Type］には、 "Filesystem" を選択し、 "fstype" というパラメーターを削除します。このパラメー

ターは必要ありません。新しいパラメーターを追加し、［Name］には "device" を選択します。

［Value］には、共有記憶域のデバイス名、コロン、共有マウントのロケーションを指定します。

新しいパラメーターをもう 1 つ追加し、［Name］には "directory" を選択します。［Value］には、

NFS マウントで使用するディレクトリを指定します。

Psql （OCF リソースエージェント）

新しい "native" 項目をもう 1 つ追加します。［Belong to group］には、 Pervasive PSQL 用に追加し

たグループを選択します。［Type］では、［Description］フィールドに "PSQL OCF Resource Agent"の記載がある "psql" エントリをクリックします。このほかにパラメーターは必要ありません。

マウントされた共有記憶

域上にサブディレクトリ

を作成する

Filesystem リソースを追加できた場合は、クラスターサーバーと共有記憶域間にマウントが存

在するようになります。クラスターノードの 1 つに、ユーザー psql としてログインします。共

有記憶域マウントで、 "log" と "etc" という名前のディレクトリを作成します。

たとえば、マウントディレクトリが "/usr/local/psql/shared" の場合、 /usr/local/psql/shared/log と /usr/local/psql/shared/etc というディレクトリを追加します。

PCC でクラスターサー

バーを構成する

それぞれのクラスターノードで、Pervasive PSQL Control Center （PCC）を使ったクラスターサー

バーを構成する必要があります。

PCC を実行するノード以外のすべてのクラスターノードを代替モードにします。 psql ユーザー

として、 1 つのアクティブノードで、あるいはアクティブノードにアクセスできるクライアン

トから PCC を実行します。

Pervasive PSQL エクスプローラーで、新しいサーバーを追加し、クラスターの名前（または IPアドレス）を指定します。

追加したサーバーのプロパティにアクセスします。ログインを指示された場合は、 "admin" ユー

ザーとしてログインします。パスワードは空のままにします。［ディレクトリ］プロパティにア

クセスします。［トランザクションログのディレクトリ］には、 "log" ロケーション用に作成し

たディレクトリを指定します。［DBNames 設定ファイルのディレクトリ］には、"etc" ロケーショ

ン用に作成したディレクトリを指定します。「マウントされた共有記憶域上にサブディレクトリ

を作成する」を参照してください。

PCC で新しいサーバーを追加し、そのプロパティをほかの各クラスターノードから設定しま

す。 PCC を実行するノード以外のすべてのノードを代替モードにします


操作説明

162


クラスター環境における Pervasive PSQL の管理

フェールオーバークラスター環境に Pervasive PSQL をインストールすると、 Pervasive PSQL はリソースとして管

理できます。ここでは、一般的な管理の内容について説明します。

「Pervasive PSQL ライセンスおよびノードのメンテナンス」

「Pervasive PSQL のエラー時の動作」

「エラーが発生したノードにおける Pervasive PSQL の復元」

「Pervasive PSQL トランザクショナルサービスの停止と再開始」

「Pervasive PSQL 設定の変更」

「プロキシサーバーを持つクラスター環境」

「ソフトウェアのアップグレード」

Pervasive PSQL ライセンスおよびノードのメンテナンス Pervasive PSQL ライセンスやマシンのメンテナンスに関する一般的な手順は、フェールオーバークラスター環境

のノードにも同様に適用されます。データベースエンジンがインストールされた物理マシンまたは仮想マシンの

構成を変更する前には Pervasive PSQL 製品キーを認証解除してください。構成の変更が完了したら再度認証して

ください。

『Pervasive PSQL User's Guide』の「キーを認証解除するには」および「キーを認証するには」を参照してください。

Pervasive PSQL のエラー時の動作

クラスターノードでエラーが発生した場合、 Pervasive PSQL クライアントはスタンバイノード上の PervasivePSQL エンジンに自動的に再接続しません。アプリケーションでクライアントを Pervasive PSQL データベースに

再接続するか、アプリケーションを再起動する必要があります。データベースエンジンで［自動再接続の有効化］

がオンに設定されていたとしても同様の対処が必要です。

トランザクション一貫性保守がオフで、トランザクションが完了する前にエラーが発生した場合には、自動的に

トランザクションを開始する前の状態にロールバックされます。つまり、すぐ前の完了済みチェックポイントへ

戻るということです。ロールバックは、アクティブサーバーがデータファイルへのアクセスを要求した時点で

発生します。

共有記憶域上にデータ

ベースを作成する

クラスターノードのうち 1 つのノードのオペレーティングシステムから、ユーザー psql とし

てログオンし、データベースを置くファイルシステム共有下にディレクトリを作成します

（ユーザー root としてディレクトリを作成する場合、ユーザー psql はそのディレクトリに対し

て読み取り、書き込みおよび実行権限を持っていることを確認してください）。

PCC を実行するノード以外のすべてのクラスターノードを代替モードにします。

psql ユーザーとして、 1 つのアクティブノードで、あるいはアクティブノードにアクセスでき

るクライアントから PCC を実行します。「PCC でクラスターサーバーを構成する」で追加した

サーバーに新しいデータベースを作成します。［場所］には、データベースを置くディレクトリ

を指定します。必要に応じてその他のデータベースオプションを指定します。

新しいデータベースの場合、必要であればテーブルを作成します。

各ノードからのデータ

ベースへのアクセスを確

認する

各クラスターノードは共有記憶域上の Pervasive PSQL データベースにアクセスできる必要があ

ります。データベースを作成したクラスターノードを代替モードにします。これは "psql" リソース（データベースエンジン）を実行しているノードです。

クラスターの次のノードへフェールオーバーします。次のノードが、 "psql" リソースの実行の

制御を受け取ることを確認してください。クラスター内の各ノードに対して、上記の手順（代

替、フェールオーバー、確認）を繰り返し、開始したノードまで戻ったら終了します。


操作説明

163


トランザクション一貫性保守を設定している場合、クラスターノードに障害が発生した時点と後のチェックポイントの時点との間に発生した完了済みの変更は回復させることができます。トランザクション一貫性保守はす

べてのノードで同じように構成される必要があります。また、トランザクションログは共有記憶域に置かれます。

ただし、トランザクション一貫性保守が有効だった場合でも、クラスターの障害が発生した時点で完了していな

いトランザクションは失われます。

エラーが発生したノードにおける Pervasive PSQL の復元

フェールオーバークラスターには優先的に実行させるプライマリノードがあるかもしれません。プライマリ

ノードでエラーが発生した場合、セカンダリノードを使用するよりも早急にプライマリノードの方を復元しよう

と思われるでしょう。そのような状況の場合は、 Pervasive PSQL の一時ライセンスによってプライマリノードの

確立を支援できる Pervasive PSQL Insurance の利用をご検討ください。

Pervasive PSQL Insurance を使用すれば、直ちにオンラインに戻し業務を続行することができます。その間に元の

Pervasive PSQL ライセンスの復元を行うことが可能です。 Pervasive PSQL Insurance は、 3 回の認証が可能で、

Windows および Linux の 32 ビットまたは 64 ビット環境で利用可能な 14 日間の一時ライセンスを提供します。詳

細については、 http://www.agtech.co.jp/products/pervasive/ をご覧ください。

Pervasive PSQL トランザクショナルサービスの停止と再開始

オペレーティングシステムから Pervasive PSQL トランザクショナルサービスを手動で停止すると、アクティブ

ノードからクラスターのフェールオーバーが発生します。サービスノードのメンテナンスを実行しており、その

ようなフェールオーバーを回避したい場合は、 Pervasive PSQL トランザクショナルサービスをクラスターユー

ティリティから停止します。

Pervasive PSQL 設定の変更

データベースエンジンの再起動を必要とする設定の変更

変更する設定によってはデータベースエンジンを再起動する必要があります。そのような変更の場合は、非アク

ティブモードで変更を行うようにしてください。そうしないと、その再起動が原因でフェールオーバーが起こり

ます。「設定リファレンス」を参照してください。

ユーザー数追加キーの追加

追加キーはアクティブノードまたは非アクティブノード上の Pervasive PSQL へいつでも追加することができま

す。ユーザー数追加キーを追加する場合、データベースエンジンの再起動は不要で、直ちにその追加が適用され

ます。『Pervasive PSQL User's Guide』の「ユーザー数、セッション数または使用データの追加」も参照してください。

プロキシサーバーを持つクラスター環境

ご利用のクラスター環境にプロキシサーバーを組み込んでいる場合は、『Pervasive PSQL User's Guide』の「プロ

キシサーバー経由の認証アクセス」を参照してください。

ソフトウェアのアップグレード

ある時点で、Pervasive PSQL またはフェールオーバークラスターソフトウェアをアップグレードする必要がある

かもしれません。 Pervasive PSQL の場合、必ず非アクティブノード上のデータベースエンジンをアップグレード

するようにしてください。アップグレードバージョンのリリースノートも参照してください。フェールオーバー

クラスターソフトウェアの場合は、ソフトウェアベンダーが推奨する手順を参照してください。

164




マイグレーションでは、 Pervasive PSQL を実行している仮想マシンを、ある物理ホストから別のホストへ移動し

ます。通常は、仮想マシンのメモリ、記憶域およびネットワーク接続が移行先に移行されます。ハイパーバイザー

によって、マイグレーションは " ライブ " マイグレーションまたは " ホット " マイグレーションと呼ばれます。

" ライブ " マイグレーションまたは " ホット " マイグレーションでは、クライアントから Pervasive PSQL への接続

がそのまま維持されます。これにより、ハードウェアバランスまたはリソースバランスの変更が可能です。

" コールド " マイグレーションでは、仮想マシンを一時停止する必要があるため、ネットワーク接続が中断され

ます。クライアントから Pervasive PSQL への接続を再確立する必要があります。

マイグレーション環境には、実行中の Pervasive PSQL のインスタンスが 1 つだけあります。これにより、ホスト

マシンがクラッシュした、またはホストマシンを直ちにオフラインにする必要がある場合、その環境はやや脆弱

になります。また、共有記憶域にエラーが生じた場合、データベースエンジンは物理記憶域に対する読み込みま

たは書き込みを処理することができません。ハイパーバイザーによっては、共有記憶域を使用しないマイグレー

ションソリューションを提供しています。

Pervasive PSQL Vx Server はマイグレーション環境に適した製品です。仮想 MAC アドレスとホスト名が仮想マシ

ン移行後も同じままであれば、 PSQL Vx Server は正常に動作し続けます。製品キーの状態は " アクティブ " のま

まです。

Pervasive PSQL Server を使用することも可能ですが、その場合は別のホストへの移行が発生したときに製品キー

の状態が " 検証失敗 " に変わります。データベースエンジンは、一定期間（検証失敗期間）は検証失敗状態の

キーで実行することができます。検証失敗期間が終わる前に元のホストへ移行し直すということであれば、デー

タベースエンジンは正常に動作します。

マイグレーション環境で Pervasive PSQL をインストールまたは構成する際、特別な手順は必要ありません。ハイ

パーバイザーのドキュメントを参照してください。

165


フォールトトレランス

フォールトトレラント環境はマイグレーション環境と似ていますが、さらにコンポーネントがエラーになっても

動作が中断されないようする機能も備えています。フォールトトレラント環境では、ネットワーク接続、継続的

なサービスおよび同期された共有記憶域を介したデータアクセスが確保されます。コンポーネントの切り替えが

起こっても、クライアントマシンおよびアプリケーションは正常に機能し続け、データベースエンジンは中断さ

れません。

Pervasive PSQL Vx Server は「マイグレーション」での説明と同様の理由でフォールトトレラント環境に適した製

品です。

フォールトトレラント環境で Pervasive PSQL をインストールまたは構成する際、特別な手順は必要ありません。

ハイパーバイザーのドキュメントを参照してください。

166

障害回復

障害回復

障害回復にはデータの回復やサイトの回復が含まれています。データの回復はデータを保護および復元する方法

です。サイトの回復は、データを含むサイト全体を保護および復元する方法です。

データの回復は、ハイパーバイザーの共有記憶域および Pervasive PSQL のトランザクションログとトランザク

ション一貫性保守によって容易に行うことができます。「トランザクションログおよびトランザクション一貫性

保守」を参照してください。Pervasive PSQL Server および Server Vx ではトランザクションログとトランザクショ

ン一貫性保守を使用できます。

サイトの回復は Pervasive PSQL Server と Server Vx のどちらでも実行できます。 Pervasive PSQL Server の場合は、

物理マシン用に単独の製品キーが必要です。この回復に元のサイトの仮想マシンが含まれる場合、その仮想マシ

ンの起動時には Pervasive PSQL 製品キーの状態が「検証失敗」に変わります。データベースエンジンは、一定期

間（検証失敗期間）は検証失敗状態のキーで実行することができます。検証失敗期間が終わる前に元のホストへ

移行し直すということであれば、データベースエンジンは正常に動作します。ただし、サイトの回復で元のホス

トが失われる可能性があります。

仮想 MAC アドレスとホスト名が、回復されたサイト仮想マシンと元の仮想マシンとで同じままであれば、 PSQLVx Server は正常に動作します。製品キーの状態は " アクティブ " のままです。

障害回復環境で Pervasive PSQL をインストールまたは構成する際、特別な手順は必要ありません。ハイパーバイ

ザーのドキュメントを参照してください。

167


168

10
ワークグループエンジンの詳細
ワークグループエンジンの技術的な詳細および高度な処理

この章では、ワークグループエンジンのも特徴的な機能を利用する方法について説明します。

「ネットワーク」

「サーバーとワークグループの技術的な相違」

「ワークグループの問題のトラブルシューティング」

「ロケーターファイルのリダイレクト」

169


ネットワーク

サーバーおよびワークグループ製品には同一のネットワークコンポーネントが含まれています。したがって、

ワークグループエンジンをサーバーエンジンにアップグレードすることが可能です。クライアント側のリクエス

ターはいずれのタイプのエンジンにも接続することができます。

NetBIOSPervasive ネットワークサービスレイヤーは、以前サポートされていた名前付きパイプ、DNS および NDS などの

プロトコルと同様に、NetBIOS を使用してネットワーク上でエンジンを検索します。NetBIOS および DNS プロト

コルは、ワークグループエンジンと交信するのに使用することができます。 Windows 上のサーバーエンジンは

名前付きパイプを使用して自身をアドバタイズするため、 NetBIOS は必要ありません。

クライアントのリクエスターが IP、 SPX、または NetBEUI アドレスを見つけると、その転送プロトコルを使用し

て MicroKernel エンジンに接続を確立しようとします。

MicroKernel のルーター決定アルゴリズム

クライアント側の MicroKernel ルーターは、完全に確立されたアルゴリズムに従ってファイルのゲートウェイ

オーナーシップを見つけます。

クライアント側のルーターが常に初に試みることは、データと同じコンピューター上のエンジンに接続するこ

とです。このため、データが存在する場所でエンジンが実行されていることは常に非常に効果的です。

Pervasive ネットワークサービスレイヤーは、リモートデータベースエンジンに接続するのに非常に多数のさま

ざまな方法を用いるため、データベースエンジンが実行されていないファイルサーバー上のファイルを初に開

こうとするときに時間がかかることがあります。「ゲートウェイ一貫性保守」をオンにすると、ルーターがエンジ

ンの位置を特定するのに失敗した各マシンを記憶するので、その後その接続は試行されません。

リモートファイルサーバー上のエンジンに接続できなかった場合、ルーターはローカルエンジンがリモート

ファイルを開くことを許可します。ローカルエンジンはまず新しいロケーターファイルを作成し、リモートディ

レクトリのオーナーシップをとることを試みます。既にほかの MicroKernel がそのディレクトリを所有している

場合、ローカルエンジンはルーターにステータスコード 116 を返します。

後に、ルーターはゲートウェイコンピューターを探そうとします。ロケーターファイルを開き、ゲートウェイ

エンジンの名前を読み込みます。それからエンジンにリクエストを送ります。ルーターは MicroKernel からステー

タスコード 116 を受け取らなければロケーターファイルを読み込まないことに注意してください。この動作は、

ゲートウェイ機能を使用するためにはローカルワークグループエンジンがインストールされている必要がある

ことを示しています。ローカルエンジンがないためにローカルエンジンを使用してリモートファイルを開くこ

とに失敗した場合、ルーターはロケーターファイルを読み込まず、ゲートウェイエンジンを見つけることができ

ません。

表 40 ゲートウェイ検索の優先順位

優先順位手順

1 データファイルと同一のコンピューター上でデータベースエンジンに接続を

試みます。

2 ローカルエンジン（クライアントマシン上の）を使用してデータファイルの

オープンを試みます。

3 ファイルを所有するゲートウェイエンジンを見つけて接続を試みます。

170

サーバーとワークグループの技術的な相違

サーバーとワークグループの技術的な相違

サーバーエンジンとワークグループエンジンにはいくつかの重要な相違点があります。このセクションではその

違いについて説明します。

プラットフォーム

サーバーエンジンには 32 ビット版および 64 ビット版があり、Linux および Windows で使用することができます。

ワークグループエンジンの場合は 32 ビット Windows 版のみです。ワークグループエンジンを 64 ビット Windowsオペレーティングシステムで実行することはできますが、使用できるメモリは大でも 2 GB であるため、一般

的に 64 ビットシステムでインストールされる（2 GB を超える）大量のメモリを活用することはできません。

ユーザーインターフェイス

Windows のサーバーエンジンは、インストールされると Windows のサービスとして実行されます。ワークグルー

プエンジンは、インストールされるとアプリケーションまたはサービスとして実行されます。『Getting Started withPervasive PSQL』の「ワークグループエンジンの構成」を参照してください。アプリケーションとして実行する

ようにインストールした場合、ワークグループエンジンはトレイアイコンをインターフェイスとして使用しま

す。

認証と Btrieve セキュリティポリシー

サーバーエンジンでは、オペレーティングシステムにおけるファイルのアクセス許可の設定を適用します。ワー

クグループエンジンは自身でユーザーの認証を行いません。ワークグループエンジンがネットワーク上のコン

ピューターにアクセスすることができれば、そのデータに到達できます。この緩和されたセキュリティは、セキュ

リティよりも使いやすさを優先する小規模のオフィスを対象としています。

ワークグループエンジンでオペレーティングシステム認証がないということは、Btrieve の " 混合 " セキュリティ

ポリシーと " クラシック " セキュリティポリシーが同じであることを意味します。『Advanced Operations Guide』の「セキュリティモデルと概念」を参照してください。セキュリティポリシーの違いは、サーバーエンジンと

ワークグループエンジン間の動作の違いです。

ゲートウェイのサポート

ワークグループエンジンは、ローカル、リモート共にファイルを開いたすべての場所にロケーターファイルを作

成し、ワークグループエンジンがゲートウェイオーナーシップを動的に適合できるようにします。デフォルト

で、ワークグループエンジンはほかのコンピューターやネットワークデバイスで認証されるユーザー ID でも実

行されます。このため、ワークグループエンジンはゲートウェイ環境での使用に適です。『Getting Started withPervasive PSQL』の「ゲートウェイ構成のセットアップ」を参照してください。

サーバーエンジンは必ずしもゲートウェイロケーターファイルを作成する、または引き受けるわけではありま

せん。したがって、サーバーエンジンをゲートウェイ環境で使用するような設計やテストを行なっていません。

そのため、ワークグループ環境では、ワークグループエンジンに代わってサーバーエンジンをゲートウェイとす

ることはサポートされていません。

非同期 I/OWindows 版のサーバーエンジンは非同期 I/O を使用します。また、データベースページの書き込みの結合はサー

バーエンジンでのみ行われます。これらの機能によって、 I/O の負荷が高いときは、ワークグループエンジンに

比べサーバーエンジンが大きなパフォーマンスの利点を得ることができます。

デフォルトの設定

いくつかのデータベース設定（キャッシュサイズやシステムキャッシュなど）のデフォルト値は、サーバーエンジンとワークグループエンジンでそれぞれ異なります。ワークグループエンジン設定用のデフォルト値は、シ

171


ステムリソースの消費をより抑えるよう設定されます。『Advanced Operations Guide』の「設定リファレンス」を


Xtreme I/O （XIO）のサポート

XIO は Windows 32 ビットサーバーエンジンでのみサポートされます。『Advanced Operations Guide』の「XtremeI/O ドライバー」を参照してください。

ライセンスモデル

Pervasive PSQL Server および Pervasive PSQL Workgroup ではユーザーカウントライセンスモデルを使用します。

Pervasive PSQL Vx Server では容量ベースライセンスモデルを使用します。『Pervasive PSQL User's Guide』の「ラ

イセンスモデル」を参照してください。 Pervasive PSQL Vx Server に関する詳細については、『Pervasive PSQL VxProduct Guide』を参照してください。

172

ワークグループの問題のトラブルシューティング

ワークグループの問題のトラブルシューティング

このセクションでは、ワークグループ環境での問題の解決に役立つヒントを提供します。

初の接続での待ち時間

初のファイルオープンリクエストが発行されるときに何度も遅延が起きるのであれば、次の方法が役に立つか

どうか調べてください。

可能であれば、データが存在する場所でエンジンが実行されるようにしてください。

ファイルオープンのリクエストをどこに送るかを決定するとき、クライアントが優先で行う方法は、データが

あるのと同じマシン上のエンジンに接続することです。ワークグループエンジンがアプリケーションとして実行

されるのを確実にするため、次のコマンドを使用してエンジンのアイコンをスタートアップフォルダーに入れま

す。

W3dbsmgr.exe

もう 1 つの方法としては、ワークグループエンジンをサービスとしてインストールします。『Getting Started withPervasive PSQL』を参照してください。また、 Pervasive PSQL ファイルのデフォルトの場所については、『GettingStarted with Pervasive PSQL』の「Pervasive PSQL ファイルはどこにインストールされますか？」を参照してくだ

さい。

ゲートウェイトポロジを実行している場合

データが存在する場所でエンジンを実行できない場合、初の接続の待ち時間はより重要な問題になります。試

してみることがいくつかあります。

1 クライアントの設定で［サポートプロトコル］を減らし、ネットワークで使用されていないプロトコルの使

用が試みられないようにします。

2 ゲートウェイ一貫性保守を使用します。ゲートウェイ一貫性保守はクライアントの設定で、ゲートウェイ環

境で初の接続を確立するときの待ち時間をほとんどなくすことができます。［ゲートウェイ一貫性保守］が

オンに設定されていると、クライアントルーターがエンジンの実行されていないコンピューター名をレジス

トリに書き込むようにします。接続に失敗すると、ルーターはこのサーバー名を実行中のみ保存するのでは

なく、レジストリに保存します。次回アプリケーションが起動したとき、データのある場所のエンジンへの

接続は試行されません。直ちに現在のゲートウェイを決定する次の段階に進みます。

この設定は PCC で切り替えることができます。 PCC の Pervasive PSQL エクスプローラーで［ローカルクラ

イアント］ノードを展開し、［MicroKernel ルーター］を右クリックします。［プロパティー］をクリックし、

［アクセス］を選択します。［ゲートウェイ一貫性保守］オプションをクリックしてオンに設定し（チェック

マークは、その設定が「オン」であることを表します）、［OK］をクリックします。

メモこの機能はトポロジを固定するため、デフォルトではオフになっています。データが存在する場所に

サーバーエンジンまたはワークグループエンジンを追加した場合、この設定をオンにした各クライアントで

オフに戻す必要があります。この設定をオフに戻すと、エンジンが実行されていないコンピューターのレジ

ストリを消去するので、その後すぐにオンにすると新しいトポロジに基づいた新しいリストが生成されます。

ステータスコード 116 ステータス 116 は MicroKernel のステータスコードで、ゲートウェイとして動作する別の MicroKernel エンジン

によってファイルが使用されていることを示します。アプリケーションがステータスコード 116 を受け取った場

合、 MicroKernel ルーターはロケーターファイルを読むことができたけれどもゲートウェイコンピューター上で

実行されているエンジンと交信できなかったことを示します。

173


初にしなければならないことは、ゲートウェイがどれかを見極めることです。この作業は Gateway Locator ユー

ティリティを使用して行うことができます。

次に PSA ネットワークテストを使用してそのコンピューターに接続してみます。 PSA は問題を分離するための

役に立つ情報を提供します。

これが起こる 1 つの状況は、 2 つのコンピューターがルーターで分けられていて、両方ともファイルサーバーを

見ることができるが、互いを見ることができない場合です。

174

ロケーターファイルのリダイレクト


ゲートウェイエンジン操作のこの機能は、複数ディレクトリのデータベースのトランザクションアトミシティを

保証し、また複数のデータディレクトリにわたるゲートウェイエンジンの名前の変更を容易にします。

Pervasive PSQL クライアントがリモートデータファイルにアクセスする際に次の方法を使用することを思い出


データファイルと同一のコンピューター上でデータベースエンジンに接続を試みます。

次に、そのリモートマシンでデータベースエンジンが使用可能でない場合、ローカルエンジンを使用して

リモートディレクトリのオーナーシップをとり、ロケーターファイルを作成します。ゲートウェイロケー

ターファイルが既に存在する場合、ローカルエンジンは使用されません。

3 番目に、指定されたゲートウェイエンジンを使用することを試みます。

ゲートウェイ設定は、データファイルが存在するコンピューター上に使用可能なデータベースエンジンがない場

合にのみ有効になることを覚えておいてください。

この機能により、同一ボリューム上の複数ディレクトリのデータベースのトランザクション一貫性保守を保ちな

がら動的（変動）ゲートウェイエンジンを使用することができます。この利点は、別のゲートウェイロケーター

ファイルを指示する新しいゲートウェイロケーターファイルによってもたらされました。新しいタイプはリダイ

レクトロケーターファイルと呼びます。ディレクトリ D のロケーターファイルを指示するリダイレクトロケー

ターファイルをディレクトリ A、 B、 C に持つことにより、ディレクトリ D のロケーターファイルが指定する

ゲートウェイエンジンが、ほかのディレクトリにあるデータファイルのサービスも確実に提供することができる

ようになります。

ディレクトリ D のロケーターファイルが固定ゲートウェイを指定しているか、これらのファイルを初に開いた

エンジンによって動的に作成されるかにかかわらず、このアーキテクチャは指定されたすべてのディレクトリが

必ず同一のゲートウェイエンジンを使用します。同様に、いくつかのディレクトリの固定ゲートウェイを変更し

ようとする場合、リダイレクトロケーターファイルを使用すると、すべてのロケーターファイルではなく、たっ

た 1 つのロケーターファイルを変更するだけで済みます。したがって、一定のハードドライブ上のすべてのデー

タファイルが固定ゲートウェイを指定しているといないにかかわらず、同一ゲートウェイエンジンを使用するよ

うに指定することができます。

リダイレクトロケーターファイルの要件

リダイレクトロケーターファイルの初の行は "=>" で始め、その後に必ず同一ドライブ上にある別のロケー

ターファイルのパスを指定する必要があります。パス名にはスラッシュおよび円記号の任意の組み合わせを使用

することができます。スラッシュはすべてローカルオペレーティングシステムの使用するタイプの区切り文字に

変換されます。

スラッシュで終わるパスを指定した場合、データベースエンジンはパスの後にデフォルトのロケーターファイ

ル名（~PVSW~.LOC）を追加します。指定したパスがスラッシュで終わっていない場合、データベースエンジン

はパスにファイル名が含まれているものと見なします。

次の表は、リダイレクトロケーターファイルのパスの指定方法の一覧です。

これらのロケーターファイルに複数レベルのリダイレクトを割り当てることができます。たとえば、初のロ

ケーターファイルが 2 番目のロケーターファイルを指示し、2 番目のロケーターファイルが 3 番目のロケーター

表 41 リダイレクトロケーターファイルパスの記述方法

パス説明

=>\path_name 現在のロケーターファイルが格納されているルートドライブからパスを指定します。

=>.\path_name 現在のディレクトリからの相対パスを指定します。

=>..\path_name 現在のディレクトリの親ディレクトリからの相対パスを指定します。

175


ファイルを指示するという具合です。各ワークグループエンジンはそれぞれのロケーターファイルを順に開き、

実際のゲートウェイ名を探します。いったん "=>" で始まらないロケーターファイルを見つけると検索は中止さ

れ、エンジンはこのロケーターファイルがゲートウェイエンジンを指定しているものと見なします。

リダイレクトロケーターファイルの作成

ほかのロケーターファイルと同様、リダイレクトロケーターファイルは普通のテキストファイルです。リダイ

レクトロケーターファイルは手作業でもプログラムからでも作成することができます。リダイレクトロケー

ターファイルには読み取り専用フラグを設定しておかないと、そのディレクトリにあるデータファイルに初に

アクセスを試みたエンジンによって上書きされてしまいます。

リダイレクトロケーターファイルを作成するには

1 メモ帳またはテキストエディターを開き、新規テキストファイルを開きます。

2 完了時にファイルをどこに保存するかを決定します。別のロケーターファイルにリダイレクトしようとする

データファイルと同じディレクトリにファイルを保存します。

たとえば、 C:\data にあるデータファイルが、確実にほかのデータファイルと同じゲートウェイエンジンに

よってアクセスされるようにするには、 C:\data を忘れないようにしておきます。

3 => と次のロケーターファイルのパス名を入力します。前の手順の例で続けると、 C:\data にある現在のデー

タファイルが、C:\moredata にあるロケーターファイルで指定されたゲートウェイエンジンに属するように

したい場合、次のように入力します。

=>..\moredata\ （推奨）または

=>\moredata\ （推奨しません）

初のケースでは現在のディレクトリからの相対パスを指定しています。 2 番目のケースは現在のドライブ

からの絶対パスを指定しています。この例の場合では、両方とも同じ目的のディレクトリを解決することが

できます。

メモ Pervasive はリダイレクトロケーターファイルでは相対パス（ .\ または ..\ で始まる）を使用し、同じ

データにアクセスするすべてのワークステーションで同じ共有名を使用することを強くお勧めします。この

2 つの忠告に従えば、マップドライブでのネットワークパス名の解決で起こるエラーを防ぐことができま

す。

4 ゲートウェイエンジンを指定したいデータファイルが存在するディレクトリに ~PVSW~.LOC という名前で

ファイルを保存します。

5 メモ帳またはテキストエディターを閉じます。

6 このテキストファイルに読み取り専用フラグを設定します。

Windows でファイルを読み取り専用にするには、Windows エクスプローラーでファイルアイコンを右クリッ

クして［プロパティ］ダイアログボックスを使用するか、［プログラム］の DOS セッションかプログラムで

ATTRIB コマンドを使用します。

ATTRIB +R ~PVSW~.LOC

固定ゲートウェイで多数のデータディレクトリの同期をとるには

1 手作業または Gateway Locator プログラムを使用して、リダイレクトしない読み込み専用の（固定）ロケー

ターファイルを作成します。ゲートウェイとして使用するワークグループエンジンを指定する必要がありま

す。

たとえば、ロケーターファイルに "workgroup1" というコンピューター名をゲートウェイエンジンとして指

定し、ファイルが C:\DATA\DB1 にあるとします。

176


2 前の手順で指定したゲートウェイエンジンを使用しようとする、その他のデータディレクトリごとに、リダ

イレクトロケーターファイルを作成する必要があります。各リダイレクトロケーターファイルは前の手順

で作成したファイルを示す必要があります。

前の例でいうと、 C:\DATA\DB2 および C:\DATA\DB3 にあるリダイレクトロケーターファイルは次のテキ

ストを含みます。

=>..\DB1\

これにより、このファイルを読み込んだエンジンはすべて相対パスに従って、指定された C:\DATA\DB1 で別のロケーターファイルを検索します。この場合、指定したディレクトリには "workgroup1" をゲートウェイ

コンピューターとして挙げているロケーターファイルがあります。

動的ゲートウェイで多数のデータディレクトリの同期をとるには

1 上記の手順に従いますが、手順 1 でロケーターファイルが固定的に割り当てられないように書き込み可能に

するだけです。

この場合、リダイレクト階層内にあるデータファイルにどのエンジンもアクセスしていなければ、目的の

ディレクトリにはロケーターファイルがないということを覚えておいてください。この状態は正常です。動

的ロケーターファイルはエンジンの初のデータアクセスによって各セッションに作成され、後のユー

ザーセッションが終了したときに削除されます。ロケーターファイルが存在しないデータディレクトリを

示すリダイレクトロケーターファイルを持つことは問題ありません。この場合、データファイルを初に

開いたエンジンがロケーターファイルを作成します。

例

図 4 に示したロケーターファイルの例を使用すると、左側のリダイレクトロケーターファイルはデータベース

エンジンに 1 つ上のディレクトリに行き、そのサブディレクトリの newdir でデフォルト名（~PVSW~.LOC）を

持つ別のロケーターファイルを探すように指示しています。今度は、このロケーターファイルが ntserver1 という名前のコンピューター上にあるワークグループエンジンがゲートウェイエンジンであることを指定します。

その結果、 mydir ディレクトリにあるデータファイルにアクセスするために、 ntserver1 にあるデータベース

エンジンが使用されます。

図 4 リダイレクトロケーターファイルの例

mydir/~pvsw~.loc

=>../newdir/ ntserver1

newdir/~pvsw~.loc

177


178

11
データベースリソースの監視
Monitor を使用してデータベースリソースを調べる


「Monitor の概要」

「Monitor のグラフィカルユーザーインターフェイス」

「Monitor のコマンドラインインターフェイス」

179


Monitor の概要

Monitor はデータベースエンジンの特定の動作と属性を監視することができるユーティリティです。このユー

ティリティでは、データベース管理およびアプリケーションのプログラムの診断に役立つ情報を提供します。こ

のユーティリティはトランザクショナルインターフェイスおよびリレーショナルインターフェイスの状況も監

視できます。

インターフェイスの各種バージョン

Monitor には 3 つのインターフェイスがあり、これらはすべて同じ機能を提供します。グラフィカルインターフェ

イスでは、一連のダイアログボックスで情報を表します。コマンドラインインターフェイスでは、設定可能な

場所への情報を指示する実行可能プログラムを使用します。もう 1 つのインターフェイスは Pervasive PSQLControl Center に組み込まれており、データベースエンジンのコンテキストメニューからアクセスします。

グラフィカルユーザーインターフェイスの説明については、「Monitor のグラフィカルユーザーインター

フェイス」を参照してください。

コマンドラインインターフェイスの説明については、「Monitor のコマンドラインインターフェイス」を参


PCC に組み込まれた Monitor の詳細については、『Pervasive PSQL User's Guide』の「Monitor」を参照してく

ださい。

180

Monitor のグラフィカルユーザーインターフェイス


グラフィカルユーザーインターフェイス（GUI）バージョンの Monitor は、 Windows 32 ビットおよび 64 ビット

プラットフォームで実行される 32 ビット Windows アプリケーションです。

Monitor では、ある時点のサーバー稼動状況のスナップショットを作成することができます。スナップショット

がどのくらい近のものであるかは、リフレッシュレートの間隔によって決まります。デフォルトの間隔は 4 秒です。リフレッシュレートの設定方法については、「Monitor のオプション設定」を参照してください。

Monitor の起動オペレーティングシステムの［スタート］メニューまたはアプリ画面から、あるいは Pervasive PSQL Control Centerの［ツール］メニューから Monitor にアクセスします。

Monitor はデフォルトでローカルデータベースエンジンに接続します。しかし、リモートサーバーへ接続すれ

ば、リモートデータベースエンジンのリソースも監視することができます。

リモートサーバーに接続するには

1 Monitor で現在開かれているダイアログがないことを確認してください。

ダイアログが開いていた場合はリモートサーバーに接続することができません。

2 ［オプション］メニューの［接続］をクリックします。［リモートサーバーに接続］ダイアログが表示されます。

3 ［サーバー名］フィールドに、監視対象のサーバーの名前または IP アドレスを入力します。

4 ［ユーザー名］および［パスワード］フィールドにそれぞれサーバーに対するユーザー名とパスワードを入力

します。

認証されるためには、指定されたユーザーが、データベースエンジンが起動しているコンピューターに対し

管理者レベルの権限を持っているか、そのコンピューター上の Pervasive_Admin グループのメンバーでなけ

ればなりません。


サーバーから切断するには

1 Monitor で現在開かれているダイアログがないことを確認してください。

ダイアログが開いていた場合はサーバーから切断することはできません。

2 ［オプション］メニューの［切断］をクリックします。

3 ［はい］をクリックします。

Monitor のオプション設定

Monitor オプションを設定するには

1 ［オプション］メニューから［設定］をクリックします。［Monitor 設定］ダイアログには現在の設定が表示

されます。

181


2 以下のオプションを指定します。

3 ［OK］をクリックして設定を保存します。

トランザクショナルインターフェイスリソースの監視

このセクションでは、トランザクショナルインターフェイス（MicroKernel）を監視する以下のオプションについ

て説明します。

「ダイアログリフレッシュオプションの設定」

「アクティブファイルの表示」

「セッション情報の表示」

「リソース使用状況の表示」

「通信統計情報の表示」

ダイアログリフレッシュオプションの設定

Monitor の各種ダイアログにある情報は、以下のように自動または手動でリフレッシュできます。

自動に設定するには、［自動リフレッシュ］オプションを選択します。［Monitor］のオプションで指定した

［リフレッシュレート］に従ってダイアログが更新されます（「Monitor のオプション設定」を参照してくだ

さい）。

手動で行うには、［リフレッシュ］をクリックします。

アクティブファイルの表示

［MicroKernel］メニューの［アクティブファイル］をクリックします。［MicroKernel アクティブファイル］ダイ

アログが表示され、現在 MicroKernel によって開かれているファイルをすべて示します。

終了時に設定を保存 Monitor を閉じる際、全設定を保存するにはこのオプションを選択します。 Monitor により、こ

のダイアログにある設定および各ダイアログにある自動リフレッシュオプションが保存され

ます。

終了時にウィンドウレイアウトを保存

開かれたすべてのダイアログの状態（開いているか閉じているか）および画面表示位置を保存

するには、このオプションを選択します。 Monitor を再起動すると、そのダイアログが自動的

に開かれ、選択した位置に配置されます。この機能により、好みのレイアウトを簡単に再現す


リフレッシュレート

（秒単位）

Monitor がその表示をリフレッシュする間隔を指定します。リフレッシュレートは秒単位で表

します。デフォルトの設定は 4 秒です。指定できるのは整数のみです。

この数値の設定が小さ過ぎると、 Monitor は頻繁にリフレッシュするため、データベースエン

ジンのパフォーマンスに影響を与えることがあります。この現象は特にローカルデータベー

スエンジンを監視する場合に現れます。

182


図 5 ［MicroKernel アクティブファイル］ダイアログ

ファイルのリスト

ダイアログの左上に［アクティブな MicroKernel ファイル］のリストが表示されます。このスクロール可能なリ

ストには、開いているすべてのファイルの絶対パスがアルファベット順に表示されます。

ファイルについての詳細情報を表示するには

1 リスト内の目的のファイルをクリックします。

2 ダイアログの左下にある［ファイル情報］セクションに、そのファイルに関する情報が表示されます。

ファイルハンドルのリスト

［MicroKernel アクティブファイル］ダイアログの右上には［選択されたファイルのハンドル］のリストが表示さ

れます。このスクロール可能なリストには、選択したファイルに関連するアクティブハンドルが表示されます。

ページサイズファイルの各ページサイズ（バイト単位）を表します。

リードオンリー

フラグ

このファイルに、オペレーティングシステムからリードオンリーのフラグが付けられているかを示しま

す。

レコードロック選択したファイルのアクティブハンドルのいずれかが、レコードロックを行っているかどうかを示しま

す。どのアプリケーションもロックされたレコードを読み込むことが可能ですが、レコードの変更や削

除ができるのは、ロックを行ったアプリケーションのみです。レコードロックはファイルを開いたアプ

リケーションがレコードを更新している期間中にのみかかります。 " はい " はファイルに対し 1 つ以上の

レコードロックが適用されていることを示し、 " いいえ " はロックされたレコードがないことを示して

います。

トランザクション

ロック

選択したファイルのアクティブハンドルのいずれかが、トランザクションロックを行っているかどうか

を示します。トランザクションロックはファイルを開いたアプリケーションがトランザクションの作業

をしている期間中にのみかかります。

物理ファイルサイズ KB

ファイルのサイズをキロバイト（KB）で示します。この情報は特に、容量ベースのライセンスモデルで

ファイルごとの使用データ量を再調査する場合に役立ちます。『Pervasive PSQL User's Guide』の「容量

ベースライセンスモデル」も参照してください。

Monitor では、個々のファイルのサイズにはキロバイト（KB）、またリソースの使用状況（「リソース使

用状況の表示」）にはメガバイト（MB）の単位を使用することに注意してください。License Administratorではサイズの単位にギガバイト（GB）を使用しています。これは、使用データがその単位でキーに関連

付けられているからです。コンテキストごとに適切な単位を必要とします。

大量レコードの挿入直後にファイルを閉じた場合、Monitor ではそのファイルのサイズの変更が直ちに反

映されないので注意してください。たとえば、そのファイルに関する［物理ファイルサイズ KB］の統

計情報は、次回そのファイルが読み取りまたは書き込みのために開かれるまで更新されません。

183


各ハンドルは、名前（通常はユーザーのログイン ID）、またはデータベースエンジンのクライアントリストへの

インデックスで表されます。

ファイルハンドルについての詳細情報を表示するには

1 リスト内の目的のハンドルをクリックします。

2 ダイアログの下部中央にある［ハンドル情報］セクションに、そのハンドルに関する情報が表示されます。

セッション情報の表示

現在のセッションおよびファイルのリストや各セッションのファイルハンドルを表示することができます。

「セッション」とは、トランザクショナルエンジンインターフェイスによって使用されるクライアント ID、また

はリレーショナルエンジンインターフェイスへの接続と定義されます。「クライアント ID」とは、データベース

トランザクションコンテキストを一意に識別するために、アプリケーション、クライアントプラットフォームお

よびデータベースエンジンによって提供される要素を組み合わせた 16 バイトの構造体と定義されます。

接続番号クライアントのネットワーク接続番号を表示します。クライアントがネットワーク接続を持たない場

合、このフィールドには "NA" （適用外）と表示されます。

タスク番号サーバーまたは Windows クライアントで発生するプロセスのタスク番号を表示します。

サイトユーザープロセス（ローカルまたはリモート）のロケーションを示します。

ネットワークアド

レス

ネットワーク上の呼び出し元プロセスのロケーションを表示します。

呼び出し元プロセスが SPX の場合、ネットワークのノード / ネットワークアドレスの先頭に S: と表

示されます。たとえば S: 65666768 00000000001 のように表示されます。

呼び出し元プロセスが TCP/IP の場合、アドレスの先頭には次のように T が付きます。

T: 180.150.1.24、 T: 1234:5678:0000:0000:0000:0000:9abc:def0、あるいはT: <mymachine.mydomain.mycompany>.com

オープンモードアプリケーションでファイルの特定のハンドルを開くのに使用する方法を表示します。有効なオープ

ンモードは以下のとおりです。

ノーマル－ファイルを開いたアプリケーションでノーマル共有読み込み / 書き込みアクセスが可能

アクセラレイティド－ファイルを開いたアプリケーションで共有読み込み /書き込みアクセスが可能

リードオンリー－ファイルを開いたアプリケーションで読み込み専用モードでアクセスできるが、

ファイルの変更は不可

エクスクルーシブ－ファイルを開いたアプリケーションでエクスクルーシブなアクセスモードが使

用可能。呼び出し元アプリケーションが閉じるまで、ほかのアプリケーションからファイルを開くこ

とはできません。

Monitor では、すべてのオープンモードについて、非トランザクションまたは共有ロックが適用可能

な場合は、その状態も示します。

レコードロックタイプ現在ハンドルで扱われているレコードロックの種類を表示します。レコードロックには、［シング

ル］、［マルチ］、［なし］の 3 種類があります。

シングルレコードロックの場合、ユーザーは一度に 1 つのレコードをロックすることができます。マ

ルチレコードロックの場合、ユーザーは一度に複数のレコードをロックすることができます。

ウェイト状態このハンドルで、なんらかのロックによってユーザーが待機しているかどうかを次のように表示しま

す。［レコードロックウェイト］、［ファイルロックウェイト］、または［なし］。


タイプ

現在ハンドルで扱われているトランザクションロックの状態を表示します。トランザクションには、

［排他］、［並行］、および［なし］の 3 種類があります。

184


セッション情報は、トランザクショナルインターフェイスおよびリレーショナルインターフェイスを介して確立

されたセッションを示します。（リレーショナルインターフェイスによってのみ確立されたセッションを表示さ

せる場合は、「SQL アクティブセッションの表示」を参照してください）。

セッションを表示するには

［MicroKernel］メニューの［アクティブセッション］をクリックします。［MicroKernel アクティブセッション］

ダイアログが表示されます。

図 6 ［MicroKernel アクティブセッション］ダイアログ

セッションのリスト

ダイアログの左上に［アクティブな MicroKernel セッション］のリストが表示されます。このスクロール可能な

リストには、アルファベット順にアクティブセッションの名前が表示されます。各セッションは、名前（通常は

ユーザーのログイン ID）、またはデータベースエンジンのクライアントリストへのインデックスで表されます。

セッションについての詳細情報を表示するには

1 目的のセッションをクリックします。

2 ダイアログの左下にある［セッション情報］セクションに、そのセッションに関する情報が表示されます。

接続番号セッションのネットワーク接続番号を表示します。そのセッションがネットワーク接続を持たない

場合、このフィールドには "NA" （適用外）と表示されます。

タスク番号サーバーで、または Windows クライアントから発生するプロセスのタスク番号を表示します。

サイトセッションプロセス（ローカルまたはリモート）のロケーションを示します。

ネットワークアドレスネットワーク上の呼び出し元プロセスのロケーションを表示します。呼び出し元プロセスが SPXの場合、ネットワークのノード / ネットワークアドレスの先頭に S: と表示されます。たとえば S:65666768 00000000001 のように表示されます。

呼び出し元プロセスが TCP/IP の場合、アドレスの先頭には次のように T が付きます。

T: 180.150.1.24、 T: 1234:5678:0000:0000:0000:0000:9abc:def0、あるいはT: <mymachine.mydomain.mycompany>.com

単独マシンの複数のクライアントを異なる TCP/IP アドレスで接続する場合、各アドレスはそのク

ライアントに対して有効です。ただし、データベースエンジン内部的には、クライアントと関連

付けられるアドレスは、そのクライアントによって使用される実際のアドレスではないかもしれま

せん。これは、データベースエンジンが同じマシンからの複数のクライアントを特定および管理

するからです。その結果、 Monitor はエンジン情報を報告しているので、このユーティリティでは

実際のアドレスではなく、関連付けられたアドレスが表示される可能性があります。

使用中ロック数セッションが現在使用中のロック数。

185


セッションのファイルハンドル

ダイアログの右上に［選択されたセッションのハンドル］のリストが表示されます。このスクロール可能なリス

トには、選択したセッションに関連するアクティブファイルハンドルが表示されます。MicroKernel は、セッショ

ンでファイルを開くたびにハンドルを作成します。 1 つのセッションが同じファイルに対していくつかのハンド

ルを持つことができます。

セッションのファイルハンドルについての詳細情報を表示するには

1 目的のセッションファイルハンドルをクリックします。

2 ダイアログの中段右側にある［ハンドル情報］セクションに、そのハンドルに関する情報が表示されます。

現在のセッションの削除

現在のセッションを削除すると、そのセッションはアクティブセションのリストから削除され、セッションの

データベースエンジンへの接続が切断されます。セッションが開いていたすべてのファイルが閉じられ、割り当

てられていたすべてのリソースが解放されます。

注意現在のセッションを削除すると、その時点で発生している処理によっては、データが不正になる、レ

コードが不完全になる、またはトランザクションが中止される可能性があります。

セッションを削除するには

1 目的のセッション名をクリックします。

2 以下の操作のいずれかを実行します。

［現セッションの削除］をクリックすると、選択したセッションは削除されます。［全セッションの削除］をクリックすると、現在のセッションはすべて削除されます。

トランザクションタイプセッションが現在扱っているトランザクションロックの種類。トランザクションには、［排他］、

［並行］、および［なし］の 3 種類があります。

読み込みレコード数セッションがファイルを初に開いてから現在までに読み込んだレコードの数。

挿入レコード数セッションが挿入したレコードの数。

削除レコード数セッションが削除したレコードの数。

更新レコード数セッションが更新したレコードの数。

ディスクアクセス数セッションがディスクアクセスを要した回数。開いたばかりのファイルでは、ディスクアクセス

についての情報は表示できません。

キャッシュアクセス数このクライアントが L1 キャッシュに失敗し、要求を満たすために L2 キャッシュまたはディスク

から L1 キャッシュへページを移動した回数を示します。

オープンモード「オープンモード」を参照してください。

レコードロックタイプ「レコードロックタイプ」を参照してください。

ウェイト状態「ウェイト状態」を参照してください。

トランザクションタイプ「トランザクションタイプ」を参照してください。

186


リソース使用状況の表示

［MicroKernel］メニューの［リソース使用状況］をクリックします。［MicroKernel リソース使用状況］ダイアロ

グボックスが表示されます。

図 7 ［MicroKernel リソース使用状況］ダイアログ

このダイアログでは、 MicroKernel が後に起動してから現在まで使用されているリソースを表示します。

［MicroKernel 稼働時間］セクションには、MicroKernel が起動されている時間が、週、日、時、分、秒で示されます。

このダイアログでは各リソースに対して以下の統計情報が表示されます。

現在値－そのリソースの現在の値を表示。

ピーク値－ MicroKernel が起動してから現在までにそのリソースが記録した高値を表示。

大値－そのリソースで使用できる大値を表示。

データベースエンジンは、これらのリソースのうちいくつかの大値を動的に制御します。ユーザー数、セッ

ション数および使用中データの大値は製品ライセンスによって決まります。『Pervasive PSQL User's Guide』の

「ライセンスモデル」を参照してください。

リソースが監視対象の Pervasive PSQL 製品のタイプに適用されない場合、そのリソースの各統計情報には "N/A"（適用外）が表示されます。たとえば、 " ユーザー数 " は Pervasive PSQL Vx Server には適用されません。このた

め、 Pervasive PSQL Vx Server が監視される場合は、［ユーザー数］の［現在値］、［ピーク値］および［大値］に

は "N/A" が表示されます。同様に、 Pervasive PSQL Server が監視される場合は、［セッション数］と［使用中デー

タ MB］の［大値］には "N/A" が表示されます。

ただし、 Pervasive PSQL Vx Server の使用を検討されている場合、［セッション数］および［使用中データ MB］の

現在値やピーク値の予測が必要です。そのため、それらの統計情報は PSQL Server でも表示されますが、実施は

されません。これらの統計情報については、その値に関わらず通知は送信されません。

以下のリソースに関する使用状況の情報が表示されます。

ファイル数 MicroKernel によって現在開かれているファイル数。

ハンドル数アクティブハンドルの数。 MicroKernel は、ユーザーがファイルを開くたびにハンドルを作成します。

1 つのセッションが同じファイルに対していくつかのハンドルを持つことができます。

クライアント数 MicroKernel にアクセス中のクライアントの数。 1 台のマシンで複数のクライアントがデータベースエンジンに同時にアクセスできます。データベースエンジンはクライアント一覧を動的に管理します。

クライアント数はコンピューターのメモリによってのみ制限されます。

「クライアント」とは、クライアント ID （トランザクショナルエンジンインターフェイス）によって、

またはリレーショナルエンジンインターフェイスへの接続によって確立されたセッションをいいま

す。データベースエンジンは、 Pervasive PSQL システムファイル、メタデータファイル、 dbnames.cfgおよびデフォルトのシステムデータベースへのアクセスなど、独自の内部処理用にさまざまなクライ

アントセッションを使用します。クライアント数は、内部的なクライアントセッションと非内部的な

クライアントセッションの両方を示します（「セッション数」を参照）。

ワーカスレッド数 MicroKernel の並行プロセスの数。

187


通信統計情報の表示

［MicroKernel］メニューから［通信］をクリックします。［MicroKernel 通信統計情報］ダイアログが表示されます。

図 8 ［MicroKernel 通信統計情報］ダイアログ

ユーザー数同時に接続しているユーザー数。この大値は、使用許諾契約書に従って許可される、大ユーザー

数です。

セッション数データベースエンジンによって使用されているセッション数。「使用されているセッション数」は端的

に「セッション数」ともいいます。この大値は、使用許諾契約書に従って許可される大セッショ

ン数を示します。この大値は、「セッショ数の制限値」ともいいます。

セッション数は、トランザクショナルインターフェイスまたはリレーショナルインターフェイスを介

して確立されたすべてのセッションを示します。

セッション数に関するメッセージは、 Pervasive PSQL のさまざまなログリポジトリに記録されます。

『Pervasive PSQL User's Guide』の「Pervasive PSQL メッセージログ」を参照してください。

データベースエンジンは、 Pervasive PSQL システムファイル、メタデータファイル、 dbnames.cfg およびデフォルトのシステムデータベースへのアクセスなど、独自の内部処理用にさまざまなセッショ

ンを使用します。これらの内部セッションについてはセッション数を消費しません。

使用中データ MB 同時に開く全データファイルのサイズ（MB 単位）。この大値は、使用許諾契約書に従って許可され

る、同時に開く全データファイルの総量です。この大値は、「使用データの制限値」ともいいます。

使用データの値は、データファイルが初めて開かれたときに増加します。データファイルが既に開か

れていれば、それ以降に開く際には総量に加算されません。使用データは、開くファイルのサイズが

増加した場合にも増えます。既に開かれているファイルのサイズが大きくなって使用データの制限を

超えても、そのファイルに対する操作は引き続き許可されます。

使用データの値は、データファイルを開いた後のユーザーがそのデータファイルを閉じたとき減少

します。複数のユーザーが同じデータファイルにアクセスできるので、そのデータファイルを開いた

すべてのユーザーがそのファイルを閉じないと使用データは減少しません。

データに関するメッセージは、Pervasive PSQL のさまざまなログリポジトリに記録されます。『PervasivePSQL User's Guide』の「Pervasive PSQL メッセージログ」を参照してください。

データベースエンジンは、 Pervasive PSQL システムファイル、メタデータファイル、 dbnames.cfg およびデフォルトのシステムデータベースなど、独自の内部処理用にさまざまなファイルを使用します。

内部処理に使用するファイルによって使用データの値が増えることはありません。

大量レコードの挿入直後にファイルを閉じた場合、Monitor ではそのファイルのサイズの変更が直ちに

反映されないので注意してください。たとえば、そのファイルに関する［使用中データ MB］の統計

情報は、次回そのファイルが読み取りまたは書き込みのために開かれるまで更新されません。

トランザクション数トランザクションの数。このリソースの大値に制限はありません。

ロック数レコードロックの数。このリソースの大値に制限はありません。

188


このダイアログでは、 MicroKernel が後に起動されてから現在までのデータベースエンジンの通信統計情報が

表示されます。［MicroKernel 稼働時間］セクションには、 MicroKernel が起動されている時間が、週、日、時、

分、秒で示されます。

該当する場合、このダイアログではリソースに対して以下の統計情報が表示されます。

現在値－そのリソースの現在の値を表示。

ピーク値－ MicroKernel が起動してから現在までにそのリソースが記録した高値を表示。

大値－そのリソースで使用できる大値を表示。

以下の通信リソースの動作状況を監視できます。

MicroKernel 稼働時間 MicroKernel が起動されている時間が、週、日、時、分、秒で示されます。

処理済リクエスト総数データベースエンジンが処理している、ワークステーションやリモート、サーバーベース

アプリケーションからのリクエストの数。

合計値－データベースエンジンの起動時から現在までに処理されたリクエストの数。

増加値－［通信統計情報］ダイアログの起動時から現在までのリクエストの数。 0 にリ

セットするには、［増加値をリセット］をクリックします。

SPX 処理済リクエスト数データベースエンジンが処理している、クライアントやリモート、サーバーベースアプ

リケーションからの SPX リクエストの数。




TCP/IP 処理済リクエスト数データベースエンジンが処理しているクライアントやリモート、サーバーベースアプリ

ケーションからの TCP/IP リクエストの数。




NetBIOS 処理済リクエスト数データベースエンジンが処理している、クライアントやリモート、サーバーベースアプ

リケーションからの NetBIOS リクエストの数。




接続タイムアウト数 Auto Reconnect がクライアントに再接続を試行するときのタイムアウトの回数。「自動再接

続タイムアウト」も参照してください。




接続復元数 AutoReconnect 機能が接続タイムアウトから回復に成功した回数を示します。




通信スレッド数 MicroKernel で現在処理中のリモートリクエストの数。ここには、ローカルのリクエスト

についての情報は含まれません。処理中のリモートおよびローカルスレッドの合計につい

ては、「リソース使用状況の表示」を参照してください。

データベースエンジンは必要に応じて、通信スレッド数を許容される大値まで動的に増

加させます。 Windows および Linux プラットフォームでは、大値は 1,024 です。

通信スレッドは Monitor のリクエストを処理するためにも使用されるので、現在の通信ス

レッド数にはこの数も含まれています。この状態は正常です。

189


リレーショナルインターフェイスリソースの監視

このセクションでは、リレーショナルインターフェイスの監視について説明します。

「SQL アクティブセッションの表示」

「SQL セッション情報」

SQL アクティブセッションの表示

SQL アクティブセッションでは、リレーショナルインターフェイスへの接続を介して確立されたセッションの

みを表示します。（セッションの確立がトランザクショナルインターフェイス経由かリレーショナルインター

フェイス経由かに関わらず）すべてのセッションを表示させる場合は、「セッション情報の表示」を参照してくだ

さい。

SQL アクティブセッションを表示するには

［SQL］メニューの［アクティブな接続］をクリックします。［SQL アクティブセッション］ダイアログが表示

されます。

図 9 ［SQL アクティブセッション］ダイアログ

SQL セッション情報

ダイアログ上部の［アクティブセッション］ラベルには、SQL アクティブセッションの数が表示されます。［ユー

ザー名］ボックスには、データベースエンジンに接続しているユーザー名のリストが表示されます。ユーザー名

は、デフォルトで Windows のログイン ID が設定されていますが、これが使用不可の場合、ユーザー名は［不明］

に設定されます。

リモートセッション総数データベースエンジンに接続したリモートクライアントの数。大数は動的で、ゼロが


SPX リモートセッション数 SPX プロトコルを介してデータベースエンジンに接続したリモートクライアントの数。

TCP/IP リモートセッション数 TCP/IP プロトコルを介してデータベースエンジンに接続したリモートクライアントの数。

NetBIOS リモートセッション数 NetBIOS プロトコルを介してデータベースエンジンに接続したリモートクライアントの数。

190


選択したユーザー名についての詳細情報が［セッション情報］セクションに表示されます。

SQL アクティブセッションのリストをリフレッシュするには

1 ［セッションリストのフレッシュ］をクリックします。

2 上記以外の方法を用いる場合は、［自動リフレッシュ］オプションを選択し、［リフレッシュレート］に設定

した一定時間間隔でリフレッシュを行います。「Monitor オプションを設定するには」を参照してください。

SQL アクティブセッションを削除するには

1 ［ユーザー名］リスト内で目的のユーザー名をクリックします。

2 ［セッションの削除］をクリックします。

アクティブセッションによる大きな SQL ブロックの実行中にそのセッションを削除すると、一時的な接続

状態として「無効」になる可能性があります。このセッションは、データベースエンジンが適切な終了ポイ

ントに到達すると表示されなくなります。

注意アクティブセッションを削除すると、その時点で発生している処理によっては、データが不正になる、

レコードが不完全になる、またはトランザクションが中止される可能性があります。

クライアントホスト名選択されたユーザー名に対応するクライアントマシンの名前。使用不可の場合、［不明］に設定

されます。

ネットワークアドレス選択されたユーザー名のクライアントマシンの IP または SPX アドレス。使用不可の場合、［不

明］に設定されます。

表示される値には、 "IP"、 "SPX"、 "Shared Memory" および " 不明 " があります。

クライアントアプリケー

ション

接続したアプリケーションまたはモジュール。使用不可の場合、［不明］に設定されます。

データソース名クライアントアプリケーションによって参照される、 DSN の名前。

接続状態選択されたユーザーの接続状態。接続状態のタイプは次のとおりです。

［アクティブ］－セッションには開いているファイルがあります。

［アイドル］－セッションには開いているファイルがありません。

［無効］－アクティブセッションは削除されていますが、 SQL コードの処理が終了されていない

ことを示す一時的な状態。適切な終了時点で、そのセッションは［SQL アクティブセッション］

ダイアログに表示されなくなります。

［不明］－状態を入手できません。

アクティブ / アイドル時間接続がアクティブまたはアイドルになってからの時間（ミリ秒単位）を表示します。

総接続時間接続が確立されてからの時間（秒単位）を表示します。

191


Monitor のコマンドラインインターフェイス

Monitor のコマンドラインインターフェイス（CLI）バージョンは、 GUI バージョンと同様の監視機能を提供し

ます。

CLI Monitor は、 Pervasive PSQL でサポートされる Windows および Linux プラットフォームで動作します。

Windows では、実行可能プログラムは bmon.bat です。これはデフォルトで Pervasive PSQL インストールディ

レクトリ内の \bin ディレクトリにインストールされます。『Getting Started with Pervasive PSQL』の「PervasivePSQL ファイルはどこにインストールされますか？」を参照してください。

Linux では、実行可能プログラムの名前は bmon といい、デフォルトでは /usr/local/psql/bin ディレ

クトリにあります。 Linux 上で bmon を実行するには、一定の要件を満たしている必要があります。この要件

は、もう 1 つの Java ユーティリティである bcfg と同様です。「Linux での bcfg の実行要件」および「Linuxでの bcfg の実行に関するトラブルシューティングガイド」を参照してください。

構成ファイル

bmon はその設定を提供するために構成ファイルを必要とします。 Pervasive PSQL は、 monconfig.txt という名前

のサンプルの構成ファイルを用意しています。このファイルは、デフォルトで Pervasive PSQL のインストール

ディレクトリの \bin ディレクトリにあります。『Getting Started with Pervasive PSQL』の「Pervasive PSQL ファイ

ルはどこにインストールされますか？」を参照してください。

構成できる設定については、サンプル構成ファイル内のコメントを参照してください。

監視の出力

bmon からの出力をコンソールおよびログファイルのいずれかまたは両方にリダイレクトすることができます。

たとえば、アプリケーションは、コンソールから、またはログファイルで特定の状態を調べてから適切な動作を

行うことができます。

設定ファイルに出力先を指定することができます。

コマンド構文bmon -f [filepath]config_file [-runonce]

オプション

runonce パラメーターを省略した場合のキーボードのキー応答

runonce パラメーターは省略可能です。省略した場合、ユーティリティは設定ファイルの設定を実行し、次にリフ

レッシュレートに指定された時間停止します。停止中に、表 42 に示すキーボードのキー応答をユーティリティ

に送ることができます。

-f 設定ファイルが入力をユーティリティに提供することを指定するために必要なパラメーターです。

filepath 設定ファイルのパス。省略すると、 bmon は設定ファイルをローカルディスクで検索します。

config_file 設定ファイルの名前。ファイル名は、自由に選択できます。

-runonce ユーティリティを 1 度実行したら終了するように指示するオプションパラメーターです。 runonceパラメーターは、 bmon をバッチファイルで使用する場合に特に役立ちます。

「runonce パラメーターを省略した場合のキーボードのキー応答」も参照してください。

192

Monitor のコマンドラインインターフェイス

リフレッシュレートにゼロを設定すると、ユーティリティは有効なキーボードのキー応答があるまで無限に停止

します。設定ファイルのリフレッシュレート設定（refreshrate）により、停止する時間を指定します。デフォル

トで、リフレッシュレートは小値である 5 秒に設定されます。

表 42 bmon リフレッシュレートおよびキーボードのキー応答

リフレッシュレートキーボードのキー応答

refreshrate=0 （有効なキーボードのキー応答を受け取るまで停止）

Q （または q） + Enter は、 bmon の実行を停止します。

R（または r） + Enter は、監視を更新します（bmon を再実行します）。

refreshrate=seconds_to_pause

seconds_to_pause は 5 以上の整数

（seconds_to_pause 秒の間停止）

Q （または q） + Enter は、 bmon の実行を停止します。

193


194

12
Btrieve オペレーションのテスト
Function Executor ユーティリティで Btrieve オペレーションを実行する方法


「Function Executor の概念」

「Function Executor のグラフィカルユーザーインターフェイス」

「Function Executor での作業」

195


Function Executor の概念


「概要」

「Function Executor でできること」

「Function Executor の機能」

「Function Executor の自動モード」

「詳細情報を入手するには」

概要

Function Executor は Windows 上で動作します。この対話型ユーティリティを使用すると、 Btrieve オペレーション

がどのように動作するかを確認することができます。この章では、トランザクショナルインターフェイスのオペ

レーションを「Btrieve オペレーション」と呼びます。

また、 Btrieve オペレーションを一度に 1 つずつ実行できるため、アプリケーション開発者は Function Executor を使って、 Btrieve アプリケーションのオペレーションをシミュレートすることができます。このシミュレーション

は、アプリケーションの残りの部分のデータベース呼び出しから分離しているので、プログラムのテストおよび

デバッグに役立ちます。

Function Executor は、本来アプリケーション開発者向けのツールです。この章では、 Btrieve オペレーションの基

礎知識があることを前提に説明を進めます。 Btrieve オペレーションの詳細については、開発者リファレンスの

『Btrieve API Guide』を参照してください。

Function Executor でできること

Btrieve オペレーションを実行しながらメモリ構造の内容を監視することができます。

一連の Btrieve オペレーションをキャプチャして履歴ファイルとして保存し、後で再生することができます。

Btrieve クライアント、ローカルエンジンおよびリモートエンジンのバージョンを表示します。

データファイルの Btrieve 特性を表示し、これらをテンプレート（ディスクリプションファイル）として保

存したり、これらの特性に基づいて新しいファイルを作成したりすることができます。詳細については、「ファ

イル統計情報」を参照してください。

Function Executor の機能

Function Executor の機能は以下のとおりです。

「エディターステータスバー」

「統計情報」

「Get および GetExt」

「トランザクションツールバー」

「ログインダイアログ」

「履歴ログ」

「任意のデータ型での表示」

196


エディターステータスバー

ステータスバーには以下の要素があります。

統計情報

［ファイル統計情報］アイコンをクリックすると、現在開いているファイルについての統計情報を一覧表示したダ

イアログボックスが表示されます。これらの統計情報は、テキストファイルに出力するか、 BUTIL-CREATE で使用可能なディスクリプションファイルに保存できます（同一の特性を持つ空の新規ファイルを作成することも

できます）。

Get および GetExt［Get］メニューから、テーブル内にある先頭レコード、次レコード、前レコード、末尾レコードを取得すること

ができます。［GetExt］メニューには、［Goto Percent （パーセンテージによるレコードの取得）］、［Get Position（物理位置の取得）］、［Find Percent （レコード位置のパーセンテージを取得）］の各コマンドがあります。

開いているファイルのウィンドウの下部にあるエディターウィンドウの

ステータスバーに新 / 現在のステータスコードが表示され、新のス

テータスがゼロ以外の場合には赤色で表示されます。

ステータスコードにマウスカーソルを移動すると、そのステータスにつ

いての説明と、原因となったオペレーションが表示されます。これらのス

テータスコードのヘルプ全体を表示するには、赤色で表示されている部

分をクリックします。詳細については、「ステータスコードのヘルプを見

るには」を参照してください。

カーソルが Function Executor メインウィンドウの入力領域にあるときに

は、ステータスバーにはバッファー内でのオフセットが表示されます。つ

まり、現在の位置のバイトを 16 進数、 10 進数、 ASCII 値で表した値が表

示されます。

キューに複数の項目がある場合には、オペレーションがいくつ実行された

のかもステータスバーに表示されます。通常、 1 / 1 と表示されますが、複

数のオペレーションを実行している場合には実行されるオペレーション

の数が表示されます。

トランザクションに入ると、その状態もステータスバーに表示されます。

197


［Get］コマンドと［GetExt］コマンドは、メニューバーとツールバーから使用できます。ツールバーには、［Step］（物理的）と［Get］（論理的）があり、ファイルの自然の順序で（物理的）、または特定の順序で（論理的）移動

できます。

［Goto Percent （パーセンテージによるレコードの取得）］では、ファイルの物理レイアウト内での特定の地点に

移動するか、あるいはそのファイル内に定義されているキーを定めて、任意のキーパスをたどっていくかどうか

の選択ができます。［ロック］グループボックスのオプションボタンを使用して、ロックバイアスを設定するこ

ともできます。

［Find Percent （レコード位置のパーセンテージを取得）］は、［Goto Percent （パーセンテージによるレコードの

取得）］の逆です。ファイル内を論理的に移動しているか、物理的に移動しているかによって、データ内での位置

を示します。

トランザクションツールバー

トランザクションツールバーを使用すると、トランザクションの開始、終了、中止を行うことができます。

Transaction API のすべてをこのツールバーで設定することができ、オペレーションはすぐに実行されます。トラ

ンザクションのステータスは、そのクライアント ID 用に開いているすべてのファイルに影響するため、メイン

ウィンドウのステータスバーにも表示されます。

ログインダイアログ

ログインダイアログボックスを使用すると、 GUI インターフェイスを介して Btrieve ログイン操作を実行するこ

とができます。ログインダイアログボックスの詳細については以下のトピックを参照してください。

「ログインおよびログアウト」

「Pervasive PSQL データベース」

「Pervasive PSQL セキュリティ」

198


履歴ログ

Function Executor ユーティリティを使用してオペレーションを実行すると、これらは履歴ログに記録されます。こ

のログを使用して、ログに含まれるオペレーションを実行したり、履歴をファイルとして保存し後で再読み込み

して同じ手順を行うことができます。

履歴ログの詳細については以下のトピックを参照してください。

「履歴」

「履歴の作業」

任意のデータ型での表示

ファイルが開いているとき、バッファー内の任意の場所を右クリックし、［表示形式］をクリックします。ダイア

ログボックスが表示され、選択したバッファー位置のバイト数を任意のデータ型で表示できます。

表 43 に Function Executor で使用できるコントロールを示します。

表 43 Function Executor のコントロール

コントロール説明

履歴コマンドの繰り返しができます。

作成新規ファイルを作成できます。

ファイル統計情報 BSTAT 関数の情報を示します。この統計情報は印刷できます。

MDI Multiple Document Interface によって、複数のファイルを開くことができます。

199


Function Executor の自動モード

開いているファイルごとに（「アプリケーションウィンドウ」を参照） Btrieve オペレーションを実行する際に

Function Executor を使用するかどうかを選択することができます。Function Executor を使用する方法としない方法

で設定を変更する必要はありません。自動モードと手動モードのどちらを使用するかは、どの GUI コントロール

を使用するかによって決まります。

図 10 自動モードと手動モードのコントロール

メモメニュー（「アプリケーションウィンドウ」を参照）での選択も自動モードの一部として行われます。

自動モード領域のボタンをクリックすると、ユーティリティは以下のような支援を行います。

データバッファーとデータ長は、自動的にステータスコード 22 を防ぐように設定されます。

情報は操作に応じて適切に要求されます。

詳細情報を入手するには

Function Executor はプログラム開発者にとって有益なツールですが、 Btrieve の実際的な基礎知識があることを前

提にしています。このユーティリティのすべての機能を理解するには、以下のトピックを参照してください。

『Pervasive PSQL Programmer's Guide』の「トランザクショナルインターフェイスの基礎」。このマニュアル

は、 Pervasive PSQL 開発者リファレンスに含まれています。

『Btrieve API Guide』の「Btrieve API オペレーション」。このマニュアルは、 Pervasive PSQL 開発者リファレ

ンスに含まれています。


リセットクライアント ID をリセット

ストップ Btrieve の停止

バージョン Btrieve バージョン情報

表 43 Function Executor のコントロール

コントロール説明

200

Function Executor のグラフィカルユーザーインターフェイス


このセクションでは、 Function Executor のグラフィカルユーザーインターフェイス（GUI）のオブジェクトにつ

いて説明します。

「アプリケーションウィンドウ」

「メインウィンドウ」

「ログインおよびログアウト」

「［ファイルのオープン］ダイアログ」

「Btrieve ファイルの作成」

「ファイルの作成用ダイアログ GUI のリファレンス（高度）」

「トランザクション」

「ファイル統計情報」

「履歴」

201


アプリケーションウィンドウ

下の表は次の図のウィンドウコンポーネントの説明です。画像上のそれぞれの領域をクリックするとその詳細が


表 44 Function Executor アプリケーションウィンドウ

GUI オブジェクト説明関連情報

［ファイル］メニュー以下のコマンドおよび Btrieve オペレーションが実行できます。

Login および Logout

Open および Close

New

Print Setup

Set Owner Name および Clear Owner Name

Continuous オペレーションの開始または終了

Reset、 Stop および Exit

「オペレーション作業の

実行」

「ファイルを開く作業」

［Get］メニュー以下の Btrieve オペレーションが実行できます。

Get First および Get Next

Get Previous および Get Last

Get Greater Than および Get Greater or Equal

Get Less および Get Less or Equal


実行」

［GetExt］メニュー以下の Btrieve オペレーションが実行できます。

Goto Percent

Get Position

Find Percent


実行」

［Step］メニュー以下の Btrieve オペレーションが実行できます。

Step First および Step Next

Step Previous および Step Last


実行」

［Update］メニュー以下の Btrieve オペレーションが実行できます。

Insert、 Update および Delete

このメニューを使用してロックを解除することもできます。


実行」

202


［表示］メニュー GUI 要素を表示することができます。

ツールバー（メインおよびトランザクション）

履歴ウィンドウ

ファイル統計情報ウィンドウ

Btrieve Version オペレーションを使用したエンジンのバー

ジョン


［ツール］メニュー以下の Btrieve オペレーションが実行できます。

Get Directory および Set Directory

［ウィンドウ］メニューウィンドウ操作が実行できます。

［ウィンドウを重ねて表示］および［ウィンドウを並べて表示］

開いているウィンドウの一覧から選択

［ヘルプ］メニューこのユーティリティのヘルプリソースを一覧から選択すること

ができます。

「ステータスコードのヘ

ルプを見るには」

［開く］ボタンダイアログボックスを表示し、開く Btrieve ファイルを選択しま

す。


［新規作成］ボタンダイアログボックスを表示し、新規 Btrieve ファイルを作成する

ことができます。

「Btrieve ファイルを作成

する作業」

［リセット］ボタン現在のクライアント接続をリセットし（Btrieve オペレーション

28）、そのクライアント ID で開いているすべてのファイルを閉

じます。

［停止］ボタントランザクショナルサービス（Btrieve オペレーション 25）を終

了させ、開いているすべてのファイルを閉じます。

統計情報現在開いているファイルの統計情報を一覧表示するダイアログ

ボックスを表示します。これらの統計情報をテキストファイル

に出力したり、 BUTIL -CREATE で使用できるディスクリプショ

ンファイルに保存することができます。

［バージョン］ボタン実行中の Pervasive PSQL のバージョン情報を（Btrieve オペレー

ション 26 を使用して）表示します。開かれているファイルがな

い場合には、リクエスター DLL とローカル MicroKernel エンジ

ンについての情報が表示されます。リモートサーバーでファイ

ルを開いている場合、サーバーとリクエスター DLL についての

情報が表示されます。

ヘルプの表示ゼロ以外のステータスコードを受け取ったときにポップアップ

ダイアログボックスを表示するかしないかを切り替えます。

履歴の表示履歴ウィンドウを表示するかしないかを切り替えます。「履歴ウィンドウを表示

するには」

「履歴」

「履歴ログ」



203


オペレーションカウント現在のオペレーション数を示します。

繰り返しの値に 2 以上を設定したときに使用されます。


実行」

トランザクションの状態トランザクションの現在の状態を示します。以下のいずれかにな

ります。

空白（トランザクションが 1 つも有効でない場合）

並行（Concurrent）

排他（Exclusive）


実行」

「トランザクション」



204


メインウィンドウ

すべての開いているファイルについて、メインウィンドウが表示されます。画像上のそれぞれの領域をクリック

するとその詳細が表示されます。

表 45 Function Executor メインウィンドウ（オープンファイル用）


タイトルバー開いているデータファイルの絶対パスを一覧表示します。「Function Executor でデータファ

イルを開くには」

データバッファーデータの値を指定します。読み取りや書き込みオペレーショ

ンでは、 Data Buffer にレコードが含まれています。ほかのオ

ペレーションには、データベースエンジンでオペレーション

の処理に必要なファイルスペック、フィルター条件、その他

の情報が Data Buffer に含まれています。このコントロールは

Data Buffer パラメーターに対応するものです。

キーバッファー Btrieve オペレーションを実行するデータファイルのパスを

指定します。

Step と Get Step および Get オペレーションを切り替えます。

Get/Step First Get Next または Step Next オペレーションを実行します。「オペレーション作業の実行」

Get/Step Prev Get Previous または Step Previous オペレーションを実行しま

す。

「オペレーション作業の実行」

Get/Step Next Get Next または Step Next オペレーションを実行します。「オペレーション作業の実行」

Get/Step Last Get Last または Step Last オペレーションを実行します。「オペレーション作業の実行」

Get Equal Get Equal オペレーションを実行します。「オペレーション作業の実行」

Get Less Than Get Less Than オペレーションを実行します。「オペレーション作業の実行」

Get Greater Than Get Greater Than オペレーションを実行します。「オペレーション作業の実行」

Get Less Than or Equal Get Less Than または Get Equal Than オペレーションを実行し

ます。


Get Greater Than orEqual

Get Greater Than または Get Equal Than オペレーションを実行

します。


205


Get/Find Percent Get Percent または Find Percent オペレーションを実行します。「オペレーション作業の実行」

Insert Insert オペレーションを実行します。「オペレーション作業の実行」

Update Update オペレーションを実行します。「オペレーション作業の実行」

Delete Delete オペレーションを実行します。「オペレーション作業の実行」

Cancel 後に行った変更をキャンセルします。

Unlock すべてのロックを解除します。

Set Bookmark またはGoto Bookmark

前もって定義しておいたブックマークに設定または位置付

けます。

キー番号ほとんどの Get オペレーションで、現在のオペレーションが

従うことになるキー番号またはインデックスパスを指定し

ます。ほかのオペレーションには、ファイルオープンモー

ド、暗号化、論理ディスクドライブなどの情報を指定するも

のもあります。このコントロールは Key Number パラメー

ターに対応するものです。

キーオンリーデータではなくキーのみを取得することを指定します。

繰り返しオペレーションを指定した回数だけ繰り返します。

ロック現在のオペレーションで行いたいロック動作を指定します。

オペレーションコード現在のオペレーションコードとそのバイアス（ある場合）を

示します。デフォルト設定は、 0 です。 Btrieve オペレーショ

ンコードに精通している場合は、目的のコードを入力するこ

とができます。慣れていなければ、［リスト］ボックスを使

用してオペレーションを指定します。このコントロールは、

オペレーションコードパラメーターに対応するものです。


［実行］ボタン現在指定されているオペレーションを実行します。「オペレーション作業の実行」

オペレーションリスト Btrieve オペレーションとそのコードをリストします。デフォ

ルトは Open （0）です。実行するオペレーションの頭文字を

入力すれば、リスト内ですぐに移動ができます。


データ長データバッファーの長さ（バイト単位）を指定します。デ

フォルトは、 1024 です。データバッファーを必要とする各

オペレーションでは、バッファー長を必ず指定してくださ

い。多くのオペレーションでは、データベースエンジンによ

り Data Length に値が返されます。一般には、オペレーショ

ンの実行前に、Data Length を必ず指定してください。このコ

ントロールは Data Buffer Length パラメーターに対応するも

のです。


ステータスコードインジケーター

データベースエンジンで返された数値のステータスコード

と、Btrieve オペレーションの結果を示す短いメッセージが表

示されます。

これらのステータスコードやメッセージについての詳細は、

『Status Codes and Messages』マニュアルを参照してください。

「ステータスコードのヘルプを見

るには」

Continuous オペレー

ションインジケーター

ファイルが Continuous オペレーションモード（オペレーショ

ン 42）にある場合、ファイルウィンドウの下行に以下を

表示します。

「Continuous オペレーションの使

用」

表 45 Function Executor メインウィンドウ（オープンファイル用）


206


ログインおよびログアウト

ログインおよびログアウトダイアログボックスを使用すると、 Btrieve のログインおよびログアウトオペレー

ションを個々のデータベースエンジンに対して実行することができます。画像上のそれぞれの領域をクリックす

るとその詳細が表示されます。

図 11 ログインダイアログ

図 12 ログアウトダイアログ

表 46 Function Executor ログインおよびログアウトダイアログ

GUI オブジェクト説明

サーバーログインまたはログアウトしたいデータベースが存在するサーバーを指定します。 Linux オペレー

ティングシステム上のデータベースにアクセスするにはサーバー名が必要なので注意してください。

『Pervasive PSQL Programmer's Guide』の「データベース URI」も参照してください。

データベース認証を求めるサーバー上のデータベースを指定します。

ユーザー名データベースに対して認証を求めるユーザーの名前です。

パスワードユーザー名に対するパスワードです。

クライアント ID このログインまたはログアウトを特定のクライアント ID にのみ適用する場合は、［使用］をクリック

して範囲を指定します。それ以外の場合は、そのままにしておきます。

『Btrieve API Guide』の「クライアント ID」を参照してください。

URI 文字列情報をフォームに入力すると、選択した結果の URI がこの領域に表示されます。

207


［ファイルのオープン］ダイアログ

このダイアログを使用すると、ファイルを開くことができます。画像上のそれぞれの領域をクリックするとその

詳細が表示されます。

表 47 Function Executor ファイルのオープンダイアログ


ファイル名開くファイルのロケーションと名前を指定します。「ファイルを開く作業」

オーナーネーム Btrieve ファイルに関連付けられているパスワードを指定します。指

定した場合、 Btrieve ファイルにアクセスするためにはオーナー

ネームが必要です。オーナーネームは、システムのユーザー名と

は無関係です。オーナーネームは、ファイルパスワードと考えて

ください。

短いオーナーネームは半角 8 文字までの範囲で指定できます。長

いオーナーネームは半角 24 文字までの範囲で指定できます。ただ

し、長いオーナーネームを指定した場合、そのデータファイルは

Pervasive PSQL v10 SP1 より前のデータベースエンジンで読み取る

ことができないので注意してください。また、長いオーナーネーム

を使用したデータファイルは、 v9.5 より前のファイル形式にリビ

ルドしようとする場合、そのオーナーネームを初に削除してお

かないとリビルドすることができません。

オーナーネームは、長いものでも短いものでも、その大長（8 または 24 バイト）に満たない部分は空白が埋め込まれます。




モードファイルを開くときの状態を指定します。この状態に基づき、デー

タベースエンジンは開くファイルに適用する条件を識別します。た

とえば、ファイルの読み取りは可能だが更新はできない（リードオ

ンリー）という条件が可能です。


モードの説明については、開発

者リファレンスの『Btrieve APIGuide』の「オープンモード」を


クライアント ID このログインを特定のクライアント ID にのみ適用する場合は、［使

用］をクリックして範囲を指定します。それ以外の場合は、そのま

まにしておきます。


共有データベースエンジンは、 " 共有 " オプションを無視します。 " 共

有 " オプションは、このエンジンのレガシーバージョンである

Btrieve 6.15 のみに適用されます。


208


Btrieve ファイルの作成

このダイアログボックスを使用すると、Btrieve ファイルを作成することができます。画像上のそれぞれの領域を

クリックするとその詳細が表示されます。

表 48 Function Executor ファイルの作成ダイアログ


ファイル名作成するファイルのロケーションと名前を指定します。「Btrieve ファイルを作成する

作業」

オーナーネーム Btrieve ファイルに関連付けられているパスワードを指定します。指定

した場合、Btrieve ファイルにアクセスするためにはオーナーネームが

必要です。オーナーネームは、システムのユーザー名とは無関係です。

オーナーネームは、ファイルパスワードと考えてください。

短いオーナーネームは半角 8 文字までの範囲で指定できます。長い

オーナーネームは半角 24 文字までの範囲で指定できます。ただし、長

いオーナーネームを指定した場合、そのデータファイルは PervasivePSQL v10 SP1 より前のデータベースエンジンで読み取ることができ

ないので注意してください。また、長いオーナーネームを使用した

データファイルは、 v9.5 より前のファイル形式にリビルドしようとす

る場合、そのオーナーネームを初に削除しておかないとリビルドす

ることができません。

オーナーネームは、長いものでも短いものでも、その大長（8 また

は 24 バイト）に満たない部分は空白が埋め込まれます。

「Btrieve ファイルを作成する

作業」

「Pervasive PSQL セキュリ

ティ」を参照してください。

モードファイルを開くときの状態を指定します。この状態に基づき、データ

ベースエンジンは開くファイルに適用する条件を識別します。たとえ

ば、ファイルの読み取りは可能だが更新はできない（リードオンリー）

という条件が可能です。


作業」

モードの説明については、開

発者リファレンスの『BtrieveAPI Guide』の「オープンモー

ド」を参照してください。

クライアント ID このログインを特定のクライアント ID にのみ適用する場合は、［使用］

をクリックして範囲を指定します。それ以外の場合は、そのままにし

ておきます。


作業」

共有データベースエンジンは、 " 共有 " オプションを無視します。 " 共有 "オプションは、データベースエンジンのレガシーバージョンである

Btrieve 6.15 のみに適用されます。

209


ファイルの作成用ダイアログ GUI のリファレンス（高度）

このダイアログボックスを使用すると、作成しようとしているファイルに、さらに別の属性を指定することがで

きます。画像上のそれぞれの領域をクリックするとその詳細が表示されます。

表 49 Function Executor ファイルの作成ダイアログ（高度）


［キー］および［セグメント］

コマンド

キーの追加と削除や、キーセグメントの追加、挿入、削除が

行えます。

「Btrieve ファイルを作成す

る作業」

ファイル仕様ファイルの仕様の表示、およびその編集が行えます。「Btrieve ファイルを作成す

る作業」

「レコードおよびページ圧縮」

統計情報ファイルに関する情報を提供します。読み取り専用です。「Btrieve ファイルを作成す

る作業」

キーとセグメントの行列ファイルのキーとセグメントの開始位置、長さ、属性および

データ型を表示します。行をクリックすると、下方のキーと

セグメントの各ブロックで情報が表示されます。必要であれ

ば、この情報は変更することもできます。


る作業」

キーキーの仕様の表示、およびその編集が行えます。「Btrieve ファイルを作成す

る作業」

セグメントセグメントの仕様の表示、およびその編集が行えます。「Btrieve ファイルを作成す

る作業」

各種コマンドボタンデータファイルやディスクリプションの作成、あるいはダイ

アログボックスで行った編集をキャンセルすることができま

す。


る作業」

210



このダイアログボックスを使用すると、 Function Executor セッション中にトランザクションを制御することがで

きます。画像上のそれぞれの領域をクリックするとその詳細が表示されます。

表 50 Function Executor トランザクションダイアログ


メインアプリケーションウィンドウプログラムの主な機能です。「アプリケーション

ウィンドウ」

トランザクションの種類排他的トランザクションまたは並行トランザクションの

どちらを使用するかを指定します。

ロック情報トランザクションで使用するロックの種類を指定します。

［トランザクションの開始］ボタントランザクションを開始します。

［トランザクションのコミット］ボタンアクティブなトランザクションをコミットします。

［トランザクションの中止］ボタンアクティブなトランザクションを中止し、行われた変更

をロールバックします。

ファイル領域この領域には開いているファイルが 1 つ以上含まれます。「メインウィンドウ」

トランザクションインジケーター現在トランザクション内にあるかどうかを示します。こ

こには " 並行 " または " 排他 " と表示されます。

211


ファイル統計情報

このダイアログボックスを使用すると、Btrieve ファイルの統計情報を表示することができます。画像上のそれぞ

れの領域をクリックするとその詳細が表示されます。

表 51 Function Executor ファイル統計情報ダイアログ

GUI オブジェクト説明

ファイル情報ファイルの統計情報を表示します。

フラグこのファイルに設定されているフラグを表示することができます。ダイアログボックス内の一覧で、設

定されているすべてのフラグの隣にはチェックマークが付きます。

キーこのファイルに定義されているキーを表示することができます。

キーの凡例 1 文字の値でこのファイルのキー属性を示します。

D = DUP （重複可能）

M = MOD （変更可能）

R = REPEAT_DUPS_KEY （繰り返し重複キー）

A= NUL （全セグメントヌルキー）

L = MANUAL_KEY （一部セグメントヌルキー）

< = DESC_KEY （キー値を表します）

I = NOCASE_KEY （大文字小文字無視キー）

『Pervasive PSQL Programmer's Guide』の「キー属性」も参照してください。

［印刷］ボタンファイル統計情報を印刷することができます。［ファイル］メニューを使用してプリンターを設定しま

す。

［保存］ボタン現在のファイル統計情報をディスクリプションファイルに保存することができます。このディスクリプ

ションファイルを使用して、後で同じ属性を持つファイルを新規作成することができます。

［ファイルの新規

作成］ボタン

これらのファイル統計情報に基づいて新規ファイルを作成することができます。

212


履歴

このダイアログボックスを使用すると、これまでに実行したすべてのオペレーションを見ることができます。画

像上のそれぞれの領域をクリックするとその詳細が表示されます。

表 52 Function Executor 履歴ダイアログ


［ファイル］メ

ニュー

以下の操作が実行できます。

履歴ファイルのインポート

履歴ファイルのエクスポート

履歴ウィンドウを閉じる

［設定］メニュー履歴ウィンドウの表示属性を指定することができます。

終了時に保存 - 履歴ウィンドウで行ったカスタマイズをほかの

セッションでも使用できるように保存するかどうかを指定しま

す。

デフォルト - 履歴ウィンドウをデフォルトの設定にリセットし

ます。指定した設定はすべて取り除かれます。

ドッキング - 履歴ウィンドウの状態で、分離したウィンドウまた

は「アプリケーションウィンドウ」と一体化した状態とを切り

替えます。

手前に表示 - 履歴ウィンドウの状態を、フォーカスを失わない状

態と失う状態の間で切り替えます。

「履歴ウィンドウのドッキング

状態を切り替えるには」

「履歴ウィンドウの常に前面に

表示状態を切り替えるには」

「履歴ウィンドウをデフォルト

の設定にリセットするには」

［実行］コマンド［履歴の再生設定］ウィンドウをロードします。

オペレーション

の一覧

近実行したオペレーションを一覧表示します。各オペレーション

と共に以下の情報がログに記録されます。

ファイル ID

［オペコード名］チェックボックスの状態により、オペレーショ

ン名またはオペレーション番号。

そのオペレーションが実行されたときのステータスコード。

そのオペレーションが実行された回数。

そのオペレーションで設定されたキー番号。

キーバッファーの内容。

データバッファーの内容。


「履歴」

213


ロギング履歴一覧に将来のオペレーションを含めるか含めないかを切り替え

ます。

オペコード名オペレーション列に表示するオペレーションコード名（B_OPEN など）とオペレーションコード番号（B_OPEN に対する０）を切り

替えます。

表 52 Function Executor 履歴ダイアログ


214

Function Executor での作業


Function Executor での作業は以下のカテゴリにグループ化されています。

「Function Executor での作業の開始」



「Btrieve ファイルを作成する作業」


Function Executor での作業の開始

Function Executor ユーティリティを起動するには

1 オペレーティングシステムの［スタート］メニューまたはアプリ画面から、あるいは Pervasive PSQL ControlCenter の［ツール］メニューから Function Executor にアクセスします。

2 メインウィンドウ（図 13）が表示されます。

図 13 Function Executor メインウィンドウ

オペレーション作業の実行

Btrieve には数多くのオペレーションがあるため、この章ですべてを説明することはできません。次のセクション

では、一般的ないくつかのオペレーションと、 Function Executor を使ったそれらの新しい実行方法についても説

明します。

メモどのメニューからでもオプションを選択すれば、目的のオペレーションがすぐに実行されます。以前

のバージョンの動作のように、グリッドに自動入力したりコマンドの実行待ちになることはありません。ま

た、フォームを閉じると、開いているファイルは閉じられます。 Close オペレーションを手動で実行する必

要はありません。

215


全般的なオペレーション - 関連する作業

「ステータスコードのヘルプを見るには」

ほかの作業については、以下のセクションを参照してください。


「Btrieve ファイルを作成する作業」


ステータスコードのヘルプを見るには

1 Function Executor を使用してステータスコードを受け取った場合は、開いているファイルのステータスバー

に表示されます。

マウスを動かして赤色で表示されているステータスコード上に移動します。

図 14 ステータスコードを受け取る

2 ステータスコードインジケーターをクリックすると、図 15 のように、そのステータスコードの完全な説明

が表示されます。

図 15 ステータスコードの説明

ファイルを開く作業

Function Executor でデータファイルを開くには

1 ［ファイル］メニューの［開く］を選択します。次のダイアログボックスが表示されます。

216


図 16 ［Btrieve ファイルのオープン］ダイアログボックス

メモクライアント ID ：［使用］を無効にしている場合、 Function Executor では、 BTRV() 関数呼び出しが使

用されます。［使用］を有効にしている場合、そのファイルで実行される各オペレーションについて BTRVID()関数呼び出しが使用されます。［自動］を有効にしている場合、 Function Executor では、クライアント ID が自動的に作成されます。［自動］を無効にしている場合には、手動で値を入力できます。

2 ［参照］をクリックします。

3 目的のファイル名をダブルクリックします。

Function Executor でファイルを開くその他の方法

1） Windows エクスプローラーまたはオペレーティングシステムのフォルダービューから［Btrieve ファイルの

オープン］ダイアログボックス内にファイルをドラッグすることができます。ドラッグしたファイル名が［ファ

イル名］ボックスに入ります。

2）メインウィンドウには複数のファイルをドラッグすることができます。

3） 1 つのファイルを開いておけば（エディターウィンドウが使用可能になるので）、オペコード（オペレーショ

ンコード） 0 を使用して別のファイルを開くことができます。そのファイルは新しいウィンドウに表示されます。

4） DOS コマンドラインから Function Executor を起動し、ファイル名の一覧を指定して開くことができます。た

とえば、次のようなコマンドラインを使用すると、DEMODATA サンプルデータベースから 2 つのファイルを開

くことができます。

WBExec32 person.mkd billing.mkd

次の例のように、ワイルドカードを使用することもできます。

WBExec32 *.mkd

このコマンドを実行すると、ファイルの拡張子（種類）を Function Executor に関連付けることができます。たと

えば、 MKD、 BTR、 DAT またはその他の拡張子を Function Executor に関連付けることができます。関連付けされ

たファイルをエクスプローラー内でダブルクリックすると、そのファイルは自動的に Function Executor で開かれ

ます。

Btrieve ファイルを作成する作業

Function Executor で Btrieve ファイルを作成する方法には 2 つの方法があります。ファイルが既に開かれている場

合、それを基にクローンファイルを作成するか、始めから作成します。

注意同じディレクトリに、ファイル名が同一で拡張子のみが異なるようなファイルを置かないでください。

たとえば、同じディレクトリ内のデータファイルの 1 つに Invoice.btr、もう 1 つに Invoice.mkd という名前を

217


付けてはいけません。このような制限が設けられているのは、データベースエンジンがさまざまな機能で

ファイル名のみを使用し、ファイルの拡張子を無視するためです。ファイルの識別にはファイル名のみが使

用されるため、ファイルの拡張子だけが異なるファイルは、データベースエンジンでは同一のものであると

認識されます。

方法 1 ：現在のファイルをテンプレートとして使用する

1 ［ファイル］メニューの［新規作成］を選択します。次のダイアログボックスが表示されます。

図 17 ［ファイル定義の修正］ダイアログボックス

2 このダイアログボックスでキーの操作もできます。［キー］メニューから、［追加］、［削除］、［セグメント］

メニューから［追加］、［挿入］、［削除］のいずれかをクリックします。新規ファイルを BUTIL-create での使

用の目的でディスクリプションとして保存することもできます。［ディスクリプションとして保存］をクリッ

クし、ファイルの保存先の名前とロケーションを示します。

3 ファイルを作成するには、［作成］をクリックします。すると、ファイルが開き、作成が完了したことを示す

メッセージが表示されます。

方法 2 ：新しいファイルを始めから作成する

1 メインツールバーの［Btrieve ファイルの作成］アイコンをクリックするか、ファイルがまだ開いていない

場合には、前項と同様に［ファイル］メニューの［新規作成］をクリックします。

2 画面上にファイルが既に開かれている場合には、ドロップダウンボックスが表示されます。［新規ファイル

の作成］を選択します。

3 前と同じダイアログボックスが値が空白の状態で表示され、これに新しい値を入力できます。

4 まず、［キー］メニューを使用するか、 Ctrl キーと A キーを同時に押して新規キーを追加します。

5 ダイアログボックスの下部にキーの属性を入力します。

6 必要に応じてキーやセグメントの追加や削除を続けます。これにはメニューを使用するか、一覧表示された

キーを右クリックします。

218


7 ここで、［作成］ボタンをクリックすると、 B_Create （14）オペレーションが実行されます。すると、画面上

にそのファイルも自動的に開きます。

履歴の作業

以下の作業は履歴の機能に関連しています。

「履歴ウィンドウを表示するには」

「履歴ウィンドウのドッキング状態を切り替えるには」

「履歴ウィンドウの常に前面に表示状態を切り替えるには」

「履歴ウィンドウをデフォルトの設定にリセットするには」

履歴ウィンドウを表示するには

1 ［表示｜履歴］を選択するか、［履歴］ボタンをクリックします。

履歴ウィンドウのドッキング状態を切り替えるには

1 履歴ウィンドウが表示されていない場合は、表示させます（「履歴ウィンドウを表示するには」を参照してく

ださい）。

2 履歴項目ウィンドウ内で右クリックし、次の図に示すように［ドッキング］オプションのチェックを付ける

かはずしてドッキング状態を切り替えます。

図 18 履歴ウィンドウをのドッキングを解除するには

ドッキングされた場合、履歴ウィンドウは図 18 に示すようにアプリケーションウィンドウに連結されます。

ドッキングされない場合、履歴ウィンドウは別個のウィンドウになります。ドッキングされない場合、図 18に示すように、履歴ウィンドウには右クリックで表示されるコマンドと同じメニュー項目が表示されます。

履歴ウィンドウの常に前面に表示状態を切り替えるには


ださい）。

2 この機能は、履歴ウィンドウがドッキングされていない状態でのみ使用できます。「履歴ウィンドウのドッキ

ング状態を切り替えるには」を参照してください。

3 履歴項目ウィンドウで表示を右クリックし、［常に手前に表示］にチェックを付けるかまたははずします。

履歴ウィンドウをデフォルトの設定にリセットするには


ださい）。

2 履歴項目ウィンドウで表示を右クリックし、［設定｜デフォルト］を選択します。

219


220

13
Maintenance を使用した Btrieve データファイルの操作
Maintenance ユーティリティを使用した Btrieve データファイルの操作


「Maintenance ユーティリティの概要」

「対話型 Btrieve Maintenance ユーティリティ」

「ファイル情報エディター」

「オーナーネーム」

「情報レポート」

「インデックス」

「データ」

「Btrieve コマンドライン Maintenance ユーティリティ（butil）」

「データのインポートとエクスポート」

「データファイルの作成と変更」

「データファイル情報の表示」

「Btrieve インターフェイスモジュールのバージョンの表示」

「Btrieve インターフェイスとリクエスターのアンロード（DOS のみ）」

「Continuous オペレーションの実行」

「アーカイブログの使用」

221


Maintenance ユーティリティの概要

Pervasive PSQL には、対話型の Maintenance ユーティリティおよびコマンドラインの Maintenance ユーティリティ

が用意されています。この Maintenance ユーティリティは、いずれも以下の共通したファイル操作およびデータ

操作を行います。

定義したファイルおよびキー仕様に基づいた新規データファイルの作成

既存データファイルのファイルおよびキー仕様の設定

データファイルのオーナーネームの設定とクリア

データファイルのインデックスの作成と削除

ASCII シーケンシャルデータのインポートとエクスポート

Pervasive PSQL データファイル間のデータのコピー

後のバックアップからシステムエラーが発生する間に行ったファイルへの変更の回復

2 つのユーティリティは基本的に同じですが、機能が異なる部分が多少あります。たとえば、対話型 Maintenanceユーティリティでは、定義したファイルおよびキー仕様に基づいてディスクリプションファイルを作成すること

ができますが、コマンドライン Maintenance ユーティリティでは、サーバー上でファイルの Continuous オペレー

ションを直接開始または停止することができます。

Maintenance ユーティリティを使用する前に、ファイル、レコード、キー、セグメントなどの Btrieve の基本概念

について熟知しておく必要があります。これらの項目の詳細については、『Pervasive PSQL Programmer's Guide 』を


メモ Pervasive PSQL 製品では次の 2 種類の Maintenance ユーティリティを提供します。Btrieve および SQL の2 つです。 SQL Maintenance ユーティリティは ODBC 経由でのリレーショナルアクセスに使用するデータ

ソース名（DSN）をサポートします。

222

対話型 Btrieve Maintenance ユーティリティ


対話型 Maintenance ユーティリティは、 Windows 32 ビットおよび 64 ビットプラットフォームで実行される

Windows アプリケーションです。このユーティリティは、グラフィカルインターフェイスを使用した場合、また

はディスクリプションファイルを作成したい場合に使用します。このセクションには次の主なトピックがありま

す。

「ファイル情報エディター」

「オーナーネーム」

「情報レポート」

「インデックス」

「データ」

それぞれの主なトピックにはそのトピックに固有のタスクがあります。

拡張ファイルのサポート

MicroKernel データファイルは、オペレーティングシステムのファイルサイズ上限を超えた容量を持つことが可

能です。データを、 MicroKernel の拡張ファイルからシーケンシャルファイルにエクスポートした際、実際の形

式の違いから、そのシーケンシャルファイルの容量がデータベースエンジンのファイルサイズ上限を超える場

合があります。

大きなサイズのファイルをエクスポートする際、対話型 Maintenance ユーティリティでは、シーケンシャルファ

イルがファイルサイズの上限（2 GB）を超えていることを検出すると、エクステンションファイルの作成が開

始されます。この処理は自動的に行われます。エクステンションファイルおよび元のシーケンシャルファイル

は、同じボリューム内に存在する必要があります（ファイルのサイズの制限は、オペレーティングシステムや

ファイルシステムによって異なります。 2 GB というサイズは単にデータベースエンジンで強制的に指定した制

限サイズです）。

エクステンションファイルの名前には、ベースファイルと似た名前を付ける方式が使用されます。エクステン

ションファイルを示すのに、ネイティブな MKDE エクステンションファイルがキャレット（"^"）を使用するの

に対し、シーケンシャルファイルのエクステンションファイルはチルダ（"~"）を使用するので、同じベースファ

イル名を持つ既存の MKDE 拡張ファイルを上書きするのを防ぎます。初のエクスポートエクステンション

ファイルには、ベースファイル名に ".~01" という拡張子が付きます。次のエクステンションファイルには、ベー

スファイル名に ".~02" というように拡張子が付けられます。これらの拡張子は 16 進形式で追加されます。

名前付け規則は 255 までのエクステンションファイルをサポートします。したがって、大ファイルサイズは

256 GB です。

また、シーケンシャルファイルからデータをインポートする場合は、ファイルが拡張されているかどうかが

チェックされ、エクステンションファイルからデータがロードされます。

長いファイル名と埋め込みスペースのサポート

スペースを含む長いファイル名は、サポートされるすべてのオペレーティングシステムで使用できます。参照対

象となるすべてのファイル名には、埋め込みスペースを含むことが可能であり、また 8 バイトを超える名前も使

用可能です。

Btrieve の古いバージョンでは、 Open や Create など、パスに基づくオペレーションの際に、ファイル名の後に

スペースを追加することができました。このバージョンでも、デフォルトとしてこれが設定されており、操作に

支障をきたしませんが、バージョン埋め込みスペースを含むファイル名やディレクトリ名も正しく認識する機能

を利用したい場合は、クライアントリクエスターの［スペースを含むファイル / ディレクトリ名］設定をオンに

設定します。デフォルトの設定はオンです。

このオプションをオフに設定した場合でも、埋め込みスペースを含む名前を持つファイルにアクセスする際に、

アプリケーションがファイルを開く、または作成する BTRV/BTRVID/BTRCALL/BTRCALLID コールを行うとき、

その名前を二重引用符で囲めば、使用することができます。

223


レコードおよびページ圧縮

Pervasive PSQL ではレコードおよびページによる 2 種類のデータ圧縮を提供します。これら 2 種類のデータ圧縮

は、別々に使われることもあれば、一緒に使われることもあります。 2 つの圧縮タイプの主な目的はいずれも、

データファイルのサイズを減らし、データのタイプとデータ操作のタイプに応じてより速いパフォーマンスを提

供することです。

レコード圧縮

レコード圧縮には 6.0 以上のファイル形式が必要です。レコード圧縮により、多数の繰り返し文字を含むレコー

ドの格納に必要なスペースを大幅に削減できます。データベースエンジンは、 5 つ以上連続する同一文字を 3 バイトに圧縮します。

ファイルの作成時、指定されたレコード長に余裕を持たせるため、データベースエンジンは自動的に指定された

より大きいページサイズを使用します。圧縮されていないレコードが、使用できる大ページに収まりきらない

ほど大きい場合、データベースエンジンは自動的にレコード圧縮をオンにします。

圧縮レコードの終的な長さは、ファイルに書き込まれるまで決定されないため、データベースエンジンはレ

コード圧縮されたファイルを可変長レコードファイルとして作成します。レコードの圧縮されたイメージは可変

長レコードとして格納されます。アプリケーションがレコードの追加、更新、削除を頻繁に行うと、個々のレコー

ドはいくつかのファイルページに断片化されます。データベースエンジンは 1 つのレコードを取得するために複

数のファイルページを読み取らなければならない場合があるので、この断片化によってアクセス時間が遅くなる

おそれがあります。

開発者リファレンス『Pervasive PSQL Programmer's Guide』の「ページサイズの選択」、「ファイルサイズの予測」

および「レコード圧縮」も参照してください。

ページ圧縮

ページ圧縮には 9.5 以上のファイル形式が必要です。内部的には、 Pervasive PSQL データファイルはさまざまな

種類のページの連続です。ページ圧縮は、ファイル内のデータページの圧縮と復元を制御します。

ファイルが物理ストレージから読み取られると、データページは復元されてメモリキャッシュに保持されます。

レコードの読み取りと更新は、メモリキャッシュ内の圧縮されていないデータに対して行われます。書き込み操

作が行われると、データページは圧縮されて物理ストレージに書き込まれます。圧縮されたページが、次回アク

セスされるまで保持されるかどうかは、キャッシュ管理によって異なります。

データの種類によって圧縮しても意味がない場合、データベースエンジンはそのデータを圧縮しないで物理スト

レージに書き込みます。

224


圧縮の使用時期の判断

レコード圧縮、ページ圧縮、あるいはその両方を使用することで得られる利点は、圧縮されるデータのタイプに

よって異なります。次の表では、データ圧縮を使用するかどうかを判断するための一般的な要因を説明します。

Btrieve Maintenance ユーティリティのインターフェイス

オペレーティングシステムの［スタート］メニューまたはアプリ画面から、あるいは Pervasive PSQL Control Centerの［ツール］メニューから Maintenance ユーティリティにアクセスします。このユーティリティのメインウィン

ドウは、次のようになります。

表 53 データ圧縮がふさわしいか考慮するための要因

圧縮考慮する要因

レコードページ

○ レコード圧縮は、以下の条件の場合にも効果的です。

各レコードに文字の繰り返しが多数含まれる可能性がある。たとえば、レコードにいくつかの

フィールドが含まれており、レコードをファイルに挿入するときにそれらのフィールドはすべて

タスクによって空白に初期化される可能性があります。レコード圧縮は、これらのフィールドが

ほかの値を含むフィールドで分割される場合でなく、レコード内で 1 つにグループ化される場合

に有効です。

データベースエンジンを実行するコンピューターが、圧縮バッファーで必要となる追加メモリを

提供できる。

レコードは、変更されることに比べ、より頻繁に読み取られる。

レコードの固定長部分が「ページサイズ - オーバーヘッド」より長い場合、自動的に圧縮が使用さ

れます。

レコード圧縮は、キーオンリーファイルやブランクトランケーションを使用するファイルには使用

できません。

○ ページ圧縮は、以下の条件の場合にも効果的です。

データが ZIP タイプの圧縮アルゴリズムを使用して高度に圧縮可能である。ページ圧縮によって

ファイルサイズが 1/4 程度に著しく縮小できる場合、ファイルのパフォーマンスはかなり向上し

ます。

ページは、追加、更新、削除されることに比べ、より頻繁に読み取られる。

圧縮しても意味がない場合、データベースエンジンはデータページを圧縮しないで物理ストレージ

に書き込みます。

○ ○ レコード圧縮およびページ圧縮の使用は、レコードに大きな空白部分が含まれる場合と、ページが追

加、更新、削除されることに比べ頻繁に読み取られる場合にも効果的です。

225


図 19 Btrieve Maintenance ユーティリティのメインウィンドウ

メニューオプション

対話型 Maintenance ユーティリティには、以下のメニューが用意されています。

ヘルプの起動

Maintenance ユーティリティのヘルプを使用するには、ヘルプの必要なダイアログボックスで［ヘルプ］をクリッ

クするか、以下のような［ヘルプ］メニューのコマンドを選択します。

オプションファイル情報エディターの表示、オーナーネームの設定およびクリア、ファイル情報レポートの生成、

ユーティリティの終了を行います。

インデックスインデックスの作成と削除を行います。

データ ASCII ファイルからのデータのロード、 ASCII ファイルへのデータの保存、データファイル間のレコー

ドのコピー、および後のバックアップからシステムエラーが発生するまでの間に行ったデータファ

イルへの変更を回復するためのロールフォワードを行います。

ヘルプ Maintenance ユーティリティのヘルプを起動します。

ヘルプの起動 Maintenance ユーティリティのヘルプトピックが表示されます。

バージョン情報著作権情報および製品のバージョン番号が表示されます。

226

ファイル情報エディター


このセクションでは、構築するファイルおよびキー仕様に基づいて新しいファイルを作成する［ファイル情報エ

ディター］に関する一般的な説明を行います。このエディターでは、既存ファイルの情報をロードできるため、

既存データファイルのファイル仕様やキー仕様の確認に便利です。また、既存ファイルのファイルやキー仕様に

基づいた新規ファイルの作成も可能です（コマンドライン Maintenance ユーティリティである BUTIL の CLONEコマンドと同様）。







ファイル情報エディターを開くには、［オプション｜情報エディターの表示］をクリックします。

図 20 ファイル情報エディター

［ファイル情報エディター］ダイアログの項目

エディターの上部には、以下のボタンが表示されます。

情報のロード既存ファイルの情報をロードします。情報をロードしても、既存ファイルを編集されること

はありません。既存ファイルに関する情報のコピーのみがロードされます。

ファイルの作成ダイアログボックスの現在の情報に基づいて新規ファイルを作成します。

デフォルトに設定設定をデフォルト値に戻します。

ディスクリプションコメントディスクリプションファイルを作成する場合は、ファイルに関するメモを入力することがで

きます。

ヘルプ［ファイル情報エディター］ダイアログボックスのヘルプを表示します。

227


データファイル情報

［ファイル情報エディター］の上部の［データファイル情報］領域には、以下のコントロールが含まれます。

ファイル仕様

［ファイル情報エディター］の中央部に［ファイル仕様］領域があります。表 54 はこのボックス内のコントロー

ルの説明です。

オーナーネーム必要に応じて、既存ファイルのオーナーネームをテキストボックスから指定します。

バージョンファイルの全属性を読み込むことができるデータベースエンジンのも古いバージョンを表しま

す。たとえば、バージョン 9.5 の Btrieve エンジンでファイルを作成し、バージョン 0.5 特有の属性

を使用しなかった場合、 Maintenance ユーティリティでは、バージョン 9.0 と表示されます。ファ

イル形式のバージョンについては「ファイルバージョンに関する注意」を参照してください。

総レコード数ファイルのレコード総数を表します。

表 54 ［ファイル仕様］のコントロール

コントロール説明範囲デフォルト

レコード長ファイルの固定長レコードの論理データレコード長

（バイト単位）を設定します。

レコード長およびオーバーヘッドの説明について

は、『Pervasive PSQL Programmer's Guide』の「レコー

ド長」セクションを参照してください。このマニュ

アルは、Pervasive PSQL 開発者リファレンスに含まれ

ています。

低 4 バイト。大値はファイル

バージョンによって異なります。

指定されたレコード長が、ページ

サイズからオーバヘッドを差し引

いた数値を超える場合、データ

ベースエンジンは自動的にその

ファイル形式で次に使用可能な

ページサイズになるよう試行しま

す。レコード長が、大ページサイズからオーバーヘッドを差し引

いた数値を超える場合、エンジン

はレコードの圧縮をオンにしま

す。

100

ページサイズファイルの物理ページサイズ（バイト単位）を設定

します。

512 － 4096 ：9.0 より前のファイル

バージョの場合（512 バイトの倍数

で大 4096 バイト）

512、1024、1536、2048、2560、3072、3584、 4096 または 8192 ：ファイル

バージョンが 9.0 の場合

1024、 2048、 4096、 8192 または

16384 ：ファイルバージョンが 9.5以上の場合

4,096

キー数（キーセグメントと対照して）エディターで現在定義

されている識別キーの数を表します。キーリストの

キーの数が反映されます。

0 － 119 0

セグメント数エディターで現在定義されているキーセグメントの

数を表します。セグメントリストのセグメントの数

が反映されます。

0 － 119 ： 9.5 より前のファイル

バージョンの場合。

0 － 420 ： 9.5 以上のファイルバー

ジョンの場合。

リレーショナルインターフェイス

のセグメントの数は、すべての

ファイルバージョンにおいて、119個までです。

0

228


リンク可能キー将来のリンク重複キーに予約する 8 バイトプレース

ホルダーの数を設定します。既存データファイルの

情報をロードしている場合、そのファイルで現在使

用可能なプレースホルダーの数がこの数値に反映さ

れます。元から予約してあるプレースホルダーの数

は、ファイルに保存されません。

0 － 119 3

キーオンリーファイルがキーオンリーかどうかを表します。レ

コードタ圧縮または可変長レコードを有効にした場

合、およびファイルに複数のキーを定義した場合は、

この設定は使用できません。

オンまたはオフオフ

インデックス

バランス

ファイルにおけるキーページ管理のインデックスバランスの使用を設定します。


プリアロケー

ション

ファイルにおけるプリアロケートページの使用を設

定します。


ページ数ファイル作成時にプリアロケートするページの数を

設定します。［プリアロケーション］がオンの場合に

のみ設定できます。既存データファイルの情報を

ロードしている場合、そのファイルの未使用の残り

プリアロケートページ数がこの数値に反映されま

す。元からプリアロケートしてあるページの数は、

ファイルに保存されません。

1 － 65,535 0

レコード圧縮ファイルにおけるレコード圧縮の使用を設定しま

す。キーオンリーファイル、またはブランクトラン

ケーションを使用するファイルには対応していませ

ん。「レコードおよびページ圧縮」も参照してくださ

い。


ページ圧縮ファイルにおけるページ圧縮の使用を設定します。

「レコードおよびページ圧縮」も参照してください。


可変長レコードファイルに、可変長レコードを含むことができるか

どうかを設定します。


ブランクトラ

ンケーション

ディスク領域を確保するために、ファイルが可変長

レコードに対してブランクトランケーションを使用

するかどうかを設定します。この設定は、可変長レ

コード有効時のみ可能です。


VAT ファイルが、長いレコード内のデータへ高速にアク

セスするため、可変長部割り当てテーブルを使用す

るかどうかを設定します。この設定は、可変長レコー

ド有効時のみ可能です。


% 空きスペース新規可変ページ作成前に、ファイルの可変ページが

確保する未使用スペースの量を設定します。この設

定は、［レコード圧縮］または［可変長レコード］が

オンの場合にのみ設定できます。

5、 10、 20、 30 5

表 54 ［ファイル仕様］のコントロール

コントロール説明範囲デフォルト

229


キー

ダイアログボックスの左下部には［キー］グループボックスがあります。表 55 はこの領域のコントロールの説

明です。これらのコントロールは、現在のキーセグメントだけでなく、［キー］リストで選択されているキーに

固有です。これらの設定を変更した場合、指定したキーのすべてのセグメントに対して変更が適用されます。

［キー］リストおよび［セグメント］リスト

ダイアログボックス中央下部の［キー］リストには、ファイルに定義されているキー番号が表示されます。バー

ジョン 6.x 以降のファイルでは、このキー番号が連続した数値である必要はありません。 Maintenance ユーティリ

ティでは、選択されたキーの仕様が、ダイアログボックス左下部の［キー］ボックスに表示されます。

また、ダイアログボックス中央下部の［セグメント］リストには、［キー］リストで選択されたキーに定義され

ている、キーセグメント番号が表示されます。 Maintenance ユーティリティでは、選択されたセグメントの仕様

が、ダイアログボックス右下部の［セグメント］ボックスに表示されます。

表 55 ［キー］のコントロール

コントロール説明デフォルト

重複可能キーが、重複する値（リンク重複）を持つことができるかどうかを設定します。

「重複キーの操作方法」を参照してください。

オン

変更可能キーの値を、作成後に変更できるかどうかを設定します。キー値の変更を許可しても

パフォーマンスには影響しません。キーページは、実際のキー値が変更された場合に

のみ更新され、特定のレコードのキー以外のフィールドが変更されても更新されませ

ん。

オン

繰り返し重複重複キー値を格納するのにデータベースエンジンがくり返し重複の手法を使用する

よう指定します。

「重複キーの操作方法」を参照してください。

オフ

散布キー（ヌルキー）散布キーには、ファイル内にあるレコード数よりも少ない数のキー値が含まれます。

インデックスから除外するキー値を指定するには、この次にある 2 つのコントロール

を参照してください。この設定は、ヌル可能なセグメントが含まれるキーの場合のみ

可能です。

オフ

全セグメント（ヌル）レコードのすべてのキーセグメントにヌル値が含まれる場合に、そのレコードをイン

デックスに含まれないよう設定します。この設定は、散布キー（ヌルキー）有効時の

み可能です。キーフラグ 0x0008 に相当します。セグメントがヌルとして評価される

かどうかは、そのフィールドのヌルインジケーターセグメントだけを基に判断され

ます。そのフィールドの内容は評価されません。

オフ

一部セグメント

（マニュアル）

1 つまたは複数のキーセグメントにヌル値が含まれる場合に、そのレコードをイン

デックスに含めないよう指定します。この設定は、散布キー（ヌルキー）有効時のみ

可能です。キーフラグ 0x0200 に相当します。セグメントがヌルとして評価されるか

どうかは、そのフィールドのヌルインジケーターセグメントだけを基に判断されま

す。そのフィールドの内容は評価されません。

オフ

ACS 情報キーのオルタネートコレーティングシーケンス（ACS）を設定します。この設定は、

キーのセグメントに対する［ACS を使用する］チェックボックスがオンの場合にの

み使用できます。

オフ

ユニーク値ファイルにある重複しないキー値の数を表します。これは、既存データファイルの情

報をロードしている場合のみ表示されます。

適用外

230


また、［キー］と［セグメント］リストには、以下のボタンが表示されます。

これらのボタンは、作成するファイルのキー仕様を設定するもので、既存ファイルのキーに対して使用すること

はできません。既存ファイルのインデックスを作成または削除する場合は、「インデックスの作業」を参照してく

ださい。

キーセグメント

ダイアログボックスの右下部には［キーセグメント］グループボックスがあります。表 56 はこの領域のコント

ロールの説明です。これらのコントロールは、［セグメント］リストで選択されているセグメントに固有のもので

す。

重複キーの操作方法

複数のレコードが、インデックスキーに同一の重複した値を持つことができます。重複キー値を持つレコードを

記憶しておく 2 つの方法は、リンク重複および繰り返し重複と呼びます。

挿入新しいキーまたはセグメントを定義します。

削除選択されたキーまたはセグメントの仕様を削除します。

圧縮キーの番号を再割り当てします。このボタンは、キー仕様を削除することに

よって生じたキー番号の不連続をなくすことができます。

表 56 ［キーセグメント］グループボックスのコントロール


データ型キーセグメントのデータ型を指定します。

NULL データ型は、インデックスが 1 バイトのヌルインジケーターセグメントであるこ

とを示します。このセグメントはマルチセグメントキー内にあり、 NULL 型でないほか

のキーセグメントの前にある必要があります。このキータイプに使用される Btrieve APIの番号は 255 です。

String

位置レコード内でのこのキーセグメントの相対的な開始位置を、数値で設定します。この数

値は、レコード長を超えて設定することはできません。

1

長さキーセグメントの長さ（バイト単位）を設定します。この数値は、セグメントのデータ

型に指定された制限を超えることはできません。キー位置とキー長の合計も、レコード

長を超えないように注意してください。

10

ヌル値（16 進）キーセグメントのヌル文字値（16 進数）を設定します。この設定は、キーに対する［ヌ

ルキー］チェックボックスがオンの場合にのみ使用できます。

バイナリ

ゼロ

大小文字無視セグメントで大文字小文字が区別されるかどうかを設定します。この設定は、 STRING、

LSTRING、 ZSTRING のデータ型、または ACS を使用しないキーに対してのみ有効です。

オン

降順ソートキーセグメント値を降順（大きいものから小さいものへ）でソートするかどうかを指定

します。

オフ

ACS を使用するセグメントで、キーに定義されたオルタネートコレーティングシーケンスを使用するかどうかを設

定します。この設定は、大文字小文字が区別される STRING、 LSTRING、 ZSTRINGのデータ型に対してのみ使用できます。

オフ

ヌル値の離散順

序

ヌル値の離散順序は、ヌルインジケーターセグメント（NIS）で、MKDE が NIS を Booleanとして扱って非ゼロ値をすべてヌルと見なすのか、 1 バイトの Integer として扱ってゼロ

が非ヌルでその他すべての値を異なるタイプのヌルと見なすのかを決定するのに使用さ

れます。この場合、これらは離散値としてソートされます。 Btrieve API は NO_CASE フラグ 0x0400 がこれまで Integer 値に使用されていなかったので、これを使用し、離散順序

ソートが実行されるようにします。

オフ

231


リンク重複

リンク重複の手法では連鎖技術を使用し、グループ内の各レコードをポインターを使用して隣のレコードと連結

します。同一インデックスページ上の各エントリは 1 組のレコードポインターを持ち、キー値が重複しているレ

コードの連鎖の初と後のリンクを示します。このため、各キーページのエントリは繰り返し重複インデック

スより 4 バイト長くなります。さらに、データページの各レコードでは、リンク重複インデックスごとに 8 バイ

トのオーバーヘッドが必要です。この 8 バイトは、連鎖中の次のレコードと前のレコードを指す 2 つのレコード

ポインターです。

初のレコードポインターは、初に、またはも古い時期に格納されたレコードのアドレスを保持します。 2番目のポインターは近または後に格納されたレコードのアドレスを保持します。初のレコードが書き込ま

れた後でほかのレコードが追加される前には、キーページエントリ上の両方のポインターに初のレコードのア

ドレスが保持されています。その後にレコードが追加されると、 2 番目のポインターが追加された各レコードを

指すように変更されます。このことにより、後のレコードのレコードポインターが、レコードの追加時にデー

タページ内に構築される前のレコードの連鎖のリンクとして使用されること、および前のレコードの検索に使用

されることが可能になります。

繰り返し重複

繰り返し重複の手法では、各重複キー値はインデックスページとデータページ上のレコード内の両方に格納され

ます。各キー値には、レコードポインターが 2 つではなく 1 つだけあります。この手法ではデータレコードの連

鎖が不要で、レコードごとの 8 バイトのオーバーヘッドを節約します。キー値が重複レコードごとに繰り返され

るため、インデックスのサイズが大きくなるという影響があります。

手法の比較

リンク重複および繰り返し重複の手法は、以下の基準によって比較することができます。

順序付け

ストレージ


並行性

順序付け

リンク重複インデックスは、データが追加された順序で重複を取得します。繰り返し重複インデックスは、デー

タがファイル内に存在する順序で重複を取得します。ファイル内での位置は制御できないため、順序はランダム

であると考える必要があります。

ストレージ

リンク重複インデックスでは、各重複キー値の初の出現で 12 バイト余分に必要になります。これには、各レ

コードについての 8 バイトとキーページエントリとしての 4 バイトが含まれます。ただし、重複レコードはキー

ページでこれ以外の余計な空間を必要とせず、レコードごとに 8 バイトが追加されるだけです。したがって、キー

値ごとの重複の数が増加してキー値のサイズが増加しても、リンク重複インデックスはキーページが使用するス

トレージ空間を著しく節約することができます。ただし、重複キーを持つレコードがほとんどファイルに格納さ

れていないか、キー長が非常に短い、またはその両方に該当する場合は、使用するストレージ空間は増加します。

次の図で、リンク重複インデックスの使用によって節約されるストレージ空間の量を例示します。リンク重複イ

ンデックスは、キー値ごとの重複レコード数が少ない場合にはより多くの空間を必要とするので注意してくださ

い。しかし、キー値ごとの重複レコード数が増えるにつれ、リンク重複インデックスが必要とするページ数は少

なくなり、ストレージ空間を著しく節約します。

232


図 21 重複キー手法によるページ数の比較


インデックス検索に関わるページが少ない場合、ディスクから読み込むページ数が少なくなるため、結果として

速いパフォーマンスが得られます。リンク重複手法は一般的に少しの物理ストレージ空間しか使用しないため、

速いパフォーマンスが得られます。繰り返し重複手法は、重複のあるキー数が少ない場合にのみパフォーマンス

での利点があります。

並行性

データベースエンジンは、複数の並行トランザクションが同一ファイルに対し同時にアクティブである場合に、

ページレベルの並行性を提供します。これは、キーページへのほとんどの変更と、データページへのすべての

変更に適用されます。並行性とは、同一ページが別個のトランザクションからの複数の保留中の変更を同時に持

つことができることを意味します。また、これらのトランザクションはどのような順序でもコミットすることが

できます。繰り返し重複インデックスはこの並行性をもよく利用しています。

リンク重複インデックスでは、繰り返し重複には存在しない並行性の制限が追加されます。新しい重複データが

作成された場合、そのレコードはリストの後で別のレコードにリンクされます。このレコードのリンクにより、

1 つではなく 2 つのレコードがロックされることになります。すべての重複データはリンクレコードの連鎖の

後に追加されるため、重複は一度に 1 つしか追加できません。

このようなレコードロックの衝突により、通常、ほかのクライアントは初のトランザクションがコミットされ

るまで待機状態になります。並行動作が行われる環境では、すべての新規レコードが同じ重複値を使用する場合、

並行性は事実上一度に 1 トランザクションというレベルまで低減します。さらに、トランザクションが大きいか

または長く継続する場合、この連続状態がパフォーマンスに非常に大きく影響します。

並行環境で更新されるデータベースに繰り返し重複インデックスを使用した場合、パフォーマンスは一般的に向

上します。したがって、リンク重複手法を使用せざるを得ない理由がある場合を除き、並行環境で更新されるデー

タベースには繰り返し重複インデックスを使用してください。

凡例： = リンク重複 = 繰り返し重複

先頭の 2 行はキー長 100 を表します

中央の 2 行はキー長 50 を表します

下部の 2 行はキー長 4 を表します

233


情報エディターでの作業

ファイル情報エディターを使用して次の作業を行うことができます。

「既存ファイルからの情報のロード」

「新規ファイルの作成」

「Btrieve データファイルのコンパクト化」

「キーのオルタネートコレーティングシーケンスの設定」

既存ファイルからの情報のロード

既存ファイルから情報をロードした場合、既存ファイルを編集するわけではありません。既存ファイルに関する

情報のコピーのみがロードされます。一般的に、ファイル情報エディターでほかの作業をする前にファイルをロー

ドしますが、これは必須ではありません。

既存データファイルからファイル情報エディターに情報をロードするには

1 ［ファイル情報エディター］ダイアログボックスの上部の［情報のロード］をクリックします。［ファイルの

選択］ダイアログボックスが表示されます。

図 22 ［ファイルの選択］ダイアログボックス

2 情報をロードするファイルの名前とパスを指定します。デフォルトでは、データファイルの拡張子は .mkdになっています。

Maintenance ユーティリティでは、指定されたファイルを、まずデータファイルとして開こうとします。ファ

イルにオーナーネームが必要な場合は、オーナーネームを要求するメッセージが表示されます。オーナー

ネームはオプションであるため、開こうとするファイルがオーナーネームを必要としない場合もあります。

指定されたファイルがデータファイルでない場合、このユーティリティではそのファイルを、ディスクリプ

ションファイルとして開こうとします。

新規ファイルの作成

ファイル情報エディターで、現在の情報または入力した新しい情報に基づいた新規ファイルを作成することがで

きます。

ファイル情報エディターの現在の情報に基づいて新規ファイルを作成するには

1 ［ファイル情報エディター］ダイアログボックスの上部の［ファイルの作成］をクリックします。［ファイル

の作成］ダイアログボックスが表示されます。

234


図 23 ［ファイルの作成］ダイアログボックス

2 ［ファイルの作成］ダイアログボックスで設定を行います。各コントロールについては、表 57 を参照してく

ださい。

ディスクリプションファイルへのコメントの追加

コメントは、ディスクリプションファイルを作成したときに、その先頭に出力されます。たとえば、コメント

「これは私のファイルです」はディスクリプションファイルの先頭に /* これは私のファイルです */ と表示され

ます。ディスクリプションファイル作成後にコメントを追加する場合は、コメントを追加してファイルを作成し

直す必要があります。

ディスクリプションファイルにコメントを追加するには

1 ［ディスクリプションコメント］をクリックします。［ディスクリプションファイルコメント］ダイアログ

ボックスが表示されます。

表 57 ［ファイルの作成］ダイアログのコントロール


ファイル名ファイルの名前とパスを指定します。デフォルトでは、データファイルの拡張子

は .mkd になっています。

適用外

ファイルの種類作成するファイルの種類を指定します。ディスクリプションファイルを作成する

場合は、［インデックスオンリー］オプションを使用して、BUTIL ユーティリティ

で既存データファイルへのインデックス追加に使用できるディスクリプション

ファイルを作成できます。詳細は、「インデックスの作成」を参照してください。

MicroKernel 互換

システムデータファイルにシステムデータを含むかどうかを設定します。［エンジン設定を使用］

を選択した場合は、［システムデータ］設定オプションの設定が適用されます。［シ

ステムデータなし］を選択した場合、エンジンの設定にかかわらず、システムデー

タは作成されません。［システムデータを強要］を選択した場合は、エンジンの設

定にかかわらず、システムデータが作成されます。

この設定は、ファイルの種類が［MicroKernel 互換］の場合にのみ有効になります。

エンジン設定を

使用

235


図 24 ［ディスクリプションファイルコメント］ダイアログボックス

2 全角で 2,560 文字（半角で 5,120 文字）以内のコメントを入力します。

3 コメント入力後、［OK］をクリックします。

Btrieve データファイルのコンパクト化

未使用スペースを除去することにより Btrieve データファイルのコンパクト化を行うことができ、通常ファイル

のサイズを小さくすることができます。この処理は、コマンドライン Maintenance ユーティリティ（「Btrieve デー

タファイルをコンパクト化するには」を参照）を使用して実行することもできます。

Btrieve ファイルをコンパクト化するには

1 ファイル情報エディターの［情報のロード］をクリックし、コンパクト化するファイルを選択します。

2 ［ファイルの作成］をクリックし、［ファイルの作成］ダイアログボックスに、複製する新しいファイルの名

前を入力して［OK］をクリックします。

3 メインウィンドウの［データ］メニューから［保存］をクリックします。［データの保存］ダイアログボッ

クスの［保存元 MicroKernel ファイル］ボックスに元のファイルの名前を入力し、［保存先シーケンシャル

ファイル］ボックスに出力ファイルの名前（たとえば < 元のファイル名 >.out）を入力します。

4 ［実行］をクリックします。［データの保存］ダイアログボックスに、保存の結果が表示されます。［閉じる］

をクリックします。

5 ［データ］メニューの［ロード］をクリックします。［データのロード］ダイアログボックスの［ロード元

シーケンシャルファイル］ボックスに、保存したシーケンシャルデータファイルの名前を入力します。ス

テップ 2 で作成した複製ファイルの名前を［ロード先 MicroKernel ファイル］ボックスに入力します。

6 ［実行］をクリックします。［データのロード］ダイアログボックスに、ロードの結果が表示されます。［閉

じる］をクリックします。

元のファイルと複製されたファイルのサイズを比較すると、コンパクト化の結果を確認できます。

キーのオルタネートコレーティングシーケンスの設定

オルタネートコレーティングシーケンス（ACS）を使用して、文字型のキー（STRING、LSTRING および ZSTRING）

を標準 ASCII コレーティングシーケンスとは異なる順序でソートすることができます。1 つまたは複数の ACS を使用して、次のようにキーをソートすることができます。

英数字（A-Z および 0-9）と非英数字（# など）の混在した独自のユーザー定義ソート順による

マルチバイトコレーティング要素、符号、および文字の拡張と短縮を含む言語固有のコレーションに適合す

る、インターナショナルソート規則（ISR）による

ファイルには、キーごとに異なる ACS を持つことができますが、1 つのキーには 1 つの ACS のみです。したがっ

て、キーがセグメント化されている場合、各セグメントはそのキーに指定された ACS を使用するか、または ACS

236


をまったく使用しないかのいずれかになります。あるファイルに、一部のセグメントにだけ ACS が指定されてい

るキーがある場合、 Btrieve は指定されたセグメントのみ、 ACS を使用してソートします。

ISR テーブルは ISO の標準ロケールテーブルに基づいており、 Pervasive PSQL によって提供されます。 ISR テー

ブルは Pervasive PSQL のデータベースエンジンと一緒にインストールされた COLLATE.CFG ファイルに格納さ

れています。複数のデータファイルが 1 つの ISR を共有できます。

キーのオルタネートコレーティングシーケンスを設定するには

1 ［ACS 情報］をクリックします。

Maintenance ユーティリティに［ACS 情報の指定］ダイアログボックスが表示されます。

図 25 ［ACS 情報の指定］ダイアログボックス

2 カントリ ID とコードページ、 ACS ファイル名、インターナショナルソート規則（ISR）のいずれかを、以

下のように指定できます。

3 カントリ ID およびコードページ ID を設定した場合は、ロケール特有のコレーティングシーケンスがデー

タファイルに保存されます。また、ロケール変更後も、新しいキー値を正しく挿入することができます。

4 データファイルに ACS ファイル名を指定した場合は、 ACS ファイルの内容がデータファイルにコピーされ

ます（データファイルには、 ACS ファイルの名前は含まれません）。ACS は、 8 バイトの名前（UPPER など）

で識別され、 Maintenance ユーティリティでは、データファイルの ACS 情報に、元の ACS のファイル名で

はなく、この 8 バイトの名前が表示されます。

表 58 ACS 情報のコントロール


ACS カントリ / コード

カントリ ID 国を識別する Intel 形式の番号です。詳細は、オペレーティングシステムのマニュアル


-1

コードページ使用するコードページを識別する Intel 形式の番号です。詳細は、オペレーティングシステムのマニュアルを参照してください。

-1

ACS ファイルオルタネートコレーティングシーケンスファイルのフルパス名を指定します。適用外

インターナショナ

ルソート規則

このラジオボタンをクリックすると、インターナショナルデータをソートするために使

用する、 ISR テーブルを指定することができます。Pervasive PSQL には、『Pervasive PSQLProgrammer's Guide』に一覧表示された ISR テーブルがあらかじめ用意されています。

237


5 ディスクリプションファイルに ACS ファイルを指定した場合は、 ACS ファイルの実際のパスとファイル名

がディスクリプションファイルにコピーされます。その結果、ディスクリプションファイルの ACS 情報を

表示する場合、 Maintenance ユーティリティは指定した ACS ファイルを検索しようとします。

ISO で定義されている言語固有のコレーティングシーケンスを使用して文字列の値をソートする ACS を指

定する場合は、 ISR テーブル名を指定します。［テーブル名］フィールドへの入力は、半角で 16 文字までで

す。ISR の詳細については、開発者リファレンスの『Pervasive PSQL Programmer's Guide』を参照してください。

238



MicroKernel では、オーナーネームを指定することにより、ファイルへのアクセスを制限することができます。

オーナーネームはオプションであるため、ユーティリティで使用するファイルにオーナーネームが必要でない場

合もあります。オーナーネームは大文字小文字を区別します。

概念としては、オーナーネームはパスワードに似ています。オーナーネームは、 PCC で設定することのできる、

ユーザー名やグループ名と同じではありません。たとえば、オーナーネームの "Master" はデフォルトユーザー

の Master とは異なります。


指定できます。ただし、長いオーナーネームを指定した場合、そのデータファイルは Pervasive PSQL v10 SP1 より前のデータベースエンジンで読み取ることができないので注意してください。また、長いオーナーネームを使

用したデータファイルは、v9.5 より前のファイル形式にリビルドしようとする場合、そのオーナーネームを初

に削除しておかないとリビルドすることができません。オーナーネームは、長いものでも短いものでも、その

大長（8 または 24 バイト）に満たない部分は空白が埋め込まれます。

リレーショナルアクセスでは、オーナーネームの制限のあるテーブルを操作しようとすると ODBC エラーにな

ります。たとえば、 PCC でテーブル名をダブルクリックしたり、テーブルを削除しようとする場合です。 GRANTステートメントまたは SET OWNER ステートメントでオーナーネームを指定することができます。

GRANT ステートメントを使用して、特定のユーザーまたはグループにアクセス権を与え、 ODBC 経由でリレー

ショナルアクセスすることができます。Master ユーザーは GRANT ステートメントに正しいオーナーネームを使

用する必要があります。『SQL Engine Reference』の「GRANT」を参照してください。

SET OWNER ステートメントを使用し、現在のデータベース接続中に使用するオーナーネームを 1 つまたは複数

指定できます。『SQL Engine Reference』の「SET OWNER」を参照してください。

オーナーネームの作業

オーナーネームは設定およびクリアすることができます。

オーナーネームを設定またはクリアする

データファイルへのアクセスを制限するためにオーナーネームを設定します。アクセス制限を解除するために

オーナーネームをクリアします。

メモオーナーネームを指定するには GRANT ステートメントを使用することもできます。『SQL EngineReference』の「オーナーネーム」を参照してください。 PCC では現在、ファイルのセキュリティプロパティ

を介してオーナーネームを指定する方法は提供していません。

オーナーネームを設定またはクリアするには

1 メニューバーの［オプション｜オーナーネームの設定 / クリア］をクリックします。［オーナーネームの設

定 / クリア］ダイアログが表示されます。

239


図 26 ［オーナーネームの設定 / クリア］ダイアログ

2 ［MicroKernel ファイル］ボックスで、オーナーネームを設定またはクリアするファイルを指定します。オー

ナーネームをクリアする場合は、［オーナーネームのクリア］をクリックし、［現在のオーナー］フィール

ドにファイルのオーナーネームを指定します。

3 オーナーネームを設定する場合は、［オーナーネームの設定］をクリックし、［新しいオーナー］フィール

ドにファイルの新しいオーナーネームを指定して、その後、希望するオプションを選択します。

［オーナーネームなしの読み込み専用アクセスを許可する］を選択すると、すべてのユーザーが、デー

タファイルへの読み込み専用アクセスを許可されます。

［ファイルのデータを暗号化する］を選択すると、デバッグユーティリティやファイルダンプユーティ

リティを使用したデータへの不正アクセスを防ぐことができます。暗号化や復号化の処理には若干の時

間を要するため、使用する環境でデータのセキュリティが優先される場合にのみ、このチェックボック

スをオンにしてください。

［長いオーナーネーム］を選択して、半角 24 文字までの範囲でオーナーネームを作成します（短いオー

ナーネームは半角 8 文字までの範囲で指定できます）。長いオーナーネームを指定した場合、そのデー

タファイルは Pervasive PSQL v10 SP1 より前のデータベースエンジンで読み取ることはできません。また、長いオーナーネームを使用したデータファイルは、v9.5 より前のファイル形式にリビルドしようと

する場合、そのオーナーネームを初に削除しておかないとリビルドすることができません。

4 ［実行］をクリックしてオプションを適用します。

240

情報レポート

情報レポート

ファイル情報レポートの作成は、データベースエンジンのトランザクション一貫性保守機能でファイルのログを

作成できるかどうかを確認する際に便利です。レポートは、ファイルにシステムデータがあるかどうか、キーが

ユニークであるかどうかを表示します（ユニークキーには、重複が許可されていることを示す "D" フラグが付き

ません）。情報レポートはファイルのメタデータを提供します。この情報は、問題の解決に使用したり、よく似た

ファイルを作成するのに役立ちます。

情報レポートの作業

情報レポートを作成する手順を以下に示します。

既存データファイルのファイル情報レポートを作成するには

1 メインウィンドウのメニューで、［オプション｜情報レポートの作成］をクリックします。 Maintenance ユー

ティリティに［ファイル情報レポート］ダイアログボックスが表示されます。

図 27 ［ファイル情報レポート］ダイアログボックス

2 使用するデータファイルとレポートのファイル名を指定します。作成後にレポートを表示する場合は、［レ

ポートを表示する］チェックボックスをオンにします。

レポートを表示する設定にした場合、次のような［ファイルの表示］ウィンドウが表示されます。

図 28 ファイル情報レポートの例

ファイル情報レポートの情報ヘッダーは、「ファイル情報エディター」に記述されているファイル情報エディ

ターのコントロールに対応しています。

ファイル情報レポート下部の凡例には、レポートのキー / セグメントの部分で使用されている記号の説明が

表示されます。この情報には、キーやキーセグメントの数、ファイル中のキーの位置、キー長などが含まれ

ます。

File Statistics for person.mkd

File Version = 9.50Page Size = 4096Page Preallocation = NoKey Only = NoExtended = NoTotal Number of Records = 1500Record Length = 333 Record Compression = NoPage Compression = NoVariable Records = Yes

241


凡例：

< = Descending Order

D = Duplicates AllowedI = Case Insensitive

M = Modifiable

R = Repeat DuplicateA = Any Segment (Manual)

L = All Segments (Null)

* = The values in this column are hexadecimal.?? = Unknown

-- = Not Specified

242

インデックス

インデックス

インデックスは、特定キーのすべてのキー値をソートするためのものです。 Btrieve アクセスではオーバーラップ

するインデックス（列の一部を含むインデックス）が許可されます。 ODBC を介したリレーショナルアクセスで

は、オーバーラップするインデックスは許可されません。［エディターの起動］ボタンをクリックして表示できる

ファイル情報エディターを使用して、オーバーラップするインデックスを作成することができます。

インデックスの作業

インデックスに関連する以下の作業を行います。

「インデックスの作成」

「インデックスの削除」

インデックスの作成

ファイルにキーが定義されていない場合、ファイルのインデックスを作成することはできません。ファイル情報

エディター（「ファイル情報エディター」を参照）を使用してキーを作成することができます。

インデックスを作成するには

1 メインメニューで、［インデックス｜作成］をクリックすると、［インデックスの作成］ダイアログボック

スが開きます。

図 29 ［インデックスの作成］ダイアログボックス

2 ［インデックスの作成］ダイアログボックスで以下のオプション設定を行います。

インデックスの種類内部インデックスと外部インデックスのどちらを作成するかを指定します。内部インデッ

クスは、データファイルの一部として動的に管理されます。外部インデックスは、必要に

応じて作成する別のファイルとなります。

外部インデックスは、指定したキーによってソートされたレコードを含む標準データファ

イルです。各レコードは、以下の項目から成ります。

元のデータファイルにおけるレコードの物理位置を識別する 4 バイトアドレス

キー値

データファイルインデックスを作成するデータファイルの名前を指定します。

外部インデックスファイル外部インデックスに作成するファイルの名前を指定します。内部インデックスには使用で

きません。

243


3 ［エディターの起動］をクリックすると、［ファイル情報エディター］ダイアログボックスにキーの詳細情報

が表示されます。［リストのリフレッシュ］をクリックして、データファイルからキー情報を読み込むと、

［データファイルの既存キー番号］リストと［作成に使用するキー番号］リストをリフレッシュできます。

インデックスを作成する前に［リストのリフレッシュ］をクリックしてください。

4 ［インデックスの作成］ダイアログボックスの設定完了後、［実行］をクリックしてインデックスを作成しま

す。インデックス作成の所要時間は、ファイルに含まれるデータの量によって異なります。

インデックスの削除

インデックスを削除する前に、アプリケーションプログラムが行うアクセスについてよく理解しておいてくださ

い。必要なインデックスがないと、 GET NEXT などの機能が動作しません。その結果、アプリケーションプログ

ラムは正常に機能しなくなります。

インデックスを削除するには

1 メインメニューで、［インデックス｜削除］をクリックします。［インデックスの削除］ダイアログボックス


図 30 ［インデックスの削除］ダイアログボックス

2 ［インデックスの削除］ダイアログボックスで以下のオプション設定を行います。

3 ［リストのリフレッシュ］をクリックし、指定したファイルからキー情報を読み込みます。

情報エディターで使用する

キー仕様番号

ファイル情報エディターで定義されたキー番号が表示されます。

データファイルの既存キー

番号

［リストのリフレッシュ］をクリックすると、ファイルに定義されているキー番号が表示さ

れます。ファイルにシステム定義のログキーが含まれている場合は、このリストに

SYSKEY が表示されます。

作成に使用するキー番号［リストのリフレッシュ］をクリックすると、ファイルに定義されていない、使用可能な

キー番号が表示されます。インデックスの作成時に使用するキー番号を選択します。

ファイルにシステム定義のログキー（システムデータ）が含まれ、そのキーが削除されて

いる場合は、リストに SYSKEY が表示され、それを選択することにより、システム定義の

ログキーをファイルに再追加することができます。

MicroKernel ファイルインデックスを削除するデータファイルの名前を指定します。

既存のキー番号［リストのリフレッシュ］をクリックすると、ファイルに定義されているキー番号が表示されま

す。削除するインデックスのキー番号を選択します。ファイルにシステム定義のログキーが含ま

れている場合は、リストに SYSKEY が表示され、それを選択することにより、システム定義のロ

グキーをファイルから削除することができます。

番号再割当てキーの番号を再割り当てします。このチェックボックスをオンにすると、インデックス削除に

よって生じたキー番号の欠番がなくなります。

244

データ

データ

［データ］メニューのコマンドを使用して、データファイルのレコードをインポート、エクスポート、およびコ

ピーすることができます。また、ロールフォワード機能を利用して、システムエラー発生後にデータを修復する

ことも可能です。ロールフォワードについては、「ロールフォワードコマンド」を参照してください。

ASCII ファイル形式のインポートとエクスポート

データを保存すると、ASCII ファイルのレコードは、以下の形式になります。以下の仕様に従うことにより、ASCIIテキストエディターを使用してロード可能なファイルを作成できます。多くのテキストエディターでは、バイナ

リデータを編集することができないので注意してください。

初のフィールドは、レコードの長さを指定する左揃えの整数（ASCII 形式）です（この値の計算時、行末

のキャリッジリターン / ラインフィードは無視します）。このフィールドの値は、データファイルで指定さ

れているレコード長と同じになります。

固定長レコードを含むファイルでは、データファイルのレコード長と同じ長さを指定します。

可変長レコードを含むファイルでは、データファイルの固定レコード長以上の長さを指定します。

長さフィールドの次に、区切り文字（カンマまたはスペース）が入ります。

区切り文字の次に、レコードデータが続きます。データの長さは、長さフィールドで指定したバイト数と

まったく同じにします。テキストエディターを使用してインポート ASCII ファイルを作成する場合は、各レ

コードが適切な長さになるように、必要に応じてスペースで埋めてください。

各行末には、キャリッジリターン / ラインフィード（16 進数の 0D0A）を使用します。Maintenance ユーティ

リティでは、データファイルにキャリッジリターン / ラインフィードが挿入されません。

ファイルの終行には、ファイル終了文字（CTRL+Z または 16 進数の 1A）を使用します。多くのテキスト

エディターでは、ファイルの後にこの文字が自動的に挿入されます。

図 31 は、入力 ASCII ファイルのレコード形式です。この例では、データファイルに 40 バイトのレコード長が定

義されています。

図 31 入力シーケンシャルファイルのレコード形式

データに関する作業

以下のデータに関する作業は Maintenance ユーティリティを使用して行うことができます。

「ASCII データをインポートするには」

「ASCII レコードをエクスポートするには」

「MicroKernel データファイル間でレコードをコピーするには」

後のバックアップからシステムエラーが発生する間に行った、データファイルへの変更の回復（ロール

フォワード）の方法は、「ログ、バックアップおよび復元」の章を参照してください。

245


ASCII ファイルからのレコードのインポート

Maintenance ユーティリティでは、 ASCII ファイルから標準データファイルにレコードをインポートすることが

できます。この処理では、データ変換は行われません。テキストエディター、または Maintenance ユーティリティ

を使用してインポートファイルを作成することが可能です（「ASCII ファイルへのレコードのエスクポート」参

照）。

ASCII データをインポートするには

1 メインメニューで［データ｜ロード］をクリックします。［データのロード］ダイアログボックスが表示さ

れます。

図 32 ［データのロード］ダイアログボックス

指定する ASCII ファイルは、「ASCII ファイル形式のインポートとエクスポート」で説明されている仕様に

従っている必要があります。指定する標準データファイルのレコード長は、 ASCII ファイル内のレコードと

適合している必要があります。

2 ［実行］をクリックしてレコードをインポートします。

データのインポート中は、インポートされたレコードの数とパーセンテージ、およびステータスメッセージ

が表示されます。このとき、 Maintenance ユーティリティでは別の作業（新しい［データのロード］ダイアロ

グボックスを開くなど）を続けることもできます。

ASCII ファイルへのレコードのエスクポート

Maintenance ユーティリティでは、データファイルから ASCII ファイルにレコードをエクスポートすることがで

きます。

ASCII レコードをエクスポートするには

1 メインメニューで［データ｜保存］をクリックします。［データの保存］ダイアログボックスが表示されます。

図 33 ［データの保存］ダイアログボックス

246

データ

2 ［データの保存］ダイアログボックスで、以下のオプションを設定します。

3 ［実行］をクリックしてデータをエクスポートします。 Maintenance ユーティリティによって、「ASCII ファイ

ル形式のインポートとエクスポート」の形式に従って、指定された ASCII ファイルが作成されます。その後、

この ASCII ファイルを編集し、［ロード］コマンドを使用して、編集したテキストを別の標準データファイ

ルにインポートできます。

データファイル間のレコードのコピー

Maintenance ユーティリティでは、 MicroKernel データファイルから別の MicroKernel データファイルにデータを

コピーすることができます。指定するデータファイルの両方のレコード長は、同じでなければなりません。

MicroKernel データファイル間でレコードをコピーするには

1 メインメニューで、［データ｜コピー］をクリックします。［データのコピー］ダイアログボックスが表示さ

れます。

図 34 ［データのコピー］ダイアログボックス

2 コピーするファイルの名前を［コピー元 MicroKernel ファイル］ボックスに入力し、ファイルのコピー先の

パスを［コピー先 MicroKernel ファイル］ボックスに入力します。

保存元 MicroKernel ファイル保存する既存 MicroKernel 互換ファイルの名前を指定します。

保存先シーケンシャルファイル作成するシーケンシャルファイルの名前を指定します。

インデックスを使用するエクスポートするレコードをソートする際に、指定したインデックスを使用します。

デフォルトでは、 Maintenance ユーティリティでインデックスは使用されず、レコード

はデータファイル内の物理ポジションに従ってエクスポートされます。

内部インデックス番号：

指定したキー番号を使用します。［保存元 MicroKernel ファイル］ボックスのファイル

を変更した場合は、［インデックスリストをリフレッシュ］をクリックして使用可能

なインデックスを更新します。

外部インデックスファイル：

指定した外部インデックスを使用します（外部インデックスの作成は、「インデックス

の作成」参照）。

方向前方：これがデフォルトの設定で、データ回復がファイルの先頭から末尾に向かって

行われます。

後方：データ回復がファイルの末尾から行われます。

前方から後方：エラーが発生するまで、ファイルを前方から読み込みます。次に、エ

ラーが発生したレコード、または別のエラーが発生したレコードまで、ファイルを末

尾から読み込みます。

後方から前方：エラーが発生するまで、ファイルを後方から読み込みます。次に、エ

ラーが発生したレコード、または別のエラーが発生したレコードまで、ファイルを先

頭から読み込みます。

247


指定するデータファイルの両方のレコード長は、同じでなければなりません。

データファイルへの変更の回復（ロールフォワード）

「ログ、バックアップおよび復元」を参照してください。

248

Btrieve コマンドライン Maintenance ユーティリティ（butil）

Btrieve コマンドライン Maintenance ユーティリティ（butil）このユーティリティは、コマンドライン形式のインターフェイスを使用したい場合、または Continuous オペレー

ションを開始または停止したい場合に使用します。Btrieve Maintenance ユーティリティは、サーバー上で（Windowsプラットフォームの DOS プロンプトから）、またはローカルの DOS、 Linux および Windows クライアントから、

コマンドライン形式で使用することもできます。Maintenance ユーティリティのコマンドは、コマンドラインまた

は作成したコマンドファイルから実行することができます。Btrieve Maintenance ユーティリティのコマンド（butil）を実行する前に、「コマンド」で説明されている、基本的な考え方と操作方法を理解しておく必要があります。

Btrieve のコマンドライン Maintenance ユーティリティでは、以下のファイル処理およびデータ処理を行います。

「データのインポートとエクスポート」

「データファイルの作成と変更」

「データファイル情報の表示」

「Btrieve インターフェイスモジュールのバージョンの表示」

「Btrieve インターフェイスとリクエスターのアンロード（DOS のみ）」

「Continuous オペレーションの実行」

リターンコード

butil が実行を完了すると、終了コードまたは DOS エラーレベルをオペレーティングシステムに返します。リター

ンコードは以下のとおりです。

コマンド

次の表はコマンドライン Maintenance ユーティリティで使用できるコマンドの一覧です。

表 59 BUTIL のリターンコード

コード説明

SUCCESS_E = 0 要求された処理は正常に終了しました。

PARTIAL_E = 1 要求された処理は完了しましたがエラーが発生しました。

INCOMPLETE_E = 2 要求された処理は正常に終了しませんでした。

USAGE_E = 3 入力の構文エラー。使用方法を画面に表示し、終了します。

表 60 コマンドライン Maintenance ユーティリティコマンド

コマンド説明

「CLONE」既存ファイルの仕様を使用して、空の新規データファイルを作成します。

「CLROWNER」データファイルのオーナーネームをクリアします。

「COPY」データファイルの内容を、別のデータファイルにコピーします。

「CREATE」データファイルを作成します。

「DROP」インデックスを削除します。

「ENDBU」バックアップを対象として定義されたファイルの Continuous オペレーションを停止します。

「INDEX」外部インデックスファイルを作成します。

「LOAD」データファイルにシーケンシャルファイルの内容をロードします。

249


コマンド構文の表示

各コマンドの使用方法を表示するには、ファイルサーバーで butil コマンドを入力します。

コマンド形式

Maintenance ユーティリティのコマンドラインは、以下の形式になります。

butil [-command [parameter ...]] | @commandFile

コマンドファイル

コマンドファイルは、以下の処理に使用します。

コマンドラインに収まらない、長いコマンドの実行

頻繁に使用するコマンドの実行（コマンドファイルに一度入力し、その後はそのコマンドファイルを実行）

以下のコマンド形式を使用した、コマンドの実行とその出力のファイルへの書き込み

butil @commandFile [commandOutputFile]

コマンドを実行すると、結果の出力ファイルには、実行したコマンドとその結果が表示されます。すべての

メッセージは、サーバーのコンソール画面にも表示されます。

複数コマンドの連続実行

コマンドファイルには、コマンドラインで必要な情報と同じものが含まれます。

「RECOVER」データファイルから連続的にデータを読み込み、シーケンシャルファイルに結果を書き込みます。

（ただし DOS バージョンでは、 ROLLFWD は使用できません）。破損したファイルがある場合は、こ

のコマンドを使用します。

ROLLFWD 後のバックアップからシステムエラーが発生する間に行った、データファイルへの変更を回復し

ます。「アーカイブログの使用」を参照してください。

「SAVE」キーパスのデータを読み込み、シーケンシャルファイルに結果を書き込みます。

「SETOWNER」データファイルにオーナーネームを割り当てます。

「SINDEX」インデックスを作成します。

STARBU バックアップを対象として定義されたファイルの Continuous オペレーションを開始します。「ログ、

バックアップおよび復元」の章を参照してください。

「STAT」ファイル属性の情報およびデータファイルの現在のサイズを表示します。

「STOP」（DOS のみ） Btrieve インターフェイスとリクエスターをアンロードします。

「VER」サーバーにロードされているデータベースエンジンおよび Btrieve インターフェイスモジュールの

バージョンを表示します。

-command COPY などの Maintenance ユーティリティのコマンドが入ります。コマンドの前にはハイフン（-）を付け、ハイフンの前にはスペースを入力します。表 60 はコマンドの一覧です。

parameter コマンドに必要な情報です。詳細は各コマンドに応じて説明します。

@commandFile コマンドファイルのフルパス名

表 60 コマンドライン Maintenance ユーティリティコマンド

コマンド説明

250

Btrieve コマンドライン Maintenance ユーティリティ（butil）

コマンドファイルの規則

Maintenance ユーティリティのコマンドファイルを作成する際、以下の規則に従ってください。

1 つのパラメーターを 2 行に分割しない。

各コマンドは、 <end> または [end] で終わる必要があります。複数のコマンドを実行する場合は、各コマ

ンドが <end> で終わっている必要があります。 <end> または [end] には、小文字を使用します。

コマンドファイルの例

以下は、コマンドファイルの例 COPYCRS.CMD です。このファイルでは、BUTIL -CLONE コマンドを呼び出し、

COURSE.MKD ファイルを複製することによって NEWCRS.MKD ファイルを作成します。次に -CREATE コマン

ドを呼び出し、 NEWFILES.DES ディスクリプションファイルのディスクリプションを使用して NEWFILE.DTAファイルを作成します。

-clone newcrs.mkd course.mkd <end>-create newfile.dta newfiles.des <end>

以下のコマンドでは、 COPYPATS.CMD ファイルを使用して COPYPATS.OUT ファイルに書き込みを行います。

butil @copypats.cmd copypats.out

ディスクリプションファイル

ディスクリプションファイルは、データファイルとインデックスの作成に使用するファイルのディスクリプショ

ンおよびキー仕様を含む、 ASCII テキストファイルです。作成したファイルの情報を保存するための媒体として

ディスクリプションファイルを使用することもできます。ディスクリプションファイル形式の詳細については、

「ディスクリプションファイル」を参照してください。

拡張ファイルのサポート

データベースエンジンのデータファイルは、オペレーティングシステムのファイルサイズ上限を超えた容量を

持つことが可能です。データを、 MicroKernel の拡張ファイルからシーケンシャルファイルにエクスポートした

際、実際の形式の違いから、そのシーケンシャルファイルの容量がデータベースエンジンのファイルサイズ上

限を超える場合があります。

大きなサイズのファイルをエクスポートする際、対話型 Maintenance ユーティリティでは、シーケンシャルファ

イルがオペレーティングシステムのファイルサイズの上限（2 GB）を超えていることを検出すると、エクステ

ンションファイルの作成が開始されます。この処理は自動的に行われます。エクステンションファイルおよび元

のシーケンシャルファイルは、同じボリューム内に存在する必要がありますエクステンションファイルの名前に

は、ベースファイルと似た名前を付ける方式が使用されます。エクステンションファイルを示すのに、ネイティ

ブな MKDE エクステンションファイルがキャレット（"^"）を使用するのに対し、シーケンシャルファイルのエ

クステンションファイルはチルダ（"~"）を使用するので、同じベースファイル名を持つ既存の MKDE 拡張ファ

イルを上書きするのを防ぎます。初のエクスポートエクステンションファイルには、ベースファイル名に

".~01" という拡張子が付きます。次のエクステンションファイルには、ベースファイル名に ".~02" というように

拡張子が付けられます。これらの拡張子は 16 進形式で追加されます。

名前付け規則は 255 までのエクステンションファイルをサポートしますが、現在のエクステンションファイルの

大数は 64 です。したがって、大ファイルサイズは 128 GB です。

サイズの大きなファイルをシーケンシャルファイルに「SAVE」または「RECOVER」する場合は、それぞれのコ

マンドを参照してください。また、シーケンシャルファイルからデータをインポートする場合は、そのファイル

が拡張されているかどうかがチェックされ、エクステンションファイルからデータがロードされます。


MicroKernel では、オーナーネームを指定することにより、ファイルへのアクセスを制限することができます。

オーナーネームはオプションであるため、ユーティリティで使用するファイルにオーナーネームが必要でない場

合もあります。

251



指定できます。長いオーナーネームを指定した場合、そのデータファイルは Pervasive PSQL v10 SP1 より前のデー

タベースエンジンで読み取ることはできません。また、長いオーナーネームを使用したデータファイルは、 v9.5より前のファイル形式にリビルドしようとする場合、そのオーナーネームを初に削除しておかないとリビルド

することができません。オーナーネームは、長いものでも短いものでも、その大長（8 または 24 バイト）に満

たない部分は空白が埋め込まれます。

ファイルにオーナーネームが必要な場合は、 /O オプションを使用してオーナーネームを指定します。オーナー

ネームの指定は、以下のいずれかの方法で行います。

1 つのオーナーネーム

8 つまでのオーナーネーム（オーナーネームはカンマで区切る）

アスタリスク（*）オーナーネームの入力を要求するメッセージが表示されます。 rollfwd コマンドでは、複

数のオーナーネームをカンマで区切って入力します。

オーナーネームは大文字小文字を区別します。コマンドラインでオーナーネームを入力した場合、先頭のスペー

スは削除されます。アスタリスクを使用した場合は、先頭のスペースは削除されません。

エラーメッセージのリダイレクト

エラーメッセージをリダイレクトする場合は、フルパス名（ドライブ文字または UNC パスを含む）を入力します。

エラーメッセージをファイルへリダイレクトするには

以下のコマンド形式を使用します。

butil -command commandParameters > filePath

ASCII ファイル形式

「対話型 Maintenance ユーティリティ」セクションの、「ASCII ファイル形式のインポートとエクスポート」を参


異なるプラットフォームでのファイル名指定の規則

Windows ベースまたは Linux ベースのプラットフォームで butil を使用する際、データファイルが現在のディ

レクトリに存在する場合は、パスを指定する必要はありません。

252

データのインポートとエクスポート


このセクションでは、 butil コマンドの「COPY」、「LOAD」、「RECOVER」、および「SAVE」を使用したデータ

のインポートおよびエクスポートの詳細について説明します。

COPYCOPY コマンドは、 MicroKernel ファイルの内容を、別のファイルにコピーします。 COPY は、入力データファ

イルの各レコードを取得して、出力データファイルに挿入します。両ファイルのレコードのサイズは同じである

必要があります。レコードのコピー後、COPY によって新しいデータファイルに挿入されたレコードの総数が表

示されます。

メモ COPY は、「RECOVER」コマンドと「LOAD」コマンドに相当する処理を一度に実行します。

COPY コマンドを使用することにより、古いファイルからのデータと新しいキー属性を持つデータファイルを作

成できます。

MicroKernel データファイルをコピーするには

1 「CREATE」コマンドを使用し、任意のキー属性（キー位置、キー長、重複キー値）を持つ空のデータファイ

ルを作成します。

または

「CLONE」コマンドを使用して、既存ファイルの属性を使った空のデータファイルを作成します。

2 COPY コマンドを使用し、既存データファイルの内容を、新しく作成したデータファイルにコピーします。

形式

butil -copy sourceFile outputFile [/O< owner1 | *> [/O<owner2 | *>]] [/UIDuname /PWDpword [/DBdbname]]

表 61 データのインポートとエクスポートを行うコマンド

コマンド説明

「COPY」データファイルの内容を、別のデータファイルにコピーします。

「LOAD」データファイルにシーケンシャルファイルの内容をロードします。

「RECOVER」データファイルからシーケンシャルにデータを読み込み、シーケンシャルファイルに結果を

書き込みます。

「SAVE」キーパスのデータを読み込み、シーケンシャルファイルに結果を書き込みます。

sourceFile レコードをコピーする元となるデータファイルのフルパス名。 Windows プラットフォームで BUTILを使用する際、データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はあり

ません。

outputFile レコードを挿入する先のデータファイルのフルパス名。出力データファイルにはデータが入ってい

ても空でもかまいません。 Windows プラットフォームで BUTIL を使用する際、データファイルが現

在のディレクトリに存在する場合は、パスを指定する必要はありません。

/Oowner1 ソースデータファイルのオーナーネーム（必要な場合）。出力データファイルのみでオーナーネー

ムが必要な場合は、 /O に続けて owner1 にスペースを指定します（使用例を参照してください）。

/Oowner2 出力データファイルのオーナーネーム（必要な場合）。

253


例

以下のコマンドは、 COURSE.MKD のレコードを NEWCRS.MKD にコピーします。 COURSE.MKD 入力ファイル

に、オーナーネームは必要ありませんが、 NEWCRS.MKD 出力ファイルでは、オーナーネーム Pam が使用され

ています。

butil -copy course.mkd newcrs.mkd /O /OPam

この例から初の /O を省略した場合、オーナーネーム Pam は、出力データファイルではなく、入力データファ

イルのものとして認識されます。

LOADLOAD コマンドは、入力 ASCII ファイルのレコードをファイルに挿入します。入力 ASCII ファイルは、1 つのファ

イルまたは拡張ファイル（ベースファイルと複数のエクステンションファイル）のどちらでもかまいません。

LOAD コマンドでは、入力 ASCII ファイルのデータは変換されません。データファイルへのレコード移動後、

ロードされたレコードの総数が表示されます。

メモ LOAD コマンドは、アクセラレイティドモードで出力ファイルを開きます。ロードオペレーション中

は、ファイルのログは作成されません。アーカイブログを使用している場合は、 LOAD コマンド使用後に

データファイルを再度バックアップします。

拡張ファイル：次のエクステンションファイルが検出された場合は、ロードが継続されます。 SAVE コマン

ドおよび RECOVER コマンドで作成してあるエクステンションファイルは、削除しないでください。ファ

イルに 3 つのエクステンションファイルが存在し、ユーザーが 2 つ目のエクステンションファイルを削除し

た場合は、 1 つ目のエクステンションファイル処理後に、レコードのロードが中止されます。

SAVE または RECOVER コマンドにより作成されたエクステンションファイルは 3 つなのに、 4 つ目のエ

クステンションファイルが以前の SAVE または RECOVER コマンドで作成されて存在している場合、 4 つ目のエクステンションファイルからもレコードが読み込まれ、データベースエンジンファイルに挿入され

ます。 4 つ目のエクステンションファイルが存在する場合は、 LOAD 開始前に削除してください。

LOAD コマンド実行前には、入力 ASCII ファイルおよびデータファイルを作成する必要があります。入力 ASCIIファイルは、標準のテキストエディターやアプリケーションを使用して作成できますが、そのファイル形式

（「ASCII ファイル形式のインポートとエクスポート」参照）に従う必要があります。データファイル

は、「CREATE」コマンドまたは「CLONE」コマンドを使用して作成できます。

/UID<name>/UIDuname

セキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定し

ます。

/PWD<word>/PWDpword

uname で識別されるユーザーのパスワードを指定します。 uname が指定された場合、 pword は必ず指


/DB<name>/DBdbname



254


形式

butil -load unformattedFile outputFile [/O<owner |*>] [/UIDuname /PWDpword [/DBdbname]]

例

以下の例では、シーケンシャルレコードを COURSE.TXT から COURSE.MKD に読み込みます。 COURSE.MKDのオーナーネームは Sandy です。

butil -load course.txt course.mkd /oSandy

RECOVERRECOVER コマンドは、 MicroKernel ファイルからデータを取り出し、「LOAD」コマンドで使用する入力 ASCIIファイルと同じ形式の ASCII ファイルに書き込みます。これは、破損した MicroKernel ファイルから、一部また

は全部のデータを取り出すときに便利です。 RECOVER コマンドは、すべてではないにしても、ファイルのレ

コードの多数を取り出すことができます。この後は、 LOAD コマンドを使用し、新しい MicroKernel ファイルに

回復したレコードを挿入します。

メモ Maintenance ユーティリティでは、レコードのデータは変換されないため、テキストエディターを使用

してバイナリデータを含む出力ファイルを編集する場合、テキストエディターによってはバイナリデータ

が変更されてしまい、予期しない問題が発生する場合があります。

形式

butil -recover sourceFile unformattedFile [/O<owner |*>] [/Q] [/J] [/I] [/UIDuname /PWDpword [/DBdbname]]

unformattedFile データファイルにロードするレコードを含む ASCII ファイルのフルパス名。 Windows プラット

フォームでは、データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はあ

りません。

outputFile レコードを挿入する先のデータファイルのフルパス名。Windows プラットフォームで BUTIL を使用

する際、データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

/Oowner データファイルのオーナーネーム（必要な場合）。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



sourceFile 回復するデータを含むデータファイルのフルパス名。Windows プラットフォームで BUTIL を使用す

る際、データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

unformattedFile 回復したレコードを保存する ASCII ファイルのフルパス名。


255


ソースファイルの各レコードでは、 RECOVER コマンドで可変ページエラー（ステータスコード 54）が発生し

た場合、現在のレコードから取得できるすべてのデータをシーケンシャルファイルに書き込み、回復処理を継続

します。

ユーティリティでは、以下のメッセージが表示されます。

後に作成されたエクステンションファイルの名前に関する情報が表示されます。

次のエクステンションファイルの存在をチェックし、存在する場合、削除が指示されます。

拡張シーケンシャルファイルを移動した場合、ベースファイルとその全エクステンションファイルの移動

が指示されます。

例

以下の例では、 COURSE.MKD からレコードを取り出し、 COURSE.TXT に書き込みます。

butil -recover course.mkd course.txt

SAVESAVE コマンドは、指定したインデックスパスを使用して MicroKernel ファイルからデータを読み込み、 LOADコマンドで使用する形式に対応した ASCII ファイルに書き込みます。その後、その ASCII ファイルを編集し、

LOAD コマンドを使用して編集後のデータを、別のデータファイルに保存することができます。 ASCII ファイル

形式の詳細については、「ASCII ファイル形式のインポートとエクスポート」を参照してください。

SAVE は、入力データファイルの各レコードに対して、出力 ASCII ファイルにレコードを 1 つ作成します。完了

後、 SAVE によって保存されたレコードの総数が表示されます。

/Q 既存のシーケンシャルファイルに上書きするかどうかを指定します。デフォルトでは、既存のファ

イルに上書きされます。このオプション使用時に同名のファイルが存在する場合は、エラーメッセー

ジが表示されます。

また、回復の対象となるデータベースエンジンファイルが拡張されているかどうかがチェックされ

ます。ファイルが拡張されている場合は、存在する可能性のあるエクステンションファイルと同名

のファイルが存在するかどうかもチェックされます。このいずれかのファイルが存在する場合は、エ

ラーメッセージが表示されます。

/J ファイルを後方から読み込みます。このオプションを使用した場合は、 STEP LAST と STEPPREVIOUS オペレーションを使用してデータベースエンジンファイルのデータ回復が行われます。

デフォルトでは、 STEP FIRST と STEP NEXT オペレーションを使用してファイルの先頭からデータ

が読み込まれます。

/I ファイルを前方から読み込みます。デフォルトでは、前方から読み込まれますが、このオプションを

使用して前方および後方を指定することができます。 /I および /J の両方を指定した場合は、エラーが

発生するまで前方からファイルが読み込まれます。次に、発生したエラーまで、または別のエラーが

発生するまで、ファイルを後から読み込みます。

/J を初に指定した場合は、まず後方から、次に前方から読み込みます。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



256


メモ Maintenance ユーティリティでは、レコードのデータは変換されないため、テキストエディターを使用

してバイナリデータを含む出力ファイルを編集する場合、テキストエディターによってはバイナリデータ

が変更されてしまい、予期しない問題が発生する場合があります。

形式

butil -save sourceFile unformattedFile [Y indexFile | N <keyNumber | -1>] [/O<owner1 | *> [/O<owner2 | *>]] [/Q] [/J] [/I] [/UIDuname /PWDpword [/DBdbname]]

sourceFile 保存するレコードを含むデータファイルのフルパス名。 Windows プラットフォームで BUTIL を使

用する際、データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありま

せん。

unformattedFile レコードを保存する ASCII ファイルのフルパス名。

indexFile デフォルトの設定である小キー番号を使用してレコードを保存しない場合、レコードを保存する

外部インデックスファイルのフルパス名。

keyNumber デフォルトの設定である小キー番号を使用してレコードを保存しない場合、レコードを保存する

キー番号（0 以外）。

-1 Btrieve Step オペレーションを使用して、物理的順序に従ってレコードを保存する場合に指定します。

/Oowner1 ソースファイルのオーナーネーム（必要な場合）。インデックスファイルのみでオーナーネームが

必要な場合は、 /O に続けて owner1 にスペースを指定します。

/Oowner2 インデックスファイルのオーナーネーム（必要な場合）。

/Q 既存のシーケンシャルファイルに上書きするかどうかを指定します。デフォルトでは、既存のファ

イルに上書きされます。このオプション使用時に同名のファイルが存在する場合は、エラーメッセー

ジが表示されます。

また、保存の対象となるデータベースエンジンファイルが拡張されているかどうかがチェックされ

ます。ファイルが拡張されている場合は、存在する可能性のあるエクステンションファイルと同名

のファイルが存在するかどうかもチェックされます。このいずれかのファイルが存在する場合は、エ

ラーメッセージが表示されます。

/J ファイルを後方から読み込みます。このオプションを使用した場合は、GET LAST と GET PREVIOUSオペレーションを使用してデータベースエンジンファイルのデータ回復が行われます。デフォルト

では、 GET FIRST と GET NEXT オペレーションを使用してファイルの保存が行われます。

/I ファイルを前方から読み込みます。デフォルトでは、前方から読み込まれますが、このオプション

を使用して前方および後方を指定することができます。/I および /J の両方を指定した場合は、エラー

が発生するまで前方からファイルが読み込まれます。次に、発生したエラーまで、または別のエラー

が発生するまで、ファイルを後から読み込みます。

/J を初に指定した場合は、まず後方から、次に前方から読み込みます。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname

セキュリティが設定されたデータベース名を指定します。省略した場合はデフォルトのデータベー

スと解釈されます。

257


ユーティリティでは、以下のメッセージが表示されます。

後に作成されたエクステンションファイルの名前に関する情報が表示されます。

次のエクステンションファイルの存在をチェックし、存在する場合、削除が指示されます。

拡張シーケンシャルファイルを移動した場合、ベースファイルとその全エクステンションファイルの移動

が指示されます。

例

以下の 2 つの例は、 SAVE コマンドを使用した、データファイルからのレコード取得方法です。

この例では、 NEWCRS.IDX 外部インデックスファイルを使用して COURSE.MKD からレコードを取得し、それ

らを COURSE.TXT という名前のシーケンシャルテキストファイルに保存します。

butil save course.mkd course.txt newcrs.idx

この例では、キー番号 3 を使用して COURSE.MKD からレコードを取得し、それらを COURSE.TXT という名前

のシーケンシャルテキストファイルに保存します。

butil -save course.mkd course.txt n 3

258

データファイルの作成と変更


このセクションでは、「CLONE」、「CLROWNER」、「CREATE」、「DROP」、「INDEX」、「SETOWNER」、および

「SINDEX」といった各種 BUTIL コマンドを使用した、データファイルの作成と変更に関する詳細について説明

します。またこのセクションでは、「Btrieve データファイルのコンパクト化」で、 Btrieve データファイルの未使

用スペース削除に関して詳細に説明します。







CLONECLONE コマンドは、既存ファイルと同じファイル仕様（オーナーネームを含まず、補足インデックスを含む）

を持つ、空の新規ファイルを作成します。新しいデータファイルには、既存ファイルのすべての定義済みキー属

性（キー位置、キー長、重複キー値など）が含まれます。

CLONE コマンドでは、ファイル情報（「システムデータ」参照）に影響する MicroKernel 設定オプションのすべ

てが無視されます（ファイルバージョンを除く）。 CLONE コマンドは、［作成ファイルのバージョン］オプショ

ンで指定したデータベースエンジンのファイルバージョンを使用して新規ファイルを作成します。

形式

butil -clone outputFile sourceFile [/O<owner | *>] [/pagecompresson | /pagecompressoff] [/recordcompresson | /recordcompressoff] [/UIDuname /PWDpword [/DBdbname]] [/S]

表 62 データファイルの作成と変更を行うコマンド

コマンド説明

「CLONE」既存ファイルの仕様を使用して、空の新規データファイルを作成します。

「CLROWNER」データファイルのオーナーネームをクリアします。

「CREATE」データファイルを作成します。

「DROP」インデックスを削除します。

「INDEX」外部インデックスファイルを作成します。

「SETOWNER」データファイルにオーナーネームを割り当てます。

「SINDEX」インデックスを作成します。

outputFile 空の新規データファイルに使用するフルパス名。Windows プラットフォームで BUTIL を使用する際、

データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

sourceFile 複製する既存データファイルのフルパス名。Windows プラットフォームで BUTIL を使用する際、デー

タファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

259


備考

Btrieve 6.0 以降では、ページサイズが 1,024 バイトのデータファイルで大 23 のキーセグメントを使用するこ

とができるため、 CLONE コマンドでは、既存データファイルに 24 のキーセグメントが含まれ、ページサイズ

が 1,024 バイトの場合、新規データファイルのページサイズは 2,048 バイトに設定されます。これは、既存デー

タファイルがバージョン 6.0 より前の形式で、データベースエンジンロードの際に、「作成ファイルのバージョ

ン」オプションが 5.x または 6.x に設定されていない場合に発生します。

バージョン 7.x 以前のファイルを複製する場合は、作成する新規ファイルのバージョン設定を確認してください。

たとえば、 6.15 ファイルを 9.5 形式で複製する場合は、［作成ファイルのバージョン］オプションを 9.5 に設定し

ます。

メモソースファイルがシステムデータを含まない 8.x 以上の形式の場合は、データベースエンジンの設定

にかかわらず、出力ファイルにもシステムデータは含まれません。既存ファイルへのシステムデータの追加

については、『Getting Started with Pervasive PSQL』を参照してください。

ステータスコード 30 （指定されたファイルは MicroKernel ファイルではありません）が発生し、ソースファイル

のヘッダーページが破損している可能性がある場合、ディスクリプションファイルで「CREATE」コマンドを使

用して新規の MicroKernel ファイルを作成します。

例

以下のコマンドは、 COURSE.MKD ファイルを複製して NEWCRS.MKD ファイルを作成します。

butil -clone newcrs.mkd course.mkd

CLROWNERCLROWNER コマンドは、 MicroKernel ファイルのオーナーネームをクリアします。

/Oowner ソースデータファイルにオーナーネームが割り当てられている場合は、そのオーナーネーム。新規

データファイルには、オーナーネームは含まれません。詳細については、「オーナーネーム」を参照


/pagecompresson outputFile のページ圧縮をオンにすると、以下の条件が設定されます。

Pervasive PSQL データベースエンジンのバージョンは Pervasive PSQL 9.5 以上

作成ファイルのバージョン設定は 0950 （9.5）以上。「作成ファイルのバージョン」を参照してく

ださい。

/pagecompressoff outputFile のページ圧縮をオフにします。このパラメーターは、 sourceFile にページ圧縮が指定されて

いない場合は無効です。

/recordcompresson outputFile のページ圧縮をオンにします。

/recordcompressoff outputFile のレコード圧縮をオフにします。このパラメーターは、 sourceFile にレコード圧縮が指定さ

れていない場合は無効です。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



260


形式

butil -clrowner sourceFile </O<owner | *> [/UIDuname /PWDpword [/DBdbname]]

例

以下のコマンドは、 TUITION.MKD のオーナーネームをクリアします。このファイルのオーナーネームは Sandyです。

butil -clrowner tuition.mkd /OSandy

CREATECREATE コマンドは、ディスクリプションファイルで指定されている属性を使用して、空の MicroKernel ファイ

ルを作成します。CREATE コマンドを実行する前に、新しいキー属性を指定するディスクリプションファイルを

作成します。詳細については、「ディスクリプションファイル」を参照してください。

形式

butil -create outputFile descriptionFile [< Y | N >] [/UIDuname /PWDpword [/DBdbname]]

sourceFile データファイルの完全なフルパス名。 Windows プラットフォームで BUTIL を使用する際、データ

ファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

/Oowner クリアするオーナーネーム詳細については、「オーナーネーム」を参照してください。

/UID<name>

/UIDunameセキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定し

ます。

/PWD<word>

/PWDpworduname で識別されるユーザーのパスワードを指定します。 uname が指定された場合、 pword は必ず指


/DB<name>

/DBdbnameセキュリティが設定されたデータベース名を指定します。省略した場合はデフォルトのデータベース


outputFile 作成するデータベースエンジンファイルのフルパス名。ファイル名が既存の MicroKernel ファイルと

同名の場合、既存ファイルの代わりに空の新規ファイルが作成されます。既存ファイルに保存されて

いるデータは消去され、回復することができません。 Windows プラットフォームで BUTIL を使用す

る際、データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

descriptionFile 新規 MicroKernel ファイルの仕様を含むディスクリプションファイルのフルパス名。

Y | N 既存のファイルに上書きするかどうかを指定します。このオプションに N を指定し、同名の

MicroKernel ファイルが存在する場合は、エラーメッセージが表示されます。デフォルト設定は、 Yです。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



261


例

以下のコマンドは、 CREATE.DES ディスクリプションファイルで定義された内容を使用し、ファイル

COURSE.MKD を作成します。

butil -create course.mkd create.des

CREATE コマンドで使用するディスクリプションファイルの例図 35 の例では、 MicroKernel 形式のファイルが作成されます。ファイルのページサイズは 512 バイト、キーは 2つに設定されています。ファイルの各レコードの固定長部は 98 バイトに設定されています。このファイルでは、

可変長レコードがブランクトランケーション、レコード圧縮、可変長部割り当てテーブル（VAT）を使用しない

ように指定されています。空きスペーススレッショルドは、 20 パーセントに設定されています。プリアロケー

ションは、 100 ページに設定されています。ファイル作成時に、 100 ページつまり 51,200 バイトがプリアロケー

トされます。

図 35 CREATE コマンドで使用するディスクリプションファイルの例

キー 0 は、重複可能で変更不可能な文字列セグメントを 2 つ含むセグメントキーで、この 2 つのセグメントには、

16 進数で 20 （スペース）のヌル値が指定されています。キー 0 では、コレーティングシーケンス upper.alt が使

用されます。

キー 1 は、重複不可能で変更可能な数値型のセグメント化されていないキーです。これは、降順でソートされます。

DROPDROP コマンドは、ファイルからインデックスを削除し、それ以降のキー番号から 1 を引くことによって、残り

のインデックスのキー番号を調整します。キーの番号を調整しない場合は、削除に指定したキー番号に 128 を加

算します。この調整は、 6.0 以降のファイルでのみ使用可能です。

形式

butil -drop sourceFile < keyNumber | SYSKEY > [/O<owner | *>] [/UIDuname /PWDpword [/DBdbname]]

sourceFile インデックスを削除するファイルのフルパス名。Windows プラットフォームで BUTIL を使用する際、

データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

keyNumber 削除するキー番号。元のキー番号を維持する場合は、指定したキー番号に 128 というバイアス値を足

します。

record=98 variable=y truncate=n compress=ykey=2 page=512 allocation=100 replace=nfthreshold=20 vats=y

position=1 length=5 duplicates=ymodifiable=n type=string alternate=ynullkey=allsegs value=20 segment=y

position=6 length=10 duplicates=ymodifiable=n type=string alternate=ynullkey=allsegs value=20 segment=n

position=16 length=2 duplicates=nmodifiable=y type=numeric descending=ynullkey=n segment=n

name=c:\myacsfiles\upper.alt

ファイル仕様

キー 0セグメント 1


キー 1

262


例

以下の例では、 COURSE.MKD に 3 つのキーが存在します。ファイルの元のキーは、それぞれの番号が 0、 1、 2となっています。

初の例では、 butil -drop コマンドで、COURSE.MKD からキー番号 1 を削除し、残りのキー番号をそれぞれ 0 と1 に調整します。

butil -drop course.mkd 1

以下の例では、 butil -drop コマンドでキー番号 1 を削除し、キー番号の調整は行いません。キー番号は、それぞ

れ 0 と 2 のままになります。

butil -drop course.mkd 129

INDEXINDEX コマンドは、既存ファイルでキーとして指定されていないフィールドに基づき、既存 MicroKernel ファイ

ルの外部インデックスファイルを構築します。INDEX コマンドを実行する前に、新しいキー属性を指定するディ

スクリプションファイルを作成します。ディスクリプションファイルの詳細については、「ディスクリプション

ファイル」を参照してください。

新規ファイルのレコードは、以下から構成されます。

既存データファイルに含まれる各レコードの 4- バイトのアドレス

ソートの基準として使用する新しいキー値

メモディスクリプションファイルで指定したキー長が 10 バイトの場合、外部インデックスファイルのレ

コード長は 14 バイト（10 + 4- バイトアドレス）になります。

SYSKEY システム定義のログキー（システムデータ）を削除します。システム定義のログキーを削除した場

合でも、レコードから値は消去されず、新しく挿入されたレコードには、重複しないシステム定義の

ログキー値が割り当てられます。

しかし、重複しないユーザー定義のキーが存在しない限り、システム定義のログキーが削除された

ファイルのログは実行されません。この理由から、システム定義のログキーが破損している可能性が

あり、再追加する場合にのみ、このオプションを使用してください。

SINDEX コマンドを使用すると、削除したシステム定義のログキーを再利用できます。

/Oowner ファイルのオーナーネーム（必要な場合）。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



263


形式

butil -index sourceFile indexFile descriptionFile [/O<owner | *>] [/O<owner | *>] [/UIDuname /PWDpword [/DBdbname]]

備考

INDEX コマンドは、外部インデックスファイルを作成し、インデックスが設定されたレコードの数を表示しま

す。外部インデックスファイルを使用して、データファイルのレコードを読み込む場合は、「SAVE」コマンドを

使用します。

INDEX コマンドで使用するディスクリプションファイルの例

以下のディスクリプションファイルでは、 1 つのセグメントを含む新しいキーを定義します。キーは、レコード

の 30 バイト目から始まり、 10 バイトの長さを持ちます。また、重複と変更が可能な STRING 型で、オルタネー

トコレーティングシーケンスを使用しません。

図 36 INDEX コマンドで使用するディスクリプションファイルの例

例

以下のコマンドは、データファイル COURSE.MKD を使用し、外部インデックスファイル NEWCRS.IDX を作成

します。 COURSE.MKD には、オーナーネームは必要ありません。新しいキーの定義を含むディスクリプション

ファイルは、 NEWCRS.DES という名前です。

butil -index course.mkd newcrs.idx newcrs.des

SETOWNERSETOWNER コマンドは、データファイルのオーナーネームを設定します。

sourceFile 外部インデックスを構築する既存ファイルの完全なフルパス名。 Windows プラットフォームで

BUTIL を使用する際、データファイルが現在のディレクトリに存在する場合は、パスを指定する必

要はありません。

indexFile 外部インデックスを保存するインデックスファイルのフルパス名。

descriptionFile 新しいキー定義を含む、作成したディスクリプションファイルのフルパス。ディスクリプションファ

イルには、新しいキーの各セグメントに対する定義が含まれている必要があります。


/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



264


形式

butil -setowner sourceFile /O<owner | *> level [/L] [/UIDuname /PWDpword [/DBdbname]]

例

以下の例では、 course.mkd データファイルの短いネームのオーナーを作成します。オーナーネーム Sandy に制限

レベル 1 を設定します。

butil -setowner course.mkd /OSandy 1

以下の例では、 billing.mkd データファイル用の長いオーナーネームを作成し、そのオーナーネームとファイル

を暗号化し、すべてのアクセスモードを制限します。

butil -setowner billing.mkd /Ohr#Admin$945k7YY%svr 2 /L

SINDEXSINDEX コマンドは、既存 MicroKernel ファイルに追加インデックスを作成します。デフォルトでは、新規イン

デックスのキー番号は、データファイルでそれまで大だったキー番号より 1 つ大きな番号になりますが、キー

番号を指定することも可能です。例外として、 DROP コマンドでインデックスを削除し、残りキー番号の調整を

行わなかった場合は、未使用のキー番号が存在するため、新しいインデックスに初の未使用番号が割り当てら

れます。

キー番号オプションを使用することにより、新規インデックスのキー番号を指定できます。指定するキー番号は、

ファイルで使用されていない有効なキー番号でなければなりません。無効なキー番号を指定した場合は、ステー

タスコード 6 が返されます。

sourceFile データファイルのフルパス名。 Windows プラットフォームで BUTIL を使用する際、データファイ

ルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

/Oowner 設定するオーナーネーム

level データファイルのアクセス制限の種類。以下は、このパラメーターの説明です。

level は /O パラメーターの直後に置く必要があります。

0: すべてのアクセスモードでオーナーネームが必要（データ暗号化なし）

1: リードオンリーアクセスにはオーナーネームは必要なし（データ暗号化なし）

2: すべてのアクセスモードでオーナーネームが必要（データ暗号化あり）

3: リードオンリーアクセスにはオーナーネームは必要なし（データ暗号化あり）

/L 長いオーナーネームを指定します。

オーナーネームでは大文字と小文字が区別されます。また、短いものと長いものがあります。短い

オーナーネームは半角 8 文字までの範囲で指定できます。長いオーナーネームは半角 24 文字まで

の範囲で指定できます。長いオーナーネームに関する制限事項については、『Btrieve API Guide』の

「Set Owner （29）」で「手順」を参照してください。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword

uname で識別されるユーザーのパスワードを指定します。 uname が指定された場合、 pword は必ず

指定する必要があります。

/DB<name>/DBdbname



265


このコマンドで SYSKEY オプションを使用しない場合は、 SINDEX コマンドを使用する前に、インデックスの

キー仕様を定義するディスクリプションファイルを作成する必要があります。ディスクリプションファイルの詳

細については、「ディスクリプションファイル」を参照してください。

形式

butil -sindex sourceFile <descriptionFile | SYSKEY> [keyNumber] [/O<owner | *>] [/O<owner | *>] [/UIDuname /PWDpword [/DBdbname]]

例

以下の例では、 COURSE.MKD にインデックスを追加します。ディスクリプションファイルの名前は、

NEWIDX.DES です。

butil -sindex course.mkd newidx.des

以下の例では、システム定義キーが削除された COURSE.MKD にシステム定義キーを追加します。

butil -sindex course.mkd syskey

Btrieve データファイルのコンパクト化

BUTIL では、複数のコマンド（「CLONE」、「RECOVER」、「LOAD」）を使用してデータファイルの未使用スペー

スを削除し、ファイルサイズを縮小することができます。

Btrieve データファイルをコンパクト化するには

1 データファイルの名前を変更し、「CLONE」オプションを使用して元のファイルと同名の空のデータファイ

ルを作成します。

2 「RECOVER」を使用し、複製したファイルのデータを、シーケンシャルテキストファイルに保存します。

3 「LOAD」を使用し、回復されたデータを複製ファイルにロードします。

空のレコード以外のデータを含むすべてのレコードは、新しく作成したデータファイルにロードされます。

（この処理は、対話型 Maintenance ユーティリティを使用して実行することもできます）。

sourceFile 外部インデックスを構築する既存ファイルの完全なフルパス名。Windows プラットフォームで BUTILを使用する際、データファイルが現在のディレクトリに存在する場合は、パスを指定する必要はあり

ません。

descriptionFile 新しいキー定義を含む、作成したディスクリプションファイルのフルパス。ディスクリプションファ

イルには、新しいキーの各セグメントに対する定義が含まれている必要があります。

SYSKEY システムキーが削除されたファイルに、システムキーを再追加します。


/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



266

データファイル情報の表示


このセクションでは、 STAT を使用した、データファイルの特性と情報を含むレポートの作成について説明しま

す。

STATSTAT コマンドは、定義されているデータファイルの特性、およびファイルの内容に関する情報を含むレポート

を作成します。 STAT コマンドは、データベースエンジンのトランザクション一貫性保守機能によってファイル

のログを作成できるかどうかを確認する際に便利です。 STAT コマンドでは、 Create Supplemental Index オペレー

ション（Btrieve 6.0 以降）および Create オペレーションのいずれで作成されたかに関わらず、同じインデックス


形式

butil -stat <sourceFile> [/O<owner | *>] [/O<owner | *>] [/UIDuname /PWDpword [/DBdbname]]

例

以下の例では、 PATIENTS.DTA のファイル情報を表示します。データファイルには、オーナーネームは含まれ

ません。

butil -stat patients.dta

以下は、結果レポートの例です。

**************************************************File Statistics for PATIENTS.DTA

File Version = 8.00Page Size = 2048Page Preallocation = NoKey Only = NoExtended = No

Total Number of Records = 16Record Length = 104Record Compression = NoVariable Records = No

Available Linked Duplicate Keys = 0Balanced Key = NoLog Key = 1 System Data = No

sourceFile 情報を表示するデータファイルのフルパス名。 Windows プラットフォームでは、データファイルが

現在のディレクトリに存在する場合は、パスを指定する必要はありません。


/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



267


Total Number of Keys = 3Total Number of Segments = 4

Key Segment Position Length Type FlagsNull Values* Unique ACS Values0 1 21 20 String MD-- 16 00 2 7 12 String MD-- 16 01 1 1 6 String M-- 16 02 1 83 10 String MD-- 7 0

Alternate Collating Sequence (ACS) List: 0 UPPER

凡例： < = Descending Order D = Duplicates Allowed I = Case Insensitive M = Modifiable R = Repeat Duplicate A = Any Segment (Manual) L = All Segments (Null) * = The values in this column are hexadecimal.?? = Unknown-- = Not Specified

この例では、ファイル PATIENTS.DTA が、 8.0 形式のファイルであることを表しています（バージョン番号は、

そのファイル形式を読むことができる Btrieve の一番古いバージョン）。ファイルには、 2,048 バイトのページサイズが指定されており、プリアロケートページはありません。これは、キーオンリーファイルでも拡張ファイ

ルでもありません。

このファイルには 16 件のレコードが挿入されています。また、 104 バイトのレコード長が定義されており、レ

コード圧縮は使用せず、可変長レコードも許可されていません。

このファイルには、リンク可能な重複キーは存在せず、インデックスバランスも使用しません。キー 1 を使用し

たログが実行され、ファイルには、システム定義のデータも存在しません。また、 4 つのキーセグメントから構

成される 3 つのキーが存在します。

メモ「SINDEX」で作成したインデックスには、「予約重複ポインター」要素を指定しない限り、デフォルト

で R が割り当てられます。

STAT レポートには、特定のキーに関する情報も表示されます。たとえば、キー 0 が、重複可能、変更可能であ

り、 2 つのセグメントから構成されることが、レポートに表示されます。

初のセグメントはポジション 21 から始まり、長さが 20 バイト、重複可能、変更可能、そして STRING 型として保存されます。ハイフンは、ヌル値が定義されていないことを表します。 Unique Values の列は、 16 個の重複しない値がセグメントに挿入されていることを表しています。このセグメントでは、オルタネートコレーティングシーケンスファイル upper.alt が使用されます。

2 つ目のセグメントはポジション 7 から始まり、長さが 12 バイト、重複可能、変更可能、そして STRING 型として保存されます。 16 個の重複しない値が、このセグメントに挿入されています。このセグメントでは、

オルタネートコレーティングシーケンスファイル upper.alt が使用されます。

キー 1 は、このファイルのログに使用されるキーです。キー 1 は、 1 つのセグメントで構成されます。ポジショ

ン 1 から始まり、長さが 6 バイト、重複不可、変更可能、そして STRING 型として保存されます。 16 個の重複し

268


ないキー値が、このキーに挿入されています。このキーでは、オルタネートコレーティングシーケンスファイ

ル upper.alt が使用されます。

キー 2 は、 1 つのセグメントで構成されます。ポジション 83 から始まり、長さが 10 バイト、重複可能、変更可

能、そして STRING 型として保存されます。7 個の重複しないキー値が、このキーに挿入されています。このキー

では、オルタネートコレーティングシーケンスファイル upper.alt が使用されます。

ファイルバージョンに関する注意

ファイル形式のバージョンをレポートする際、データベースエンジンは指定したファイルを読むことのできる

も古いエンジンのバージョンを出力します。たとえば、 Btrieve 5.x 形式で作成されたファイルがあっても、 4.x と5.x の機能を一切使用していないのであれば、レポートにはバージョン 3.x ファイルと出力されます。 6.x 形式で

始めるには、ファイル自体にバージョンスタンプを含める必要があります。 6.x より前のバージョンでは、ファ

イルバージョンを調べる唯一の方法は、ファイルが使用している機能を調べることです。バージョン 5.x 以前の

ファイルで、使用されているかどうかによってレポートに出力されるバージョンを決定する機能を次の表に示し

ます。

表 63 バージョン 5.x 以前のファイル形式の機能

レポートに出力される


... これらの機能の 1 つ以上が使用されている場合

5.x 圧縮レコード

キーオンリーファイル

4.x 拡張キータイプ

可変長レコード

CreateIndex オペレーションで追加されたインデックス

3.x 上記のいずれも使用していない

269


Btrieve インターフェイスモジュールのバージョンの表示

このセクションでは、 VER コマンドを使用した、 Btrieve インターフェイスモジュールのバージョンの表示に関

して詳細に説明します。

VERVER コマンドは、データベースエンジンおよび Btrieve アクセスモジュールの両方のバージョン番号を表示しま

す。

形式

butil -ver

備考

VER コマンドを実行した場合、以下のようなメッセージが表示されます（Windows NT）。

Btrieve リクエスターのバージョンは 10.00 です。Btrieve のバージョンは 10.00 で、 xxx 版です。

270

Btrieve インターフェイスとリクエスターのアンロード（DOS のみ）

Btrieve インターフェイスとリクエスターのアンロード（DOS のみ）

STOPSTOP コマンドは、 Btrieve インターフェイスおよびリクエスターをアンロードします。

形式

butil -stop

271


Continuous オペレーションの実行

Continuous オペレーションに関連するコマンド startbu および endbu については、「ログ、バックアップおよび復

元」で説明しています。

272



Btrieve Maintenance ユーティリティ（GUI またはコマンドラインの BUTIL）は、アーカイブログファイルをデー

タファイルにロールフォワードする手段を提供します。「ログ、バックアップおよび復元」を参照してください。

BUTIL ROLLFWD コマンドは、後のバックアップからシステムエラーが発生する間に行った、データファイ

ルへの変更を回復します。システムエラーが発生した場合は、データファイルのバックアップコピーを復元し

た後、 BUTIL ROLLFWD コマンドを使用し、ログに保存されているすべての変更を復元したデータファイルに

適用します。バックアップからデータファイルを復元しない限り、このコマンドを使用しないでください。

メモ ROLLFWD コマンドを利用するには、 MicroKernel の［選択ファイルのアーカイブロギング］オプショ

ンを有効にし、システムエラー発生前にファイルのバックアップを行う必要があります。

また、ROLLFWD コマンドを使用し、ログオペレーションの出力ファイルを作成することも可能です。ROLLFWDコマンドでは、ロールフォワード前、またはロールフォワードと同時に出力ファイルを作成できます。

単一のファイルをロールフォワードすることもできますし、ボリューム上のすべてのデータファイル、ドライブ

上のすべてのデータファイル、もしくは、ファイル、ボリュームおよび / またはドライブのリストをロールフォ

ワードすることもできます。

GUI の使用

1 オペレーティングシステムの［スタート］メニューまたはアプリ画面から、あるいは Pervasive PSQL ControlCenter の［ツール］メニューから Maintenance ユーティリティにアクセスします。

2 ［Btrieve Maintenance ユーティリティ］ウィンドウで、［データ｜ロールフォワード］を選択します。［ロー

ルフォワード］ダイアログボックスが表示されます。

図 37 ［ロールフォワード］ダイアログ

3 オペレーションタイプとして、 " 単一ファイル "、 " ファイルのリスト "、 " ボリューム名 "、 " ドライブレター " のいずれかを選択します。 " ボリューム名 " または " ドライブレター " を選択する場合は、名前の

後に円記号（\）またはスラッシュ（/）を挿入する必要があります（例、 \\server\vol1\ または D:\ など）。

4 ロールフォワードタスクの実行に必要なすべての Btrieve オペレーションのリストである、ダンプファイル

と呼ばれるログファイルを作成することができます。

273


デフォルトでは、このファイルは作成されません。ファイルを作成する場合は、［ダンプファイルを作成す

る］チェックボックスをオンにします。以下のオプションも設定可能です。

メモ実行する Btrieve オペレーションに対して、キーバッファーまたはデータバッファーが入力パラメー

ターでない場合、ダンプファイルには何も書き込まれません。

5 ［実行］をクリックし、ダンプファイルの作成やロールフォワードを実行します。データが有効な場合は、

［ロールフォーワードステータス］ダイアログボックスが表示されます。

図 38 ［ロールフォワードステータス］ダイアログボックス

処理されたファイルは、リストボックスに追加され、ファイル名、およびロールフォワードオペレーショ

ンから返される Pervasive PSQL ステータスコードが表示されます。

処理中にエラーが発生した場合は、エラー時のロールフォワード続行を指定できるダイアログボックスが

表示されます。このダイアログボックスでは、このダイアログを再表示することなく処理を継続するか、処

理を継続して必要な場合にこのダイアログを再表示するか、またはファイル処理の中断を選択できます。

表 64 ロールフォワード GUI オプション

ダンプファイルの作成のみダンプファイルのみが作成され、ロールフォワードは実行されません。

ダンプファイル名これには、円記号（\）またはスラッシュで始まるダンプファイル名が含まれ、ドライブ

文字、サーバー名またはボリューム名は含まれません。

データバッファー長各 Btrieve オペレーションで、ダンプファイルに書き込まれるデータバッファーのバイト

数を表します。

キーバッファー長各 Btrieve オペレーションで、ダンプファイルに書き込まれるキーバッファーのバイト数

を表します。

16 進で数値を表示このオプションを選択した場合は、ダンプファイル出力の数が 16 進形式で表示されます。

このオプションを選択しない場合、数は十進形式で表示されます。

詳細ユーザー名、ネットワークアドレス、タイムスタンプなど、ダンプファイルの補足情報

が含まれます。

274


図 39 エラー時のロールフォワード続行を指定するダイアログボックス

コマンドラインの使用

このセクションでは、ロールフォワードをコマンドラインで使用する構文を説明します。

butil -rollfwd <sourceFile | drive | @listFile> [</L[dumpFile] | /W[dumpFile]> [/T<dataLength>] [/E<keyLength>] [/H] [/V] [/O<ownerList | owner>|*]][/A] [/UID<name> <PWD<word>> [DB<name>]]

sourceFile 変更をロールフォワードするデータファイルのフルパス名。Windows プラットフォームでは、デー

タファイルが現在のディレクトリに存在する場合は、パスを指定する必要はありません。

drive 変更をロールフォワードするドライブ文字。ボリューム名の後には、円記号（\）またはスラッ

シュ（/）を使用します（例： F:\、 F:/）。

listFile 変更をロールフォワードするファイルのパス、ボリューム、ドライブを含む、テキストファイルの

フルパス名。これらのパスは、キャリッジリターン / ラインフィードで区切ります。エラーが発生

した場合は、現在のファイルのロールフォワードが中断されますが、その時点までの変更はロール

バックされます。 /A オプションを指定した場合は、次のファイルからロールフォワードが継続され

ます。

/LdumpFile ロールフォワードを実行せず、出力ファイルを作成します。

/WdumpFile ロールフォワードを実行し、出力ファイルを作成します。

dumpFile ログオペレーションが書き込まれる出力ファイルの名前。デフォルトは \BLOG\BROLL.LST で、物

理ドライブのルートに関連付けられます。ファイル名は、スラッシュ（/）または円記号（\）で始ま

り、ドライブ文字やボリューム名は使用しません。ファイルは、 BLOG.CFG と同じボリュームに配

置されます。

/TdataLength 出力ファイルに書き込む、オペレーションのデータバッファーの長さを指定します。このオプショ

ンを指定しない場合は、出力ファイルにデータバッファーの内容が含まれません。

/EkeyLength 出力ファイルに書き込む、オペレーションのキーバッファーの長さを指定します。このオプション

を指定しない場合は、出力ファイルにキーバッファーの内容が含まれません。

/H 出力ファイルの数値表示を 16 進数形式にします。このオプションを指定しない場合、出力ファイル

の数値は ASCII 形式で表示されます。このオプションは、エントリ数、オペレーションコード、キー

番号、データ長の各フィールドの形式に影響します。

/V 出力ファイルに、補足情報（ユーザー名、ネットワークアドレス、タイムスタンプなど）が追加さ

れます。

/O データファイルのオーナーネームを指定します（必要な場合）。ログに記録したオペレーションの

出力ファイルをリクエストし、データファイルのバックアップコピーにリードオンリーアクセス

用のオーナーネームが存在する場合に、オーナーネームが必要になります。

2 つ以上のファイルにオーナーネームがある場合は、それぞれのオーナーネームはカンマで区切る

必要があります。詳細については、「オーナーネーム」を参照してください。

275


メモ実行する Btrieve オペレーションに対して、キーバッファーまたはデータバッファーが入力パラメー

ターでない場合、ダンプファイルには何も書き込まれません。

例

例 A 次の例は、 CLASS.MKD ファイルに、デフォルトのアーカイブログおよびログロケーションから変更を回

復します。

butil -rollfwd file_path\PSQL\Demodata\class.mkd


例 B この例では変更を回復し、それらを以下のオプションを使用して d:\ ボリュームのすべてのファイルに出力

します。

デフォルトのダンプファイル使用

書き込むデータバッファーの長さを 32 バイトに設定

書き込むキーバッファーの長さを 4 バイトに設定

16 進モードで書き込み

butil -rollfwd d:\ /W /H /T32 /E4

例 C 以下の例では、ロールフォワードは実行されず、以下のダンプオプションに従って、 files.txt にリスト

されているファイルへの変更が出力されます。

d:\temp\files.lst をダンプファイルとして使用

追加情報を書き込む

データファイルにはオーナーネーム own123 および own321 が含まれる

データバッファーやキーバッファーは出力しない

butil -rollfwd d:\temp\files.txt /L\temp\files.lst /V /Oown123,own321

/A 複数ファイルのロールバック中にエラーが発生した場合、次のファイルからロールフォワードを継

続します。

このオプションを指定しない場合は、エラー発生時にロールフォワードが中断され、その時点まで

の変更はロールバックされません。

メモ： /A オプションを使用した場合は、出力をファイルにリダイレクトできます。「エラーメッセー

ジのリダイレクト」および「コマンドファイル」の説明を参照してください。

/UID<name>/UIDuname


ます。

/PWD<word>/PWDpword



/DB<name>/DBdbname



276

14
データファイルの変換
Pervasive PSQL ファイル互換性を維持する

Pervasive PSQL には、Pervasive PSQL ファイルを、Pervasive PSQL エンジンの新バージョンで利用できるように

する変換するツールがあります。この章では、これらのツールの概要、その使用目的と使用方法を説明します。

以下の項目について説明します。

「Rebuild ユーティリティの概念」

「Rebuild ユーティリティの GUI のリファレンス」

「Rebuild ユーティリティの作業」

277


Rebuild ユーティリティの概念

Rebuild ユーティリティを使用すると、 MicroKernel ファイル（データファイルと辞書ファイル）に対して以下の

操作を行うことができます。

旧ファイル形式を新しい Pervasive PSQL 形式に変換する

新しいファイル形式を 6.x 形式より古くない形式に変換する

同じファイル形式（6.x、 7.x、 8.x または 9.x）を使用してファイルをリビルドする

ファイルにインデックスを追加する

ファイルのページサイズを変更する

ファイルをリビルドしてシステムデータとキーまたはキーなしのシステムデータを含める

Rebuild で使用するログファイルの場所と名前を指定する

データベースで辞書ファイル（DDF）を使用している場合は、データファイルだけでなくこれらもリビルドする


データファイルのリビルドの概念についてより理解を深めるため、以下のセクションをお読みください。

「サポートされるプラットフォーム」

「ファイル形式」

「コマンドラインパラメーター」

「テンポラリファイル」

「Rebuild 処理の適化」

「ログファイル」

Rebuild ユーティリティの使用についての情報は、以下のセクションを参照してください。

「Rebuild ユーティリティの GUI のリファレンス」

「Rebuild ユーティリティの作業」

「CLI 操作」

サポートされるプラットフォーム

Rebuild には 2 つの様式があります。 1 つは Windows 用の 32 ビット GUI バージョンで、もう 1 つは Linux および

Windows 用のコマンドラインバージョンです。「Rebuild ユーティリティの GUI のリファレンス」および「CLI操作」を参照してください。

Linux CLI Rebuild

Rebuild は Linux では rbldcli というプログラムとして実行されます。デフォルトでは、このプログラムは /usr/local/psql/bin にあります。

Windows CLI Rebuild

Rebuild は Windows では rbldcli.exe というプログラムとして実行されます。これらのファイルはデフォルトで、

Program Files ディレクトリにインストールされます。

278


ファイル形式

現在のデータベースエンジンはいくつかの古いデータ形式や辞書ファイル形式と互換性を保っていますが、新

の機能を利用するためにファイルを新の形式に変換したい場合があります。次の表に、旧形式から新しい形式

に変換する主な理由を挙げます。

コマンドラインの Rebuild ユーティリティを使用してできたファイル形式は、 -f パラメーターによって異なりま

す。 -f パラメーターを指定しないと、 Rebuild は MicroKernel の［作成ファイルのバージョン］設定オプション

に指定されている値を使用します。たとえば、［作成ファイルのバージョン］の値が 8.x の場合、バージョン 7.xのファイルに対して Rebuild ユーティリティを実行すると、このファイルはバージョン 8.x の形式に変換されま

す。「作成ファイルのバージョン」および -f パラメーターを参照してください。

Rebuild ユーティリティを実行する前に、変換するデータファイルをすべてバックアップしておくことをお勧め

します。これは、元のファイルと同じ場所にリビルドする場合には特に重要です（この場合リビルドされたファ

イルは元のファイルを置き換えます）。バックアップコピーを取っておけば、必要な場合に元のファイルを復元

することができます。バックアップを確実に実行するためには、以下のいずれかの操作を行います。

バックアップユーティリティを実行する前にすべてのデータファイルを閉じます。

Continuous オペレーションを使用します（バックアップ中のみ）。

メモ Continuous オペレーションモードになっているファイルで Rebuild ユーティリティを実行することはで

きません。

テンポラリファイル

Windows では、 Rebuild は TMP システム環境変数で指定されたディレクトリにテンポラリファイルを作成しま

す。デフォルトで、 Linux では Rebuild は出力ディレクトリ（-b パラメーターが使用されていない場合はソース

ディレクトリ）にテンポラリファイルを作成します。このため、テンポラリファイルディレクトリには元のファ

イルと新しいファイルの両方を格納するために十分なディスク容量が必要です（Rebuild ユーティリティの実行

中）。 Rebuild GUI バージョンの［出力ディレクトリ］オプションを使用するか、 CLI バージョンの -B オプション

を使用して、これらのファイルを別のディレクトリに保存するように指定できます。

表 65 Rebuild ユーティリティによる変換

変換前のファイル

形式

変換後のファイル

形式

変換の理由

9.0 9.5 120 個以上のセグメントキーと大 256 GB のファイルサイズ。

8.x 9.x 大 128 GB のファイルサイズのサポートの追加。

8.x 8.x ファイルから削除レコードのスペースを除去する、ページサイズを変更する、

またはシステムデータを追加する。

v8.x より前 8.x 書き込み（Insert、Update、Delete）パフォーマンスの向上（Turbo Write Acceleratorによっても実現）。

7.x 7.x 変換前のファイルには、システムキーがない。

v7.x より前 7.x バージョン 7.x の機能の利用および全般的なパフォーマンスの向上。

v6.0 より前 6.x バージョン 6.x の機能の利用および全般的なパフォーマンスの向上。バージョ

ン 6.x のエンジンとバージョン 7.x のエンジンが共に稼動している場合にのみ、

このオプションを使用します。

279


通常、変換が終了するとテンポラリファイルは自動的に削除されます。ただし、停電などの重大な障害が発生し

た場合は、テンポラリファイルが削除されないことがあります。このような場合は、以下のタイプのテンポラリ

ファイルを削除してください。

Rebuild 処理の適化

Rebuild はデータベースエンジンに Btrieve 呼び出しを行います。したがって、データベースエンジン環境設定お

よびお使いのコンピューター上のランダムアクセスメモリ（RAM）の量がリビルド処理のパフォーマンスに影

響を与えます。このことは、特にサイズの大きなデータファイルをリビルドする際の所要時間を見れば明らかで

す。

一般的に、インデックスを構築するのはデータページを構築するよりはるかに時間がかかります。インデックス

を多数持つデータファイルがある場合、同じファイルでインデックスが少ないものに比べ、ファイルを構築する

のにより多くの時間を要します。

リビルドの処理時間には以下の項目が影響します。

「CPU 速度およびディスク速度」

「メモリ量」




「インデックスページサイズ」

「インデックス数」

CPU 速度およびディスク速度

CPU （中央処理装置）の速度および物理ストレージディスクへのアクセス速度が、リビルドの処理時間に影響し

ます。一般的に、これらの両方の速度が速いほどリビルド処理も速く行われます。ディスク速度は、メモリに全

体が入りきらない大きなファイルのリビルドではより重要になります。

ヒント 3 GB または 4 GB 以上などの大きなサイズのファイルでは変換に数時間かかる場合があります。複

数のデータベースエンジンが使用できる場合、リビルド処理をいくつかのマシンの CPU 間で分担したいと

考えるでしょう。たとえば、すべてのファイルの中からいくつかずつをデータベースエンジンがインストー

ルされている各マシンにコピーし、リビルド処理が終わったらファイルをコピーして元に戻します。

メモリ量

Rebuild では、デフォルトの方法ともう 1 つの方法の 2 つの方法を用いてファイルをリビルドすることができま

す。「-m<0 | 2>」パラメーターを参照してください。選択する方法は、使用できるメモリの量によって決まります。

デフォルトの方法（-m2）では、利用可能なメモリがあれば、 Rebuild は以下の手順を行います。

1 元のファイルに定義されているのと同じレコード構造とインデックスを持つ空のデータファイルを新規作

成します。

2 新しいファイルからすべてのインデックスを削除します。

3 新しいファイルにインデックスなしですべてのデータをコピーします。

プラットフォームテンポラリファイル名

Linux _rbldxxxxxx、ここで、 xxxxxx はランダムな 6 個の文字です。注意： Rebuild 実行モジュールである

rbldcli を削除しないようにしてください。

Windows _rbldx、 x は数字です。

280


4 以下の処理でインデックスを追加します。

a. 元のファイルの特定のキーについて、 Extended Step オペレーションを使用してメモリバッファーにで

きるだけ多くのキー値を読み込みます。

b. メモリバッファーの値をソートし、ソートされた値をテンポラリファイルに書き出します。

c. 手順 a および b を繰り返し、各レコードのキー値を処理します。

これで、テンポラリファイルにはいくつかのキー値が設定されました。それぞれのキー値は個別にソー

トされています。

5 データのセットをインデックスページにマージし、各ページの容量いっぱいまで書き込みます。各インデッ

クスページはデータファイルの後に追加され、ファイル長は拡大されます。

6 残りの各キーについて、手順 4 および 5 を繰り返します。

この処理中にテンポラリファイルのオープンや書き込みに失敗などのエラーが発生した場合、 Rebuild はもう 1つの方法を用いてファイルのビルドを初からやり直します。

デフォルトの方法には存在するメモリが足りない場合やデフォルトの方法で処理中にエラーが発生した場合、

Rebuild はもう 1 つの方法（-m0）を使用します。

1 元のファイルに定義されているのと同じレコード構造とインデックスを持つ空のデータファイルを新規作

成します。

2 新しいファイルからすべてのインデックスを削除します。

3 新しいファイルにインデックスなしですべてのデータをコピーします。

4 以下の処理でインデックスを追加します。

a. 元のファイルの特定のキーについて、 Step Next オペレーションを使用して、 1 度に 1 レコードを読みま

す。

b. レコードからキー値を抽出し、インデックスの適切な場所に挿入します。この処理では、キーページ

がいっぱいになると必然的にページの分割が行われます。

c. 手順 a および b を繰り返し、各レコードのキー値を処理します。

5 残りの各キーについて、手順 4 を繰り返します。

もう 1 つの方法は、デフォルトの方法に比べて一般的にはるかに時間がかかります。多数のインデックスを持つ

サイズの大きなファイルがある場合、 2 つの方法の差は何時間から何日にまで及ぶことがあります。 Rebuild が必

ずデフォルトの方法を使用するようにする唯一の方法は、十分な使用可能メモリを確保することです。設定プロ

パティのいくつかは、利用可能なメモリ量に影響を与えます。

必要なメモリ量を見積もる式

以下の式は、速い方法でファイルインデックスをリビルドするのに必要な連続した空きメモリの適かつ小の

量を見積もります。適なメモリ量は、 RAM 上のすべてのマージブロックを格納するのに十分な量です。小

のメモリ量は、 RAM 上の 1 つのマージブロックを格納できる量です。

キー長 = ファイル上で大のキーのすべてのセグメントの合計サイズキーオーバーヘッド = 8 （キータイプがリンク重複でない場合）、12 （キータイプがリンク重複の場合）。レコード数 = ファイル内のレコード数

適なメモリバイト = ((( キー長 + キーオーバーヘッド ) * レコード数 ) + 65536) / 0.6

小メモリバイト = 適メモリバイト / 30

たとえば、ファイルに 8,000,000 レコードが含まれていて、も長いキーが 20 バイト（リンク重複キーではない）

である場合、理想的なメモリの量は 373.5 MB、つまり ((( 20 + 8 ) * 8,000,000 ) + 65536 ) / 0.6 = 373,442,560 バイト

となります。

適な連続空きメモリの量は 373.5 MB です。少なくともこれだけの空きメモリがあれば、 Rebuild 処理はすべて

RAM 上で行われます。 60 % という割り当て制限のため、メモリの適な量というのは、実際はリビルド処理開

281


始時に必要とされる空き領域の量で、リビルド処理が実際に使用する量ではありません。この適量に 0.6 をか

けると、 Rebuild が実際に使用する大量が決定されます。

メモリの低量は適量の 1/30、 12,448,086 バイト、または 12.45 MB です。

除数に 30 を使用するのはデータベースエンジンが一度に追跡するマージブロックは 30 以下であるためですが、

常に 1 つのマージブロックがメモリ上にある必要があります。除数に 0.6 を使用するのは、エンジンがリビルド

処理に 60% より多くの物理メモリを割り当てることはないためです。

使用可能メモリが小の量より少ない場合、 Rebuild はデータファイルのリビルドにもう 1 つの方法を使用しま

す。

後に、割り当てられたメモリブロックは 2 つの条件を満たす必要があります。必要なブロックと割り当てられ

たブロックサイズは次のようになります。

必要なブロック数は 30 以下です。

必要なブロック数 = Round Up ( 適なメモリバイト / 割り当てられたブロック )

割り当てられたブロックサイズは以下の値以上である必要があります。

((2 * 大キー数 + 1) * ( キー長 + キーオーバーヘッド )) * 必要なブロック数

ページサイズ 512 バイト、 12.45 MB のブロック割り当てに成功したと仮定すると、必要なブロック数は次のよ

うになります。

必要なブロック数 = 373,500,000 / 12,450,000 = 30

初の条件に合っています。

割り当てられたブロックサイズの値は次のようになります。

大キー数 = (512-12) / 28 = 18(((2 * 18) + 1) * (20 + 8)) * 9 = 9324

割り当てられたブロック（12,500,000 バイト）は 9324 バイトより大きいですか ? そうであれば 2 番目の条件に

合っています。インデックスキーはテンポラリファイルに 12.45 MB ずつの塊として書き込まれ、メモリに格納

され、次にインデックスに書き込まれます。

ソートバッファーサイズ

この設定は、ランタイムでインデックスを作成中に MicroKernel がソートのために動的に割り当てる、または割

り当てを解除するメモリの大容量を指定します。「ソートバッファーサイズ」を参照してください。

設定がゼロ（デフォルト）の場合、 Rebuild は適なメモリバイト値を計算し、その値に基づいてメモリを割り

当てます。メモリ割り当てに成功したら、割り当てられたブロックのサイズは少なくとも小メモリバイトで定

義された値になります。「必要なメモリ量を見積もる式」を参照してください。

設定がゼロ以外の値で、値が計算された小メモリバイトより小さい場合、 Rebuild はその値を使用してメモリ

を割り当てます。

後に、 Rebuild は割り当てるべきメモリ量と実際に利用可能な量の 60% とを比較します。そして、その 2 つの

うち小さい方を割り当てようとします。メモリ割り当てに失敗した場合、Rebuild は後に割り当てようとしたメ

モリ量の 80% の割り当てを試みることを続けます。メモリ割り当てに完全に失敗した場合（これは小メモリバイトよりメモリ量が少ないことを意味します）、 Rebuild はファイルのリビルドにもう 1 つの方法を使用します。


この設定は、総物理メモリに対して MicroKernel が消費できるメモリの割合を指定します。MicroKernel による L1、L2 およびその他すべてのメモリの使用量が含まれます（SRDE は含まれません）。「MicroKernel の大メモリ使

用量」を参照してください。

リビルドするサイズの大きなファイルがある場合、［MicroKernel の大メモリ使用量］のパーセンテージを一時

的にデフォルトより小さい値に設定します。リビルド処理が終わったら、再度適切なパーセンテージに設定し直

します。

282




すべてのデータファイルへのアクセスにこのキャッシュが使用されます。「キャッシュ割当サイズ」を参照して

ください。

この設定は、データベースエンジンがデータファイルにアクセスするのにどれだけのメモリが使用できるかを決

定します。インデックスを構築する際に使用するものではありません。

キャッシュ割り当てサイズを大きな値に増やしても、インデックスの構築は速くなりません。実際、重要なメモ

リを占めることにより Rebuild にとっては利用不可能となり、処理を遅くする可能性があります。大きなファイ

ルをリビルドする場合には、キャッシュ値を低い値に抑えます。たとえば、現在の値の 20% で、ただし 5 MB を下回らないようにします。こうすると、できるだけ多くのメモリをインデックスのリビルドに残すことができま

す。

インデックスページサイズ

ファイルのページサイズも、インデックス構築の速度に影響します。 Rebuild がもう 1 つの方法を使用した場合、

小さいキーページを使用するとインデックスの構築に必要な時間は劇的に増加します。 Rebuild がデフォルトの

方法を使用した場合には、キーページサイズはインデックスの構築にはあまり影響を与えません。

Rebuild は、ページサイズをアプリケーションのパフォーマンスまたはディスクストレージに対して適化しま

す。

（アプリケーションがそのデータにアクセスする）パフォーマンスについて適化するには、 Rebuild はデフォル

トのページサイズ 4096 バイトを使用します。この結果は、物理ストレージ上の大きなページサイズと遅いリビ

ルド時間になります。

ディスクストレージに対するページサイズの適化に関する解説は、開発者リファレンスの『Pervasive PSQLProgrammer's Guide』の「ページサイズの選択」を参照してください。

アプリケーションで、 8,000,000 レコード、 20 バイトのキーおよび 512 バイトのページサイズを使用すると仮定

します。 MicroKernel は各インデックスページに 8 個から 18 個の間のキー値を書き込みます。こうすると、各

ページで必要となる物理ストレージ量が減ります。ただし、 8,000,000 レコードにインデックスを付けると、およ

そ 7 階層の深さの B ツリーが作成され、ほとんどのキーページが 7 番目のレベルに属します。パフォーマンスは

低下します。

ページサイズ 4096 バイトを使用すると、データベースエンジンは各インデックスページに 72 から 145 個のキー

値を書き込みます。 B ツリーはおよそ 4 レベルの深さで済み、 Rebuild が新しいキー値を挿入するときに調べる

ページ数が少なくなります。パフォーマンスは向上しますが、物理ストレージをより必要とします。

インデックス数

インデックス数もインデックス構築の速度に影響します。一般的に、インデックス数が多いほどビルド処理には

時間がかかります。インデックスの構築に必要な時間は、B ツリーの深さの増加により幾何級数的に増加します。

ログファイル

リビルド処理からの情報はテキストログファイルに追加されます。ログファイルはデフォルトで現在の作業

ディレクトリに保存されます。

CLI Rebuild では、デフォルトのファイル名は Windows および Linux で rbldcli.log です。デフォルトを使用せず、

ログファイルのロケーションと名前を指定することもできます。「-lfile」パラメーターを参照してください。

テキストエディターを使用してログファイルが確認できます。ログファイルに記録される情報は、以下のとお

りです。

リビルド処理の開始時刻

コマンドラインで指定されたパラメーター

ステータスコードおよびエラー説明（エラーが発生した場合）

処理中のファイル

283


処理に関する情報（ページサイズの変更など）

処理済みレコード総数

再構築されたインデックス総数（-m2 処理方法が使用された場合）

リビルド処理の終了時刻

処理のステータス（たとえば、ファイルのリビルドが成功したかどうかなど）

284

Rebuild ユーティリティの GUI のリファレンス


このセクションでは、 Rebuild ユーティリティのグラフィカルユーザーインターフェイス（GUI）のオブジェク

トについて説明します。

ファイルオプションの画面

この画面を使用すると、リビルドのリストにファイルを追加することができます。

図 40 Rebuild ユーティリティのファイル選択

Rebuild オプションの画面

この画面を使用すると、ファイルのリビルドに関するオプションを選択することができます。

図 41 Rebuild ユーティリティのファイルオプション


選択ファイルリビルドするためにリストされたデータファイルおよ

び辞書ファイル。［追加］ボタンを使用して選択したも

のです。

「ファイルをリビルドす

るには」

［追加］ボタンリビルドするファイルのリストにデータファイルまた

は辞書ファイルを追加します。「ファイルをリビルドす

るには」

［削除］ボタン選択したデータファイルまたは辞書ファイルをリスト

から削除します。「ファイルをリビルドす

るには」

［クリア］ボタン選択されたデータファイルおよび辞書ファイルのリス

ト全体をクリアします。「ファイルをリビルドす

るには」

285



システムデータ Rebuild 時にファイルにシステムデータキーを作成するかど

うかを指定します。

システムデータはトランザクション一貫性保守とトランザク

ションログでは必須です。

システムデータおよびキーデータを使用してファイルをリ

ビルドするかどうかを指定します。 MicroKernel は、ユーザー

定義のユニークなキーが存在しないとき、システムデータを

含まないファイルのロギングを行うことができません。

「ファイルをリビルドするには」

ページ圧縮ファイルにページ圧縮を使用するかどうかを指定します。選

択肢は、 " オン "、 " オフ "、および " 既存を保持 " です。 " 既存を保持 " を選択すると、ファイルにページ圧縮が設定され

ている場合は、それを維持します。

ページ圧縮には 9.5 以上のファイル

形式であることが必要です。


レコード圧縮ファイルにレコード圧縮を使用するかどうかを指定します。

選択肢は、 " オン "、 " オフ "、および " 既存を保持 " です。 "既存を保持 " を選択すると、ファイルにレコード圧縮が設定

されている場合は、それを維持します。


エラー時続行リビルド処理中にエラーが発生した場合に、 Rebuild ユーティ

リティの処理を続行するかどうかを決定します。このオプ

ションを選択すると、エラーが発生した場合でも、ユーティ

リティは次のファイルの処理を続行します。ユーティリティ

により、MicroKernel データファイル以外のファイルであるこ

とやその他のエラーが発生したことが通知されますが、デー

タファイルのリビルドは続行されます。このオプションを選

択しない場合、エラーが検出された場合、リビルド処理が停

止します。

このオプションは、リビルドファイルにワイルドカード文字

を指定した場合に効果的です。


終了時に設定を保存このダイアログボックスの現在の設定を保存して、次回のリ

ビルドのセッションでもこの設定を使用できるようにしま

す。


キー番号ファイルのリビルド処理を行う際にユーティリティが読み込

むキーを指定します。このオプションで［NONE］を選択した

場合、ファイルの複製、インデックスの削除、新しいファイ

ルへのレコードのコピーが行われた後、インデックスがリビ

ルドされます。この方法は、キー番号を指定するよりも短時

間でリビルドでき、ファイルのサイズも小さくなるため、で

きる限りこの方法を使用するようにしてください。

この方法では、元のファイルとは異なる物理順序のレコード

を含む新規ファイルが作成されることがあります。

キー番号を指定した場合には、インデックスの削除と置き換

えは行われず、ファイルの複製とコピーが行われます。この

方法は、［NONE］を指定するよりもリビルドに時間がかかり

ますが、インデックスをリビルドしたくない場合には、この

方法を使用します。


『Pervasive PSQL Programmer's Guide』の「キー属性」

ファイルフォーマットこれまでは、 Rebuild ユーティリティは［作成ファイルのバー

ジョン］設定パラメーターに基づいてファイルバージョンを

決定していました。

この Rebuild ユーティリティを使用すると、その設定とは無関

係にファイルバージョンを指定することができます。


286


ページサイズ新しいファイルのページサイズをバイト単位で指定します。

"EXISTING"、 " 適化（ディスクスペース） "、 " 適化（デー

タアクセス） " のいずれかを選択するか、サイズをバイト単

位で指定します。"EXISTING" を選択した場合は現在のページ

サイズが使用されます。何らかの理由で元のサイズが使用で

きない場合は、ユーティリティにより、ほかのページサイズ

に変更されます。

たとえば、ページサイズが 1024 で、 24 個のキーを持つ v5.xファイルがあるとします。Btrieve v6.0 以降のバージョンでは、

ページサイズが 1024 の場合、 23 個までのキーのみをサポー

トするため、ファイルには、ユーティリティによって新しい

ページサイズが自動的に割り当てられ、ログファイルに通知

メッセージが記述されます。


データアクセスの適化につ

いては、「Rebuild 処理の適化」


ディスクスペースの適化に

ついては、『Pervasive PSQLProgrammer's Guide』の「ページ

サイズの選択」を参照してくだ

さい。

出力パスリビルドされたファイルの保存先となる別のロケーションを

指定します（デフォルトのロケーションは現在のディレクト

リです）。必ず既存のディレクトリを指定してください。

このオプションを使用すれば、サイズの大きいファイルを別

のサーバーでリビルドすることができます。 MicroKernel とそ

の通信コンポーネントが、リビルドされたファイルを格納す

るサーバーでロードされている必要があります。パスには、ワ

イルドカード文字を使用しないでください。

出力ディレクトリのロケーションが元のファイルのロケー

ションと異なる場合、元のファイルはリビルド中に削除され

ません。出力ディレクトリが元のファイルと同じディレクト

リである場合には、リビルドの完了時に元のファイルは削除

されます。

DefaultDB w/ DB security: ［名前付きデータベースの管理］で

指定したデータベースのファイルロケーション以外ではリビ

ルドできません。


ログファイルリビルドログファイルのロケーションを指定します（デフォ

ルトのロケーションは現在の作業ディレクトリです）。パスに

は、ワイルドカード文字を使用しないでください。




287


Rebuild 進行状況画面

この画面を使用すると、リビルドの進行状況を知ることができます。また、リビルド処理完了後にログファイル

を表示することができます。

図 42 Rebuild ユーティリティの進行状況


メッセージ領域リビルド中のファイルについての情報が表示されます。リビルドが完了

した場合には操作の要約が表示されます。


ログファイルの表示各ファイルのリビルド処理に関する情報を表示することができます。

［ログファイルの表示］をクリックすると、デフォルトのテキスト

ビューアーを使用してリビルドログを表示します。


288

Rebuild ユーティリティの作業


以下の Rebuild の作業が行えます。

GUI Rebuild ：「GUI 操作」

コマンドライン Rebuild ：「CLI 操作」

GUI 操作

「GUI Rebuild ユーティリティを開始するには」

「Rebuild ユーティリティのヘルプを入手するには」


GUI Rebuild ユーティリティを開始するには

Pervasive PSQL Control Center のメニューから［ツール｜ Rebuild］を選択するか、オペレーティングシステムの

［スタート］メニューまたはアプリ画面から Rebuild にアクセスします。

Rebuild ユーティリティのヘルプを入手するには

どの GUI （グラフィカルユーザーインターフェイス）でも、［ヘルプ］をクリックするとヘルプファイルにアク

セスできます。

ファイルをリビルドするには

1 Rebuild の開始画面で［次へ］をクリックすると、ファイルの選択画面が表示されます。

2 ［追加］をクリックしてリビルドするデータファイルまたは辞書ファイルを選択します。複数のファイルを

一度に選択することもできます。

図 43 ファイルの選択用ダイアログボックス

元のファイルと同じディレクトリでファイルをリビルドする場合、元のファイルはリビルド完了後に削除さ

れます。新しいファイルを別のディレクトに置く場合は、元のファイルは削除されません。

3 目的のファイルを追加したら、［次へ］をクリックします。

4 リビルドオプションを指定します。「Rebuild オプションの画面」を参照してください。

5 ［次へ］をクリックしてリビルド処理を開始します。

このユーティリティは処理に関する情報をレポートします。リビルド処理が完了すると、成功か失敗かが表

示され［ログファイルを表示する］ボタンが有効になります。

289


図 44 リビルド処理

6 結果を表示するには、［ログファイルを表示する］をクリックします。ログファイルの内容は、オペレー

ティングシステムのデフォルトのテキストエディターで表示されます。

Rebuild ユーティリティでは、変換を試みたすべてのファイルについてログファイルに書き込みます。［エ

ラー時続行］の設定を無効にした場合、ログファイルには、エラーが発生した時点までの情報が記録されま

す。リビルドが失敗した場合、ログファイルにはそのエラーの原因を説明するメッセージが記録されます。

7 ファイルのリビルドが完了してログファイルを見終わったら、［完了］をクリックします。

CLI 操作

Rebuild コマンドラインユーティリティの名前は、 Windows の場合は rbldcli.exe、 Linux の場合は rbldcli です。以

下のコマンドライン Rebuild ユーティリティ作業が行えます。

「Rebuild を Linux で実行するには」

「Rebuild を Windows で実行するには」

「リビルド中のファイルの進行状況を見るには」

CLI Rebuild ユーティリティのコマンドラインパラメーターについては、次のセクションを参照してくださ

い。

コマンドラインパラメーター

parameter オプションには、このユーティリティで使用するパラメーターを指定します。パラメーターはどのよう

な順序でも使用できます。各パラメーターの前にはハイフン（-）を付けます。ハイフンの後、または、 1 文字の

パラメーターおよびパラメーター値の後にスペースを入れないでください。

メモ Linux プラットフォームに限り、パラメーターで大文字小文字が区別されます。

290


parameter は以下のように定義されています。

-c エラーが発生しても、次のデータファイルまたは辞書ファイルのリビルドを続行するように、

Rebuild に指示します。ユーティリティにより、 MicroKernel データファイル以外のファイルである

ことや MicroKernel ファイルでエラーが発生したことが通知されますが、データファイルのリビル

ドは続行されます。エラーはログファイルに書き出されます。「ログファイル」を参照してください。

ヒント：このパラメーターは、混合するファイルのセットに対してワイルドカード文字（*.*）を指

定した場合に特に便利です。混合ファイルのセットとは、MicroKernel ファイルと非 MicroKernel ファ

イルの組み合わせです。Rebuild は非 MicroKernel ファイルを処理するたび（または MicroKernel ファ

イルのエラー時）にエラーを報告しますが、処理を続行します。

-d -d を指定すると、バージョン 6.0 より前の補助インデックス（重複が可能）を 6.x、 7.x または 8.x のリンク重複キーのあるインデックスに変換します。

このパラメーターを指定しないと、 Rebuild はインデックスを繰り返し重複キーとして保持します。

トランザクショナルインターフェイスを介してのみデータファイルにアクセスし、かつファイルに

比較的多数の重複キーがある場合には、 -d パラメーターを使用して Get Next オペレーションや GetPrevious オペレーションのパフォーマンスを向上させることができます。

-m<0 | 2> 'm' パラメーターは method （方法）を表します。 Rebuild はこのパラメーターが指定されているかど

うかによって処理方法を選択します。このパラメーターを指定しない場合、 Rebuild は以下のように

処理します。

十分な使用可能メモリがある場合には、 -m2 をデフォルトの処理方法とします。

使用可能メモリが十分でない場合はもう 1 つの方法の -m0 を使用します。

選択した方法によって影響を受けるメモリの量については、「メモリ量」を参照してください。

0 インデックスの削除や置き換えを行うことなくデータファイルまたは辞書ファイルの複製を作成

してコピーします。この方法は -m2 の方法に比べて時間がかかります。インデックスをリビルドし

ない場合には、この方法が使用できます。

-m0 を使用すると、各キーページの使用率が 55% から 65% のファイルが作成されます。このファ

イルは書き込み用により適化されていて、読み取りには適化されていません。状況によります

が、リビルドにかける時間の余裕がある場合は、書き込み用に適化されるリビルドを行うのが望

ましいでしょう。

「Rebuild 処理の適化」も参照してください。

2 データファイルまたは辞書ファイルの複製を作成し、インデックスを削除して新しいファイルにレ

コードをコピーした後、インデックスをリビルドします。この方法は、 -m0 の方法よりも短時間で

リビルドでき、ファイルのサイズも小さくなります。

-m2 の方法では、元のファイルとは異なる物理順序のレコードを含む新規ファイルが作成されるこ

とがあります。

-m2 の方法を使用して作成されるファイルのキーページは 100% 使用済みです。こうすると、ファ

イルを読み取りに適化することができます。

291


-p<D | P | bytes> ページサイズをディスクストレージまたは処理に適化します。またはリビルドするファイル

に特定のページサイズを指定します。

このパラメーターを指定しないと、 Rebuild は元のファイルのページサイズを使用します。元の

ファイルのページサイズでは現在のデータベースエンジンで動作しない場合、Rebuild はページ

サイズを変更し、変更したことを示す情報メッセージを表示します。たとえば、 5.x などの古い

ファイル形式ではページサイズが 1024 でキーを 24 個持つファイルをサポートしていました。

8.x のファイル形式では、ページサイズ 1024 で 23 個のキーしかサポートしません。したがっ

て、 Rebuild は 8.x ファイルを作成する場合、異なるページサイズを選択します。

データベースエンジンでは、指定されたページサイズを無視してそのサイズを自動的に更新す

ることがあります。たとえば、バージョン 9.5 のファイル形式の場合、 1536 や 3072 などの奇数

ページサイズはサポートされません。データベースエンジンでは効率を良くするために、ペー

ジサイズを次の有効なページサイズへ自動的に更新します。旧バージョンのファイル形式の場

合、データベースエンジンは別の条件に基づいてページサイズを更新することができます。

「インデックスページサイズ」も参照してください。

D ページサイズをディスクストレージに適化します。

開発者リファレンス『Pervasive PSQL Programmer's Guide』の「ページサイズの選択」を参照してく

ださい。

P 処理に対して適化します（つまり、そのデータにアクセスするアプリケーションのための適化

です）。 -pP では、 Rebuild はデフォルトのページサイズ 4096 バイトを使用します。

「Rebuild 処理の適化」を参照

bytes 新しいファイルのページサイズをバイト単位で指定します。 9.0 より前のファイルバージョンの場

合、有効な値は 512、 1024、 1536、 2048、 2560、 3072、 3584 および 4096 です。 9.0 のファイルバー

ジョンの場合、上記と同じ値に 8192 が加えられます。 9.5 以上のファイルバージョンの場合、有効

な値は 1024、 2048、 4096、 8192 および 16384 です。

-bdirectoryname リビルドしたファイルに別のロケーションを指定します。別のサーバー上のロケーションも指定で

きます。デフォルトのロケーションは、データファイルのあったディレクトリです。必ず存在する

ロケーションを指定してください。 Rebuild はディレクトリを作成しません。また、そのディレクト

リは Pervasive PSQL データベースエンジンが起動しているマシン上のディレクトリでなければなり

ません。

完全に修飾したパスまたは相対パスのいずれも使用できます。 directoryname にはワイルドカード文

字を使用しないでください。

ローカルサーバーの場合は、 MicroKernel Database エンジンとメッセージルーターがロードされて

いる必要があります。リモートサーバーの場合は、MicroKernel Database エンジンと通信コンポーネ

ントがロードされている必要があります。

このパラメーターを指定しないと、リビルドされたファイルによって元のデータファイルが置き換

えられます。元のファイルのコピーは保持されません。

このパラメーターを指定すると、リビルドされたファイルは指定のロケーションに置かれ、元のファ

イルが保持されます。これに関する例外があります。指定したロケーションに同じ名前のデータ

ファイルが既に存在する場合です。元のファイルと同じ名前のファイルが指定されたロケーション

に含まれていた場合、 Rebuild ではエラーが起こります。たとえば、 folder1 というディレクトリ

にある mydata.mkd をリビルドしようとするとします。リビルドされたファイルを foder2 という

ディレクトリに保存したいとします。folder2 にも mydata.mkd が存在していた場合（おそらく気

付かないうちに）、 Rebuild ではエラーになり、ログファイルを調べるよう通知があります。

メモ：指定したロケーション（このパラメーターを指定しなかった場合は元のファイルのロケーショ

ン）に対して、ファイルを作成するアクセス権があることを確認してください。

-knumber キー番号を指定します。Rebuild はこれを使って元のファイルを読み、リビルドしたファイルを並べ

替えます。このパラメーターを指定しないと、 Rebuild はもとのファイルを物理順に読み、リビルド

したファイルも物理順で作成します。

「Rebuild 処理の適化」も参照してください。

292


-s[D | K] リビルドしたファイルに、元のファイルの既存のシステムデータとキーを保持します。このパラ

メーターを指定しないと、 Rebuild はシステムデータとキーをリビルドしたファイルに含めません。

「システムデータ」も参照してください。

D リビルドしたファイルにシステムデータを含めます。システムデータにはインデックスが作成され

ません。「システムデータ」も参照してください。

K リビルドしたファイルにシステムデータとキーを含めます。システムデータにはインデックスが作

成されます。「システムデータ」も参照してください。

-lfile Rebuild のログファイルにファイル名を指定します。オプションでパスロケーションを指定するこ

とができます。デフォルトのファイル名は、Windows および Linux では rbldcli.log です。Windows および Linux では、デフォルトのロケーションは現在の作業ディレクトリです。

以下の条件が適用されます。

パスロケーションは既に存在している必要があります。Rebuild はパスロケーションを作成しま

せん。

ファイル名を指定しないでパスロケーションを指定した場合、 Rebuild はこのパラメーターを無

視してデフォルトのファイル名とロケーションを使用します。

パスロケーションを指定しないでファイル名を指定した場合、 Rebuild はデフォルトのロケー

ションを使用します。

指定したロケーションに対する読み取りおよび書き込みのアクセス権を持っている必要があり

ます。ファイルのアクセス権のためにログファイルを作成できなかった場合、 Rebuild はデフォ

ルトのロケーションを使用します。

「ログファイル」も参照してください。

-pagecompresson 「file」のページ圧縮をオンにすると、以下の条件が設定されます。

Pervasive PSQL データベースエンジンのバージョンは Pervasive PSQL 9.5 以上

作成ファイルのバージョン設定は 0950 （9.5）以上。

-pagecompressoff 「file」のページ圧縮をオフにします。このパラメーターは、「file」にページ圧縮が指定されていない

場合は無効です。

-recordcompresson 「file」のページ圧縮をオンにします。

-recordcompressoff 「file」のレコード圧縮をオフにします。このパラメーターは、「file」にレコード圧縮が指定されてい

ない場合は無効です。

293


File および @command_file は次のように定義されます。

-f<6 | 7 | 8 | 9 | 95> リビルド後のデータファイルまたは辞書ファイルのファイル形式を指定します。ファイル形式は、

バージョン 6.x、 7.x、 8.x および 9.x が使用できます。次の例ではファイルを 9.0 形式にリビルドし

ます。

rbldcli -f9 file_path\class.mkd

次の例ではファイルを 9.5 形式にリビルドします。

rbldcli -f95 file_path\class.mkd

このパラメーターを指定しないと、 Rebuild は MicroKernel の［作成ファイルのバージョン］設定オ

プションに指定されている値を使用します。「作成ファイルのバージョン」を参照してください。

メモ 1 ：現在のデータベースエンジンでサポートされているバージョンより新しいファイル形式を

指定した場合、 Rebuild はそのエンジンでサポートされている新のファイル形式を使用します。

Rebuild はこれに関してはエラーもメッセージも報告しません。

メモ 2 ：Rebuild はインデックスのデータ型を変換しません。ファイルを古いデータベースエンジン

で使用するために古いファイル形式にリビルドする場合、エンジンが使用されているデータ型をサ

ポートしているかどうかを確認してください。必要に応じ、アプリケーションとそのデータベース

エンジンによって、手作業でデータ型を調整する必要があります。

例 1. データファイルに WZSTRING データ型を使用するインデックスフィールドが含まれていま

す。データファイルを 6.x 形式にリビルドする場合、 WZSTRING データ型は変換されません。この

データファイルを Btrieve 6.15 エンジンで使用することはできません。このエンジンは WZSTRINGデータ型をサポートしません。

例 2. データファイルに NULL が含まれています。データファイルをを 7.x ファイル形式にリビル

ドします。真の NULL は変換されません。このデータファイルを Pervasive PSQL 7 エンジンで使用

することはできません。このエンジンは真の NULL をサポートしません。

-uiduname セキュリティが設定されているデータベースにアクセスする権限を与えられたユーザー名を指定し

ます。

-pwdpword uname で識別されるユーザーのパスワードを指定します。 uname が指定された場合、 pword は必ず

指定する必要があります。

-dbdbname セキュリティが設定されたデータベース名を指定します。

file 変換するデータファイルおよび辞書ファイルを指定します。元のファイルが現在の作業ディレク

トリにない場合は、完全修飾パスまたは相対パスのいずれかを使用してロケーションを含めてくだ

さい。ファイル名にはアスタリスク（*）ワイルドカード文字を使用して、複数のファイルを指定

することができます。

メモ：元のファイルにオーナーネームが含まれている場合、 Rebuild はリビルドしたファイルに

オーナーネームとレベルを適用します。

@command_file Rebuild で実行されるコマンドファイルを指定します。 1 つのコマンドファイルに複数の項目を指

定できます。コマンドファイルの各項目には、コマンドラインパラメーター（ある場合）と変換

するファイルのセットを指定し、その後に <end> または［end］を続けます。

変換するファイルを指定する場合には、完全なディレクトリ名を使用します。ファイル名にはアス

タリスク（*）ワイルドカード文字を使用できます。

次に、 Rebuild コマンドファイルの例を示します。

-c d:\mydir\*.* <end>-c -p1024 e:\dir\*.* <end>-m0 -k0 d:\ssql\*.* <end>

294


Rebuild を Linux で実行するには

1 ログインするアカウントが Pervasive PSQL ユーティリティを実行する権限を持っていることを確認してくだ

さい。

デフォルトでは、ユーティリティを実行するには psql ユーザーとしてログインする必要があります。 psql

ユーザーにはパスワードがありません。su コマンドを使用することによって root アカウントでのアクセス

のみを行うことができます。 psql 以外のアカウントからこのユーティリティを使用するには、まず

.bash_profile を変更する必要があります。『Getting Started with Pervasive PSQL』の「Linux での PervasivePSQL のアカウント管理」を参照してください。

2 /usr/local/psql/bin ディレクトリに移動します。

3 プロンプトに、次のどちらかのコマンドを入力します。

rbldcli [-parameter ...] file

または

rbldcli @command_file

parameter、 file および @command_file は、「コマンドラインパラメーター」に定義されています。

使い方の例

以下の例はエラー時も処理を続けます。ページサイズは 4096 バイトに設定され、リビルドされたファイルはサー

バー上の別のディレクトリに保存します。

rbldcli -c -p4096 -b/usr/local/psql/tmp /usr/local/psql/data/DEMODATA/*.mkd

Rebuild を Windows で実行するには

1 Pervasive PSQL がインストールされているマシンで、コマンドプロンプトを開きます。

2 状況により、 \bin ディレクトリをプログラムファイルをインストールしたディレクトリに変更します。そ

の場所が Path システム変数に含まれている場合は、この操作は不要です。

3 プロンプトに、次のどちらかのコマンドを入力します。

rbldcli [-parameter ...] file

または

rbldcli @command_file

parameter、 file および @command_file は、「コマンドラインパラメーター」に定義されています。

使い方の例

以下の例はエラー時も処理を続けます。ページサイズは 4096 バイトに設定され、リビルドされたファイルはサー

バー上の別のディレクトリに保存します。

rbldcli -c -p4096 -bc:\dbtemp c:\datafiles\*.mkd

リビルド中のファイルの進行状況を見るには

Rebuild は、ファイルごとに処理されたレコード数を画面上に表示します。1 度に 50 レコードずつ増加します。さ

らに、 Rebuild はこれらの情報をテキストログファイルに書き込みます。「ログファイル」を参照してください。

295


296

A
ディスクリプションファイルを使用して Btrieve ファイル情報を保存する

ディスクリプションファイルは、 Maintenance ユーティリティがデータファイルやインデックスの作成に使用す

るファイルスペックとキースペックの記述を含む ASCII テキストファイルです。作成したファイルの情報を保

存するための媒体としてディスクリプションファイルを使用することもできます。ディスクリプションファイル

は、 Scalable SQL 4.0 や ODBC インターフェイスで使用されるデータ辞書ファイル（DDF）とは異なります。

ディスクリプションファイルには 1 つ以上の要素が含まれます。 1 つの要素は、キーワード、等号（=）、それに

値がスペースなしで続く形式で構成されます。ディスクリプションファイルの各要素は、データファイルまたは

キースペックの特性に対応しています。

メモディスクリプションファイルを使用する前に、 Btrieve の基本について熟知しておく必要があります。

これらの項目の詳細については、『Pervasive PSQL Programmer's Guide 』を参照してください。

この付録では以下の項目について説明します。

「ディスクリプションファイルの規則」

「ディスクリプションファイルの例」

「ディスクリプションファイルの要素」

297


ディスクリプションファイルの規則

ディスクリプションファイルを作成する際は、以下の規則に従います。

要素は、大文字または小文字のいずれかで入力する。

要素を区切る場合は、以下の例のように、区切り文字（スペース、タブ、またはキャリッジリターン / ライ

ンフィード）を使用する。

record=4000

key=24

ディスクリプションファイルの要素を適切な順序で指定する。表 66 に要素の適切な順序が示されています。

要素の依存関係は、すべて指定する。たとえば、ディスクリプションファイルで nullkey=allsegs を指

定した場合は、 value= という要素の値も指定します。

キーには、キー数要素で指定した数と同じ数のキーを定義する。たとえば、key=12 を指定した場合は、ディ

スクリプションファイルでも 12 個のキーを定義します。

キーに複数のセグメントがある場合は、各キーセグメントに以下の要素を定義する。

キーポジション

キー長

重複キー値変更可能キー値キータイプ

各セグメントの降順ソート要素は、省略可能です。

ファイル中のキーで ACS を使用している場合は、ACS ファイル名、カントリ ID とコードページ ID、または

ISR テーブル名を指定する。この情報は、キーの後の要素（現在のキーのみに適用）またはディスクリプ

ションファイルの後の要素（データファイル全体に適用）として含めることができます。

1 つのキーに対して指定できる ACS は 1 つのみで、 ACS ファイル名、カントリ ID とコードページ ID、

または ISR テーブル名も指定します。同一ファイル中の異なるキーには、異なる形式の ACS が使用でき

ます。たとえば、キー 0 に ACS ファイル名、キー 1 にカントリ ID およびコードページ ID を使用でき

ます。

同一キーの異なるセグメントに、異なる ACS を使用することはできません。

ディスクリプションファイルの後に ACS を指定した場合は、その ACS がデフォルトとして使用され

ます。たとえば、 alternate=y を指定し、 ACS ファイル名、カントリ ID とコードページ ID、または

ISR テーブル名を指定しない場合、データベースエンジンでは、ファイルの後に指定されている ACSファイル名、カントリ ID とコードページ ID、または ISR テーブル名を使用します。

新しいキーを作成する際に alternate=y を指定し、 ACS ファイル名、カントリ ID とコードページ

ID、または ISR テーブル名を指定しない場合、データベースエンジンでキーは作成されません。

ディスクリプションファイルの要素がオプションの場合は、それを省略することができる。

ディスクリプションファイルには、書式設定文字列を使用しない。一部のワードプロセッサでは、テキスト

ファイルに書式設定文字列が埋め込まれます。

298

ディスクリプションファイルの例

ディスクリプションファイルの例

このセクションにあるディスクリプションファイルのサンプルは、データファイルの説明です。このデータファ

イルのページサイズは 512 バイトで、キーは 2 つです。レコードの固定長部分は 98 バイトです。ファイルで可

変長レコードは使用可能ですが、ブランクトランケーションは使用できません。

ファイルはレコード圧縮を使用します。また、可変長部割り当てテーブル（VAT）を許可し、空きスペーススレッショルドは 20 % に設定されています。 MicroKernel Database エンジンは、ファイルを作成する際に 100 ペー

ジ、つまり 51,200 バイトをプリアロケートします。ファイルには、キー 0 およびキー 1 の 2 つがあり、キー 0 には 2 つのセグメントがあります。

図 45 では、同一の ACS ファイル名（upper.alt）が両方のキーで使用されています。図 46 では、同一のカントリ

ID （-1）およびコードページ ID （-1）が両方のキーで使用されています。図 47 では、キー 0 （lower.alt）および

キー 1 （upper.alt）で、異なる ACS ファイル名を使用しています。図 48 のファイルには、ログに使用されるシス

テム定義キーのみが含まれています。

図 45 キーセグメントに ACS のファイル名を使ったディスクリプションファイルのサンプル

図 46 ACS ID を使ったディスクリプションファイルのサンプル





name=c:\myacsfiles\upper.alt

ファイル仕様



キー 1





countryid=-1 codepageid=-1

ファイル仕様



キー 1

299


図 47 キーセグメントに ACS のファイル名を使ったディスクリプションファイルのサンプル

図 48 システム定義キーをログに使用するディスクリプションファイルのサンプル




position=16 length=2 duplicates=nmodifiable=y type=numeric descending=ynullkey=n segment=nname=c:\myacsfiles\upper.alt

ファイル仕様



キー 1

name=sys:\pvsw\demodata\lower.alt

name=c:\myacsfiles\lower.alt

record=98 variable=y truncate=n compress=ykey=2 page=512 allocation=100 replace=nfthreshold=20 vats=y sysdataonrecord=loggable

300

ディスクリプションファイルの要素


ディスクリプションファイルの要素は特定の順序で並べる必要があります。表 66 は、ディスクリプションファ

イルの要素を適切な順序で示しています。この表では、各要素に必要な書式および指定可能な値の範囲を示しま

す。

アスタリスク（*）は、その要素が省略可能であることを意味します。

シャープ記号（#）は、その要素が以前のバージョンの MicroKernel にのみ適用されることを意味します。

パーセント記号（%）は、その要素が現バージョンの MicroKernel にのみ適用されることを意味します。

表 66 ディスクリプションファイルの概要

要素キーワードとフォーマット範囲解説

ファイルスペック情報

コメントブロック * /*. . . . . . . . . . . . */ 5,120 バイトなし。

レコード長 record=nnnn 4 － 8,184 なし。

可変長レコード variable=<y|n> 適用外キーオンリーファイルには適用で

きません。

予約重複ポインター * dupkey=<nnn> 0 － 119 リンク重複キーを追加するファイ

ルにのみ適用できます。

ブランクトランケーション * truncate=<y|n> 適用外レコード圧縮が使用されるファイ

ルには適用できません。

レコード圧縮 * compress=<y | n> 適用外キーオンリーファイルには適用で

きません。「レコードおよびページ

圧縮」も参照してください。

キー数 key=nnn 0 － 119 データオンリーファイルを作成す

る場合は、 0 を指定します。

キーカウントがゼロの場合、［デー

タのインクルード］および［システ

ムデータの使用］は "no" に設定す

ることはできません。

ページサイズ page=nnnn 512 － 9.0 より前のファイル

バージョの場合は 4096 バイ

ト（512 バイトの倍数で大

4096 バイト）

512、1024、1536、2048、2560、3072、3584、4096 または 8192バイト（ファイルバージョ

ンが 9.0 の場合）

1024、 2048、 4096、 8192 また

は 16384 バイト（ファイル

バージョンが 9.5 以上の場

合）

ページプリアロケーション * allocation=nnnnn 1 － 65,535 なし。

既存ファイルの置き換え *# replace=<y|n> 適用外なし。

301


データのインクルード * data=<y|n> 適用外キーオンリーファイルを作成する

場合は、 n を指定します。重複を許

可し、システム定義のキーを使用す

るキーオンリーファイルを作成す

ることはできません。

空きスペーススレッショ

ルド *fthreshold=<5|10|20|30> 適用外可変長レコードのあるファイルの

みに適用できます。デフォルト値は

5 です。

可変長部割り当てテーブ

ル（VAT）huge=<y|n> #vats=<y|n>

適用外可変長レコードのあるファイルの

みに適用できます。

インデックスバランス * balance=<y|n> 適用外なし。

キー番号の使用 * usekeynum=<y|n> 適用外キー番号の要素と併用されます。

1 システムデータの使用 *% sysdataonrecord=<n|loggable>

適用外要素が指定されない場合は、

MicroKernel の設定が使用されます。

キーオンリーのファイルを作成す

る場合は、MicroKernel の設定が使用

され、この要素は無視されます。

ページ圧縮 * pagecompress=<y | n> 適用外「レコードおよびページ圧縮」も参


キースペック情報

キー番号 * keynum=nnn 0 － 118 ファイル内で重複せず、昇順に指定

され、ファイルのページサイズに有

効であることが必要です。ファイル

を作成する場合のみに適用されま

す。

キーポジション position=nnnn 1 － 8,184 レコード長を超えてはいけません。

キー長 length=nnn キータイプの制限キータイプが指示する制限を超え

てはいけません。バイナリキーの

キー長は、偶数であることが必要で

す。キーポジションとキー長の合計

が、ファイルのレコード長を超えて

はいけません。

重複キー値 duplicates=<y|n> 適用外重複を許可し、システム定義のキー

を使用するキーオンリーファイル

を作成することはできません。

変更可能キー値 modifiable=<y|n> 適用外なし。

キータイプ type=validMKDEKeyType

適用外名前全体（例、「float」）または初

の三文字（例、「flo」）を入力します。

降順ソート * descending=<y|n> 適用外なし。



302


オルタネートコレーティ

ングシーケンス（ACS）alternate=<y|n> 適用外大文字小文字を区別する STRING や

LSTRING、WSTRING、WZSTRING、

ZSTRING キーのみに適用できます。

既存ファイルにインデックスを追

加作成する際に、そのインデックス

でデータファイルの初にある

ACS 以外の ACS を使用する場合は、

caseinsensitive=y と共に使

用します。

大文字小文字無視のキー * caseinsensitive=<y|n> 適用外 ACS が使用されない STRING、

LSTRING、または ZSTRING キーの

みに適用できます。

繰り返し重複 * repeatdup=<y|n> 適用外キーオンリーのファイルを作成す

る場合は、繰り返し重複を使用しま

す。この要素を使用する場合は、

duplicates=y を使用します。

ヌルセグメント * nullkey=<allsegs | n |anyseg |>

適用外なし。

ヌルキーの値 value=nn 16 進の 1 バイトヌルセグメント要素に使用されま

す。

セグメントキー segment=<y|n> 適用外なし。

オルタネートコレーティ

ングシーケンスのファイ

ル名と ID

name=sequenceFile また

は countryid=nnn およびcodepageid=nnnisr=table name (%)

有効なパス、つまり、使用中

のオペレーティングシステ

ムで有効な値、または -1

オルタネートコレーティングシー

ケンス要素と共に使用されます。

1 データベースエンジンがシステムキーを追加する場合、結果レコードがファイルの既存ページサイズを超えることがあり

ます。その場合、データベースエンジンは、ファイルのページサイズを自動的に次の適切な大きさに調整します。



303


304

advanced operations guideadvanced operations guide procedures and references for advanced users...

Documents