データウェアハウス-DB2 to SQL Server：ETLにどのように＆何が影響しますか？
IBM DB2データベースからSQL Serverへの移行に取り組んでいますが、DB2データベースはデータウェアハウス環境にあります。
さまざまな種類のデータベース間のデータウェアハウジング、DB2、およびDB移行に非常に慣れていないので、これに最善のアプローチをとり、関連するコンポーネントを理解する方法について質問したいと思います（他の場所にリストまたはリンクするのは問題ありません。物事や何か新しいことを学ぶ）。
コンテキスト：
- 使用中のETLツール、および使用を継続するETLツールはInformaticaです
- DBを照会する唯一のアプリケーションはCognosです。
- 2つの（Windows以外の）ホストで4つのDB2 DBが使用されています。そのうちの1つは「H1」で、データウェアハウスの一部として「DB2-DW-PROD」DBが使用されています。
- 「DB2-DW-PROD」DBを既存の（Windows）SQL Serverホスト「H2」上にある「SQL-DW-PROD」という名前のスペースに移行したいと思っています。このホストには現在、他の目的で（1つのインスタンスで）複数のDBがあり、必要に応じてSSRS/SSISまたは他のサービス/リソースをインストールまたは構成できます。
- 過去2年間に使用/更新されていないものに基づいて、可能であれば、移行中にメンテナンスが不十分なDBを少しクリーンアップしたいと思います。
直接的または間接的に知りたいこと：
- H2に新しいインスタンスを作成する必要がありますか、それとも単一の新しいデータベースで十分ですか？
- 新しいインスタンス/ DBには特定のリソースが必要ですか？もしそうなら、どこから？
- 必要なデータを取得するには、特定のMicrosoftツールを使用する必要がありますか、それとも何らかのタイプのインポート/エクスポートを使用する必要がありますか？ （このプロセスにはInformaticaが関与していますか？）
- 誰かがInformaticaやCognosの「メタデータテーブル」に言及しましたが、何か注意する必要がありますか？
- 別の言及されたシーケンス値の維持-これはどのようにして最良に達成されますか必要ですか？
- Informatica側での変更は私の個人的な関心事ではなく、別の人の仕事です。そのため、この人に提供する必要があるものはありますか（新しいdbのアドレスは別として）？
私はこの分野で非常に新しいので、馬鹿げたことは大歓迎です。そうは言っても、複雑であるが知っておく必要がある、または良いことも同様です。それは私にとって急な学習曲線ですが、私は今のところ困惑しており、手を必要としています。
私はプロセスを制御できません-InformaticaとCognosはそのまま維持する必要があります。また、この段階ではDB2 DBを表示できませんが、大きすぎないことはわかっています。ほとんどの場合、この質問では1 TBであると想定しています。
現時点では、私がたどるプロセスと、その時が来たら何に注意する必要があるかを理解しようとしています。
編集：私は非常に感謝している質問のインスタンスとデータベースの部分についてたくさんのフィードバックを受けました。ただし、データの移行をどのように実行するかについては、まだ混乱しています。つまり「Informaticaとcognosをサポートするために必要なすべてのものが揃うように移行するには、どのように、または何を使用すればよいですか？」
最も差し迫った問題は、私がinformatica/cognosの依存関係を理解していないか、db2がどのように機能するかを知らないことです。ユーザーテーブルデータを単にコピーするだけで十分であり、確認やポインタで何をすべきかを正確に把握したいのではないかと思います。
1つはハードウェアリソースです。現在のサーバーは、一定量のメモリ、CPU、およびIOを使用してジョブを実行します。1TBのデータベースの場合、これは簡単ではない可能性があります。その作業を新しいサーバーに移動すると同じ量のメモリ、CPU、IOPSが必要になります（新しいサーバーがすでにアプリケーションをホストしていて、それらのニーズに対応している場合）、移行したアプリケーションの新しいニーズにも対応できる容量がない可能性があります。結果：すべてがゆっくりと実行され、悲しみがたくさんあります。
DW作業は、大きな順次読み取りを使用する傾向があります。 OLTP通常、作業には小さなランダムIOがあります。これら2つを1つのハードウェアボックスに混在させる場合、どちらかで最高のパフォーマンスが得られるようにストレージ（SANアレイ？）を構成するのは難しいかもしれません。両方のための。
SQL Serverの各インスタンスには、tempdbや最小メモリなどの固定オーバーヘッドがあります。 1つのボックスにあるインスタンスが多いほど、より多くのオーバーヘッドを支払う必要があります。また、ピーク負荷に対応するために、各インスタンスにリソースを過剰に割り当てる必要があり、コストが高くなります。すべてが1つのインスタンスにあるため、このコストを分散できます。反対に、同じインスタンスで貪欲なタスクから通常の作業を分離するのはより多くの作業になる可能性がありますが、 不可能ではない です。この決定は、コンサルタント契約であり、Q＆Aの投稿ではありません。