InterBase の移行における問題
提供: InterBase
目次
InterBase 2020 の移行における問題
- InterBase 2020 Update 1 で作成されたデータベース バックアップは、2020 Update 1(もしくはそれ以降)のクライアント(gbak)またはサーバー(サービス API) バージョンで復元されなければなりません。これより古い ODS バージョンで、古いバージョンのサーバーへバックアップを復元する場合には、2020 Update 1
GBAK
クライアントを使用してください。 - InterBase 2020 は、デフォルトでは ODS 18 でデータベースを作成しますが、トランザクション負荷のため、ODS 13 以降のデータベースにも接続できます。
- InterBase 2020 では、ODS 11 および ODS 12 のデータベースのバックアップは、クライアント/サーバー モード使用している
gbak
コマンドライン ツールを使用している場合にのみ可能で、サーバー マネージャ モードではできません。 古い InterBase ODS 11 や 12 のデータベースから移行する場合、この機能を使用することができます。 - 本リリースでは、次の新しい InterBase キーワードが導入されています:
COLLATION
は InterBase 2020 での予約キーワードです。
InterBase 2017 の移行における問題
- InterBase 2017 は、デフォルトでは ODS 17 でデータベースを作成しますが、トランザクション負荷のため、ODS 13 以降のデータベースにも接続できます。
- InterBase 2017 では、ODS 11 および ODS 12 のデータベースのバックアップは、クライアント/サーバー モード使用している
gbak
コマンドライン ツールを使用している場合にのみ可能で、サーバー マネージャ モードではできません。 古い InterBase ODS 11 や 12 のデータベースから移行する場合、この機能を使用することができます。 - 本リリースでは、次の新しい InterBase キーワードが導入されています:
DEFERRED
およびIMMEDIATE
は、未予約のキーワードです。EXCLUSIVE
、EXCLUSIVITY
、RECURSIVE
、TRUNCATE
は、InterBase 2017 における予約キーワードです。 - ODS 17 では、テーブル行全体に対する変更ビュー サブスクリプション定義のサポートが有効になっており、それ以降の
ALTER TABLE
オペレーションが継続されます。 この利点を利用したい場合は、ODS 16 データベースをバックアップと取り、ODS 17 へリストアしてください。
InterBase XE7 の移行における問題
- 古いクライアント(古い IBConsole)が、新しい ODS 16 データベースに接続しようとすると、例外が発生する点に注意してください。これは、そのクライアントが INTEGER として定義されていないデータ型に直面するためです。 回避策は、新たな IBConsole をインストールして、新旧の InterBase サーバーに接続します。 新しい IBConsole は、この用途のために後方互換性があります。
- InterBase Lock Table サイズは、IBConfig パラメータを変更して増加させる必要があります。これは、すべてのエントリが領域を取るためです。 InterBase Lock Table サイズを増加させるには、ibconfig ファイルを編集して、V4_LOCK_MEM_SIZE エントリを変更してください。
- InterBase XE7 は、ODS 16 と共にリリースされています。 新しいエンジンは、ODS 13 移行のみをサポートしています。 この変更により、サポートされているすべてのプラットフォームは、同じ ODS バージョン(13 から 16)をサポートします。
- 古いバージョンの Visual Studio(2005 以前)で構築されている 64 ビット UDF ライブラリは、InterBase XE7 で動作しないというレポートが上がっています。 古い UDF ライブラリがある場合、新しい InterBase バージョンで念のためテストしてください。 もしくは、UDF 64 ビット ライブラリを最新バージョンの Visual Studio で再ビルドしてください。
- 新しいキーワード ROW が、SQL キーワード トークンとして「予約語」になりました。
InterBase XE3 の移行における問題
Windows レジストリおよびプログラム ファイルの変更
InterBase XE3 では、よりよい Windows 互換性のために変更が行われています。 InterBase XE3 では、[Program Files] の場所への製品のインストールがデフォルトになり、Windows レジストリ階層でも「Borland」サブ キーを使用しなくなりました。 現在では、インスタンス固有の情報の追跡には、「Embarcadero」サブ キーを使用しています。 お使いのアプリケーションを、なるべく早く新しい環境へ移行することを、強くお勧めします。
- プログラム ファイルのインストール場所
- 2009 以降のバージョンの InterBase は、製品を Windows のデフォルト フォルダ [Program Files] 以下の場所へインストールされていました。 これは、Windows UAC ガイドラインによるもので、管理者権限のないアプリケーション周りには制限をおき、[Program Files] ファイル システム フォルダ下への書き込みを抑制しています。 InterBase XE3 でのサーバー ベース エディションでは、Windows アプリケーション互換性ガイドラインに準拠し、 デフォルト インストール場所が、C:\Embarcadero\InterBase から C:\Program Files\Embarcadero\InterBase へ変更されました。
- プログラム データの場所
- InterBase XE3 では、プログラム データ ファイルを、 %ALLUSERSPROFILE%\Embarcadero\InterBase ディレクトリに配置するようになりました。 インストールの各インスタンスについて、この下にフォルダが作成され、書き込みアクセスを必要とするすべてのファイルが、ここに配置されます。 たとえば、InterBase XE3 をデフォルトでインストールした場合、「gds_db」インスタンスを取得し、InterBase の書き込み場所とファイルは次のようになります:
- ディレクトリ: %ALLUSERSPROFILE%\Embarcadero\InterBase\gds_db
- ファイル:
- admin.ib (古いバージョンの InterBase から移行している場合には、ここに古い admin.ib ファイルを配置する)
- license/ (ここに InterBase ライセンス ファイルを配置する)
- examples のサブフォルダ構造と、すべての関連ファイル
- OTW SSL 関連ファイルは、「secure」サブフォルダに
- 実行時作成されるファイル(interbase.log、.lck、.env など)
InterBase XE 以前の移行に関わる問題
- 旧バージョンをアンインストールする前に、セキュリティ データベースを含むすべてのデータベースを必ずバックアップしてください。
- SUSE 11 SP1(もしくはそれ以降)のサーバーを対象と考えているのなら、InterBase クライアントを 10.0.0.292 以上にアップグレードすることをお薦めします。 SUSE 11 SP1 サーバーからのイベントを待機する、古いバージョンのクライアントには、既知の問題があります。
- カスタマイズされている場合は、ibconfig をバックアップします。
- このバージョンでは、新しいデータベースは ODS バージョン 15 で作成されます。
- 64 ビット版の InterBase では、64 ビット UDF ライブラリだけを使用してください。 64 ビット サーバーでは、これまでの 32 ビット UDF ライブラリを読み込めません。 提供されている UDF ライブラリ(OOTB、ib_udf)は、既に 64 ビット用にビルドされており、製品と一緒にインストールされています。
- InterBase XE では、1 つのテーブルに格納できるレコード数が増えています。 現在のカウントには 32 ビットという限界があります。 32 ビットよりも大きいレコード値の数のカウントが必要であれば、以下の手順を実行してください。
- テーブルの行数が 2 G を超える場合には、CAST(COUNT() AS NUMERIC(18,0)) というコードを使用してカウントを 64 ビットにしなければなりません。
- InterBase XE で、強度の高いパスワード保護 が実装されました。 古いバージョンの InterBase クライアントが(ローカルまたはリモート システムから)このインストール ファイルと通信する場合には、システムを InterBase XE3 にアップグレードする際に、次の点に留意してください。
- 既存の(旧バージョンの InterBase で使用していた)ユーザー認証データベースがある場合には、そのデータベース ファイルを(InterBase XE フォルダにコピーして)使用すると、ローカルやリモートのクライアントの認証は正しく動作します。
- InterBase XE の新しい admin.ib を使用する場合には、このデータベースで強度の高い "SHA-1" パスワード(デフォルト)が使われていることに注意してください。 強度の低い DES パスワード アルゴリズム(これまでの InterBase リリースのもの)を引き続き使用する場合には、「強度の高いパスワード保護」のトピックで説明した ALTER DATABASE コマンドを使用してください。
- InterBase XE で提供されている "強度の高い長いパスワード" を使用する場合には、ユーザー アカウントを作り直し、かつ、この InterBase XE サーバーに接続しているリモート マシンに新しい InterBase クライアントをインストールする必要があります。 これは、"古い" InterBase クライアントでは "SHA-1" パスワードを計算することができず、"DES" の強度のパスワードを渡すので、InterBase XE サーバー側で予期しているものと一致しないためです。 その結果、"Your user name and password are not defined...(ユーザー名とパスワードが定義されていません)" というエラーが出力されます。
- InterBase XE の更新された SSL パラメータ名。 古い OTW クライアント プロパティは、新しい OTW プロパティによって置き換えられました。 操作ガイ の「OTW 暗号の設定」と、第5章にある表 5.2 を参照してください。
- データベースを復元すると "unassigned code(割り当てられていないコード)" というエラーが出力される
- InterBase XE でデータベースを復元すると、"unassigned code(割り当てられていないコード)" というエラーが出力されます。 長く使われているデータベースや、InterBase 2009 でバックアップして InterBase XE で復元したデータベースでは、メタデータ セキュリティの設定が異なります。 So when selecting a system table (for example: RDB$RELATIONS) you get the error message: "no permission for read/select access to table RDB$RELATIONS by user SYSDBA" (ユーザー SYSDBA は RDB$RELATIONS の読み取り/検索アクセスを行う権限がありません)
- このエラーは、次の基準に当てはまるデータベースで発生します。
- 元々は InterBase 6.5 より前のバージョンで作成された。
- InterBase 2009 より前のバージョンでバックアップされた。
- Readmeta.sql がまだ適用されていない。
- このような動作が生じるのは、データベースの復元を行うときに、InterBase XE ではメタ データ権限が厳密に適用されるためです。
-
- 解決方法:
- この問題を解決するには、バックアップする前に readmeta.sql をデータベースに対して実行します。 readmeta.sql は、多くの場合、\examples\security にあります。 isql または IBConsole を使用して、readmeta.sql をデータベースに対して実行することができます。
-
- 説明:
- 長い間使われているデータベースでこの問題が発生します。 (1)データベースが IB6 -> IB7 -> IB2007 -> IB2009 -> IBXE と復元されてきた、(2)データベースが IB2009 でバックアップされて IBXE で復元された、という 2 つの状況が考えられます。 それぞれの状況で、メタデータ セキュリティ設定は異なります。 (1)の場合は、最初に IB6 で作成されているため、そもそもメタデータ セキュリティが設定されていません。 それに対して(2)の場合には、IB2009 で作成されているため(復元はされていません)、すべてのシステム テーブルにあらゆるセキュリティ権限が設定されています。
- 前者の場合、データベースはバックアップと復元が繰り返され、新しいリリースになるたびに、そのリリースで追加されたシステム テーブル(RDB$USERS、RDB$ENCRYPTIONS、RDB$ROLES など)の権限が設定されます。 ただし、元々存在するシステム テーブルについては、データベース所有者が既にセキュリティ権限を変更しているかどうかを判断できないため、変更は行われません。 たとえば、ユーザーが RDB$TRIGGERS および RDB$PROCEDURES に対する権限をすべて取り消して、トリガーやストアド プロシージャのコードを隠していることも考えられます。
- また、前者の場合には、何年も前に SYSDBA が readmeta.sql を実行し、その基準のメタデータを変更してカスタム セキュリティ プロファイルを作成している可能性もあります。 XE の復元の後で InterBase が自動的に既定値に戻して、そのカスタマイズを上書きすることはできません。XE InterBase XE では、個々のデータベースのこれまでの履歴を把握していないため、復元するすべてのデータベースに無条件にデフォルトのメタデータ権限を設定するべきだと想定することはできません。
- そのため、readmeta.sql を実行し、そのデフォルト値を出発点として望ましい状態に構成することをお勧めします。 これは、移行先が XE 以外の場合でも同じです。
-
- isql の使用例:
isql "path to database" -user sysdba -password masterkey -i readmeta.sql
-
- IBConsole での readmeta.sql の実行
- IBConsole でデータベースに接続します。
- [ツール|対話型 SQL...] を選択します。
- [クエリー|SQL スクリプトの読み込み] を選択し、readmeta.sql を選択して [開く] をクリックします。
- IBConsole での readmeta.sql の実行
-
- ERROR: No Permission for read/select access to table RDB$XXXX by user SYSDBA(ユーザー SYSDBA はテーブル RDB$XXXX の読み取り/検索アクセスを行う権限がありません)
- InterBase 6.5 より前のバージョンで作成されたデータベースでは次のエラーを発生させる可能性があります: no permission for read/select access to table RDB$XXXX by user SYSDBA with InterBase XE. (ユーザー SYSDBA は InterBase XE でテーブル RDB$XXXX の読み取り/検索アクセスを行う権限がありません)
-
- 解決方法:
- InterBase XE ではメタ データのセキュリティが厳しくなっているため、バージョン 6.5 よりも前の InterBase で最初に作成されたデータベースに対してメタ データ操作を行うと、このエラーが出力される可能性があります。 メタ データ操作には、システム オブジェクトの一覧の作成などシステム オブジェクトの情報を要求する、それを更新する、パフォーマンス モニタを使用する、といったものがあります。
- このエラーを解決するには、よく似た 2 つの操作を実行する必要があります。 最初の操作では、システム テーブルに対する権限を付与します。 そのためには、InterBase インストール ディレクトリの examples\security フォルダにある readmeta.sql を実行します。 isql または IBConsole を使用して、readmeta.sql をデータベースに対して実行することができます。
- isql の使用例:
isql "path to database" -user sysdba -password masterkey -i readmeta.sql
-
- IBConsole での readmeta.sql の実行
- IBConsole でデータベースに接続します。
- [ツール|対話型 SQL...] を選択します。
- [クエリー|SQL スクリプトの読み込み] を選択し、readmeta.sql を選択して [開く] をクリックします。
- IBConsole での readmeta.sql の実行
-
- 次に、パフォーマンス監視機能を使用する場合には、システム一時テーブルに対する権限を付与する必要があります。 セキュリティ上の問題が起きる可能性があるため、ほとんどのインストールでは、システム一時テーブルに対する権限を sysdba およびデータベース所有者にしか付与しないようになっています(以下で紹介しているのはそれです)。 すべてのユーザーがシステム一時テーブルを閲覧できるようにするには、この例を GRANT TO PUBLIC に変更してください。 特定のユーザーだけに権限を付与したい場合もあるでしょう。そのときにはさらにカスタマイズされたスクリプトが必要になる可能性があります。
-
- システム一時テーブルに対する権限を付与するには、以下のコードをテキスト ファイルに保存し、上記の readmeta.sql と同様に実行してください。
create procedure granttmp as declare variable stmt varchar(1024); declare variable ownername varchar(66); declare variable tablename varchar(66); begin select rdb$owner_name from rdb$relations where rdb$relation_name = 'RDB$RELATIONS' into :ownername; For select rdb$relation_name from rdb$relations where rdb$system_flag>0 and rdb$relation_name starts with 'TMP$' into :tablename do begin stmt = 'grant all on ' || tablename || ' to sysdba'; execute statement stmt; stmt = 'grant all on ' || tablename || ' to ' || ownername; execute statement stmt; end end; execute procedure granttmp; drop procedure granttemp; commit; exit;