sql >> データベース >  >> RDS >> Oracle

adopフェーズで何が起こるか

    Adopフェーズの準備は、R12.2のオンラインパッチ適用サイクルの最初のフェーズです。 Adopは、フェーズで多くのアクションアイテムを実行します。アクティビティのシーケンスは次のとおりです。
    1。クリーンアップを実行するかどうかを確認します。これは、前のオンラインパッチ適用サイクルのカットオーバーフェーズ後にユーザーがクリーンアップを呼び出せなかった場合に必要になります。 。

    2.システム構成を検証して、システムがオンラインパッチ適用サイクルを開始する準備ができていることを確認します。

    3.データベースがオンラインパッチの準備ができているかどうかを確認します

    a)データベースユーザーがエディション対応かどうかを確認します。そうでない場合、adopはすぐにエラーで終了します。

    b)パッチサービスが作成されているかどうかを確認します。 adopでは、パッチエディションに接続するために特別なデータベースサービスが存在する必要があります。このサービスは自動的に作成されますが、その継続的な存在は各準備で検証されます。

    c)ログオントリガーが存在し、有効になっているかどうかを確認します。ログオントリガーがないか、パッチサービスが作成されていない場合、adopは問題を自動的に修正して続行できるようにします。それができない場合は、エラーメッセージが表示されて終了します。

    d)データベースデータディクショナリの整合性をチェックします。破損が見つかった場合、adopはエラーイーズ12.2で終了します。

    e)E-Business Suiteテクノロジーコードレベルチェッカー(ETCC)が実行されていることを確認し、必要なすべてのパッチがデータベースに適用されていることを確認します。
    4.各アプリケーション層ノードのシステム構成を確認します。各アプリケーション層ノードが正しく登録、構成され、パッチを適用する準備ができていることを確認するために、いくつかの重要な設定が検証されます。

    TXKスクリプト$AD_TOP / patch / 115 / bin / txkADOPPreparePhaseSanityCheck.pl を使用して、ファイルシステムをチェックします 。このスクリプトは、ファイルシステムスペース、データベース接続、Apps / System / Weblogicパスワード、Contextfile検証などをチェックします。
    また、生成された最も重要なテーブルスペースに関する情報を示すレポートを生成します。このレポートは$APPL_TOP/ admin / $ TWO_TASK/outで作成されます。
    5.「進行中のオンラインパッチ適用」(ADZDPATCH)の存在を確認します。 並行プログラム。このプログラムは、特定の事前定義された並行プログラムが開始されないようにするため、パッチ適用サイクルの進行中(つまり、データベースパッチエディションが存在する間)にアクティブにする必要があります。

    プロセスの流れは

    a。ADZDPATCHプログラムの実行がまだ要求されていない場合は、要求が送信されます。存在しない場合は、以下のエラーが報告されます
    1行目のエラー

    ORA-20008:並行プログラムを実行できる並行マネージャが定義されていません

    ADZDPATCH

    b。ADZDPATCHのステータスが決定されます。保留中の場合は、互換性のないプログラムが終了するのを待っている可能性があります。非互換性が解消されると、ステータスが実行中に変わり、準備フェーズを続行できるようになります。この旨のメッセージがユーザーに表示されます。
    c。次の段階は、並行マネージャーが実行されているかどうかによって異なります。

    i。コンカレントマネージャーがすべてダウンしている場合、準備フェーズが続行され、マネージャーが開始されるまでADZDPATCHが保留中(最高の優先度)のステータスになります。
    ii。コンカレントマネージャーが部分的にアップしているが、 ADZDPATCHを実行できるマネージャーが定義されていない場合、準備フェーズはエラーで終了します。
    iii。同時マネージャーが稼働していて、ADZDPATCHを実行できるマネージャーが定義されている場合、ADZDPATCHがからステータスを変更するまで処理はループします。実行中です。その後、準備フェーズが続行されます。
    カットオーバーフェーズが完了すると、ADZDPATCHはキャンセルされます。

    カスタムプログラムをパッチ適用サイクルで実行しないようにする場合は、このプログラムとの互換性をなくす必要があります。
    6.TXKスクリプト$AD_TOP/ patch / 115 / bin / txkADOPPreparePhaseSynchronize.plを呼び出して、パッチを同期します。実行APPL_TOPには適用されていますが、パッチAPPL_TOPには適用されていません。スクリプトは、実行APPL_TOPに適用されたパッチのadopリポジトリに依存しますが、パッチAPPL_TOPには依存しません。

    実行APPL_TOPに適用されたパッチを識別し、それらをパッチAPPL_TOPに適用します。次の手順が自動的に実行されます。

    a。パッチAPPL_TOPに適用する必要のあるパッチはデータベースから識別されます。
    b。マージされたパッチはadopユーティリティによって適用されます。
    adopユーティリティは適用されるデルタパッチを識別します。そしてそれらを現在のパッチAPPL_TOPにサイレントに適用します。この手順ではデルタパッチの適用のみが必要なため、必要な時間は短くなります

    状況によっては、一連のパッチをパッチエディションに適用するときに、デルタスタイル(インクリメンタル)の同期方法が失敗する場合があります。これは、前のパッチ適用サイクルに正しく適用できなかったパッチが含まれ、その後に問題を修正した後続のパッチが含まれている場合に発生する可能性があります。

    skipsyncerrorパラメーターを使用すると、準備フェーズでの同期エラーが、後続のパッチで行われる同期で自動的に修正されることを期待するように指定できます。

    パラメータの値が「yes」として渡された場合、同期される最初のパッチは「autoskip」フラグが設定された状態で実行されます。
    重要:ログファイルを確認し、エラーを修正するのはユーザーの責任です。後続の適用フェーズ、または後続のパッチとの同期によって問題が解決したことを確認します。
    このパラメーターの使用例は次のとおりです。

    a。adopphase=prepareを実行します。
    b。実行ファイルシステムとパッチファイルシステムを同期しようとすると、フェーズがエラーで失敗します。つまり、パッチの同期の試みは失敗しますが、後続のパッチで問題が修正されることがわかっています。
    c。ログファイルを調べて、同期エラーは次の同期で自動的に修正されると結論付けます。後続のパッチを配置します。
    d。コマンドadopphase=prepare skipsyncerror =yesを実行して、準備フェーズを再開します。今回は、前回の準備で失敗したパッチの適用を、「autoskip」フラグを設定して再試行します。
    カスタマイズの同期

    ファイルシステム同期のデフォルトのデルタスタイル(インクリメンタル)方式は、公式パッチを処理しますが、手動で適用されたカスタマイズは同期しません。デフォルトで同期されないパッチ適用アクションの例は次のとおりです。

    ユーザー定義のJSPのコンパイル

    一部のサードパーティライブラリをコピーする

    ユーザー定義の並行プログラムのコピーとコンパイル

    ユーザー定義フォームのコピーと生成
    デフォルトのファイルシステム同期にカスタムパッチアクションを含めるには、カスタム同期ドライバー $ APPL_TOP_NE / ad / custom /adop_sync.drv 。ファイルの次のセクションにカスタマイズを追加します。
    #BeginCustomization

    #EndCustomization

    このファイルで定義されているすべてのアクションは、準備フェーズ中にadopによって自動的に実行されます。 adop_sync.drvには、2つのカテゴリのカスタムコマンドがあることに注意してください。1回だけ実行されるものと、各ファイルシステムの同期(adop準備フェーズ中)で実行されるものです。
    重要:adop_sync。 drvファイルは現在、どの時点でもテンプレートファイルにリセットされていません。したがって、カットオーバー後(および次の準備フェーズの前)に、adop_sync.drvの内容を確認し、カスタムコマンドの要件が引き続き満たされていることを確認する必要があります。
    7。データベースにパッチが存在するかどうかを確認します。エディションを作成し、見つからない場合は作成します。

    a)パッチエディションがデータベースに作成されます。
    b)パッチエディションのすべてのコードオブジェクトは、実行エディションのコードオブジェクトへのポインタとして始まります。パッチエディションのコードオブジェクトは、以前のエディションから継承された実際のオブジェクト定義を指す軽量の「スタブオブジェクト」として始まります。スタブオブジェクトは最小限のスペースしか消費しないため、データベースパッチエディションのサイズは最初は非常に小さくなります。
    c)パッチがパッチエディションに適用されると、そのエディションでコードオブジェクトが実現されます(新しい定義が作成されます)。

    8. $ AD_TOP / patch / 115 / bin / txkADOPPreparePhaseSanityCheck.plスクリプトを再度呼び出して、パッチエディションへのデータベース接続が機能していることを確認します。

    関連記事

    R12.2で説明されているAdop

    R12.2オンラインパッチングサイクルの概要


    1. AzureでSQLServerを使い始める方法

    2. SQLビュー:SQLでビューを操作する方法は?

    3. SQLでは、範囲内でどのようにグループ化できますか?

    4. Kubernetes AWSでのJenkinsの使用、パート2