回答:
私がそれをするたびに、私たちは2つのパスに行きました...
それから、週末に、あなたは予定された停止を持っています：
私たちのスケジュールでは、データベース担当者は通常、金曜日の午後6時から土曜日の午前10時までバックアップおよび移行スクリプトを実行していました。したがって、私たちの目標は8時間以内に実行することでした（そのうち6回はバックアップでした）。 d利害関係者にリリースされる前に、テストと修正のための時間があります。
利害関係者には事前に時間枠が与えられていたため、時間枠の最初に週末をテスト用に開いておくことがわかっていました。また、ウィンドウの終わり、通常は日曜日の午後に通知され、誰もがサインオフしなかった場合、ロールバックを開始する必要があります。
ああ、もちろん...受け入れテストのいずれかで誰かが変更を加え、変更を加えた場合、利害関係者のサインオフはすべて無効になり、再テストが必要になりました...一度に1つずつ適用するのではなく、問題を探して修正をバッチとして実行するために、しばらくそれらを提供するようにします。
幸いなことに、ダウンタイムを大幅に減らすことができない状況の1つになったのは、移行するシステムがユーザー入力ではなくスクリプトから供給されていたため、2つの並列システムを実行して、それらを交換することでした。物事がサインオフされたとき。（問題が発生したのは一度だけで、上司が私たちが完全なバックアップを取ると主張したとき、全体が別のIPでまだオンラインになっていることを理解していなかったので...悪い日は5時間の停止になりました。）
それはすべて、データベースをサポートするハードウェアの能力とシステムの可用性に関する合意と比較したデータ量に依存します。ダウンタイムが発生しますか、それともすべてオンラインで行う必要がありますか？データのクリーニングを開始し、古くなった行を可能な限り消去します。これは、それ自体のプロジェクトです。データがクリーンで価値がある場合は、ユーザーにダウンタイムを決定してもらいます。ダウンタイムが利用可能な場合、既存のデータに適用して更新されたコレクションを形成する必要がある既知の変換であれば、かなり簡単です。ダウンタイムがまったくない、またはほとんどない場合、チャレンジが開始されます。Oracleは、オンラインのテーブル再定義や11gの新機能、エディションベースの再定義など、いくつかの方法でこれをサポートしています。オンラインの表の再定義を使用すると、表を準備して新しい形式にすることができます。これは、アプリケーションが古い形式のテーブルで実行されているときに実行できます。すべての準備が整ったら、新しい形式のテーブルに切り替えることができます。これは、新しいアプリケーションコードを導入する瞬間でもあり、同時に新しいアプリケーションを配置するために必要なダウンタイムの始まりを示します。Oracle Golden Gateなどのツールを使用して、ライブデータを移行する前に古い履歴データを準備し、同期を保つことができます。このようなシナリオでは、古いデータベースの役割を引き継ぐ新しいデータベースを効果的に構築します。エディションベースの再定義は、テーブルの変更が不要な場合に適しています。考慮すべきオプションは山ほどありますが、常に機能する良いルールを与えるのは難しいと思います。これは、新しいアプリケーションコードを導入する瞬間でもあり、同時に新しいアプリケーションを配置するために必要なダウンタイムの始まりを示します。Oracle Golden Gateなどのツールを使用して、ライブデータを移行する前に古い履歴データを準備し、同期を保つことができます。このようなシナリオでは、古いデータベースの役割を引き継ぐ新しいデータベースを効果的に構築します。エディションベースの再定義は、テーブルの変更が不要な場合に適しています。考慮すべきオプションは山ほどありますが、常に機能する良いルールを与えるのは難しいと思います。これは、新しいアプリケーションコードを導入する瞬間でもあり、同時に新しいアプリケーションを配置するために必要なダウンタイムの始まりを示します。Oracle Golden Gateなどのツールを使用して、ライブデータを移行する前に古い履歴データを準備し、同期を保つことができます。このようなシナリオでは、古いデータベースの役割を引き継ぐ新しいデータベースを効果的に構築します。エディションベースの再定義は、テーブルの変更が不要な場合に適しています。考慮すべきオプションは山ほどありますが、常に機能する良いルールを与えるのは難しいと思います。Oracle Golden Gateなどのツールを使用して、ライブデータを移行する前に古い履歴データを準備し、同期を保つことができます。このようなシナリオでは、古いデータベースの役割を引き継ぐ新しいデータベースを効果的に構築します。エディションベースの再定義は、テーブルの変更が不要な場合に適しています。考慮すべきオプションは山ほどありますが、常に機能する良いルールを与えるのは難しいと思います。Oracle Golden Gateなどのツールを使用して、ライブデータを移行する前に古い履歴データを準備し、同期を保つことができます。このようなシナリオでは、古いデータベースの役割を引き継ぐ新しいデータベースを効果的に構築します。エディションベースの再定義は、テーブルの変更が不要な場合に適しています。考慮すべきオプションは山ほどありますが、常に機能する良いルールを与えるのは難しいと思います。
興味深いテーマです、ロナルド。
これまでのところ良い答えです。考慮すべき点をさらにいくつか追加します。
まず、単純なSQL DMLを使用して移行を実行できる場合、SQLエンジンに大きく依存して、すべての行が正常に処理されることを確認できます。ただし、移行には多少複雑で、データの新しい構造への移行に伴い実際のデータ変換が行われた移行にも関わってきました。これらの場合、次の項目を処理できるプロセスがあることが重要です。
私が付け加える他のポイントは、物事が計画通りに進まない場合/いつ行うかについて計画を立てることが重要だということです。これは展開全体の実際の機能ですが、頻繁に見直されているように思えるので、言及する価値があると思いました。
方法の概要
で開始する
次に、Red Gate CompareツールまたはEmbarcadero SQL Change managerのようなものをダウンロードします。それなしでは簡単に移行できません。コストは、節約される時間の量に対して些細なものです。そして最も重要なのは、生成されたスクリプトが単一のトランザクションで変更を加えることで、クリーンな展開を意味します
さて、
これで、いつでも適用できる安全でテスト済みの変更およびロールバックスクリプトができました。
そしてもちろん、統計的にたわごとは常に最終的に発生するため、変更前にデータベースをバックアップします。
Red Gateツールは、ソース管理下にあるフォルダーと比較することもできます。次に、実際の変更スクリプトとは別に、ソース管理でALTERなどをキャプチャします。