| Oracle® Databaseアップグレード・ガイド 12cリリース1 (12.1) B71306-08 |
|
 前 |
 次 |
最小の停止時間でOracle Databaseをアップグレードし、新しいリリースにアプリケーションを移行するための包括的なツールのセットが提供されています。
この章の内容は次のとおりです。
|
注意: 古いOracleソフトウェアを保持している場合、古いソフトウェアを使用してアップグレードしたデータベースを起動しないでください。新しいOracle Databaseインストールの実行可能ファイルでのみデータベースを起動してください。 |
Oracle Database 12c以上では、マルチテナント・アーキテクチャは、Oracle Databaseをプラガブル・データベースを含むマルチテナント・コンテナ・データベース(CDB)として機能させることができます。Oracle Database 12cより前のすべてのOracle Databaseリリースは、非CDBでした。マルチテナント・アーキテクチャの概要については、『Oracle Database概要』を参照してください。
このリリースでは、アップグレードに関する多くの計画が提供されています。以前のリリースをOracle Database 12cにアップグレードした後で、「以前のリリースのアップグレードおよびCDBへのPDBの接続」の説明に従って、アップグレードされたデータベースをCDBに接続できます。
|
重要: COMPATIBLE初期化パラメータを12.1.0.2に設定すると、データベースをダウングレードできません。互換性が12.1.0.1に設定されている場合のみ、プラガブル・データベース(PDB)に対するダウングレードが可能になりますが、ダウングレードに関する制約がある可能性があります。第6章「以前のリリースへのOracle Databaseのダウングレード」を参照してください。 |
この項には次のトピックが含まれます:
|
関連項目: CDBの作成および構成に関する詳細は、『Oracle Database管理ガイド』を参照し、マルチテナント・アーキテクチャの概要については、『Oracle Database概要』を参照してください。 |
非CDBのOracle Databaseでは、マルチテナント・アーキテクチャが使用されず、プラガブル・データベース(PDB)が含まれていません。Oracle Database Upgrade Assistant (DBUA)を使用するか、または手動で、データベースをアップグレードできます。「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」または「非CDBのOracle Databaseの手動でのアップグレード」の手順に従います。
DBUAまたはパラレル・アップグレード・ユーティリティのいずれかを使用してOracle Databaseの以前のリリースをアップグレードした後、アップグレードしたデータベースをマルチテナント・コンテナ・データベース(CDB)に接続できます。アップグレードされたリリース12.1データベースは、既存のCDBに接続できます。第2章「Oracle Databaseのアップグレードの準備」で説明している必要なアップグレード前手順を実行するようにしてください。次の手順では、両方のデータベースが同じシステム上にあると想定しています。
|
関連項目: SQL*Plusを使用したPDBの作成および削除の詳細は『Oracle Database管理者ガイド』、異なる要因を含む様々なシナリオの例は『Oracle Database管理者ガイド』を参照してください。 |
データベースをアップグレードしてCDBに接続するには、次の手順を実行します。
新しいOracle Database 12cソフトウェアをインストールします。ご使用のオペレーティング・システム・プラットフォームの『Oracle Databaseインストレーション・ガイド』を参照してください。
このガイドの説明に従ってデータベースをアップグレードします。第3章「Oracle Databaseのアップグレード」を参照してください。
COMPATIBLEパラメータを12.0.0に設定します(アップグレード・プロセスでそのように設定していない場合)。「Oracle DatabaseのCOMPATIBLE初期化パラメータ」を参照してください。
データベースが読取り専用モードであることを確認します。
SQL> startup mount SQL> alter database open read only;
切断されたPDBを接続するための前提条件を満たしていることを確認します。これらの要件が満たされているかどうかを判断するためにDBMS_PDB.CHECK_PLUG_COMPATIBILITYファンクションを使用する方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
PDB用のXMLファイルを作成します。XMLファイルのルート名は、PDBの名前に一致させます。場所のpathは任意に指定できます。この場所は、XMLファイルが保存される場所です。
SQL> exec DBMS_PDB.DESCRIBE('path/PDB1.xml');
データベースを停止します。
SQL> SHUTDOWN IMMEDIATE
データベースをCDBに接続します。
SQL> CREATE PLUGGABLE DATABASE PDB1 USING 'path/PDB1.xml' NOCOPY TEMPFILE REUSE;
この例では、PDBにはPDB1という名前が付いています。任意の名前を使用できますが、名前はそのCDBで一意である必要があります。
また、この例では、データファイルはデータベースがスタンドアロンであったときと同じ場所にそのまま残ると想定しています。データファイルを別の場所にコピーした場合(Oracle ASMとともに格納している場合など)、パラメータSOURCE_FILE_NAME_CONVERTを指定する必要があります。SOURCE_FILE_NAME_CONVERT句を使用する例については、『Oracle Database管理者ガイド』を参照してください。
TEMPFILE REUSEは、既存のTEMP表領域を再利用できることを指定します。
「プラガブル・データベースが作成されました。」と表示され、これで、アップグレードされたデータベースは、CDB用として準備ができたPDBになります。
構成済のリスナーを使用してPDBに接続します。この例のPDBの名前はPDB1です。
SQL> sys/oracle@PDB1 as sysdba
かわりに、次のようにPDBに接続することもできます。
SQL> ALTER SESSION set container=PDB1;
ディクショナリをPDBタイプに変換します。adminディレクトリからnoncdb_to_pdb.sqlスクリプトを実行します。このスクリプトは、PDBを初めてオープンする前に実行する必要があります。
@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
新しいPDBを起動し、読取り/書込みモードでオープンします。Oracle Databaseで新しいPDBをCDBに統合するには、PDBを読取り/書込みモードでオープンする必要があります。STARTUP SQL*PlusコマンドでのPDBのオープン・モード変更の詳細は、『Oracle Database管理者ガイド』を参照してください。
SQL> STARTUP PLUGGABLE DATABASE PDB1 OPEN;
PDBをバックアップします。PDBのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
Oracle Database 12c以上では、プラガブル・データベース(PDB)の作成および管理を行うことができるマルチテナント・アーキテクチャが提供されます。非CDBデータベースのように、Oracle Database Upgrade Assistant (DBUA)を使用するか、または手動で、CDBをアップグレードできます。「Oracle Database Upgrade Assistant (DBUA)を使用したアップグレード」または「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」の手順に従います。
CDBには、0(ゼロ)、1またはそれ以上のプラガブル・データベース(PDB)を含めることができます。CDB全体をアップグレードせずに、1つのPDBをアップグレードできます。たとえば、リリース12.1.0.1のCDBからPDBを切断し、リリース12.1.0.2のCDBに接続した後、そのPDBをリリース12.1.0.2にアップグレードできます。DBUAを使用してPDBをアップグレードすることはできません。そのため、手動でPDBをアップグレードできます。この項の手順に従い、詳細は、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」を参照してください。
|
注意: PDBは、バックアップしないとリカバリできません。CDBを作成してデータベースに接続する方法でアップグレードした後は、必ずPDBをバックアップしてください。PDBのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
この手順では、リリース12.1.0.2にアップグレードする必要のあるPDBを準備します。
リリース12.1.0.1環境で、アップグレードするPDBに切り替えます。たとえば、PDB1の場合は次のようになります。
SQL> alter session set container=PDB1;
リリース12.1.0.2環境からpreupgradeスクリプトを実行し、修正スクリプトを生成します。
@$ORACLE_HOME_12102/rdbms/admin/preupgrd.sql
preupgrade.logの出力には、修正スクリプトの場所が含まれています。ORACLE_BASEが定義されている場合、ログ・ファイルと修正スクリプトは、ORACLE_BASE/cfgtoollogsの下に作成されます。ORACLE_BASEが定義されていない場合、ファイルはORACLE_BASE/cfgtoollogsではなくORACLE_HOME/cfgtoollogsの下に作成されます。
PDBの出力のみを表示するには、cfgtoollogs/SID/preupgrade/pdbfilesを参照します。PDBファイルは最初にpreupgrade/pdbfilesに書き込まれ、次にcfgtoollogs/SID/preupgradeディレクトリのpreupgrade.log、preupgrade_fixups.sql、およびpostupgrade_fixups.sqlに連結されます。
次のように修正スクリプトを実行します。
@$ORACLE_BASE/cfgtoollogs/CDB1/preupgrade/preupgrade_fixups.sql
|
注意: preupgrade_fixups.sqlを実行する前にPDBに接続しておく必要があります。 |
アップグレード時の停止時間を短縮するには、次のようにオプティマイザ統計を収集します。
SQL> exec dbms_stats.gather_dictionary_stats;
この時点で、preupgrade.logからの追加の推奨事項も適用します。
CDBルート・コンテナに切り替えます。
SQL> alter session set container=CDB$ROOT;
例PDB1のPDBを終了します。
SQL> alter pluggable database PDB1 close;
PDB1を切断し、ステージングすると、12.1.0.2 CDBへの接続が可能になります。完了したらこのCDBを終了します。次に例を示します。
SQL> alter pluggable database PDB1 unplug into '/stage/PDB1.xml'; SQL> exit
この時点で、「PDBの12.1.0.2 CDBへのプラグイン」の説明のとおりスタンドアロンPDBをリリース12.1.0.2 CDBにプラグインする準備ができました。
この手順では、手順1で準備したPDBをリリース12.1.0.2 CDBに接続します。この例では、PDB1というPDBを使用します。リリース12.1.0.2でDBCAを実行したとき、互換性パラメータはデフォルトで12.1.0.2に設定されていました。互換性パラメータを前のリリースに変更してある場合、アップグレードを実行するには、これを12.1.0.2に設定する必要があります。
リリース12.1.0.2 CDBに接続します。
SQL> alter session set container=CDB$ROOT;
ステージングされた12.1.0.1 PDBを使用して12.1.0.2 PDBを作成します。
SQL> create pluggable database PDB1 using '/stage/PDB1.xml'
file_name_convert=('/oradata/CDB1/PDB1', '/oradata/CDB2/PDB1');
|
関連項目: SQL*PlusによるPDBの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
PDBをアップグレード・モードで開きます。
SQL> alter pluggable database PDB1 open upgrade;
SQL*Plusを終了して手順3のPerlスクリプトであるパラレル・アップグレード・ユーティリティを実行します。
SQL> Exit
この手順では、パラレル・アップグレード・ユーティリティと修正スクリプトを実行し、アップグレードを完了します。
コマンド・プロンプトから12.1.0.2 Oracleホームのadminディレクトリに移動します。
cd $ORACLE_HOME/rdbms/admin
パラレル・アップグレード・ユーティリティcatctl.plを実行します。通常catctl.plで使用する構文を使用しますが、アップグレードするPDBを指定する場合には、-c PDBnameオプションを使用する必要があります。PDB1を使用しているこの例に示すように、PDBの名前は大文字にします。
$ORACLE_HOME/perl/bin/perl catctl.pl -c "PDB1" -l /home/oracle/upgrade catupgrd.sql
catctl.plの構文の詳細は、「パラレル・アップグレード・ユーティリティ(catctl.pl)のパラメータ」を参照してください。
SQL*Plusにログインし、PDBを開始して必要なスクリプトおよびアップグレード後の修正スクリプトを実行します。
SQL> alter session set container=PDB1; SQL> startup
utlrp.sqlを実行してオブジェクトをコンパイルします。
@?/rdbms/admin/utlrp.sql
アップグレード後の修正スクリプトを実行し、アップグレードを完了します。(PDBに接続していることを確認してください。)
$ORACLE_BASE/cfgtoollogs/CDB1/preupgrade/postupgrade_fixups.sql
ORACLE_BASEが設定されていない場合、ファイルは$ORACLE_BASE/cfgtoollogsではなく$ORACLE_HOME/cfgtoollogsの下に作成されます。
|
注意:
|
複数のPDBをアップグレードするには、これらの手順を繰り返します。catctl.plを実行する場合、PDBのスペース区切りリストを使用して、すべてのPDBを一括して指定できます。次に例を示します。
$ORACLE_HOME/perl/bin/perl catctl.pl -c "PDB1 PDB2" -l /home/oracle/upgrade catupgrd.sql
Database Upgrade Assistant (DBUA)では、Oracle Databaseのアップグレードを順を追って説明するためのグラフィカル・ユーザー・インタフェースが提供されています。DBUAは、CDBおよび非CDBのデータベース・システム用に動作します。
次の各項では、DBUAを使用したデータベースのアップグレードに関する推奨事項および手順を説明します。
|
注意: 「サイレント・モードのDBUAを使用したOracle Databaseのアップグレード」に記載されているとおり、DBUAをユーザー・インタフェースを表示しないサイレント・モードで起動できます。これは、大きいロールアウトおよびスクリプトの場合に役立ちます。 |
DBUAを使用するときの手順は、マルチテナント・コンテナ・データベース(CDB)、プラガブル・データベース(PDB)、および非CDBの場合と同じです。CDBおよびPDBを使用する際の概要およびドキュメント・ロードマップについては、『Oracle Database概要』を参照してください。ただし、DBUAを実行する場合の考慮事項および推奨事項があります。この項では、推奨事項をまとめています。「アップグレード時のDBUAの停止の概要」も参照してください。
DBUAの使用に関する推奨事項は、次のとおりです。
DBUAを使用してアップグレードを開始する前に、アップグレード前情報ツールを実行することを強くお薦めします。DBUAでは、前提条件の確認の一部としてアップグレード前情報ツールが実行されますが、事前にこのツールを実行することは、データベースを分析し、アップグレード時の停止時間を短縮可能なアクションを実行するためにお薦めします。詳細および手順は、「Oracle Databaseのアップグレード前情報ツールの概要」を参照してください。
アップグレード時にアーカイブ・ログをONに設定します。DBUAによってアップグレード処理のログ・ファイルが作成および更新されるように、アーカイブ・ログをONに設定することをお薦めします。
データベース・インスタンスが実行されていない場合、DBUAはインスタンスを起動しようとします。インスタンスが起動され、実行されている場合、DBUAはそのインスタンスに接続します。
Oracle RACでは、DBUAを使用してクラスタ・データベースをアップグレードする場合は、CLUSTER_DATABASE初期化パラメータの設定をTRUEのままにする必要があります。
DBUAを使用せずに手動でデータベースをリストアする場合は、DBUAを起動する前にORACLE_HOME/cfgtoollogs/dbua/logs/ディレクトリにあるWelcome_SID.txtファイルを削除します。このファイルが存在すると、DBUAでは、この操作が再実行操作であると認識されます。
Oracle Database Vaultが有効になっている場合、「Oracle Database Vaultを使用しているOracle Databaseのアップグレードの要件」を参照してください。
アップグレードを中止し、データベースをリストアしない場合は、Oracle Database 12cのサーバーを使用してUPGRADEモードで既存のデータベースを起動するまで、DBUAを再起動できません。データベースをリストアしないかぎり、元のOracle Databaseのサーバーに戻ることはできません。かわりに、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」の説明に従って、手動(コマンドライン)アップグレードを続行する必要があります。
Oracle Database 12cのソフトウェアをインストールし、既存のOracle Databaseのアップグレードを指定した場合は、DBUAが自動的に起動されます。また、「Oracle Databaseのアップグレードの再実行」に記載されているとおり、インストールの完了後にDBUAを個別で起動することもできます。
アップグレードの実行中、DBUAによって、各コンポーネントのアップグレード処理の進行状況が表示されます。DBUAは、詳細なトレース・ログおよびログ・ファイルを書き込み、後で参照するための完全なHTMLレポートを作成します。セキュリティを強化するために、DBUAは、アップグレード後のデータベースで、新しいユーザー・アカウントを自動的にロックします。その後、DBUAは、新しいOracleホームへの新しい構成ファイル(パラメータ・ファイルおよびリスナー・ファイル)の作成へと進みます。
DBUAは、アップグレード前のすべての手順が完了するまで、アップグレード処理を開始しません。詳細情報および手順の概要とそれらへのポインタが記載されている「Oracle Databaseのアップグレードを準備するための作業」を参照してください。
アップグレード時、DBUAは、新しく必要な表領域を自動的に変更または作成し、適切なアップグレード・スクリプトを起動します。
前提条件フェーズでは、DBUAはアップグレード前情報ツール(preupgrd.sql)を実行し、次の論理を使用して新しく必要な表領域を変更または作成します。
データファイルが自動拡張可能で、十分なディスク領域がある場合、DBUAはアップグレードを続行します。
データファイルを自動拡張できない場合、ファイルの自動拡張を可能にするようにDBUAから求められます。
表領域が自動拡張可能で、MAXSIZE初期化パラメータに調整が必要な場合、DBUAは同じことを要求して、MAXSIZEパラメータを調整します。
拡張できるディスク容量がない場合、DBUAはユーザーに領域を作成(データファイルを追加)するよう要求します。DBUAはファイルの作成場所を決定できないため、DBUAによる新しいデータファイルの追加は自動的に行われません。
DBUAは前提条件フェーズで検出された多くの問題に対処します。たとえば、DBUAは正しいタイムゾーン・ファイルが使用されていて、ネットワーク・アクセス制御リストのACLの調整を行うことを確認できます。
アップグレード・フェーズで、DBUAは、アップグレード処理をシリアルではなくパラレルに実行するcatctl.plを実行し、これにより、停止時間を可能なかぎり短縮するためにCPU性能が最適に活用されます。
DBUAのグラフィカル・ユーザー・インタフェースを使用したデータベースをアップグレードするための手順は、Oracle Database 12cソフトウェアがインストールされた新しいOracleホームから実行されます。WindowsシステムのDBUAを起動するのは、管理者のみである必要があります(「アップグレード時のWindows認証の概要」を参照してください)。
|
関連項目:
|
Linux、UNIXまたはWindowsでDBUAを使用してデータベースをアップグレードするには、次の手順を実行します。
dbua実行可能ファイルは、ORACLE_HOME/binディレクトリにあります。新しいデータベース・ソフトウェアがインストールされたOracleホームからDBUAを起動します。
LinuxまたはUNIXプラットフォームの場合は、Oracle Database 12cの新しいホームで、システム・プロンプトに次のコマンドを入力します。
dbua
Windowsオペレーティング・システムの場合は、「スタート」→「プログラム」→「Oracle-HOME_NAME」→「Configuration and Migration Tools」→「Database Upgrade Assistant」の順に選択します。
DBUAの「操作を選択」ページが表示されます。
DBUAページのヘルプが必要な場合、またはDBUAの詳細を参照する場合は、「ヘルプ」をクリックしてオンライン・ヘルプを開きます。
「次へ」をクリックします。
「データベースの選択」ページが表示され、アップグレード可能なデータベースがリストされます。
ソース・データベースにオペレーティング・システムの認証がない場合は、DBUAによってSYSDBAユーザー名およびパスワードが要求されます。
|
注意:
Windowsシステムでのユーザー・アカウントの管理の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。 |
「ソース・データベースのOracleホームの指定」ドロップダウン・リストから、Oracle Database 12cにアップグレードするデータベースを選択します。DBUAによって、リリースの情報が表示され、選択したOracleホームに関連付けられているOracle Databaseが選択されます。
一度に1つのデータベースのみを選択できます。データベースがリストに表示されない場合は、etcディレクトリにあるoratabファイルにそのデータベース名のエントリが存在することを確認してください。
SYSDBA権限を所有していないユーザー・アカウントからDBUAを実行する場合は、ユーザー名およびパスワード資格証明を入力して、選択されたデータベースに対するSYSDBA権限を有効にする必要があります。
「次へ」をクリックします。
選択したデータベースがマルチテナント・コンテナ・データベース(CDB)の場合、DBUAによって「プラガブル・データベース」ページが表示されます。「プラガブル・データベース」ページでは、選択したCDBとともにアップグレードされる、CDBに含まれるプラガブル・データベースがリストされます。
「次へ」を再度クリックします。
DBUAによって、データベースの分析およびアップグレード前のチェックが実行され、必要に応じて警告が表示されます。次に、DBUAによるデータベースのチェックの例を示します。
空のデータベースのごみ箱。
無効なオブジェクト。
非推奨となったかサポートが終了した初期化パラメータ。
タイム・ゾーン・データ・ファイルのバージョン。
DBUAによる分析が終了すると、「前提条件チェック」ページが表示されます。分析の完了までには数分かかります。
「前提条件チェック」ページには、検証と結果、重大度、問題がある場合に結果が修正可能かどうかおよび実行可能なアクションが表示されます。検証結果を選択すると、「修正可能」列に結果が修正可能かどうかが表示されます。「アクション」ドロップダウン・リストには、実行可能なアクションがリストされます。たとえば、DBUAで「修正」を選択すると、問題を修正するためのスクリプトまたはコマンドが実行されます。
「検証」列で結果を選択すると、ページの下部領域に結果に関する情報がDBUAによって表示されます。
テキスト情報領域で詳細へのリンクをクリックします。詳細情報が含まれた「検証の詳細」ボックスが表示されます。
検証エラーまたは警告があり、これらが修正可能な場合は、実行する「アクション」を選択できます。
「次へ」をクリックします。
「アップグレード・オプション」タブが選択された状態の「アップグレード・オプションの構成」ページが表示されます。
「アップグレード・オプション」タブが選択された状態の「アップグレード・オプション」ページには、次のオプションがあります。
アップグレード並列度の選択
「アップグレード並列度」セクションでは、アップグレード処理の並列度を有効にします。このオプションでは、スクリプトおよび処理の実行を同時に処理するために使用可能なCPUの数に基づいて、アップグレードの実行に必要な時間を短縮します。
DBUAはデフォルトで、「アップグレード並列度」をCPUの数またはCPUの数が4つより少ない場合は2に設定します。このデフォルト値は、「並列度」ドロップダウン・リストから新しい値を選択して調整できます。
アップグレード後に無効なオブジェクトを再コンパイル
アップグレード完了後に、すべての無効なPL/SQLモジュールを再コンパイルします。アップグレード後に無効なオブジェクトを再コンパイルする際の並列度を指定します。DBUAでは、再コンパイルの並列度の推奨程度が提供され、これは使用可能なCPUの数より1つ少ない数に設定されます。並列度を利用することで、アップグレード時間を大幅に短縮できます。アップグレード後フェーズでDBUAによる無効なオブジェクトの再コンパイルを行わない場合は、データベースをアップグレードした後に無効なオブジェクトを手動で再コンパイルする必要があります。
タイム・ゾーン・データのアップグレード
このリリースのタイムゾーン・データ・ファイルを更新します。このオプションを選択しない場合は、アップグレード後にタイム・ゾーン構成ファイルを手動で更新する必要があります。
アップグレード前の統計の収集
アップグレード前に統計を収集することにより、アップグレード処理全体の時間が短縮されます。
アップグレード中にユーザーの表領域を読取り専用に設定
表領域を転送する必要があるデータベースをアップグレードしている場合は、選択を解除します。トランスポータブル表領域のファイル・ヘッダーは、書込み可能である必要があります。
診断先
DBUAが診断用に作成した出力の場所です。デフォルトを受け入れるか、フィールドにフルパスを入力するか、または「参照」をクリックして場所に移動することができます。
監査ファイル保存先
DBUAが監査ファイルを保存する場所です。デフォルトを受け入れるか、「参照」をクリックして別の場所に移動します。
(オプション)「カスタムSQLスクリプト」タブをクリックして、アップグレードの前後に実行するカスタムSQLスクリプトを指定します。
「カスタム・スクリプト」ページが表示されます。「カスタムSQLスクリプト」オプションを使用せずに、「次へ」をクリックすることもできます。
オプション: 「アップグレード前」および「アップグレード後」フィールドで、実行するカスタムSQLスクリプトの場所を参照します。いずれか1つまたは両方を指定するか、フィールドを空白にしてこのオプションをスキップすることができます。
「次へ」をクリックします。
管理オプション・ページが表示されます。
「管理オプション」ページで、次の管理オプションを選択します。
Enterprise Manager (EM) Database Expressの構成
Oracle Enterprise Manager Database Expressは、Oracle Database 12cに組み込まれているWebベースのデータベース管理アプリケーションです。EM Expressは、リリース10gおよび11gで使用可能だったDB Controlコンポーネントを置き換えます。EM Database Expressのポート番号(たとえば5502など)を入力します。
Enterprise Manager (EM) Cloud Controlへの登録
Oracle Enterprise Manager Cloud Controlへの登録では、データベースおよび関連するリスナー、Oracle ASMディスク・グループおよびOracle Clusterwareなどのエンティティを管理対象ターゲットとして追加します。
このオプションを選択した場合は、次の各フィールドに情報を入力する必要があります。
OMSホスト
OMSポート
EM管理ユーザー名
EM管理パスワード
DBSNMPユーザー・パスワード
「次へ」をクリックします。
単一インスタンスのデータベースまたはOracle Express Edition (XE)をアップグレードしている場合は、「データベース・ファイルの移動」ページが表示されます。
|
注意: Oracle Real Application Clustersのデータベースをアップグレードしている場合は、「データベース・ファイルの移動」ページは表示されません。Oracle RACのアップグレードを続行するには、データベース・ファイルの移動およびネットワークの構成に関係する手順をスキップできます。 |
Oracle Expressデータベース(Oracle XE)をアップグレードする場合、「データベース・ファイルの移動」画面には、次のように、「グローバル・データベース名」および「SID」フィールドがある「データベース名の変更」が追加で含まれます。
「データベース・ファイルの移動」ページで、オプションを１つ選択します。
アップグレードの一部としてデータベース・ファイルを移動
高速リカバリ領域をアップグレードの一部として移動
Oracle XEデータベースをアップグレードする場合、「グローバル・データベース名」および「SID」を指定する必要があります。「データベース・ファイルの移動」の残りのオプションは、Oracle Databaseの場合と同じです。
|
注意: 高速リカバリ領域は、バックアップおよびリカバリに関連するファイルを格納するためのディスクの場所で、Oracleによって管理されます。高速リカバリ領域を使用すると、データベース・リカバリ・プロセスのスピード、信頼性および管理性が大幅に向上するため、高速リカバリ領域を構成することを強くお薦めします。「管理オプション」ページでローカル管理を有効にした場合、高速リカバリ領域の場所はOracle Enterprise Managerでも使用されます。 |
「アップグレードの一部としてデータベース・ファイルを移動」を選択した場合は、データベース・ファイルの記憶域のタイプも構成する必要があります。
「記憶域のタイプ」ドロップダウン・リストで、「ファイルシステム」または「Oracle ASM」を選択します。
「ファイルシステム」を選択した場合は、データベース・ファイルがホスト・ファイル・システムに移動されます。
「Oracle Automatic Storage Management」 (Oracle ASM)を選択した場合は、データベース・ファイルはOracle ASM記憶域(現在システム上に存在している必要があります)に移動されます。Oracle ASMインスタンスがない場合は、Oracle Grid InfrastructureホームからAutomatic Storage Management Configuration Assistant(ASMCA)を使用してインスタンスを作成し、DBUAを再起動できます。
|
関連項目:
|
「すべてのデータベース・ファイルに対して共通の位置を使用」または「マッピング・ファイルを使用してデータベース・ファイルの位置を指定」のいずれかを選択できます。「ファイルの場所」フィールドで場所を指定するか、場所を参照します。
「Oracle Managed Fileの使用」を選択した場合、「REDOログおよび制御ファイルの多重化」をクリックします。「場所」フィールドがある「REDOログおよび制御ファイルの多重化」ダイアログ・ボックスが表示されます。書込み先のオンラインREDOログおよび制御ファイルの場所を入力します。フォルト・トレランスを高めるために、異なるディスクにまたがって分散した複数の場所を使用します。
「アップグレードの一部として高速リカバリ領域を移動」を選択した場合は、記憶域タイプおよび高速リカバリ領域の場所を構成し、この手順の説明に従って、割り当てられるサイズも指定する必要があります。
データベース・ファイルの移動および高速リカバリ領域の移動オプションは、互いに独立しています。たとえば、Oracle ASMへのデータベース・ファイルの移動を選択して、ファイル・システム上の高速リカバリ領域のままにすることができます。
高速リカバリ領域に移動することを選択した場合、DBUAは、既存のアーカイブ済REDOログを新しい場所に物理的に移動しません。かわりに、DBUAは、データベースが新しいOracleホームから起動されたときに、DB_RECOVERY_FILE_DESTおよびDB_RECOVERY_FILE_DEST_SIZE初期化パラメータに新しい場所および新しいサイズを設定します。
Oracle Express EditionのデータベースがOracle Enterprise Editionにアップグレードされた場合は、高速リカバリ領域を構成する必要があります。高速リカバリ領域が現在構成されている場合は現在の設定が保持されますが、この値を上書きできるページが表示されます。
記憶域のタイプ
記憶域のタイプ・リストで、「ファイルシステム」または「Oracle ASM」を選択します。
「ファイルシステム」を選択した場合は、高速リカバリ領域はホスト・ファイル・システムになります。
「Oracle Automatic Storage Management」 (Oracle ASM)を選択した場合は、高速リカバリ領域はOracle ASM記憶域になり、ここは、現在システム上に存在している必要があります。Oracle ASMインスタンスがない場合は、Grid InfrastructureホームからAutomatic Storage Management Configuration Assistant(ASMCA)を使用してインスタンスを作成し、DBUAを再起動できます。
高速リカバリ領域の場所
ホスト・ファイル・システム上またはOracle ASM記憶域上の場所を参照します。
高速リカバリ領域のサイズ
高速リカバリ領域に割り当てるサイズを指定します。デフォルトは1024MBです。
「次へ」をクリックします。
表示される「ネットワーク構成」ページで、リスナーを選択します。
「ネットワーク構成」ページの「リスナーの選択」領域には、「名前」、「ポート」、「Oracleホーム」および「移行」の列がある表が表示されます。リスナー名の左側には、リスナーを選択するためのボックスがあります。
ソースOracleホームから新しくアップグレードされたOracleホームに移行する1つ以上のリスナーを選択します。
DBUAによって、選択したリスナーがターゲットOracleホームのlistener.oraファイルに追加され、開始されます。
DBUAによって、古い(ソース)listener.oraファイルからアップグレードされたデータベースのエントリが削除されます。
DBUAによって、ソースとターゲット両方のOracle Database環境で、listener.oraファイルが再ロードされます。
|
注意: 他のデータベースが同じリスナーに登録されている場合、リスナーの移行中に、それらの新しいクライアント接続リクエストが影響を受ける可能性があります。 |
「新規リスナーの作成」を選択して、新規リスナーを作成します。名前およびポート番号を指定します。
「次へ」をクリックします。
DBUAによって、「リカバリ・オプション」ページが表示されます。DBUAは、アップグレード前手順で、リスナーの移行を実行します。
「リカバリ・オプション」ページで、アップグレード処理で問題が発生した場合に使用するリカバリ・メソッドを選択します。
次のリカバリ・オプションおよび構成が使用できます。
RMANバックアップの使用
フラッシュバックおよび保証付きリストア・ポイントの使用
独自のバックアップおよびリストア計画
RMANバックアップの使用
「新規オフラインRMANバックアップの作成」を選択した場合、「バックアップの場所」フィールドにバックアップの場所へのフル・パスを入力します。
「最新の使用可能なRMANバックアップの使用」を選択し、アップグレードの前にRMANバックアップの作成を選択しなかった場合は、DBUAによって、存在する最新のRMANバックアップのタイム・スタンプが表示されます。このバックアップのリストアに既存のスクリプトの実行を選択するには、タイム・スタンプの隣の「スクリプトのリストア」を選択できます。
フラッシュバックおよび保証付きリストア・ポイントの使用
「新規保証付きリストア・ポイントの作成」を選択すると、DBUAがアップグレード処理に入る前にDBUAによってリストア・ポイントが作成されます。
「データベースをフラッシュバック」を以前に有効化し、フラッシュバック保存ターゲットを使用して高速リカバリ領域を構成した場合は、「使用可能な保証付きリストア・ポイントの使用」を選択して、ドロップダウン・リストから名前付きSCNを選択します。現在のリストア・ポイントの設定は保持されます。必要に応じて、DBUAによって、これらの値を上書きできるページが表示されます。
独自のバックアップおよびリストア計画
独自のバックアップ方法でデータベースをバックアップした場合のみ、このオプションを選択します。この場合、「リストア」では、元のデータベースの設定のみがリストアされます。データベース自体をリストアするには、独自のバックアップ・ユーティリティを使用して作成したバックアップをリストアする必要があります。
|
注意: フラッシュバックおよび保証付きリストア・ポイントを利用するには、アップグレードしているデータベースがリリース11.1.0.7以上である必要があり、ソース・データベースで有効化される必要があります。 |
|
関連項目: フラッシュバック・データベースおよび保証付きリストア・ポイントの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
「次へ」をクリックします。
「データベースのアップグレード・サマリー」ページが表示されます。
アップグレードを開始する前に、アップグレードに関する情報が「サマリー」ページに表示されます。すべての詳細を表示するには、リストを下にスクロールします。次に例を示します。
ソース・データベース
ターゲット・データベース
プラガブル・データベース
アップグレード前のチェック
初期化パラメータの変更
タイムゾーンのアップグレード
すべての詳細を確認します。次のとおり、「戻る」または「終了」をクリックします。
設定内容が間違っている場合は、その設定を修正できるページが表示されるまで「戻る」をクリックします。
すべて正しい場合は、「終了」をクリックします。
プログレス・バーが表示された「進行状況」ページが表示され、DBUAによってアップグレードが開始されます。「進行状況」ページには、アップグレードの進行にともなって、実行されている手順、継続時間およびステータスが示される表も表示されます。DBUAでは、この時点でアップグレードを取り消す必要がある場合に備えて、「停止」ボタンが提供されています。
CDBルートおよび各PDBシードのアップグレードの終了を介してアップグレードが進むと、「進行状況」ページでは、ステータスが「終了」とマークされます。「アクティビティ・ログ」、「アラート・ログ」および「アップグレード結果」をクリックすると、詳細を表示できます。
アップグレードの完了後、「アップグレード結果」ページに、元のデータベースとアップグレードしたデータベースの説明が表示され、初期化パラメータに対して行われた変更が表示されます。このページには、アップグレード後に様々なログ・ファイルが格納されるディレクトリ、およびプラガブル・データベースも表示されます。アップグレード前チェックの詳細を表示するには、下にスクロールします。
オプション: アップグレード処理の詳細を確認するには、このログ・ファイルを確認します。DBUAログ・ファイルは、/ORACLE_BASE/cfgtoollogs/dbua/logsにあります。
|
注意: HTML版のアップグレード結果も、ログ・ファイル・ディレクトリに保存されます。このHTMLページにあるリンクをクリックすると、ブラウザでログ・ページを表示できます。 |
アップグレード結果に問題がない場合は、「閉じる」をクリックしてDBUAを終了し、新しくアップグレードしたデータベースを使用します。
第4章「Oracle Databaseのアップグレード後の作業」に示す手順を実行します。
|
注意: データベースの不正な使用を防止するために、データベースをアップグレードした直後にすべてのユーザー・パスワードを変更することをお薦めします。Oracle Database 12cのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、 |
Windowsシステムでは、SYSDBA権限を使用して接続するユーザーは、Windowsのネイティブ認証を利用できます。このユーザーがドメイン・アカウントを使用してOracle Databaseを操作する場合は、ローカル管理権限およびORA_DBAメンバーシップを明示的に付与する必要があります。
以前のリリースとは異なり、Oracle Databaseサービスがローカル・システム・アカウントの権限を使用して実行することが必須ではありません。Oracle DatabaseのサービスをWindowsのユーザー・アカウントを使用して実行できます。データベースに対する認証には、Oracle DatabaseのWindows固有のオペレーティング・システム・グループを使用できます。
|
関連項目:
|
DBUAを使用すると、Oracle Database 12cデータベースを、既存の12cのOracleホームから別の12cのOracleホームに移行できます。
データベースを既存の12cのホームから新しい12cのOracleホームに移動するには、次の手順を実行します。
「DBUAを使用したLinux、UNIXおよびWindowsシステムでのデータベースのアップグレード」の説明に従って、DBUAを起動します。
DBUAが「操作を選択」ページで起動します。
「操作を選択」ページで、「別のリリース12.1 Oracleホームからのデータベースの移動」を選択して「次へ」をクリックします。
「データベースの選択」ページが表示されます。
「データベースの選択」ページで、新しいOracleホームに移動するデータベースを選択します。リリース12cのOracleホームにあるデータベースのみが表示されます。Oracle Database 12cのデータベースがない場合は、移動操作で使用できるデータベースはありません。
「次へ」をクリックします。「データベース・オプションの移動」ページが表示されます。
「データベース・オプションの移動」ページでは、DBUAが作成する診断ログ・ファイルの別の場所を指定でき、オプションで、データベースの移動後に実行するカスタムSQLスクリプト(存在する場合)を指定できます。
「次へ」をクリックします。「データベースの移動サマリー」ページが表示されます。
移動操作のサマリーを確認して、「次へ」をクリックします。DBUAによるデータベースの移動処理が表示される「進行状況」ページが表示されます。
移動処理が完了したら、「終了」をクリックします。
-silentコマンドライン・オプションを使用してDBUAを起動すると、DBUAはサイレント・モードで動作します。サイレント・モードでは、DBUAのユーザー・インタフェースは表示されません。メッセージ(情報、エラー、および警告を含む)がDBUAによってORACLE_HOME/cfgtoollogs/dbua/SID/upgradenにあるログ・ファイルに書き込まれますが、ここでnは、DBUAが実行したアップグレードの続き番号を表します。確実にアップグレードを行うために、DBUAによって生成されたログ・ファイルを確認することを強くお薦めします。
サイレント・モードのDBUAを使用してデータベースをアップグレードするには、次の手順を実行します。
次のコマンドを発行します。
dbua -silent -sid ORCL &
この例では、データベースの名前はORCLです。
Database Upgrade Assistant(DBUA)では、サイレント・モードで実行する場合のコマンドライン・オプションがサポートされています。表3-1に、DBUAでサポートされている様々なオプションおよび対応するパラメータを示します。
|
注意: Oracle Databaseのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
表3-1 DBUAのコマンドライン・オプション
| オプション | 説明 |
|---|---|
|
|
DBUAがサイレント・モードで動作するように指定します。 |
|
|
アップグレードするデータベースのシステム識別子(SID)を指定します。 |
|
|
アップグレードするデータベースのOracle Databaseホーム・ディレクトリを指定します。 |
|
|
アップグレードするデータベースのOracle Databaseベース・ディレクトリを指定します。 |
|
|
新しいリリースのOracleホームにリスナーを作成するには、 |
|
|
データベースを既存のリスナーに登録するには、カンマ区切りの |
|
|
Oracleトレース・ファイルおよび診断ファイルを保存するデフォルトの場所を指定します。これにより、バックグラウンド・ダンプ保存先およびユーザー・ダンプ保存先の初期化パラメータ設定が、前のリリースの設定から置き換わります。 |
|
|
|
|
|
SYSDBA_userのパスワードを指定します。 |
|
|
アップグレード中にデータベース・ファイルの自動拡張を行います。データ・ファイルはアップグレードの後で元の自動拡張設定に戻ります。 |
|
|
新しいグローバル・データベース名を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。 |
|
|
アップグレードするデータベースの新しいシステム識別子(SID)を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。 |
|
|
データベースのタイムゾーン・ファイルのバージョンをアップグレードします。 |
|
|
データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。このオプションを指定した場合、DBUAではログの場所にデータベース・マップ・ファイルのみが生成されて、終了します。 |
|
|
データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。アップグレードするデータベースにOracle ASMインスタンスがある場合、そのインスタンスを使用してアップグレードを実行するように、このオプションでDBUAに指定します。 |
|
|
データベース・ファイルを格納するための共通の位置を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。 |
|
|
Oracle Managed Files用のデータベース領域を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。 |
|
|
データベース・ファイルをマップするためのマップ・ファイルの完全名を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。 |
|
|
アップグレード中に移動されるデータベース用のリカバリ領域を指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。 |
|
|
アップグレード中に移動されるデータベース用のリカバリ領域のサイズをMB単位で指定します。このオプションは、データ・ファイルを移動する場合、またはOracle XEデータベースをアップグレードする場合にのみ適用されます。 |
|
|
Application Express管理者のパスワードを指定します。 |
|
|
アップグレード時に実行しているSQLスクリプトの詳細ログの生成を無効にします。このオプションは、デフォルトでは有効になっています。ログ生成を有効にする場合は、このオプションを指定しないでください。 |
|
|
アップグレードを開始する前に、データベースをバックアップするディレクトリを指定します。 |
|
|
SQLスクリプトを、カンマで区切ったリストにして指定します。完全なパス名を指定します。このスクリプトはアップグレード後に実行されます。 |
|
|
name=valueの形式で初期化パラメータ値のカンマ区切りのリストを指定します。 |
|
|
アップグレード中のアーカイブおよびフラッシュバック・ロギングをオフにします。 |
|
|
このオプションを |
|
|
パラレル再コンパイルに使用するレベルを指定します。 |
|
|
すべてのリカバリ・ファイルの宛先ディレクトリを指定します。このオプションが適用されるのは、データ・ファイルを移動する場合、Oracle XEデータベースをアップグレードする、またはOracle Enterprise Managerを構成する場合のみです。 |
|
|
クラスタ・データベースがOracle Cluster Registryに登録されていない場合は、クラスタ・データベースのローカルSIDを指定します。 |
|
|
DBUAのヘルプを表示します。 |
次の構文を使用して、すべての有効なオプションをコマンドラインから指定できます。
dbua [ -silent ] [ -sid SID ] [-oracleHome home_name] [-oracleBase base_name] [-diagnosticDest diagnostic_destination] [-sysDBAUserName SYSDBA_user] [-sysDBAPassword SYSDBA_pwd] [-upgradeASM] [-autoextendFiles] [-newGlobalDbName db_name] [-newSid new_SID] [-generateMapFile] [-useASM] [-commonFileLocation common_files] [-omfLocation omf_area] [-databaseMapFile map_file_name] [-newRecoveryArea recover_area] [-newRecoveryAreaSize recover_size] [-apexAdminPassword apex_pwd] [-disableUpgradeScriptLogging ] [-backupLocation directory] [-sysauxTablespace -datafileName name -datafileSize size -datafileSizeNext size -datafileSizeMax size] [-postUpgradeScripts script [, script ] ... ] [-initParam parameter=value [, parameter=value ] ... ] [-disableArchiveLogMode] [-recompile_invalid_objects true | false] [-degree_of_parallelism number] [-recoveryAreaDestination directory] [-h|-help]
Oracle Database 12cでは、パラレル・アップグレード・ユーティリティ(catctl.pl)が導入されましたが、これにより、特定の順序でアップグレードする必要のないコンポーネントを、CPU性能を活用して同時にアップグレードできます。手動によるアップグレードとDatabase Upgrade Assistant (DBUA)を使用して実行するアップグレードの両方でアップグレード処理を簡易化するための改善を引き続き行います。DBUAおよび手動アップグレード手順では、新しいパラレル・アップグレード・ユーティリティを活用します。パラレル・アップグレード・ユーティリティでは、データベースをアップグレードするために複数のSQLプロセスを使用してデータベース・ディクショナリをパラレルでロードすることによって、アップグレードの実行にかかる合計時間を短縮します。
新しいパラレル・アップグレード・ユーティリティ(catctl.pl)に関連する項目は、次のとおりです。
パラレル・アップグレード・ユーティリティでは、データ・ディクショナリおよびコンポーネントをパラレルでロードするため、アップグレード全体の時間が短縮されます。パラレル・アップグレード・ユーティリティ(catctl.pl)を起動する前に、アップグレード前に通常行うデータベースのバックアップ手順に従います。また、前提条件として、アップグレード前情報ツール(preupgrd.sql)を実行して、アップグレード処理の前にデータベース管理者が対処する必要のある問題を特定する必要があります。
手動でcatctl.plを実行するための手順の詳細は、「マルチテナント・コンテナOracle Database (CDB)の手動でのアップグレード」に記載されています。パラレル・アップグレード・ユーティリティを使用してデータベースをアップグレードするための一般的な手順は次のとおりです。
「アップグレードのためのOracle Databaseのバックアップ」の説明に従って、現行のデータベースをバックアップします。
「新しいOracle Databaseソフトウェアのインストール」の説明に従って、新しいリリースのOracle Database 12cソフトウェアをインストールします。
「Oracle Databaseのアップグレード前情報ツールの概要」に記載されているとおり、アップグレード前情報ツール(preupgrd.sql)がソース・データベースで実行されていることを確認します。
ORACLE_HOME/rdbms/adminディレクトリから、SQL*Plusを起動します。
アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。
CONNECT / AS SYSDBA
データベースをアップグレード・モードで起動します。
マルチテナント・コンテナ・データベース(CDB)の場合:
SQL> alter pluggable database all open upgrade;
非CDBの場合:
SQL> startup upgrade
|
注意: UPGRADEキーワードは、アップグレード用に環境を準備する操作を実行します。 |
起動コマンドでPFILEオプションを使用して、初期化パラメータ・ファイルの場所を指定する必要がある場合があります。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
一度データベースをアップグレード・モードで起動すると、catctl.plスクリプトを実行するまでは、固定ビューへの問合せのみ、エラーにならずに実行できます。catctl.plを実行する前は、他のビューへの問合せやPL/SQLの実行で、エラーが戻されます。
サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。
SQL*Plusを終了します。
新しいOracleホームからcatctl.plを実行します。catctl.plを実行可能なパラメータについては、「パラレル・アップグレード・ユーティリティ(catctl.pl)のパラメータ」を参照してください。
Linuxでは、次のようにcatctl.plを実行します。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql -l
Windowsでは、次のようにcatctl.plを実行します。
cd %ORACLE_HOME%\rdbms\admin %ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql -l
表3-2にリストされているパラメータは、catctl.plの起動時に使用できます。catctl.plでのアップグレード・フェーズの処理方法およびその例の詳細は、「パラレル・アップグレード・ユーティリティの使用例」を参照してください。
表3-2 catctl.plパラメータ
| パラメータ | 説明 |
|---|---|
|
-c |
アップグレードするPDBを指定します。 このパラメータは包含リストを指定します。たとえば、ここで名前を指定したPDBは含まれます(ここで名前を指定しないすべてのPDBはスキップされます)。 LinuxおよびUNIXの場合(一重引用符を使用): -c 'PDB1 PDB2' Windowsの場合(二重引用符を使用): -c "PDB1 PDB2" |
|
-C |
アップグレードしないPDBを指定します。 このパラメータは除外リストを指定します。たとえば、ここで名前を指定したすべてのPDBはスキップされます(他のすべてのPDBはアップグレードされます)。 LinuxおよびUNIXの場合(一重引用符を使用): -C 'PDB1 PDB2' Windowsの場合(二重引用符を使用): -C "PDB1 PDB2" 注意: |
|
-d |
処理されるファイルが含まれているディレクトリの場所を指定します。 |
|
-e |
スクリプトの実行中にecho OFFに設定します。デフォルトはecho ONです。 |
|
-i |
スプール・ログ・ファイルの作成時に使用する識別子を指定します。 |
|
-l |
スプール・ログ・ファイルで使用するディレクトリの場所を指定します。デフォルトは現行の作業ディレクトリです。
|
|
-M |
PDBのアップグレード中に、UPGRADEモード内でCDB$ROOTを維持します。非CDBでは、このパラメータは無視されます。CDBのアップグレード中に、このパラメータ設定を使用すると、CDBおよびそのすべてのPDBがアップグレード・モードになるので、アップグレードにかかる合計の時間を減らすことができます。ただし、CDBおよびそのすべてのPDBのアップグレードがすべて終了するまで、いずれのPDBも取り出すことはできません。デフォルトでは、-Mパラメータ設定を使用しない場合、CDB$ROOTは通常のモードでアップグレードされて再起動し、通常のバックグラウンド処理が開始されます。それぞれのPDBのアップグレード中に、他のPDBのアップグレードが進行中にPDBをオンラインにすることができます。 |
|
-n |
パラレル操作で使用する処理の数を指定します。 非CDBでは、データベースをアップグレードする時に使用するSQL処理の数を指定します。最大値は8です。最小値は1です。デフォルト値は4です。 CDBでは複数のPDBのアップグレードが同時に処理されます。同時にアップグレードされるPDBの数は、-nパラメータの値よって制御されます。デフォルト値は、CPUの数を2で割った数値です(cpu_count/2).。cpu_countは、24に等しく、12 PDBのアップグレードが同時に実行されているのと同等です。最大値は64です。最小値は4です。最大のPDBアップグレードは同時に32 (64/2)実行され、最少の値は2 (4/2)です。 |
|
-N |
データベースをアップグレードする時に使用するSQL処理の数を指定します。 非CDBでは、このパラメータは無視されます。 CDBでは、最大値は8です。最小値は1です。デフォルト値は2です。 |
|
-p |
指定したフェーズを再起動します(再実行では成功したフェーズをスキップします)。 |
|
-P |
指定したフェーズを停止します。 |
|
-s |
セッションを初期化するSQLスクリプトを指定します。 |
|
-S |
パラレルではなく、シリアル・アップグレードを指定します。 |
|
-u |
ユーザー名を指定し、パスワードを要求します。 |
|
-y |
フェーズのみを表示します。 |
|
-z |
catcon.pmのデバッグ情報を戻します。 |
|
-Z |
たとえば、1に設定する場合、 |
catctl.plパラレル・アップグレード・ユーティリティはDBUAと統合されています。ただし、手動のコマンドライン・アップグレードでは、catctl.plを様々なパラメータを指定して実行できます。たとえば、catctl.plをパラレル操作を使用せずにシリアル・モードで実行するには、-Sパラメータを指定します。使用可能なパラメータについては、表3-2「catctl.plパラメータ」を参照してください。
例3-1 選択したパラメータを使用したcatctl.plの実行
catctl.plの起動時に-n 4が使用されている場合、アップグレード処理でcatupgrd0.log、catupgrd1.log、catupgrd2.logおよびcatupgrd3.logが作成されます。アップグレードが成功したか失敗したかを検証する場合は、catupgrd#.logファイルをすべて確認する必要があります。catctl.plを再実行する場合は、別のログ・ディレクトリを指定しないかぎり、以前のログ・ファイルは上書きされます。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -n 4 -l $ORACLE_HOME/diagnostics catupgrd.sql
Oracle Database 12cのソフトウェアをインストールして、新しいOracleホームを準備したら、DBUAではなく、手動のコマンドライン・アップグレードに進むことができます。
この項の手順では、Oracleマルチテナント・コンテナ・データベース(CDB)ではないOracle Databaseのアップグレードのステップについて説明します。この手順は、Oracle Database 12cのソフトウェアをインストールし、新しいOracleホームを準備し、アップグレード前情報ツールを実行済であることを想定しています。手順の詳細は、「新しいOracle Databaseソフトウェアのインストール」および「アップグレードのための新しいOracleホームの準備」を参照してください。
|
関連項目: マルチテナント・アーキテクチャの概要については、『Oracle Database概要』を参照してください。 |
非CDBのデータベースを手動でアップグレードするには、次の手順を実行します。
まだ実行していない場合は、「Oracle Databaseのアップグレード前情報ツールの概要」の記載に従って、アップグレード前情報ツールを実行します。次に進む前に、アップグレード前情報ツールの出力を確認して、出力に記載されているすべての問題を修正します。問題の修正の詳細は、「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」を参照してください。
「アップグレードのためのOracle Databaseのバックアップ」の説明に従って、ソース・データベースをバックアップします。
まだ実行していない場合は、「アップグレードのための新しいOracleホームの準備」の記載に従って、新しいOracleホームを準備します。
データベースを停止します。
SQL> SHUTDOWN IMMEDIATE
ご使用のオペレーティング・システムがWindowsの場合、次の手順を実行します。
アップグレードするデータベースのOracleサービスOracleServiceSIDを停止します(SIDはインスタンスの名前です)。たとえば、SIDがORCLの場合、コマンド・プロンプトで次のように入力します。
C:\> NET STOP OracleServiceORCL
コマンド・プロンプトで、ORADIMを使用してOracleサービスを削除します。詳細は、「WindowsでOracle Databaseのアップグレード時に使用するORADIMの変数」を参照してください。ORADIMの構文およびコマンドの完全なリストは、ご使用のプラットフォームのガイドを参照してください。
SIDがORCLの場合、次のコマンドを入力します。実際のSIDの名前で置き換えます。
C:\> ORADIM -DELETE -SID ORCL
次の例に示すとおり、新しいOracle DatabaseリリースのORADIMコマンドをコマンド・プロンプトで使用して、Oracle Database 12cのサービスを作成します。
C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -MAXUSERS USERS -STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA
ほとんどのOracle Databaseサービスは、Oracleホーム・ユーザーの権限を使用してシステムにログオンします。サービスは、このユーザーの権限を使用して実行されます。ORADIMコマンドは、このユーザー・アカウントのパスワードを要求します。ORADIMを使用して、他のオプションを指定できます。
この例で、SIDがORCL、password (SYSPWD)がTWxy5791、ユーザーの最大数(MAXUSERS)が10、ORACLE_HOMEディレクトリがC:\ORACLE\PRODUCT\11.2.0\DBの場合、次のコマンドを入力します。
C:\> ORADIM -NEW -SID ORCL -SYSPWD TWxy5791 -MAXUSERS 10 -STARTMODE AUTO -PFILE C:\ORACLE\PRODUCT\11.2.0\DB\DATABASE\INITORCL.ORA
ORADIMによって、ORACLE_HOME\databaseディレクトリにログが書き込まれます。ログ・ファイルには、マルチテナント・データベース内のPDBの名前が含まれています。
ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の内容を確認します。
ORACLE_SIDが正しく設定されていること。
oratabファイルがOracle Database 12cのOracleホームを指していること。
次の環境変数がOracle Database 12cのディレクトリを指していること。
ORACLE_HOME
PATH
ORACLE_HOME値を設定するためにクライアントで使用するすべてのスクリプトが、新しいOracleホームを指している必要があります。
|
注意: クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。 |
|
関連項目: ご使用のオペレーティング・システムでのその他の重要な環境変数の設定に関する詳細は、オペレーティング・システム固有の『Oracle Databaseインストレーション・ガイド』を参照してください。 |
新しいOracle Database 12cのOracleホームの所有者として、システムにログインします。
ORACLE_HOME/rdbms/adminディレクトリから、SQL*Plusを起動します。
アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。
SQL> CONNECT / AS SYSDBA
SQL*Plusで次のコマンドを発行して、インスタンスを起動します。
SQL> startup upgrade pfile=pfile_name
|
注意: UPGRADEキーワードを使用すると、前のOracle Databaseリリースをベースとするデータベースをオープンできます。また、AS SYSDBAセッションへのログオンの制限、システム・トリガーの無効化、およびアップグレードの環境を準備するその他の操作も実行されます。 |
初期化パラメータ・ファイルPFILEの場所を指定します。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。
SQL*Plusを終了したら、次の手順に進みます。
この手順の説明に従って、新しいOracleホームからcatctl.plスクリプトを実行します。パラレル・アップグレード・ユーティリティ(catctl.pl)によって、停止時間を短縮するパラレル・アップグレード・オプションが提供されています。
Linuxでは、次のようにcatctl.plを実行します。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql
Windowsでは、次のようにcatctl.plを実行します。
cd %ORACLE_HOME%\rdbms\admin %ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql
|
注意:
|
catctl.plを実行すると、アップグレードしたデータベースは停止されます。インスタンスを再起動して、通常の操作用にシステム・パラメータを再初期化します。
SQL> STARTUP
catctl.plスクリプトの一部としてデータベースが停止された後のこの再起動では、すべてのキャッシュがフラッシュされ、バッファが消去されて、その他のハウスキーピング・アクティビティが実行されます。これらの操作は、新しくアップグレードしたOracle Databaseソフトウェアの整合性と一貫性を保証するための重要な最終手順です。
|
注意: 手順11でデータベースを起動したときに、サポートが終了した初期化パラメータがリストされているメッセージが表示された場合は、再起動の前にサポートが終了した初期化パラメータをパラメータ・ファイルから削除します。ファイルを編集してパラメータを削除するために、必要に応じてSPFILEをPFILEに変換します。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
重要: catuppst.sqlスクリプトは、アップグレード処理中にエラーが戻されないかぎり、アップグレードの一部として実行されます。ログ・ファイルで「Rem BEGIN catuppst.sql」を検索して、アップグレード処理中にcatuppst.sqlが実行されたことを確認します。
catuppst.sqlが実行されていない場合は、この手順に示されているcatuppst.sqlの実行に進みます。catctl.plを実行すると、アップグレード中にcatuppst.sqlが実行されなかったことを示す警告メッセージも表示されます。
次のようにcatuppst.sqlを実行します。
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b catuppst -d '''.''' catuppst.sql
ログ・ファイルcatuppst0.logは、アップグレード後の結果を記録して生成されます。
catcon.plを実行して、utlrp.sqlを起動し、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。次の構文を使用します。
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql
ログ・ファイルutlrp0.logは、再コンパイルの結果を記録して生成されます。
postupgrade_fixups.sqlを実行します。「postupgrade_fixups.sqlスクリプトの実行」を参照してください。
utlu121s.sqlを実行して、すべての問題が修正されたことを確認します。
SQL> @rdbms/admin/utlu121s.sql
ログ・ファイルutlu121s0.logは、アップグレード結果を記録して生成されます。
データベースの状態に関する情報を確認するには、アップグレードの完了後、いつでも何回でもutlu121s.sqlを実行できます。utlu121s.sqlスクリプトからエラーが戻されたり、VALIDでないか、または最新のリリースのものではないコンポーネントが表示された場合は、詳細を「Oracle Databaseのアップグレードのトラブルシューティング」で確認してください。
予測されるすべてのパッケージおよびクラスが有効であることを確認します。(この手順は、アップグレードを開始する前にpreupgrd.sqlが実行済であることを前提としています。)
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utluiobj -d '''.''' utluiobj.sql
ログ・ファイルutluiobj0.logは、検証の結果を記録して生成されます。
|
注意: アップグレード前情報ツールでINVALIDオブジェクトが検出され、registry$sys_inv_objs表およびregistry$nonsys_inv_objs表に移入された場合は、ORACLE_HOME/rdbms/admin/utluiobj.sqlを実行して、アップグレード処理の結果、新しく無効になったオブジェクトのみを表示します。このutluiobj.sqlスクリプトを実行すると、アップグレード前はVALIDであったが、現在はINVALIDであるオブジェクトのみが表示されます。「アップグレード前情報ツール(preupgrd.sql)の使用方法」を参照してください。 |
SQL*Plusをまだ起動している場合は終了します。
リリース10.2、11.1または11.2からクラスタ・データベースをアップグレードする場合は、次のコマンドを使用してOracle Clusterwareのデータベース構成をアップグレードしてください。
$ srvctl upgrade database -d db-unique-name -o oraclehome
ここで、db-unique-nameは(インスタンス名ではなく)割り当てられたデータベース名であり、oraclehomeは、データベースがアップグレードされるOracleホームの場所です。SRVCTLユーティリティでは、以前のリリースで使用されていた短いCLIオプションに加えて、GNUスタイルの長いオプションもサポートされます。
これで、データベースがOracle Database 12cにアップグレードされました。第4章「Oracle Databaseのアップグレード後の作業」に示す手順を完了する準備ができました。
|
注意: Oracle Warehouse Builder(OWB)コンポーネントはOracle Databaseアップグレード処理の一部としてアップグレードされません。Oracle Warehouse Builderは、Oracle Database 12cの一部としてインストールされません。詳細は、「Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件」を参照してください。 |
|
注意: 古いOracleソフトウェアを保持している場合、古いソフトウェアを使用してアップグレードしたデータベースを起動しないでください。新しいOracle Databaseインストールの実行可能ファイルでのみデータベースを起動してください。また、古いOracle環境を削除する前に、古いOracle環境にあるデータ・ファイルをすべて新しいOracle Database環境に再配置してください。データ・ファイルの再配置の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Windowsプラットフォームでは、ORADIMによって、Windowsデータベースおよびサービスの管理作業を手動で実行するためのコマンドライン・インタフェースが提供されています。Database Configuration Assistant (DBCA)では、同じ作業を実行するためのグラフィカル・ユーザー・インタフェースが提供されています。Oracle Databaseのアップグレード時に知っておく必要のあるORADIMの変数には、アップグレード対象のデータベースのSID、新しいOracleホームの場所および新しいデータベース・インスタンスのパスワードが含まれます。また、ORADIMによって、ORACLE_HOME\databaseディレクトリにログが書き込まれます。
次の表に、アップグレード時にORADIMを使用するための変数を示します。
| ORADIM変数 | 説明 |
|---|---|
SID |
アップグレードするデータベースのSIDと同じSID名。 |
PASSWORD |
新しいOracle Database 12cデータベース・インスタンスのパスワード。SYSDBA権限で接続するユーザー用のパスワードです。-SYSPWDオプションは必須です。
Oracle Database 12cのデフォルトのセキュリティ設定では、パスワードは8文字以上にする必要があり、 |
USERS |
SYSDBA権限およびSYSOPER権限を付与できるユーザーの最大数。 |
ORACLE_HOME |
Oracle Database 12cのOracleホームの場所。-PFILEオプションを使用して、Oracleホームの場所のドライブ文字を含む、フルパス名を指定する必要があります。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。 |
|
関連項目: ORADIMを使用したデータベース・インスタンスの管理の詳細は、Oracle Databaseプラットフォーム・ガイドfor Microsoft Windowsを参照してください。 |
Oracle Database 12cでは、Oracle Databaseをプラガブル・データベースを含むマルチテナント・コンテナ・データベース(CDB)として機能させることができるマルチテナント・アーキテクチャが導入されています。CDBをアップグレードできるため、CDB内のすべてのプラガブル・データベースを同時にアップグレードします。Oracle Database 12cのソフトウェアをインストールして、新しいOracleホームを準備したら、DBUAではなく、手動のコマンドライン・アップグレードに進むことができます。
この項の手順では、CDBのアップグレードのステップについて説明します。この手順は、Oracle Database 12cのソフトウェアをインストールし、新しいOracleホームを準備し、アップグレード前情報ツールを実行済であることを想定しています。手順の詳細は、「新しいOracle Databaseソフトウェアのインストール」および「アップグレードのための新しいOracleホームの準備」を参照してください。
CDBのデータベースを手動でアップグレードするには、次の手順を実行します。
まだ実行していない場合は、「Oracle Databaseのアップグレード前情報ツールの概要」の記載に従って、アップグレード前情報ツールを実行します。次に進む前に、アップグレード前情報ツールの出力を確認して、出力に記載されているすべての問題を修正します。問題の修正の詳細は、「Oracle Databaseのアップグレードでのアップグレード前情報ツールの警告および推奨事項」を参照してください。
「アップグレードのためのOracle Databaseのバックアップ」の説明に従って、ソース・データベースをバックアップします。
まだ実行していない場合は、「アップグレードのための新しいOracleホームの準備」の記載に従って、新しいOracleホームを準備します。
データベースを停止します。(構文は、非CDBとCDBで同じです。)
SQL> SHUTDOWN IMMEDIATE
|
注意: PDBを閉じるには、CDBルートから次のように指定できます:alter pluggable database PDBname close |
ご使用のオペレーティング・システムがWindowsの場合、次の手順を実行します。
アップグレードするデータベースのOracleサービスOracleServiceSIDを停止します(SIDはインスタンスの名前です)。たとえば、SIDがORCLの場合、コマンド・プロンプトで次のように入力します。
C:\> NET STOP OracleServiceORCL
コマンド・プロンプトで、ORADIMを使用してOracleサービスを削除します。詳細は、「WindowsでOracle Databaseのアップグレード時に使用するORADIMの変数」を参照してください。ORADIMの構文およびコマンドのリストは、ご使用のプラットフォームのガイドも参照してください。
SIDがORCLの場合、次のコマンドを入力します。実際のSIDの名前で置き換えます。
C:\> ORADIM -DELETE -SID ORCL
次の例に示すとおり、新しいOracle DatabaseリリースのORADIMコマンドをコマンド・プロンプトで使用して、Oracle Database 12cのサービスを作成します。
C:\> ORADIM -NEW -SID SID -SYSPWD PASSWORD -MAXUSERS USERS -STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA
ほとんどのOracle Databaseサービスは、Oracleホーム・ユーザーの権限を使用してシステムにログオンします。サービスは、このユーザーの権限を使用して実行されます。ORADIMコマンドは、このユーザー・アカウントのパスワードを要求します。ORADIMを使用して、他のオプションを指定できます。
この例で、SIDがORCL、password (SYSPWD)がTWxy5791、ユーザーの最大数(MAXUSERS)が10、ORACLE_HOMEディレクトリがC:\ORACLE\PRODUCT\11.2.0\DBの場合、次のコマンドを入力します。
C:\> ORADIM -NEW -SID ORCL -SYSPWD TWxy5791 -MAXUSERS 10 -STARTMODE AUTO -PFILE C:\ORACLE\PRODUCT\11.2.0\DB\DATABASE\INITORCL.ORA
ORADIMによって、ORACLE_HOME\databaseディレクトリにログが書き込まれます。ログ・ファイルには、マルチテナント・データベース内のPDBの名前が含まれています。
ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の内容を確認します。
ORACLE_SIDが正しく設定されていること。
oratabファイルがOracle Database 12cのOracleホームを指していること。
次の環境変数がOracle Database 12cのディレクトリを指していること。
ORACLE_HOME
PATH
ORACLE_HOME値を設定するためにクライアントで使用するすべてのスクリプトが、新しいOracleホームを指している必要があります。
|
注意: クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。 |
|
関連項目: ご使用のオペレーティング・システムでのその他の重要な環境変数の設定に関する詳細は、オペレーティング・システム固有の『Oracle Databaseインストレーション・ガイド』を参照してください。 |
新しいOracle Database 12cのOracleホームの所有者として、システムにログインします。
ORACLE_HOME/rdbms/adminディレクトリから、SQL*Plusを起動します。
アップグレード対象のデータベースにDBA権限のあるアカウントを使用して接続します。
SQL> CONNECT / AS SYSDBA
アップグレード・モードでCDBを開始します。
SQL> startup upgrade
SQL*Plusで次のコマンドを発行して、インスタンスを起動します。
SQL> alter pluggable database all open upgrade;
|
注意: UPGRADEキーワードを使用すると、前のOracle Databaseリリースをベースとするデータベースをオープンできます。また、AS SYSDBAセッションへのログオンの制限、システム・トリガーの無効化、およびアップグレードの環境を準備するその他の操作も実行されます。 |
初期化パラメータ・ファイルPFILEの場所を指定します。初期化パラメータの起動時の指定および初期化パラメータ・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。
SQL*Plusを終了したら、次の手順に進みます。
CDB全体をアップグレードするには、この手順の説明に従って、新しいOracleホームからcatctl.plスクリプトを実行します。パラレル・アップグレード・ユーティリティ(catctl.pl)によって、停止時間を短縮するパラレル・アップグレード・オプションが提供されています。
Linuxでは、次のようにcatctl.plを実行します。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql
Windowsでは、次のようにcatctl.plを実行します。
cd %ORACLE_HOME%\rdbms\admin %ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql
|
注意:
|
CDB内のPDBのサブセットをアップグレードするために、この手順の例に示すように、包含リストまたは除外リストのいずれかを指定できます。
PDB1のみをアップグレードするための包含リストは、次のとおりです。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -c 'PDB1' catupgrd.sql
PDB1を除くCDB内のすべてをアップグレードするための除外リストは、次のとおりです。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -C 'PDB1' catupgrd.sql
|
注意: 特定のPDBを切断してからCDBに接続することにより、そのPDB自体でアップグレードすることもできます。これは、「プラガブル・データベース(PDB)のアップグレード」で説明しています。Windowsでは、CDBルート名およびPDBシード名を引用符で囲んだ-Cオプションを指定する必要があります。たとえば、次のようになります。 ... |
重要: catuppst.sqlスクリプトは、アップグレード処理中にエラーが戻されないかぎり、アップグレード処理の一部として実行されます。ログ・ファイルで「Started: catuppst.sql」を検索して、アップグレード処理中にcatuppst.sqlが実行されたことを確認します。catuppst.sqlが実行されていない場合は、この手順に示されているcatuppst.sqlの実行に進みます。catctl.plを実行すると、アップグレード中にcatuppst.sqlが実行されなかったことを示す警告メッセージも表示されます。
次のようにcatuppst.sqlを実行します。
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b catuppst -d '''.''' catuppst.sql
ログ・ファイルcatuppst0.logは、アップグレード後の結果を記録して生成されます。
catcon.plを実行して、utlrp.sqlを起動し、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。次の構文を使用します。
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql
ログ・ファイルutlrp0.logは、再コンパイルの結果を記録して生成されます。
utlu121s.sqlを実行して、すべての問題が修正されたことを確認します。
CDBの場合:
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlu121s -d '''.''' utlu121s.sql
非CDBの場合:
SQL> @rdbms/admin/utlu121s.sql
ログ・ファイルutlu121s0.logは、アップグレード結果を記録して生成されます。
データベースの状態に関する情報を確認するには、アップグレードの完了後、いつでも何回でもutlu121s.sqlを実行できます。utlu121s.sqlスクリプトからエラーが戻されたり、VALIDでないか、または最新のリリースのものではないコンポーネントが表示された場合は、詳細を「Oracle Databaseのアップグレードのトラブルシューティング」で確認してください。
予測されるすべてのパッケージおよびクラスが有効であることを確認します。(この手順は、アップグレードを開始する前にpreupgrd.sqlが実行済であることを前提としています。)
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utluiobj -d '''.''' utluiobj.sql
ログ・ファイルutluiobj0.logは、検証の結果を記録して生成されます。
|
注意: アップグレード前情報ツールでINVALIDオブジェクトが検出され、registry$sys_inv_objs表およびregistry$nonsys_inv_objs表に移入された場合は、ORACLE_HOME/rdbms/admin/utluiobj.sqlを実行して、アップグレード処理の結果、新しく無効になったオブジェクトのみを表示します。このutluiobj.sqlスクリプトを実行すると、アップグレード前はVALIDであったが、現在はINVALIDであるオブジェクトのみが表示されます。「アップグレード前情報ツール(preupgrd.sql)の使用方法」を参照してください。 |
この時点で、タイムゾーン・データ・ファイルが現行のものであることを確認できます。タイムゾーンを更新する必要がある場合、CDB$ROOTとPDBデータベースの両方のタイムゾーンを更新する必要があります。この調整は、アップグレード後に行うこともできます。
「Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード」を参照してください。
(たとえば非CDBなどで)SQL*Plusをまだ起動している場合は終了します。
リリース10.2、11.1または11.2からクラスタ・データベースをアップグレードする場合は、次のコマンドを使用してOracle Clusterwareのデータベース構成をアップグレードしてください。
$ srvctl upgrade database -d db-unique-name -o oraclehome
ここで、db-unique-nameは(インスタンス名ではなく)割り当てられたデータベース名であり、oraclehomeは、データベースがアップグレードされるOracleホームの場所です。SRVCTLユーティリティでは、以前のリリースで使用されていた短いCLIオプションに加えて、GNUスタイルの長いオプションもサポートされます。
これで、データベースがOracle Database 12cにアップグレードされました。第4章「Oracle Databaseのアップグレード後の作業」に示す手順を完了する準備ができました。
|
注意: Oracle Warehouse Builder(OWB)コンポーネントはOracle Databaseアップグレード処理の一部としてアップグレードされません。Oracle Warehouse Builderは、Oracle Database 12cの一部としてインストールされません。詳細は、「Oracle Warehouse Builder (OWB)を使用しているデータベースのアップグレードの要件」を参照してください。 |
|
注意: 古いOracleソフトウェアを保持している場合、古いソフトウェアを使用してアップグレードしたデータベースを起動しないでください。新しいOracle Databaseインストールの実行可能ファイルでのみデータベースを起動してください。また、古いOracle環境を削除する前に、古いOracle環境にあるデータ・ファイルをすべて新しいOracle Database環境に再配置してください。データ・ファイルの再配置の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Database 12cでは、アップグレード処理およびアップグレードされたデータベースのアップグレード・ステータスの表示方法が改善されました。
次の各項目では、データ・ディクショナリのオブジェクトのパフォーマンスとステータスに影響する変更について説明します。
現在、Oracle Databaseのデータ・ディクショナリのアップグレードは、catctl.plユーティリティを使用してパラレルで行われますが、これによりアップグレード処理が高速化されます。1つのSQL処理がデータ・ディクショナリをロードするのではなく、CPU性能に応じて複数の処理が可能になりました。catctl.plユーティリティによってデータがディクショナリに可能なかぎり高速にロードされ、アップグレード・モードではなく通常モードで実行可能な作業を遅らせます。この方法によるデータベースのアップグレードでは、全体の停止時間が短縮されます。
アップグレード完了時にエラーがない場合は、データベースのステータスはUPGRADEDに設定されます。この動作は、アップグレード後にデータベースのステータスがVALIDに設定されていた以前のリリースとは異なります。UPGRADEDステータスは、データ・ディクショナリが、エラーなくロードされたことを示します。エラーがregistry$errorに記録されている場合、アップグレードのステータスはINVALIDに設定されます。
Oracle Databaseの以前のリリースでは、データベースのアップグレード後のVALIDは、データ・ディクショナリのすべてのオブジェクトが再コンパイルされ、使用の準備ができたことを意味しました。Oracle Database 12cでは、VALIDステータスを取得することは異なります。utlrp.sqlスクリプトを通常モードで実行し、データ・ディクショナリのオブジェクトを再コンパイルしてそのデータ・ディクショナリをUPGRADEDステータスからVALIDステータスに移動します。
データベースのアップグレードが有効かどうかは、アップグレード後、アップグレードされたデータベースが最初に起動される前にutlrp.sqlが実行されるまで保証できません。アップグレードの実行後にutlrp.sqlを実行しないと、データ・ディクショナリのオブジェクトの再コンパイルが最初のアクセス中に強制されます。データベースに最初にアクセスするユーザーは、この時点で無効な各オブジェクトがアクセスされることによるパフォーマンス・ヒットの影響を受けます。無効なオブジェクトの再コンパイルが完了すると、通常の処理に戻ります。utlrp.sqlを実行すると、アップグレード後にデータベースを使用する準備が整います。検出されたエラーは、ただちにレポートされ、アップグレードしたデータベースのユーザーが問題に遭遇する前に修正できます。
Oracle Databaseの以前のリリースでは、アップグレードの処理にcatupgrd.sqlアップグレード・ユーティリティを使用していました。Oracle Database 12cからは、catupgrd.sqlを置換し、パラレル処理モードとシリアル・モードの両方が提供されるcatctl.plパラレル・アップグレード・ユーティリティを使用することを強くお薦めします。catupgrd.sqlに関する情報は、任意のカスタム・スクリプトとの下位互換性またはアップグレードで使用する処理について、この項で説明します。catupgrd.sqlスクリプトは、Oracle Database 12c環境から実行する必要があります。
|
注意: catupgrd.sqlを単独で実行した場合は、catuppst.sqlはアップグレード処理の一部として実行されません。catuppst.sqlスクリプトは、catupgrd.sqlの完了後に実行する必要があります。 |
catupgrd.sqlスクリプトを実行すると、特定のデータ・ディクショナリ表を作成して変更します。また、新しいOracle Database 12cデータベースの次のデータベース・コンポーネントも、アップグレードまたはインストールされます。
Oracle Database Catalog Views
Oracle Database Packages and Types
JServer JAVA Virtual Machine
Oracle Database Java Packages
Oracle XDK
Real Application Clusters
Oracle Workspace Manager
Oracle Multimedia
Oracle XML Database
OLAPアナリティック・ワークスペース
Oracle OLAP API
Oracle Text
Oracle Spatial and Graph
Oracle Data Mining
Oracle Label Security
Messaging Gateway
Oracle Database Vault
Oracle Application Express
catuppst.sqlスクリプトでは、アップグレード中に情報メッセージおよびログ・ファイルが生成されます。DBUAおよびcatctl.plではcatuppst.sqlは自動的に実行されます。手動アップグレード中にエラーが発生した場合は、このスクリプトを個別に実行します。
ORACLE_HOME/rdbms/adminディレクトリにあるcatuppst.sqlスクリプトは、データベースをUPGRADEモードにする必要のない、残りのアップグレード操作を実行します。また、このスクリプトは、最新のOracleパッチ・セット更新(PSU)を自動的に適用します。
catuppst.sqlの出力の例は次のとおりです。
Generating apply and rollback scripts...
Check the following file for errors:
Apply script: .*
Rollback script: .*
Executing script file...
Updating registry...
Check the following log file for errors:
Generating apply and rollback scripts...
Check the following file for errors:
.../cfgtoollogs/catbundle/catbundle_PSU_*.log
Apply script:
.../rdbms/admin/catbundle_PSU_*_APPLY.sql
Rollback script:
.../rdbms/admin/catbundle_PSU_*_ROLLBACK.sql
Executing script file...
Updating registry...
Check the following log file for errors:
.../cfgtoollogs/catbundle/catbundle_PSU_PDB_name.log
Oracle Data Pumpのフル・トランスポータブル・エクスポート/インポート機能では、2つのオプションが提供されています(詳細は、『Oracle Database管理者ガイド』を参照)。次の2つのオプションがあります。
ファイルベースのOracle Data Pumpエクスポート/インポートの使用
ファイルベースでないネットワーク・モードのOracle Data Pumpインポートの使用
|
関連項目:
|
データベースのアップグレード時に発生する可能性のあるエラーや問題について、トラブルシューティングのヒントを提供しています。今回のリリースに影響する重要な変更について、第8章「Oracle Database 12cで非推奨となった機能とサポートが終了した機能」を必ず確認してください。
この項には次のトピックが含まれます:
一度データベースをアップグレード・モードで起動すると、catctl.plスクリプトを実行するまでは、固定ビューへの問合せのみ、エラーにならずに実行できます。アップグレード・スクリプトを実行する前は、他のビューへの問合せやPL/SQLの実行で、エラーが戻されます。
この項に記載されているエラーは、新しいOracle Database 12cデータベースの起動を試みると発生する可能性があります。これらのエラーの一部はアラート・ログに記録され、セッションには表示されません。いずれかのエラーが表示された場合、 SHUTDOWN ABORTコマンドでデータベースを停止し、問題を修正します。
ORA-00401: パラメータcompatibleの値はこのリリースではサポートされません。
COMPATIBLE初期化パラメータが11.0.0未満に設定されている場合。
ORA-39700: データベースは、UPGRADEオプションを使用してオープンしてください
UPGRADEキーワードを指定しないでSTARTUPコマンドを発行した場合。
|
関連項目: My Oracle Support (http://support.oracle.com)の「Ora-00704、Ora-39700: Database Must Be Opened With Upgrade Option」(Doc ID 1349722.1) |
ORA-00336: ログ・ファイルのサイズxxxxが最小値8192より小さくなっています
REDOログのサイズが4MB未満の場合。
サポートが終了した初期化パラメータを示すエラーが表示された場合は、そのサポートが終了した初期化パラメータを記録し、アップグレードを継続します。次回、データベースを停止したときに、そのサポートが終了した初期化パラメータを削除します。
データベースをアップグレードする際、DBUAはソース(12cより前)のOracleホームと宛先(新規の12c)のOracleホームを同じユーザーが所有していることを想定しています。ご使用の環境でこれが該当しない場合は、データベース・ファイルの権限を変更し、DBUAに追加のパラメータを渡す必要があります。そうしないと、DBUAの「前提条件チェック」ページに「upgrade.xml not found」エラーが表示され、アップグレードを続行できなくなります。
まず、すべてのデータベース・ファイル(データ・ファイル、REDOファイル、制御ファイル、アーカイブ・ログ宛先、リカバリ領域、Spfileおよびパスワード・ファイル)が新しい12cと12cより前の両方のバイナリ所有者によって読取りおよび書込み可能であることを確認します。これは、両方のユーザーを同じグループ(oinstallなど)に置き、このグループにすべてのデータベース・ファイルへの読取り/書込みアクセスを付与することによって行うことができます。
-logdirコマンドライン・スイッチを指定してDBUAを実行し、12cと12cより前の両方のバイナリ所有者が書込みできるディレクトリ(/tmpなど)を指定します。DBUAはこのディレクトリを使用してアップグレード前情報ツール(12cより前のバイナリ所有者が実行する12cより前のインスタンスで実行します)からの出力、および12cのバイナリ所有者によってアップグレード時に生成されるDBUAログを格納します。
たとえば、コマンドラインで次のようにDBUAを実行します。
dbua -logdir /tmp
アップグレードの開始前にアップグレード前情報ツールを実行しなかった場合、catctl.plおよびcatupgrd.sqlスクリプトが次のエラーで終了します。
ORA-00942: table or view does not exist ORA-00904: "TZ_VERSION": invalid identifier ORA-01722: invalid number
これらのエラーのいずれかが発生した場合は、SHUTDOWN ABORT文を発行します。次に、元のOracleホーム・ディレクトリに戻し、「Oracle Databaseのアップグレード前情報ツールの概要」の記載に従って、アップグレード前情報ツール(ultu121i.sql)を実行します。
アップグレードを開始する前に、アップグレード前情報ツール(preupgrd.sql)を実行することを強くお薦めします。
アップグレード前情報ツールは、無効なSYSおよびSYSTEMオブジェクトと他の無効なオブジェクトを識別します。utlrp.sqlを使用して、無効なオブジェクトを再コンパイルします。アップグレード前にこの処理を実行できない場合、アップグレードを開始する前に無効だったシステムのオブジェクトおよびアップグレードの結果として無効になるオブジェクトを判別することが難しくなります。
アップグレードが完了するまで、新しいOracle Database 12.1リリース(utlu121s.sql)のアップグレード後ステータス・ツールを実行しないでください。
アップグレード・プロセスが完了し、utlrp.sqlを実行した後にのみ、アップグレード後ステータス・ツールを実行することをお薦めします。@utlrp.sqlを実行する前にアップグレード後ステータス・ツールを実行すると、ツールの出力に正確な最終コンポーネント・ステータス値が表示されない場合があります。utlrp.sqlを実行する前にツールを実行すると、コンポーネント・ステータス値に最終状態が適切に反映されない場合があります。utlrp.sqlの実行後にのみ、最終コンポーネント状態を決定できます。
アップグレード中にリソースが不足した場合は、リソースの割当てを増やします。リソースの割当てを増やした後、SHUTDOWN ABORTを実行し、インスタンスを(UPGRADEモードで)再起動してから、catupgrd.sqlスクリプトを再実行するか、またはDBUAを再起動する必要があります。
通常、Oracle Databaseの新しいリリース用に増やす必要があるリソースは、次のとおりです。
通常、SYSTEM表領域のサイズが不十分な場合、アップグレード中に次のエラー・メッセージが表示されます。
ORA-01650: unable to extend rollback segment string by string in tablespace string ORA-01651: unable to extend save undo segment by string for tablespace string ORA-01652: unable to extend temp segment by string in tablespace string ORA-01653: unable to extend table string.string by string in tablespace string ORA-01654: unable to extend index string.string by string in tablespace string ORA-01655: unable to extend cluster string.string by string in tablespace string
これらのエラーを回避するには、SYSTEMおよびSYSAUX表領域にAUTOEXTEND ON MAXSIZE UNLIMITEDを設定します。
より大きな共有メモリーのプール・サイズが必要な場合があります。増やす必要がある共有メモリーの初期化パラメータが、エラー・メッセージに示されます。
ORA-04031: unable to allocate string bytes of shared memory ("string","string","string","string")
|
関連項目: 手動の共有メモリー管理の使用の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
ロールバック・セグメントを使用している場合、アップグレード・スクリプトの実行中は、1つの大きい(100MBの)パブリック・ロールバック・セグメントをオンラインにする必要があります。小さいパブリック・ロールバック・セグメントは、アップグレード中はオフラインにする必要があります。通常、ロールバック・セグメントのサイズが不十分な場合は、次のエラーが表示されます。
ORA-01562: failed to extend rollback segment number string
UNDO表領域を使用している場合は、400MB以上であることを確認してください。
高速リカバリ領域を使用していてアップグレード中にこの領域が一杯になった場合は、アラート・ログに次のエラーが表示され、その後に問題から復旧するためのアドバイスが表示されます。
ORA-19815: WARNING: db_recovery_file_dest_size of string bytes is 98.99% used, and has string remaining bytes available.
問題の根本原因を特定し、アップグレードを続行するための適切な対処を行います。アップグレード中にこの問題が発生しないようにするには、アップグレードを開始する前に、高速リカバリ領域内の使用可能な領域を増やします。
アップグレード・スクリプトまたはSQL*Plusで実行するコマンドでEDITIONパラメータを設定すると、それ以降はOracle Databaseが適切に起動できなくなり、エラー「SP2-1540: Oracle Databaseはエディション・セッションでは起動できません。」がスローされます。この問題を回避するには、このパラメータが変更されるcatugrd.sqlまたはSQL*Plusセッションを実行した後に、そのSQL*Plusセッションを終了し、別のセッションでそのインスタンスを再起動します。
索引に関するORA-01408エラーは、データベース内に異なる名前で同じ索引が存在するために発生する、Oracle Applicationデータベースの既知の問題です。
SQL> create index system.repcat$_audit_column_f2_idx on
2 system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
3 base_reference_name)
4 /
system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
*ERROR at line 2:
ORA-01408: such column list indexed
回避策として、REPCAT$_AUDIT_COLUMN_IDX1索引を削除し、「Oracle Databaseのアップグレードの再実行」の説明に従って再度アップグレードを実行します。
Oracle Grid Infrastructureを使用していてOracle RACリリース11.1.0.7データベースを作成する場合、セッション処理に対するDBCAのデフォルトを増やす必要がある場合があります。Oracle Database 12cでは、処理に対するDBCAのデフォルトの値は300に設定されています。以前のリリースでは、DBCAのデフォルト設定値は150でした。
エラー・メッセージ「ORA-00018:maximum number of session exceeded」が表示された場合は、DBCAのセッション処理に対するデフォルト値を300に変更します。その後、DBCAは、Oracle Grid Infrastructureリリース12.1で使用するリリース11.1.0.7データベースの作成に成功します。
このエラーは、使用するOracle構成にリコンパイルに必要な数のプロセスがないことを示します。ドキュメントを参照して、PROCESSESパラメータの設定に関する詳細を確認します。
|
関連項目: Oracle Databaseリファレンス |
Oracle Database 12cにアップグレードした後、DBMS_DSTパッケージを実行すると、「ORA-01882: タイムゾーンのリージョンが見つかりません」エラーが発生する場合があります。
このエラーは、タイムゾーン・ファイルのバージョンが誤って設定されていることが原因で、データベースに複数のタイムゾーン地域のIDが不正に格納されている場合に戻されます。次に例を示します。
ERROR at line 1: @ ORA-01882: time zone region not found @ ORA-06512: at "SYS.DBMS_DST", line 113 @ ORA-06512: at "SYS.DBMS_DST", line 1101 @ ORA-06512: at line 1
この問題を解決するには、「TIMESTAMP WITH TIME ZONEデータ型に対するOracle Databaseの警告の概要」の説明に従ってタイムゾーンのバージョンを更新し、「Oracle Databaseのアップグレードの再実行」の説明に従ってアップグレードを再実行します。
Windowsプラットフォームでは、アップグレード中にサーバーが再起動した場合に、ADVMドライバまたはACFSドライバ関連のエラーが発生する可能性があります。次のエラー・メッセージが表示されることがあります。
最初のノード(アップグレードを開始したノード)以外のノードで、次の手順を実行します。
エラーが発生したノードを再起動します。
そのノード上で、rootスクリプトを再度実行します。
最初のノード(アップグレードを開始したノード)で、次の手順を実行します。
クラスタ内のその他すべてのノードのアップグレードを完了します。
最初のノードを再起動します。
最初のノード上で、rootスクリプトを再度実行します。
アップグレードを完了するには、rootでログインし、パスGrid_home/cfgtoollogs/configToolAllCommandsにあるスクリプトconfigToolAllCommandsを実行します。
|
関連項目: クラスタのアップグレードの問題のトラブルシューティングの詳細は、使用しているオペレーティング・システムの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
utlu121s.sqlアップグレード後の状態ツールには、アップグレード後に、データベース・コンポーネントの状態が表示されます。このツールは、アップグレード後にいつでも(アップグレード後または無効なオブジェクトの再コンパイル後)、utlrp.sqlを使用して実行できます。サマリー・レポートの例は、「アップグレード後の状態ツール(utlu121s.sql)のアップグレード・サマリー・レポートのサンプル」に記載されています。
次のリストでは、表示される可能性のある状態の値を簡単に説明します。
アップグレードの完了時に、コンポーネントの一部のオブジェクトが無効でした。コンポーネントのアップグレード中にエラーが発生しなかった場合は、アップグレード全体を再実行しなくても、utlrp.sqlを実行することで、状態がVALIDに変わる可能性があります。utlrp.sqlを実行した後に、DBA_REGISTRYビューを確認します。「Oracle Databaseのアップグレード用スクリプト」を参照してください。
VALID
コンポーネントは有効で、エラーがありません。
LOADING
コンポーネントはロード中です。
LOADED
コンポーネントは正常にロードが終了しました。
UPGRADING
コンポーネントはアップグレードの処理中です。
コンポーネントはアップグレードが完了し、エラーがありません。
DOWNGRADING
コンポーネントはダウングレードの処理中です。
DOWNGRADED
コンポーネントはダウングレードが完了し、エラーがありません。
REMOVING
コンポーネントは削除の処理中です。
データベースから削除されたため、コンポーネントはアップグレードされませんでした。
コンポーネントに必要なサーバー・オプションがインストールされていないか、またはサーバーとリンクされていません。V$OPTIONビューおよびインストール・ログを確認します。コンポーネントをインストールするか、必要なオプションをサーバーに再リンクしてから、catctl.plを再実行します。「Oracle Databaseのアップグレード用スクリプト」を参照してください。
コンポーネント・アップグレード・スクリプトがORACLE_HOMEに見つかりませんでした。インストール・ログを確認し、コンポーネント・ソフトウェアをインストールし、catctl.plを再実行します。「Oracle Databaseのアップグレード用スクリプト」を参照してください。
アップグレード後の状態ツールによって、アップグレード・サマリー・レポートが作成されます。例3-2「アップグレード後の状態ツールのアップグレード・サマリー・レポート」に示すように、アップグレード・サマリー・レポートには、データベース内のすべてのコンポーネントのステータスが含まれています。例は、マルチテナント・コンテナ・データベース(CDB)およびプラガブル・データベース(PDB)のレポートを示しています。
アップグレードが完了すると、レポートのコピーは、次のいずれかの場所に配置されます。
$ORACLE_BASE/cfgtoollogs/db-unique-name/upgrade/upg_summary.rpt
$ORACLE_HOME/cfgtoollogs/db-unique-name/upgrade/upg_summary.rpt
$ORACLE_HOME/rdbms/logs/upg_summary.rpt
場所は、utlu121s.sqlがレポートの作成に使用する順序で示されます。最初のディレクトリ・スキームの下にレポートを作成できない場合、2番目、3番目の場所で試行してから、レポートの書込みをこれ以上試行しなくなります。
例3-2 アップグレード後の状態ツールのアップグレード・サマリー・レポート
Oracle Database 12.1 Post-Upgrade Status Tool 06-12-2014 20:37:07 . CDB$ROOT:1 Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . UPGRADED 12.1.0.2.0 00:14:26 JServer JAVA Virtual Machine . VALID 12.1.0.2.0 00:05:50 Oracle Real Application Clusters . OPTION OFF 12.1.0.2.0 00:00:01 Oracle Workspace Manager . VALID 12.1.0.2.0 00:01:19 Oracle Label Security . VALID 12.1.0.2.0 00:00:11 Oracle XDK . VALID 12.1.0.2.0 00:00:59 Oracle Text . VALID 12.1.0.2.0 00:00:32 Oracle XML Database . VALID 12.1.0.2.0 00:01:40 Oracle Database Java Packages . VALID 12.1.0.2.0 00:00:21 Oracle Multimedia . VALID 12.1.0.2.0 00:03:43 Oracle Database Vault . VALID 12.1.0.2.0 00:00:13 Post Upgrade . 00:01:25 Final Actions . 00:00:15 Total Upgrade Time: 00:31:47 PL/SQL procedure successfully completed. Elapsed: 00:00:00.11 . Oracle Database 12.1 Post-Upgrade Status Tool 06-12-2014 21:00:02 . PDB$SEED:2 Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . UPGRADED 12.1.0.2.0 00:13:19 JServer JAVA Virtual Machine . VALID 12.1.0.2.0 00:02:24 Oracle Real Application Clusters . OPTION OFF 12.1.0.2.0 00:00:01 Oracle Workspace Manager . VALID 12.1.0.2.0 00:00:51 Oracle Label Security . VALID 12.1.0.2.0 00:00:06 Oracle XDK . VALID 12.1.0.2.0 00:00:40 Oracle Text . VALID 12.1.0.2.0 00:00:11 Oracle XML Database . VALID 12.1.0.2.0 00:00:48 Oracle Database Java Packages . VALID 12.1.0.2.0 00:00:11 Oracle Multimedia . VALID 12.1.0.2.0 00:01:41 Oracle Database Vault . VALID 12.1.0.2.0 00:00:12 Post Upgrade . 00:01:19 Final Actions . 00:00:01 Total Upgrade Time: 00:22:24 PL/SQL procedure successfully completed. Elapsed: 00:00:00.08 . Oracle Database 12.1 Post-Upgrade Status Tool 06-12-2014 21:24:16 . CDB1_PDB1:3 Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . UPGRADED 12.1.0.2.0 00:13:05 JServer JAVA Virtual Machine . VALID 12.1.0.2.0 00:03:01 Oracle Real Application Clusters . OPTION OFF 12.1.0.2.0 00:00:02 Oracle Workspace Manager . VALID 12.1.0.2.0 00:01:01 Oracle Label Security . VALID 12.1.0.2.0 00:00:06 Oracle XDK . VALID 12.1.0.2.0 00:00:45 Oracle Text . VALID 12.1.0.2.0 00:00:15 Oracle XML Database . VALID 12.1.0.2.0 00:00:55 Oracle Database Java Packages . VALID 12.1.0.2.0 00:00:17 Oracle Multimedia . VALID 12.1.0.2.0 00:01:59 Oracle Database Vault . VALID 12.1.0.2.0 00:00:10 Post Upgrade . 00:01:18 Final Actions . 00:00:01 Total Upgrade Time: 00:23:33 PL/SQL procedure successfully completed. Elapsed: 00:00:00.12 . Oracle Database 12.1 Post-Upgrade Status Tool 06-12-2014 21:27:03 . CDB1_PDB2:4 Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . UPGRADED 12.1.0.2.0 00:14:01 JServer JAVA Virtual Machine . VALID 12.1.0.2.0 00:03:11 Oracle Real Application Clusters . OPTION OFF 12.1.0.2.0 00:00:02 Oracle Workspace Manager . VALID 12.1.0.2.0 00:01:05 Oracle Label Security . VALID 12.1.0.2.0 00:00:07 Oracle XDK . VALID 12.1.0.2.0 00:00:49 Oracle Text . VALID 12.1.0.2.0 00:00:12 Oracle XML Database . VALID 12.1.0.2.0 00:00:54 Oracle Database Java Packages . VALID 12.1.0.2.0 00:00:15 Oracle Multimedia . VALID 12.1.0.2.0 00:02:03 Oracle Database Vault . VALID 12.1.0.2.0 00:00:13 Post Upgrade . 00:01:18 Final Actions . 00:00:01 Total Upgrade Time: 00:24:51 PL/SQL procedure successfully completed. Elapsed: 00:00:00.11 . Oracle Database 12.1 Post-Upgrade Status Tool 06-12-2014 21:49:18 . CDB1_PDB3:5 Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . UPGRADED 12.1.0.2.0 00:13:57 JServer JAVA Virtual Machine . VALID 12.1.0.2.0 00:03:01 Oracle Real Application Clusters . OPTION OFF 12.1.0.2.0 00:00:02 Oracle Workspace Manager . VALID 12.1.0.2.0 00:01:07 Oracle Label Security . VALID 12.1.0.2.0 00:00:07 Oracle XDK . VALID 12.1.0.2.0 00:00:46 Oracle Text . VALID 12.1.0.2.0 00:00:12 Oracle XML Database . VALID 12.1.0.2.0 00:00:58 Oracle Database Java Packages . VALID 12.1.0.2.0 00:00:13 Oracle Multimedia . VALID 12.1.0.2.0 00:02:10 Oracle Database Vault . VALID 12.1.0.2.0 00:00:13 Post Upgrade . 00:01:17 Final Actions . 00:00:01 Total Upgrade Time: 00:24:42 PL/SQL procedure successfully completed. Elapsed: 00:00:00.10 . Oracle Database 12.1 Post-Upgrade Status Tool 06-12-2014 21:51:15 . CDB1_PDB4:6 Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . UPGRADED 12.1.0.2.0 00:13:41 JServer JAVA Virtual Machine . VALID 12.1.0.2.0 00:02:48 Oracle Real Application Clusters . OPTION OFF 12.1.0.2.0 00:00:04 Oracle Workspace Manager . VALID 12.1.0.2.0 00:00:58 Oracle Label Security . VALID 12.1.0.2.0 00:00:07 Oracle XDK . VALID 12.1.0.2.0 00:00:40 Oracle Text . VALID 12.1.0.2.0 00:00:15 Oracle XML Database . VALID 12.1.0.2.0 00:00:50 Oracle Database Java Packages . VALID 12.1.0.2.0 00:00:16 Oracle Multimedia . VALID 12.1.0.2.0 00:02:04 Oracle Database Vault . VALID 12.1.0.2.0 00:00:15 Post Upgrade . 00:01:16 Final Actions . 00:00:01 Total Upgrade Time: 00:23:54 PL/SQL procedure successfully completed. Elapsed: 00:00:00.08 . Oracle Database 12.1 Post-Upgrade Status Tool 06-12-2014 22:08:18 . CDB1_PDB5:7 Component Current Version Elapsed Time Name Status Number HH:MM:SS . Oracle Server . UPGRADED 12.1.0.2.0 00:09:42 JServer JAVA Virtual Machine . VALID 12.1.0.2.0 00:02:31 Oracle Real Application Clusters . OPTION OFF 12.1.0.2.0 00:00:01 Oracle Workspace Manager . VALID 12.1.0.2.0 00:00:52 Oracle Label Security . VALID 12.1.0.2.0 00:00:05 Oracle XDK . VALID 12.1.0.2.0 00:00:42 Oracle Text . VALID 12.1.0.2.0 00:00:13 Oracle XML Database . VALID 12.1.0.2.0 00:00:44 Oracle Database Java Packages . VALID 12.1.0.2.0 00:00:12 Oracle Multimedia . VALID 12.1.0.2.0 00:01:44 Oracle Database Vault . VALID 12.1.0.2.0 00:00:12 Post Upgrade . 00:01:08 Final Actions . 00:00:01 Total Upgrade Time: 00:18:44 PL/SQL procedure successfully completed. Elapsed: 00:00:00.08 .
Standard Edition(SE)の初期データベースをアップグレードする場合、初期データベースに付属していないコンポーネントは、Standard Editionにインストールされていないオプションが必要となるため、SEサーバーでアップグレードできません。
アップグレード後、コンポーネントをDBA_REGISTRYビューで参照すると、STATUSの値がOPTION OFFと表示され、関連付けられたコンポーネント・スキーマに無効なオブジェクトが含まれます。Database Upgrade Assistant(DBUA)には、これらのコンポーネントのアップグレードが失敗したことが表示されます。
Grid Infrastructureのアップグレード後、srvctl config asmを起動すると、コマンド出力にはOracle ASMパスワード・ファイルの場所は表示されません。パスワード・ファイルの場所は、新しいOracle ASMディスク・グループに自動的には渡されません。SRVCTLがアップグレード後のパスワード・ファイルの場所を特定できるようにするには、ディスク・グループの互換性の設定を拡張し、ディスク・グループにPWFILEを作成する必要があります。SRVCTLは、共有PWFILEの構成済の場所を報告するようになります。
ディスク・グループでの共有パスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』の手順を参照してください。
データベースのアップグレード時に、DBUAで障害が発生してエラー「ORA-27248: sys.dra_reevaluate_open_failuresが実行されています」が表示された場合、実行中のジョブDRA_REEVALUATE_OPEN_FAILURESが原因でアップグレードが失敗しています。このジョブが停止していることを確認する必要があります。
ジョブ定義でALLOW_RUNS_IN_RESTRICTED_MODEがTRUEに設定されている場合、このモード中にジョブの所有者がログインを許可されていると、データベースが制限またはアップグレード・モードのときにジョブの実行が許可されます。デフォルト設定はFALSEです。
次の問合せを使用して、実行されている可能性があるジョブの状態を確認できます。
SQL> select OBJECT_NAME, Owner, OBJECT_TYPE from dba_objects whereobject_name like '%DRA_REEVA%';
OLSを使用するデータベースおよびスタンバイ・データベースをアップグレードすると、ORA-16000 (データベースは読取り専用アクセスでオープンされています。)が表示される場合があります。スイッチオーバー後、プロビショニング・プロファイルは新しいプライマリの接続情報で更新される必要があります。そうしないと、ポリシーは新しいスタンバイ(古いプライマリ)への適用を続行し、ORA-16000で失敗します。Oracle Databaseリリース10g (10.1)以上からOracle Database 12cへのアップグレードに必要な追加の手順の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
初期化パラメータMAX_STRING_SIZEがEXTENDEDに設定されたが、32K移行がutl32k.sqlスクリプトの実行を完了していない場合、エラーが生成されます。データベース・アップグレードは、次のエラーで終了します。
SELECT TO_NUMBER('32K_MIGRATION_NOT_COMPLETED')
*
ERROR at line 1:
ORA-01722: invalid number
データベース・アップグレードではutl32k.sqlスクリプトを自動的に実行せず、32K移行を実行しません。
アップグレードおよびアップグレード後の32K移行を完了するには、次の手順を実行します。
初期化パラメータMAX_STRING_SIZEをSTANDARDにリセットします。
UPGRADEモードでデータベースを再起動します。
DBUAを使用するか、手動の手順でアップグレードを再実行します。
データベースをアップグレードした後で、初期化パラメータMAX_STRING_SIZEをEXTENDEDに設定します。
UPGRADEモードでデータベースを再起動します。
../rdbms/admin/utl32k.sqlを実行します。
アップグレードされたデータベースでは32K移行を完了し、EXTENDEDパラメータがサポートされます。
Cluster Ready Services (CRS)がすべてのノードで停止した場合、Oracle Automatic Storage Management (Oracle ASM)ではローリング移行状態が失われます。Oracle Databaseリリース11.2.0.2で、リリース12.1.0.2にアップグレードされる4つのノード(node1、node2、node3およびnode4)の次のシナリオを考えてみます。
node1およびnode2は12.1.0.2にアップグレードされ、実行中です。
node3およびnode4は11.2.0.2のままで、実行中です。
すべてのCRSスタックがダウンしている停止があると考えます。クラスタは異機種状態のままです(つまり、11.2.0.2に2ノード、12.1.0.2に2ノード)。
アップグレードを続行するには、リリース11.2.0.2のノード(つまり、node3またはnode4、あるいはその両方)のみを起動する必要があり、次のコマンドを実行する必要があります: 12.1.0.2ノードの起動前のnode3またはnode4のOracle ASMインスタンスでのALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.2'コマンド。
前述の手順を実行してOracle ASMクラスタをローリング移行に戻す前に、クラスタ内の異なるバージョンの2つのノードを起動できないことに注意してください。これを行った場合、Oracle ASMのバージョンの1つがORA-15153またはORA-15163のいずれかのエラー・メッセージで失敗します。
これ以降ですでに記載されているように、アップグレード手順を続行します。
リリース12.1.0.2の一部として、Oracleオブジェクト型の属性となるデータ型のバージョニングが導入されました(参照バグ18897657)。この機能により、リリース12.1.0.1データベースとリリース12.1.0.2データベースのバージョン間のレプリケーションは影響を受ける可能性があり、ORA-26656エラーが発生します。
ユーザー定義のオブジェクト型にDATE、TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE、BINARY_FLOAT、BINARY_DOUBLE、NCHAR、NVARCHAR2、NCLOB、ANYDATAなどの属性が含まれている場合、必須パッチ・セット更新18038108をリリース12.1.0.1のすべてのインスタンスに適用する必要があります。
この項で説明する問題は、リリース11.2.0.2のOracle Databaseのアップグレードに関するもののみです。
次のシナリオにより、ALTER TABLE EXCHANGE PARTITION文はエラーで失敗します。
11.2.0.2データベース上で、XMLType表またはパーティション化されたXMLType列を含む表を作成し、その表に構造化XMLIndexを作成します。次に、11.2.0.2データベースをOracle Database 12c以上にアップグレードします。同じ構造と類似のXMLIndexを持つOracle Database 12cデータベースで作成された別のパーティションまたは表とともに、実表のパーティションの1つでALTER TABLE EXCHANGE PARTITION文を実行する場合、次のエラーで失敗します。
ORA-64123: XMLIndex DDL: failure of a recursive DDL ORA-14097: column type or size mismatch in ALTER TABLE EXCHANGE PARTITION
索引が11.2.0.2以外のデータベースで作成された場合、これは問題ではありません。この問題を持つデータベース・リリースは11.2.0.2のみです。他のデータベース・リリース(11.2.0.1や11.2.0.3など)には、この問題はありません。
回避策は次のとおりです: Oracle Database 12c以上にアップグレードした後で、リリース11.2.0.2から索引をアップグレードした表で構造化XMLIndexを削除および再作成します。
Oracle Databaseをアップグレードするときに、DBUAまたはcatctl.plスクリプトを使用して、アップグレード処理を再実行できます。
次の方法を使用して、アップグレードを再実行できます。
catctl.plスクリプトを使用して、アップグレードを再実行できます。「マルチテナント・データベース(CDB)のアップグレードの再実行のオプション」も参照してください。
データベースを停止します。非CDBとCDBでは、構文は同じです。
SQL> SHUTDOWN IMMEDIATE
UPGRADEモードでデータベースを再起動します。
非CDBの場合:
SQL> STARTUP UPGRADE
CDBの場合:
SQL> STARTUP UPGRADE alter pluggable database all open upgrade;
catctl.plを再実行します。
|
注意: catctl.plスクリプトは、必要な回数だけ再実行できます。CDBの場合、特定のPDBに対してcatctl.plを再実行できます。たとえば、PDB1という名前のPDBの場合は、次のようになります。
$ORACLE_HOME/perl/bin/perl catctl.pl -n 4 -l $ORACLE_HOME/diagnostics catupgrd.sql -c 'PDB1' |
utlu121s.sql (アップグレード後の状態ツール)を実行します(これにより、スプール・ログにアップグレードのステータスのサマリーが表示されます)。utlu121s.sqlは、アップグレードの完了前または後のいつでも実行できます。
非CDBの場合:
SQL> @rdbms/admin/utlu121s.sql
CDBの場合:
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlu121s -d '''.''' utlu121s.sql
utlu121s.sqlスクリプトからエラーが戻されたり、VALIDでないか、または最新のリリースのものではないコンポーネントが表示された場合は、詳細を「Oracle Databaseのアップグレードのトラブルシューティング」で確認してください。
重要: catuppst.sqlスクリプトは、アップグレード処理中にエラーが戻されないかぎり、アップグレード処理の一部として実行されます。ログ・ファイルで「Started: catuppst.sql」を検索して、アップグレード処理中にcatuppst.sqlが実行されたことを確認します。catuppst.sqlが実行されていない場合は、この手順に示されているcatuppst.sqlの実行に進みます。catctl.plを実行すると、アップグレード中にcatuppst.sqlが実行されなかったことを示す警告メッセージも表示されます。
ORACLE_HOME/rdbms/adminディレクトリにあるcatuppst.sqlを、次のとおり実行します。
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b catuppst -d '''.''' catuppst.sql
ログ・ファイルcatuppst0.logは、アップグレード後の結果を記録して生成されます。
utlrp.sqlを実行して、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' utlrp.sql
ログ・ファイルutlrp0.logは、再コンパイルの結果を記録して生成されます。
予測されるすべてのパッケージおよびクラスが有効であることを確認します。
単一のPDB (この例ではPDB1)で、次のように標準モードでPDBを開きます。
alter pluggable database PDB1 open;
catcon.plを実行して、PDB内のutlrp.sqlを起動し、残りのすべてのストアドPL/SQLおよびJavaコードを再コンパイルします。次の構文を使用します。
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlrp -d '''.''' -c 'PDB1' utlrp.sql
非CDBの場合:
SQL> SELECT count(*) FROM dba_invalid_objects; SQL> SELECT distinct object_name FROM dba_invalid_objects;
CDB全体の場合:
SQL> ALTER SESSION SET CONTAINER = "CDB$ROOT" SQL> SELECT count(*) FROM dba_invalid_objects; SQL> SELECT distinct object_name FROM dba_invalid_objects; SQL> ALTER SESSION SET CONTAINER = "PDB$SEED" SQL> SELECT count(*) FROM dba_invalid_objects; SQL> SELECT distinct object_name FROM dba_invalid_objects; SQL> ALTER SESSION SET CONTAINER = "PDB1" SQL> SELECT count(*) FROM dba_invalid_objects; SQL> SELECT distinct object_name FROM dba_invalid_objects;
|
注意: アップグレード前情報ツールでINVALIDオブジェクトが検出され、registry$sys_inv_objs表およびregistry$nonsys_inv_objs表に移入された場合は、ORACLE_HOME/rdbms/admin/utluiobj.sqlを実行して、アップグレード処理の結果、新しく無効になったオブジェクトのみを表示します。このutluiobj.sqlスクリプトを実行すると、アップグレード前はVALIDであったが、現在はINVALIDであるオブジェクトのみが表示されます。 |
utlu121s.sqlを再度実行して、すべての問題が修正されたことを確認します。
非CDBの場合:
SQL> @rdbms/admin/utlu121s.sql
CDBの場合:
$ORACLE_HOME/perl/bin/perl catcon.pl -n 1 -e -b utlu121s -d '''.''' utlu121s.sql
SQL*Plusを終了します。
リリース10.2、11.1または11.2からクラスタ・データベースをアップグレードする場合は、次のコマンドを使用してOracle Clusterwareのデータベース構成をアップグレードしてください。
$ srvctl upgrade database -d db-unique-name -o Oracle_home
ここで、db-unique-nameは(インスタンス名ではなく)割り当てられたデータベース名であり、Oracle_homeは、データベースがアップグレードされるOracleホームの場所です。
これで、データベースがOracle Database 12cにアップグレードされました。第4章「Oracle Databaseのアップグレード後の作業」に示す手順を完了する準備ができました。
マルチテナント・データベース(CDB)の構成に応じて、アップグレードの再実行に関するいくつかのシナリオがあります。次を行うことができます。
最初の試行中に複数の異なる問題が発生した場合、アップグレード全体を再実行する必要がある可能性があります。この例では、共有プールの不足などの問題が発生した場合の、CDB$ROOT、PDB$SEEDおよびコンテナの再アップグレードを示しています。
再度アップグレードを開始します。
SQL> startup upgrade;
alter pluggable database all open upgrade;
次のようにcatctl.plを実行します。
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_ HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl catupgrd.sql
CDB$ROOTおよびPDB$SEEDに含まれているすべてのコンテナで、アップグレードが再度実行されます。
指定した1つ以上のマルチテナント・コンテナ(CDB)のみで、アップグレードを再実行できます。これは除外リストを使用して実行できます。除外リストには、アップグレードしないコンテナが含まれています。除外リストは、catctl.plで-Cパラメータ・オプションを使用します。(このパラメータには大文字のCを使用する必要があります。大文字と小文字が区別されます。)この方法は、再アップグレードするPDBが多数ある場合に役立ちます。
この例では、マルチテナント・コンテナ・データベースに5つのPDBが含まれています。CDB1_PDB1およびCDB1_PDB2がアップグレード・エラーで失敗したことを除いて、すべてのアップグレードが成功しました。目的は、CDB1_PDB1およびCDB1_PDB2コンテナのみでアップグレードを実行することです。マルチテナント・データベース全体を停止し、アップグレードするPDBのみを再起動することによって、これを行うことができます。
停止してから、アップグレード・モードで起動します。
SQL> shutdown immediate;
startup upgrade;
alter pluggable database CDB1_PDB1 open upgrade;
alter pluggable database CDB1_PDB2 open upgrade;
CDBおよびPDBの状態を表示します。
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED MIGRATE YES
3 CDB1_PDB1 MIGRATE YES
4 CDB1_PDB2 MIGRATE YES
5 CDB1_PDB3 MOUNTED
6 CDB1_PDB4 MOUNTED
7 CDB1_PDB5 MOUNTED
アップグレードからCDB$ROOTおよびPDB$SEEDを除いて、アップグレードを再実行します。
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_ HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl -C 'CDB$ROOT PDB$SEED' catupgrd.sql
アップグレードはCDB1_PDB1およびCDB1_PDB2で再実行し、完了します。
|
注意: Windowsでは、CDBルート名およびPDBシード名を引用符で囲んだ-Cオプションを指定する必要があります。たとえば、次のようになります。... |
この例では、CDB$ROOTは標準モードで起動され、コンテナCDB1_PDB3、CDB1_PDB4およびCDB1_PDB5はオンラインです。この場合、コンテナCDB1_PDB1およびCDB1_PDB2ではアップグレードが失敗しますが、コンテナCDB1_PDB3、CDB1_PDB4およびCDB1_PDB5ではアップグレードが成功します。DBAでは、CDB1_PDB3、CDB1_PDB4およびCDB1_PDB5のアップグレード・ログを確認し、これらの特定のコンテナをオンラインにします。
コンテナCDB1_PDB1およびCDB1_PDB2でアップグレードを再実行するには、次を行います。
CDB$ROOTを標準モードで起動し、CDB1_PDB1およびCDB1_PDB2をアップグレード・モードで開きます。CDB1_PDB3、CDB1_PDB4、CDB1_PDB5は標準モードです。例は次のとおりです。
SQL> startup;
alter pluggable database CDB1_PDB1 open upgrade;
alter pluggable database CDB1_PDB2 open upgrade;
alter pluggable database cdb1_pdb3 open;
alter pluggable database cdb1_pdb4 open;
alter pluggable database cdb1_pdb5 open;
PDBの状態を表示します。
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 CDB1_PDB1 MIGRATE YES
4 CDB1_PDB2 MIGRATE YES
5 CDB1_PDB3 READ WRITE NO
6 CDB1_PDB4 READ WRITE NO
7 CDB1_PDB5 READ WRITE NO
アップグレードからCDB$ROOTを除いて、アップグレードを再実行します。
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_ HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl -C 'CDB$ROOT' catupgrd.sql
Windowsでは、CDBルート名およびPDBシード名を引用符で囲んだ-Cオプションを指定する必要があります。たとえば、次のようになります。
... -C "CDB$ROOT PDB$SEED"
アップグレードはCDB1_PDB1およびCDB1_PDB2で再実行し、完了します。
除外リストを使用してアップグレードを再実行するかわりに、包含リストを使用して、アップグレードを再実行するCDBおよび/またはPDBを指定できます。この例に示すように、包含リストは、catctl.plで-cパラメータを使用します。
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catctl.pl -d $ORACLE_HOME/rdbms/admin -l $ORACLE_HOME/rdbms/log catctl.pl -c 'CDB1_PDB1 CDB1_PDB2' catupgrd.sql
アップグレードはCDB1_PDB1およびCDB1_PDB2で再実行し、完了します。
catctl.plを使用して、アップグレードを再実行し、実行が成功したアップグレードのフェーズをスキップできます。再開するフェーズの番号を確認するには、アップグレード・ログで最初のエラーが発生した場所とフェーズを特定します。
CDB$ROOT (CDB)のログ・ファイルの範囲は、catupgrd0...catupgrd7.logです。コンテナ(PDB)のログ・ファイルの範囲は、catupgrdpdbname0...catupgradepdbname7.logです。
失敗したフェーズからマルチテナント・アップグレードを再開するには、まずエラーが発生したPDBを特定し、適切なログ・ファイルを検索します。
マルチテナント・アップグレードのエラーの原因のPDBを特定するには、アップグレード・サマリー・レポートを確認するか、catupgrd0.logを参照します。このログ・ファイルの最後に、アップグレード・サマリー・レポートが記載されています。
次の手順に従い、ログ・ファイルをチェックしてエラーを探します。
エラーのあるログ・ファイルを特定します。次に例を示します。
LinuxおよびUNIXの場合
$ grep -i 'error at line' catupgrd*.log
Windowsの場合
C:\> find /I "error at line" catupgrd*.log
grepまたはfindコマンドを使用すると、エラーが発見されたログ・ファイルのファイル名が表示されます。
エラーのあるログ・ファイルをチェックし、最初のエラーが発生した場所を特定します。任意のエディタを使用して、ログ・ファイルを表示します。最初の文字列「error at line」を検索します。文字列を発見したら、エラーからさかのぼって、PHASE_TIME___STARTを検索します。次に例を示します。
PHASE_TIME___START 15 15-01-16 08:49:41
PHASE_TIME___STARTの後の数字が、エラーの発生したフェーズ番号です。たとえば、フェーズ番号が15だとします。
各ログ・ファイルにエラーがあります。この文字列の検索を繰り返して、すべてのログ・ファイルでエラーのあるフェーズ番号を特定し、フェーズ番号の数字が最も小さい場所を特定します。
最も小さい数字のフェーズ番号を含むログ・ファイルが、再開するフェーズ番号です。このフェーズ番号から、アップグレードを再開します。
次に例を示します。
catupgrd0.logエラーがフェーズ15で発生したとします。
PHASE_TIME___START 15 15-01-16 08:49:41
catupgrd1.logエラーがフェーズ19で発生したとします。
PHASE_TIME___START 19 15-01-16 08:50:01
この例では、フェーズ番号15から再開します。すべてのログ・ファイルを検証して最初のエラーを探し、アップグレードを再開するフェーズを特定してください。
-pフラグを使用して再開するフェーズ番号を与えてcatctl.plコマンドを実行するディレクトリに変更し、失敗したフェーズからアップグレードを再開します。マルチテナント・データベースでは、-cフラグを構文-c 'PDBname'のように使用できます。ここでは、PDBnameは、エラーが発生したPDBの名前です。
次に例を示します。
非CDBのOracle Databaseの場合
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -p 15 catupgrd.sql
マルチテナントOracle Database (CDB)内のPDBの場合
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -p 15 -c 'PDB1' catupgrd.sql
いずれの例でも、アップグレードは、-pフラグを使用して特定されたフェーズ15から再開されています。マルチテナントの例では、エラーの発生したPDBは、-cフラグで特定されます。
これらの例で、アップグレードはフェーズ15から再開され、最後までアップグレードが実行されます。
(オプション) -Pフラグを使用して停止フェーズを指定することで、エラーを含むフェーズを実行できます。停止フェーズを使用すると、エラーが発生したフェーズのみを再実行できます。アップグレード全体を実行することなく、エラーが発生したフェーズのみで実行することで、エラーが修正されたかどうかを迅速に特定できます。
次のcatctl.plコマンドの例では、アップグレードはフェーズ15で再開され、-Pフラグで指定した停止フェーズであるフェーズ15の最後で停止します。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -p 15 -P 15 -c 'PDB1' catupgrd.sql
エラーの発生したフェーズでエラーが修正されたことを確認したら、その後のフェーズのアップグレードを中止できます。
たとえば、使用するマルチテナント・データベースのアップグレードPDB1のフェーズ15で発生したエラーが修正されたことを確認したら、次のコマンドを使用してフェーズ16でアップグレードを継続できます。
cd $ORACLE_HOME/rdbms/admin $ORACLE_HOME/perl/bin/perl catctl.pl -p 16 -c 'PDB1' catupgrd.sql
