| Oracle® Databaseプラットフォーム共通日本語README 12cリリース1 (12.1) B71333-15 |
|
 前 |
 次 |
この章では、Oracle Database 12cリリース1 (12.1.0.1)のOracle Databaseドキュメント・ライブラリには含まれていない、重要な最新機能と変更について説明します。
この章は、次の項目で構成されています。
3.1項「互換性、アップグレード、ダウングレードおよびインストール」
3.2項「Oracle Database 12.1.0.1で使用できないか、制限されている機能」
3.4項「Oracle Database 12cの非推奨機能およびサポートが終了した機能」
3.6項「Oracle Automatic Storage Management(Oracle ASM)」
3.7項「Oracle Application Express」
3.10項「Oracle Enterprise Manager」
3.11項「Oracle Exadataデータベース・マシンおよびSPARC SuperCluster」
3.12項「クラスタ用のOracle Grid Infrastructure」
3.17項「Oracle Warehouse Builder」
アップグレード前、アップグレード後、互換性および相互運用性の説明に関する最新の更新情報およびベスト・プラクティスについては、Upgrade Companion WebサイトにリンクするMy Oracle Support (https://support.oracle.com)のノート1462240.1を参照してください。
|
注意: インストールの完了後、Oracleソフトウェアの実行中に、cronまたは/tmp/.oracleディレクトリ、あるいはそれらのファイルを、手動で削除したり、削除する/var/tmp/.oracleジョブを実行したりしないでください。これらのファイルを削除すると、Oracleソフトウェアが断続的にハングする場合があります。クラスタ用のOracle Grid InfrastructureおよびOracle Restartのインストールが失敗し、次のエラーが表示されます。CRS-0184: Cannot communicate with the CRS daemon. |
注意:
同じリリースのインストール・メディアを使用して、Oracleソフトウェアを削除する必要があります。新しいリリースのインストール・メディアを使用して、古いリリースからOracleソフトウェアを削除しないでください。たとえば、12.1.0.1のインストール・メディアから削除を実行して、既存の11.2.0.4 OracleホームからOracleソフトウェアを削除しないでください。
Oracle Database 12cリリース1 (12.1.0.1)へのアップグレード後、CHARパラメータがNCHAR以上の値に設定されている場合、オプティマイザによりヒストグラム統計を含んだOPTIMIZER_FEATURES_ENABLEまたは11.2.0.4データ型列に対して最適以下のプランが生成されます。12.1.0.1が、Oracle Database 12cリリース1 (12.1.0.1)のOPTIMIZER_FEATURES_ENABLEパラメータのデフォルト値です。
この問題の回避策の1つとしては、Oracle Bug#18255105のためのパッチを適用します。このパッチにより、ヒストグラム統計を含んだCHARまたはNCHARデータ型列が陳腐化としてマークされます。このパッチは、自動統計収集または手動統計集(GATHER AUTOまたはGATHER STALEオプション)を使用して、問題のある表で統計を収集する場合にも便利です。
別の回避策としては、ヒストグラム統計を含んだCHARまたはNCHARデータ型列のある表を見つけ(DBA_TAB_COL_STATISTICSビューを使用)、その表でGATHER_TABLE_STATSプロシージャを実行します。本番システムでGATHER_TABLE_STATSプロシージャを使用するかわりに、テスト・システムで統計を収集し、ユーザーの統計表に統計をエクスポートし、本番システムに統計をインポートします。この回避策の場合、Oracle Bug#18255105のためのパッチの必要がありません。
統計を収集する際、NO_INVALIDATEパラメータをFALSEに設定すると、SQL文の再実行時に既存のカーソル(最適以下のプランが含まれる)は共有されません。
次のすべてのシナリオのある表の統計を収集する場合に最適以下のプランが生成される可能性があります。
表にCHARまたはNCHARデータ型列が含まれる。
OPTIMIZER_FEATURES_ENABLEパラメータが11.2.0.4以上に設定されている。
表にヒストグラムが含まれる。
後で、OPTIMIZER_FEATURES_ENABLEパラメータ値を11.2.0.4よりも前の値に変更する(たとえば、Oracle Databaseをダウングレードし、OPTIMIZER_FEATURES_ENABLEパラメータをより小さい値に設定する)。
このシナリオでは、OPTIMIZER_FEATURES_ENABLEパラメータの変更後にこれらの表の統計を再収集する必要があります。
12.1.0.1から11.2.0.4へダウングレードした後には、DBA_REGISTRY内の簡易なSpatial (SDO)ネットワーク・コンポーネントと、次の2つのSpatialオブジェクトのステータスが無効になります(Oracle Bug#16757980を参照)。
関数MDSYS.SDO_OWM_INSTALLED
パブリック・シノニムSDO_OWM_INSTALLED
12.1.0.1で、ダウングレード(@catdwgrd.sql)の実行後、次のコマンドを使用して無効なSpatialオブジェクトを削除します。
drop function mdsys.SDO_OWM_INSTALLED; drop public synonym SDO_OWM_INSTALLED;
その後、@catrelod.sqlおよび@utlrpの手順を実行します。
JAVAVMコンポーネントがデータベース・レジストリに存在しないか、preupgrd.sqlまたはINVALIDに設定されている場合、アップグレード前ツール(OPTION OFF)は、出力ファイルを格納するためのディレクトリを作成できません。次に例を示します。
SQL> @/tmp/preupgrd Loading Pre-Upgrade Package ... WARNING: Failed to open preupgrade.log for write access script will generate terminal output only WARNING: Failed to open preupgrade_fixups.sql for write access script will not generate fixup scripts. Results of the checks are located at: *** Scripts/Logs are not being Generated *** preupgrade.log
回避策としては、次の手順を実行して、preupgrd.sqlの実行前に出力ディレクトリを手動で作成します。
環境設定でORACLE_BASEが定義されている場合は、ディレクトリ$ORACLE_BASE/cfgtoollogs/<db-unique-name>/preupgradeを作成するか、ディレクトリ$ORACLE_HOME/cfgtoollogs/<db-unique-name>/preupgradeを作成します。
<db-unique-name>を取得するには、次の問合せを使用します。
SELECT value FROM V$PARAMETER WHERE NAME = 'db_unique_name';
ディレクトリ・パスで使用される<db-unique-name>は、大/小文字が区別されます。
preupgrd.sqlツールを再実行します。
ディレクトリからルート構成スクリプトを実行する際、スクリプトを実行するユーザーがそのディレクトリに対する書込み権限を持っていない場合、またはファイル・システムにエクスポートしたOracle Local Registryのコンテンツを含むファイルを作成する十分な領域がない場合、次のエラーが表示されてスクリプトは失敗します(Oracle Bug#16626394を参照)。
PROTL-3: Failed to create export file 'OLRUPGRADEFILE' CLSRSC-169: Failed to create or upgrade OLR
この問題を回避するには、インストールするユーザーが書込み権限を持つディレクトリから構成スクリプトを実行します。また、ファイル・システムに、エクスポートしたファイルを書き込む十分な領域が存在する必要があります。
Oracle Database 12cでは、SEC_CASE_SENSITIVE_LOGONシステム・パラメータがパラメータ・ファイルにある場合、アップグレード・プロセス中にDatabase Upgrade Assistant (DBUA)により削除されます(Oracle Bug#16238456を参照)。
SEC_CASE_SENSITIVE_LOGONシステム・パラメータがアップグレード前にFALSEに設定されていた場合、アップグレード後、SEC_CASE_SENSITIVE_LOGONシステム・パラメータのデフォルト値はTRUEに設定され、ログイン時には大文字と小文字の区別が必要になります。
DBUAアップグレード・プロセスの後にパラメータ・ファイルのSEC_CASE_SENSITIVE_LOGONシステム・パラメータの設定をFALSEに戻すか、パスワードの大文字小文字の区別のあるバージョンを使用してログインします。
Oracle Exadata環境で、アップグレード対象のデータベースに多数の表領域(64,000など)および対応するデータファイルがあり、表領域ごとにOracle ASMに1つのデータファイルが格納されている場合に、Database Upgrade Assistant (DBUA)がサービスを起動すると、失敗するか、データファイルが多数あるために起動に長時間かかることがあります(Oracle Bug#16738865を参照)。
グローバル・データ・サービスのインストールおよび構成の情報は、Oracle Database Global Data Services概要および管理ガイド12cリリース1 (12.1)の第2章を参照してください。このマニュアルの部品番号はE22100-01です。
リリースOracle Database 12cから11.2.0.2へダウングレードするときは、catrelod.sqlの更新バージョンを提供するリリース11.2.0.2用のパッチ11811073を適用する必要があります。このパッチは、catrelod.sqlを実行して11.2.0.2のホームからPL/SQLパッケージの再ロードを試みる前に、いつでも11.2.0.2のホームに適用できます。
リリースOracle Database 12cから11.2.0.3または11.2.0.2へダウングレードするときに、SQLJタイプが存在する場合、ORA-00600の実行後に無効なオブジェクトを再コンパイルするためのutlrp.sqlを実行すると、次のcatrelod.sqlエラーが発生する可能性があります(Oracle Bug#16230705を参照)。
ORA-00600: internal error code, arguments: [16211]
このエラーを回避するには、@utlrp.sqlを実行する前に(@catrelod.sql後に)元のリリース(11.2.0.2または11.2.0.3)に修正を適用する必要があります。
アップグレードの間にノード・クラッシュが発生した場合、-forceアップグレードを実行して、部分的なクラスタから使用できないノードを除いた部分をアップグレードできます(Oracle Bug#12933798を参照)。
-forceアップグレードを実行した後、インベントリ内のGridホームのノード・リストは、Oracle Grid Infrastructureの実際のデプロイメントと同期していません。ノード・リストにはまだ使用できないノードが含まれます。インベントリのノード・リストが正しくないので、その後のアップグレードまたはノードの追加およびOracle Grid Infrastructureの他のデプロイメントは失敗します。
-forceアップグレードを実行した後、CRSユーザーとして次のコマンドを手動で呼び出してください。
$GRID_HOME/oui/bin/runInstaller -updateNodeList "CLUSTER_NODES={comma_separated_alive_node_list}" ORACLE_HOME=$GRID_HOME CRS=true
リリースOracle Database 11gリリース1 (11.1)からOracle Database 12cにアップグレードすると、インストーラでクラスタ検証ユーティリティ(CVU)前提条件チェックを実行した後に、次のエラーが発生する可能性があります。
Verify that default ASM disk discovery string is used - This is a prerequisite check to warn users that permission must be granted to devices so that all ASM devices visible with the pre-Version 12 default discovery string "/dev/raw/*" are also visible with the Version 12 default discovery string "/dev/sd*"
このエラーは無視してかまいません。ただし、デフォルトの検出文字列を使用してOracle ASMディスクが表示可能であることを確認してください。
Oracle ASMディスク検出文字列を設定するには、次のSQL文を使用します。
ALTER SYSTEM SET ASM_DISKSTRING=<usr_string> SCOPE-SPFILE;
この後の各項では、今回のリリースのOracle Database 12cリリース1 (12.1.0.1)で使用できない、または制限されているコンポーネントについて説明します。
次に示すのは、Oracle Database 12cリリース1 (12.1.0.1)のマルチテナント・コンテナ・データベースで使用できない、または制限されている機能のリストです。
データベース変更通知
連続問合せ通知(CQN)
クライアント側キャッシュ
フラッシュバック・データ・アーカイブ(FDA)
フラッシュバック・トランザクション問合せ
フラッシュバック・トランザクション・バックアウト
ヒート・マップ
自動データ最適化
Oracle Streams
データベースUnicode移行アシスタント(DMU)
次のリストは、このリリースのOracle Database 12cリリース1 (12.1)で使用できないか制限されているコンポーネントのリストです。
時間隔パーティションは、XMLIndexでサポートされていません。XMLIndexでは、範囲、リストおよびハッシュ・パーティション化スキームのみがサポートされます。
共有サーバーおよびOracle XML DBは、LISTENER_NETWORKS初期化パラメータへの登録用にはサポートされていません(Oracle Bug#16051343を参照)。共有サーバー接続にはかわりにLOCAL_LISTENERおよびREMOTE_LISTENERを使用してください。
Oracle Database 12cでは、アプリケーション・コンティニュイティによるデータベース・レジデント接続プール(DRCP)のサポートはありません(Oracle Bug#14792095を参照)。
Oracle Database 12cの最初のリリースでは、プロキシ認証の使用時に再生がアプリケーション・コンティニュイティに対してサポートされません。
データベース・セキュリティでは次の変更が加えられています。
|
注意: これは、Oracle Clusterwareと中間層/JDBCクライアント間の接続のセキュリティに影響します。 |
JDBCまたはOracle Universal Connection Pool (UCP)のOracle RAC機能(高速接続フェイルオーバー(FCF)など)は、Oracle RACノード上で実行されているOracle Notification Service (ONS)からの通知をサブスクライブします。データベース層のONSサーバーと中間層の通知クライアントとの間の接続は、通常は認証されません。SSL証明書を構成および使用して認証を設定することも可能ですが、手順は明確に文書化されていません。
回避策は次のとおりです。
orapkiインタフェースを使用してSSL証明書を保存するためのOracle Walletを作成します。
cd $ORA_CRS_HOME/opmn/conf
mkdir sslwallet
orapki wallet create -wallet sslwallet -auto_login
プロンプトが表示されたら、パスワードとしてONS_Walletと入力します。
orapki wallet add -wallet sslwallet -dn "CN=ons_test,C=US" -keysize 1024 -self_signed -validity 9999 -pwd ONS_Wallet
orapki wallet export -wallet sslwallet -dn "CN=ons_test,C=US" -cert sslwallet/cert.txt -pwd ONS_Wallet
手順cで作成したウォレットを、同じ場所にある他のすべてのクラスタ・ノードにコピーします。
クラスタ内のすべてのノード上のONSサーバーを停止します。
srvctl stop nodeapps
データベース層のすべてのノード上のONS構成ファイルを更新して、手順1で作成したウォレットの場所を指定します。
ファイルORA_CRS_HOME/opmn/conf/ons.configを開きます。
walletfileパラメータをons.configファイルに追加します。
walletfile=ORA_CRS_HOME/opmn/conf/sslwallet
次のsrvctlコマンドを使用して、ONSサーバーを再起動します。
srvctl start nodeapps
中間層でクライアントサイドONSデーモンを実行している場合は、次の2つの構成が考えられます。
OPMNから起動されるONS(Oracle AS 10.1.3.xの場合など)。構成にはopmn.xmlが使用されます。
スタンドアロンで起動するONS(onsctlを使用する場合など)。構成にはons.configが使用されます。
ケース(1)の場合は、『OPMN管理者ガイド』でOracle Application Serverのリリースを参照してください。opmn.xmlファイルを変更してウォレットの場所を指定する必要があります。
ケース(2)の場合は、『Oracle Database JDBC開発者ガイド』の「付録B」にある「ONSの構成」という項を参照してください。クライアントサイドONSデーモンは、異なるマシンに対して実行される可能性があります。手順1で作成したウォレットをそれらのクライアントサイド・マシンにコピーし、ons.configファイルまたはopmn.xmlファイルで、該当のクライアントサイド・マシンでのパスを指定してください。
クライアントサイドONSデーモンなしでリモートONS構成を実行している場合は、『Oracle Database JDBC開発者ガイド』の「高速接続フェイルオーバー」の章で、「高速接続フェイルオーバーの使用」の項の「高速接続フェイルオーバー用のONSの構成」サブ項にある、「リモートONSサブスクリプション」サブ項を参照してください。手順1で作成したウォレットをそれらのクライアントサイド・マシンにコピーし、ons.configファイルまたはopmn.xmlファイルで、該当のクライアントサイド・マシンでのパスを指定してください。
なお、setONSConfiguration引数として次の文字列を指定することもできます。
propertiesfile=location_of_a_Java_properties_file
Javaプロパティ・ファイルには、次のONS Javaプロパティを1つ以上含める必要があります(oracle.ons.nodesプロパティは必須)。これらのJavaプロパティの値は、この手順で前述した「リモートONSサブスクリプション」サブ項に記載されているものと同様です。
oracle.ons.nodes oracle.ons.walletfile oracle.ons.walletpassword
データベース・セッションがホストとポートで実行されているJDWPデバッガに接続するには、JDWPと呼ばれる追加のアクセス・コントロール・リスト(ACL)権限が必要です。この権限は、次のコールを使用してデータベース管理者が付与できます。
begin
dbms_network_acl_admin.append_host_ace(
host => '<debugger-host>',
lower_port => <JDWP-port>,
upper_port => <JDWP-port>,
ace => xs$ace_type(privilege_list => xs$name_list('jdwp'),
principal_name => '<debugging-user>',
principal_type => xs_acl.ptype_db));
end;
ホスト・パラメータには、ホスト名、IPアドレス、ドメイン名またはIPサブネットを指定できます。lower_portとupper_portの値を省略すると、任意のポート番号で接続できます。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
Oracle Database 12cでは、新機能追加の他に、データベースの動作の変更が行われています。動作の変更には、初期化パラメータ、オプション、構文、機能およびコンポーネントの非推奨とサポートの終了が含まれます。詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
この項では、Oracle Database 12cリリース1 (12.1)と旧リリースのデータベースの動作の違いをいくつか説明します。アップグレードおよびダウングレードに関する大部分の情報は、『Oracle Databaseアップグレード・ガイド』に記載されています。
この後の各項では、Oracle Database 12cリリース1 (12.1)のOracle Automatic Storage Management (Oracle ASM)に関する情報について説明します。
Oracle Application Expressの詳細は、『Oracle Application Expressリリース・ノート』および『Oracle Application Expressインストレーション・ガイド』を参照してください。
Oracle Data Miningを使用する際は、次のことに注意してください。
次のデータ・マイニング機能のサポートはこのリリースで終了しました。
Oracle Data Mining Java API
Adaptive Bayes Network(ABN)アルゴリズム
Data Mining APIを説明するデモ・プログラムは、Oracle Database Examplesとともにインストールされます。Data Miningデモ・プログラムのインストールおよび構成の手順は、『Oracle Data Miningユーザーズ・ガイド』を参照してください。
Oracle Data Miningスコアリング機能は、Oracle Exadata Storage Serverソフトウェアでも使用できます。記憶域レイヤーのスコアリング機能により、膨大なデータセットを迅速にマイニングできるため、すでにOracleインデータベースの分析により得ている競争上の優位性をさらに高めることができます。Oracle Exadata Storage Serverソフトウェアの詳細は、http://www.oracle.com/technetwork/server-storage/engineered-systems/exadata/を参照してください。
Oracle Database Vaultを使用する際は、次のことに注意してください。
Oracle Database VaultがインストールされているOracle Database 12cデータベースを11.2.0.3にダウングレードする際、次のエラーが表示されます(Oracle Bug#14217829を参照)。
ERROR at line 1: ORA-31011: XML parsing failed ORA-19202: Error occurred in XML processing LPX-00222: error received from SAX callback function ORA-00001: unique constraint (DVSYS.REALM_T$_UK1) violated ORA-06512: at "DVSYS.DBMS_MACADM", line 114 ORA-06512: at line 2
このエラーは予想されているものであり、無視しても問題ありません。Oracle Database Vaultの機能に影響はありません。
DVSYS.CONFIGURE_DVプロシージャを実行してOracle Database Vaultをデータベースに登録した後、データベースに無効なオブジェクトが存在することがあります(Oracle Bug#7631281を参照)。
この問題を回避するには、次の手順を実行してください。
SYSDBA管理権限を付与されたユーザーとしてSQL*Plusにログインします。次に例を示します。
sqlplus sys as sysdba
Enter password: password
SQL*Plusで、無効なオブジェクトを見つけるために次の問合せを実行します。
SELECT COUNT(*) FROM ALL_OBJECTS WHERE STATUS = 'INVALID';
無効なオブジェクトがある場合、utlrp.sqlスクリプトを実行し(これは、デフォルトでは$ORACLE_HOME/rdbms/adminディレクトリにあります)、無効なオブジェクトを再コンパイルします。
@?/rdbms/admin/utlrp.sql
utlrp.sqlスクリプトで指示が出たらそれに従い、スクリプトを再実行します。スクリプトがなんの指示も示さず異常終了した場合は、再実行します。
次に、Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以降とデータベース・プラグインのバージョン12.1.0.3以降でサポートされているアイテム、およびOracle Enterprise Manager Grid Controlバージョン10g、11gおよびOracle Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)でサポートされていないアイテムを示します。(Oracle Bug#16605386を参照)
Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以降とデータベース・プラグインのバージョン12.1.0.3以降では、次のことがサポートされています。
Database Configuration Assistant (DBCA)またはOracle Universal Installer (OUI)を使用した12cデータベースの作成。
12cより前のデータベースがOracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以降とデータベース・プラグインのバージョン12.1.0.3以降によって監視されている場合、アップグレード時にDatabase Upgrade Configuration Assistant (DBUA)またはOracle Universal Installer (OUI)を使用して「管理オプション」画面で選択された場合は、データベースのORACLE_HOMEプロパティがEnterprise Managerで更新されます。
Oracle Enterprise Manager Grid Controlバージョン10g、11gおよびOracle Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)では、Cloud Controlコンソールを使用した12cデータベースの作成はサポートされません。
回避策1:
データベースを作成する前に、Oracle Enterprise Managerを12cリリース2 (12.1.0.2)以降にアップグレードします。Database Configuration Assistant (DBCA)またはOracle Universal Installer (OUI)を使用してデータベースを作成する際に、「管理オプション」画面に同じ内容を入力します。
回避策2:
Grid ControlまたはCloud Controlコンソールを使用してデータベースを作成した後、検出を実行するか、ターゲットを手動でOracle Enterprise Managerに追加します。Oracle Enterprise Managerを12cリリース2 (12.1.0.2)にアップグレードせずに検出を実行すると、一部の監視機能が失われる可能性があります。
Database Configuration Assistant (DBCA)またはOracle Universal Installer (OUI)を使用してDatabase Controlが12cリリース2 (12.1.0.2)に構成された、12cより前のデータベースのアップグレード後、Oracle Enterprise Manager Database Control (DB Control)がサポートされなくなります。
回避策:
今後の監視には、Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以降を使用します。
Database Configuration Assistant (DBCA)またはOracle Universal Installer (OUI)を使用して、Oracle Enterprise Manager Grid Controlバージョン10g、11gまたはOracle Enterprise Manager Cloud Control 12cリリース1 (12.1.0.1)によって監視されていた12cより前のデータベースを12cリリース2 (12.1.0.2)以降にアップグレードした後、ORACLE_HOME変数を更新できなくなります。
回避策1:
データベースをアップグレードする前に、Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)以降にアップグレードします。Database Configuration Assistant (DBCA)またはOracle Universal Installer (OUI)を使用する際、「管理オプション」画面と同じ内容を入力します。
回避策2:
Grid ControlまたはCloud Controlコンソールを使用して、「モニタリング構成」でデータベースおよび関連するターゲットのORACLE_HOME変数を更新します。
次の手順を実行して、Oracle Enterprise Manager Grid ControlまたはOracle Enterprise Manager Cloud Controlでターゲットのプロパティを変更します。
「ターゲット」ページに移動して「すべてのターゲット」をクリックします。
ターゲットを選択します。
メニュー項目を選択し、「ターゲット設定」をクリックしてから「モニタリング構成」をクリックします。
モニタリング構成ページで、「Oracleホーム・パス」をアップグレードしたOracleホームに設定します。
Cluster Ready Services (CRS)および関連するターゲットがOracle Enterprise Manager Grid ControlまたはOracle Enterprise Manager Cloud Controlによって監視されている場合、Oracle Universal Installer (OUI)を使用して12cより前のOracle Clusterwareまたは単一インスタンスの高可用性(SIHA)データベースを12cにアップグレードするときに、Oracle Clusterware、Oracleデータベースの高可用性サービス、Oracle Net Listener、Oracle Automatic Storage Management (Oracle ASM)などのターゲットのORACLE_HOME変数を更新できません。
回避策:
Oracle Enterprise Manager Grid ControlまたはCloud Controlコンソールを使用して、Oracle Clusterware、Oracleデータベースの高可用性サービス、Oracle Net Listener、Oracle Automatic Storage Management (Oracle ASM)などのターゲットのORACLE_HOME変数を手動で変更します。
その後、Windowsで、管理エージェント・サービスを自動起動タイプに変更します。
次の手順を実行して、Oracle Enterprise Manager Grid ControlまたはOracle Enterprise Manager Cloud Controlでターゲットのプロパティを変更します。
「ターゲット」ページに移動して「すべてのターゲット」をクリックします。
ターゲットを選択します。
メニュー項目を選択し、「ターゲット設定」をクリックしてから「モニタリング構成」をクリックします。
モニタリング構成ページで、「Oracleホーム・パス」をアップグレードしたOracleホームに設定します。
Cluster Ready Services (CRS)および関連するターゲットがOracle Enterprise Manager Database Control (DB Control)によって監視されている場合、Oracle Universal Installer (OUI)を使用して12cより前のOracle Clusterwareまたは単一インスタンスの高可用性(SIHA)データベースを12cにアップグレードするときに、Oracle Clusterware、Oracleデータベースの高可用性サービス、Oracle Net Listener、Oracle Automatic Storage Management (Oracle ASM)など関連するターゲットのORACLE_HOME変数をDatabase Controlで更新できません。
回避策:
Database Controlユーザー・インタフェースを使用して、Oracle Clusterware、Oracleデータベースの高可用性サービス、Oracle Net Listener、Oracle Automatic Storage Management (Oracle ASM)などのターゲットのORACLE_HOME変数を手動で変更します。
Oracle Enterprise Manager Database Control (DB Control)でターゲットのプロパティを変更するには、次の手順を実行します。
エージェント・ページに移動してエージェントをクリックします。
ターゲットを選択して、「構成」をクリックします。
モニタリング構成ページで、「Oracleホーム・パス」をアップグレードしたOracleホームに設定します。
Oracle Exadataデータベース・マシンおよびSPARC SuperClusterは、Oracle Exadata Storage Serverソフトウェア・バージョン11.2.3.2.1以上が実行されているシステム上でOracle Database 12cを実行しているデータベースをサポートします。Oracle Database 12cリリース1 (12.1)データベースは、同一クラスタ内で、Oracle Database 11gリリース2 (11.2)を実行している他のデータベースと並行して実行できます。Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)をデータベース以上のバージョンにアップグレードするための、一般的なルールが適用されます。
次の既知の制限があります。
Oracle Database 12cオフロード・ライブラリは、Oracle Exadata Storage Serverソフトウェア・バージョン12.1.1.1.0以上にしかありません。そのため、Oracle Database 12cのスマート・スキャン・オフロードは、Exadata Storage Serverソフトウェア・バージョン12.1.1.1.0以上でしか利用できず、それより古いバージョンのExadata Storage Serverソフトウェアでは無効になります。
Oracle Database 12cデータベースのI/Oリソース管理計画は、Exadata Storage Serverソフトウェア・バージョン12.1.1.1.0以上でしか実施されません。
Oracle Database 12cデータベースのセル・メトリックは、OTHER_DATABASEでレポートされます。
Oracle ExadataまたはSPARC SuperClusterでOracle Database 12cを実行するために必要な、最小ソフトウェア要件およびパッチについては、https://support.oracle.comを参照してください。My Oracle Supportを使用するには、事前にオンライン登録する必要があります。My Oracle Supportアカウントを持っていない場合は、オラクル社の営業担当に連絡してください。
クラスタ・インストール用のOracle Grid InfrastructureとともにインストールされるOracle ClusterwareとOracle Automatic Storage Management (Oracle ASM)で作業をする場合には、次のことに注意してください。
一部の非Oracle Grid Infrastructureのマウント・ポイントの使用により、カーネルでのアンマウントおよびボリューム無効化が妨げられます(Oracle Bug#8651848を参照)。例として次のようなものがあります。
ネットワーク・ファイル・システム(NFS)
Samba/共有インターネット・ファイル・システム(CIFS)
このような状況の場合、スタックの停止、ファイル・システムのアンマントまたはボリュームの無効化を開始する前に、必ずこれらの機能の使用を中断します。
また、特定のユーザー・スペース・プロセスおよびシステム・プロセスでは、Oracle Grid Infrastructureスタックがパッチ適用やアップグレード中に停止しないように、ファイル・システムまたはボリューム・デバイスを使用する場合があります。
これが発生した場合は、lsofおよびfuserコマンド(LinuxおよびUNIX)か、handleおよびwmicコマンド(Windows)を使用して、Oracle ACFSファイル・システムとOracle ADVMボリューム上でアクティブなプロセスを特定してください。これらのプロセスが確実にアクティブでなくなるようにするには、すべてのOracle ACFSファイル・システムまたはOracle ADVMボリュームをディスマウントし、Oracle Clusterwareの停止を発行します。このようにしないと、Oracle Clusterwareの停止時にOracle ACFSファイル・システムまたはOracle ADVMボリュームのアクティビティに関してエラーが発行される場合があり、Oracle Clusterwareの正常な停止を妨げることになります。
Oracle interMediaの名称が、Oracle Database 11gリリース1 (11.1)でOracle Multimediaに変更されました。機能は同じで、名称のみが変更されました。Oracle interMediaへの参照はOracle Multimediaに置き換えられますが、Oracle interMediaやinterMediaへの参照が、グラフィカル・ユーザー・インタフェース、コード・サンプル、およびOracle Database 12cリリース1 (12.1)ドキュメント・ライブラリの関連ドキュメントに一部残っている場合があります。
その他の情報は、次のOracle MultimediaのREADMEファイルを参照してください。
ORACLE_HOME/ord/im/admin/README.txt
Oracle ODBCドライバの詳細は、『Oracle ODBCドライバ・リリース・ノート』を参照してください。
Oracle SQL DeveloperのREADMEについては、「Oracle SQL Developer README」を参照してください。
ORACLE_HOME/sqldeveloper/readme.html
Oracle Textを使用する際は、次のことに注意してください。また、「ドキュメントの追加事項」の『Oracle Textアプリケーション開発者ガイド』の記述も確認してください。
Oracle Textのナレッジ・ベースは、テーマの索引付け、ABOUTによる問合せ、およびドキュメント・サービス用のテーマ抽出に使用される、概念の階層ツリーです。次のOracle Textサービスでは、ナレッジ・ベースがインストールされていることが必要です。
BASIC_LEXERプリファレンスでINDEX_THEMES=YESを指定した索引作成
INDEX_THEMES=YESの場合、索引に対するSYNCの実行
CTX_DOC.THEME
CTX_DOC.POLICY_THEME
CTX_DOC.GIST
CTX_DOC.POLICY_GIST
CTX_QUERY.HFEEDBACK
CTX_QUERY.EXPLAIN (ABOUTまたはTHEMESをTRANSFORMとともに使用している場合)
CTX_DOC.SNIPPET (ABOUT演算子を使用している場合)
CTX_DOC.POLICY_SNIPPET (ABOUT演算子を使用している場合)
ABOUTまたはTHEMESをTRANSFORMとともに使用するCONTAINS問合せ
ナレッジ・ベース拡張コンパイラ(ctxkbtc)
テーマが指定されている場合のクラスタリング・サービスと分類サービス
これらのOracle Text機能を使用するには、OTNからダウンロードできるOracle Database Examplesメディアから、ナレッジ・ベース(英語およびフランス語)をインストールする必要があります。
提供されているナレッジ・ベースを拡張したり、英語やフランス語以外の言語で独自のナレッジ・ベースを作成できます。ナレッジ・ベースの作成と拡張の詳細は、『Oracle Textリファレンス』を参照してください。
Oracle Database Examplesメディアから製品をインストールする方法については、プラットフォーム固有のOracle Database Examplesのインストレーション・ガイドを参照してください。
Oracle TextのOracle Database 12cに対する次の制限に注意してください。
BIG_IOおよびSEPARATE_OFFSETSプリファレンスは、次のシナリオではサポートされません。
データベース・セッションが制限されている場合(たとえば、ALTER SYSTEM ENABLE RESTRICTED SESSION)
これらのプリファレンスを使用して作成した索引に対してALTER TABLE MODIFY PARTITIONを実行している場合
大文字と小文字が混在する引用符付きの索引名で索引を作成しようとしている場合
CTX_DDL.RECREATE_INDEX_ONLINEを使用している場合
STAGE_ITABプリファレンスは、次のシナリオではサポートされません。
ALTER INDEX REBUILD PARAMETERS ('resume')を発行しようとしている場合
索引を作成または変更してSYNC ON COMMITを使用しようとしている場合
CTX_DDL.RECREATE_INDEX_ONLINEを使用している場合
CTX_DDL.REMOVE_MDATAを使用している場合
MIGRATE FIELD SECTION句を使用して索引を変更しようとしている場合
FORWARD_INDEXプリファレンスは、次のシナリオではサポートされません。
このプリファレンスを使用した索引に対して、CTX_DDL.SYNC_INDEXおよびCTX_DDL.OPTIMIZE_INDEXを現在実行している場合
同じ索引にSDATAセクションがある場合
Oracle Text索引を非表示にするマーキングはサポートされません。
Oracle Database 12cリリース1 (12.1)でのOracle Warehouse Builder (OWB)の詳細は、『Oracle Warehouse Builderリリース・ノート』を参照してください。
Oracle XML DBでは、次の機能はサポートされていません。
フラッシュバック・データ・アーカイブ
エディショニング・ビュー
SecureFile LOB暗号化
同一XMLドキュメントに構造化と非構造化のハイブリッドXMLIndexが設定されているOracle Label Security (OLS)
Pro*Cの詳細は、Pro*C/C++リリース・ノートを参照してください。
Pro*COBOLの詳細は、『Pro*COBOLリリース・ノート』を参照してください。
SQL*Plusの詳細は、『SQL*Plusリリース・ノート』を参照してください。
サマリー管理を使用する際は、次の事項に注意してください。
Enterprise Editionでは、次の操作を使用できます。
マテリアライズド・ビューの作成機能およびリフレッシュ機能。
SQLアクセス・アドバイザからのクエリー・リライトおよびマテリアライズド・ビューのアドバイス。
特定のマテリアライズド・ビューを使用またはリフレッシュするときは、NLSパラメータが、そのマテリアライズド・ビューで作成した時点のパラメータと同じであることを確認してください。この制限を受けるのは、次の構成メンバーが含まれるマテリアライズド・ビューです。
NLSパラメータの設定に応じて異なる値を戻すことが可能な式
そのような式は、NLSに依存しない方法で記述することをお薦めします。次に例を示します。
(date > DATE '2003-01-02')
または
(rate <= 2.150)
結合の片側が文字データの等価結合
この等価結合の結果は照合によって異なり、セッションごとに変化する可能性があります。クエリー・リライトの場合は正しい結果が得られません。また、リフレッシュ操作後はマテリアライズド・ビューに一貫性がなくなります。
マテリアライズド・ビューの選択リスト内、またはマテリアライズド集計ビューの集計内に文字データへの内部変換を生成する式
この制限は、数値データのみが含まれる式には適用されません。たとえば、a+bとaが数値のbには適用されません。
透過的データ暗号化(TDE)を使用する際は、次のことに注意してください。
Oracle Database 11gリリース1 (11.1)で表領域の暗号化を有効にしたデータベースでは、データベースをプラガブル・データベース(PDB)に変換する前に、Oracle Database 12cリリース1 (12.1)へのアップグレード後、マスターのキー更新を実行する必要があります(Oracle Bug#16219806を参照)。これにより、キー更新コマンドが以前に実行されていない場合、TDE表領域と列の統一暗号化鍵が使用できるようになります。
Oracle Database 12cでは、これは次のコマンドで実行できます。
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY <password>; ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY <password> WITH BACKUP;
この項では、今回のリリースでの既知の不具合を示します。これ以外に、使用しているプラットフォーム固有のリリース・ドキュメントに補足のリストが含まれている場合があります。
READMEのこの項には、さらに次の項があります。
3.24.1項「マルチテナント・コンテナ・データベース(CDB)とプラガブル・データベース(PDB)に関する既知の不具合」
3.24.2項「Database Configuration Assistantに関する既知の不具合」
3.24.4項「Java Database Connectivity (JDBC)に関する既知の不具合」
3.24.5項「Oracle Automatic Storage Management (Oracle ASM)に関する既知の不具合」
3.24.6項「Oracle ASM Dynamic Volume Manager (Oracle ADVM)に関する既知の不具合」
3.24.7項「Oracle ASM Cluster File System (Oracle ACFS)に関する既知の不具合」
3.24.8項「Oracle Database Quality of Service (QoS) Managementに関する既知の不具合」
3.24.9項「Oracle Clusterwareに関する既知の不具合」
3.24.10項「Oracle Database Enterprise Editionに関する既知の不具合」
3.24.12項「Oracle Data Guardロジカル・スタンバイ・データベースに関する既知の不具合」
3.24.13項「Oracle Enterprise Managerに関する既知の不具合」
3.24.14項「Oracle OLAPに関する既知の不具合」
3.24.15項「Oracle Real Application Clusters (Oracle RAC)に関する既知の不具合」
3.24.16項「Oracle SQLJに関する既知の不具合」
3.24.17項「Oracle Textに関する既知の不具合」
3.24.18項「Oracle Universal Installerに関する既知の不具合」
3.24.19項「Oracle XML DBに関する既知の不具合」
3.24.21項「ベンダーとオペレーティング・システムに関する既知の不具合」
この項では、マルチテナント・コンテナ・データベース(CDB)とプラガブル・データベース(PDB)に関する既知の不具合について説明します。
ROOTデータベース内のアカウント(特にANONYMOUS)をロック解除する際には必ず、アクセスさせたくないプラガブル・データベース(PDB)で、そのアカウントを明示的にロックする必要があります。
回避策: ありません。
PDBをCDBから切断すると、SCOPE=BOTHまたはSCOPE=SPFILEでPDBに指定された初期化パラメータの値が、PDBのXMLメタデータ・ファイルに追加されます。ただし、CDBへの接続時に、PDBでこれらの値はリストアされません。
回避策: ありません。
フェイルオーバーDDL操作ALTER DATABASE FAILOVER TO <target_standby_db_unique_name>で、スタンバイ・データベースに接続されていたすべてのセッションを妥当な期間内に終了できないことがあります。このような場合、ORA-3113エラーでフェイルオーバーが失敗します。
回避策: スタンバイ・データベースですべてのノードを停止します。その後、1つのノードをマウントしてフェイルオーバーDDLを再実行します。それでもまだフェイルオーバー操作が失敗する場合は、『Oracle Data Guard概要および管理』の物理スタンバイへのフェイルオーバーの実行に関する項の手順8と9を参照してください。
データベースをOracle Database 12cリリース1 (12.1)にアップグレードしてからCDBに接続すると、自動SQLチューニング・アドバイザにより次のエラーが生成されます。
ORA-65040: operation not allowed from within a pluggable database
このエラーが発生するのは、12.1 CDBでは、自動SQLチューニング・アドバイザはPDB内ではなくCDB$ROOTで実行されることになっているためです。エラーが発生するのは、PDBで、アップグレードしたデータベースから取得された古いプログラムが自動的に実行されるためです。新しいPDBでは、この問題は発生しません。
回避策: 自動SQLチューニング・アドバイザによってORA-65040エラーが生成されたPDBに接続し、DBMS_SCHEDULER.DROP_PROGRAM('AUTO_SQL_TUNING_PROG')プロシージャを使用して、既存の古いAUTO_SQL_TUNING_PROGプログラムを削除してから、execsqlt.sqlスクリプトを実行して再作成します。このスクリプトは、ORACLE_HOME/adminディレクトリにあります。
自動SQLチューニング・アドバイザは、CDBレベルでのみ構成できます。
次の自動メンテナンス・タスクは、CDBまたはPDBレベルで構成できます。
オプティマイザ統計収集
セグメント・アドバイザ
プラガブル・データベース(PDB)レベルでは、共有サーバーを有効化または無効化できません。このため、次のいずれかの回避策を使用する場合を除き、すべてのPDBで共有サーバーを使用するか、すべてのPDBで共有サーバーを使用しないかのどちらかにする必要があります。
回避策: マルチテナント・コンテナ・データベース(CDB)の一部のPDBのみで共有サーバーを使用する場合は、次のいずれかの回避策を使用できます。
専用にする接続の接続別名を変更して、(SERVER=DEDICATED)セクションにCONNECT_DATAを含めます。
専用にする接続がsqlnet.ora初期化パラメータ・ファイルを共有する場合は、USE_DEDICATED_SERVER=onを設定します。
ディスパッチャ構成で、SERVICE=フィールドを使用して共有サーバーを使用するPDBサービスのリストを指定します。
スキーマ・ファイルがある場合、Oracle ASM Cluster File System (ACFS)でスナップショット・コピーを使用したプラガブル・データベース(PDB)のクローニングに失敗します。
回避策: ありません。
Standard Editionのマルチテナント・コンテナ・データベースで、Database Configuration Assistant (DBCA)のRMANオプションを使用したPDBの切断が、次のエラーで失敗します。
Error while while creating backup piece
回避策: PDBアーカイブ(TAR形式)オプションを使用するか、SQL*Plusを使用して手動でPDBを切断します。
CURSOR_SHARING=FORCEパラメータが設定され、PDBがCDBと互換性のないキャラクタ・セットで接続されているCDBで、PDBを開こうとすると、ORA-41400エラーで失敗し、PDBが暗黙的に再び閉じられます。互換性のないキャラクタ・セット違反がPDB_PLUG_IN_VIOLATIONSビューに記録されます。
回避策: ありません。
DCBAからOracleに割り当てられたデフォルトのメモリーは、RAM合計の40%です。これは、多数のプラガブル・データベース(PDB)を持つマルチテナント・コンテナ・データベース(CDB)を作成する場合には不十分です。デフォルトのメモリー・パラメータでは、PDBの作成中にORA-4031エラーが発生する可能性があります。
回避策: CDBの作成にDBCAを使用する際に、システム・グローバル領域(SGA)ターゲットをより大きな値に変更します。デフォルトのSGAの値24MGのPDB数倍に増やすことをお薦めします。ワークロードによっては、もっと大きな値が必要になる可能性があります。
PDBのPoint-in-Timeリカバリを越えてCDBをフラッシュバックすると、一時ファイルが削除される場合があります。
回避策: 一時ファイルを再作成します。
デフォルトのパラメータを使用して252のPDBを持つCDBを作成すると、ORA-00020エラーが返されます。
回避策: CDBの作成にDBCAを使用する際に、プロセス番号をより大きな値に変更します。
PDBごとのセッション数または制限は、リスナーには送信されません。このため、別のインスタンスのPDBが限度に達していないかぎり、リスナーはPDBが限度に達しているインスタンスに接続を送ることができます。
これが問題になるのは、PDBがセッション制限に達している場合のみです。そうでない場合、この不具合による影響はありません。
回避策: PDBごとのセッション制限を使用しないでください。
Oracle Database 12cでは、DBCAを使用したCDBの作成時に、スタンドアロンのOracle Label Security (OLS)とOracle Database 12c CDB用のOLS-OID (Oracle Label Security-Oracle Internet Directory)構成のどちらかを選択する必要があります。OLS-OID構成はOLS-OIDオプションを選択することで選択できるのに対し、Label Securityの構成は「カスタム・インストール」オプションで選択します。一度選択すると、CDBの存続中はオプションを変更できません。
また、OLSを有効化したスタンドアロンのPDBをOLS-OIDが有効なCDBに接続、またはその逆もしないでください。そうしてしまった場合、警告がPDB_PLUG_IN_VIOLATIONSビューに記録されます。非互換性は、rdbms/admin/catolsrecomp.sqlを実行すれば解決できます。
回避策: PDB_PLUG_IN_VIOLATIONSビューの警告を削除するには、『Oracle Database管理者ガイド』を参照してください。
オフライン表領域のあるPDBをCDBに接続すると、接続後に表領域をオンラインにできません。現在、警告は接続時にこの制限を示すために表示されます。
回避策: PDBの接続前に、オフラインの表領域がないことを確認してください。オフラインの表領域がある場合は、接続前に必ずそれらをオンラインにしてください。
定義者の権限のプロシージャでALTER SESSION SET CONTAINER文を使用すると、一部のセッション状態が正しく設定されないことがあります。
回避策: DBMS_SQLパッケージを使用して、特定のコンテナでSQL文を実行するか、定義者の権限のプロシージャ外でALTER SESSION SET CONTAINER文を実行します。
プライマリ・データベースがCDBで、制御ファイルを再作成したためにすべてのデータ・ファイル名が含まれなくなると、クラッシュするか、スタンバイ・データベースのリカバリ・プロセスが中断されます。
回避策: 次の手順をプライマリ・データベースで実行してください。
プライマリ・データベースを停止します。
制御ファイルを削除します。
データベースをマウントせずにプライマリ・データベースを起動します。
不足しているデータ・ファイルが含まれる制御ファイルを再作成します。
プライマリ・データベースでなくなっているファイルのためにデータベース・リカバリを実行し、データベースおよびPDBを開きます。
次に、スタンバイ・データベースで次の手順を続行します。
スタンバイ・データベースを停止します。
プライマリ・データベースで、新規のスタンバイ制御ファイルを作成します。
前のスタンバイ制御ファイルを、新しく作成したスタンバイ制御ファイルで置換します。
スタンバイ・データベースをマウントします。
スタンバイREDOログを作成します。
スタンバイ・データベースとそのすべてのPDBを開きます。
管理対象のリカバリ・プロセス(MRP)を開始します。
この項では、Oracle Database Configuration Assistant (DBCA)に関する既知の不具合について説明します。
DBCAを使用してデータファイルを含むテンプレートでデータベースを作成する際、MAX_STRING_SIZE初期化パラメータを変更すると、次のエラーでデータベースの作成が失敗します。
ORA-14694: database must in UPGRADE mode to begin MAX_STRING_SIZE migration
回避策: DBCAの実行中に、MAX_STRING_SIZE初期化パラメータをデフォルト(STANDARD)に設定したまま、またはテンプレートに設定されている値のままにします。MAX_STRING_SIZE=EXTENDEDでデータベースを作成する必要がある場合は、DBCAのカスタム・データベース・テンプレートを使用します。マルチテナント・コンテナ・データベース(CDB)では、MAX_STRING_SIZE初期化パラメータはPDBごとのパラメータです。ルートのCDBは、パラメータに関係なく、常にSTANDARDセマンティックを使用します。CDBの作成後、必要に応じて、PDBのMAX_STRING_SIZE初期化パラメータを変更できます。
この項では、削除ツールに関する既知の不具合について説明します。
この項では、Java Database Connectivity (JDBC)に関する既知の不具合について説明します。
Java Database Connectivity (JDBC)でOracle Application Expressアプリケーション移行(Application Migration)を使用している場合、標準パラメータ・マーカー(?)は":<n>"形式のOracleスタイルに変換されます。つまり、変換のために問合せがサーバーに移動する前に、連続する"?"が":1"、":2"などに変換されます。しかし、既存の不具合により(Oracle Bug#16182805も参照)、変換は確実には行われず、マーカーは" :b<n> "形式に変換されるため、信頼できない動作が引き起こされます。この不適切な形式により、問合せの変換中に一貫性のない動作が引き起こされる可能性があります。この一貫性のない動作は、『Oracle Database移行ガイド』に記載されています。
回避策: この不正確に記載された動作は、将来のリリースで修正されます。Oracle Database 12cで発生しているパラメータでの変換は偶然であり、一貫性はありません。
Java Database Connectivity (JDBC)ドライバでOracle Application Expressアプリケーション移行(Application Migration)を使用している場合、バインドが適切に変換されません。これにより、Oracle Sybase TranslatorはJDBCプログラムでバインド変数を使用できず、影響を受けます。影響を受けるのは、Oracle Sybase Translatorだけではありません。バインドに依拠するすべてのトランスレータが影響を受ける可能性があります。
回避策: ありません。
JSBC仕様4.1に準拠するために、ローカル・トランザクション処理にいくつかの変更が加えられました。setAutoCommit(true)がコールされ、ローカル・トランザクションが存在する場合、そのトランザクションは自動的にコミットされます(旧リリースでは、処理は行われませんでした)。AUTOCOMMITモードのときにコミットまたはロールバックがコールされると、ドライバでは例外がスローされます(ここでも、旧リリースでは処理が行われませんでした)。ご使用のアプリケーションにこれらの状況が発生する可能性があり、すぐにそのソフトウェアを変更することが難しい場合があります。
回避策: -Doracle.jdbc.autoCommitSpecCompliant=falseシステム・プロパティをコマンドラインに追加することで、アクションのない古い動作が保存されます。
Oracle WebLogic Server (WLS) Active GridLink 10.3.6または12.1.1を新しいOracle Database 12cリリース1 (12.1)ドライバとともに使用するには、互換性のために-Doracle.ucp.PreWLS1212Compatible=trueシステム・プロパティを指定する必要があります。
回避策: ありません。
この項では、Oracle Automatic Storage Management (Oracle ASM)に関する既知の不具合について説明します。
Oracle Grid Infrastructureを10.2.x.xからOracle Database 12cリリース1 (12.1)にアップグレードする際、10.2.x.x Oracle ASMホームの所有者が12.1 Oracle Grid Infrastructureホームの所有者と異なる場合、アップグレードは失敗します。
回避策: 次の手順を実行します。
失敗後、Oracle Universal Installer (OUI)を終了します。
Oracle Grid Infrastructureユーザーとして、ORACLE_BASE環境変数を12.1 Oracle Grid InfrastructureホームのOracleベースに設定します。
次のコマンドを実行して、Oracle ASMのアップグレードを終了します。
GRIDHOME/bin/asmca -silent -upgradeASM
Oracle ASM Dynamic Volume Manager (Oracle ADVM)ボリュームが使用されるOracle Flex ASMモードで使用するためにディスク・グループを作成する場合、COMPATIBLE.ASMを12.1.0.1.0ではなく、12.1または12.1.0.0.0に設定する必要があります。ディスク・グループの作成中にCOMPATIBLE.ASMが12.1.0.1.0に設定されていると、Oracle ADVMボリュームをOracle Flex ASMモードで使用できなくなります。グループ作成後にCOMPATIBLE.ASMが12.1.0.1.0に設定されていれば、この問題はありません。
回避策: COMPATIBLE.ASMを12.1または12.1.0.0.0のいずれかに設定します。
Oracle Flex ASMクラスタのインストール後、または従来のOracle ASMクラスタからOracle Flex ASMクラスタへの変換プロセスの完了時に、Oracle ADVMボリュームを有効化すると、Cluster Ready Services (CRS)スタックがOracle Flex ASMモードで起動したときにタイムアウトとなり、次のエラー・メッセージがコンソールに表示されます。
CRS-5000: Expected resource ora.C3DBFRA.dg does not exist in agent process. For details refer to "(:CLSN00107:)" in "/TB/12.1.0/grid/log/hi07-3d/agent/crsd/orarootagent_root/orarootagent_root.log".
回避策: この状態は無害で、無視してもかまいません。ボリュームの有効化は数分内に成功させる必要があり、CRSボリューム・リソースはONLINE状態に遷移します。
Oracle Database 12cから、Oracle ASMのデフォルトの検出文字列がLinuxでは/dev/sd*に変わりました。
回避策: /dev/raw/*ディスクを続けて使用するには、システムに適した検索文字列を明示的に設定します。
Cluster Ready Services(CRS)がすべてのノードで停止されると、Oracle Automatic Storage Management (Oracle ASM)はローリング移行状態を失います。
回避策: リリース11.2.0.2のノードと、リリース12.1.0.1にアップグレードしたノードによる、4ノード(node1、node2、node3およびnode4)のシナリオで考えてみます。
node1とnode2を12.1.0.1にアップグレードして実行中。
node3とnode4は11.2.0.2のままで実行中。
停電によってすべてのCRSスタックがダウンし、クラスタが異種混在状態になったとします(つまり、11.2.0.2の2ノードと12.1.0.1の2ノード)。
アップグレードを進めるには、11.2.0.2のノード(node3、node4、または両方)のみを起動し、12.1.0.1のノードを起動する前に、Oracle ASMインスタンス上でnode3とnode4に対して次のコマンドを実行する必要があります。
ALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.1'
この時点から、説明どおりにアップグレード手順を続行します。
なお、前述の手順を実行してOracle ASMクラスタをローリング移行に戻すまでは、クラスタ内でバージョンの異なる2つのノードを起動することはできません。これを行うと、いずれかのOracle ASMバージョンが失敗し、ORA-15153またはORA-15163エラー・メッセージが返されます。
権限エラーを避けるために、Oracle ASM上でデータベースを手動で作成している場合は、asmgidwrapスクリプトをコールする必要があります。
回避策: ロール分離インストール(グリッドおよびRDBMSに異なるユーザーとグループがあります)の場合、DBCAを使用して、Oracle ASM上でのデータベース作成時に自動的にasmgidwrapスクリプトをコールするデータベースを作成します。データベースを手動で作成することを選択した場合、権限エラーを避けるために正しいグループを設定できるように、スクリプトを明示的にコールする必要があります。
この項では、Oracle ASM Dynamic Volume Manager (Oracle ADVM)に関する既知の不具合について説明します。
この項では、Oracle ASM Cluster File System (Oracle ACFS)に関する既知の不具合について説明します。
非アクティブなボリュームによって、Oracle Grid Infrastructureのアップグレードの完了が阻止されることがあります。
回避策: Oracle Universal Installer (OUI)によりグリッドのアップグレード中のエラーがレポートされた場合は、次の手順を実行します。
crsctl stat res -t -w "TYPE == ora.acfs.typeおよびcrsctl stop res <resource name> -fを使用して、すべてのOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)ファイル・システム・リソースが停止されていることを確認します。
SQLを使用してすべてのボリュームが有効化されていることを確認するか、ASMCAを使用して有効化します。
crs\config\gridconfig.batスクリプトを再実行します。
OUIでアップグレードを続行します。
11.2.x.xからOracle Database 12cリリース1 (12.1)にアップグレードする際、最初にOracle ACFSリソースを停止しないと、rootupgradeスクリプトがノード上の11.2 Cluster Ready Services (CRS)スタックの停止に失敗することがあります。
回避策: いずれかの11.2.x.xノードを再起動して、rootupgradeスクリプトを再実行します。
Oracle Database 11gからOracle Database 12cへのアップグレード時に、Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)のレジストリCRSリソースが、登録済の各Oracle ACFSファイル・システムに対応する個々のCRS Oracle ACFSファイル・システム・リソースに置換されます。
このプロセスの一部として、Oracle ACFSレジストリに、アップグレード中にすでに存在しないかオフラインになっているOracle ASM動的ボリューム・マネージャ(Oracle ADVM)のボリュームがあると、変換中にエラーが発生します。次に例を示します。
PRCA-1089 : Unable to retrieve volume and disk group for volume device path <path>
回避策: この状況は、acfsutil registry -dコマンドを使用して、Oracle ACFCレジストリから無効になったボリュームおよびマウント・ポイントを削除することで回避できます。
または、アップグレード・プロセスの一部としてボリュームを有効にできない場合、アップグレードには成功しますが、オフラインのボリュームに関連付けられているOracle ACFSファイル・システムは、手動でCRSネームスペースに再度追加することが必要になります。これは、次の手順で実行できます。
SQL、Oracle ASMコンフィギュレーション・アシスタント(ASMCA)、またはsrvctl start volumeコマンドを使用して、ボリュームを有効化します。
acfsutil registry -aコマンドまたはsrvctl add filesystemコマンドを使用して、Oracle ACFSファイル・システムをCRSネームスペースに再び追加します。
特定のノードでOracle ACFSプラグインを初めて有効化するとき、acfsutil plugin enableコマンドが次のエラーで失敗する可能性があります。
ACFS-3613: Unable to write plug-in config file.
回避策: Oracle ACFSルート・ディレクトリのコンテンツをリストしてから、acfsutil plugin enableコマンドを再発行します。
ボリュームの削除が対応するボリューム・リソースの削除をトリガーしないという、透過的高可用性の障害というまれなケースで、リソースを次のコマンドを使用して削除できます。
srvctl remove volume
回避策: リソースを削除します。
このリリースでは、グリッド・ホーム・クラスタの高可用性NFS(HANFS)機能でIPv6アドレスがサポートされていません。
回避策: IPv4アドレスにのみ解決される名前を使用して、高可用性仮想インターネット・プロトコル(HAVIP)を構成します。
acfsutil registryを使用して登録済のファイル・システムを変更する際に、そのファイル・システムに依存するエクスポートまたはデータベースが存在しても、ファイル・システムが変更されます。たとえば、ファイル・システムをクラスタ全体のシステムから"ノード・ローカル"ファイル・システムに変更した場合、サポートされていない構成になる可能性があります。
回避策: ありません。
パスワードで保護されたキー・ストアを持つクラスタで、暗号化を使用するOracle ACFSファイル・システムがOracle ACFSマウント・レジストリを使用してマウントされる際、管理者にキー・ストア・パスワードの入力を求めるプロンプトが表示されません。ファイル・システムのマウント・プロセスは成功しますが、Oracle ACFSの暗号化が正常に機能するために必要な一部の情報を、ファイル・システムで利用できません。この場合、このファイル・システムで暗号化が機能せず、ファイル・システム内の暗号化されたファイルの読取りまたは書込みを行うことができません。
回避策: パスワードで保護されたキー・ストアを持つクラスタでは、暗号化を使用するファイル・システムのマウントに、Oracle ACFSマウント・レジストリを使用しないでください。一部のファイル・システムがすでにOracle ACFSマウント・レジストリを使用してマウントされている場合は、アンマウントし、これらのファイル・システムをマウント・レジストリから削除して、暗号化されたデータが将来利用できなくなることを防ぎます。その後、リクエストされたら正しいパスワードを入力して、Oracle ACFSマウント・レジストリを使用せずにこれらのファイル・システムを再マウントします。または、暗号化されたファイル・システムで引き続きマウント・レジストリを使用する場合は、acfsutil keystore migrateコマンドを使用し、ファイル・システムのマウント時にパスワードが不要なタイプに暗号化キーストアを移行します。
この項では、Oracle Database Quality of Service (QoS) Managementに関する既知の不具合について説明します。
リソース・マネージャでは、CDBまたはPDBのデータベース・デプロイメントに対するCPUリソースの管理方法が、Oracle Database QoS Management 11.2のプランやモデルと互換性のない方法に変更されました。これらの変更により、2つのプランと、関連するワークロード検証を使用した異なるリソース・モデリングが必要になりました。これらのモデルは、本番用のリソース・マネージャ・コードで開発、テスト、および調整される必要があります。そのため、この初期リリースでは、Oracle Database QoS ManagementはCDBやPDBのデータベース・デプロイメントを測定および監視することしかできず、パフォーマンス目標を満たしていないCDBやPDBのパフォーマンス・クラスを支援するために、推奨を生成することはできません。
回避策: ありません。
この不具合は、Oracle Database QoS Managementによって管理されるCPUリソースの推奨事項に対するものです。サーバー上のすべてのインスタンスに対して構成されているCPUの数が、そのサーバーの物理CPUの数より少ない場合、割り当てられていない(空いている)CPUがOracle Database QoS Managementによって検出されず、構成されているCPUの数を増やすことを薦める推奨が行われません。データベースをホストしているスライスだけが、ターゲット・スライスに対するドナーとして考慮されます。割り当てられていないいずれかのCPUの追加が、最高ランクのCPU移動アクションである必要があります。
回避策: 各サーバーで各データベース・インスタンスに対して構成されているCPU数の合計が、物理的なCPUの数と同じであることを確認します。
この不具合は、クラスタ状態モニター(CHM)をサポートしているプラットフォームに当てはまります。Oracle Clusterware管理のデータベース・サービスが停止しているものの無効の状態ではない場合、そのサービスのホストであるサーバーのメモリーが過大割当ての状態であると検出されなければ、サービスはOracle Database QoS Managementにより起動されます。メモリーが過大割当てされている場合は、有効なサービスはすべて、たとえ手動で起動されていても停止されます。メモリーの過剰割当て状態(赤)からせ正常な状態(緑)に遷移するサービスのみを起動するというのが、望ましい動作です。サーバーが赤の状態にあるときに、サービスが手動で起動される場合、そのサービスは停止しないでください。
回避策: Oracle Enterprise Managerコンソールから、停止状態のままにするサービスを停止して無効にするか、Oracle Database QoS Managementを無効にします。
この項では、Oracle Clusterwareに関する既知の不具合について説明します。
Oracle Grid InfrastructureをOracle Database 11gリリース2 (11.2.0.4)からOracle Database 12cリリース1 (12.1)にアップグレードしようとすると、Oracle ACFSまたはOracle ADVMリソースを停止できないことが原因で、アップグレードが失敗します。
回避策: SRVCTLまたはCRSCTLを使用してリソースを手動で停止し、アップグレードを再試行します。
11.2より前のデータベース設定を持つOracle Flex ASMクラスタ構成で、Oracle Cluster Synchronization Services (CSS)プライベート・ネットワークおよびOracle ASMネットワークが同じネットワークに分類されている場合、11.2より前のデータベースのCLUSTER_INTERCONNECTS初期化パラメータでプライベート・ネットワークではなくパブリック・ネットワークが使用されます。
回避策: クラスタ・インターコネクトとOracle ASMに異なるネットワークを選択します。
すべてのプライベート・ネットワークで障害が発生した後、Oracle Cluster Synchronization Service (CSS)またはOracle ASMインスタンスがクラスタに再度参加できません。
前提条件として、障害が発生したノードで少なくとも1つのプライベート・ネットワークがリストアされていることを確認します。
クラスタの状態を確認します。次のコマンドを使用して、インスタンスがクラスタに再度参加できないかどうかを確認できます。
crsctl stat res ora.cssd -init crsctl stat res ora.asm -init crsctl check cluster -all
回避策: 再度参加するノードを再起動します。ノードを再起動できない場合は、次の手順を実行できます。
次のコマンドを使用して、クラスタに再度参加できないノードでクラスタウェアを停止します。
crsctl stop crs –f
Highly Available IP Address(HAIP)がシステム上で使用されている場合、残っているHAIPを停止します。HAIPアドレスは、デフォルトでは169.254.0.0サブネットにあります。オペレーティング・システム固有のコマンドを使用して、インタフェースを停止します。たとえば、Linuxの場合:
ifconfig eth0:1 down
Solarisの場合:
ifconfig net2:1 unplumb
AIXの場合:
ifconfig en4 169.254.180.68 delete
ノードがクラスタへの参加に失敗したことに気付いた時点から、少なくとも10分が経過したことを確認します。次のコマンドを使用して、クラスタウェアを再起動します。
crsctl start crs
それでもノードがクラスタに再度参加できない場合は、ノードを再起動します。
多数のサービスのある11.2 Oracle ClusterwareをOracle Database 12cリリース1 (12.1)にアップグレードする場合、最後のクラスタ・ノードで実行されているrootupgrade.shスクリプトが中断されます。アップグレード時にora.crsdの起動は初期化されましたが完了に失敗したためです。
回避策: 最後のノードでrootupgrade.shスクリプトを再実行します。
1,000を超えるデータベース・サービスが登録されている場合に、11.2.x.xからOracle Database 12cにアップグレードすると、サーバー管理(SRVM)モデルのアップグレード時に、最初のノードでルート・スクリプトが失敗します。この問題により、1,000を超えるデータベース・サービスが登録されている場合に、11.2.x.xからOracle Database 12cへのCluster Ready Services (CRS)のアップグレードが完了しないことがあります。
回避策: 11.2ホームにパッチを適用して修正されたバージョンにするか、データベース・サービス・リソースを削除し、アップグレードを完了して、データベース・サービス・リソースを再登録します。
/usr/sbin/ping6にsetuidが設定されていない場合、Oracle Universal InstallerがINS-41112エラーを戻します。
回避策: 次のコマンドをrootとして実行し、setuidを設定してインストーラを再実行します。
chmod +s /usr/sbin/ping6
Oracle Restart環境では、Oracle ClusterwareスタックによりOracle ASMインスタンスへの接続が毎秒生成され、その結果Grid_Home/rdbms/auditに多くの監査ファイルが生成され、時間の経過とともにディスクが一杯になってしまうことがあります。
回避策: 次のコマンドを実行すると、これらの監査ファイルの生成がただちに停止されます。
/u01/app/oracle/product/12.1.0/grid/bin/crsctl modify resource ora.asm -attr START_DEPENDENCIES="hard(ora.cssd)"
投票ファイルが5つ以上ある環境で、ノードが突然停止された場合、Oracle Cluster Synchronization Services (CSS)デーモンは最後のディスク・ハートビートを、そのノードの投票ファイルのサブセットにのみ書き込むことができます。これにより、ノードの2つの投票ファイルの、ディスク・ハートビートのタイムスタンプが異なるという状況が発生します。この状況で、クラスタ全体を停止して、別のノード(突然停止されたノード以外のノード)をEXCLUSIVE MODEで起動しようとすると、突然停止されたノードが起動していると間違って認識され、EXCLUSIVE MODEでの起動に失敗することがあります。
回避策: 次の手順を使用して、この問題からリカバリします。
すべての投票ファイルを物理的に削除するか、オフラインにします。
スタックをEXCLUSIVE MODEで起動します。
crsctl delete css votediskコマンドを使用して、すべての投票ファイルを構成から削除します。
crsctl add css votediskコマンドを使用して、新しい投票ファイルを追加します。
これで、スタックをOracle Flex Clusterモードで起動できます。
新たにインストールした12.1 Oracle Grid Infrastructureでの、11.2ベースのデータベースの作成に失敗します。
12.1より前のリリースから12.1にアップグレードしたOracle Grid Infrastructureでは、11.2ベースのデータベースの実行に関する問題は発生しません。
回避策: ありません。
Oracle Clusterwareのリリース12.1へのアップグレード後に、リリース10.2およびリリース11.1のOracle RACデータベースのOracleリソースが正常に動作しない場合があります。
回避策: Oracle Clusterware 12gリリース1 (12.1)をインストールした後に、Oracleサポート・サービスに連絡して、次の不具合のパッチを入手してください。
8373758: TB-CMP: 11107 SERVICE CAN'T BE BROUGHT UP BY 11107 SRVCTL WHEN WITH 11.2 CRS
8441769: TB_UD: INCORRECT SERVICE INFO REGISTER TO DB, UPGRADE CRS_HOME 11.1.0.7 -> 11.2
8406545 - TB-CMP: RESTART OF 11.2 HAS STACK FAILED TO BRING UP 11.1 ORACLE RAC INSTANCE
8262786: TB-CMP: FAIL TO START 11106 DB INSTANCE WITH 11.2 CRS
|
注意: パッチはOracle Databaseホームに適用してください。 |
Oracle Real Application Clusters (Oracle RAC)のマルチテナント・コンテナ・データベース(CDB)のインスタンスを開くときに、ハングすることがあります。これは、プラガブル・データベース(PDB)がすべてのインスタンスで一律に開かれていないためです。
CDBのPDB1が、Instance 1では開かれているがInstance 2では開かれていないとします。また、Instance 2で生成された配信不能トランザクションが、過去のいずれかの時期にPDB1を変更したとします。PDB1はInstance 1で開かれているため、その配信不能トランザクションによってすでに変更されたデータを、プロセスで変更することができます。しかし、UNDOセグメントはInstance 2に属するため、Instance 1は配信不能トランザクションをリカバリできません。PDB1はInstance 2では閉じられているため、この配信不能トランザクションはInstance 2でもリカバリできません。このため、ハングが引き起こされます。
回避策: 開かれているすべてのインスタンスで、PDB1を起動します。
Linuxプラットフォーム上のOracle Grid Infrastructureリリース12.1で、Oracle ASMのデフォルトの検出文字列が/dev/raw/raw*から/dev/sd*に変更されました。Oracle ASMのデフォルトの検出文字列が、Oracle ASMによって管理されるデバイスの選択に使用されており、既存のキャラクタ・デバイスがパターン/dev/sd*によって識別されるそれぞれのブロック・デバイスにマップされない場合、これらのデバイスはOracle ASMには表示されません。この結果、アップグレード後にディスク・グループがマウントされず、アップグレードは失敗します。これらのデバイスに対するクラスタ検証ユーティリティ(CVU)前提条件チェックもスキップされます。
回避策: アップグレードする前に、次のコマンドを使用して、Oracle ASMディスク検出文字列を設定します。
ALTER SYSTEM SET ASM_DISKSTRING=<ASM_disk_discovery_string> SCOPE=SPFILE;
IPv6環境でのみ、一部のSCAN仮想IPアドレス(VIP)がグリッド・ネーミング・サービス(GNS)に登録されません。
回避策: GNSがクラスタで実行されている場合、srvctl relocate gns -node <node_name>コマンドを使用して、GNSをSCAN VIPが実行されているノードに再配置します。これにより、SCAN VIPをGNSに登録できます。その後、GNSを他のノードに再配置できます。
Oracle Grid Infrastructureスクリプト自動化機能を使用するために、Oracle Universal Installer (OUI) GUIページでsudoまたはrootユーザーを指定した場合、rootスクリプトはこの自動化機能を使用して実行されますが、次のエラーで失敗する可能性があります。
Exception in thread "main" java.lang.NullPointerException
これは、/etc/resolve.confファイルで定義されている名前付きサーバーの1つを介してIPv6アドレスを解決できないために起こります。
回避策: /etc/resolve.confファイルを開き、このファイルで定義されている名前付きサーバーのすべてを収集します。通常、次のものが定義されています。
nameserver x1.y1.z1.k1 nameserver x2.y2.z2.k2 nameserver x3.y3.z3.k3
名前付きサーバーごとに、次のコマンドを実行して、IPアドレスが解決されるかどうかを確認します。
nslookup -querytype=AAAA <IPv6_address> <named_server>
次のようなエラー・メッセージが表示された場合、特定の名前付きサーバーがIPv6アドレスを解決できないことを意味します。
;; connection timed out; trying next origin
IPv6アドレスを解決できない名前付きサーバーを削除するかコメントする必要があります。
グリッド・ネーミング・サービス(GNS)が有効になっている構成で、クライアントがSCAN名を使用してデータベースに接続できません。これは、データベースのSCAN値のREMOTE_LISTENER名が、ドメイン修飾されていないためです。
回避策: SQL*Plusを使用して、REMOTE_LISTENERをドメイン修飾されたSCAN名に手動で変更します。次に例を示します。
SQL> ALTER SYSTEM SET REMOTE_LISTENER ='myscan.mycluster.example.com:1521' SCOPE=BOTH;
Oracle Grid Infrastructureを12.1にアップグレードする場合、次のエラー・メッセージが出力ストリームに表示される可能性があります。
PRCR-1154 : Failed to create file output stream with file name: GI Home/cfgtoollogs/crsconfig/srvmcfg0.log
回避策: ありません。このエラー・メッセージは無視してかまいません。この警告に関係なく、アップグレードは完了します。
Oracle Grid Infrastructureを11.2.0.3から12.1にアップグレードした後、11.2.0.3データベース(管理者が管理)は起動しません。
回避策: アップグレードの終了後、crsctl stop crsの後に crsctl start crsを実行することにより、Cluster Ready Services (CRS)をバウンスします。
SCANリスナーは、同じクラスタ内のノードからのサービス登録を拒否します。拒否はSCANリスナー・ログ・ファイルに記録されます。
回避策:srvctl modify scan_listener -update -invitednodesまたはsrvctl modify scan_listener -update -invitedsubnetsを使用して、サービス登録のためにSCANリスナーで受け入れられるノードまたはサブネット情報を指定します。
11.1 CRSから12c Oracle Grid Infrastructureへクラスタに対してアップグレードするときと、Oracle ASMコンフィギュレーション・アシスタント(ASMCA)がOracle ASMをアップグレードした後、一部のデータベース・インスタンスが起動しない可能性があります。この問題は、Oracle Universal Installerではエラーまたは警告として反映されません。
回避策: データベース・インスタンスの状態を検出するために、アップグレード後に手動でデータベース・インスタンスをチェックします。次に例を示します。
srvctl status database -db <db_name>
それから、手動でデータベース・インスタンスを起動します。次に例を示します。
srvctl start database -db <db_name>
純粋なIPv6環境でGNS仮想IPアドレス(VIP)がIPv4およびIPv6アドレスに解決される場合、cluvfyコマンドの実行中に、グリッド・ネーミング・サービス(GNS)の整合性チェックが失敗します。
回避策: GNS VIPのIPv6アドレスを問い合せます。問合せに成功した場合、GNS整合性チェックは無視できます。
グリッド・インフラストラクチャ管理リポジトリ(GIMR)のセキュリティ・ポリシーでは、ユーザーのパスワードを180日ごとに変更する必要があります。このリリースでは、GIMRクライアントによりこの機能が実行されず、したがってOLOGGERDとOCLUMONにより接続例外が記録されます。
回避策: CRS管理者は、GIMRが実行されているノードから(手動またはそれ以外の方法で) GRID_HOME/bin/mgmtcaコマンドを実行する必要があります。そのノードは、GRID_HOME/bin/srvctl status mgmtdbコマンドを実行することで見つかります。
最初のクラスタ・ノードでインストール・スクリプトを中断または停止すると、最初のノードでスクリプトが再び実行されるか、その後別のクラスタ・ノードで実行されるとき、次のエラーが発生する可能性があります。
CLSRSC-46: Error: '$ORA_CRS_HOME/gpnp/wallets/pa/cwallet.sso' does not exist CLSRSC-153: Could not set permissions on '$ORA_CRS_HOME/gpnp/wallets/pa/cwallet.sso' CLSRSC-148: Errors occurred while setting GPnP wallets ownership/permissions
これらのエラーは、後続の実行で既存の構成が再検証されるときに検出されない重要でないファイルが見つからないことで発生します。
回避策: これらのエラーは、安全に無視でき、スクリプトはそのまま実行され、製品のインストールには影響がありません。
ただし、クリーンな実行が必要な場合、最初のノードでスクリプトを再起動する前に、すべてのクラスタ・ノードの次のディレクトリでファイルを削除します。
rm $ORA_CRS_HOME/gpnp/profiles/peer/* rm $ORA_CRS_HOME/gpnp/wallets/peer/*
複数のクラスタで共有ファイル・システム上の同じディレクトリを使用して、Oracle Cluster Registry (OCR)と投票ディスクを配置するとき、mgmtdbによるインストールとアップグレードは失敗します。
回避策: OCR用に別の記憶域の場所を使用するか、1つを除くすべてのクラスタに対してmgmtdbオプションが無効化されていることを確認します。
強制アップグレード後にノードがクラスタに加わる際、データベース・インスタンスとサービスが自動的に起動しません。
回避策: データベース・ホームにあるSRVCTLを使用して、このノードでデータベース・インスタンスとサービスを手動で起動します。
中国語の環境(つまり、zh_CN.utf8またはzh_TW.utf8以外のロケール)では、Oracle Grid Infrastructureのインストール中に、"Use "root" user credential"オプションを有効にすると、GUIがハングし、INS-32128エラーが返されます。
回避策: この不具合には2つの回避策があります。
回避策1: ロケールをzh_CN.utf8またはzh_TW.utf8に設定します。
回避策2: このオプションを有効化しないでください。手動でroot.shを実行します。
Oracle Grid Infrastructureがリリース12.1にアップグレードされた後、11.2より前のリリースのサービス・リソースがOFFLINEになることがあります。
回避策: srvctl start service -d <dbname> -s <srvname> -i <instname>を使用して、OFFLINEサービス・リソースを手動で起動します。
まれに、Oracle Clusterwareを11.1.0.7.7から12.1にアップグレードする際、rootupgrade.shの実行中に、ノードの再起動の問題が発生する場合があり、これは次の状況でのみ起こります。
11.1.0.7.0リリースがクラスタにインストールされ、パッチ7483779が適用される(Oracle Bug#7374972のBLR修正)前に、クラスタウェアがノードで起動されました。
パッチ7483779の適用以来、クラスタウェアの完全再起動が行われていません。クラスタウェアの完全再起動とは、クラスタ内のすべてのノードで停止した後のクラスタウェアを起動することです。
初期インストールが11.1.0.7.1 (つまり、11.1.0.7 CRSバンドル1以上)だった場合、パッチ7374972は初期インストールに含まれており、この問題は見られません。
回避策: 12.1へのアップグレード前に、すべてのノードでクラスタウェアの完全再起動を実行してください。
この項では、Oracle Database Enterprise Editionに関する既知の不具合について説明します。
データベース・ディレクトリ名に、エラー・メッセージの接頭辞コード(TNS、ORAなど)が含めないでください。Oracle Enterprise Managerでのトラブルの原因となります。
回避策: ありません。
Oracle OLAPオプションは、Oracle Database Enterprise Editionでのみ使用できます。Oracle Database Standard Edition (SE)でOracle OLAPを使用しようとすると、エラーが発生します。たとえば、SEでOracle OLAPを使用してエクスポートを実行しようとすると、次のエラーが表示されます。
EXP-00008: ORACLE error 29280 encountered ORA-29280: invalid directory path ORA-06512: at "SYS.UTL_FILE", line 41 ORA-06512: at "SYS.UTL_FILE", line 478 ORA-06512: at "SYS.DBMS_AW_EXP", line 89 ORA-06512: at "SYS.DBMS_AW_EXP", line 1177 ORA-06512: at line 1 EXP-00085: The previous problem occurred when calling SYS.DBMS_AW_EXP.instance_extended_info_exp for object 85676
回避策: Oracle OLAPは、Oracle Database Enterprise Editionで使用してください。
プラガブル・データベース(PDB)のメンテナンス操作では、PARALLEL_MAX_SERVERS初期化パラメータの設定にかかわらず、各インスタンスで操作を実行するために、パラレル・タスクがすべてのアクティブ・インスタンスに割り当てられる必要があります。インスタンスでPARALLEL_MAX_SERVERS=0に設定されている場合、パラレル・タスクがそのインスタンスに割り当てられず、そこで操作は実行されません。
回避策: PARALLEL_MAX_SERVERS初期化パラメータの値を0に設定しないでください。PARALLEL_MAX_SERVERS初期化パラメータを何も設定しなければ十分です。
デフォルト値のNull値可能列を追加し、後からOracle Database 12cリリース1 (12.1)環境でデフォルト値を設定解除すると、データ・ディクショナリにはデフォルト値のNULLへの変更が反映されるにもかかわらず、デフォルト値が設定解除(NULLに戻る)されません。影響を受ける文は、ALTER TABLE x ADD (y NUMBER DEFAULT 99)およびそれに続くALTER TABLE x MODIFY (y DEFAULT NULL)で、yはNull値可能列です。
回避策: デフォルト値の設定解除と同じセマンティック結果になるALTER TABLE x MODIFY (y DEFAULT TRIM(''))文を使用して、デフォルト値を設定解除します。
Oracle RACデータベース・ファイルがネットワーク・ファイル記憶域(NFS)またはOracle Cluster File System 2 (OCFS2)にある場合、FILESYSTEMIO_OPTIONS=DIRECTIOまたはFILESYSTEMIO_OPTIONS=SETALL初期化パラメータを設定して、データの破損を回避します。この問題は、Direct NFSには当てはまりません。将来は、パッチが利用可能になります。最新のステータスおよび利用可能なパッチについては、Oracle Bug#16865261を監視してください。
回避策: FILESYSTEMIO_OPTIONS初期化パラメータの値をDIRECTIOまたはSETALLに設定します。データベース・ファイルがNFSにあり、Direct NFSが有効になっている場合、この設定は不要です。
接頭辞が圧縮された索引の索引高速フル・スキャンが、ORA-600[6033]エラーで失敗することがあります。
回避策: 問合せを再試行するか、適切なヒントで代替アクセス・パスを実行します。
共有サーバーが有効な場合、PDBでオブジェクト・リンク・ビューの問合せがクラッシュすることがあります。オブジェクト・リンク・ビューはすべてOracleによって提供されたもので、ほとんどはDBA_HISTビューです。次のコマンドを使用して、完全なリストを検索できます。
SELECT OWNER, OBJECT_NAME FROM ALL_OBJECTS WHERE SHARING='OBJECT LINK' AND OBJECT_TYPE='VIEW'
回避策: これらのビューを問い合せる際は、共有サーバーを無効にします。
OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータがデフォルト値の2に設定されている場合、SQLプラン・ディレクティブが使用されません。
回避策: OPTIMIZER_DYNAMIC_SAMPLING初期化パラメータに2より大きな値を設定します。
共通ユーザーが、rootの特定のOracle提供ビューを問い合せ、CONTAINER_DATA属性によって特定のコンテナのデータのみを参照するように制限されると、問合せでORA-7445エラーが発生する可能性があります。
回避策: rootに切り替え、共通ユーザーのCONTAINER_DATA属性をALLに設定します。
次のALTER USER文を実行します。
ALTER USER <common_user> SET CONTAINER_DATA=ALL CONTAINER=CURRENT;
プラガブル・データベース(PDB)サービスのOracle RAC Load Balancing (RLB)イベントが、Oracle Notification Service (ONS)イベント・ストリームにありません。これらのイベントに依拠するコードは、イベントを受け取りません。
回避策: ありません。
CONTAINERパラメータを含むDBMS_AUDIT_MGMTルーチンで、DBMS_AUDIT_MGMT.CONTAINER_ALL値が使用されている場合、次のエラーで実行が失敗します。
ORA-46273: DBMS_AUDIT_MGMT operation failed in one of the PDB
回避策: それぞれのPDBに接続後、CONTAINERパラメータにDBMS_AUDIT_MGMT.CONTAINER_CURRENT値を使用して、必要なルーチンを実行します。
12.1 Oracle Grid InfrastructureスタックをOracle Flex ASM構成とともに起動する際、11.2より前のOracleインスタンス・リソースが自動的に起動しないことがあります。
回避策: 11.2より前のOracleインスタンス・リソースを手動で起動します。
古いOracle ASMからOracle Flex ASMにクラスタを変換する際には、ユーザーによってrootとして実行されるスクリプトの出力に、次のエラー・メッセージ・シーケンスが1つ以上表示されます。
CRS-2672: Attempting to start 'ora.proxy_advm' on '<node-name>'^M CRS-5017: The resource action "ora.proxy_advm start" encountered the following error: ^M ORA-03113: end-of-file on communication channel^M Process ID: 0^M Session ID: 0 Serial number: 0^M
詳細は、<CRS-Home>/log/<node-name>/agent/crsd/oraagent_crsusr/oraagent_crsusr.logの(:CLSN00107:)を参照してください。
回避策: これらのエラーは無視してかまいません。変換が終了すると、すべてのノードでora.proxy_advmが正しくONLINE状態に変わります。
同時実行のUNION ALLは、UNION ALL文が後続のSELECT文内にある場合にのみ、適格な文に対して自動的に呼び出されます。たとえば、次のコマンドを使用すれば、すべてのブランチを同時に実行できます。
SELECT * FROM (SELECT FROM ...UNION ALL ...UNION ALL)
ただし、まったく同じUNION ALL文であっても、後続のSELECT文として実行されないものはこれに該当しません。
回避策: UNION ALLコンストラクトを後続のSELECT文として埋め込むか、次の文を使用してレガシー・コードの制約を無効にします。
ALTER SESSION SET "_fix_control"='6748058:0';
AL32UTF8データベースを使用している場合、およびSQL*Loaderがロード方法として外部表とともに使用されていて、表名に非ASCII文字が含まれている場合、SQL*Loaderがエラーなしで終了し、ターゲット・データベースにまったくデータがロードされないことがあります。これは次のいずれかで発生する可能性があります。
external_table=executeが指定されている場合の制御ファイル。
デフォルトの外部表のロード方法が使用されているか、external_table=executeコマンドライン・パラメータが強制的に使用されている場合に、エクスプレス・モードを使用しているとき。
回避策: ありません。
nprocの弱い制限が、データベースによって実行時に調整されません。その結果、その制限に達しても、データベースでは追加のプロセスを分岐できなくなるため、不安定になる可能性があります。
回避策: /etc/security/limits.conf内のnprocの弱い制限が、指定されたワークロードに対して、システム上の同時スレッドの最大数を十分に収容できる高い値に設定されていることを確認します。不確かな場合は、強い制限に設定します。次に例を示します。
oracle soft nproc 16384 oracle hard nproc 16384
Oracle Flex ASMを有効化している間、クラスタ内のすべてのノードの周期的再起動を実行するための要件があります。管理データベース・インスタンス(すなわちOracle Restartにより管理されているデータベース・インスタンス)があるノードが再起動されたとき、そのインスタンスはまだ再起動されていない別のノードに再配置される可能性があります。この場合、そのデータベース・インスタンスは、次のエラーにより起動に失敗します。
ORA-15343: Feature Flex ASM is not enabled
これは、そのデータベース・インスタンスが再起動されているノードで起動されるまで発生します。こうなれば、データベース・インスタンスは正常に動作します。
回避策: ありません。すべてのノードが再起動すれば、そのデータベース・インスタンスは正常に動作します。
PQ_CONCURRENT_UNIONヒントは現在、文レベルのヒントとしては機能しませんが、問合せブロックを明示的に指定する必要があります。たとえば、次のコマンドは機能し、UNION ALLの同時処理を行います。
SELECT /*+ PQ_CONCURRENT_UNION (@SET$1) */ ...UNION ALL ...UNION ALL ...
ただし、次のコマンドは機能しません。
SELECT /*+ PQ_CONCURRENT_UNION */ ...UNION ALL ...UNION ALL ...UNION ALL ...
問合せブロックの識別と命名の方法の詳細は、『Oracle Database SQLチューニング・ガイド』を参照してください。
回避策: 問合せブロックを明示的に指定します。
ソース・データベースとターゲット・データベースのタイム・ゾーンが異なる場合、TIMESTAMP WITH LOCAL TIME ZONEデータを含んだ表は、トランスポータブル表領域テクノロジを使用してデータベース間で移動させることができません。影響を受ける各表には、インポート時に次のエラーでフラグが立てられます。
ORA-39360, Table "<owner>"."<table name>" skipped due to transportable import and TSLTZ issues.
回避策: ターゲット・データベースをソース・データベースと同じタイム・ゾーンに変換するか、影響を受ける表を従来のデータ・ポンプ・エクスポートおよびインポートにより移動します。
Oracle INTERVALデータ型INTERVAL YEAR TO MONTHは、SQL、PL/SQL、OCI、Pro*Cなどのすべてのコンポーネントにわたり、エチオピア暦で正しく使用できません。
回避策: ありません。
索引付きパーティションに対する索引の使用や、索引付けのあるパーティションの全表スキャンの使用には、部分索引付けを最大限に活用する必要があります。Oracle Database 12cリリース1 (12.1)では現在のところ、時間隔パーティション表の表拡張(可能ならばいつでも索引を利用するために、文をUNION ALLに内部的にリライトする機能)をサポートしていません。
回避策: 手動で文をUNION ALL演算子に書き換えて、パーティションを索引付けのあるなしで分けるか、時間隔パーティション機能を無効にするかのいずれかです。
Oracle Database 12cリリース1 (12.1)から、最大256Kのサイズの一時LOBがプログラム・グローバル領域(PGA)メモリーに配置されます。これは、PGAのメモリー消費増大につながる可能性があります。一部のワークロードでは、作成される一時LOBの数によって、ORA-4030エラーに遭遇することがあります。
回避策: イベント32761, level 16を設定して、インメモリーの一時LOBをオフにします。このイベントを設定することにより、一時LOBがディスクの一時セグメントに移動します。メモリー消費量は12.1より前のレベルになってしまいますが、ユーザーにとっては、インメモリーの一時LOBにはパフォーマンス上のメリットはありません。
この項では、Oracle Database Vaultに関する既知の不具合について説明します。
Oracle Database Vaultがすでに11.2.0.4にインストールされている状態でOracle Database 11gリリース2 (11.2.0.4)からOracle Database 12cリリース1 (12.1)にアップグレードすると、アップグレード・ログに次の2つのORA-00001エラーが記録されます。
ORA-00001: unique constraint (DVSYS.CODE$_PK1) violated ORA-00001: unique constraint (DVSYS.CODE_T$_UK1) violated
また、アップグレード後のステータス・ユーティリティ(utlusts.sql)でも同じエラーが発生します。
回避策: これらのエラーは、特に害はなく、無視してかまいません。
この項では、Oracle Data Guardロジカル・スタンバイ・データベースに関する既知の不具合について説明します。
データベースを12.1より前のリリースにダウングレードすると、LogMinerバックグラウンド・プロセスでORA-54013エラーが発生する可能性があります。
回避策: 仮想列を削除するために表を変更します。DBMS_STATS.CREATE_EXTENDED_STATS()関数を使用して追加された場合、DBMS_STATS.DROP_EXTENDED_STATS()関数を使用すれば、その仮想列を削除できます。降順索引がサポートされている場合は、その降順索引を削除します。
入力済の索引構成表(IOT)でのピース単位のLOB更新は、ロジカル・スタンバイ・データベースではレプリケートされません。SQL Applyは、REDOストリーム内でこのような変更に遭遇した場合、ORA-1403を返して停止します。
回避策: ロジカル・スタンバイでDBMS_LOGSTDBY.SKIPプロシージャを使用して、表のレプリケートをスキップします。
4,000バイトを超えるバインド値を持つ抽象データ型(ADT)属性の更新には、サプリメンタル・ロギングはサポートされていません。
回避策: レプリケートが必要なADT属性を更新するには、バウンド値が4,000バイト未満の場合のみ、直接バインドを使用します(max_string_size=extendedの場合は32,767バイト)。変数をこの制限を超える値とバインドするには、LOBデータ型をバインドするか、ADT全体を更新します。
SQL Applyは、Oracle Data Guard構成がDBMS_ROLLINGパッケージにより開始された周期的変更操作中に、次のエラーによって停止する可能性があります。
ORA-00600: internal error code, arguments: [kwqicarsm: rs obj #], []
回避策: DBMS_RULE_ADMパッケージは、DBMS_ROLLINGパッケージのコンテキストではサポートされていませんから、DBMS_ROLLINGがアクティブの間は、プライマリ・データベースでOracle Advanced Queuing (AQ)サブスクライバに対するルールの作成または変更に使用しないでください。
DBMS_ROLLING.ROLLBACKを使用して、Oracle Data Guard構成での周期的変更操作をロールバックします。データベースまたはアプリケーションがDBMS_ROLLING操作中にAQサブスクライバに関連付けられたルールを追加または変更することがないと確認したら、周期的変更操作を再試行します。
SQL Applyでは、SYS.ANYDATA列を持つ表のレプリケーションはサポートされません(SYS.ANYDATA列にマルチバイト文字が含まれている場合)。
回避策: ありません。
SQL Applyは、Securefile LOB列を持つ表での次のエラーで異常終了します。
ORA-600 [curr loc with no gather] [0x2B6D75918]
回避策: DBMS_LOGSTDBY.SKIPを使用する表をスキップし、SQL Applyを再起動します。
この項では、Oracle Enterprise Managerに関する既知の不具合について説明します。
Enterprise Managerエージェントは、監視のために専用のサーバー接続を使用してCDBに接続する必要があります。
回避策: これは、Enterprise Managerエージェント接続用の接続文字列のCONNECT_DATAで(SERVER=dedicated)を設定することで構成できます。
古いバージョンのEnterprise ManagerでデータベースをOracle Database 12gリリース1 (12.1)にアップグレード後、Enterprise ManagerでOracleホームが更新されません。
回避策: データベースの作成または削除時のターゲット・アップグレードOOBをサポートするように、データベース・プラグイン12.1.0.3.0以上とともにEnterprise Managerを12cPS1以上にアップグレードします。また、データベースおよびリスナー・ターゲットの監視プロパティ(Oracle_home)を編集して、ターゲット・プロパティを手動でアップグレードまたは変更し、Oracleホームの値を古いデータベース・ホームから新しい12.1データベース・ホームに変更します。
この項では、Oracle OLAPに関する既知の不具合について説明します。
インストール・キットで提供されているシードを使用してデータベースがインストールされていて、OLAPオプションが選択されていない場合、インストールの終了時またはしばらくしてから、OLAP Analytic WorkspaceおよびOLAP APIコンポーネントが無効と報告されます。
エラー・メッセージを除くと、これによるインスタンスの実行への影響は何もありません。
回避策: 次のいずれかを行います。
エラーを無視します。
OLAP (または問題のあるオプション)を有効にします。
OLAPを含まない独自のシード・データベースを作成して使用します。
この項では、Oracle Real Application Clusters (Oracle RAC)に関する既知の不具合について説明します。
11.2.x.xから12.1.0.1にアップグレードする際、カスタマイズされたリスナー構成が設定されている場合(リモート・リスナーなど)、Database Upgrade Assistant (DBUA)はそれをデフォルト設定に戻します。
回避策: データベースのアップグレード後、SQL*PlusからALTER SYSTEM SET REMOTE_LISTENER=<user_remote_listener_setting>, ... SCOPE=BOTHを実行します。
Oracle RACポリシー管理型データベースがDatabase Configuration Assistant (DBCA)によって作成されると、DBCAサマリーにより表示されるEM Express URLが機能しない場合があります。これは、ローカル・ノードがデータベースのホストであるサーバー・プールの一部でない場合に起きる可能性があります。この問題は、ポリシー管理型Oracle RACデータベースに関してのみ起こります。
EM Expressは、データベース・インスタンスが実行されているノードからアクセスできるように構成されています。これにはスキャン名を使用してアクセスすることもできます。
回避策: EM Express URL内のホスト名にスキャン名を使用します。たとえば、次のEM Express URL (racnode1はノード名)について考えてみます。
https://racnode1.oracle.com:5500/em
次のように指定できます(scan1はクラスタのスキャン名)。
https://scan1.oracle.com:5500/em
Oracle Enterprise Manager Database Express (EM Express) URLが、Oracle RACノードで機能しない場合があります。
回避策: この不具合は、Oracle RACインストール中に発生することがあります。EM Express URLがOracle RACノードで機能しない場合、そのマシンのノード・リスナーを再起動します。
Oracle RACノード・リスナーで、同じノードのインスタンスからのサービス登録が拒否された場合、その拒否はリスナー・ログ・ファイルにTNS-01182エラーで記録されます。
回避策: オペレーティング・システムからlsnrctl RELOADコマンドを使用するか、リスナーを再起動します。
Gridホームでlsnrctlを使用すると、実行されているノード・リスナーでも接続できません。
回避策: srvctl getenv listenerコマンドを使用して、対応するリスナー・リソースのTNS_ADMINの設定を確認します。通常、これは次のようになります。
<GIHOME>/network/admin/<listener_user_id>
次に、TNS_ADMIN環境を同じ値に設定し、lsnrctlを再実行します。その後、lsnrctlはリスナーに接続できるようになります。
12.1 Oracle Grid InfrastructureスタックをIPv6環境でインストールすると、IPv6ネットワーク・インスタンスの検出に問題がある可能性があります。これは、IPv4またはIPv6をサポートするIPv4インタフェースまたはネットワーク・インタフェースがない場合に発生します。これにより、インストーラがOracle Grid Infrastructureのデプロイに失敗する可能性があります。
回避策: 必ずIPv4とIPv6の両方をサポートするネットワーク・インタフェースを使用するか、仮想IPv4ネットワーク・インタフェースをアクティブ化します。これは次のコマンドを実行すればできます(net0はIPv4ネットワーク・インタフェースの名前)。
/sbin/ifconfig net0 up
srvctl stop listener -forceコマンドを発行して、Oracle ASMインスタンスが実行されているノードでOracle ASMリスナーを停止すると、次のメッセージでエラーが発生する場合があります。
PRCR-1014 : Failed to stop resource ora.ASMNET1LSNR_ASM.lsnr PRCR-1065 : Failed to stop resource ora.ASMNET1LSNR_ASM.lsnr Cannot communicate with crsd
回避策: Oracle ASMネットワーク削除の一部としてならば、特定のサブネットでOracle ASMリスナーを実行する必要がなくなります。次のコマンドを使用します。
srvctl update listener -listener <listener_name> -asm -remove
このコマンドにより、Oracle ASMリスナーをそれが実行されているすべてのノードで停止し、Oracle ASMリスナー構成も削除します。
Oracle Grid Infrastructureのダウングレード後、11.2より前のリスナーが起動に失敗します。
回避策: アップグレード前に、手動で$db_home/network/adminからlistener.oraをバックアップし、ダウングレード後にリストアします。
CRSの再起動後、ディスク・グループ・リソースが、Oracle ASMにマウントされていてもOFFLINEになる場合があります。
回避策: ディスク・グループ・リソースのAUTO_START属性をalwaysに変更します。次に例を示します。
crsctl modify resource ora.<dgname>.dg -attr AUTO_START=always
または、SQLPLUSを使用してOracle ASMでディスク・グループをディスマウントしてマウントすることにより、同じことができます。次に例を示します。
ALTER DISKGROUP <dgname> DISMOUNT; ALTER DISKGROUP <dgname> MOUNT;
12.1では、SQLNET.ALLOWED_LOGON_VERSIONパラメータのデフォルト値が11に更新されています。したがって、11gより前のJDBCシン・ドライバを使用しているデータベース・クライアントは、SQLNET.ALLOWED_LOGON_VERSIONパラメータを古いデフォルト値(8)に設定しないかぎり、12.1のデータベース・サーバーに対して認証できません。
そのため、12.1のOracle ASMおよびOracle Grid Infrastructure環境では、DBCAを使用して10.2.0.5のOracle RACデータベースを作成しようとすると、ORA-28040: No matching authentication protocolエラーが発生して操作が失敗します。
回避策: $crs_home/network/admin/sqlnet.oraファイルにSQLNET.ALLOWED_LOGON_VERSION=8を設定します。
10.2.0.5 DBCAを実行する前に回避策を使用し、12.1 Oracle ASMとOracle Grid Infrastructureを使用するデータベースを作成します。
Oracle Grid Infrastructureを使用していて、Oracle RACリリース11.1.0.7データベースを作成する場合は、DBCAのセッション・プロセスのデフォルトを増加させる必要があります。Oracle Database 12cの場合、DBCAでは、プロセスのデフォルト値は300に設定されます。これより前のリリースでは、デフォルト値は150に設定されます。
回避策: ORA-00018:maximum number of session exceededというエラー・メッセージが返された場合は、DBCAでセッション・プロセスのデフォルト値を300に変更します。そうすると、Oracle Grid Infrastructureリリース12.1と使用するための、リリース11.1.0.7のデータベースが正常に作成されます。
インストーラの起動で、サイレント・モードのDBCAに次のメッセージが表示され、検証警告後に実行が停止します。デフォルトのDBCAの動作では、次の警告後に停止します。
There are not enough servers available to allocate to this server pool, Database instances may not come up on specified cardinality.Do you want to continue?
Yesをクリックすると、DBCAが失敗します。
回避策: インストーラを起動する前に、空きサーバー・プールに十分な数のサーバーがあることを確認します。空きサーバーの数は、ポリシー管理型Real Application Clustersデータベースを構成するために、インストーラで指定されているカーディナリティ以上にする必要があります。サーバー・プールのステータスおよびメンバーシップの詳細は、次のコマンドを使用して確認できます。
Grid_home/bin/crsctl status serverpool
DBACを使用するクラスタ環境用に、12.1 Oracle Grid Infrastructureで11.2より前のOracle RACデータベースを作成すると、次のメッセージで失敗します。
記憶域としてクラスタ・ファイル・システムを使用しているとき、次のメッセージが表示されます。
ORA-00119: invalid specification for system parameter REMOTE_LISTENER
記憶域としてOracle ASMを使用しているとき、次のメッセージが表示されます。
DBCA could not startup the ASM instance configured on this node
回避策: 11.2より前のデータベース・ホームでこの不具合のためのパッチを適用します。このパッチは、10.2.0.4、11.1.0.6および11.1.0.7データベース・リリースに対して必要です。リリース10.2.0.5にはパッチは不要です。
この項では、Oracle SQLJに関する既知の不具合について説明します。
この項では、Oracle Textに関する既知の不具合について説明します。
ORA-4036エラー・メッセージは、ローカルのCONTEXT索引と並行してグローバルなCONTEXT索引を作成する非常に特殊なユースケース・シナリオでユーザーに影響を与える既知の問題です。これらの索引を複数回削除および再作成し、BIG_IOオプションを有効にすることで、問題が表面化するとみなされています。問題の症状には、ハンドル・リークの使用の増加も含まれます。
回避策: ありません。
CONTEXT索引のBIG_IOオプションでは、TOKEN_INFO列に対してSecureFilesを使用します。CONTEXT索引がBIG_IOオプションで作成されるとき、表領域が自動セグメント領域管理(ASSM)であることを確認するためのチェックがありません。索引内のTOKEN_INFO表の$I列が、BasicFileによって暗黙的に作成されます。
回避策: BIG_IOオプションを試す前に、表領域がASSMとして設定されていることを確認します。
CURSOR_SHARINGパラメータをFORCEに設定すると、save_scoreとtopNを必要とするctxfiltercache演算子を使用する問合せは、エラーDRG-10886をスローします。
回避策: ありません。
BIG_IOオプションが指定され、MIXED_CASE属性を持つAUTO_LEXER型がYESに設定されているとき、索引作成中に次のエラーが返される可能性があります。
ORA-00060: deadlock detected while waiting for resource
回避策: AUTO_LEXER用に設定されたMIXED_CASE属性を使用しないか、それが必要な場合は、BIG_IOを指定しないでください。
プリファレンスCTXSYS.CONTEXTを使用してBIG_IO索引上で索引を作成すると、データ・サイズに対して直線的にスケールが調整されません。
回避策: BIG_IOオプションを使用しないでください。
このリリースでは、LONG VARCHAR2 (VARCHAR2 > 4K)機能がCTXSYS.CONTEXT索引でサポートされていません。
回避策: ありません。
STAGE_ITABおよびFORWARD_INDEX属性を同じCTXSYS.CONTEXT索引で使用すると、内部エラーが発生する可能性があります。
回避策: 索引の作成を再び試みます。
この項では、Oracle Universal Installer (OUI)に関する既知の不具合について説明します。
インストールとアップグレードに関するその他の問題について、3.1項「互換性、アップグレード、ダウングレードおよびインストール」も参照してください。
ユーザーは、Oracle Database Client 12cリリース1 (12.1.0.1.0)またはOracle Database Examples 12cリリース1 (12.1.0.1.0)ソフトウェアを、それぞれのインストーラを使用して異なるバージョンの既存のOracleホームにインストールすることを妨げられません。
回避策: リリース12.1.0.1.0 Clientおよびリリース12.1.0.1.0 Examplesソフトウェアを既存のOracleホームにインストールする前に、Oracle Databaseサーバーのバージョンもリリース12.1.0.1.0であることを確認してください。
Oracle Grid Infrastructureのインストール時に、Oracle Universal Installer (OUI)がハングして、次のエラーがログ・ファイルに表示される可能性があります。
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: PermGen space
回避策: インストールを再実行します。
Oracle Grid Infrastructure 12cリリース1 (12.1)では、クラスタ状態モニター(CHM)リポジトリ用に、ノードごとにローカル記憶領域を割り当てる必要がありません。12.1では、このリポジトリは、現在グリッド・インフラストラクチャ管理リポジトリ(GIMR)として知られていますが、Oracle Cluster Registry (OCR)および投票ディスク・ファイルと同じディスク・グループにあります。GIMRに必要な領域は、クラスタの現在の最大サイズと、このディスク・グループの冗長性のレベルによって決まります。使用可能な必須領域は、『Oracle Grid Infrastructureインストレーション・ガイド』のOracle Grid Infrastructure共有ファイル・システム・ボリューム・サイズの要件に関する項で説明されているように、手動で確認する必要があります。この領域の可用性は、Oracle Universal Installer (OUI)アップグレード・インストールの一部として自動的に確認されません。十分な領域が見つかると、GIMRを作成しようとするときに、アップグレードは失敗します。
回避策: ディスク・グループにさらなるディスクを追加し、GIMRを作成するOUIのステップを再試行することが解決策です。
Oracle RACホームまたはCluster Ready Services (CRS)ホーム用のOracle Universal Installer (OUI)では、大文字と小文字が混在するホスト名はサポートされていません。
回避策: 大文字と小文字の混在したホスト名は使用しないでください。
データベースの削除は、Oracle Grid Infrastructureとデータベースが別のユーザーによってインストールされている場合、次のエラー・メッセージで失敗する可能性があります。
./runInstaller[192]: /tmp/deinstall_bootstrap/deinstallbootstrap.log: cannot create [Permission denied]
回避策: 手動でdeinstall_bootstrapを削除し、Gridホームを削除するために削除を再実行します。
アップグレード中、ignore unreachable nodesがOUIで選択されていて、停止しているノードがいくつかあるとき、強制アップグレード・コマンド(rootupgrade.sh -forceなど)が完了する前に、停止していたノードが再び起動する場合、強制アップグレードは実行できません。
回避策: 停止していたノードが、アップグレードが完了するまで確実に停止したままであるようにします。
Oracle Universal Installer (OUI)は、共有メモリー・セグメントの割当てが多すぎることが原因で、Oracle Grid Infrastructureのインストールに失敗する可能性があります。この問題は、サーバーが起動した後、OUIの最初の起動時にのみ発生するものと思われます。
回避策: Oracle Grid Infrastructureのインストールを最終決定する前(OUIダイアログの最後のページにある「インストール」ボタンをクリックする前)にipcs -m | wc -lコマンドを別の端末で発行し、この時点で割り当てられている共有メモリー・セグメントの数を確認します。
割り当てられた共有メモリー・セグメントの返された数が500を大幅に上回る場合、インストールは失敗する可能性が高いので、現在のOUIインストールを取り消し、runInstallerを再起動します。レスポンス・ファイルを使用してインストールを再開するために、レスポンス・ファイルを保存できます。さもなければ、ダイアログで必須の情報をすべて再度入力しなおすことが必要になります。問題は、サーバーの起動後、初めてOUIを起動したときにのみ発生するものと思われるため、サーバーを再起動せずにOUIを再起動すれば、問題は解決するはずです。
中央インベントリの場所がクラスタの別のノードで違っている場合、addnode.shはクラスタのリモート・ノードでインベントリを正しく更新しません。
回避策: クラスタにノードを追加するには、クラスタのすべてのノードで中央のインベントリの場所が同じであることが必要です。addnode.shを実行する前に、この要件が満たされていることを確認してください。
32ビットのOracleデータベースと64ビットのOracleデータベースを同じORACLE_BASEにインストールすると、削除ツールを使用していずれかのデータベースを削除した場合に、予期しない結果になることがあります。これらのOracleホームが同じ中央インベントリを使用していない場合、削除ツールは、ORACLE_BASE下にあるすべてのOracleホームを削除します。
回避策: 複数の中央インベントリを使用しないようにします。32ビットと64ビットのデータベース・インストールに同じORACLE_BASEを使用しないようにするか、常に64ビットのホームから削除を実行するようにしてください。
Oracleホーム内にあるOracle Universal Installer (OUI) runInstallerスクリプト(ORACLE_HOME/oui/bin/runInstaller)は、Oracle Database 12cリリース、クラスタ用Oracle Grid Infrastructure、およびOracle Database Clientのインストールには使用できません。
回避策: それぞれのOracle Database 12c製品メディアのOracle Universal Installerを使用して各製品をインストールします。
この項では、Oracle XML DBに関する既知の不具合について説明します。
バイナリXMLデータを使用した表を、トランスポータブル表領域(TTS)を使用してエクスポート/インポートすることはサポートされていません。
回避策: Oracle Data Pumpの従来型パスのみを使用してデータを移動します。
XMLIndexが定義されたXMLType表を持つOracle Database 12c非CDBデータベースをOracle Database 12c CDBデータベースに接続し、noncdb_to_pdb.sqlスクリプトを実行する場合、XMLIndexが無効になる可能性があります。
回避策: 次のDDLを発行することにより、手動でXMLIndexを有効化します。
ALTER INDEX <index_name> ENABLE;
次のシナリオについて考えてみます。
11.2.0.2データベースで、XMLType表、またはパーティション化されているXMLType列を持つ表を作成してから、その表で構造化されたXMLIndexを作成します。次に、11.2.0.2データベースをOracle Database 12c以上にアップグレードします。ALTER TABLE EXCHANGE PARTITION文を別のパーティションを持つベース表パーティションの1つ、またはOracle Database 12cデータベースで同じ構造と類似のXMLIndexで作成される表で実行した場合、次のエラーで失敗します。
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を削除後再作成します。
32K VARCHARデータ型が有効で、XMLの格納がオブジェクトリレーショナルである場合、UPDATEXMLまたは相当のXQuery Update操作によりパーサーの問題が発生する可能性があります。
回避策: ありません。
32K VARCHARデータ型が有効で、XMLの格納がオブジェクトリレーショナルである場合、XMLType列を直接選択すると、正しくないデータが返される可能性があります。次に例を示します。
SELECT xml_col FROM some_table p;
回避策: GETCLOBVAL()関数をコールします。次に例を示します。
SELECT p.xml_col.getclobval() FROM some_table p;
Oracle Database 12cリリース1 (12.1)より前、ネームスペースのないXML要素をXML文書に挿入すると、新しく挿入された要素は、デフォルトのネームスペースが親要素内で定義されていれば、親要素のネームスペースに割り当てられますが、これは正しくありません。
Oracle Database 12cでは、新しい要素はxmlns=""を使用して挿入されます。
回避策: ありません。
バインド変数としてCLOB, BLOBまたはNCLOBデータ型を含むXML問合せは、ロジカル・スタンバイ、Oracle GoldenGateおよびXStreamレプリケーションに対してはサポートされていません。
回避策: CLOB, BLOBまたはNCLOB以外のデータ型を使用して、問合せを実行します。
ロジカル・スタンバイ・ベースのスキーマ登録レプリケーションでは、互換性をOracle Database 12c以上に設定する必要があります。XStreamおよびOracle GoldenGateの場合、スキーマを各インスタンスに個別に登録する必要があり、レプリケーションはサポートされていません。COPYEVOLVEおよびCOMPILESCHEMAを除き、DBMS_XMLSCHEMAパッケージのすべてのプロシージャがサポートされています。
回避策: ありません。
サプリメンタル・ロギングは、REFカーソルにバインドされた変数を使用するXMLQuery更新用にはサポートされません。
回避策: レプリケートが必要なXMLType列または属性を更新する前に、REFカーソルの評価を非カーソル変数に格納し、その後、REFカーソルのかわりにこれらの変数を使用して列や属性を更新します。
XMLIndex構造化コンポーネントを持つXMLType表で、EXCHANGE PARTITION操作が機能しません。
回避策: この問題を回避するには、次の手順を実行してください。
EXCHANGE PARTITION操作を実行する前に、次のコールを発行します。
EXEC DBMS_XMLSTORAGE_MANAGE.EXCHANGEPREPROC(user, 'partitioned_myxml');
partitioned_myxmlはパーティション化されたXMLType表です。
EXCHANGE PARTITION操作を実行します。次に例を示します。
ALTER TABLE partitioned_myxml EXCHANGE PARTITION p1 WITH TABLE myxml;
EXCHANGE PARTITION操作を実行した後、次のプロシージャをコールします。
EXEC DBMS_XMLSTORAGE_MANAGE.EXCHANGEPOSTPROC(user,'partitioned_myxml');
myxml表にも構造化XMLIndexがある場合、myxml表でもDBMS_XMLSTORAGE_MANAGE.EXCHANGEPREPROCおよびDBMS_XMLSTORAGE_MANAGE.EXCHANGEPOSTPROCプロシージャを実行する必要があります。次に例を示します。
EXCHANGE PARTITION操作を実行する前に、次のコールを実行します。
EXEC DBMS_XMLSTORAGE_MANAGE.EXCHANGEPREPROC(user, 'myxml');
EXCHANGE PARTITION操作の実行後に、次のコールを実行します。
DBMS_XMLSTORAGE_MANAGE.EXCHANGEPOSTPROC(user,'myxml');
Oracle RACシステムでは、複数の同時データベース・インスタンスで単一の物理データベースを共有できます。ただし、Oracle RACデータベース内のOracle XML DBに対するディスパッチは、仮想IPではリスニングしません。
回避策: Oracle XML DBがOracle RACシステム上でTCP(S)を使用できるようにするには、クラスタの各データベース・インスタンスに対して、TCP(S)ディスパッチャを次のように構成する必要があります(ここで、SIDはインスタンスのSID、HOSTは物理データベースのホスト名です)。
SID.dispatchers="(address=(protocol=tcps)(host=HOST-vip)(service=SIDxdb))"
非セキュア・ディスパッチャ(TCPSではなくTCP)の場合は、tcpのかわりに、コマンド内tcpsを使用してください。
この項では、Oracle Recovery Manager (RMAN)に関する既知の不具合について説明します。
Oracle Database 12cリリース1 (12.1)に、ALTER DATABASE OPEN RESETLOGS文の実行時にresetlogs間の変更トラッキングをサポートする新機能が追加されました。これは、不要なビットマップを削除することで実現されます。ビットマップでは、指定したresetlogs Point-in-Time後に行われた変更が追跡されるためです。ビットマップの削除には問題があり、ORA-600 [krccchs_1]時にOPEN RESETLOGSエラーが発生する可能性があります。
回避策: 変更トラッキングを無効にしてから、再び有効にします。ALTER DATABASE OPEN RESETLOGS文を実行する前に変更トラッキングを無効にし、open resetlogs操作が完了してから、変更トラッキングを再び有効にする必要があります。
データベースをNOARCHIVELOGモードでバックアップするには、データベースをきちんと停止してから、マウント状態で起動する必要があります。
マルチテナント・コンテナ・データベース(CDB)がNOARCHIVELOGモードで、ルートが開いている場合、RMANバックアップは失敗します(予想どおり)が、それでもバックアップ・ピースは生成されます。これらのパックアップ・ピースは、CDBがNOARCHIVELOGモードで開かれている間に生成されたため、CDBまたはPDBのリカバリには使用できません。
回避策: 次のいずれかをこの状況に対する回避策として使用します。
バックアップを取る前に、必ずCDBをきちんと停止してからマウント状態で起動します。
バックアップを取る前に、CDBがARCHIVELOGモードであることを確認します。
当初作成された使用できないバックアップは、RMANを使用して手動で削除する必要があることに注意してください。
この項では、ベンダーとオペレーティング・システムに関する既知の不具合について説明します。
1つのクライアント・マシン上でSCANとEZCONNECTを使用する接続は、特定のSCANリスナーを使用するようにリクエストできます。したがって、ラウンドロビンDNSを使用してロード・バランシングを行うことはできません。
回避策: tnsnames.oraでLOAD_BALANCE=onを指定する次の構成を使用して、データベースに接続します。
ORCL =
(DESCRIPTION =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST = stscan1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = srv.world)
)
)
