| Oracle® Databaseプラットフォーム共通日本語README 11gリリース2 (11.2) B56292-21 |
|
 前 |
 次 |
|
注意: Oracle Database 11gリリース2 (11.2.0.4)を使用する場合は、このREADMEを参照してください。 |
READMEのこの項には、さらに次の項があります。
第2.1項「互換性、アップグレード、ダウングレードおよびインストール」
第2.2項「11.2.0.4で使用できないか制限されている機能」
第2.3項「Oracle Databaseの非推奨機能およびサポートが終了した機能」
第2.8項「Oracle Application Express」
第2.9項「Oracle Automatic Storage Management (Oracle ASM)」
第2.10項「クラスタ用Oracle Grid Infrastructure」
第2.13項「Oracle Real Application Clusters」
第2.18項「Oracle Warehouse Builder」
アップグレード前の処理、アップグレード後の処理、互換性および相互運用性の説明に関する最新の更新内容およびベスト・プラクティスについては、Oracle Database 11gリリース2(11.2)(https://support.oracle.com)のノート785351.1を参照してください。
|
注意: インストールの完了後、Oracleソフトウェアが実行されている間は、/tmp/.oracleまたは/var/tmp/.oracleディレクトリやディレクトリ内のファイルを手動で削除したり、それらを削除するcronジョブを実行しないでください。これらのファイルを削除すると、Oracleソフトウェアが断続的にハングする場合があります。クラスタ用のOracle Grid InfrastructureおよびOracle Restartのインストールが失敗し、次のエラーが表示されます。CRS-0184: Cannot communicate with the CRS daemon. |
Oracle Database 11gリリース2 (11.2.0.4)にアップグレードした後、OPTIMIZER_FEATURES_ENABLEパラメータの値が11.2.0.4 (Oracle Database 11gリリース2 (11.2.0.4)でのデフォルト値)に設定されていると、オプティマイザはヒストグラム統計情報を持つCHARまたはNCHARデータ型の列について次善プランを生成します。
この問題の1つの回避策は、Bug#18255105用のパッチを適用することです。このパッチは、ヒストグラム統計情報を持つCHARまたはNCHARデータ型の列を失効した列としてマークします。このパッチはまた、(GATHER AUTOまたはGATHER STALEオプションを使用して)統計情報の自動収集や手動収集を行っている場合に、問題のある表から統計情報を収集する目的にも使用できます。
もう1つの回避策は、ヒストグラム統計情報を持つCHARまたはNCHARデータ型の列(DBA_TAB_COL_STATISTICSビューを使用して)を見つけ、それらに対してGATHER_TABLE_STATSプロシージャを実行することです。本番システムでGATHER_TABLE_STATSプロシージャを使用するのではなく、テスト・システムで統計を収集し、統計をユーザー統計表にエクスポートした後、本番システムに統計をインポートしてください。この回避策を使用した場合、Bug#18255105用のパッチを適用する必要はありません。
統計を収集する際には、(次善プランを持つ)既存のカーソルがSQL文の再実行時に共有されないよう、NO_INVALIDATEパラメータをFALSEに設定してください。
次のすべてのシナリオに該当する表から統計を収集した場合にも、次善プランが生成されることがあります。
表にCHARまたはNCHARデータ型の列がある。
OPTIMIZER_FEATURES_ENABLEパラメータの値が11.2.0.4に設定されている。
表にヒストグラムがある。
後で、OPTIMIZER_FEATURES_ENABLEパラメータの値を11.2.0.4よりも小さい値に変更した(たとえば、Oracle Databaseをダウングレードし、OPTIMIZER_FEATURES_ENABLEパラメータをより小さい値に設定した)。
このシナリオに該当する場合は、OPTIMIZER_FEATURES_ENABLEパラメータを変更した後に、それらの表の統計を再収集する必要があります。
リリース11.2.0.4から11.2.0.2にダウングレードするとき、@catdwgrd.sqlを実行すると次のエラーが発生します(Oracle Bug#11811073を参照)。
ORA-20000: Upgrade from version 11.2.0.2.0 cannot be downgraded to version
更新バージョンのcatrelod.sqlを提供するリリース11.2.0.2用のパッチ11811073を適用してください。このパッチは、@catdwgrd.sqlを実行する前に11.2.0.2環境で適用する必要があります。
Database Controlが構成されている状態でデータベースをダウングレードするときは、次の事項に注意してください(Oracle Bug#9922349を参照)。
11.2.0.1から11.2.0.4へのアップグレードを行っていて、後で11.2.0.1にダウングレードする予定の場合、データベースのダウングレードの一部としてDatabase Controlをダウングレードするには、11.2.0.1 PSU2バンドル・パッチを適用する必要があります。
このパッチを適用しないと、Database ControlのデータをリストアするときにemdwgrdユーティリティがIMPORT (impdp)エラーで失敗します。
11.2.0.1 Oracle RACデータベースでemdwgrdを実行する際、システム識別子(SID)の別名がtnsnames.oraで定義されていない場合は、追加のパラメータ-serviceAliasを渡す必要があります。SID名とデータベース名が異なる場合は、単一のインスタンスに対してもこのパラメータの指定が必要です。次に例を示します。
emdwgrd -save [-cluster] -sid SID [-serviceAlias tns_alias] -path save_directory emdwgrd -restore -tempTablespace TEMP [-cluster] -sid SID [-serviceAlias tns_alias] -path save_directory
Oracleホームを使用する11.2.0.4から11.2.0.1へのインプレース・ダウングレードの場合は、emdwngrd -restoreを実行する前にemca -restoreを実行する必要はありません。
アップグレードの間にノード・クラッシュが発生した場合、-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
リリース11.2.0.3から11.2.0.4へのアップグレードの後、ora.onsのステータスがUNKNOWNで説明がCHECK TIMED OUTと示される場合があります(Oracle Bug#12861771を参照)。
回避策は、Oracle Notification Services (ONS)プロセスを強制終了してsrvctl start nodeappsを実行することです。
アップグレード処理中に次のエラーが表示された場合、ごみ箱が消去されていない可能性があります。
ORA-00600: internal error code, arguments: [15239]
アップグレードする前に、次のコマンドを実行してデータベースのごみ箱を空にします。
SQL> PURGE DBA_RECYCLEBIN
リリース11.1.0.6へのダウングレードを予定している場合は、Oracle Bug#7634119用のパッチを適用します。このアクションにより、次のDBMS_XS_DATA_SECURITY_EVENTSエラーが回避されます。
PLS-00306: wrong number or types of arguments in call to 'INVALIDATE_DSD_CACHE' DBMS_XS_DATA_SECURITY_EVENTS PL/SQL: Statement ignored
このパッチは、catrelod.sqlの実行前に適用してください。
Data Miningオプションを使用するデータベースを11.2.0.1から11.2.0.4にアップグレードする場合は、DMSYSスキーマが11.2.0.1データベースに存在しないことを確認してください。存在する場合は、DMSYSスキーマとそれに関連するオブジェクトを次のようにデータベースから削除する必要があります。
SQL> CONNECT / AS SYSDBA; SQL> DROP USER DMSYS CASCADE; SQL> DELETE FROM SYS.EXPPKGACT$ WHERE SCHEMA = 'DMSYS'; SQL> SELECT COUNT(*) FROM DBA_SYNONYMS WHERE TABLE_OWNER = 'DMSYS';
前述のSQLでゼロ以外の行が戻された場合は、次の例に示すようにSQLスクリプトを作成して実行します。
SQL> SET HEAD OFF SQL> SPOOL dir_path/DROP_DMSYS_SYNONYMS.SQL SQL> SELECT 'Drop public synonym ' ||'"'||SYNONYM_NAME||'";' FROM DBA_SYNONYMS WHERE TABLE_OWNER = 'DMSYS'; SQL> SPOOL OFF SQL> @dir_path/DROP_DMSYS_SYNONYMS.SQL SQL> EXIT;
10gから11.2にデータベースをアップグレードすると、すべてのデータ・マイニング・メタデータ・オブジェクトはDMSYSからSYSに移行されます。アップグレード後、ダウングレードを実行する必要がないと判断した場合は、初期化パラメータCOMPATIBLEを11.2に設定し、前述されているようにDMSYSスキーマおよび関連するオブジェクトを削除します。
タイムゾーン・ファイルの最新バージョンを以前にインストールし、DBMS_DST PL/SQLパッケージを使用してTIMESTAMP WITH TIME ZONEデータを最新バージョンにアップグレードした場合は、ダウングレード・プロセスの一環としてcatrelod.sqlが実行されると、次のエラーが戻されます(Oracle Bug#9803834を参照)。
ORA-00600: internal error code, arguments: [qcisSetPlsqlCtx:tzi init], [], [], [], [], [], [], [], [], [], [], []
詳細は、『Oracle Databaseアップグレード・ガイド』の第6章で、データベースのダウングレートの手順2を参照してください。
タイムゾーン・ファイルの最新バージョンを以前にインストールし、DBMS_DST PL/SQLパッケージを使用してTIMESTAMP WITH TIME ZONEデータを最新バージョンにアップグレードした場合は、ダウングレードするリリースに対して最新バージョンのタイムゾーン・ファイルをインストールする必要があります。たとえば、Oracle Database 11gリリース2 (11.2)に付属している最新タイムゾーン・ファイルはバージョン14です。データベースのアップグレード後にDBMS_DSTを使用してTIMESTAMP WITH TIME ZONEデータをバージョン14にアップグレードした場合は、ダウングレードするリリースに対してバージョン14のタイムゾーン・ファイルをインストールします。これにより、データ検索で論理的に正しいTIMESTAMP WITH TIME ZONEデータが確保されます。データベースで使用されているバージョンを確認するには、V$TIMEZONE_FILEを問い合せます。
タイムゾーン・ファイルのインストールの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』も参照してください。
Oracle Automatic Storage Management (Oracle ASM)のローリング・アップグレード・チェックでは、11.1.0.6からそれ以降のリリースへのローリング・アップグレードが許可されません(Oracle Bug#6872001を参照)。アラート・ログに、次のメッセージがレポートされます。
Rolling upgrade from 11.1.0.6 (instance instance-number) to 11.x.x.x is not supported
LMONからORA-15156が通知され、インスタンスが終了します。
Oracle ASMを11.1.0.6からそれ以降のリリースにアップグレードする場合は、この不具合に対応するパッチを11.1.0.6インスタンスに適用してから、ローリング・アップグレードを開始します。このパッチは、ローリング方式で11.1.0.6インスタンスに適用できます。
Oracle ASMが投票ディスクおよび定数ディスクとして使用されていない場合、インストールの後で、Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)・レジストリ・リソースがOFFLINEを報告します(Oracle Bug#9876173およびOracle Bug#9864447を参照)。この原因は、Oracle ACFSレジストリでは、Oracle ASM Dynamic Volume Manager (Oracle ADVM)ボリュームを提供するために、Oracle ASMを使用する必要があるためです。
クラスタ用Oracle Grid Infrastructure 11gリリース2 (11.2.0.1)でOracle ACFSファイル・システムを使用していて、Oracle Grid Infrastructureを11gリリース2 (11.2.0.2)、11gリリース2 (11.2.0.3)または11gリリース2 (11.2.0.4)にアップグレードし、冗長なインターコネクトの使用を利用して1つ以上のプライベート・インタフェースをプライベート・ネットワークに追加する場合は、アップグレードした各クラスタ・メンバー・ノードでOracle ASMインスタンスを再起動する必要があります(Oracle Bug#9969133を参照)。
@catupgrd.sqlと@utlrp.sqlの両方を実行した後、マテリアライズド・ビューのステータスがINVALIDになります(Oracle Bug#12530178を参照)。このことは次のコマンドを使用して確認できます。
SELECT object_name, object_id, owner FROM all_objects WHERE object_type='MATERIALIZED VIEW' and status='INVALID'; OBJECT_NAME OBJECT_ID OWNER ------------------------------ ----------- ------- FWEEK_PSCAT_SALES_MV 51062 SH
@catupgrd.sqlを実行してデータベースをアップグレードし、さらに@utlrp.sqlを実行して無効なオブジェクトを再コンパイルした後で、無効なマテリアライズド・ビューがまだ存在している場合は、次のSQL文を発行します。
ALTER MATERIALIZED VIEW sh.FWEEK_PSCAT_SALES_MV COMPILE;
|
注意: 高速リカバリの以前の名称はフラッシュ・リカバリでした。 |
Oracle Database 11gのアップグレード前情報ユーティリティ(utlu112i.sql)は、SYSTEM表領域およびデータベース内のコンポーネントに関連するその他の表領域(SYSAUX、DRSYSなど)で必要となる追加領域を見積ります(Oracle Bug#13067061を参照)。手動でアップグレードする場合は、その前に既存のデータベースに対して必ずこのユーティリティを実行してください。
表領域サイズの見積りは、特に、データベースにOracle XML DBがインストールされている場合は小さすぎる場合があります。ただし、手動でのアップグレードまたはDatabase Upgrade Assistant (DBUA)を使用したアップグレード時に発生する可能性のある領域の問題を回避するために、アップグレード中は、各表領域用のデータファイルにAUTOEXTEND ON MAXSIZE UNLIMITEDを設定できます。
ファイル・システムを使用してデータファイルを格納している場合は、ファイル・システムに、アップグレード中の表領域の増大に対応できる十分な領域があることを確認してください。
高速リカバリ領域を使用している場合は、使用可能なサイズが、アップグレード中に生成されるREDOに対して十分であることを確認してください。サイズが適切でない場合には、アラート・ログにORA-19815エラーが書き込まれ、追加の領域が使用可能になるまでアップグレードは停止されます。
次の各項では、削除および構成解除の制限について説明します。詳細は、第2.22.2項「削除ツールに関する既知の不具合」を参照してください。
アップグレードしたOracle Database 11gリリース2 (11.2)のOracle RACホームを構成解除または削除した後に、11.2のクラスタ用Oracle Grid Infrastructureホームを構成解除または削除するには、11.2より前のOracle RACソフトウェア・ホームを中央のインベントリからデタッチする必要があります(Oracle Bug#8666509を参照)。
11.2より前のOracle RACホームを中央のインベントリからデタッチするには、次のコマンドを使用します。
ORACLE_HOME/oui/bin/runInstaller -detachHome ORACLE_HOME_NAME=pre-11.2_ORACLE_HOME_NAME ORACLE_HOME=pre-11.2_ORACLE_HOME
Oracle Database Express Edition 10gからOracle Database 11gにアップグレードすることはできません。かわりに、Oracle Data Pumpを使用します(参照バグ28137959)。
Oracle Databaseアップグレード・ガイド(11gリリース2 (11.2)、部品番号B56310-08)のOracle Database Express EditionからOracle Databaseへのアップグレードの概要に関する項には、Oracle Database 10g Express Edition (Oracle Database XE)からOracle Database 11gにアップグレードできると記述されています。この情報は誤りです。Oracle Database 10g XEからOracle Database Standard EditionまたはEnterprise Editionにアップグレードすることはできません。かわりに、Oracle Data Pumpを使用してOracle Database XEからOracle Databaseのより新しいリリースにデータをエクスポートできます。
|
関連項目: Oracle Databaseユーティリティ |
次に、Oracle Database 11gリリース2 (11.2.0.4)で使用できない、または制限されているコンポーネントのリストを示します。
サード・パーティのテクノロジが基になっているOracle Textの一部の機能(AUTO_LEXERやCTX_ENTITYなど)は、11.2.0.4では無効になりました(Oracle Bug#12618046を参照)。BASIC_LEXERでは、サード・パーティのテクノロジに依存するINDEX_STEMS属性値の使用も影響を受けます。これによって既存のアプリケーションに影響がある場合は、Oracleサポート・サービスにお問い合せください。
Oracle Clusterware 11gリリース2 (11.2.0.1)または11gリリース2 (11.2.0.2)では、rootcrs.plスクリプトを使用してノードを削除することはできません(Oracle Bug#13712508を参照)。
クラスタ用Oracle Grid Infrastructureの11.2.0.1、11.2.0.2または11.2.0.3リリースが非共有Oracleホームにインストールされていて、クラスタ用Oracle Grid Infrastructureの11.2.0.4リリースが共有Oracleホームにインストールされている場合、Oracle Databaseリリース11.2.0.1、11.2.0.2または11.2.0.3からOracle Clusterwareリリース11.2.0.4へのアップグレードはサポートされません(Oracle Bug#10074804を参照)。Oracle Clusterwareのアップグレード前とアップグレード後のリリースの両方が、共有Oracleホームまたは非共有Oracleホームのどちらか一方にインストールされている必要があります。
すべてのOracle Grid Infrastructureパッチセット・アップグレードは、アウトオブプレース・アップグレードになります。この場合、パッチセットは新規のOracle Gridホームにインストールしてください(Oracle Bug#10210246を参照)。インプレース・パッチセット・アップグレードはサポートされていません。
Oracle Database 11gリリース2 (11.2)では、新機能追加の他に、データベースの動作の変更が行われています。動作の変更には、初期化パラメータ、オプション、構文、機能およびコンポーネントの非推奨とサポートの終了が含まれます。詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
この項では、Oracle Database 11gリリース2 (11.2)と旧リリースのデータベースの動作の違いをいくつか説明します。アップグレードおよびダウングレードに関する大部分の情報は、『Oracle Databaseアップグレード・ガイド』に記載されています。
AUDIT_SYS_OPERATIONS初期化パラメータがTRUEに設定されている場合、DBMS_SYS_SQL PL/SQLパッケージを使用してSYS認可で実行されたユーザーSQL文は、Oracle Databaseによって監査されます。
|
注意: この設定は、Oracle Clusterwareと中間層、またはOracle ClusterwareとJDBCクライアントとの間の接続におけるセキュリティに影響を与えます。 |
JDBC接続プールまたはOracle Universal Connection Pool (UCP)で使用する高速接続フェイルオーバー(FCF)などのOracle RAC機能は、Oracle RACノードで実行されているOracle Notification Service (ONS)の通知をサブスクライブします。通常、データベース層のONSサーバーと中間層の通知クライアント間の接続は認証されません。SSL証明書を構成して使用することで認証を設定できますが、その手順が明確に記載されていません。
回避策は次のとおりです。
orapkiインタフェースを使用してOracle Walletを作成し、SSL証明書を格納します。
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
手順1で作成したウォレットの場所を指定するために、データベース層のすべてのノードでONS構成ファイルを更新します。
ORA_CRS_HOME/opmn/conf/ons.configファイルを開きます。
ons.configファイルにwalletfileパラメータを次のように追加します。
walletfile=ORA_CRS_HOME/opmn/conf/sslwallet
srvctlを使用して、次のようにONSサーバーを再起動します。
srvctl start nodeapps
中間層でクライアント側ONSデーモンを実行している場合は、次の2つの構成が可能です。
(OracleAS 10.1.3.xなどの)OPMNからONSを起動する場合はopmn.xmlを使用します。
(onsctlの使用など)スタンドアロンでONSを起動する場合はons.configを使用します。
ケース(1)の場合は、Oracle Application Serverリリースに対応する『OPMN管理者ガイド』を参照してください。この構成では、ウォレットの場所を指定するために、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
ダイレクト・パスのINSERTを使用して多数のパーティションをロードすると、特にデータ圧縮が指定されている場合にメモリー制限を超える場合があります(Oracle Bug#6749894を参照)。メモリーを確保するために、11.2からはPGA_AGGREGATE_TARGET初期化パラメータに基づいて、同時にロードされるパーティションの数が制限されるようになりました。ロード中のパーティションに格納されない行は、一時表領域に保存されます。パーティションの現在のセットですべての行がロードされた後に、一時表領域に保存されている行から他のパーティションがロードされます。
この動作により、不十分なメモリーによりダイレクト・パスのINSERTが終了することがなくなりました。
Bloomフィルタを使用すると、Oracle Exadataでシリアル問合せを実行し、結果をストレージ・セルに入れることができます。11.2より前のリリースでは、シリアル問合せでbloomフィルタを使用できる状況は非常に限られていました。今回の11.2.0.4リリースでは、Oracle Exadataでのみより多くの場面でbloomフィルタを使用できるようになりました。これによって問合せがサーバー・ノードでシリアルに実行された場合にも、ストレージ・セルにプッシュされたbloomフィルタがパラレルで実行されるため、影響を受ける問合せのパフォーマンスが改善されます。
CTXシステム・パラメータFILE_ACCESS_ROLEのデフォルトの動作が変更されています(Oracle Bug#8360111を参照)。ファイルまたはURLのデータストアを使用するOracle Textの既存の索引を持つ顧客は、エラーを発生せずに索引を引き続き使用できるように、措置を講ずる必要があります。変更内容は次のとおりです。
FILE_ACCESS_ROLEがNULL (デフォルト)の場合、アクセスは許可されません。このタイプの索引を作成できたユーザーは、変更後はこれらの索引をデフォルトで作成できなくなります。
索引の同期およびドキュメント・サービスの操作で、FILE_ACCESS_ROLEがチェックされるようになりました。この変更前は、このタイプの索引の同期や、ctx_doc.highlightなどのドキュメント・サービス・コールの使用が許可されていたユーザーも、デフォルトではできなくなります。
FILE_ACCESS_ROLEの変更が許可されるのは、SYSのみです。SYS以外のユーザーとしてctx_adm.set_parameter (FILE_ACESS_ROLE, role_name)をコールすると、新規エラーが発生するようになりました。
DRG-10764: only SYS can modify FILE_ACCESS_ROLE
ユーザーは、FILE_ACCESS_ROLEをPUBLICに設定して、このチェック(前のデフォルトの動作)を明示的に無効にできます。
Oracle Database 11gリリース2 (11.2)では、不均一なメモリー・アクセスのサポートがデフォルトで無効になりました。この制限は、すべてのプラットフォームおよびオペレーティング・システムに適用されます(Oracle Bug#8450932を参照)。
Oracle Databaseで不均一なメモリー・アクセスの最適化およびサポートが使用できるのは、特定の組合せのOracleバージョン、オペレーティング・システムおよびプラットフォームのみです。不均一なメモリー・アクセスのサポートを有効にするには、Oracleサポート・サービスとハードウェア・ベンダーを使用してください。
データベース・セキュリティの次の変更に注意してください。
Oracle Databaseサーバーおよびクライアントの両方に対して、ネイティブ・ネットワーク暗号化セキュリティを強化するパッチが用意されています。
Oracleパッチは、暗号化およびチェックサム・アルゴリズムを更新して、弱い暗号化およびチェックサム・アルゴリズムを非推奨にします。
My Oracle Supportノート2118136.2からダウンロードできるこのパッチは、ネイティブ・ネットワーク暗号化およびチェックサム・アルゴリズムの脆弱性を修正して、サーバーとクライアントの間の接続を強化します。古い、あまりセキュアではない暗号化およびチェックサム・アルゴリズムの無効化を容易にする2つのパラメータが追加されます。このパッチをOracle Databaseサーバーおよびクライアントに適用することをお薦めします。
このパッチはOracle Databaseリリース11.2以降に適用されます。次の環境でこのパッチを適用できます: スタンドアロン、プライマリ/スタンバイ、Oracle Real Application Clusters (Oracle RAC)およびデータベース・リンクを使用する環境。
向上した、サポートされているアルゴリズムは、次のとおりです。
暗号化アルゴリズム: AES128、AES192およびAES256
チェックサム・アルゴリズム: SHA1、SHA256、SHA384およびSHA512
非推奨になり、パッチの適用後に使用しない弱いアルゴリズムは、次のとおりです。
暗号化アルゴリズム: DES、DES40、3DES112、3DES168、RC4_40、RC4_56、RC4_128およびRC4_256
チェックサム・アルゴリズム: MD5
従う一般的なプロシージャは、まず、Oracle Database環境でサポートされなくなったアルゴリズムへの参照をサポートされるアルゴリズムに置き換え、サーバーにパッチを適用し、クライアントにパッチを適用して、最後に、sqlnet.oraパラメータを設定してサーバーとクライアントの間の適切な接続を再び有効化します。
パッチが影響する領域は次を含みますが、これらに限定されません。
Java Database Connectivity (JDBC) Thinドライバに使用されるoracle.net.ano.AnoServicesインタフェース定数設定
CONNECTION_PROPERTY_THIN_NET_CHECKSUM_TYPEシンJDBCネットワーク・パラメータ設定
SQLNET.ENCRYPTION_TYPES_SERVERおよびSQLNET.ENCRYPTION_TYPES_CLIENTパラメータ設定
Secure Sockets Layer (SSL) SSL_CIPHER_SUITEパラメータ設定
SecureFile LOB暗号化列
データベース常駐接続プーリング(DRCP)構成
Oracle Call Interface (Oracle OCI)、ODP.NETの構成に使用される暗号化設定
|
関連項目:
|
Oracle Databaseサーバーおよびクライアントへのパッチの適用に加えて、サーバーおよびクライアントのsqlnet.oraパラメータを設定する必要があります。
次のステップを示された順番で実行してください。
パッチをインストールするサーバーおよびクライアントをバックアップします。
My Oracle Supportにログインし、My Oracle Supportノート2118136.2で説明されているパッチをダウンロードします。
My Oracle Supportは次のURLにあります。
https://support.oracle.com
サーバーにパッチを適用します。
My Oracle Supportノート2118136.2の指示に従って、パッチをサーバーに適用します。後のステップで、同じパッチをクライアントに適用します。
クライアントにパッチを適用します。
パッチを適用する必要があるクライアントを決定します。
My Oracle Supportノート2118136.2の指示に従って、パッチを各クライアントに適用します。
各クライアントのsqlnet.oraファイルで、非推奨になったアルゴリズムが定義されている場合はそれらをすべて削除します。
次のパラメータが定義されていないか、アルゴリズムがリストされていない場合は、このステップを省略できます。
SQLNET.ENCRYPTION_TYPES_CLIENT
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT
サーバーのsqlnet.oraファイルで、非推奨になったアルゴリズムが定義されている場合はそれらをすべて削除します。
次のパラメータが定義されていないか、アルゴリズムがリストされていない場合は、このステップを省略できます。
SQLNET.ENCRYPTION_TYPES_SERVER
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER
サーバーのセキュリティを最大にするために、次のsqlnet.oraパラメータを設定します。
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA512)
SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS = FALSE
クライアントのセキュリティを最大にするために、次のsqlnet.oraパラメータを設定します。
SQLNET.ENCRYPTION_CLIENT = REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256)
SQLNET.CRYPTO_CHECKSUM_CLIENT = REQUIRED
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (SHA512)
SQLNET.ALLOW_WEAK_CRYPTO = FALSE
ステップ5および6に従って、非推奨になったすべてのアルゴリズムをサーバーおよびクライアントから削除した後、各クライアントのsqlnet.oraファイルで、クライアントがパッチを適用していないサーバーと通信することを防止できるように、パラメータSQLNET.ALLOW_WEAK_CRYPTO = FALSEを設定します。
SQLNET.ALLOW_WEAK_CRYPTOパラメータがFALSEに設定されている場合、弱いアルゴリズムを使用しようとするクライアントにより、サーバーでORA-12269: client uses weak encryption/crypto-checksumming versionエラーが発生します。弱いアルゴリズムを使用しているサーバー(またはプロキシ)に接続するクライアントは、ORA-12268: server uses weak encryption/crypto-checksumming versionエラーを受け取ります。
ステップ9に従ってすべてのクライアントをSQLNET.ALLOW_WEAK_CRYPTO = FALSEで更新した後、サーバーのsqlnet.oraファイルで、パラメータSQLNET.ALLOW_WEAK_CRYPTO_CLIENTS = FALSEを設定します。このパラメータは、パッチを適用されたサーバーが、パッチを適用されていないクライアントと通信することを防止します。
SQLNET.ALLOW_WEAK_CRYPTOパラメータがFALSEに設定されている場合、弱いアルゴリズムを使用しようとするクライアントにより、サーバーでORA-12269: client uses weak encryption/crypto-checksumming versionエラーが発生します。弱いアルゴリズムを使用しているサーバー(またはプロキシ)に接続するクライアントは、ORA-12268: server uses weak encryption/crypto-checksumming versionエラーを受け取ります。
データベース・リンクを使用する場合、最初のデータベース・サーバーがクライアントとして機能し、2つ目のサーバーに接続します。そのため、すべてのサーバーが完全にパッチを適用され、サポートされていないアルゴリズムが削除されたことを確認してから、SQLNET.ALLOW_WEAK_CRYPTOをFALSEに設定してください。
Oracleは、ネットワーク上のデータを暗号化するために、ネイティブ・ネットワーク暗号化とトランスポート層セキュリティ(TLS)の2つの方法を提供しています。
どちらの方法にもメリットおよびデメリットがあります。
Javaを使用する際は、次の事項に注意してください。
Oracle Database 11gリリース2 (11.2)には、すべての機能を持つJava仮想マシン(JVM)とSun社のJava Development Kit (JDK) 6.0用Javaクラス・ライブラリが組み込まれています。リリース11.2.0.4には、OracleのJDBCおよびSQLJとともに、サーバーベースJavaアプリケーションの開発とデプロイのためのエンタープライズ・クラス・プラットフォームであるOracle JVMが用意されています。次のサイトにあるOracle JVM READMEファイルを参照してください。
ORACLE_HOME/relnotes/readmes/README_javavm.txt
単一のサーバーで構成される環境向けに、Oracle Secure Backup Expressが用意されており、Oracle Databaseおよびその他の重要なOracleインフラストラクチャをテープにバックアップできます。Oracle Secure BackupはRecovery Manager (RMAN)と完全に統合され、データ保護サービスを提供します。より規模の大きな環境では、Oracle Secure Backupをライセンス供与可能な別の製品として使用し、多数のデータベース・サーバーおよびファイル・システムをテープにバックアップできます。Oracle Secure Backupリリース10.4は、Oracle Database 11gリリース2 (11.2.0.4)に同梱されています。Oracle Secure Backupの詳細は、次のサイトを参照してください
http://www.oracle.com/goto/osb/
Oracle Secure Backupには、グローバリゼーションについて次の制限が適用されます。
Oracle Secure BackupのWebツールおよびコマンドライン・インタフェースは英語のみで、グローバル化されていません。すべてのメッセージおよびドキュメントは英語で表示されます。
Oracle Secure Backupでは、Unicode UTF-16などのNULLバイト終了をサポートしないキャラクタ・セットでエンコードされているファイル名やRMANバックアップ名はサポートされません。この制限により影響を受けるのは、バックアップ内容ではなくファイル名であることに注意してください。Oracle Secure Backupでは、Oracle Databaseを任意のキャラクタ・セットでバックアップできます。
Oracle Application Expressの詳細は、『Oracle Application Expressリリース・ノート』および『Oracle Application Expressインストレーション・ガイド』を参照してください。
次の項には、Oracle Automatic Storage Management (Oracle ASM)に関する情報を示します。
Oracle ACFSへのOracleホームの配置は、Oracle Database 11gリリース2 (11.2)からサポートされます(Oracle Bug#10144982を参照)。11.2より前のデータベース・バージョンで、Oracle ACFSにOracleホームを配置しようとすると、Oracle ACFSで、予期しない不適切な動作が発生する可能性があります。
Oracle Automatic Storage Management 11gリリース2 (11.2.0.3)以降では、Oracle ACFSは、RMANバックアップ(BACKUPSETファイル・タイプ)、アーカイブ・ログ(ARCHIVELOGファイル・タイプ)、Data Pumpダンプセット(DUMPSETファイル・タイプ)をサポートします。Oracle ACFSスナップ・ショットでは、これらのファイルはサポートされません。
また、Oracle Automatic Storage Management 11gリリース2 (11.2.0.3)から、Oracle ACFSは、フラッシュ・リカバリ領域で、アーカイブREDOログ、フラッシュバック・ログ、RMANバックアップ(データファイルと制御ファイル)などの一時的なファイルをサポートしています。Oracle ACFSスナップ・ショットでは、これらのファイルはサポートされません。オンラインREDOログや現行の制御ファイルのコピーなどの永続ファイルはサポートされません。
Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)を使用する場合は、次の事項に注意してください。これらは、クラスタ用Oracle Grid Infrastructureのインストールを使用してインストールされます。
Oracle Clusterwareを停止しようとすると、選択したノードでOracle Clusterwareスタックが正常に停止しなかったとレポートされる場合があります(Oracle Bug#8651848を参照)。データベース・ホームがOracle ACFSにある場合は、次のエラーが表示されることがあります。
CRS-5014: Agent orarootagent.bin timed out starting process acfsmount for action
このエラーは無視しても問題ありません。
また、Oracle ACFSリソースを停止できないため、選択したノードでOracle Clusterwareスタックが正常に停止しなかったとレポートされる場合もあります。このエラーが発生した場合は、次の手順を実行します。
プログラムまたはプロセスを停止し、Oracle ACFSマウント・ポイントに対するすべてのファイル・システムのアクティビティが停止していることを確認し、停止操作を再試行します。
ora.registry.acfsリソース・チェック機能がタイムアウトした場合や、リソースがUNKNOWNまたはINTERMEDIATEの状態を示した場合は、Oracle Cluster Registry (OCR)にアクセスできない可能性があります。この原因に共通するのはネットワーク障害です。acfsutil registryコマンドおよびocrcheckコマンドにより、特定のエラーの原因が明確になる場合があります。このエラーを解決し、Oracle Clusterwareの停止を再試行してください。
Oracle MultimediaのREADMEについては、「Oracle Multimedia README」を参照してください。
ORACLE_HOME/ord/im/admin/README.txt
Oracle ODBC DriverのREADMEについては、「Oracle ODBC Driver README」を参照してください。
ORACLE_HOME/odbc/html/ODBCRelnotesUS.htm
Oracle RACを使用する際は、次の事項に注意してください。
Oracle RACデータベースをNFSデバイス上の共有Oracleホームにインストールする場合、ORADISMバイナリ(oradism)を各ノード上のローカル・ディレクトリにコピーする必要があります(Oracle Bug#7210614を参照)。
oradismを移動するには、次の手順を実行します。
ORACLE_HOME/bin/oradismバイナリをすべてのクラスタ・ノード上の同一のディレクトリ・パスにコピーします。パス(手順2の例の/u01/local/binなど)はローカルで、NFSではない必要があります。次に例を示します。
cp -a ORACLE_HOME/bin/oradism /u01/local/bin
次のコマンドをrootユーザーとして実行して、oradism実行可能ファイルの所有権と権限を設定します。
$ chown root /u01/local/bin/oradism $ chmod 4750 /u01/local/bin/oradism
NFS共有ホームからローカルのoradismディレクトリ・パスへのシンボリック・リンクを作成します。作成する必要があるのは1つのノードに対してのみです。これで各ノードは、共有Oracleホームからsymlinkを使用してそのノード独自のoradismを参照できます。次に例を示します。
$ cd /nfs/app/oracle/product/11.2.0/db_1/bin $ rm -f oradism $ ln -s /u01/local/bin/oradism oradism
OracleホームがOracle Databaseホーム・ディレクトリの場合は、extjob、jssu、nmb、nmhs、nmoなどの他のバイナリに対して手順1から3を繰り返します。OracleホームがOracle Grid Infrastructureホーム・ディレクトリの場合は、この手順を実行する必要はありません。
Oracle SpatialのREADMEファイルには、『Oracle Spatial開発者ガイド』、『Oracle Spatialトポロジおよびネットワーク・データ・モデル開発者ガイド』および『Oracle Spatial GeoRaster開発者ガイド』の補足情報が含まれています。Oracle SpatialのREADMEについては、「Oracle Spatial README」を参照してください。
ORACLE_HOME/md/doc/README.txt
Oracle SQL DeveloperのREADMEについては、「Oracle SQL Developer README」を参照してください。
ORACLE_HOME/sqldeveloper/readme.html
Oracle Textを使用する際は、次の事項に注意してください。また、「ドキュメントの追加事項」の『Oracle Textアプリケーション開発者ガイド』の記述も確認してください。
サード・パーティのテクノロジが基になっているOracle Textの一部の機能(AUTO_LEXERやCTX_ENTITYなど)は、リリース11.2.0.4では無効になりました(Oracle Bug#12618046を参照)。BASIC_LEXERでは、サード・パーティのテクノロジに依存するINDEX_STEMS属性値の使用も影響を受けます。これによって既存のアプリケーションに影響がある場合は、Oracleサポート・サービスにお問い合せください。
Oracle Textのナレッジ・ベースは、テーマの索引付け、ABOUT問合せ、およびドキュメント・サービスのテーマを導出するために使用する概念の階層ツリーです。次のOracle Textサービスでは、ナレッジ・ベースがインストールされていることが必要です。
INDEX_THEMES=YESの場合、BASIC_LEXERプリファレンスを使用した索引作成
INDEX_THEMES=YESの場合、索引に対するSYNCの実行
CTX_DOC.THEME
CTX_DOC.POLICY_THEME
CTX_DOC.GIST
CTX_DOC.POLICY_GIST
CTX_QUERY.HFEEDBACK
CTX_QUERY.EXPLAIN (TRANSFORMを指定したABOUTまたはTHEMESを使用する場合)
CTX_DOC.SNIPPET (ABOUT演算子を使用する場合)
CTX_DOC.POLICY_SNIPPET (ABOUT演算子を使用する場合)
TRANSFORMを指定したABOUTまたはTHEMESを使用するCONTAINS問合せ
ナレッジ・ベース拡張コンパイラ(ctxkbtc)
テーマが指定されている場合のクラスタリング・サービスと分類サービス
これらのOracle Text機能を使用するには、OTNからダウンロードできるOracle Database Examplesメディアから、ナレッジ・ベース(英語およびフランス語)をインストールする必要があります。
提供されているナレッジ・ベースを拡張したり、英語やフランス語以外の言語で独自のナレッジ・ベースを作成できます。ナレッジ・ベースの作成と拡張の詳細は、『Oracle Textリファレンス』を参照してください。
Oracle Database Examplesメディアから製品をインストールする方法については、プラットフォーム固有のOracle Database Examplesのインストレーション・ガイドを参照してください。
Oracle XML DBを使用する際は、次の事項に注意してください。
Oracle Database 11gリリース1 (11.1)では、XMLTypeオブジェクトリレーショナルの記憶域で、xdb:storeVarrayAsTableのデフォルト値がFALSE からTRUEに変更されています。このデフォルト値はデフォルト表に適用されますが、スキーマ登録後のXMLTypeオブジェクトリレーショナルの表および列の作成時には適用されません(Oracle Bug#6858659を参照)。Oracle Database 11gリリース2 (11.2)では、デフォルトですべてのVARRAYデータ要素が表として作成されます。これにより、問合せ時のパフォーマンスが大幅に向上します。また、次の点にも注意してください。
11.2より前に作成された表はこの影響を受けません。アップグレード・プロセスによって記憶域パラメータが保持されます。これは、11.2以降で作成される表に適用されます。
VARRAYデータ要素のサイズが小さく、すべてのVARRAYを一度に読取りおよび書込みする場合は、11.2より前のVARRAY記憶域のデフォルト値をLOBとして保持できます。11.2より前の動作に戻すには、2つのオプションがあります。
xdb:storeVarrayAsTable=FALSEでスキーマを再登録します。これにより、デフォルトおよびデフォルト以外の表に適用されます。
表(デフォルト以外の表)を作成する場合は、STORE ALL VARRAYS AS LOBS句を使用して、XMLTypeのすべてのVARRAYデータ要素のデフォルト値を指定の値で優先できます。この句は、表の作成時にのみ使用できます。この句では、スキーマの登録時にtable_propsを使用すると、エラーが返されます。
11.2より前に登録されたスキーマ(VARRAYデータ要素のデフォルトの記憶域がLOBの場合)では、STORE ALL VARRAYS AS TABLES句を使用して、XMLTypeのすべてのVARRAYデータ要素のデフォルト値を指定の値で優先できます。
Oracle Database 11gリリース2 (11.2)のOracle Warehouse Builder (OWB)の詳細は、『Oracle Warehouse Builderリリース・ノート』参照してください。
Pro*CのREADMEについては、「Pro*C/C++ README」を参照してください。
ORACLE_HOME/precomp/doc/proc2/readme.doc
Pro*COBOLのREADMEについては、「Pro*COBOL README」を参照してください。
ORACLE_HOME/precomp/doc/procob2/readme.doc
SQL*Plusの詳細は、SQL*Plusリリース・ノートを参照してください。
この項では、リリース11.2.0.4での既知の不具合を示します。これ以外に、使用しているプラットフォーム固有のリリース・ドキュメントに補足のリストが含まれている場合があります。
Oracle Bug#16929299
ホストで実行されているサーバー・インスタンスの数およびそのメモリー・リソースの使用率によっては、Database Configuration Assistant (DBCA)がメモリー不足に陥り、次のエラーで失敗することがあります。
java.lang.OutOfMemoryError
回避策: DBCAのJavaヒープ・サイズを128MBから256MBに増やします。次に例を示します。
JRE_OPTIONS="${JRE_OPTIONS} -DSET_LAF=${SET_LAF}
-Dsun.java2d.font.DisableAlgorithmicStyles=true
-Dice.pilots.html4.ignoreNonGenericFo nts=true -DDISPLAY=${DISPLAY}
-DJDBC_PROTOCOL=thin -mx256m"
Oracle Bug#16832579
11.2.0.xのOracle Grid Infrastructure環境に10.2.0.4のデータベースが共存していて、11.2のOracleホームと10.2のOracleホームの所有者が異なる場合は、権限の問題により、10.2.0.4のDatabase Configuration Assistant (DBCA)でGridホーム・リスナーを追跡することができません。
回避策: 10.2.0.4のOracleホームからデータベースを構成しているときに、すべてのノードのGridhome/network/adminディレクトリに対して書込み権限を指定します。
Oracle Bug#12762927
削除ツールを使用して共有Oracle RACホームを削除すると、一部のファイルまたはディレクトリが削除されない場合があります。
回避策: ORACLE_HOMEを削除するには、削除ツールの終了後にrm -rf $ORACLE_HOMEコマンドを実行します。
Oracle Bug#9925724
rootが所有するディレクトリのすぐ下にGrid_homeを作成した場合、削除ツールではトップレベルのホーム・ディレクトリを削除できません。削除が終了しても、空のOracleホーム・ディレクトリが残ります。
回避策: すべてのノードでrootユーザーを使用してrmdir ORACLE_HOMEを実行します。
Oracle Bug#8666509
Oracle Clusterwareを削除すると、11.2より前のOracle RACホームをOracleインベントリからデタッチするように求められます。
回避策: アップグレードした11.2 Oracle RACホームを構成解除および削除し、クラスタ用Oracle Grid Infrastructureホームの構成解除および削除を続行する場合は、最初に、11.2より前のOracle RACソフトウェア・ホームを中央のインベントリからデタッチします。
Oracle Bug#8644344
削除ツールを実行してデータベースを削除する場合、Oracleホームを開いてコンポーネントを選択するように求められます。トップ・レベル・コンポーネント(Oracle Database Server)を選択して、Oracleホームを選択しないと、削除ユーティリティを実行してデータベースの削除を続行するように求めるメッセージがOUIに表示されません。
回避策: 削除ツールを実行してOracleホームを削除します。
Oracle Bug#8635356
共有NFS記憶域にインストールされているORACLE_HOMEから削除ツールを実行している場合は、ORACLE_HOMEのクリーンアップ中に.nfsファイルに関連するエラーが表示されます。
回避策: ORACLE_HOMEを削除するには、削除ツールの終了後にrm -rf ORACLE_HOMEコマンドを実行します。また、スタンドアロンのdeinstall.zipを使用してORACLE_HOMEの場所を指定することもできます。
Oracle Bug#12881572
Oracle ASMリリース10.1.0.5から単一インスタンスの高可用性(SIHA)リリース11.2.0.4へのアップグレード中、rootupgrade.shスクリプトが次のエラーを返します。
<ORACLE_HOME>/bin/crsctl query crs activeversion ... failed rc=4 with message: Unexpected parameter: crs
回避策: このエラーは無視しても問題ありません。
Oracle Bug#12332603
Cluster Ready Services (CRS)がすべてのノードで停止した場合、Oracle Automatic Storage Management (Oracle ASM)はローリング移行の状態を失います。これが発生した場合、Oracle ASMのいずれかのバージョンが、ORA-15153またはORA-15163のエラー・メッセージで失敗します。
回避策: リリース11.2.0.3をリリース11.2.0.4にアップグレードしている4つのノード(node1、node2、node3、node4)での次のようなシナリオを考えます。
node1とnode2は11.2.0.4にアップグレードされて、稼働しています。
node3とnode 4はまだ11.2.0.3で、稼働しています。
ここで停止が発生し、すべてのCRSスタックがダウンして、クラスタが異種混合状態のままになるものとします(つまり、2つのノードは11.2.0.3で、2つのノードは11.2.0.4)。
アップグレードを続行するには、(最初のノードとして開始されたノードに応じて)次のいずれかの手順を実行します。
node3またはnode4が最初のノードとして開始された場合は(たとえば、11.2.0.3ノードとして)、11.2.0.4ノードを起動する前に、node3またはnode4上のOracle ASMインスタンスで、ALTER SYSTEM START ROLLING MIGRATION TO '11.2.0.4'コマンドを実行する必要があります。
node1またはnode2が最初のノードとして開始された場合は、11.2.0.3ノードを起動する前に、node1またはnode2上のOracle ASMインスタンスで、ALTER SYSTEM START ROLLING MIGRATION TO '11.2.0.3'コマンドを実行する必要があります。
この時点からは、すでに説明されているようにアップグレード手順を続行します。前述のいずれかの手順を実行して、Oracle ASMクラスタをローリング移行に戻すまで、クラスタ内で異なるバージョンの2つのノードを起動できないことに注意してください。起動すると、Oracle ASMのいずれかのバージョンが、ORA-15153またはORA-15163のエラー・メッセージで失敗します。
Oracle Bug#9413827
Oracle Cluster Registry (OCR)がOracle ASMにある場合、11.2.0.1 Oracle Clusterwareの11.2.0.4へのローリング・アップグレードが失敗します。
回避策: アップグレードを実行する前に、11.2.0.1クラスタ用Oracle Grid InfrastructureホームでOracle Bug#9413827用のパッチを適用します。
Oracle Bug#9276692
Oracle ASMインスタンスを完全に停止できません。
回避策: SRVCTLを使用してOracle ASMインスタンスが無効にされた場合は、Oracle ASMインスタンスが再起動されないようにOracle ACFS関連リソースの登録を解除する必要があります。そのためには、次のコマンドをrootとして実行します。
acfsroot disable
Oracle Bug#9683229
Oracle ADVMでは、マウント・バリア・オプションを有効化した状態でOracle ADVMを介してext3ファイル・システムをマウントすることはサポートされていません。SLES11では、マウント・バリア・オプションがデフォルトで有効化されます。
回避策: ext3ファイル・システムを-o barrier=1でマウントします。次に例を示します。
mount -o barrier=0 /dev/asm/myvol-131 /mnt
Oracle Bug#19668256
OracleベースがOracle ACFSマウント・ポイント内にある場合、アンインストール・ツールによってOracle ACFSマウント・ポイントが削除されます。
回避策: Oracle ACFSマウント・ポイントの外側の場所をOracleベースの場所として選択します。
Oracle Bug#16988224
Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)・レプリケーションが構成されたローリング・アップグレードの後、クラスタ内で一部のレプリケーション・デーモンが実行されないことがあります。これは、次のコマンドを実行して確認できます。
crsctl stat res -w "TYPE = ora.acfsrepltransport.type"
レプリケートされたOracle ACFSファイル・システムがマウントされているノードでトランスポート・デーモンが実行されない場合、アップグレードの完了後にすべてのノードでファイル・システムをアンマウントしてから再マウントする必要があります。同じコマンドを再度実行して、デーモンが実行していることを確認します。
回避策: ありません。
Oracle Bug#15944411
Oracle ACFSファイル・システムのサイズ変更の5回目の試行で、次のエラーが返されます。
ACFS-03008: The Volume Could Not Be Resized At the 5th attempt
回避策: compatible.advm属性を11.2.0.4に設定します。compatible.advm属性を11.2.0.4に設定すると、Oracle ACFSファイル・システムの無制限のサイズ変更がサポートされます。
Oracle Bug#12690672
11.2.0.4より前のリリースでは、データベース・ホームをOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)に配置できます。データベース・ホームがOracle ACFSファイル・システム上にある場合、データベースとそれに対応するOracle ACFSファイル・システムの間には起動および停止の強い依存関係があります。
Oracle Grid InfrastructureまたはOracle RACをリリース11.2.0.4にアップグレードした後、データベースと以前のバージョンのデータベース・ホームを格納していたOracle ACFSファイル・システムの間の依存関係は削除されません。
以前のバージョンのデータベース・ホームを格納するために使用されていたものとは異なるOracle ACFSファイル・システムを使用すると、データベースは起動できません。
回避策: データベースをアップグレードした後、データベース・ホームに異なるOracle ACFSファイル・システムを使用する場合は、データベース用に使用しているOracle ACFSファイル・システムのリストを確認し、srvctl modify database -d db_unique_name -j acfs_path_listコマンド(srvctl modify filesystem -j filesystem-listコマンドではなく)を使用して、ファイル・システムに対するデータベースの依存関係を更新することをお薦めします。
Oracle Bug#10104766
非常に大規模な共有Oracle ACFSディレクトリのlsコマンドがハングする場合があります(そのディレクトリからファイルを削除していた場合も含みます)。
回避策: compatible.advm属性を11.2.0.4に設定します。
compatible.advm属性をアップグレードした後、新しく作成したディレクトリでパフォーマンスが改善します。必要に応じて、compatible.advm属性の変更前に作成したファイルを、新しく作成したディレクトリにコピーできます。
Oracle Bug#10069735
パスワードで保護されたキーストアを使用するクラスタでは、暗号化を使用するOracle ACFSファイル・システムがOracle ACFSマウント・レジストリによってマウントされていると、管理者はキーストアのパスワードの入力を求められません。ファイル・システムをマウントする処理は正常に行われても、Oracle ACFSの暗号化が正しく動作するために必要な一部の情報を、ファイル・システムで使用できません。この場合、このファイル・システムでは暗号化は動作せず、ファイル・システムに含まれる暗号化されたファイルは、書き込むことも読み取ることもできません。
回避策: パスワードで保護されたキーストアを使用するクラスタでは、暗号化を使用するファイル・システムのマウントに、Oracle ACFSマウント・レジストリを使用しないでください。Oracle ACFSマウント・レジストリを使用してマウントされたファイル・システムがすでにある場合は、そのようなファイル・システムをアンマウントし、マウント・レジストリから削除して、後で暗号化されたデータが使用できなくなることがないようにしてください。その後、Oracle ACFSマウント・レジストリを使用しないでファイル・システムを再マウントし、リクエストされたら正しいパスワードを入力します。
Oracle Bug#8644639
Oracle ACFSマウント・ポイントを作成してレジストリに追加する場合、次の条件に該当すると、マウント・ポイントは自動的にマウントされません。
マウント・ポイントのディレクトリがOracle ACFSレジストリで登録済である。
マウント・ポイントのディレクトリがマウント済である。
マウント・ポイントがアンマウントされ、Oracle ACFSレジストリから削除されている。
レジストリからマウント・ポイントが削除されてから、ora.registry.acfsリソースが再起動されていない。
回避策: /tmp/.usm_state_fileファイルからマウント・ポイントのディレクトリを削除します。
Oracle Bug#17279427
クラスタウェアのインストールの一環としてroot.shまたはrootupgrade.shが実行されたときにJAVA_HOME環境変数がユーザー環境変数に設定されていると、Oracle Trace File Analyzer (TFA)のインストールが失敗します。次のメッセージが返されます。
You should not use any other parameters with -crshome will be seen in the root script log file.
回避策: この問題は、クラスタウェアのインストールまたはアップグレードでrootスクリプトの実行前にJAVA_HOMEが設定されないようにするか、最新のTFAをMy Oracle Supportのノート1513912.1 (https://support.oracle.com)からダウンロードすることで対応できます。
Oracle Bug#17227707
Oracle Trace File Analyzer (TFA)は、コレクション・ディレクトリとコレクション・ファイルのネーミングに日付とタイムスタンプを使用します。一部の非英語環境ではオペレーティング・システムのdateコマンドを使用すると、想定外のキャラクタが戻され、ディレクトリおよびファイルの名前に使用されることがあります。
回避策: この問題は、tfactl diagcollectをコールする前に環境変数LC_ALL=Cをエクスポートするか、または最新のTFAをMy Oracle Supportのノート1513912.1 (https://support.oracle.com)からダウンロードすることで対応できます。
Oracle Bug#17181902
Oracle Grid Infrastructureをリリース11.2.0.4にアップグレードした後、11.2以前のリリースのサービス・リソースがOFFLINEになることがあります。
回避策: 次のコマンドを使用して、OFFLINEのサービス・リソースを手動で起動します。
$ORACLE_HOME/bin/srvctl start service -d <dbname> -s <srvname> -i <instname>
Oracle Bug#17027888
メッセージの送信中にOCRマスターが停止すると、PEマスター以外のノード上のクラスタ・レディ・サービス・デーモン(CRSD)がハングしてOracle Cluster Registry (OCR)リクエストの処理を停止する場合があります。
回避策: CRSDプロセスを再起動します。
Oracle Bug#16914379
Oracle Grid InfrastructureをOracle Database 11gリリース2 (11.2.0.4)からOracle Database 12cリリース1 (12.1)にアップグレードしようとすると、Oracle ACFSまたはOracle ADVMリソースを停止できないために処理が失敗します。
回避策: SRVCTLまたはCRSCTLを使用してリソースを手動で停止し、アップグレードを再試行します。
Oracle Bug#16825359
Cluster Health Monitor (CHM)リポジトリを以前のディレクトリに再配置しようとすると次のエラーが返されます。
CRS-9114-Cluster Health Monitor repository location change failed on one or more nodes.Aborting location change.
回避策: 以前のサブディレクトリ(<hostname>, <hostname>bkp)をアーカイブまたは削除してから再試行します。
Oracle Bug#16592535
10.1.0.5のクラスタ・レディ・サービス(CRS)を11.2.0.4にアップグレードする際、パッチ3841387が必須ですが、クラスタ検証ユーティリティ(CVU)の前提条件チェックではその要件がチェックされません。そのため、パッチが適用されていなくてもCVUはエラーを発行しません。
回避策: アップグレードを進める前に、opatch lsinventoryコマンドを使用してパッチ3841387を10.1.0.5のソース・ホームに手動で確実に適用します。
Oracle Bug#13110641
グリッド・ネーミング・サービス(GNS)とともに構成されているクラスタにOracle RACソフトウェアをインストールしているときに、GNSが正常に動作していても、前提条件のページにGNS整合チェックの警告ステータスが表示される場合があります。
このメッセージには次のようなものがあります。
PRVF-5217 : An error occurred while trying to look up IP address for "<gns-subdomain-extended-name>"
回避策: エラー・メッセージにリストされている完全修飾名に対して、nslookupを実行します。nslookupから非認証応答とともにその名前のIPアドレスが戻された場合は、この警告は無視してかまいません。名前がIPアドレスに解決されなかった場合は、エラー・メッセージの「処置」に記されている手順に従ってください。
Oracle Bug#13073882
Oracle Grid Infrastructureをリリース11.2.0.4にアップグレードした後、11.2以前のリリースのサービス・リソースがOFFLINEになることがあります。
回避策: 次のコマンドを使用して、OFFLINEのサービス・リソースを手動で起動します。
srvctl start service -d <dbname> -s <srvname> -i <instname>
Oracle Bug#13033342
Oracle RAC環境でOracle ASM 10.2.xからOracle Grid Infrastructure 11.2.xまたはOracle ASM 11.2.xにアップグレードした後、ノード追加操作を実行する前に、ディスク・グループでPFILEをSPFILEに移動する必要があります(そうしないと、正しい初期化パラメータ・ファイルを検索できません)。
回避策: ありません。
Oracle Bug#12900070
Oracle Clusterwareのアップグレードを準備する際に、Cluster検証ユーティリティ(CVU)のコマンドruncluvfy.sh stage -pre crsinst -upgradeを使用すると、次のエラーが発生する場合があります。
Unable to retrieve nodelist from Oracle Clusterware
このエラーの原因は、olsnodesはOracle Clusterwareが停止しているときにノードのリストを返せないことです。
回避策: -nフラグを使用してcluvfy.sh stage crsinst -upgradeコマンドを実行し、クラスタ・メンバー・ノードのカンマ区切りリストを提供します。次に例を示します。
runcluvfy.sh stage -pre crsinst -upgrade -n node1, node2, node3
Oracle Bug#12769576
11.2.0.3では、クラスタ状態モニター(CHM)・リポジトリのデフォルトのRETENTION_TIMEサイズ(秒単位)は、4ノード・クラスタの場合は30823、他のクラスタの場合は(30823*4)をノードの数で割った値です。11.2.0.3から11.2.0.4にアップグレードすると、RETENTION_TIMEは4ノード・クラスタの場合は6311になります。
回避策: 11.2.0.3から11.2.0.4にアップグレードした後、次のoclumonコマンドを使用して、4ノード・クラスタのRETENTION_TIMEサイズを6311から30823に変更することをお薦めします。
oclumon manage -repos resize 30823
Oracle Bug#8733944
リリース11.1.0.7からのOracle Clusterwareで、Oracle Exadataサポートに必要なパッチまたは11.1.0.7 CRSバンドル・パッチ1を適用すると発生する問題のため、停止コマンドまたは障害により別のノードでクラスタウェアが停止すると、CSSデーモンが停止する場合があります。
この兆候としては、最大値を超えていることを示す、CSSDログのASSERTです。次に例を示します。
Group ID of xxxx exceeds max value for global groups
回避策: Oracle Exadataサポート・パッチまたは11.1.0.7 CRSバンドル・パッチ1を実行している場合、この問題を解決するには、この不具合用のパッチを適用することをお薦めします。
この問題は、前述のパッチを使用して11.1.0.7からアップグレードする際にも発生する場合があります。アップグレード時に11.1.0.7のノードが停止する潜在的な問題を排除するには、この不具合用のパッチをアップグレード前に11.1.0.7のノードに適用します。
アップグレードする場合は、アップグレード時にアップグレードされなかったノードを再起動せずに、すべてのノードでアップグレードを完了しておくことをお薦めします。アップグレードの実行中に11.1.0.7のノードが停止する場合は、再起動しないでアップグレードしてください。
Oracle Bug#8657184
2つのネットワーク・インタフェースがクラスタ内でパブリック・ネットワーク・インタフェースとして構成されており、一方のノードのパブリック・インタフェースに障害が発生した場合に、もう一方のパブリック・インタフェースにVIPが自動的にフェイルオーバーされません。
回避策: 複数のパブリック・ネットワーク・インタフェースが存在する場合は、高可用性のためにインタフェースの結合を使用します。Oracle Clusterwareインストーラの「ネットワーク・インタフェースの使用方法の指定」画面で、パブリックとして1つの(結合された)インタフェースのみを選択します。srvctl add nodeappsまたはsrvctl add vipでパブリック・ネットワークを構成する場合は、-Aまたは-S引数に1つのネットワーク・インタフェース名のみを指定します。
Oracle Bug#8641798
注意: Oracle Bug#3841387、8262786、8373758、8406545および8441769も参照してください。
Oracle Clusterwareを11.2にアップグレードすると、10.1、10.2および11.1のOracle RACデータベースのOracleリソースが正常に動作しない場合があります。
回避策: ここに示すいずれかの不具合のパッチをOracle Databaseホームに適用します。
Oracle Bug#12914730
カスタム・ネットワーク構成が、リリース11.2.0.4へのOracle RACデータベースのアップグレードに継承されません。
回避策: ソースOracleホームからターゲットOracleホームに設定を手動でコピーして、カスタム・ネットワーク構成を再度行う必要があります。
Oracle Bug#8341283
成功または失敗時に監査するように監査オプションが設定されている場合、DVSYS.AUDIT_TRAIL$表のACTION_NAMEエントリに、失敗したレルム強制のRealm Authorization Auditが表示されます。RETURNCODEには、トリガーされた正しいエラー・コードが表示されます。
回避策: 違反が発生しているかどうかをRETURNCODE値を使用して判断し、レルム強制またはコマンド・ルール強制によって監査が生成されたかどうかをACTION_NAME列を使用して特定します。
Oracle Bug#7118790
Oracle Database 11gリリース2 (11.2.0.4)より前は、Oracle Database Vault環境でORADEBUGの使用を制御するメカニズムがありませんでした。
回避策: DVSYS.DBMS_MACADM.ENABLE_ORADEBUGおよびDVSYS.DBMS_MACADM.DISABLE_ORADEBUGプロシージャを使用して、ORADEBUGの使用を制限できます。
Oracle Bug#12792222
この不具合は、Oracle Database QoS Managementによって管理されるCPUリソースの推奨事項に対するものです。サーバー上のすべてのインスタンスに対して構成されているCPUの数が、そのサーバーの物理CPUの数より少ない場合、割り当てられていない(空いている) CPUがOracle Database QoS Managementによって検出されず、構成されているCPUの数を増やすことを薦める推奨が行われません。データベースをホストしているスライスだけが、ターゲット・スライスに対するドナーとして考慮されます。割り当てられていないいずれかのCPUの追加が、最高ランクのCPU移動アクションである必要があります。
回避策: 各サーバーで各データベース・インスタンスに対して構成されているCPU数の合計が、物理的なCPUの数と同じであることを確認します。
Oracle Bug#12767103
分類子に複数のサービスが含まれるパフォーマンス・クラスを作成し、これらのサービスがすべて同じサーバー・プールで実行するように指定されていない場合、Enterprise Manager Quality of Service (QoS)管理パフォーマンス・クラス詳細ページでのそのパフォーマンス・クラスのメトリック・グラフが正しくありません。リソース使用時間グラフおよびリソース待機時間グラフには、1つのサーバー・プールからのメトリックのみが表示されます。他のグラフには、すべてのサーバー・プールからのメトリックが正しく表示されます。
回避策: この不具合は、このタイプのパフォーマンス・クラスに関連する正しい管理または推奨アクションには影響しません。
Oracle Bug#20720667
Oracle Direct NFS (dNFS)を有効にして実行中の場合、バックアップ・ファイルまたはOracle Data Pumpファイル用に、ネットワーク・ファイル・システム(NFS)プロトコル・デバイスを使用できます。これらのファイルは常にデータベースによって使用されるわけではないため、NFS管理変更を実行して、NFSボリュームをアンマウントし、同じマウント・ポイントに再マウントできます。この修正がない場合、dNFSがシステム・グローバル領域(SGA)のキャッシュ・ファイル・ハンドルを使用するため、古いまたは不良ファイル・ハンドル・エラーが発生する可能性があります。UNMOUNTVOLUMEプロシージャで、SGAのキャッシュ・ファイル・ハンドルをクリーンアップできます。
UNMOUNTVOLUMEプロシージャは、SGAのキャッシュNFSファイル・ハンドルをクリーンアップし、これは、オペレーティング・システムを使用してNFSマウント変更が行われるとき、およびオペレーティング・システムのUNMOUNTおよびMOUNTコマンドが起動されるときに使用する必要があります。UNMOUNTVOLUMEプロシージャは、dNFSクライアントに対するオペレーティング・システムのUNMOUNTコマンドと同等です。
回避策: SGAにキャッシュされた古いファイル・ハンドルがデータベース起動の一部としてクリーンアップされるように、データベースを再起動します。
Oracle Bug#20511726
データベース・ディレクトリ名に、エラー・メッセージの接頭辞コード(TNS、ORAなど)が含まれていてはいけません。Oracle Enterprise Managerでのトラブルの原因となります。
回避策: ありません。
Oracle Bug#16386142
インストーラは、ソース・ファイルでの権限を保護するために-pオプションを使用して、一時的なブートストラップ先(通常は/tmp)にファイルをコピーします。ソースおよびターゲットのファイル・システムが同じACLオプションでマウントされていない場合、ターゲットのファイル・システムで権限を保持できないため、次のエラーでコピーが失敗します。
[INS-30060] Check for group existence failed.
回避策: 取り得る回避策には次の3つがあります。
同じACLオプションを使用して、ソース・ファイル・システムと/tmpディレクトリのファイル・システムをマウントします。
noaclオプションを使用して、ソース・ソフトウェアがあるファイル・システムをマウントします。
インストール・ソフトウェアを/tmpディレクトリにコピーし、インストールを再試行します。
|
注意: この問題は、ソフトウェア(zipファイル1および2)が同じ場所に展開されていないとき、またはインストール中にOSOPERグループが指定されたときに発生します。 |
Oracle Bug#9859532
ノード固有ネットワーク・インタフェースの現在の実装では、そのノードに対してOracle RACが使用するすべてのネットワークの完全な定義が必要です(つまり、ノードがグローバル・ネットワーク構成に従っているか、またはノードでノード固有のネットワーク構成が定義されていることが必要です)。
そのため、最初のノード固有ネットワーク・インタフェースが特定のノードに対して定義されると、Oracle RACは、すでに構成されていて、同じノードに適用されている可能性のある構成済のグローバル・ネットワーク・インタフェースを考慮しません。
これは正しい動作ですが、問題があります。クラスタに動作しているグローバル・ネットワーク構成がある場合、ユーザーが(oifcfgを使用して)それを更新し、ノード固有のpublicインタフェースを定義するときには、グローバル構成はそのノードに対して考慮されず、ノードは新しく定義されたpublicインタフェースを1つだけ持つようになります。グローバル・ネットワーク構成に存在し、このノードに対してまだ正常に解決を行う可能性のあるすべてのクラスタ・インターコネクトは、有効とは見なされなくなります。したがって、ノードはクラスタ・インターコネクトを失い、PCWスタックはそのノードで停止します。
回避策: ノードがグローバル・クラスタ・ネットワーク構成に属していて、ネットワーク構成をノード固有にする場合は、最初のノード固有インタフェースとしてクラスタ・インターコネクトを定義し、他のクラスタ・ノードとのインターコネクトをノードが失わないようにする必要があります。その後は、必要に応じて他のノード固有インタフェースを定義できます。
Oracle Bug#8729627
11.1のDBCAを使用して、11.2のOracle Clusterwareを実行しているクラスタでデータベースを削除する場合、データベース・リソースがロックされるためにPRKP-1061/CRS-2524エラーが表示される場合があります。
回避策: このメッセージは無視しても問題ありません。「OK」をクリックして続行します。
Oracle Bug#16706199
クラスタ・レディ・サービス(CRS)をOracle Enterprise Manager Cloud Control (Cloud Control)向けにアップグレードしても、クラスタ・ターゲットのOracleホームの値が変更されません。
回避策: 次の手順に示すとおり、Oracle Enterprise Manager Grid ControlまたはOracle Enterprise Manager Cloud Controlでクラスタ・ターゲットのプロパティをクラスタとその関連ターゲットに合わせて変更します。
「ターゲット」ページで「すべてのターゲット」をクリックします。
ターゲットを選択します。
ターゲットのメニュー項目を選択し、「ターゲット設定」、次に「監視構成」をクリックします。
「監視構成」ページで、アップグレードした「クラスタウェアのOracleホーム」に「Oracleホームのパス」を設定します。
Oracle Bug#12793336
Oracle ASM構成アシスタント(ASMCA)を使用してCluster Ready Services (CRS)またはOracle ASMをリリース11.2にアップグレードしようとすると、アップグレードは成功しますが、権限の問題により、既存のエージェント・ホーム内のクラスタ・ターゲットに対する新しいクラスタウェア・ホームの更新が失敗することがあります。その結果、Oracle Enterprise Manager Grid ControlおよびDatabase ControlはOracle ASMおよびCRSターゲットを監視できません。
回避策: ASMのホームページとクラスタのホームページにある「モニタリング構成」リンクを使用して、Oracle ASMおよびクラスタのターゲットのOracleHomeプロパティをそれぞれに変更します。
Oracle Bug#9766628
emctlコマンドが有効な結果を返しません。
回避策: emctlコマンドはOracle Databaseホームから実行する必要があります。クラスタ用Oracle Grid Infrastructureホームからこのコマンドを呼び出さないでください。
Oracle Bug#8674920
クラスタ用Oracle Grid InfrastructureとOracle Databaseのインストール所有者が異なる場合は、Oracle ASMバイナリとOracle Enterprise Managerエージェント・バイナリの所有者も異なります。サポート・ワークベンチを起動すると、エラー・メッセージError Operation failed - Operation failedが表示されます。これは、別のユーザーとしてOracle Enterprise Managerエージェントが実行されており、サポート・ワークベンチにOracle ASMターゲットの権限がないためです。
回避策: ありません。
Oracle Bug#9917299
インストール・キットで提供されているシードを使用してデータベースがインストールされていて、OLAPオプションが選択されていない場合、インストールの終了時またはしばらくしてから、OLAP Analytic WorkspaceおよびOLAP APIコンポーネントが無効と報告されます。
エラー・メッセージを除くと、これによるインスタンスの実行への影響は何もありません。
回避策: 次のいずれかを行います。
エラーを無視します。
OLAP (または問題のあるオプション)を有効にします。
OLAPを含まない独自のシード・データベースを作成して使用します。
Oracle Bug#9545221
ソース表がターゲット・スキーマの一部ではないマテリアライズド・ビューが有効なキューブまたはキューブ・ディメンションをインポートすると、「Object not found」というエラーで失敗します。
回避策: インポートの前に失敗したオブジェクトに対するマテリアライズド・ビューを無効にし、ソース表が存在するようになったら再び有効にします。
Oracle Bug#17210454
Oracle Real Application Clusters (Oracle RAC)の構成監査ツール(RACcheck)を英語以外の環境で実行すると、/tmpディレクトリに利用可能な領域が十分にある場合でも利用可能な領域のエラーが戻されます。
回避策: この問題を回避するには、My Oracle Supportのノート1268927.1 (https://support.oracle.com)から最新のRACcheckをダウンロードします。
Oracle Bug#16233295
11.2.x.xから11.2.0.4にアップグレードする際、カスタマイズされたリスナー構成が設定されている場合(リモート・リスナーなど)、Database Upgrade Assistant (DBUA)によってデフォルトに戻されます。
回避策: データベースをアップグレードした後に、SQL*PlusからALTER SYSTEM SET REMOTE_LISTENER=<user_remote_listener_setting>, ... SCOPE=BOTHを実行します。
Oracle Bug#9301862
外部表コードがNFSによって提供されるディスク上の非常に大きいファイルを読み取るとき、時間とともに読取りのI/Oパフォーマンスが低下する場合があります。これは、NFSがファイルから読み取ったブロックをメモリーにキャッシュすることが原因です。これらのブロックは再度読み取られることがないので、キャッシュの維持に費やされる時間によってI/O操作が遅くなります。
回避策: (O_DIRECTフラグを使用しない)現在の動作はデフォルトのままです。次に示す方法で、O_DIRECTフラグの使用を有効にできます。
この不具合に対する修正コントロールを有効にし、次のコマンドを使用してONに設定します。
ALTER SESSION SET "_fix_control"='9301862:ON';
修正コントロールを有効にすると、外部表コードはFILESYSTEMIO_OPTIONS構成パラメータを調べて、DIRECTIOまたはSETALLに設定されている場合は、読取り用にデータファイルを開くときに、ORACLE_LOADERアクセス・ドライバでO_DIRECTフラグを指定します。FILESYSTEMIO_OPTIONSパラメータが設定されていない場合、または他の値に設定されている場合は、ユーザーが次のオプションを選択しないかぎり、アクセス・ドライバはO_DIRECTの使用を試みません。
アクセス・ドライバで新しいIO_OPTIONS句を使用して、直接I/Oを指定します。この句は、さらに大きなRECORDS句の一部です。構文は次のとおりです。
IO_OPTIONS (DIRECTIO | NODIRECTIO)
DIRECTIOを指定した場合、アクセス・ドライバはファイルを開くときにO_DIRECTフラグを使用します。NODIRECTIOを指定した場合、アクセス・ドライバはO_DIRECTフラグを使用しません。IO_OPTIONSによって指定されるアクションは、この不具合に対する_fix_controlの設定に関係なく実行されることに注意してください。
1番目のオプションがすべての外部表に対してO_DIRECTの使用を有効にする方法であるのに対し、2番目のオプションでは特定の外部表に対してDIRECTIOを使用することも、使用しないこともできます。
Oracle Bug#17533350
32ビットのOracle Databaseクライアント・ソフトウェアを64ビット・アーキテクチャのサーバーにインストールする場合、Oracleベースを、他の64ビットOracle Database製品ソフトウェアの保護されたOracleベースと同じにすることはできません。
64ビットOracle Database製品ソフトウェアをインストールする場合、Oracleベースを、32ビットのOracle Databaseクライアント・ソフトウェアの保護されたOracleベースと同じにすることはできません。
回避策: ありません。
Oracle Bug#17085615
ローカル・ノードのみを削除しているとき、次のメッセージは無視しても問題ありません。
回避策: ありません。
Oracle Bug#17008903
11.2.0.4のOracle Grid Infrastructureをインストールするときに、十分な権限がないディスクがあるノード上でroot.shが失敗したことが原因でリモート・ノード上の権限が不十分なOracle ASMディスクが選択された場合でも、Oracle Universal Installer (OUI)は検証とレポートを行いません。
回避策: リモート・ノードにある権限が不十分なOracle ASMディスクが選択されないようにします。クラスタ検証ユーティリティ(CVU)ツールを使用して、リモート・ノードのディスクに十分な権限があることを検証できます。
Oracle Bug#16930240
11.2.0.2または11.2.0.3のOracle Grid Infrastructureを11.2.0.4.0にアップグレードするとき、1,000を超えるデータベース・サービス・リソースが登録されている場合に、Server Management (SRVM)モデルをアップグレードしようとすると、rootスクリプトが1番目のノードで停止するためにアップグレードが失敗します。
回避策: アップグレードを開始する前に、11.2.0.2または11.2.0.3のOracle Grid InfrastructureホームでOracle Bug#16684285用のパッチを手動で適用します。
Oracle Bug#16842099
データベースがOracle Universal Installer (OUI)を使用して構成されている場合、VKTM/LMSプロセスが誤った優先度で実行されます。
回避策: インストール完了後にデータベースを停止した後、起動します。
Oracle Bug#13028836
現在のノードまたはローカル・ノード上でのみ、セキュア・シェル(SSH)設定コードによってユーザーのホーム・ディレクトリ権限が755に変更されます。
回避策: SSHがローカル・ノードで一部のSSH関連操作を行うにはこの権限が必要であるため、これは必要な動作です。
Oracle Bug#13012502
Oracle Database ClientまたはOracle Database Examplesソフトウェアで追加されたOracleホームをクローニングすると、データベースの作成に失敗します。
回避策: クローニング操作中に、『Oracle Databaseインストレーション・ガイドfor Linux』で指定されているとおりに権限付きのオペレーティング・システム・グループ(OSDBA_GROUPとOSOPER_GROUP)の値を入力します。
Oracle Bug#12930328
クラスタのノードによって中央のインベントリの場所が異なる場合、addnode.shではクラスタのリモート・ノードのインベントリが正しく更新されません。
回避策: クラスタにノードを追加するには、クラスタのすべてのノードで中央のインベントリの場所が同じであることが必要です。addnode.shを実行する前に、そのようになっていることを確認してください。
Oracle Bug#12711224
Oracle Universal Installer (OUI)が、ノードの再起動中、またはrootupgradeスクリプトの実行中にクラッシュした場合、OUIはアップグレード後のタスクを再開できません。
回避策: 次のタスクを手動で処理し、アップグレードを完了する必要があります。
11.2より前から11.2.0.4リリースにアップグレードしている場合:
インベントリの更新
Orace Net Configuration Assistant
自動ストレージ管理構成アシスタント
Enterprise Managerの構成アップグレード・ユーティリティ
Oracleクラスタ検証ユーティリティ
11.2以降から11.2.0.4リリースにアップグレードしている場合:
インベントリの更新
Enterprise Managerの構成アップグレード・ユーティリティ
Oracleクラスタ検証ユーティリティ
Oracle Bug#8729326
11.2のClusterwareにアップグレードする場合、インストーラはASMCAをサイレント・モードで起動し、Oracle ASMをクラスタ用Oracle Grid Infrastructureホームにアップグレードします。11.1.0.7からアップグレードする際、Oracle ASMアップグレードはローリング方式で処理されます。前のバージョンのOracle ASMインスタンスは、ローリング方式以外の方法でアップグレードされ、Oracle ASMベースのデータベースは警告なしでバウンスされます。
回避策: すべてのノードでroot.shを実行してから、インストーラによるプロンプトを確認できる時点まで、データベースの停止を計画できます。この時点で、CRSはローリング方式でアップグレードされ、インストーラはASMCAをコールしてOracle ASMをアップグレードします。これにより、データベースはOracle ASMアップグレードの一部としてバウンスされます。
Oracle Bug#8666656
Oracleホーム(ORACLE_HOME/oui/bin/runInstaller)にあるOracle Universal Installer (OUI)のrunInstallerスクリプトでは、11.2.0.1リリースのOracle Database、クラスタ用Oracle Grid InfrastructureおよびOracle Databaseクライアントをインストールできません。
回避策: それぞれの11.2.0.1.0製品メディアのOracle Universal Installerを使用して製品をインストールします。
Oracle Bug#8638708
Oracle Universal Installer (OUI)のデータベース構成「デスクトップ・クラス」を選択すると、リスナーおよびデータベース制御は、ホスト名として'localhost'で構成されます。Oracle Enterprise Manager Database Controlのemctlを使用したstartおよびstop操作が失敗する場合があります。
回避策: 該当のホームでemctlを使用するDatabase Controlの起動および停止操作では、ORACLE_HOSTNAME環境変数を'localhost'に設定します。
Oracle Bug#8407818
addNode.shを使用して、共有Oracle Databaseホームに新しいノードを追加すると、新しく追加したノードの/etc/oratabに、addNode.shの実行元のソース・ノードに存在するソース・データベース名のエントリが入ります。DBCAを使用して新しいノードでデータベース・インスタンスが追加されると、新しいノードの/etc/oratabファイルにデータベース・エントリが入ります。
回避策: ソース・ノードからDBCAを起動して、新しいノードでデータベース・インスタンスを新しく追加する前に、エディタを使用して新しいノードで/etc/oratabファイルを開き、ソース・データベース名のエントリを削除します。
Oracle Bug#17215306
次のエラーが発生する場合があります。
ORA-600 [QMXPTREWRITEFRO1]
回避策: XMLTABLE()問合せを使用していてこのエラーが発生した場合、この不具合の修正をBLRにリクエストするか、または次のコマンドを使用します。
ALTER SESSION SET EVENTS '19120 TRACE NAME CONTEXT FOREVER, LEVEL 0x10000000'
Oracle Bug#16069266
トランスポータブル表領域(TTS)を使用してバイナリXMLデータを含んだ表をエクスポートまたはインポートする操作はサポートされていません。
回避策: Oracle Data Pumpの従来のパスを使用してデータを移動します。
Oracle Bug#12834970
リリース11.2.0.3以降、MOVEXDB_TABLESPACEおよびREBUILDHIERARCHICALINDEXプロシージャはDBMS_XDBパッケージからDBMS_XDB_ADMINパッケージに移動されました。これらのプロシージャは、DBMS_XDBパッケージでは使用できなくなりました。
回避策: ありません。
Oracle Bug#9586264
XMLQUERYまたはXMLTABLE問合せを完全に最適化するには、OPTIMIZER_FEATURE_ENABLEを11.1.0.6以降に設定する必要があります。
回避策: ありません。
Oracle Bug#8256753
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)
)
)
