質問

私たちは、Informix データベースの 1 つをテスト サーバーに複製しようとしていますが、社内に Informix の専門知識がなければ、何をすべきかを推測することしかできません。私自身、このことを臨機応変に学んでいますが、Informix を効率的に、あるいは非効率的に運用するために必要な専門知識レベルには程遠いです。とにかく...ライブサーバーのどこかから .dat ファイルと .idx ファイルをコピーすることに成功しました。Linux と最新の Informix Dynamic Server をインストールし、稼働させます。

さて、ライブサーバーからの .dat ファイルと idx ファイルをどうすればよいでしょうか?どこかにコピーすれば自動的に認識されるのでしょうか?

それとも、MS SQLServerからDBを接続してデータベースファイルを新しいデータベースに登録できるような同等の方法はありますか?

私のロープの端には...

役に立ちましたか?

解決

あなたは気づかないうちにかなり複雑な質問をしてしまいました。Informix は、すべてを共有するデータベース エンジンとして設計されており、インスタンスで利用可能なすべてのリソースが、そのインスタンス内のすべてのデータベースで利用できることを意味します。これは、複数のデータベースが特定の DB 領域、.dat、または .idx ファイルにデータを保存できることを意味します。ほとんどの DBA はそれを行うべきではないことを知っていますが、これは注意が必要です。この知識があれば、.dat ファイルと .idx ファイルはデータベースに属さず、インスタンスに属していることがわかります。DB 領域とファイルはデータベース データを含めるために作成されましたが、技術的にはインスタンスに属します。.dat ファイルと .idx ファイルは論理 DB 領域名によってデータベースに認識されることに注意してください。

このような背景情報を踏まえ、本番サーバーと開発サーバーが同じ OS を実行しており、ハードウェアが PARISC、Itanium、x86/x64 の組み合わせではなく比較的同じであると仮定して、いくつかのオプションを提示します。 。

  1. 新しいインスタンスで必要なDBSPACESを作成し、OnunloadとOnloadを使用して、生産から開発までデータベースをコピーします。
  2. ONTAPEまたはONBARを使用して、生産インスタンス全体をバックアップし、開発インスタンスに復元します。

オプション 1 では、DB 領域の名前とそのサイズを知っている必要があります。使用 onstat -d 本番インスタンスでこれを確認してください。ところで、onstat -d にリストされている数字はページ単位であり、Linux は 2K ページだと思います。

オプション 2 では、データ ファイルのパスが両方のサーバーで同じであることが必要です。これは、ROOTDBS が両方のインスタンスで同じである必要があることを意味します。それは実行することで見つけることができます onstat -c | grep ROOTDBS

省略されている部分はたくさんありますが、タスクを進めるために必要な情報が得られることを願っています。

他のヒント

.dat および .idx ファイルは C-ISAM に関連付けられます。また、dbase.dbs (dbase はデータベースの名前です) というディレクトリに編成されている場合、.dat および .idx ファイルは Informix Standard Engine に関連付けられます。別名Informix SE。SE は C-ISAM を使用してストレージを管理します。SE は Informix Dynamic Server (IDS) とはかなり異なります (そして、Informix Dynamic Server (IDS) よりもはるかに単純です)。.dat ファイルと .idx ファイルが IDS に関連付けられることは不可能ではありません。それは非常に可能性が低いだけです。

入手可能な情報によると、運用サーバーは SE を実行しているようです。SE から IDS にデータを取得するには、SE 側で DB-Export を使用し、Linux/IDS 側で DB-Import を使用することになるでしょう。確かに、それが最も簡単な方法です。

他にも考えられる解決策はありますが、C-ISAM データブレードもその 1 つです。しかし、それらはより高価であり、おそらく保証されません。HPL (High-Performance Loader) など、他のロード ソリューションも考えられます。

Informix の詳細については、すでに参照されているさまざまな Web サイト (http://www.informix.com は IBM の Web サイトの Informix セクションへのリンクです)、または 国際 Informix ユーザー グループ (IIUG) Webサイト。Informix について詳しく議論するために利用できるメーリング リスト (所属する必要がありますが、メンバーシップは無料です) があります。

これらの Informix-SE データ ファイル (.DAT) とそれに関連するインデックス ファイル (.IDX) は、SYSTABLES.DAT、SYSTABLES.IDX、SYSCOLUMNS、SYSINDEXES などのすべての関連するカタログ ファイルがなければ役に立ちません。

また、インデックス ファイル ノード サイズが 2K または 4K のものもあるため、Informix-SE のどのバージョンがそれらを作成したかについても考慮する必要があります。

最善の方法は、ソース データベースからすべての .DAT ファイルと .IDX ファイルを取得し、元の同じハードウェアとオペレーティング システムにインストールされている正しい標準エンジンを取得することです。

簡単に言うと、ソース マシンで「dbexport」を実行してすべてのデータを ASCII ファイルにアンロードし、「dbschema」を実行してすべてのテーブル スキーマとインデックスを生成します。また、ファイルを ASCII フラット ファイルにアンロードする前に、すべてのファイルに対して「bcheck」を実行しても問題ありません。

Informix 固有のアドバイスはありませんが、このような状況の場合は、通常、データベースの移動方法 (一般的な管理タスクであり、通常はマニュアルに詳しく説明されています) を調べて、必要な手順をスキップすることで答えを見つけることができます。古いデータベースを削除します。

また、システム アーキテクチャの違いによって引き起こされる問題にも注意してください。一部の DB は、ビッグエンディアン システム (Solaris など) からリトル エンディアン システム (x86 Linux など) に移動すると、見事に失敗します。繰り返しになりますが、DB の移動に関するマニュアルのセクションでは、必要な追加手順について説明します。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top