Btrieve
TM
6.15 から
Pervasive.SQL
TM
7
または
Pervasive.SQL
TM
2000
へのアップグレード
White Paper
Rev.1､ 11/1999Pervasive Software Inc.
The Freedom to Create Applications for Everyone, Everywhere
はじめに...3 インストール...3 ワークステーション...3 ワークグループ...4 サーバ ...5 リクエスタとサーバのどちらが先か...5 サーバ エンジンおよびユーザ カウントキー...5 Windows NT ...6 Novell NetWare...6 リクエスタ...6 スマート コンポーネントのコンフィグレーション...6 ネットワーク インストールを使う...7 インストールのトラブルシューティング...8
Pervasive.SQL 2000 Workstation / Workgroup ...8
Pervasive.SQL 2000 Server ...8 アップグレードの完了...10 トラブルシューティング...11 まとめ...11 ファイルの再構築 (オプション) ...12 再構築プロセスの最適化...13 コンフィグレーション パラメータおよびファイルの再構築...14
[Sort Buffer Size] 設定...14
インデックス ページ サイズ...15
必要なメモリ量は? ...16
キャッシュ割り当ての設定...17
はじめに
このWhite Paperでは、Btrieve 6.15 から Pervasive.SQL 7 または Pervasive.SQL 2000 へアプリ ケーションをアップグレードする際のアプローチについて説明します。アップグレードに要する手順は多 くはありませんが、現在ご使用中の環境によっては時間がかかる場合もあります。ここでは、発生しう る問題について理解し、アップグレードを最低限の時間で完了できるように構成されています。 内容は、次の 3 つの大項目に分けられています。 インストール ――コンフィグレーション別 (ワークステーション、ワークグループ、サーバ) の Pervasive.SQL のインストールおよび作業時に発生しうる問題についての説明。 再 構 築――必要に応じて既存の Btrieve を再構築します。このプロセスはオプションですが、 Pervasive.SQL 7 および Pervasive.SQL 2000 の新しい機能を利用するためには必要になる場合 もあります。 テスト ――アプリケーションをテストします。
このWhite Paper 全体を通じ、バージョン番号の明記がない場合は (例えば Pervasive.SQL 7 や Pervasive.SQL 2000)、両方のバージョンが対象となっています。
インストール
ワークステーション
Pervasive.SQL 7 および Pervasive.SQL 2000 のワークステーション版は、32-bit Windows データ ベースのみをサポートしています。これは、既存の DOS ベース アプリケーションや 16-bit Windows アプリケーションをサポートしないということではなく、単にワークステーションのオペレーティング シス テムが Windows 95/98 や Windows NT 4.0 (SP3) でなければならないことを示します。
Pervasive.SQL 7 または Pervasive.SQL 2000 を単に Windows アプリケーションの 1 つしてイン ストールし、後は指示にしたがって設定をアプリケーションの実行に合わせて調整してください。
Windows 32 bit アプリケーション Pervasive.SQL を活用するための特別な調整は必要ありません。 Pervasive.SQL は透過的にデータベース アクセスのコントロールを取ります。
DOS アプリケーション アプリケーションの起動に使ったバッチ ファイルを若干変更しなければなりま せんが、単に Btrieve を起動したバッチ ファイル内のコマンドを削除するだけです。Pervasive.SQL は、DOS ベース アプリケーションに必要なインターフェイスを自動的に提供します。
ワークグループ
Pervasive.SQL 2000 のみが提供する Workgroup 版は Pervasive.SQL 2000デスクトップ シリー ズの最新の版で、ワークグループ環境のニーズに応えるため、ゼロから設計されています。 Pervasive.SQL でこのような環境をサポートするのは、この版が初めてのリリースです。Btrieve 6.15 では、データベース エンジンは MEFS (マルチエンジン ファイル シェアリング) というメカニズムを使 ってこれらの環境へコネクティビティを提供していました――MEFS は確実なテクノロジーではありま すが、大規模ワークグループの場合はセキュリティ面が犠牲になるなど、ワークグループに一定の制 限が課せられてしまいました。 しかし Pervasive.SQL 2000 Workgroup はパフォーマンスに関する問題点を解決し、ワークグルー プのセキュリティおよび信頼性のレベルを向上させます。基本的にはクライアント/サーバ データベー ス エンジンのスケールダウン版としてデザインされているため、Pervasive.SQL 2000 はデータベー スへ ｢オーナ｣ を割り当てます。他のワークグループ メンバーは、この ｢オーナ｣ データベースを通じ てデータストアへアクセスします。このようにオーナは 、ローカルのハードドライブまたは Pervasive.SQL 2000 Workgroup エンジンを実行していないリモート ストレージ デバイスで、データ ベースに対する中央アクセス ポイントになります。Pervasive.SQL 2000 Workgroup は、この中央ア クセスを通すことによって高速かつ高い信頼性でファイル ロック、レコード ロック、トランザクションなど 様々な処理を管理することが可能になります。オーナはユーザが静的に定義することも、またデータベ ースを開くたびにシステムへ動的にオーナエンジンを確立させることもできます。データベース エンジ ンを実行しているコンピュータにデータベースも常駐している場合は、データベースのホスティングを行 っているワークグループ コンピュータの [Startup] ファイルへ Pervasive.SQL 2000 Workgroup を 置いておくことを推奨します。こうしておけば、常にデータベースがある場所でエンジンが実行され、｢オ ーナ｣ も確定されます。またデータベース エンジンを実行できないコンピュータにデータベースが常駐 している場合、データベースへ最初にアクセスした Pervasive.SQL 2000 Workgroup データベース エンジンが、そのリモート データベースへのゲートウェイになります。指定のマシンを常にゲートウェイ にする場合は、｢ゲートウェイ ロケータ｣ 機能を使ってゲートウェイを静的に定義してください。 ワークグループ エンジンの基本版は、データベースへの並行ユーザを 3 ユーザまでサポートしてい ます。並行ユーザ数を増やす場合は、単一の追加ユーザ ライセンスを使います。これは、データベー スへのアクセスを必要とするステーションへ単に ワークグループ エンジンをインストールし、データベ ースのオーナーとして機能する ワークグループ エンジンへ追加のユーザ ライセンスを適用するだけ です。ワークグループのコンフィグレーションでは、並行ユーザ数は他のワークグループ メンバーとは 関係なく、そのワークグループの各メンバーに適用されるので注意してください。これは基本となる 3 ユーザ ライセンスで、3 ユーザすべてが いくつでも別のマシン上のデータベースへアクセスできるこ とを意味します (例えば 3 ユーザ全員が 3 台すべてのマシン上のデータベースへ同時にアクセスで
きます)。ユーザ カウントの詳細については 『Getting Started Guide 』 を参照してください。
ワークステーション エンジンと同様に、ワークグループ エンジンのインストールもシンプルで簡単なプ ロセスです。データベースへアクセスする各コンピュータへ ワークグループをインストールすれば、 Windows 32-bit/16-bit アプリケーションは即座に Pervasive.SQL 2000 を使うことができます。DOS アプリケーションの場合は、その DOS Btrieve データベース エンジンを起動していたバッチ ファイル から “Btrieve” コマンドを削除してください。
サーバ
リクエスタとサーバのどちらが先か ユーザの皆様が使うリクエスタのバージョンは、使用しているサーバ エンジンのバージョンと同じかそ れよりも新しくなければならないというのが パーベイシブのアップグレードおよびサポートに対するポリ シーです。このポリシーに基づいて、パーベイシブは常に完全な互換性を確認するため古いサーバ エ ンジンに対して新しいリクエスタのテストを行っていますが、新しいサーバ エンジンに対する古いリクエ スタのテストは行っていません。したがって、サーバ エンジンのバージョンよりも古いリクエスタをパー ベイシブはサポートしていません。 サーバとリクエスタのどちらを先にインストールするのかは、管理者の判断に委ねられます。ただし、シ ステムの非稼動時間中にリクエスタが必要なすべてのマシンへリクエスタをインストールできるのであ れば、まずサーバをインストールしておけば即座にすべてのクライアント マシンをアップグレードするこ とができます。逆に、サーバとは別のときにクライアントをアップグレードしなければならない場合で、こ の間にユーザがシステムへアクセスする必要があるときは別のアプローチを採ってください。 方法の 1 つとして、Pervasive.SQL Server をテスト マシンへインストールするやり方があります。イ ンストールしたら、新しいリクエスタをインストールする際に InstallScout へテスト サーバの場所を入 れ、成功したクライアント インストレーションを検証することができます。クライアントへのインストール が完了すれば、稼動しているサーバ エンジンをアップグレードするまで、アプリケーションは稼動サー バに対して新しいリクエスタを使います。サーバ エンジンおよびユーザ カウントキー
Server エンジンは、CD-ROM のインストール プログラムを単に実行し、後はマニュアル (『Getting
Started (Server edition).』) の 指 示 にしたがうだけです。Btrieve 6.15 との大きな違いは、
Pervasive.SQL のソフトウェア ユーザ カウントキーに関する規定です――Btrieve 6.15 ではデータ ベース エンジンのユーザ カウントはサーバ データベース エンジンでコード化されていましたが、 Pervasive.SQL 7 から採用したユーザ カウント キーは、累計ユーザ カウントもサポートする柔軟な ユーザ カウント ライセンシング メカニズムを提供します。例えば 20 ユーザカウント ライセンスと 10 ユーザカウント ライセンスを組み合わせて、指定のサーバを 30 ユーザカウント ライセンスにす
ることができます。プロンプトが表示されたら、製品に同梱されているユーザ カウントキー ディスクを 挿入してください。
Windows NT
Pervasive.SQL の Windows NT リリースは、ターゲット サーバの CD-ROM ドライブから直接イン ストールしなければなりません。Windows NT Server 4.0 へ Pervasive.SQL をインストールする場 合は、まず Windows NT の Service Pack 3 がインストールされていることを確認してください。 Novell NetWare
Pervasive.SQL の NetWare リリースは、ターゲットの NetWare サーバに接続されている Windows ワークステーションから、管理者のアクセス権を持っているユーザがインストールしなければ なりません。
Btrieve for NetWare をご使用の場合、新しいバージョンの BTRIEVE.NLM はコマンドライン パラメ ータを受け付けず、また古い BSTART.NCF 内の設定はロードされませんが、Smart ComponentsTM、 MicroKernel、Btrieve、リレーショナル インターフェイス、コミュニケーション モジュールをロードする新 しい BSTART.NCF が用意されています。このファイルでもコマンドライン パラメータは使えません。 基本的に、Pervasive.SQL は古い Btrieve Server ユーティリティを一切サポートしていないので、 Bsetup や BTRMon などの NLM は Pervasive.SQL で使うことができません。ただし代わりの NLM は一部提供されます (例えば Butil.NLM)。Pervasive.SQL では、必ずこれらの新しいユーティ リティを使わなければなりません。これらのユーティリティが提供していた機能は、クライアント ソフトウ ェアと共にインストールした Windows ベース ユーティリティを通じて提供されます。 Server エンジンの設定は BTI.CFG ファイルに格納されるようになり、デフォルトのインストール パス を使っている場合であればこのファイルは SYS:SYSTEM に常駐します。古い BSTART.NCF のバ ックアップ コピーは SYS:SYSTEM¥PVSW7.BCK ディレクトリに置かれます。
リクエスタ
ここでは、クライアント インストールを成功させるためのいくつかのヒントについて説明します。 スマート コンポーネントのコンフィグレーション Pervasive.SQL の新機能を利用するために既存のアプリケーションを変更する場合は、必ずそのアプ リケーションが新しい ｢スマート｣ クライアント インターフェイス ライブラリ (｢接着剤｣ として機能するDLL) をロードするように変更してください。この詳細については Pervasive.SQL SDK の一部として 提供されている 『Pervasive.SQL Programmer’ s Guide』 に説明があります。
クライアント リクエスタをアップグレードする際にアプリケーションを一切変更したくない場合は、 Pervasive.SQL の新しい Smart ComponentsTM が正しく機能するために必ず実行しなければなら ない重要な処理が 1 つあります。この処理を行うことによって、アプリケーションはまだハードドライブ 上にある古いバージョンの DLL ではなく、新しい ｢スマート｣ バージョンの Pervasive.SQL クライア ント インターフェイス DLL をロードします。新しいクライアント リクエスタをインストールする直前に、 ワークステーションのハードドライブ上にある次の各ファイルのすべての出現を検索してください。 □ Wbtrcall.dll □ Wbtrv32.dll □ Wxqlcall.dll □ Wssql32.dll □ Wdbnm32.dll □ Wbnames.dll 検索したら、これらの DLL が出現するごとに名前を変更してください。もし後で必要になった場合でも、 こうしておけばまた利用することができます (例えば最後の文字を “x” に変えて、拡張子がすべて “.dlx” にするなど)。アプリケーションの中には元のバージョンの DLL が必要なものもあるので、この ような制限があるアプリケーションがある場合に古いバージョンの DLL も保持しておかなければなり ません。Pervasive.SQL クライアントで実行できないアプリケーションがある場合は、そのアプリケーシ ョンのベンダーへ問い合わせてください。 既存の Btrieve/Scalable SQL インターフェイス DLL 名をすべて変更したら、Pervasive.SQL クライ アントのインストールを開始できます。 ネットワーク インストールを使う Server エンジンを [通常] または [カスタム] どちらかのオプションでインストールする際には、リクエ スタ インストール パッケージをサーバ マシンへコピーすることができます。こうしておくと、このサーバ へ接続し適切なインストール プログラムを実行することですべてのクライアント マシンへ新しいリクエ スタをインストールすることができるので、ネットワーク内で CD-ROM を共有したり CD-ROM を物 理的にすべてのクライアント マシンへ挿入してクライアント リクエスタをインストールする必要がなくな ります。クライアント インストール パッケージをサーバへコピーするこの方法は、サーバへのクライア ント インストールの ｢ステージング｣ と呼びます。サーバへどのようにクライアント インストールをステ ージングするのか、詳細については 『Getting Started with Pervasive.SQL (Server edition)』 を参 照してください。このマニュアルは、使用しているプラットフォーム向けの他のすべての Pervasive.SQL ドキュメントと同様に、Windows のヘルプ (.hlp) フォーマットで提供されます。またパーベイシブの WebサイトからAdobe Acrobat (PDF) ドキュメントでダウンロードすることもできます。
もう 1 つのオプションに、CD-ROM から [clients] フォルダをサーバへコピーし、クライアントからサ ーバへ接続して [clients] フォルダ内の適切なサブフォルダからインストール プログラムを実行する方 法もあります。Win16、Win32、OS/2 の各ワークステーション用のクライアント プログラムが用意され ています。DOS ワークステーションへクライアント プログラムをインストールする場合は、ワークステ ーションへ DOS リクエスタを直接コピーしなければなりません。
インストールのトラブルシューティング
Workstation 版 / Workgroup 版□ Pervasive.SQL Workstation または Workgroup をインストールしても Windows 16-bit または 32-bit アプリケーションが自動的に稼動しない場合 (または、まだ Btrieve 6.15 データベース エンジ ンを使ってしまう場合) は、システム上で DLL のコンフリクトが発生していることが考えられます。ワー クステーションのハードドライブで次の各ファイルの出現を検索してください。 □ Wbtrcall.dll □ Wbtrv32.dll □ Wxqlcall.dll □ Wssql32.dll □ Wdbnm32.dll □ Wbnames.dll 検索したら、インストール時に指定したインストール パス内 (デフォルトは drive:¥PVSW) にないこれ らの DLL が出現するごとに名前を変更してください。もし後で必要になった場合でも、こうしておけば また利用することができます (例えば最後の文字を “x” に変えて、拡張子がすべて “.dlx” にするな ど)。アプリケーションの中には元のバージョンの DLL が必要なものもあるので、このような制限があ るアプリケーションがある場合に古いバージョンの DLL も保持しておかなければなりません。 Pervasive.SQL クライアントで実行できないアプリケーションがある場合は、そのアプリケーションのベ ンダーへ問い合わせてください。 既存のすべての重複したDLL 名を変更すれば、問題なくアプリケーションを実行できるようになるはず です。
Server 版
□ NetWare 4.1x 以上の場合は、Pervasive.SQL 2000 をインストールするサーバに対する管理者 権限 (ルートに対する) を有していなければなりません。 □ 既存のユーザ カウントへ ｢無制限 (Unlimited)｣ のユーザ カウントをインストールしようとすると失 敗することがあります。この場合、 ｢無制限 (Unlimited)｣ のユーザ カウントをインストールする前に、ユーザ カウント マネージャ ユーティリティを使って既存のユーザ カウントを削除しなければなりませ ん。
□ NetWare の場合、BTRIEVE.NLM や BSPXCOM.NLM への上書きができないためにインストー ルが失敗したときは、Novell から提供されたユーティリティを使ってファイル属性を読み取り/書き込み モードに設定し、またインストール中にロードされないようにしなければなりません。
□ Btrieve 6.15.451 から Pervasive.SQL 7 へのアップグレードが完全に成功したにも関わらず、 NetWare サーバで BSTART を発行すると Btrieve 7.x の代わりに Btrieve 6.15 が起動されるこ とがあります。 これは、NetWare 向けに特に行った変更――6.15.451 NLM の日付がPervasive.SQL 7 NLM の 日付よりも新しいために発生します。インストール プロセスではコンポーネントの日付がチェックされ、 インストールよりも新しい日付のコンポーネントへは上書きしません。この問題を解決するには、 SYS:SYSTEM ディレクトリから B*.NLM および B*.NCF のバックアップを取ってから削除し、 Pervasive.SQL インストール プログラムを再度実行してください。
□ Pervasive.SQL for NetWare をインスト ー ル し た 後 に 、 サ ー バ コンソ ー ル で 一 部 の Pervasive.SQL モジュールをロードする際に問題が発生したり、例えば BSPXCOM.NLM など他の NLM をロードしようとしたときに 問 題 が 発 生 す ることもあります。 NSGetConfigInfo や NsisValidRequestClass などの Undefined Public Symbol エラーでロード コマンドが処理に失敗 する場合もあります。 このように NLM が失敗する理由は、NetWare サーバが TCP/IP 用に設定されていないためです。 デフォルトでは、 Pervasive.SQL はサポートする通信プロトコルとして SPX および TCP/IP の両方 が設定されています。このコンフィグレーションはセットアップ ユーティリティを使って設定し、サーバの SYS:¥SYSTEM ディレクトリの BTI.CFG に記録されます。セットアップ ユーティリティが接続できな い場合は、テキスト エディタを使って BTI.CFG を編集できます。 NetWare サーバが SPX のみで設定されている場合は、Pervasive.SQL セットアップ ユーティリテ ィを 使 っ て サ ー バ へ 接 続し、 Scalable SQL Communications Manager お よ び Btrieve Communications Manager の [Supported Protocols] を SPX のみに変更してください。
Pervasive.SQL への接続に TCP/IP を使いたい場合、Pervasive.SQL のコンフィグレーションはデ フォルトで正しい設定になっています。NetWare サーバおよびワークステーションは TCP/IP 用に設 定しなければなりません。
NWBSRVCM は IPX/SPX サポートの BSPXCOM および/または Btrieve の TCP/IP サポートを 自動ロードします。
□ Pervasive.SQL は NetWare で TCP/IP プロトコルをサポートしているので、BTRIEVE.NLM お よび他の NetWare NLM が伴う循環参照のために MicroKernel (NWMKDE.NLM) のアンロードに 若干問題のあることがあります。コンフィグレーションが変更されているため、通常は NWMKDE を再 起動しなければなりません。NetWare では記号参照のため Btrieve.NLM をシャットダウンすること ができないので、安全にこれを行う唯一の方法がシステム全体の再起動です。Pervasive.SQL 7 の Service Pack 4 および Pervasive.SQL 2000 では、BSTOP コマンドを発行する前に BTRV UNLINK コマンドを発行することで NWMKDE を強制的にシャットダウンできます。これによって NWMKDE から Btrieve.NLM を外すことができるので、NWMKDE をアンロードできるようになりま す。 ただし、OS の記号参照のため BTRIEVE.NLM はまだアンロードできないので、NWMKDE を 再起動するために BSTART を再発行してください。Btrieve.NLM への参照を有する OS NLM のフ ァイルが開いている場合、NWMKDE から Btrieve.NLM を外した後に Btrieve の処理を発行すると エラーが発生するので注意してください。
アップグレードの完了
Pervasive.SQL の新機能すべてを使うのでなければ、これでアップグレードは完了です。データ ファ イルを再構築する必要はありません――Pervasive.SQL は、5.x および 6.x のファイル フォーマッ トをサポートしているデータ ファイル フォーマットについて、完全に下位互換性を有しています。 したがって、データファイルをバージョン 7 のフォーマットで再構築しない限り、この時点では Pervasive.SQL の一部の機能を利用できません。 6.x ファイル フォーマットで利用できる Pervasive.SQL の機能は次の通りです。 □ パフォーマンスの向上 □システムトランザクション ロギングおよびトランザクション一貫性保守(データファイルに一意のキー が格納されている場合)□ ISR (International Sort Rule) サポート
バージョン 7のファイル フォーマットでなければ利用できないPervasive.SQLの機能は次の通りです。
□ 新しい 64 GB のファイル サイズ制限
□ データファイルに一意のキーがない場合の、システムトランザクション ロギングおよびトランザクショ
ン一貫性保守
トラブルシューティング
NetWare へ Pervasive.SQL Service Pack を適用した際に ｢Licensing information is out of sync,｣ というメッセージが表示されたらパーベイシブのテクニカル サポート （03）5405-2265 または [email protected] まで電子メールでご連絡ください。
まとめ
Pervasive.SQL のアップグレードは簡単なプロセスです。ただし他のどのソフトウェアもそうであるよう に、大規模な環境や複雑な環境の場合であれば、アップグレードはここでの説明よりも複雑になること があります。本白書で説明した内容は、どのような規模の環境でも Pervasive.SQL のアップグレード を成功させるためのコンサルティング サービスを用意しております。詳しくはパーベイシブのテクニカ ル サポート （03）5405-2265 または [email protected] まで電子メールでご連絡ください。 各コンサルティングの内容は弊社ホームページhttp://ww.pervasive.co.jp/でも確認することが可能で す。付録 A
ファイルの再構築
ファイルの再構築 (オプション)
新しいバージョンのすべての機能を利用するには (例えばより大きなファイルサイズのサポートやシス テムキー生成など)、バージョン 7 のファイル フォーマットを使うようにデータファイルを再構築しなけ ればなりません。データファイルを変換するための再構築 (Rebuild) ユーティリティの詳しい使用法に ついては 『Pervasive.SQL User's Guide』 の ｢MicroKernelデータファイルの変換｣ を参照してくだ さい。ここでは、再構築ツールの適切な使い方についての情報を提供します。
□ 再構築するファイルが数多くある場合は、GUI 再構築ユーティリティを使わなければなりません。こ
のユーティリティの今回のバージョンでは 1 回に多数のファイルを選択できるので、選択処理を簡単 に実行できます。メモ: Pervasive.SQL 7 ユーザの皆様の場合、このユーティリティは Service Pack 1 以降のみサポートしています。
□ DDF もデータファイルとして変換しなければなりません。
□ 複数のファイルを変換する際に最も良いアプローチ (Windows NT Server の場合) は、GUI 再構
築ユーティリティを使い、変換したいすべてのファイルのリストを作成してから一括して変換する方法で す。3 GB や 4 GB の大きなファイルの変換には数時間かかることもあります。NetWare での複数フ ァイルに対する最良のアプローチは、BREBUILD.NLM サーバ ユーティリティを使い 『User's Guide』 の説明にあるようにコマンド ファイルを作成し、このコマンド ファイルへ変換したいすべてのファイル名 をする方法です。
□ Pervasive.SQL 7 で Service Pack 2 をインストールしていないと、NetWare サーバで大きなファ イル (2 GB 以上) の再構築を実行した場合、ファイルごとに 20時間から30時間かかってしまいます。 Service Pack 2 はこの問題に対するソリューションを提供します。 □ 複数のサーバ エンジンを利用できるのであれば、変換するファイルの合計数を分割して各サーバ エンジンで実行することができます。アップグレードのための予定停止時間内に、他のサーバ エンジン が常駐しているコンピュータへ大きなファイルをコピーし、変換が終了したら元に戻してください。こうす れば変換の負荷を複数の CPU に分散することができます。 □ ｢Continue on Error｣ オプションと *.* ファイル リストを組み合わせることで、同じディレクトリ内に 他のタイプのファイルがあったとしても、そのディレクトリ内の全データファイルを変換することができま す。他のタイプのファイルを再構築ユーティリティが開こうとするとエラーが発生しますが、｢Continue on
on Error｣ を設定しておくことでユーティリティはこれを無視し、次のファイルへと処理を継続します。 □ ディレクトリ内のファイルがすでにバージョン 7 フォーマットであってもこれらのファイルはやはり再 構築され、ユーザが指定した再構築オプションによってはレコードの物理的な順序が変わることがあり ます。新しいフォーマットから前のフォーマットへ変換することはできません。例えばバージョン 7 のデ ータファイルをバージョン 6.x フォーマットへは変換できません。 □ 現在のところ、変換対象の個別のディレクトリや個別のファイルをすべて列挙したリストを作成せず に再帰的変換や複数ディレクトリ変換を実行する機能はサポートしていません。 □ 『User's Guide』 の説明にある通り、データファイルのリストを作成する場合はメニューで [実行] を 選択してから、この実行で変換するファイルをファイル リストから選択してください。説明には、[実行] オ プションを選択した後に、実行しようとしている変換プロセスからすでに選択したファイルを除外すること はできない旨が明記されています。 再構築プロセスの最適化 再構築ユーティリティは、Btrieve に MicroKernel を呼び出させることでファイルのコピーを作成しま す。すなわち MicroKernel のコンフィグレーション設定およびコンピュータ上の物理的な RAM によっ て、データファイル再構築の所要時間が大きく変わってきます。これは大きなファイルの場合に顕著で す。 通常、インデックスの作成はデータページの作成に較べかなり長い時間を要します。したがって数多く のインデックスを有するデータファイルがある場合、インデックスの数が少ないファイルに較べて再構築 により時間がかかります。 再構築ユーティリティでは、2つの異なる方法を使ってファイルを再構築することができます。デフォルト では、再構築ユーティリティは Btrieve を使って次の手順を実行します。 1. ソースファイルの定義と同じレコード 構造およびインデックスの新しい空のファイルを作成します。 2. このファイルからすべてのインデックスを削除します。 3. このファイルへ、インデックスなしですべてのデータをコピーします。 4. 下記の手順でインデックスを付加します。
5. ソースファイル内の各キーについて、MicroKernel は適切なフィルタを有する Extended Step 処 理を使ってメモリ バッファへ読み込める限りのキー値を読み込みます。
6. MicroKernel はメモリ バッファ内の値を並べ替え、並べ替えた値を一時ファイルへ書き込みます。 7. 各レコードからのキー値をすべて処理するまで MicroKernel は上記の手順 5 および 6 を繰り返 します。
8. これで一時ファイルには、個々に並べ替えられたキー値の複数のセットが格納されます (ファイル 内のキー値のセット数は、後述する Blocks Required 値とほぼ同じになります)。MicroKernel はこ れらのセットをインデックス ページへマージし、各ページを限界まで埋めます。各インデックスページは Btrieve ファイルの最後に付加されるので、ファイル長は拡張されます。このマージ処理の間、一時フ
ァイルのサイズは大きくなっていきますが、並べ替え (手順 5 から 7) の時ほど急激に大きくはなりま せん。 9. 残っているキーについて手順 5 から 8 が繰り返されます。 MicroKernel は、デフォルトの方法を実行するには物理メモリが十分でない場合にもう 1 つの方法で ある ｢フォールバック｣ 法を使います。フォールバック法では、MicroKernel は次の手順を実行します。 1. ソースファイルの定義と同じレコード構造およびインデックスの新しい空のファイルを作成します。 2. このファイルからすべてのインデックスを削除します。 3. このファイルへ、インデックスなしですべてのデータをコピーします。 4. 下記の手順でインデックスを 1 つずつ付加します。
5. ソースファイル内の各キーについて、MicroKernel は Step Next 処理を使って 1 レコードずつ読 み込みます。 6. MicroKernel はレコードからキー値を抽出し、この値をインデックス内の適切な場所へ挿入します。 キー ページがいっぱいになった場合はページ分割しなければなりません。 7. 各レコードからのキー値をすべて処理するまで MicroKernel は上記の手順 5 および 6 を繰り返 します。 8. 残っているキーについて手順 5 から 7 が繰り返されます。 フォールバック法はデフォルトの方法に較べてかなりの時間を要します。数多くのインデックスを有する 大きなファイルがある場合、これら 2 つの方法の差は数時間、場合によっては数日になることもありま す。デフォルトの方法 (速い方) が適用されるようにするための唯一の方法は、サーバ マシンに十分 な物理メモリを用意しておくことと、また NetWare 環境であれば利用可能なメモリをあまりフラグメント (断片) 化しないことです。 次の項からは、サーバ上に十分なメモリがあるかどうかを確認する方法について説明します。 コンフィグレーション パラメータおよびファイルの再構築 コンピュータ上のフリーなメモリ量および一部のコンフィグレーション パラメータは、インデックス再構築 処理の所要時間に直接影響します。ここでは、お使いのマシンがデフォルトの方法とフォールバック法 のどちらを使ってインデックスを再構築するのか、またこの処理を迅速に行うためにユーザができるこ とについて説明します。説明中に出てくる式で斜体で表記された値は何度も出てくる値を示すので、必 要に応じて前の説明を読み返し、その値がどのように得られるのかを確認してください。
[Sort Buffer Size] 設定
セットアップ ユーティリティで [MKDE] コンポーネント、[Memory Resources] カテゴリ、[Sort Buffer Size] 属性を選択してください。この値によって、インデックスの再構築に MicroKernel が使用できる メモリが分かります。
[Sort Buffer Size] 属性がゼロ以外の値で、計算された最小必要メモリ バイト値 (下記参照) よりも 小さい場合、インデックスの構築用に再構築プロセスが割り当てるべきメモリ量として [Sort Buffer Size] の値が使われます。
[Sort Buffer Size] 属性がゼロの場合、MicroKernel は最小必要メモリ バイト値を計算し、割り当てる
べきメモリ量としてこの値が使われます。 最後に、MicroKernel は割り当てるべきメモリ量と実際に利用可能なメモリ量の 60% を比較し、小さ い方を割り当てます。コンピュータのメモリすべてを使わないようにするため、このような60%ルールを 使います。 メモリ割り当てに失敗すると、MicroKernel は元の量の半分を割り当てようとします。もし最終的に割り 当てができなかった場合に、MicroKernel はフォールバック法を適用します。 メモリ割り当てに成功した場合、割当済ブロックは少なくとも次の項で説明している最小必要メモリ バ イトの式で定義されている大きさと同じ大きさがなければなりません。また必要なメモリのブロック数も 一定の基準を満たしていることが必要です。詳細については次項からの各式を参照してください。 インデックス ページ サイズ ファイル内のページ サイズもインデックス作成の所要時間に影響を及ぼします。前項の例をここでも 使い、20バイトキー、ページサイズ 512バイトの場合、Btrieve は各インデックス ページに 8 個から 18 個のキー値 (インデックス ページは最低でも半分は埋められます) を置きます。およそ 800万レ コードのインデックスを作成すると、およそ 7 レベルの深さを持つ B-Treeが作成され、ほとんどのキ ーページは最終レベル (7番目) になります。 ページサイズを 4096バイトにした場合、Btrieve は各インデックス ページに 72 個から 145 個のキ ー値を置きます。この B-Treeは、各キー値を挿入する際に検証するページ数がなるべく少なくなるよ うに、およそ 4 レベルだけの深さになります。 キーページ数が少なくなると、フォールバック法を使ったインデックス作成に要する時間が劇的に長くな ります。並べ替え/マージ法を使えば、キーページのサイズがインデックス作成のパフォーマンスに与え る影響はずっと小さくなります。 B-Treeの深さが増えるにしたがって、インデックス作成に要する時間は指数級数的に長くなります。 ページサイズが 4096バイトより小さい Btrieve ファイルを再構築する場合は、再構築プロセス時にペ ージサイズを変更することを考えてください。ページサイズ変更時に考慮すべき点については
Pervasive.SQL SDK と共に提供される 『Pervasive.SQL Programmer's Guide 』 を参照してくださ い。 インデックス ページごとのキー値の適切な最大数の計算は次の式で求められます。 最大キー = ( ページサイズ – 12 ) / (キー長 + キーオーバーヘッド) 必要なメモリ量は? デフォルトの方法を使った場合に、あるファイルのインデックスを再構築する際に必要な最適/最小の連 続するフリーメモリ量は、次の式で求められます。最適なメモリ量とは、すべてのマージ ブロックを RAM へ格納するために十分なメモリ量を指し、最小メモリ量とはマージ ブロック 1 つをRAM へ格 納するために十分なメモリ量を指します。 キー長 = ファイル内にある最大キーの全セグメントの合計サイズ キーオーバーヘッド = 8 (ただしキータイプがリンク重複可能キー(Linked Duplicate) の場合は 12) レコード カウント = ファイル内のレコード数 最適メモリ バイト = ((( キー長 + キーオーバーヘッド) * レコード カウント) + 65536 ) / 0.6 最小メモリ バイト = 最適メモリ バイト / 30 例えば800万レコードのファイルがあり最も長いキーが20バイトのとき (タイプはリンク重複可能キーで はない)、最適なメモリ量は ((( 20 + 8 ) * 8,000,000 ) + 65536 ) / 0.6 = 373,442,560 バイト、すなわ ち 373.5 MBになり、最小メモリ量はこの値の1/30なので12,448,086 バイトすなわち12.45MBになり ます。 除数が 30 なのは、エンジンが一度に追跡できるマージブロック数は最大 30 ブロックで、メモリ内に 必要なのは常に1ブロックのみだからです。また除数 0.6 は、このプロセスでエンジンが割り当てる利 用可能な物理メモリは最大60%だからです。 利用可能な物理メモリが上記の最小量に満たない場合、エンジンはフォールバック並べ替え法を使っ てデータファイルを再構築します。 この例では、連続するフリーメモリ量の最適値は373,442,560 (373.5MB) です。この量を利用できる 場合、並べ替え/マージ プロセスが RAM 全体で実行されます。割り当て制限は60%なので、この数 字が実際に再構築プロセス開始時に必要な連続するフリーな物理メモリ量になります。再構築プロセ スが実際に使うメモリ量ではありません。再構築プロセスが実際に使う最大メモリ量を知りたいときは、
この値を0.6で乗じてください。 最後に、実際に割り当てられるブロックは次の 2 つの基準を満たしていなければなりません。 必要ブロック は 30以下であること。 必要ブロック= まるめ ( 最適メモリ バイト / 割当済ブロック ) また割当済ブロックは次の値以上であること。 ( ( 2 * 最大キー + 1 ) * ( キー長 + キーオーバーヘッド ) ) * 必要ブロック ここまでと同じ例を使って、ページサイズが512バイトで12.45MBのブロックが正しく割り当てられてい る場合のテスト値を計算してみましょう。 必要ブロック = 373,500,000 / 12,450,000 = 30 テストのこの部分はパスします。次の部分 最大キー = (512-12) / 28 = 18 ( ( ( 2 * 18 ) + 1 ) * ( 20 + 8 ) ) * 9 = 9324 割当済ブロック (12.5MB) は9324バイトよりも大きいでしょうか?――答えは ｢大きい｣ なので、上記 2番目のテストもパスします。インデックス キーは 12.45MBピースで一時ファイルへ書き込まれ、メモ リへ格納され、最終的にB-Tree インデックスとして書き込まれます。 このプロセス中に何らかの問題が発生した場合 (例えば一時ファイルを開けなかったり書き込めなか った場合など)、再構築ユーティリティは最初に戻ってフォールバック法でインデックスを構築します。 キャッシュ割り当ての設定
セットアップ ユーティリティで [MKDE] コンポーネント、[Memory Resources] カテゴリ、[Cache Allocation] (キャッシュ割り当て) 属性を選択してください。この値によって、データファイルへのアクセ スに MicroKernel が使用できるメモリが分かります。メモ: [Cache Allocation] はインデックス作成に は使いません。
キャッシュ割り当ての値を大きくしてもインデックス構築が早くなることはなく、逆に再構築プロセスで使 えるメモリがキャッシュに使われてしまうために処理速度が遅くなってしまうこともあります。大きなファ
イルを再構築する場合に最も良い方法は、キャッシュ値を小さくすることでインデックス再構築プロセス が使えるメモリ量をできる限り大きくすることです。 B-Tree インデックスの深さを計算する (オプション) B-Treeインデックスのレベル (深さ) を計算することができますが、式は若干複雑になります。まず次 のパラメータの計算を行ってください。 □ ページ オーバーヘッドはファイル ページごとのオーバーヘッドのバイト数です。この値は 12 です。 □ キー密度はファイル ページの合計ページに対してキー値が占めるスペースの割合です。 キー密度 = 1 (インデックス作成処理で最近作成されたキーの場合) キー密度 = .65 ([Index Balancing ] がオンになっている場合) キー密度 = .55 ([Index Balancing ] がオフになっている場合) □ ユニークキーは指定キーに対するキー値の合計数に対して一意なキー値の割合です。 ユニークキー = 1 (キータイプがリンク重複可能キー(Linked Duplicate) の場合) ユニークキー = 不明 (上記以外。値はデータベースの内容によって変わってきます) □ キー/ページは、インデックス ページ 1 ページ内のキー値の数です。 キー/ページ = 絶対値 ( ( ( ページサイズ – ページオーバーヘッド ) / ( キー長 + キーオーバーヘッド) ) * キー密度 ) 上記すべてのパラメータ値を求めたら、次の式を使ってB-Treeのレベル数を計算できます。 (ファイル内のレコード数 * ユニークキー < キー/ページ) のとき、B-Treeインデックスのレベルは 1 です。 (ファイル内のレコード数 * ユニークキー < (キー/ページ + キー/ページ ^2)) のとき、B-Treeインデ ックスのレベルは 2 です。 (ファイル内のレコード数 * ユニークキー < (キー/ページ + キー/ページ ^2 + キー/ページ ^3)) の とき、B-Treeインデックスのレベルは 3 です。 必要に応じてこの式を外挿し、B-Tree のレベルをさらに計算することもできます。
商標について
MicroKernel Database Architecture、MicroKernel Database Engine、Navigational Client / Server、Scalable SQL は Pervasive Software Inc. の商標です。Btrieve は Pervasive Software Inc. の登録商標です。
Novell および NetWare は Novell, Inc. の登録商標です。
Windows、Windows NT、Visual Basic は Microsoft Corporation の商標です。Microsoft は Microsoft Corporation の 登録商標です。 その他のブランドおよび製品名の権利はそれぞれの所有者が有しています。 お問合わせ先
