どなたでも歓迎します。 私は、地域の電気通信事業者の課金システム開発部門の代表です。 Oracleをバージョン12c（12.2.0.1）にアップグレードした経験を共有したい
（何らかの理由で、多くの場合、アップグレードプロセスと移行を混同します。ここでは 、いつ、どのような場合に1つまたは別の値を使用するかを明確に記述しています）。 すべてのイベントは昨年行われました。
組織活動
年の初めから、組織の準備作業が始まりました。まず、テストゾーンを展開する必要がありました。 いいえ、テストゾーンがあり、SUSEの下でOracleのみが展開されました。 そして、産業環境では、OracleはIA-64プラットフォームとOSとしてHP-UXを備えたサーバーにインストールされますが、HP-UXを仮想環境に展開することが課題であることが判明しました-HP-UXはゲストOSとして1つのVMのみをサポートします-Integrity仮想マシン。同じアーキテクチャのサーバーにインストールする必要があります。 その結果、本番環境のstandby-dbサーバーで作業することにしました。
2番目のステップは、HP-UX OSのセットアップでした（ Oracleの推奨どおり ）。 HP-UXには「テストゾーン」もTPも存在しないことを考慮して、リスクを考慮してこの作業を行うHP-UXスペシャリストを探し始めました。 おなじみの専門家の中には、HPのマネージャーに電話をかけ始める人はいませんでした。 もちろん、マネージャーとの対話は、テクニカルサポートの獲得に限定されました。そうでなければ、何も話すことはありません。
前回5年ほど前にHPテクニカルサポート（ハードウェアとソフトウェア）のコスト計算を実行しました。 興味のために、TPのコストの評価を要求しました。 提供された費用で、小規模なデータセンターを展開し、さらに3年間すべてのテクニカルサポートを提供できるため、購入の問題はなくなりました。
ソフトウェアのテクニカルサポートのみのオプションを検討し、作業期間中のTPを制限し、テストゾーンとしてItaniumの使用済みサーバーのシステムインテグレーターを検索しましたが、まったく役に立ちませんでした。
その結果、請求プロバイダーの専門家が応答しました。
前述のように、standby-dbサーバーでOS設定が行われました。 Oracle自体は、SUSEのテストゾーンで更新されました。 すべてが順調に進みました。 その結果に勇気づけられて、私たちは10月24日から25日の夜に工業地帯での更新を計画しました。次の営業日の初めまでに、すべてが機能するはずだったということを考慮に入れました。
アップグレードプロセスの準備
10月24日の午後に、DBAから送られた準備とともに準備を始めました。
必要なパラメータが設定され、異常なバックアップが構成され、いくつかの「重い」テーブルがクリアされました。 次に、サービス、ビジネスプロセス、ジョブなどを停止します。 一般に、準備にはほぼ1日かかり、更新プロセス自体は約12泊で始まり、午前4時に終了しました。 彼らがすべてを逆の順序で実行し始めた後、午前6時頃、私たちはすでに精神的に家にいて、寝る準備ができていましたが、そこにはありませんでした。 アプリケーションサーバーを除くすべてのサービスが開始されました。 Oracle Client（10）のバージョンがサーバーのバージョンより低いため、クライアント部分が有効なバージョンより下にあるすべてのサーバーを更新する必要があるため、彼のサービスは開始を拒否することがわかりました。 更新済み-獲得済み。
それは問題のほんの小さなものであることが判明しました。 ビジネスプロセスのヘルスチェック中。 サブスクライバープロファイルサーバーの機能が侵害されていることがわかりました。 特定のデータにアクセスすると、ORA-00600エラー[qmcxdGetQNameInfo2]がポップアップ表示されましたが、これが実際には問題の原因でした。 「重大度2」のステータスでOracleをサポートするサービスリクエスト（SR）を開き、同時に、問題の可能な解決策を検索しました。 状況は、サブスクライバーもサービスも登録できないという事実によって悪化しました。カスタマーサービスシステム（SBMS）は、サブスクライバーの登録時にプロファイルを作成できず、CRMも機能しませんでした。
夕方までに、負荷は収まり、状況は正常に戻りました。 さらに、問題の解決策もあります。 タイプXMLのフィールドにアクセスするときにのみエラーが発生することがわかりました。 同時に、XDBコンポーネント（Oracle XML DB）自体も有効でした。 Database Upgrade Guideのバージョン12.2にあるように、COMPATIBLEパラメーターを12.2に設定することが決定されましたが、その時点ではまだ11.2 でした ： アップグレードの準備ができるまでこの変更を行わないでください。 COMPATIBLE初期化パラメータ値を上げた後、互換性レベルは使用できません 。 つまり このパラメーターを適切な値に設定すると、以前のバージョンに戻すことはできなくなります。 ただし、別のOracle文書（Doc ID 1292089.1）には次の注釈があります。... upgradeoperationの後、データベースの互換性を少なくとも12.10.1に設定する必要があります。 互換性が12.1.0.1未満の場合、Oracle XML DBを使用しようとするとエラーが発生します。 したがって、ダウングレードの機会を犠牲にして状況を修正しようとすることにしました。 しかし、判明したように、この決定は結果をもたらしませんでした。 その後、睡眠不足が影響するため、朝まで問題の解決を延期し、毎時間考えることはより困難でした。 さらに、Oracleサポートからの応答を待つ必要がありました。
主な問題の解決策（バグ26814058）
10月26日の朝、Oracleから、次のような問題を特定する応答を受け取りました。 未公開のバグ 9月16日）、および以前のバージョン（12.1）でも。 その時点で（そして、おそらく現在のもののために）彼のためにパッチも回避策も存在しませんでした。 ステータス11は、パッチの作業が進行中であることを示しますが、同時に、Oracleからパッチをリリースする正確なスケジュールはありません。たとえ数日でリリースされてもです。 SRのレベルを「重大度1」に上げましたが、Oracleからの迅速な解決策の希望はありませんでした。 決定を下す必要がありました-バージョン11に戻るか、修正を試みてください。
カスタマーサービスの影響を受けない2日目。COMPATIBLEパラメーターのために標準のダウングレード手順を使用して戻ることができないため、夜を待って、standby-dbサーバーを使用してバージョン11にロールバックすることにしました。 テーブルを調べて分析した結果、サービスの大部分が機能しなかったことが判明しましたが、それらはすべてプロファイルサーバー（GUP）に関連付けられていました。 さらに、問題を2つの問題テーブルにローカライズすることができました。 そのうちの1つは、1,000万個以上含まれているため、特に困難でした。 レコード（約4GB）。 このエラーは、XML TYPEタイプのフィールドのデータを処理しようとしたときと、テーブルデータをエクスポートしようとしたときに発生しました。 「テーブルを作成...選択...として」操作は成功しましたが、結果が得られず、新しいテーブルのデータも破損していることが判明しました。
「更新前」状態のデータポンプを使用して、standby-dbサーバーからデータを抽出しようとすることにしました。 しかし、そこのデータも破損していることが判明しました。 実際、アップグレードの準備では、Oracleの推奨事項に従ってXDBを再構築するステップが含まれていました。 おそらく、この特定の操作の結果としてXML TYPE列のデータが破損します。これは、Oracle 12.2へのアップグレード時に偶然にも直接発生します。バージョン12からXDBコンポーネントが必須になり、再インストールができなくなったためです。 ただし、更新命令では更新時にすべてのデータベースコンポーネントが有効である必要があり、そうでない場合は再インストールする必要があるため、1日の終わりには問題は完全なテーブルデータを取得できる可能性を見つけることになりました。
おわりに
最も重要な瞬間、すべてのオプションを試したが何も助けなかったとき、私たちは10月24日の更新開始前に同僚が行ったstandby-dbサーバーからのバックアップによって救われました。 RMANを使用して、「XDBを再構築する前」の時点でスタンバイDBを部分的に（必要な表スペースのみ）復元し、必要なデータを抽出することができました。 その後、DATA PUMPを使用して、問題のテーブルがスタンバイからmain-dbサーバーにエクスポートされました。 この操作は、10月27日の午前2時頃に完了しました。 その後、GUPサーバーの機能が復元されました。 復元されたテーブルのデータは時間の経過とともに古くなっているという事実にもかかわらず、破損したデータを処理するすべての試みが失敗したため、テーブルは関連していました。 すなわち 実際、データベースは読み取り専用状態であり、そのデータベース内のデータは「更新前」の時点から変更されていません。
テストゾーンがあった場合、アップグレードの準備でこの問題を特定できたかもしれませんが、OracleはBUGを「コード/ハードウェアバグ」として分類したため、Oracleバージョンとユーザーデータだけでなく、プラットフォームとバージョンでも一致する必要がありましたOS、これは不可能でした。
バックアップすることを忘れないでください、みんなに幸運を。