| Oracle® Databaseアップグレード・ガイド 12cリリース1 (12.1) B71306-08 |
|
 前 |
 次 |
Oracle Databaseをアップグレードする手順を実行した後は、必要な作業を行い、新しいリリースの推奨事項を考慮する必要があります。
この章の内容は次のとおりです。
dbupgdiag.sqlスクリプトを実行することで、データ・ディクショナリの現在の状態に関するアップグレードおよび移行の診断情報を収集できます。スクリプトは、アップグレード前にソース・データベース上、およびアップグレード後にSYSユーザーとしてアップグレードされたデータベース上のどちらででも、SQL*Plusで実行できます。
|
関連項目: My Oracle Support (http://support.oracle.com)のNote 556610.1「Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)」 |
ディクショナリの現在の状態を表示するには、次の例のようなSQL問合せを実行します。
SQL> spool /tmp/regInvalid.out
SQL> set echo on
-- query registry
SQL> set lines 80 pages 100
SQL> select substr(comp_id,1,15) comp_id,substr(comp_name,1,30)
comp_name,substr(version,1,10) version,status
from dba_registry order by modified;
無効なオブジェクトを問い合せるには、次のようなSQL問合せを実行します。
SQL> select substr(owner,1,12) owner,substr(object_name,1,30) object,substr(object_type,1,30) type, status from dba_objects where status <> 'VALID'order by owner, type; SQL> spool off SQL> set echo off
Oracle Databaseをアップグレードした後で、新しいOracleホームからOPatchコマンドを実行する必要があります。たとえば、現在システムにインストールされている正確で完全なインベントリをリストするには、新しいOracleホームからlsinventoryコマンドを実行します。
|
関連項目: OPatchの構文およびコマンドは、Oracle OPatchユーザーズ・ガイドfor Windows and UNIXの付録Aを参照してください。 |
アップグレードを手動で行ったかDatabase Upgrade Assistant (DBUA)を使用して行ったかにかかわらず、Oracle Databaseをアップグレードした後、使用環境に指定されている必要な作業を完了する必要があります。
ご使用のオペレーティング・システムがLinuxまたはUNIXで、かつOracle Databaseを手動でアップグレードした場合は、特定の環境変数が新しいOracle Databaseリリースのディレクトリを指していることを確認する必要があります。また、クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。
次の環境変数が新しいOracleホームのディレクトリを指していることを確認します。
ORACLE_HOME
PATH
|
注意: DBUAでは、自動的にOracle環境変数に対して必要な変更が行われます。 |
|
関連項目:
|
Oracle Databaseを新しいリリースにアップグレードした後に、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、新しいOracle Database 12cリリース用に作成された新しいOracleホームを指していることを確認する必要があります。DBUAではoratabは自動的に新しいOracleホームを指しますが、アップグレードにどの方法を使用しても、クライアント・スクリプトを確認する必要があります。
|
関連項目: オペレーティング・システムの環境変数の設定の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle Database 12cでは、SQLのVARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズを制御するMAX_STRING_SIZEが導入されました。MAX_STRING_SIZE = EXTENDEDを設定することで、Oracle Database 12cで導入された32767バイト制限が有効になります。MAX_STRING_SIZE = EXTENDEDを設定できるようにするためには、COMPATIBLE初期化パラメータを12.0.0.0以上に設定する必要があります。
システムで新しい拡張データ型を使用可能にするには、『Oracle Databaseリファレンス』で説明するように、特定のアップグレードを行う必要があります。MAX_STRING_SIZEの値はSTANDARDからEXTENDEDに変更できます。ただし、MAX_STRING_SIZEの値をEXTENDEDからSTANDARDには変更できません。MAX_STRING_SIZE = EXTENDEDを設定することは、データベースでアプリケーションの非互換性が発生する可能性がある設定を明示的に指定することになります。
|
関連項目: MAX_STRING_SIZEの推奨事項および手順などの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
Oracle Database 12cでは、PARALLEL_MIN_SERVERSのデフォルトが0からご使用のハードウェア・プラットフォームに応じた値に変更されており、パラレル実行に必要な最低限のサポートが提供されます。ご使用の環境でこの新しいデフォルト設定が高すぎる場合は、要件に合せて設定を調節します。PARALLEL_MAX_SERVERSのデフォルトは変更されていないため、古い環境でデフォルトを変更していない場合は、何もする必要はありません。
|
関連項目: PARALLEL_MIN_SERVERSの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。リカバリ・カタログのアップグレードおよびUPGRADE CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
|
関連項目: RMANリカバリ・カタログの管理の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
データベースのアップグレードを完了した後、アップグレード前情報ツールによってタイム・ゾーン・ファイルをアップグレードするよう指示された場合は、DBMS_DST PL/SQLパッケージを使用してこのファイルをアップグレードします。
Oracle Databaseでは複数のバージョンのタイム・ゾーン・ファイルが提供されており、互いに関連付けられている2種類のファイルがあります。1つはデータベースで定義されているすべてのタイム・ゾーンを含む大きなファイルで、もう1つは最も一般的に使用されるタイム・ゾーンのみを含む小さいファイルです。大きいバージョンはtimezlrg_version_number.dat、小さいバージョンはtimezone_version_number.datと指定されます。ファイルは、Oracle Databaseホーム・ディレクトリ下のoracore/zoneinfoサブディレクトリにあります。
|
関連項目:
|
DBMS_STATS.CREATE_STAT_TABLEプロシージャを使用して統計表を作成した場合、次のプロシージャを実行してこれらの表をアップグレードします。
EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('green', 'stat_table');
この例で、greenは統計表の所有者で、STAT_TABLEは統計表の名前です。各統計表にこのプロシージャを実行します。
|
関連項目: DBMS_STATSパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
Oracle9iリリース2 (9.2)またはOracle Database 10gリリース1 (10.1)からのアップグレード時に、外部認証されたSSLユーザーを使用している場合は、SSL外部ユーザー変換(extusrupgrade)スクリプトを実行してそれらのユーザーをアップグレードする必要があります。スクリプトの構文は次のとおりです。
ORACLE_HOME/rdbms/bin/extusrupgrade --dbconnectstring host_name:port_no:sid --dbuser <db admin> --dbuserpassword password -a
|
注意: Oracle Database 10gリリース2 (10.2)以上のリリースからアップグレードしている場合は、extusrupgradeスクリプトを実行する必要はありません。 |
|
関連項目: extusrupgradeスクリプトの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』 |
Oracle Database 12cでは、Database Creation Assistant (DBCA)によってOracle XML DB用のポートは構成されません。また、改善されたセキュリティ機能を利用するために、Oracle XML DB RepositoryへのアクセスにHTTPの認証を構成する必要もあります。
Oracle Database 12c以上では、ダイジェスト認証のサポートを提供することによって、データベースのセキュリティが向上しました。ダイジェスト認証は、HTTPプロトコルで一般に使用される業界標準のプロトコルで、ほとんどのHTTPクライアントでサポートされています。ダイジェスト認証では、暗号化された(HTTPS)接続が使用されていない場合でも、パスワードは常にセキュアな方法で転送されます。ダイジェスト認証をサポートすることによって、組織では、パスワードの漏えいを心配することなくOracle XML DB HTTPを使用するアプリケーションをデプロイできます。Oracle XML DBでのダイジェスト認証のサポートでは、Oracle XML DB HTTPサーバーとMicrosoft Web Folders WebDAVクライアントとの互換性も引き続き維持されます。
|
関連項目: HTTPの認証メカニズムの構成および管理の詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
新しいリリースのインストールまたはアップグレード後に、次のようにOracle XML DBのFTPおよびHTTPポートを手動で構成する必要があります。
DBMS_XDB_CONFIG.setHTTPPort(HTTPポート番号)を使用して、Oracle XML DBのHTTPポートを設定します。
SQL> exec DBMS_XDB_CONFIG.setHTTPPort(port_number);
DBMS_XDB_CONFIG.setFTPPort(FTPポート番号)を使用して、Oracle XML DBのFTPポートを設定します。
SQL> exec DBMS_XDB_CONFIG.setFTPPort(port_number);
|
注意: 手順内のFTPおよびHTTPで使用するポート番号は、DBMS_XDB_CONFIG.getFTPPortおよびDBMS_XDB_CONFIG.getHTTPPortをそれぞれ使用することによって問い合せることができます。 |
使用されているすべてのポート番号を確認するには、DBMS_XDB_CONFIG.usedportを使用できます。
|
関連項目: FTPおよびHTTP(S)/WebDAVプロトコルを使用したOracle XML DB Repositoryのデータへのアクセスの詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
Oracle Textが提供するナレッジ・ベースはOracle Database 12cの付属製品の一部ですが、Oracle Database 12cへのアップグレード後すぐに使用できるようにはなっていません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレード後には機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースをインストール・メディアからインストールする必要があります。
Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、アップグレード後に再生成する必要があります。これらの変更は、指定されたOracleホームにインストールされているすべてのデータベースに影響します。
|
関連項目:
|
Oracle Database 12cリリース1へのアップグレード完了後に、AUTO_LEXERを使用して作成されたOracle Text索引を使用する場合、問合せを動作させるには、索引を再構築する必要があります。
また、BASIC_LEXERセットの次のINDEX_STEMSタイプを持つ索引を再構築する必要があります。
ARABIC
BOKMAL
CATALAN
CROATION
CZECH
DANISH
ERIVATIONAL_NEW
DUTCH_NEW
ENGLISH_NEW
FINNISH
FRENCH_NEW
GERMAN_NEW
GREEK
HEBREW
HUNGARIAN
ITALIAN_NEW
NYNORSK
POLISH
PORTUGUESE
ROMANIAN
RUSSIAN
SERBIAN
SLOVAK
SLOVENIAN
SPANISH_NEW
SWEDISH
元のデータベースにOracle Application Expressリリース3.2以上が含まれていた場合は、Oracle Database 12cにアップグレードした後に必要な追加の構成はありません。ただし、レジストリにOracle Application Expressがあり、Oracle Application Expressをアップグレードする場合、open_cursorsパラメータを最低200に設定する必要があります。
データベースはOracle Express EditionデータベースではないがOracle Application Expressの以前のリリースが含まれていた場合は、アップグレード中に最新リリースが自動的にインストールされます。新しいOracle Database 12cと併用するために、インストール後の一連の手順を実行して、Application Expressを構成する必要があります。
|
関連項目: Oracle Application Expressのインストール後の作業の詳細は、『Oracle Application Expressインストレーション・ガイド』を参照してください。 |
データベースがOracle Express Editionデータベースの場合は、Oracle Application Expressの以前のリリースが含まれおり、Oracle Express Edition環境に応じて調整されています。次のURLに用意されている、Oracle Express EditionとOracle Application Expressの相違点を説明したOracleドキュメントを参照してください。
http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html
Oracle Database 12cには、UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPまたはUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。これらのパッケージを使用するアプリケーションがある場合、Oracle Databaseのアップグレード後に、データベースのネットワーク・アクセス制御リスト(ACL)を構成してから、これらのパッケージを前のリリースと同様に動作させる必要があります。ACLがない場合、エラー「ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」でアプリケーションが失敗する可能性があります。
|
関連項目: 一部のユーザーはホストAに接続し、別のユーザーはホストBに接続するなど、より複雑な状況については、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
Oracle Database Vault (DV)を使用している場合は、データベースをアップグレードする前にこれを無効にするように指示がありました。今度は、Oracle Database Vaultを有効にする必要があります。
アップグレードされたデータベースでOracle DV施行を開始するには、プロシージャdvsys.dbms_macadm.enable_dv()を使用してDVを有効化します。DV_OWNERまたはDV_ADMINロールを持つユーザーのみが、このプロシージャを実行できます。プロシージャを有効にするには、データベース・インスタンスを再起動する必要があります。
|
関連項目:
|
Oracle Database 12c以上では、SQLNET.ALLOWED_LOGON_VERSIONパラメータのデフォルト値は、8から11に変更されました。このパラメータの使用は非推奨になり、現在はSQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータで置き換えられています。アップグレードされたデータベースでSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを明示的に設定していない場合、リリース10gより前のクライアントからの接続は、エラー「ORA-28040: 一致する認証プロトコルがありません」で失敗します。セキュリティ強化のため、データベース・ユーザーのパスワード検証機能を確認し、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータを設定して正しいパスワード検証機能を使用するようにデータベースを構成します。
既存のデータベースにパスワードで保護されたロール(セキュア・ロール)があり、11のデフォルトのSQLNET.ALLOWED_LOGON_VERSION_SERVER設定でOracle Database 12cにアップグレードする(そのセキュア・ロールにはリリース10gの検証機能のみがあるため)場合、アップグレード後もセキュア・ロールが使用可能な状態になるように、管理者は各セキュア・ロールのパスワードをリセットする必要があります。
|
関連項目:
|
アップグレード後に、環境変数設定が正しいことを確認する必要があります。「Grid Infrastructureのインストールでの環境変数の使用」を参照してください。Oracle ASMは、Oracle Grid Infrastructureのインストールの一部として含まれています。クラスタのOracle ClusterwareとOracle ASMをアップグレードすると、Oracle ClusterwareとOracle ASMは両方ともGridホームと呼ばれる同じホームに配置されます。すべてのOracleソフトウェア・インストールを所有するインストール所有者を1人のみ割り当てることも、ロール割当て済の所有者を使用することもできますが、後者の場合は、Grid Infrastructureインストールに別のソフトウェア所有者、1つ以上のOracle Databaseインストールに別々のソフトウェア所有者を使用します。
|
関連項目: ロール割当て済のインストール所有者の詳細は、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
ご使用のオペレーティング・システムがLinuxまたはUNIXの場合、アップグレードを実行した後に環境変数の設定が正しいことを確認します。
すべてのインストールに1人のOracleインストール所有者を使用する場合は、Oracle Databaseインスタンスをデータベース管理の一部として管理するかどうか、またはOracle ASMインスタンスをストレージ管理の一部として管理するかどうかに応じて、ORACLE_HOMEなどの環境変数をOracle DatabaseホームまたはGridホームに変更する必要があります。
ロール割当て済のOracleインストール所有者を使用し、Oracle Grid Infrastructure (Oracle ClusterwareとOracle ASM)ソフトウェアに別の所有者を使用する場合は、Grid Infrastructureインストール所有者の次の環境変数を、Gridホーム内のOracle ASMホームのディレクトリを指すように設定します。
ORACLE_HOME
PATH
また、oratabファイルおよびORACLE_HOME値を設定するOracle ASMのすべてのクライアント・スクリプトが、Gridホーム内のOracle ASMホームを指していることを確認します。
|
注意: クラスタOracle ASMインストールをクラスタ用のOracle Grid Infrastructureにアップグレードする場合は、すべてのクラスタ・メンバー・ノードでこれらを確認してください。DBUAでは、oratabファイルは自動的に新しいOracleホームを指します。クライアント・スクリプトは、アップグレード方法に関係なく、確認する必要があります。 |
|
関連項目:
|
Oracle Grid Infrastructureバイナリのオペレーティング・システム・ユーザー所有権と1つ以上のデータベースのOracle Databaseインストール所有者を分けた場合は、アップグレードしたOracle ASMまたはデータベースのホームのオペレーティング・システム・ユーザーを移行する必要があります。たとえば、1つのソフトウェア・バイナリ所有者(oracleなど)から複数のロール割当て済のソフトウェア所有者ユーザー・アカウント(grid、oracle1、oracle2など)に移行する場合、既存のOracle ASMインストール所有者を、Oracle Grid Infrastructureインストールで使用する予定のインストール所有者に変更します。
検討する例は次の3つです。
|
関連項目: 新しいリリースと互換性のあるOracle ASMディスク・グループの作成の詳細とOracle ASMのアップグレードの追加情報は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
既存のOracle ASMインストールに使用したのと同じオペレーティング・システム・ユーザーをOracle Grid Infrastructureインストールに使用する場合は、Oracle Universal Installer (OUI)を実行してGrid Infrastructureインストールを実行し、アップグレード・オプションを選択します。OUIによって、Gridホームで、既存のOracle ASMインストールが以前のリリースからOracle Database 12cに自動的にアップグレードされます。
以前のリリースのOracle ASMがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合に、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更する必要があるとします。これが役立つのは、Oracle ASMを使用するデータベースが2つあり、既存のデータベースの所有者と同じインストール所有者でOracle ASMをインストールした状態で、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようにOracle ASMのオペレーティング・システム・インストール所有者を変更する必要がある場合です(どちらのOracle Databaseインストール所有者にもOracle Grid Infrastructureバイナリ所有権がない場合)。
Oracle RACデータベースのオペレーティング・システム・ユーザーを変更する必要がある場合があります。たとえば、以前のリリースのデータベースがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合は、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更することを検討する必要があります。Oracle Databaseインストール所有者にGrid Infrastructureバイナリ所有権がない場合は、Oracle ASMのオペレーティング・システム・ユーザーを変更すると、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようになります。
|
関連項目: Grid InfrastructureおよびOracle ASMを使用するOracle RACデータベースのオペレーティング・システム・ユーザーの変更手順については、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
Oracle Databaseのアップグレード後に、次のタスクを行うことをお薦めします。これらの作業は、Oracle Databaseの優れた更新手法であり、アップグレードを手動で行ったかDBUAを使用して行ったかにかかわらずお薦めできる方法です。
必ず本番データベースの全体バックアップを作成してください。この手順は必須ではありませんが、本番データベースをバックアップすることを強くお薦めします。
|
関連項目: RMANを使用したデータベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
postupgrade_fixups.sqlスクリプトは、DBUAによってアップグレード・プロセスの一環として実行されますが、アップグレード後にいつでもこれを実行することができます。postupgrade_fixups.sqlスクリプトは、アップグレード対象データベースに対して、一般的な警告、エラーおよび推奨事項の3種類の情報を生成します。
このスクリプトは、DBUAまたは手動でアップグレードを完了した後に、任意の時点で実行します。Oracle_Baseが定義されている場合、生成されたスクリプトおよびログ・ファイルは、アップグレードを実行した元のデータベースのOracle_Base/cfgtoollogs/に作成されます。Oracle_Baseが定義されていない場合、生成されたスクリプトおよびログ・ファイルは、アップグレードを実行したデータベースのORACLE_HOME/cfgtoollogs/に作成されます。
出力を確認するために、結果をログ・ファイルにスプールするようにシステムを設定します。ただし、adminディレクトリにスプールしないでください。(新しくアップグレードされた場所ではなく)アップグレードを実行したデータベースの場所から、スクリプトを実行します。
SQL> SPOOL postupgrade.log
スクリプト結果のログ・ファイルへのスプーリングをオフにします。
SQL> SPOOL OFF
|
注意: PDBまたは他のスタンドアロン・データベースをサーバーAからサーバーBに移動する場合、postupgrade_fixups.sqlスクリプトを新しい場所にコピーし、新しい環境でアップグレード後にこれを実行する必要があります。 |
Oracle Databaseのアップグレードの数日後に、DBMS_STATS.GATHER_FIXED_OBJECTS_STATS PL/SQLプロシージャを使用して固定オブジェクト統計を収集することをお薦めします。これはデータベース全体のパフォーマンスによい影響を及ぼすことがあります。DBMS_STATS.GATHER_FIXED_OBJECTS_STATSでは、init.ora/spfileから非表示またはアンダースコア・パラメータおよびイベントをすべて削除するための推奨事項も表示されます。
x$表の一時性質により、システムで代表的なワークロードがあるときに固定オブジェクト統計を収集することは重要です。統計の収集には追加のリソースが必要になるため、大規模なシステムでは、必ずしもこれが可能はわけではありません。負荷ピーク時にこれを行えない場合は、システムがウォーム・アップされ、固定オブジェクト表のキー・タイプが移入された後に実行する必要があります。
固定オブジェクトの統計を収集するには、次のPL/SQLプロシージャを実行します。
SQL> execute dbms_stats.gather_fixed_objects_stats;
|
関連項目: GATHER_FIXED_OBJECTS_STATSプロシージャの使用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
パスワードでの大/小文字の区別を強制できます。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。
データベースのアップグレード手順で既存ユーザーのパスワードをリセットする必要がある場合は、既存データベースに対して各ユーザーのパスワードをALTER USER文でリセットする必要があります。アップグレード後に新しく作成されたデータベースでは、追加の作業や追加の管理要件はありません。
11.1.0.7より前のリリースでパスワードの大/小文字区別の強制を利用するには、データベースのアップグレード手順で既存のユーザーのパスワードをリセットする必要があります。この場合、データベースのアップグレードでDBMS_VERIFIER.EXPIRE_ACCOUNTS_WITHOUT_LATEST_VERIFIERプロシージャを使用し、これによって、アカウントに最新の検証機能がないユーザーに対して、次回のログイン時にパスワードを変更することが強制されます。その際、サーバーで、アカウントに対して最新の検証機能が生成できます。新しいデータベースの場合は、追加の作業や追加の管理要件はありません。
SYSDBAユーザーおよびSYSOPERユーザーの場合は、新しいコマンドライン・スイッチignorecaseを使用して、新しいORAPWDファイルを生成できます。
|
注意:
|
|
関連項目: パスワードの大/小文字の区別の有効化の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
Oracle ClusterwareおよびOracle ASMはどちらも、Oracle Grid Infrastructureインストールの一部です。
Oracle Grid Infrastructureは、単一サーバーにインストールした場合、Oracle ASMとともにOracle Restartインストールとしてデプロイされます。クラスタにインストールした場合は、Oracle ASMとともにOracle Clusterwareインストールとしてデプロイされます。
Oracle Restartは、単一インスタンス環境におけるOracle Databaseの可用性を向上します。Oracle Restartをインストールし、データベース、リスナー、Oracle ASMインスタンスなどのOracle Databaseソフトウェア・スタックの一部が一時的に失敗した場合、失敗したコンポーネントはOracle Restartによって自動的に再起動されます。また、これらのすべてのコンポーネントは、データベース・ホスト・コンピュータが再起動されるときに、Oracle Restartによって起動されます。コンポーネントは、コンポーネント間の依存性を考慮して適切な順序で起動されます。
Oracle Clusterwareは、単一サーバーを単一システムとして連携するようにクラスタ化できるポータブル・クラスタ・ソフトウェアです。Oracle RACに必須なインフラストラクチャも提供します。また、Oracle Clusterwareでは、クラスタ内の任意のOracleアプリケーションまたはその他のアプリケーションを保護できます。いずれの場合でも、Oracle Clusterwareはそれらのシステムにおけるインテリジェント機能としてクラスタ・ノード間の必要な連携を確実にします。
|
関連項目: 詳細情報および手順については、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
以前のリリースまでは、Oracle ASMは、Oracle Databaseインストールの一部としてインストールされていました。Oracle Databaseリリース11.2以上では、Oracle ASMは、Grid Infrastructureコンポーネントのインストール時にインストールされます。Oracle ASMは、Oracle RACとともにクラスタにインストールされた場合はOracle Clusterwareと、スタンドアロン・サーバーにインストールされた場合はOracle RestartとOracleホームを共有します。
|
関連項目: 詳細情報および手順については、『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
『Oracle Database新機能ガイド』では、新しいOracle Database 12cリリースで使用可能な多くの新機能について説明されています。これらのどの新機能がデータベースおよびアプリケーションに有効かを判断してください。その後、これらの機能を使用する計画を立てることができます。
新しいOracle Databaseソフトウェアを使用するためにすぐに変更する必要はありません。データベースおよびそれに対応するアプリケーションに、これらの拡張機能を徐々に取り入れることもできます。
第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」では、新しいOracle Database 12cリリースの機能を利用するためにアプリケーションを拡張する方法について説明します。ただし、新機能を実装する前にアプリケーションをテストし、アップグレードしたデータベース上でアプリケーションを正常に動作させる必要があります。
新しいOracle Database 12cリリースの機能をよく理解したうえで、データベース管理用のスクリプトおよびプロシージャを再確認し、変更が必要かどうかを判断します。
それぞれのアプリケーションに必要な変更を、データベースにも行う必要があります。たとえば、データベースで整合性制約を使用可能にした場合、アプリケーションでのデータ・チェックの一部を削除できます。
アップグレードされたOracle Database 12cデータベースでは、表領域アラートが無効になっています(しきい値がNULLに設定されています)。データベース内の監視対象の表領域を指定し、適切なしきい値を設定する必要があります。
新しく作成されたOracle Database 12cデータベースのデフォルトのしきい値は次のとおりです。
警告(表領域の使用率が85%の場合)
クリティカル(表領域の使用率が97%の場合)
データベースがOracle Database 11gより前の場合は、ロールバック・セグメント(手動UNDO管理)を使用してアップグレードしたデータベースを、自動UNDO管理に移行する必要があります。
自動UNDO管理は、デフォルトのUNDO領域管理モードです。システムで使用するUNDO領域管理モードは、次のようにUNDO_MANAGEMENT初期化パラメータで指定します。
UNDO_MANAGEMENT=AUTOの場合(またはUNDO_MANAGEMENTを設定しない場合)は、データベース・インスタンスは自動UNDO管理モードで起動します。
UNDO_MANAGEMENT初期化パラメータがNULLの場合のデフォルトは、Oracle Database 11gリリース1(11.1)では自動UNDO管理モードですが、前のリリースでは手動UNDO管理モードです。したがって、10.2または11.1のリリースをOracle Database 12cにアップグレードする際は注意が必要です。
UNDO_MANAGEMENT=MANUALの場合、UNDO領域はロールバック・セグメントとして外部に割り当てられます。
自動UNDO管理に移行するには、次の手順を実行します。
UNDO_MANAGEMENT=MANUALに設定します。
インスタンスを再起動して標準的なビジネス・サイクルを一通り実行し、代表的なワークロードを取得します。このようにしてワークロードを評価し、自動UNDO管理で必要なUNDO表領域のサイズを計算します。
標準的なビジネス・サイクルを完了したら次のファンクションを実行し、UNDO表領域のサイズと、UNDO表領域のサイズ変更に関するヘルプを収集します(このファンクションの実行にはDBA権限が必要です)
DECLARE utbsiz_in_MB NUMBER; BEGIN utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION; end; /
このファンクションではPL/SQLプロシージャが実行され、システム構成およびシステムのロールバック・セグメントの使用状況を基にして、新しいUNDO表領域のサイズを求める方法に関する情報が提供されます。このファンクションはサイズ変更に関する情報を直接戻します。
必要なサイズのUNDO表領域を作成し、UNDO_MANAGEMENT=AUTOに設定するかパラメータを削除して、自動UNDO管理を有効にします。
Oracle RAC構成の場合は、すべてのインスタンスでこれらの手順を繰り返します。
DGConnectIdentifierの値は、常時、すべてのData Guardネットワーク・トラフィック用に使用されます。Oracle Databaseリリース10gの構成をアップグレードする場合は、最初にOracle Database 11gにアップグレードする必要があり、InitialConnectIdentifierの値は、そのデータベースのDGConnectIdentifierの新しい値として保持されます。Oracle RACデータベースをアップグレードする場合、データベース管理者は、InitialConnectIdentifierプロパティの値がすべてのインスタンスに到達できることを確認する必要があります。
LOBデータ型(BFILE、BLOB、CLOBおよびNCLOB)には、LONGデータ型よりも多くのメリットがあります。ALTER TABLE文を使用して、LONGデータ型の列をCLOBに、LONG RAWデータ型の列をBLOBに変更できます。
次の例では、long_tab表のlong_colというLONG列が、CLOBデータ型に変更されます。
SQL> ALTER TABLE Long_tab MODIFY ( long_col CLOB );
この方法でLONG列をLOBに変換した後も、表に設定されている既存の制約およびトリガーはすべて使用できます。ただし、表のすべての列で、ドメイン索引およびファンクション索引を含むすべての索引が使用不可となるため、ALTER INDEX ... REBUILD文を使用してすべての索引を再構築する必要があります。また、LONG列上のドメイン索引は、LONG列をLOBに変更する前に削除する必要があります。
|
関連項目: LOBデータを使用するためのアプリケーションの変更の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 |
統合監査では、すべてのOracle Database監査証跡(データベース監査証跡ではSYS.AUD$、ファイングレイン監査ではSYS.FGA_LOG$、Database VaultではDVYS.AUDIT_TRAIL$など)は、1つの監査証跡にまとめられますが、これは、単一インスタンスのインストールではUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを、Oracle Real Application Clusters環境ではGV$UNIFIED_AUDIT_TRAILを問い合せることによって表示できます。完全な純統合監査機能を使用する場合は、「Oracle Databaseでの統合監査への移行」に従って手動で移行する必要があります。
|
関連項目: このリリースでの監査機能の変更の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
この項には次のトピックが含まれます:
デフォルトでは、アップグレードされたデータベースでは、統合監査は有効化されていません。以前のリリースからOracle Database 12cアップグレードした場合は、データベースでは以前のリリースで使用していたものと同じ監査機能が使用されています。新しく作成されたデータベースでは、統合監査の混合モードの方式がデフォルトで有効化されます。統合監査への移行が完了すると、従来の監査は無効化され、新しい監査レコードが統合監査証跡に書き込まれます。
監査ポリシーを有効化して使用方法を構成するには、次のように1つの方法を選択します。
純統合監査機能を使用。
「Oracle Databaseでの統合監査への移行」に記載されている手順に従って、純統合監査機能を使用します。統合監査への移行手順が完了すると、新しい監査ポリシーを作成および有効化でき、事前定義された監査ポリシーも使用できます。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。以前の監査証跡および監査レコードは保持されますが、新しい監査レコードは以前の監査証跡には書き込まれません。
|
注意: 以前のリリースの監査構成は、統合監査システムでは効果がありません。統合監査証跡内では、統合監査ポリシーのみが監査レコードを生成します。 |
混合モードの監査機能を使用。
混合モードの監査機能は、従来の監査機能と統合監査機能の両方を同時に実行でき、新しいデータベースとアップグレードされたデータベースの両方に適用されます。混合モードの統合監査機能は、1つ以上の事前定義された統合監査ポリシーを有効化すると使用可能になります。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。Oracle Databaseの以前のリリースでの監査構成も使用可能で、この構成の監査レコードは以前の監査証跡に書き込まれます。純統合監査機能を使用する場合は、「Oracle Databaseでの統合監査への移行」の手順に従って、切り替えることができます。
|
注意: データベースが書込み不可な場合、監査レコードは、$ORACLE_BASE/audit/$ORACLE_SIDディレクトリにある新しい形式のオペレーティング・システム・ファイルに書き込まれます。 |
|
関連項目:
|
マルチテナント・コンテナ・データベース(CDB)環境で、rootで次の手順を実行します。この手順では、rootとすべての関連付けられたPDBを統合監査に移行します。
データベースを移行して統合監査を有効化するには、次の手順を実行します。
SYSDBA権限を持つユーザーSYSとしてSQL*Plusにログインします。
sqlplus sys as sysdba
Enter password: password
プラガブル・データベース環境では、このログインにより、rootに接続されます。
次の問合せを実行して、Oracle Databaseが統合監査に移行されているかどうかを確認します。
SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
VALUE列への出力がTRUEの場合、データベースで統合監査がすでに有効化されています。次の手順については、「統合監査への移行後の古い監査レコードの管理」を参照してください。出力がFALSEの場合は、残りの手順を完了してください。
データベースを停止します。単一インスタンス環境では、SQL*Plusから次のコマンドを入力します。
SQL> SHUTDOWN IMMEDIATE SQL> EXIT
Windowsシステムでは、Oracleサービスを停止します。
net stop OracleService%ORACLE_SID%
Oracle RACインスタンスの場合は、各データベース・インスタンスを次のように停止します。
srvctl stop database -db db_name
リスナーを停止します。(Oracle RACおよびGrid Infrastructureリスナーでは、リスナーを停止する必要はありません。)
lsnrctl stop listener_name
lsnrctl statusコマンドを実行すると、リスナーの名前を検索できます。名前は、別名設定で示されます。
$ORACLE_HOME /rdbms/libディレクトリに移動します。
統合監査実行可能ファイルを次のように有効にします。
UNIXでは、次のコマンドを実行します。
make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME
Windowsでは、%ORACLE_HOME%/bin/orauniaud12.dll.dblファイルの名前を%ORACLE_HOME%/bin/orauniaud12.dllに変更します。
リスナーを再起動します。
lsnrctl start listener_name
データベースを再起動します。SQL*Plusにログインしてから、次のように、STARTUPコマンドを入力します。
sqlplus sys as sysoper
Enter password: password
SQL> STARTUP
Windowsシステムでは、Oracleサービスを再度起動します。
net start OracleService%ORACLE_SID%
Oracle RACインストールの場合は、次のようにして、各データベース・インスタンスを起動します。
srvctl start database -db db_name
統合監査を使用するためのOracle Databaseの移行手順が完了すると、データベースで使用していた以前の監査レコードは以前の監査証跡に保持されます。これらの監査レコードをアーカイブして、監査証跡を削除できます。統合監査が使用可能な場合、新しい監査レコードは統合監査証跡に書き込まれます。
|
関連項目:
|
統合監査を使用するためにデータベースを有効化した後に統合監査を使用しないことにした場合は、統合監査機能を削除できます。この場合、「Oracle Databaseでの統合監査への移行」に記載されているとおり、データベースでは混合モードの監査機能が使用されます。
統合監査を削除にするには、次の手順を実行します。
データベースを停止します。
sqlplus sys as sysoper
Enter password: password
SQL> SHUTDOWN IMMEDIATE
SQL> EXIT
Windowsシステムでは、Oracleサービスを停止します。
net stop OracleService%ORACLE_SID%
Oracle RACインスタンスの場合は、各データベース・インスタンスを次のように停止します。
srvctl stop database -db db_name
$ORACLE_HOME/rdbms/libディレクトリに移動します。
統合監査実行可能ファイルを無効にします。
UNIXの場合: 次のコマンドを実行します。
make -f ins_rdbms.mk uniaud_off ioracle ORACLE_HOME=$ORACLE_HOME
Windows: %ORACLE_HOME%/bin/orauniaud12.dllファイルの名前を%ORACLE_HOME%/bin/orauniaud12.dll.dblに変更します。
データベースを再起動します。
sqlplus sys as sysoper
Enter password: password
SQL> STARTUP
SQL> EXIT
Windowsシステムでは、Oracleサービスを再度起動します。
net start OracleService%ORACLE_SID%
Oracle RACインストールの場合は、次のようにして、各データベース・インスタンスを起動します。
srvctl start database -db db_name
Oracle Database 12cにアップグレード後に、統合監査に変更しないことを選択した場合は、OracleドキュメントおよびOracle Technology Networkで従来の非統合監査に関する情報を検索できます。
次の場所で非統合監査に関する情報を参照してください。
Oracle Databaseセキュリティ・ガイド: このガイドは、監査を構成する際の主要な情報源です。このマニュアルのOracle Databaseリリース11gバージョンを使用する必要があります。このガイドにアクセスするには、次の手順を実行します。
次のURLのOracle Technology Networkに移動します。
「ダウンロード」メニューで、「データベース」の下にある「Database 11g」を選択します。
「ダウンロード」ページで、「ドキュメント」タブを選択します。
最新のOracle Database 11g Release 2 (11.2)の「ドキュメント」ページから、「ライブラリの表示」リンクを選択して、リリース11gドキュメント・セットのホーム・ページを表示します。
「検索」フィールドで、「マスター・ブック・リスト」リンクを選択します。
「セキュリティ・ガイド」を検索します。
このガイドの「HTML」または「PDF」リンクのいずれかを選択します。
Oracle Database SQL言語リファレンス: このガイドでは、統合監査および非統合監査の両方の環境でのAUDIT文およびNOAUDIT文の使用方法について説明しています。
Oracle Databaseリファレンス: このガイドは、非統合監査環境に関連付けられている初期化パラメータおよびデータ・ディクショナリ・ビューの使用方法について説明しています。これらのリストについては、『Oracle Databaseセキュリティ・ガイド』を参照してください。
Oracle Database Vault管理者ガイド: このガイドでは、非統合監査環境でDatabase Vaultに対する監査を構成する方法を説明しています。
Oracle Label Security管理者ガイド: このガイドでは、非統合監査環境でOracle Label Securityに対する監査を構成する方法を説明しています。
テスト・データベースを新しいOracle Databaseリリースにアップグレードしてテストした場合、新しいOracle Database 12cリリースにアップグレードした本番データベースでも同じテストを繰り返すことができます。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。
新しいOracle Databaseで既存のアプリケーションが正常に動作するかどうかを確認するために、この新しくアップグレードされた本番データベースをテストします。また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。ただし、アプリケーションがアップグレードの前と同様に動作するかどうかを最初に確認してください。
Oracle Real Application Clusters 12cリリース1 (12.1)では、単一クライアント・アクセス名(SCAN)が使用されます。SCANは、パブリック・ネットワークで3つのIPアドレスに解決される単一の名前です。11.2より前のリリースのOracle RACデータベースがアップグレードされると、リモート・リスナーとしてSCANリスナーに登録され、引き続きすべてのノード・リスナーにも登録されます。SCANを使用するか、または引き続きノード・リスナーを使用するようにクライアントを構成できます。SCANを使用するようにすべてのクライアント接続を移行する場合は、REMOTE_LISTENERSパラメータからノード・リスナーを削除できます。ただし、ノード・リスナーのみがデータベースの専用サーバーを作成できるため、リスナー自体を削除することはできません。
|
関連項目: 単一クライアント・アクセス名(SCAN)の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle ASMのアップグレード後に、Oracle ASMパスワードのリセットおよびディスク・グループの構成などの作業を行うことをお薦めします。
Oracle ASMのアップグレード後に行うことが推奨されている作業は次のとおりです。
次の作業を実行することも検討してください。これらの作業については、この章の前の方で説明しています。
COMPATIBLE.ASMディスク・グループ属性を12.1に拡張した場合、ASMディスク・グループに共有パスワード・ファイルを作成する必要があります。ディスク・グループでの共有パスワード・ファイルの管理の詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
パスワードでの大/小文字の区別を強制できます。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。
Oracle Database 11gリリース1 (11.1)より前のリリースでは、パスワードで大文字と小文字は区別されませんでした。パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいOracle ASMインスタンスの場合は、追加の作業や追加の管理要件はありません。アップグレードしたOracle ASMのインスタンスの場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。
|
注意: Oracle Databaseのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
ソフトウェア・バージョンをまたいでOracle DatabaseとOracle ASMのディスク・グループの互換性設定を拡張できます。
互換性を拡張することにより、新しいリリースのみで使用可能な新機能が有効になります。ただし、こうすることで、ソフトウェアの古いリリースではディスク・グループが非互換になります。ディスクの互換性を拡張する操作は、元に戻すことができません。
compatible.rdbmsおよびcompatible.asm属性を使用して、データベース・インスタンスおよびOracle ASMインスタンスからディスク・グループにアクセスするのに必要な最小ソフトウェア・リリースをそれぞれ指定します。たとえば、次のALTER DISKGROUP文によって、ディスク・グループasmdg2のOracle ASMの互換性が拡張されます。
ALTER DISKGROUP asmdg2 SET ATTRIBUTE 'compatible.asm' = '11.2'
この場合、ディスク・グループを管理できるのはリリース11.2以上のOracle ASMソフトウェアのみですが、データベース・クライアントはリリース10.2以上であれば、このディスク・グループを使用できます。
|
関連項目: ディスク・グループの互換性の詳細は『Oracle Automatic Storage Management管理者ガイド』を、ALTER DISKGROUP文およびCREATE DISKGROUP文のディスク・グループ互換性属性の詳細は『Oracle Database SQL言語リファレンス』を参照してください。 |
Oracle ASMの管理者は、一部のディスクを他のディスクより優先して読取りI/O操作に使用するよう指定できます。Oracle ASMの優先読取りの障害グループを定義した場合、Oracle ASMでは常にプライマリ・コピーから読み取るのではなく、最も近いエクステントから読み取ることができます。
Oracle Database Expressのデータベースに含まれているのは、Oracle Database Standard EditionまたはOracle Database Enterprise Editionのデータベースで使用できるコンポーネントのサブセットのみです。新しいOracle Databaseリリースにアップグレードした後、Database Configuration Assistant (DBCA)を使用して追加のコンポーネントをデータベースにインストールできます。
元のデータベースにOracle Application Expressバージョン4.2からバージョン4.2.5.00.08までが含まれていた場合は、4.2.5パッチ・セットが適用されていました。しかし、Oracle Application Expressに付属のパッケージ・アプリケーションが、パッチ・セットの適用時に4.2.5バージョンに更新されていませんでした。スクリプトを実行して、パッケージ・アプリケーションを更新する必要があります。Oracle Application Expressが非CDBにインストールされているか、ローカルでPDBにインストールされている場合、ここに示す手順に従ってください。
非CDBでパッケージ・アプリケーションを更新するには、次の手順を実行します。
現行ディレクトリをOracleホームの最上位レベルの"apex"ディレクトリに設定します。
SQL*Plusを起動し、Oracle Application Expressをインストールするデータベースに、SYSDBAロールが指定されているSYSとして接続します。
Windowsの場合:
C:\ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password
Linuxの場合:
$ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password
次の例に示すように、apex_pkgapp_ins.sqlを実行します。
@apex_pkgapp_ins.sql
CDBでパッケージ・アプリケーションを更新するには、次の手順を実行します。
現行ディレクトリをOracleホームの最上位レベルの"apex"ディレクトリに設定します。
SQL*Plusを起動し、Oracle Application Expressをインストールするデータベースに、SYSDBAロールが指定されているSYSとして接続します。
Windowsの場合:
C:\ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password
Linuxの場合:
$ sqlplus /nolog
SQL> CONNECT SYS as SYSDBA
Enter password: SYS_password
次の例に示すように、apex_pkgapp_con.sqlを実行します。
@apex_pkgapp_con.sql
DBUAを使用せず手動でOracle Databaseのアップグレードを実行している場合は、データベースをアップグレードした後で、必要な作業を実行する必要があります。
アップグレード元のリリースによっては、新しいアカウントが提供されている場合があります。SYSおよびSYSTEM以外のオラクル社が提供するアカウントは、すべてロックしてパスワードを期限切れにし、アカウントのロックを解除したときに新しいパスワードの指定が要求されるようにすることをお薦めします。
|
注意: Oracle Database 12cのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
次のSQL文を発行して、すべてのアカウントの状態を確認できます。
SQL> SELECT username, account_status
FROM dba_users
ORDER BY username;
次のSQL文を発行して、パスワードをロックまたは期限切れにします。
SQL> ALTER USER username PASSWORD EXPIRE ACCOUNT LOCK;
REMOTE_LOGIN_PASSWORDFILE初期化パラメータがexclusiveまたはsharedに設定されている場合、ORAPWDでパスワード・ファイルを作成および移行します。Oracle Database 12cでは、既存のデータベースからパスワード・ファイルを移行するために、ORAPWDに新しいオプションが提供されています。
|
関連項目: パスワード・ファイルの作成および移行の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
従来の初期化パラメータ・ファイルを使用している場合は、次の手順でサーバー・パラメータ・ファイルへ移行します。
初期化パラメータ・ファイルがクライアント・コンピュータ上にある場合は、クライアント・コンピュータからサーバー・コンピュータに転送します。
|
注意: Oracle RACを使用している場合は、すべてのインスタンス固有の初期化パラメータ・ファイルを単一の初期化パラメータ・ファイルに結合する必要があります。クラスタ・データベース用のサーバー・パラメータ・ファイルの使用方法およびその他のアクションについては、次のマニュアルを参照してください。
|
CREATE SPFILE文を使用して、サーバー・パラメータ・ファイルを作成します。この文は、初期化パラメータ・ファイルを読み取り、サーバー・パラメータ・ファイルを作成します。CREATE SPFILE文を発行するために、データベースを起動する必要はありません。
新しく作成されたサーバー・パラメータ・ファイルを使用して、インスタンスを起動します。
|
関連項目:
|
新しいOracle Database 12cリリースへアップグレードした後、次のファイルを以前のOracleホームから新しいOracleホームにコピーします。
ステミング・ユーザー・ディクショナリ・ファイル
ユーザーが変更したKOREAN_MORPH_LEXERディクショナリ・ファイル
USER_FILTER実行可能ファイル
これらのファイルは、指定されたOracleホームにインストールされているすべてのデータベースに影響します。
これらのファイルのリストは、次の方法で取得できます。
$ORACLE_HOME/ctx/admin/ctxf102.txtにあるテキスト・ファイルを読みます。
データベース・ユーザーSYS、SYSTEMまたはCTXSYSで、$ORACLE_HOME/ctx/admin/ctxf102.sqlを実行します。
|
関連項目:
|
Oracle Clusterwareを使用している場合は、データベースのOracle Clusterwareキーをアップグレードする必要があります。
Oracle Database 12cのsrvctlを実行してデータベースをアップグレードします。次に例を示します。
ORACLE_HOME/bin/srvctl upgrade database -db name -o ORACLE_HOME
|
関連項目: srvctl upgrade databaseの構文は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』 |
Oracle Databaseの新しいリリースごとに新しい初期化パラメータが導入され、非推奨となったり、サポートが終了した初期化パラメータもあります。ご使用のシステムに有効な新しい初期化パラメータを使用するために、これらの変更に対してパラメータ・ファイルを調整する必要があります。また、DBUAを使用しないで手動アップグレードを実行した場合、tnsnames.oraファイルには新しい構成情報と設定が自動的に移入されません。したがって、手動でtnsnames.oraを更新し、local_listenerおよびremote_listenerパラメータ参照を調節する必要があります(これらを解決する必要がある場合)。
|
関連項目:
|
COMPATIBLE初期化パラメータは、ご使用のデータベースの互換レベルを制御します。データベースを元のリリースにダウングレードする必要がない場合は、新しいデータベースで必要な互換性レベルに基づいてCOMPATIBLE初期化パラメータを設定します。
COMPATIBLE初期化パラメータ値を増やすには、次の手順を実行します。
COMPATIBLE初期化パラメータ値を増やす前に、データベースのバックアップを取ります(オプション)。
COMPATIBLE初期化パラメータ値を増やすことによって、現在のデータベースが以前のリリースのOracle Databaseとは非互換になる可能性があります。バックアップを取っておくと、必要に応じて以前のリリースに戻すことができます。
|
関連項目: バックアップの実行の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
サーバー・パラメータ・ファイルを使用している場合は、次の手順を実行します。
サーバー・パラメータ・ファイルを更新して、COMPATIBLE初期化パラメータの値を設定または変更します。
たとえば、COMPATIBLE初期化パラメータを11.0.0に設定するには、次の文を入力します。
SQL> ALTER SYSTEM SET COMPATIBLE = '11.0.0' SCOPE=SPFILE;
インスタンスを停止し、再起動します。
初期化パラメータ・ファイルを使用している場合は、次の手順を実行します。
インスタンスが実行している場合は、停止します。
SQL> SHUTDOWN IMMEDIATE
初期化パラメータ・ファイルを編集して、COMPATIBLE初期化パラメータの値を設定または変更します。
たとえば、COMPATIBLE初期化パラメータをfor Oracle Database release 12.1に設定するには、初期化パラメータ・ファイルに次を入力します。
COMPATIBLE = 12.1.0
STARTUPを使用してインスタンスを起動します。
|
注意: ASMディスク・グループを使用している場合、ディスク・グループの互換性属性は、init.oraのデータベース互換性パラメータの値以下である必要があります。 |
手動アップグレードの実行後、tnsnames.oraで解決する必要がある場合は、local_listenerおよびremote_listenerパラメータ参照を調節する必要があります。DBUAは、自動アップグレード時にネットワーク・ネーミングとリスナーの変更を処理しますが、手動アップグレード時には、tnsnames.oraもリスナーも変更されません。
|
関連項目:
|
Oracle RACデータベースのアップグレードでは、「アップグレードのための新しいOracleホームの準備」に、クラスタ・データベースをアップグレードする前にCLUSTER_DATABASE初期化パラメータをfalseに設定するよう指示がありました。アップグレードが完了した時点で、この初期化パラメータをtrueに設定する必要があります。
