| Oracle® Databaseプラットフォーム共通日本語README 12cリリース1 (12.1) B71333-15 |
|
 前 |
 次 |
この章では、Oracle Database 12cリリース1 (12.1.0.2)のOracle Databaseドキュメント・ライブラリには含まれていない、重要な最新機能と変更について説明します。
この章は、次の項目で構成されています。
2.1項「互換性、アップグレード、ダウングレードおよびインストール」
2.2項「Oracle Database 12.1.0.2で使用できないか、または制限されている機能」
2.3項「Oracle Databaseで非推奨またはサポート終了となった機能」
2.4項「Oracle DatabaseのためのSPARC上のData Analytics Acceleratorの概要」
2.8項「Oracle Application Express」
2.9項「Oracle Automatic Storage Management(Oracle ASM)」
2.11項「Oracle Enterprise Manager Database Express (EM Express)」
2.12項「クラスタ用のOracle Grid Infrastructure」
2.16項「Oracle Spatial and Graph」
アップグレード前、アップグレード後、互換性および相互運用性の説明に関する最新の更新情報およびベスト・プラクティスについては、Upgrade Companion WebサイトにリンクするMy Oracle Support (https://support.oracle.com)のノート1462240.1を参照してください。
|
注意: インストールの完了後、Oracleソフトウェアの実行中に、cronまたは/tmp/.oracleディレクトリ、あるいはそれらのファイルを、手動で削除したり、削除する/var/tmp/.oracleジョブを実行したりしないでください。これらのファイルを削除すると、Oracleソフトウェアが断続的にハングする場合があります。クラスタ用のOracle Grid Infrastructureのインストールが失敗し、次のエラーが表示されます。CRS-0184: Cannot communicate with the CRS daemon. |
12.1.0.1 SEまたはSE1から12.1.0.2 SE2へのアップグレード時に事前アップグレードが失敗します(Oracle Bug#21390522を参照)。
回避策: アップグレード前にOracle Bug#18718327のための個別パッチを適用します。
Oracle Label Security (OLS)のアップグレードおよびダウングレード・スクリプトは、12.1.0.1 SEまたはSE1データベースに付属していません(Oracle Bug#21497495を参照)。その結果、12.1.0.1 SEまたはSE1へのダウングレード・プロセス後にcatrelod.sqlを実行しても、OLSパッケージは正しく再コンパイルされません。OLSパッケージは、12.1.0.2 SE2へのアップグレードの一部として導入されたオブジェクトを参照し続けます。
これにより、12.1.0.1 SEまたはSE1でORA-06508の後に utlrp.sqlを実行すると、catrelod.sqlエラーが発生する可能性があります。
回避策: 12.1.0.2 SE2からのダウングレード前に、12.1.0.1 SEまたはSE Oracleホームにパッチ21076681を適用します。
Oracle Database Upgrade Assistant (DBUA)を使用してOracle Databaseをリリース12.1.0.1からリリース12.1.0.2にアップグレードする際に、次のエラーが返されます(Oracle Bug#21449004を参照)。
ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE
回避策: 「無視」をクリックして続行します。
リリース12.1.0.1 SEまたはSE1からリリース12.1.0.2 SE2にアップグレードした後に、12.1.0.2 SE2から12.1.0.1 SEまたはSE1にダウングレードすると、Oracle Multimediaが無効になることがあります(Oracle Bug#21445944を参照)。
回避策: 再ロード・スクリプトを実行する前に、ダウングレード・プロセスの一部として12.1.0.2 ORACLE_HOMEからmd/admin/loce121.sqlを起動します。
マルチテナント・コンテナ・データベース(CDB)またはプラガブル・データベース(PDB)をダウングレードするには、リリース12.1.0.1パッチ・セット・アップグレードPSU4が必要です。パッチ・セット・アップグレードは、My Oracle Support (MOS)(https://support.oracle.com/)からダウンロードできます。最新のパッチ・セット・アップグレードと必要な追加修正プログラム・セットの入手方法については、MOS Note 756671.1を参照してください(Oracle Bug#18826367を参照)。
マルチテナント・コンテナ・データベース(CDB)を12.1.0.1から12.1.0.2にアップグレードした後、ROOT内のデフォルト表領域を持つように変更された共通ユーザーがCDBに存在し、指定されたプラガブル・データベース(たとえば、P1)内にその名前の表領域がない場合は、問題が発生する可能性があります(Oracle Bug#19174942を参照)。新しいプラガブル・データベース(たとえば、P2)がプラガブル・データベース(PDB) P1からクローンされた場合、PDB P2は警告とともに制限モードで開きます(これは予期しない動作です)。ROOT内のPDB_PLUG_IN_VIOLATIONSビューに対する次の問合せを発行すると、少なくとも1つの行が返されます。
SELECT MESSAGE, ACTION FROM PDB_PLUG_IN_VIOLATIONS WHERE NAME = 'P2' AND TYPE = 'ERROR' AND STATUS = 'PENDING' AND CAUSE = 'Sync Failure';
ROOT内のDBA_USERSビューを問い合せて各共通ユーザーのデフォルト表領域を確認し、各表領域がPDB内に存在することを確認してください。特定の表領域がPDB内に存在しない場合は、次の手順を実行します。
PDBを開きます。
PDB内のDBA_USERSビューを問い合せて、PDB内の共通ユーザーのデフォルト表領域を確認します(これはこの後の手順5で必要になります)。
見つからない表領域をPDB内に作成します。
PDBを閉じ、再度開きます。
PDBでALTER USERコマンドを発行し、PDB内の共通ユーザーのデフォルト表領域を、(手順2で確認した)元の表領域に変更します。
表領域をPDBから削除します。
Oracle Enterprise Managerのローリング・アップグレードを行うには、プライマリ・データベースよりも先にアップグレードされる物理スタンバイ・データベース上で、RDBMSのアップグレード前ツール・チェックを実行する必要があります(Oracle Bug#19195895を参照)。ただし、これらのツール・チェックは読取り専用モードで開かれている物理スタンバイ・データベースでは実行できません。
アップグレードを実行する前に、My Oracle Support (MOS)(https://support.oracle.com/)から最新の12.1.0.2アップグレード前ツール(MOS Note 884522.1)をダウンロードしてください。
リリース12.1.0.2では、Oracleオブジェクト型の属性となる可能性があるデータ型のバージョニングが新たに導入されました。この機能により、リリース12.1.0.1とリリース12.1.0.2の各データベース間でのクロスバージョン・レプリケーションが影響を受け、ORA-26656エラーが発生する可能性があります。
ユーザー定義のオブジェクト型にDATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE, BINARY_FLOAT, BINARY_DOUBLE, NCHAR, NVARCHAR2, NCLOB, ANYDATA,などの属性が含まれる場合は、リリース12.1.0.1のすべてのインスタンスを対象に、Oracle Bug#18038108に対する必須のパッチ・セット・アップグレードを適用する必要があります。
リリース12.1.0.2をリリース12.1.0.1にダウングレードし、utlrp.sqlスクリプトを実行した後に、MDSYS.SDO_COORD_OPS_TRIGGERトリガーが無効になることがあります(Oracle Bug#18900492を参照)。これによる既知の副次的影響はありません。MDSYS.SDO_COORD_OPS_TRIGGERトリガーは、トリガーの初回使用時に有効になります。なお、DBAとしてALTER TRIGGER MDSYS.SDO_COORD_OPS_TRIGGER COMPILE文を実行して有効にすることもできます。
Oracle ASMインスタンスをリリース11.1.0.7からリリース12.1.0.xにアップグレードした後、リリース11.1.0.7にダウングレードし、再度リリース12.1.0.xにアップグレードしようとすると、Oracle ASMがアップグレードされない場合があります(Oracle Bug#14756008を参照)。『Oracle Grid Infrastructureインストレーション・ガイドfor Linux』に記載されている手順に従って、Oracle ASMインスタンスを手動でアップグレードしてください。
アップグレードの間にノード・クラッシュが発生した場合、-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 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)に修正を適用する必要があります。
次に示すのは、Oracle Database 12cリリース1 (12.1.0.2)で使用できない、または制限されているコンポーネントのリストです。
時間隔パーティションは、XMLIndexでサポートされていません。XMLIndexでは、範囲、リストおよびハッシュ・パーティション化スキームのみがサポートされます。
Oracle Flex Clusterモードで稼働しているOracle Grid Infrastructureクラスタをアップグレードする場合は、Oracle Grid Infrastructureリリース12.1.0.2へのローリング・アップグレードのみがサポートされます。アップグレードの前に、クラスタ内のすべてのノード(ハブ・ノードとリーフ・ノード)上のOracle Clusterwareスタックが稼働している必要があります。標準クラスタ・モードで稼働している環境の場合は、ローリングおよび非ローリング・アップグレードがサポートされます。
Transaction Guardを使用している場合、データベース常駐接続プーリング(DRCP)はサポートされません。
XStreamは、可変幅のマルチバイト・キャラクタ・セットを使用したデータベースではLONG列をサポートしません。
Java Database Connectivity (JDBC)のThinドライバDatabase Change Notification (DCN)は、PDBではサポートされません。
Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)は現在、Hybrid Columnar Compression (HCC)をサポートしていません。
次に示すのは、Oracle Database 12cリリース1 (12.1.0.2)のマルチテナント・コンテナ・データベースで使用できない、または制限されている機能のリストです。
DBVERIFY
Data Recovery Advisor
フラッシュバック・プラガブル・データベース
フラッシュバック・トランザクション問合せ
フラッシュバック・トランザクション・バックアウト
データベース変更通知
連続問合せ通知(CQN)
クライアント側キャッシュ
ヒート・マップ
自動データ最適化
Oracle Streams
特定のマテリアライズド・ビューを使用またはリフレッシュするときは、NLSパラメータが、そのマテリアライズド・ビューで作成した時点のパラメータと同じであることを確認してください。この制限を受けるマテリアライズド・ビューには、NLSパラメータの設定に応じて異なる値を戻す可能性がある式が含まれます。
そのような式は、NLSに依存しない方法で記述することをお薦めします。たとえば、次のようにします。
(date > DATE '2003-01-02') (rate <= 2.150)
結合の片側が文字データの等価結合として式を記述します。この等価結合の結果は照合によって異なり、セッションごとに変化する可能性があります。クエリー・リライトの場合は正しい結果が得られません。また、リフレッシュ操作後はマテリアライズド・ビューに一貫性がなくなります。
式は、マテリアライズド・ビューの選択リスト内、またはマテリアライズド集計ビューの集計内に文字データへの内部変換を生成します。
この制限は、数値データのみが含まれる式には適用されません。たとえば、a+bとaが数値のbには適用されません。
Oracle Database 12cリリース1 (12.1)では、新しい機能に加えて、データベースでの動作の変更が加えられています。動作の変更には、初期化パラメータ、オプション、構文、機能およびコンポーネントの非推奨とサポートの終了が含まれます。詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
Oracle JPublisherは、2014年10月からOracle Database 12cリリース1で非推奨となっており、Oracle Database 12cリリース2では、すべてのJPublisher機能のサポートが終了し、使用できません。次に示す代替策を使用することをお薦めします。
Webサービス・コールアウトを使用し続けるには、Webサービス・コールアウト・ユーティリティの代替であるOJVM Webサービス・コールアウト・ユーティリティを使用することをお薦めします。
PL/SQLプログラムおよびSQLオブジェクトのJavaクライアント・アプリケーションを作成するには、開発者は、Java STRUCTクラスの作成を支援する他のJDK開発ツールおよび他の事前構成済オプションを使用することをお薦めします。
|
関連項目: JPublisherの非推奨およびサポート終了の詳細は、My Oracle Supportのノート1937939.1を参照してください。
また、Oracle Technology NetworkのJDKツールおよびユーティリティを参照してください。 |
SPARC M7、T7およびS7シリーズ・サーバーのマイクロプロセッサには、Data Analytics Accelerator (DAX)コプロセッサが含まれます。これらのコプロセッサは、直接ハードウェアを介して問合せ関連の演算を実行するため、Oracle Databaseのパフォーマンスが向上します。次に示すOracle Database Enterprise EditionおよびOracle Solarisの最小バージョンでは、Oracle Database 12cインメモリー・データベース操作にDAXハードウェア・アクセラレーションを使用できます。
DAXを使用するための最小要件は次のとおりです。
Solarisバージョン: システムによって異なりますが、通常Solaris 11.3以上が搭載されています。各システムのサーバー・プロダクト・ノートを参照し、必要なSolaris 11.3 SRUなど、システム固有の最小要件を確認してください。
SPARC M7/T7で最低限必要なOracleのバージョンおよびパッチ:
Oracle Database 12c 12.1.0.2
パッチ21744410: DATABASE PATCH FOR ENGINEERED SYSTEMS AND DB IN-MEMORY 12.1.0.2.13 (2015年10月)以降
パッチ21249747: FOLLOWUP FOR BUG 18867241 FOR NON PQ ENABLED QUERIES
SPARC M7/T7で推奨されるOracleバージョンおよびパッチ
Oracle Database 12c 12.1.0.2
パッチ23273686: DATABASE PROACTIVE BUNDLE PATCH 12.1.0.2.160719 (2016年7月)
パッチ21249747: FOLLOWUP FOR BUG 18867241 FOR NON PQ ENABLED QUERIES
パッチ21888938: CPUSPEEDNW IS UNDER REPORTED ON SPARC
SPARC S7で最低限必要なOracleバージョンおよびパッチ:
Oracle Database 12c 12.1.0.2
パッチ23273686: DATABASE PROACTIVE BUNDLE PATCH 12.1.0.2.160719 (2016年7月)
パッチ24353230: MERGE REQUEST ON TOP OF DATABASE BP 12.1.0.2.160719 FOR BUGS 22091036 23235386
パッチ23265829: CPU EFFECTIVE MULTIPLIER CHANGE TO 0.5 DEFAULT
パッチ21249747: FOLLOWUP FOR BUG 18867241 FOR NON PQ ENABLED QUERIES
パッチ21888938: CPUSPEEDNW IS UNDER REPORTED ON SPARC
最後に、アプリケーションのインメモリー機能を有効にします。
データベース・セキュリティでは次の変更が加えられています。
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パラメータを設定してサーバーとクライアントの間の適切な接続を再び有効化します。
パッチが影響する領域は次を含みますが、これらに限定されません。
JDBCネットワーク暗号化関連の構成設定
Oracle Net Managerを使用して構成した暗号化および整合性パラメータ
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つの方法を提供しています。
どちらの方法にもメリットおよびデメリットがあります。
Oracle Databaseリリース11gで、DBMS_CRYPTO.CHAIN_OFB暗号ブロック連鎖修飾子を設定して、出力フィードバック(OFB)モードを使用するように暗号文の暗号化を構成すると、Oracle Bug 13001552のため、その構成で電子コードブック(ECB)モードが誤って使用されました。この不具合はOracle Databaseリリース12cで修正されています。したがって、Oracle Databaseリリース11gからリリース12cにアップグレードした後、リリース11gでOFBモードを使用して暗号化された暗号文は、Oracle Databaseリリース12cでは修正されたOFBモードで正しく復号化されません。
回避策として、DBMS_CRYPTO.CHAIN_ECBブロック暗号連鎖修飾子を使用して、暗号文を復号化します。
Oracle Databaseリリース11gからリリース12cへのアップグレードを予定している場合は、復号化操作でECBモードを使用するように、OFBモードが指定されたすべてのスクリプトを編集してください。この方法によって、スクリプトはリリース11gとリリース12cの両方で使用できるため、ビジネスの継続性を確保できます。
リリース12.1.0.2では、新しいHTTPS_SSL_VERSIONパラメータが導入されました。これはリリース12.1.0.2専用のパラメータです。このパラメータは、デフォルトでは1.1または1.2に設定されています(つまり、TLSv1.1またはTLSv1.2)。これにより、HTTPSによって使用されるSecure Sockets Layer (SSL)バージョンを個別に制御できるようになりました。SSL_VERSIONとHTTPS_SSL_VERSIONパラメータを同じsqlnet.oraファイルで設定して、HTTPSで使用するSSLバージョンを制御できます。このパラメータは、任意の有効なSSL_VERSION値に設定できます。
|
注意: これは、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セキュリティ・ガイド』を参照してください。
マルチテナント・コンテナ・データベース(CDB)を使用する場合は、次のことに注意してください。
今リリースでは、マルチテナント・コンテナ・データベースに対してフラッシュバック・データ・アーカイブ(FDA)がサポートされています。
アプリケーション・サーバー・レベルでの文キャッシュ(たとえば、WebLogicまたはサードパーティ・アプリケーション・サーバーの文キャッシュ)が有効になっている場合は、リプレイの使用時にそれを無効にする必要があります。かわりに、JDBC文キャッシュを構成します。JDBC文キャッシュはJDBCとOracle用に最適化されており、アプリケーション・コンティニュイティもサポートしているため、パフォーマンスが向上します。oracle.jdbc.implicitstatementcachesize=nnnを使用します。
Oracle Application Expressの詳細は、『Oracle Application Expressリリース・ノート』および『Oracle Application Expressインストレーション・ガイド』を参照してください。
Security-Enhanced Linux (SELinux)をOracle ACFSとともに強制モードで使用している場合は、Oracle ACFSのファイル・システムがSELinuxのデフォルト・コンテキストでマウントされていることを確認してください。コンテキスト・マウント・オプションについては、Linuxベンダーのドキュメントを参照してください。
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の機能に影響はありません。
次のブラウザは、Oracle Enterprise Manager Database Express (EM Express)(データベース・リリース12.1.0.2)での使用が動作保証されています。
|
注意: これらのブラウザでEM Expressにアクセスするために必要な最低限のトランスポート・レイヤー・セキュリティ(TLS)バージョンは、TLS 1.1です。 |
クラスタ・インストール用の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 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 Spatial and Graph RDFセマンティック・グラフを使用する際は、次のことに注意してください。
リリース12.1.0.2では、Oracle Spatial and Graph RDFセマンティック・グラフを、リリース12.1.0.2.0にアップグレードされた新しいOracle Databaseインストールおよびデータベースとともに使用する場合、Oracle Spatial and Graph GeoRaster機能をまだ有効化していない場合は、SYS権限を使用してSYSDBAユーザーとして接続(SYS AS SYSDBA)し、mdsys.enableGeoRasterプロシージャを実行する必要があります。このプロシージャは、RDFセマンティクス・グラフ操作に必要なシステム・トリガーを作成します。
詳細は、『Oracle Spatial and Graph RDFセマンティク・グラフ開発者ガイド』の「RDFセマンティク・グラフ・サポートの有効化」を参照してください。
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 XML DBでは、次の機能はサポートされていません。
フラッシュバック・データ・アーカイブ
エディショニング・ビュー
SecureFile LOB暗号化
同一XMLドキュメントに構造化と非構造化のハイブリッドXMLIndexが設定されているOracle Label Security (OLS)
Pro*Cの詳細は、Pro*C/C++リリース・ノートを参照してください。
Pro*COBOLの詳細は、『Pro*COBOLリリース・ノート』を参照してください。
SQL*Plusの詳細は、『SQL*Plusリリース・ノート』を参照してください。
この項では、今回のリリースでの既知の不具合を示します。これ以外に、使用しているプラットフォーム固有のリリース・ドキュメントに補足のリストが含まれている場合があります。
READMEのこの項には、さらに次の項があります。
2.22.1項「12.1.0.2 Standard Editionリリースに関する既知の不具合」
2.22.2項「Database Upgrade Assistant (DBUA)に関する既知の不具合」
2.22.4項「マルチテナント・コンテナ・データベース(CDB)とプラガブル・データベース(PDB)に関する既知の不具合」
2.22.5項「Oracle ASM Cluster File System (Oracle ACFS)に関する既知の不具合」
2.22.6項「Oracle Automatic Storage Management (Oracle ASM)に関する既知の不具合」
2.22.7項「Oracle Clusterwareに関する既知の不具合」
2.22.8項「Oracle Database Enterprise Editionに関する既知の不具合」
2.22.9項「Oracle Database In-Memoryに関する既知の不具合」
2.22.10項「Oracle Database Quality of Service (QoS) Managementに関する既知の不具合」
2.22.11項「Oracle Data Guardロジカル・スタンバイ・データベースに関する既知の不具合」
2.22.12項「Oracle Grid Infrastructureに関する既知の不具合」
2.22.13項「Oracle Real Application Clusters (Oracle RAC)に関する既知の不具合」
2.22.14項「Oracle Textに関する既知の不具合」
2.22.15項「Oracle Universal Installerに関する既知の不具合」
2.22.16項「Oracle XML DBに関する既知の不具合」
2.22.17項「ベンダーおよびオペレーティング・システムに関する既知の不具合」
次の項では、Oracle Database 12cリリース1 (12.1.0.2) Standard Editionリリースに関する既知の不具合について説明します。
リリース12.1.0.1から、XQuery全文テキスト問合せ用のXML検索索引が導入されました。XML検索索引のために作成される内部表の1つは、Oracle Advanced Compressionオプションに依存するメディア圧縮を使用して作成されます。Oracle Database Standard Editionでは、Advanced Compressionを使用できないため、索引を作成すると次のエラーが発生します。
ORA-00439: feature not enabled: Advanced Compression
回避策: この不具合(21353871)に対する修正が含まれるパッチを適用します。Oracle Advanced Compressionオプションが使用できない場合、パッチにより圧縮を使用せずに内部表が作成されます。
この項では、Database Upgrade Assistant (DBUA)に関する既知の不具合について説明します。
リストア・スクリプトを使用してデータベースをリストアしようとする場合、セッションが不足し、リストア・スクリプトによってORA-00018エラーが表示されることがあります。
回避策: セッション初期化パラメータをより大きな値に増やし、utlrp.sqlスクリプトを実行して、次のコマンドを実行します。
ALTER SYSTEM SET SESSIONS=<new_number> SCOPE=BOTH;
Oracle Database Upgrade Assistant (DBUA)のインタビュー・プロセス時に選択したアップグレード・オプションによっては、アップグレード・エラー時にデータベースをリカバリするためのオプションが提供されます。
ソース・データベースを所有するユーザーがDBUAを呼び出した現行ユーザー以外のユーザーである場合は、ソース・データベース・ユーザーの所有するバックアップ・ファイルにアクセスできない可能性があるため、リストア操作が失敗することがあります。これは通常、Oracle Database Express Editionデータベースのアップグレード時に発生します(データベースがユーザーoracleによって所有される場合)。
回避策: データベースに対するrestore操作を確認する前に、バックアップが置かれているディレクトリの権限を変更して、現行ユーザーによるユーザー・アクセスを許可します。
この項では、削除ツールに関する既知の不具合について説明します。
この項では、マルチテナント・コンテナ・データベース(CDB)とプラガブル・データベース(PDB)に関する既知の不具合について説明します。
この項では、Oracle ASM Cluster File System (Oracle ACFS)に関する既知の不具合について説明します。
高速ホーム・プロビジョニングの移動操作の一部としてターゲット作業用コピーを作成する場合、rhpctl moveコマンドでは、ターゲット作業用コピー作成のCVU前提要件チェックの障害を無視するために必要な、-ignoreprereqオプションを使用できません。
回避策: 最初に、-ignoreprereqオプションを使用したrhpctl add workingcopyコマンドを指定してターゲット作業用コピーを作成し、その後、作成した作業用コピーに対して移動操作を実行します。
Oracle Database 10gリリース2 (10.2.0.5)用の作業用コピーをプロビジョニングする際、コマンドラインで-pathが指定されていないと、Oracle ACFSストレージ上にOracleホームを作成しようとする際にコマンドが失敗します。
回避策: rhpctl add workingcopyコマンドで-storagetype LOCALオプションを指定して、Oracle ACFSのかわりにローカル・ファイル・システム・ストレージを使用することを指定します。
11.1 CRSから12c Oracle Grid Infrastructureへクラスタに対してアップグレードするときと、Oracle ASMコンフィギュレーション・アシスタント(ASMCA)がOracle ASMをアップグレードした後、一部のデータベース・インスタンスが起動しない可能性があります。この問題は、Oracle Universal Installer (OUI)ではエラーや警告として反映されません。
回避策: データベース・インスタンスの状態を検出するために、アップグレード後に手動でデータベース・インスタンスをチェックします。次に例を示します。
srvctl status database -db <db_name>
それから、手動でデータベース・インスタンスを起動します。次に例を示します。
srvctl start database -db <db_name>
パスワードで保護されたキー・ストアを持つクラスタで、暗号化を使用するOracle ACFSファイル・システムがOracle ACFSマウント・レジストリを使用してマウントされる際、管理者にキー・ストア・パスワードの入力を求めるプロンプトが表示されません。ファイル・システムのマウント・プロセスは成功しますが、Oracle ACFSの暗号化が正常に機能するために必要な一部の情報を、ファイル・システムで利用できません。この場合、このファイル・システムで暗号化が機能せず、ファイル・システム内の暗号化されたファイルの読取りまたは書込みを行うことができません。
回避策: パスワードで保護されたキー・ストアを持つクラスタでは、暗号化を使用するファイル・システムのマウントに、Oracle ACFSマウント・レジストリを使用しないでください。一部のファイル・システムがOracle ACFSマウント・レジストリを通じてすでにマウントされている場合は、それらをマウント解除し、そのようなファイル・システムをマウント・レジストリからすべて削除して、暗号化データが今後利用できなくなる事態を回避してください。その後、リクエストされたら正しいパスワードを入力して、Oracle ACFSマウント・レジストリを使用せずにこれらのファイル・システムを再マウントします。
Oracle ADVMボリュームを削除すると、対応するCRSボリューム・リソースが削除されます。まれに、リソースが削除されないケースもありますが、次のコマンドを使用することでCRSリソースを削除できます。
srvctl remove volume
回避策: リソースを削除します。
acfsutil registryを使用して登録したOracle ACFSファイル・システム上に、Cluster Ready Services (CRS)との依存関係を持つNetwork File System (NFS)エクスポートまたはデータベース・リソースがある場合、登録したOracle ACFSファイル・システムを後からacfsutil registryで変更すると、Oracle ACFSファイル・システムのリソースは、CRSとの依存関係があっても変更されます。たとえば、Oracle ACFSファイル・システムのリソースがクラスタ全体にわたるリソースである場合、それを"ノード・ローカル"に変更すると、サポートされない構成になってしまう可能性があります。
回避策: ありません。
この項では、Oracle Automatic Storage Management (Oracle ASM)に関する既知の不具合について説明します。
Cluster Ready Services(CRS)がすべてのノードで停止されると、Oracle Automatic Storage Management (Oracle ASM)はローリング移行状態を失います。
回避策: リリース11.2.0.2のノードと、リリース12.1.0.2にアップグレードしたノードによる、4ノード(node1、node2、node3およびnode4)のシナリオで考えてみます。
node1とnode2を12.1.0.2にアップグレードして実行中。
node3とnode4は11.2.0.2のままで実行中。
停電によってすべてのCRSスタックがダウンし、クラスタが異種混在状態になったとします(つまり、11.2.0.2の2ノードと12.1.0.2の2ノード)。
アップグレードを進めるには、11.2.0.2のノード(node3、node4、または両方)のみを起動し、12.1.0.2のノードを起動する前に、Oracle ASMインスタンス上でnode3とnode4に対して次のコマンドを実行する必要があります。
ALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.2'
この時点から、説明どおりにアップグレード手順を続行します。
なお、前述の手順を実行してOracle ASMクラスタをローリング移行に戻すまでは、クラスタ内でバージョンの異なる2つのノードを起動することはできません。これを行うと、いずれかのOracle ASMバージョンが失敗し、ORA-15153またはORA-15163エラー・メッセージが返されます。
この項では、Oracle Clusterwareに関する既知の不具合について説明します。
Oracle Clusterwareインストールでは、ユーザーがTask DHCP Configuration check自動化オプションを選択し、後でそれを取り消した場合、警告とともに前提要件チェックrootがリストされることがあります。
回避策: この場合、このチェック・エラーは無視してかまいません。
-savedirオプションに使用したパスが存在しないパスである場合や、cluvfy comp baseline -savedirコマンドを実行しているユーザーに書込み権限が付与されていないパスである場合、コマンドは適切なエラー・メッセージを報告することなく失敗します。
回避策: -savedirオプションに対して、ユーザーが書込み可能なディレクトリを指定します。
Oracle High Availability Servicesデーモン(OHASD)のOracle Agent (oraagent)を再起動せずにOracle Cluster Synchronization Servicesデーモン(CSSD)を再起動すると、ohasd ora.asmリソースはINTERMEDIATE状態のままになります。
回避策: 次のコマンドを実行します。
crsctl stop res ora.asm -init crsctl start res ora.asm -init
グリッド・インフラストラクチャ管理リポジトリはヒュージ・ページを使用するように構成されています。このデータベースは他のどのデータベースよりも先に起動されるため、1つ以上のデータベースのシステム・グローバル領域(SGA)が、(ヒュージ・ページではなく)通常のページにマップされる場合があります。グリッド・インフラストラクチャ管理リポジトリのSGAのサイズは750MBです。したがって、該当するすべてのデータベースとグリッド・インフラストラクチャ管理リポジトリをあわせた、合計のSGAサイズを収容できるように、ヒュージ・ページ設定を増やす必要があります。
回避策: グリッド・インフラストラクチャ管理リポジトリのSGAを収容できるように、ヒュージ・ページの割当てを増やします。
ネットワークSTATICをnettypeからautoconfigに変換した後に、mixed SCANアドレスが失われることがあります。これが発生すると、srvctl config scanコマンドを実行してもSCANのSTATICアドレスが表示されなくなります。
回避策: ネットワークnettypeをautoconfigからmixedに変換した後に、SCANを再起動します。
データベース作成を伴うOracle RACのインストール時には、DBSNMPパスワードをCVUDBクラスタ・ウォレットに保存するためのオプションがユーザーに提供されません。そのため、DBSNMPユーザー・パスワードは保存されません。クラスタ検証ユーティリティ(CVU)のリソースが再度実行される際、CVUはデータベース関連のチェックを実行しようとしますが、ウォレットが利用できないためチェックを実行できません。その結果エラーが発生し、Oracle Clusterwareのアラート・ログに記録されます。また、データベース関連の操作を実行するcluvfyコマンドが実行される際にも、エラーが発生することがあります。
回避策: Oracle RACの所有者またはrootとして次のコマンドを実行し、CVUDBウォレットを手動で作成します。
crsctl add wallet -type CVUDB -name <dbsid> -user dbsnmp -passwd
アップグレードより前に行ったOracle Grid Infrastructure管理リポジトリのサイズ変更は、リリース12.1.0.2へのアップグレード後には保持されません。
回避策: リリース12.1.0.2へのアップグレード後にoclumon manage -repos changerespossizeコマンドを使用して、リポジトリのサイズ変更を再適用します。
この問題は2つのシナリオのいずれかで発生します。1つ目のシナリオは、ネットワーク内の2つ以上のインタフェースが同じIPアドレスを持つ場合に、ルーティングの衝突が発生するというものです。2つ目のシナリオは、ネットワーク・スクリプト内に同じIPアドレスを使用したエントリ(通常は.BAKファイル)が複数存在する場合に、ルーティングの衝突が発生するというものです。
これらのシナリオはどちらも、クラスタ検証ユーティリティ(CVU)によって検証され、いずれかのシナリオに該当する場合はCVUによって報告されます。
1つ目のシナリオの場合は実際に問題が生じるため、これを検証エラーとして報告するCVUの判断は正しいと言えます。
2つ目のシナリオの場合は、バックアップ・ファイルが自動的に作成されたか、誰かがインタフェースのコピーを作成した後、そのコピーを削除しなかったことを意味します。その場合、CVUはこれを、同じIPアドレスを持つ複数のインタフェースとして報告します。
シナリオ1の回避策: 同じIPアドレスを持つインタフェースが複数存在しないことを確認します。
シナリオ2の回避策: /etc/sysconfig/network -scriptsのネットワーク・スクリプト下に.BAKファイルや重複エントリ(たとえば、ifcfg-eth0やifcfg-eth0.BAK)があり、それらが同じIPアドレスを使用している場合は、ifcfg-eth0.BAKを削除するか、ifcfg-eth0.BAKのIPアドレスを変更します。
ネットワーク・タイプがautoconfigからmixedに変換された後に、データベース・クライアントが、動的IPv6 SCAN名を使用したデータベースへの接続に失敗することがあります。
回避策: ネットワーク・タイプをautoconfigからmixedに変換した後に、SCANを再起動します。
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ホームに適用してください。 |
最初のクラスタ・ノードでインストール・スクリプトを中断または停止すると、最初のノードでスクリプトが再び実行されるか、その後別のクラスタ・ノードで実行されるとき、次のエラーが発生する可能性があります。
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 Database Enterprise Editionに関する既知の不具合について説明します。
Oracle Direct NFS (dNFS)を有効にして実行中の場合、バックアップ・ファイルまたはOracle Data Pumpファイル用に、ネットワーク・ファイル・システム(NFS)プロトコル・デバイスを使用できます。これらのファイルは常にデータベースによって使用されるわけではないため、NFS管理変更を実行して、NFSボリュームをアンマウントし、同じマウント・ポイントに再マウントできます。この修正がない場合、dNFSがシステム・グローバル領域(SGA)のキャッシュ・ファイル・ハンドルを使用するため、古いまたは不良ファイル・ハンドル・エラーが発生する可能性があります。UNMOUNTVOLUMEプロシージャで、SGAのキャッシュ・ファイル・ハンドルをクリーンアップできます。
UNMOUNTVOLUMEプロシージャは、SGAのキャッシュNFSファイル・ハンドルをクリーンアップし、これは、オペレーティング・システムを使用してNFSマウント変更が行われるとき、およびオペレーティング・システムのUNMOUNTおよびMOUNTコマンドが起動されるときに使用する必要があります。UNMOUNTVOLUMEプロシージャは、dNFSクライアントに対するオペレーティング・システムのUNMOUNTコマンドと同等です。
回避策: この修正がない場合、SGAに保存されているキャッシュ・ファイル・ハンドルをクリーンアップするために、データベースを停止して再起動する必要があります。
データベース・ディレクトリ名に、エラー・メッセージの接頭辞コード(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で使用してください。
問合せで、表パーティションにアクセスするためにPARTITION句内でFROM句を使用すると、クエリー・リライトが発生しません。
回避策: PARTITION句をWHERE句内で同等の選択述語に変換する必要があります。
ホスト名にIPv4およびIPv6アドレスを使用しているクラスタでは、インストーラが実行されているノード以外のすべてのノードで、rootパスワードを使用したrootスクリプトの自動実行が失敗します。これは、インストールとアップグレードの両方に当てはまります。
回避策: このような環境でインストールまたはアップグレードが失敗した場合は、すべてのクラスタ・ノードでroot.shまたはrootupgrade.shスクリプトを手動で実行します。
パッチを間違って適用した後に、DBMS_QOPATCHディレクトリ・オブジェクトとORACLE_HOME内のインベントリに不一致が生じることがあります。これは、OPATCH_SCRIPT_DIR, OPATCH_LOG_DIR, (たとえば、OPATCH_INST_DIR)からDBA_DIRECTORIESまたはSELECT DIRECTORY_NAME,DIRECTORY_PATH DBA_DIRECTORIES WHERE DIRECTORY_NAME='OPATCH_SCRIPT_DIR'を選択し、それらが正しいORACLE_HOMEの場所(パッチ詳細を適用または問い合せている場所)を指しているかどうか確認することでチェックできます。
回避策: ディレクトリ・オブジェクトを手動で修正するか、DBMS_QOPATCH.REPLACE_LOGSCRPT_DIRS()を手動で実行します。ディレクトリ・オブジェクトが修正されたら、失敗した問合せまたはデータ・パッチを再度実行します。
リリース12.1.0.1のプラガブル・データベース(PDB)をリリース12.1.0.2のマルチテナント・コンテナ・データベース(CDB)にプラグインした後、自動生成された名前を持つ一部の共通タイプを使用しようとしたときに、問題が発生することがあります。これらの共通タイプは、オブジェクト関連ストレージに一部のOracle XML DBスキーマを登録することで作成されます。これらのタイプ名は自動生成されるため、リリース12.1.0.1での名前がリリース12.1.0.2での名前と違ったものになることがあります。そのため、一致する共通タイプがリリース12.1.0.2のCDB rootに存在しない場合があります。
回避策: 次の手順を実行します。
ターゲットCDB root内のPDB_PLUG_IN_VIOLATIONSビューに対し、GetTypeDDLを含んだアクションが存在するか問い合せます。存在する場合は、アップグレード後のPDBに前述の問題があることになります。
ターゲットPDB内でset serveroutput onおよびexec xdb.DBMS_XMLSTORAGE_MANAGE.GetTypeDDLを実行して、ユーザー命名によるSQLスクリプト(たとえば、script1.sql)を生成します。
ソースである12.1.0.1のCDBでscript1.sqlを実行して、すべての共通タイプ用のタイプ作成スクリプトを取得し、別のユーザー命名SQLスクリプト(たとえば、script2.sql)を生成します。
ターゲットPDB内でscript2.sqlを実行して、すべてのタイプをローカルで作成します。
プラガブル・データベース(PDB)のメンテナンス操作では、PARALLEL_MAX_SERVERS初期化パラメータの設定にかかわらず、各インスタンスで操作を実行するために、パラレル・タスクがすべてのアクティブ・インスタンスに割り当てられる必要があります。インスタンスでPARALLEL_MAX_SERVERS=0に設定されている場合、パラレル・タスクがそのインスタンスに割り当てられず、そこで操作は実行されません。
回避策: PARALLEL_MAX_SERVERS初期化パラメータの値を0に設定しないでください。PARALLEL_MAX_SERVERS初期化パラメータを何も設定しなければ十分です。
ハードウェア・セキュリティ・モジュール(HSM)構成でTDEを使用している場合、透過的データ暗号化(TDE)ビューORA-00600またはV$ENCRYPTION_KEYSを選択すると、データベースのシャットダウン時にV$CLIENT_SECRETS内部エラーが表示されることがあります。
回避策: この問題は、データベースのシャットダウンが開始された後、V$ENCRYPTION_KEYSまたはV$CLIENT_SECRETSビューのシステム・グローバル領域(SGA)キャッシュをクリーン・アップしようとしたときに発生します。これらのビューのSGAキャッシュは、ウォレットを閉じたときにもクリーンアップされます。
データベースをシャットダウンする前に次の構文を実行して、キーストアを明示的に閉じてください。
ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "user_id:password" [CONTAINER = ALL | CURRENT];
LOB操作が分散トランザクションで発行された場合、または基礎となるLOBがSecureFileとして保存されている場合には、ORA-00600エラーが返されます。
回避策: 初期化パラメータ・ファイル内で_kdli_space_cache_limit=0を設定して、SecureFileスペース・キャッシュをオフにし、インスタンスをバウンスします。
|
注意: 初期化パラメータ・ファイルで_kdli_space_cache_limit=0を設定すると、パフォーマンスが低下することがあります。 |
ソース・データベースとターゲット・データベースのタイム・ゾーンが異なる場合、TIMESTAMP WITH LOCAL TIME ZONEデータを含んだ表は、トランスポータブル表領域テクノロジを使用してデータベース間で移動させることができません。影響を受ける各表には、インポート時に次のエラーでフラグが立てられます。
ORA-39360, Table "<owner>"."<table name>" skipped due to transportable import and TSLTZ issues.
回避策: ターゲット・データベースをソース・データベースと同じタイム・ゾーンに変換するか、影響を受ける表を従来のデータ・ポンプ・エクスポートおよびインポートにより移動します。
トランスポータブル・インポートの際、表領域は一時的に読取り/書込み可能になり、その後読取り専用に戻されます。これは、パフォーマンスを改善するために、Oracle Database 12cリリース1 (12.1.0.2)から導入された動作です。ただしこの動作では、インポート・ジョブのデータ・ファイルのSCNも変更されるため、それ以後、それらのファイルのトランスポータブル・インポート時に問題が発生する可能性があります。
たとえば、表領域が読取り/書込み可能になった後の任意の時点でトランスポータブル表領域インポートが失敗した場合(後で表領域が読取り専用に戻ったとしても)、該当のデータ・ファイルは破損します。これらはリカバリできません。
回避策: トランスポータブル・ジョブは再起動できないため、失敗したジョブを最初から再起動する必要があります。破損したデータ・ファイルを削除し、フレッシュ・バージョンをターゲット宛先にコピーする必要があります。
トランスポータブル・ジョブが実行されたら、インポート・ジョブがターゲット・システム上で正常に完了するまで、ソース・システム上のデータ・ファイルのコピーを保持することをお薦めします。これにより、インポート・ジョブがなんらかの理由で失敗した場合にも、データ・ファイルの破損していないコピーを確保できます。
古い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またはUTF8データベースがあり、かつ外部表を使用したSQL*Loaderがロード・メソッドとして使用されている場合、表名に非ASCII文字が含まれていると、SQL*Loaderが失敗し、次のいずれかのエラーが報告されることがあります。
SQL*Loader-350: Syntax error at line n. Illegal combination of non-alphanumeric characters
ここで、nはSQL*Loader制御ファイル内の行を表します。または、
SQL*Loader-810: error creating external table: "*" ORA-03001: unimplemented feature
ここで、"*"はSQL*Loaderによって生成された外部表名を表します。
これは、制御ファイルでexternal_table=executeが指定されている場合か、エクスプレス・モードで外部表のデフォルト・ロード・メソッドが使用される場合(またはコマンドライン・パラメータexternal_table=executeによって強制的に使用される場合)に発生する可能性があります。
回避策: 表名が引用符で囲まれている場合は、SQL*Loaderの従来のパス・ロード・メソッドを使用することで、ロードが正常に機能することがあります。
Oracle Database 12cリリース1 (12.1)から、最大256Kのサイズの一時LOBがプログラム・グローバル領域(PGA)メモリーに配置されます。これは、PGAのメモリー消費増大につながる可能性があります。一部のワークロードでは、作成される一時LOBの数によって、ORA-4030エラーに遭遇することがあります。
回避策: イベント32761, level 16を設定して、インメモリーの一時LOBをオフにします。このイベントを設定することにより、一時LOBがディスクの一時セグメントに移動します。メモリー消費量は12.1より前のレベルになってしまいますが、ユーザーにとっては、インメモリーの一時LOBにはパフォーマンス上のメリットはありません。
この項では、Oracle Database In-Memoryに関する既知の不具合について説明します。
INMEMORY_MAX_POPULATE_SERVERSパラメータのデフォルト値は、インスタンスの起動時にPGA_AGGREGATE_LIMITパラメータから抽出されます。PGA_AGGREGATE_LIMITの見積りは、物理メモリーが把握される前のインスタンス起動時にオフになることがあります。インメモリー移入サーバー数を計算する際には、PGA_AGGREGATE_LIMITの50%のみが使用されます。各移入サーバーには500MBのPGAメモリーが必要なため、PGA_AGGREGATE_LIMITパラメータ(デフォルトでは2 * PGA_AGGREGATE_TARGET)は1GBで乗算され、移入サーバーの数が決定されます。これは、インメモリー列ストアをタイムリに移入するには不十分な場合があります。
回避策: 初期化パラメータ・ファイルで、PGA_AGGREGATE_LIMITまたはPGA_AGGREGATE_TARGETパラメータの値を、ご使用のシステムでサポートできる適切な値に指定します。たとえば、PGA_AGGREGATE_LIMITを、1 GB * #POPULATE_SERVERSと同じか、またはそれより大きい値に設定します。
MEDIAN関数を必要とする問合せを、インメモリー列ストアに対して実行した場合、間違った結果が返されることがあります。
回避策: INMEMORY_QUERYパラメータをDISABLEに設定して、インメモリー列ストアの使用をセッション・レベルで無効にするか、NO_INMEMORYヒントを使用して、インメモリー列ストアを文レベルで無効にします。
マルチテナント環境では、マルチテナント・コンテナ・データベース(CDB)に対して、1チャンクのメモリーと1セットのバックグラウンド・プロセスのみを割り当てることができます。そのCDB内のすべてのプラガブル・データベース(PDB)はメモリーを共有し、(それゆえ)インメモリー(IM)列ストアも共有します。GV$INMEMORY_AREAビューは、PDB全体のIM列ストアでどれだけのメモリーが使用され、使用可能かを示します。GV$INMEMORY_AREAビューでは、1つのPDBによって使用される容量が、すべてのPDBによって使用される容量として誤って示されます。
回避策: マルチテナント環境のIM列ストア内で使用される総容量を計算するには、PDB当たりの値をすべて加算するのではなく、GV$INMEMORY_AREAビューで1つのPDBの値のみを見ます。
この項では、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の数と同じであることを確認します。
この項では、Oracle Data Guardロジカル・スタンバイ・データベースに関する既知の不具合について説明します。
入力済の索引構成表(IOT)でのピース単位のLOB更新は、ロジカル・スタンバイ・データベースではレプリケートされません。SQL Applyは、REDOストリーム内でこのような変更に遭遇した場合、ORA-1403を返して停止します。
回避策: ロジカル・スタンバイでDBMS_LOGSTDBY.SKIPプロシージャを使用して、表のレプリケートをスキップします。
この項では、Oracle Grid Infrastructureに関する既知の不具合について説明します。
add workingcopyコマンドで-storagetypeオプションを使用しても、高速ホーム・プロビジョニングで管理されるストレージ・タイプを指定することはできません。
回避策: 高速ホーム・プロビジョニングで管理されるストレージ・タイプを、グリッド・ホーム・サーバーとグリッド・ホーム・クライアントの両方に対して指定するには、rhpctl add workingcopyコマンドを実行する際に、次のいずれかを実行します。
グリッド・ホーム・サーバーの作業用コピーをプロビジョニングするには、rhpctl add workingcopyコマンドを-storagetypeオプションなしで指定します。
グリッド・ホーム・クライアントの作業用コピーをプロビジョニングするには、rhpctl add workingcopyコマンドを-storagetypeオプションと-pathオプションなしで指定します。
高速ホーム・プロビジョニングを使用してリリース10.2.0.5のデータベースをプロビジョニングするには、前提要件としていくつかの手順を実行する必要があります。
回避策: リリース10.2.0.5のデータベースを高速ホーム・プロビジョニングでプロビジョニングする前に、次のことを確認します。
リリース10.2.0.5のデータベースをプロビジョニングするクラスタ・ノードがピニングされている必要があります。クラスタ・ノードをピニングするには、crsctl pin cssコマンドを使用します。
SQLNET.ALLOWED_LOGON_VERSION=8を
$crs home/network/admin/sqlnet.oraファイルに設定します。
ロール別の環境で、11.2.0.2バージョンの作業用コピーを高速ホーム・プロビジョニングによってプロビジョニングする際には、中央インベントリにあるinstall.platformファイルにアクセスするための権限が不十分なために、クローン・ステージの途中で操作が失敗することがあります。
回避策: すべてのクラスタ・ノードで、中央インベントリの場所からorainstRoot.shスクリプトをrootユーザーとして再実行し、プロビジョニング操作を再試行します。
高速ホーム・プロビジョニングのランタイム環境は、深刻な障害(ゴールド・イメージや作業用コピーに関連付けられたディスク・グループが喪失するなど)が起こった場合のために、リセットする必要があります。
回避策: 次の手順を実行します。
次のコマンドを使用して、高速ホーム・プロビジョニング・サーバーを停止します。
$ srvctl stop rhpserver
srvctl status mgmtdbコマンドを実行し、管理データベースが実行されているノードをメモします。
手順2で確認したノードに、Oracle Grid Infrastructureユーザーとしてログインします。
次のコマンドを使用して、環境変数を設定します。
$ setenv ORACLE_HOME <GI_home> $ setenv ORACLE_SID -MGMTDB
次のコマンドを使用して、管理データベースに接続します。
$ <GI_home>/bin/sqlplus / as sysdba
次のSQL文を実行します。
SQL> DROP USER ghsuser CASCADE; SQL> CREATE USER ghsuser IDENTIFIED BY "ghsuser" DEFAULT TABLESPACE sysgridhomedata QUOTA UNLIMITED ON sysgridhomedata ACCOUNT LOCK PASSWORD EXPIRE; SQL> GRANT CREATE SESSION, ALTER SESSION, RESOURCE to GHSUSER;
次のコマンドを実行します。
$ mgmtca setpassword -user gridhome
|
注意: 前述のアクションを実行すると、すべてのイメージ、作業用コピー、クライアント、ユーザーなどについて、高速ホーム・プロビジョニング・サーバーのメタデータが削除されます。前述のアクションを進める前に、これが意図的な削除であることを十分に理解してください。 |
Oracle Grid Infrastructureリリース12cのインストール中に、Oracle ASMデバイス・チェックで前提条件の警告エラー・メッセージPRVG-5150が表示されることがあります。このエラー・メッセージには、Windowsプラットフォーム上には存在しない/etc/multipath.confファイルに対する読取りアクセスを提案します。
回避策: エラー・メッセージを無視し、/etc/multipath.confファイルに対する読取りアクセスを選択しないようにします。
高速ホーム・プロビジョニング機能によってプロビジョニングされたデータベースについては、SYSおよびSYSTEMスキーマへのパスワードを確認することはできません。
回避策: データベースを作成する際、高速ホーム・プロビジョニング機能では、データベース内のSYSスキーマとSYSTEMスキーマの両方に、ランダム・パスワードが使用されます。これらのパスワードを取得することはできません。DBAまたはオペレータ・ロールのユーザーが、データベースの実行元のノードからデータベースにローカルに接続して、これら2つのアカウントへのパスワードを目的の値にリセットする必要があります。
この項では、Oracle Real Application Clusters (Oracle RAC)に関する既知の不具合について説明します。
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
この項では、Oracle Textに関する既知の不具合について説明します。
データベースでシステム・グローバル領域(SGA)のメモリーが不足している場合、CTX_ENTITYを使用した操作は次のエラーによって失敗します。
DRG-13710: Syntax Error in Dictionary ORA-20000: Oracle Text error: DRG-50611: Third party lexer internal error: ANL code internal error
アラート・ログにはORA-04031が記録されます。
回避策: SGAメモリーを増やすか、ALTER SYSTEM FLUSH SHARED_POOLを使用して共有プールをフラッシュします。
この項では、Oracle Universal Installer (OUI)に関する既知の不具合について説明します。
インストールとアップグレードに関するその他の問題について、3.1項「互換性、アップグレード、ダウングレードおよびインストール」も参照してください。
GSMのインプレース・アップグレードは、INS-32025エラーによって失敗します。選択したインストールが、指定のOracleホームですでにインストールされているソフトウェアと競合します。
回避策: 次の手順を実行して、GSMソフトウェアをバージョン12.1.0.1から12.1.0.2にアップグレードします。
既存の12.1.0.1 GSMによって起動されたすべてのプロセスとサービスを停止します。
環境変数ORACLE_HOMEおよびORACLE_BASEを、既存の12.1.0.1 GSMのホームとベースにそれぞれ設定します。
実行します: cd $ORACLE_HOME
実行します: mv jdk jdk.bkp
実行します: mv QOpatch/qopiprep.bat QOpatch/qopiprep.bat.bkp
12.1.0.2 GSMインストーラを呼び出して、既存のGSMホームでソフトウェアをアップグレードします。
Oracle Management Server構成を使用したスタンドアロン・サーバー・ホーム用のOracle Grid Infrastructureを削除する際、emConfig.txt内のORACLE_BASE/admin/emcaファイルが削除されません。
回避策: emConfig.txtを削除するには、次のコマンドを実行します。
rm -rf $ORACLE_BASE/admin/emca/emConfig.txt
最後のORACLE_HOMEを削除する際、ORACLE_BASEを削除するには、削除ツールの終了後に次のコマンドを実行します。
rm -rf $ORACLE_BASE
自動スクリプトを使用してOracle Grid Infrastructureをインストールし、最初のOracle ASM Dynamic Volume Manager (Oracle ADVM)ボリュームを作成する際に、Oracle ADVMプロキシがタイムリに起動されず、最初のノードでのボリューム作成リクエストが提供されないことがあります。
回避策: 最初のボリュームを作成する前に、次のコマンドを実行します。
srvctl add asm -proxy srvctl start asm -proxy
Oracle RACのインストールを実行する際、指定されたノードとの接続問題により、runInstaller操作の実行時にAttachHomeが失敗することがあります。その場合は、失敗したノードと、詳細情報が記録された中央インベントリ・ログへの参照を示すメッセージが返されます。
回避策: この問題を修正するには、次のコマンドを実行します。
<oracle_home>/oui/bin/runInstaller -attachHome -noClusterEnabled ORACLE_HOME=<oracle_home> ORACLE_HOME_NAME=<oracle_home_name> CLUSTER_NODES=<node_1, node_2, ...> -force "INVENTORY_LOCATION=<central_inventory_location>" LOCAL_NODE=<node_on_which_the_command_is_targeted_to_run>
Oracle Databaseインストーラは、管理オプションの指定画面でASMSNMPに対して指定したパスワードが正しいかどうかをチェックしません。構成を進めて間違ったパスワードを指定した場合、Oracle Enterprise Manager Cloud Controlは詳細を検出したり、Oracle ASMインスタンスを監視することができません。
回避策#1: 正しいパスワード(クラスタ用のOracle Grid Infrastructureのインストール時に指定されたのと同じパスワード)が、Oracle Databaseインストーラの管理オプションの指定画面で指定されていることを確認します。
回避策#2: Oracle Enterprise Manager Cloud Controlポータルで、Oracle ASMの資格証明画面に移動し、ASMSNMPに対する正しいパスワードを更新します。正しいパスワードがOracle Enterprise Manager Cloud Controlで保存されたら、Oracle ASMの監視が機能し始めます。
ポリシー管理型のデータベースに対して指定されたサーバー・プール名がクラスタ上にすでに存在する場合は、次のエラーによってインストーラが失敗します。
[INS-20802] Oracle Database Configuration Assistant failed.
回避策: インストーラを使用してクラスタ上に新しいポリシー管理型データベースを構成する際に、サーバー・プールに対して一意の名前を指定します。
12.1.0.2のクラスタ用Oracle Grid Infrastructureをインストールする際、Oracle Universal Installer (OUI)は、権限の不十分なOracle ASMディスクがリモート・ノードから選択されていないかどうかについて、検証も報告もしません。これは、Oracle ASMディスクの権限が不十分なノードではroot.shスクリプトが失敗するためです。
回避策: 権限の不十分なOracle ASMディスクがリモート・ノードから選択されていないことを確認します。クラスタ検証ユーティリティ(CVU)を使用すると、リモート・ノード上のディスクに十分な権限があるかどうかを検証できます。
中央インベントリの場所がクラスタの別のノードで違っている場合、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に関する既知の不具合について説明します。
簡素化されたJSON構文では、サイズの大きい(4K以上の) VARCHARデータ型はサポートされません。
回避策: RETURNING句では、JSON_VALUEまたはJSON_QUERYを使用します。
バイナリXMLデータを使用した表を、トランスポータブル表領域(TTS)を使用してエクスポート/インポートすることはサポートされていません。
回避策: Oracle Data Pumpの従来型パスのみを使用してデータを移動します。
リリース12.1にアップグレードする際、libclntsh.so.11.1ファイルに対してリンクされているクライアント・アプリケーションは、Oracle Solaris、HP-UX ItaniumまたはIBM AIXプラットフォームでの実行に失敗することがあります。その場合、次のようなエラー・メッセージが返されます。
referenced symbol count is undefined
回避策: クライアント・アプリケーションを、新しいlibclntsh.so.12.1ファイルに対して再リンクします。
Oracle Database 12cリリース1 (12.1)より前、ネームスペースのないXML要素をXML文書に挿入すると、新しく挿入された要素は、デフォルトのネームスペースが親要素内で定義されていれば、親要素のネームスペースに割り当てられますが、これは正しくありません。
Oracle Database 12cでは、新しい要素はxmlns=""を使用して挿入されます。
回避策: ありません。
サプリメンタル・ロギングは、REFカーソルにバインドされた変数を使用するXMLQuery更新用にはサポートされません。
回避策: レプリケートが必要なXMLType列または属性を更新する前に、REFカーソルの評価を非カーソル変数に格納し、その後、REFカーソルのかわりにこれらの変数を使用して列や属性を更新します。
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を使用してください。
この項では、ベンダーとオペレーティング・システムに関する既知の不具合について説明します。
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)
)
)
