| Oracle® Databaseプラットフォーム共通日本語README 11gリリース2 (11.2) B56292-21 |
|
 前 |
 次 |
|
注意: Oracle Database 11g リリース2 (11.2.0.2)を使用する場合は、このREADMEを参照してください。 |
READMEのこの項には、さらに次の項があります。
第4.2項「互換性、アップグレード、ダウングレードおよびインストール」
第4.3項「11.2.0.2で使用できないか制限されている機能」
第4.5項「Oracle Automatic Storage Management (Oracle ASM)」
第4.6項「Oracle Enterprise Manager Database Control」
第4.11項「Oracle Application Express」
第4.13項「Oracle Configuration Manager」
第4.15項「Oracle Internet Directory」
第4.18項「Oracle Real Application Clusters」
第4.19項「クラスタ用Oracle Grid Infrastructure」
第4.26項「Oracle Warehouse Builder」
命名体系では、次の点が変更されています。
フラッシュ・リカバリ領域の名称が高速リカバリ領域に変更されました。
Oracle interMediaの名称が、Oracle Database 11gリリース1 (11.1)でOracle Multimediaに変更されました。機能は同じで、名称のみが変更されました。
アップグレード前の処理、アップグレード後の処理、互換性および相互運用性の説明に関する最新の更新内容およびベスト・プラクティスについては、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 Grid Infrastructure 11gリリース2 (11.2.0.1)でOracle ACFSファイル・システムを使用していて、Oracle Grid Infrastructureを11gリリース2 (11.2.0.2)にアップグレードし、冗長なインターコネクトの使用を利用して1つ以上のプライベート・インタフェースをプライベート・ネットワークに追加する場合は、アップグレードした各クラスタ・メンバー・ノードでOracle ASMインスタンスを再起動する必要があります(Oracle Bug#9969133を参照)。
次の各項では、削除および構成解除の制限について説明します。詳細は、第4.36.2項「削除ツールに関する既知の不具合」を参照してください。
11201、11202、11203の場合
アップグレードした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
製品のホームから-homeオプションを指定してdeinstallツールを実行しようとすると、削除が失敗し、次のエラー・メッセージが表示されます。
$ ./deinstall -home /scratch/user_dir/oracle/product/11.2.0/dbhome_1 Error: invalid argument -home. Since the tool is run from inside an Oracle Home it will deinstall the home the tool is installed in. You cannot specify another home.
deinstallツールはOracleホーム内から実行されるため、-homeオプションを指定してdeinstallツールを実行することはできません。deinstallツールを実行できるのは、Oracleホーム内から./deinstallを指定した場合のみです。
Oracle Database 11gリリース2 (11.2)には、バージョン1から14のタイムゾーン・ファイルが付属しています。古いデータベースでバージョン14より新しいタイムゾーン・ファイルが使用されている場合は、データベースをアップグレードする前に、11.2に対応するタイムゾーン・ファイルのパッチを取得する必要があります。
SELECT VERSION FROM V$TIMEZONE_FILEを使用すると、Oracle Database 10gまたは11gデータベースの更新時にタイムゾーン・ファイルのバージョンを特定できます。タイム・ゾーン・ファイルのバージョンが11でない場合、アップグレード前情報ツール(utlu112i.sqlおよびDatabase Upgrade Assistantが使用する同等のもの)で警告が表示されます。この警告では、DBMS_DSTパッケージを実行してデータベースのタイム・ゾーン・バージョンを最新版にアップグレードし、さらにTIMESTAMP WITH TIME ZONEデータも更新するよう推奨されます。また、アップグレード前情報ツールでは、タイムゾーンのバージョンおよびそのアップグレードに関連するsys.database_propertiesに、3つの新しいデータベース・プロパティ(DST_PRIMARY_TT_VERSION、DST_SECONDARY_TT_VERSIONおよびDST_UPGRADE_STATE)が移入されます。DST_PRIMARY_TT_VERSIONプロパティには、使用中の実際のタイムゾーンのバージョンが記録されます。それ以外の2つのデータベース・プロパティは、DBMS_DSTパッケージを使用してタイムゾーンのバージョンをアップグレードする場合に使用されます。
リリース11.2.0.2では、11.2への移行後に現在のタイムゾーンのバージョンを保存するオプションが用意されています。たとえば、アプリケーションでTIMESTAMP WITH TIME ZONE型を使用している場合は、タイムゾーンのバージョンを最新のものにアップグレードするためにDBMS_DSTパッケージを実行する必要はありません。
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インスタンスに適用できます。
Oracle9i Databaseリリース2 (9.2)からOracle Database 11gリリース2 (11.2)へのアップグレード・スクリプトの実行中に、次のエラーが表示される場合があります。
ORA-27465: invalid value UTC for attribute DEFAULT_TIMEZONE
このエラーは、リリース9.2のデフォルトのタイムゾーン・ファイルに協定世界時(UTC)ゾーンがないために発生します。このメッセージはOracle Schedulerで生成されます。Oracle Schedulerでは、デフォルトでUTCタイムゾーンが選択され、リリース9.2のデフォルトのタイムゾーン・ファイルと照合されます。このエラー・メッセージは予想されているため、無視しても問題はありません。
|
注意: 高速リカバリの以前の名称はフラッシュ・リカバリでした。 |
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エラーが書き込まれ、追加の領域が使用可能になるまでアップグレードは停止されます。
実行中のDatabase Configuration Assistant (DBCA)は、この自動メモリー管理オプションにデフォルトで設定されます。アップグレードまたは手動でデータベースを作成する場合には、MEMORY_TARGETを初期化パラメータ・ファイルに指定できます。
Data Miningオプションを使用するデータベースを11.2.0.1から11.2.0.2にアップグレードする場合は、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スキーマおよび関連するオブジェクトを削除します。
Oracle Database 11gリリース2 (11.2)のクライアントまたはサーバーからOracle9i Databaseリリース(9.2.0.4以上)への接続はサポートされています。同様に、Oracle9iクライアント(リリース9.2.0.4以上)からOracle Database 11gリリース2 (11.2)への接続もサポートされています。
必要なフォントがシステムにインストールされていない場合は、Oracle Databaseのインストール時に、「バックアップおよびリカバリ・オプションの指定」画面が完全に表示されないことがあります。固定幅フォントのみがインストールされている場合は、この画面のバックアップ・ジョブ資格証明領域で、必要な情報を完全に指定できない可能性があります。この問題を回避するには、この画面では「自動バックアップを使用します」を選択しないでください。自動バックアップは、インストールが完了した後、Oracle Enterprise Manager 11g Database Controlを使用して有効化できます。
SQLアクセス・アドバイザ・リポジトリへの内部構造の変更により、データベースをアップグレードすると、既存のSQLアクセス・アドバイザ・タスクがすべて初期状態にリセットされます。このアクションにより、アップグレード前に正常に実行されたタスクに対するすべての推奨情報が効率的に削除されます。
アップグレード後、既存のSQLアクセス・アドバイザ・タスクを再実行して推奨情報をリストアできます。
リリース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の実行前に適用してください。
Oracle Database 11gリリース2 (11.2)では、Oracle Clusterwareのローリング・アップグレード・サイクル中に新しい前提条件チェックが行われます。この前提条件チェックが失敗した場合に関して、『Oracle Databaseアップグレード・ガイド』には次のように記載されています。
『Oracle Grid Infrastructureインストレーション・ガイド』の付録F.5.1のローリング・アップグレードの手順に従います。
提案されたこの解決策以外に、別の方法もあります。クラスタのすべてのノードを、ローリング以外の方法で同時にアップグレードできます。この解決策を選択すると、10.2.0.3.0パッチセットの要件を回避できます。
ORA-00600デッドロック・エラーを回避し、アップグレードの実行に必要な時間を最小限に抑えるには、アップグレード時にごみ箱を空にする必要があります(Oracle Bug#8632581を参照)。
このデッドロックを回避するには、データベースをアップグレードする前に、PURGE DBA_RECYCLEBIN文を使用し、アイテムおよび関連するオブジェクトをごみ箱から削除して、空き記憶域を解放します。
11.2.0.2.0をインストールするか11.2.0.2.0にアップグレードした後、またはOracle Clusterwareが再起動した後で、ora.acfs.registryリソースが不整合状態になる場合があります(Oracle Bug#9876173およびOracle Bug#9864447を参照)。
11.2.0.2.0の新規インストールが完了した後、投票ディスクまたはOracle Cluster Registry (OCR)、あるいはその両方がOracle ASMにある場合、ora.registry.acfsの値は次のようになります。
./crsctl status resource ora.registry.acfs NAME=ora.registry.acfs TYPE=ora.registry.acfs.type TARGET=ONLINE, ONLINE STATE=ONLINE, ONLINE
(ora.asmはSTATE ONLINE、TARGET ONLINEになります。)
一方、投票ディスクまたはOracle Cluster Registry (OCR)、あるいはその両方がOracle ASMにない場合、ora.registry.acfsの値は次のようになります。
./crsctl status resource ora.registry.acfs NAME=ora.registry.acfs TYPE=ora.registry.acfs.type TARGET=ONLINE , ONLINE STATE=OFFLINE, OFFLINE
(ora.asmはSTATE OFFLINE、TARGET OFFLINEになります。)
11.2.0.1.0から11.2.0.2.0へのアップグレードが完了すると、ora.registry.acfsのTARGETおよびSTATEは、11.2.0.2.0にアップグレードする前の11.2.0.1.0当時の値に設定されます。
Oracle Clusterwareを再起動すると、ora.registry.acfsの値は常に次のようになります。
./crsctl status resource ora.registry.acfs NAME=ora.registry.acfs TYPE=ora.registry.acfs.type TARGET=ONLINE , ONLINE STATE=ONLINE, ONLINE
(ora.asmはSTATE ONLINE、TARGET ONLINEになります。)
なんらかの処置を行う必要はありませんが、必要な場合はOracle ACFSを使用不可にし、コマンドacfsroot unregisterを入力します。このコマンドにより、ora.registry (およびora.drivers)リソースが完全に削除されます。
Oracle ClusterwareまたはOracle ASMをアップグレード、削除または直接停止する場合は、事前にOracle ACFSファイル・システムを手動でディスマウントする必要があります。また、Oracle ASM Dynamic Volume Manager (Oracle ADVM)上で実行しているOracle ACFS以外のファイル・システムも、手動でディスマウントしてください。システムを再起動するときも、このようにすることをお薦めします(Oracle Bug#8594128、Oracle Bug#9547527、Oracle Bug#9777741を参照)。
Oracle ClusterwareまたはOracle ASMのアップグレード、削除または直接停止の実行時には、Oracle Clusterware(またはOracle ASM)が正常に停止するように、すべてのOracle ACFSファイル・システムを手動でディスマウントしてからOracle Clusterwareを停止する必要があります。lsofとfuserコマンド(LinuxおよびUNIXの場合)またはhandleとwmicコマンド(Windowsの場合)を使用して、Oracle ACFSファイル・システムのアクティブなプロセスを識別します。これらのプロセスが確実にアクティブでなくなるようにするには、すべてのOracle ACFSファイル・システムをディスマウントし、Oracle Clusterwareの停止を発行します。このようにしないと、Oracle Clusterwareの停止時にOracle ACFSファイル・システムのアクティビティに関してエラーが発行される場合があり、Oracle Clusterwareの正常な停止を妨げることになります。
データ・ポンプ・エクスポート操作は、11.2.0.2へのアップグレードの一環としてDMSYSスキーマが削除されていないと機能しません(Oracle Bug#10007411を参照)。次のようなエラーがレポートされます。
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA ORA-39126: Worker unexpected fatal error in KUPW$WORKER.GET_TABLE_DATA_OBJECTS [] ORA-31642: the following SQL statement fails: BEGIN "DMSYS"."DBMS_DM_MODEL_EXP".SCHEMA_CALLOUT(:1,0,1,'10.01.00.05.00'); END; ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86 ORA-06512: at "SYS.DBMS_METADATA", line 1245 ORA-04063: package body "DMSYS.DBMS_DM_MODEL_EXP" has errors ORA-06508: PL/SQL: could not find program unit being called: "DMSYS.DBMS_DM_MODEL_EXP"
11.2.0.2へのアップグレードの事前チェックでは、アップグレード前に実行する必要があるアクションがレポートされます。
The DMSYS schema exists in the database.Prior to performing an upgrade Oracle recommends that the DMSYS schema, and its associated objects be removed from the database.Refer to the Oracle Data Mining Administration Guide for the instructions on how to perform this task.
この手順を実行するまで、データ・ポンプ・エクスポートは機能しません。
タイムゾーン・ファイルの最新バージョンを以前にインストールし、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グローバリゼーション・サポート・ガイド』も参照してください。
11.2.0.2から10.2.0.5へのダウングレード時に、catrelod.sqlが次の内部エラーで失敗します(Oracle Bug#9975586を参照)。
ORA-00600: internal error code, arguments: [17069]
この問題を回避するには、初期化パラメータ・ファイルに次のイベントを追加します。
event='logon trace name kra_options level 7'
spfileを使用する場合は、次のコマンドを発行します。
alter system set event='logon trace name kra_options level 7' scope=spfile;
インスタンスを再起動し、ダウングレード・スクリプトを続行します。ダウングレード終了後、初期化パラメータ・ファイルからイベントを削除します。
Database Controlが構成されている状態でデータベースをダウングレードするときは、次の事項に注意してください(Oracle Bug#9922349を参照)。
11.2.0.1から11.2.0.2へのアップグレードを行っていて、後で11.2.0.1にダウングレードする予定の場合、データベースのダウングレードの一部としてDatabase Controlをダウングレードするには、次のパッチを適用する必要があります。
11.2.0.1 PSU2バンドル
Oracle Bug#8795792用個別パッチ
Oracle Bug#10013976用個別パッチ
これらのパッチを適用しないと、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.2から11.2.0.1へのインプレース・ダウングレードの場合は、emdwngrd -restoreを実行する前にemca -restoreを実行する必要はありません。
次に、Oracle Database 11gリリース2 (11.2.0.2)で使用できない、または制限されているコンポーネントのリストを示します。
Database Controlからのパッチの適用は非推奨になり、使用できなくなりました。
クラスタ用Oracle Grid Infrastructure 11.2.0.1が非共有Oracleホームにインストールされ、クラスタ用Oracle Grid Infrastructure 11.2.0.2が共有Oracleホームにインストールされている場合、Oracle Databaseリリース11.2.0.1から11.2.0.2クラスタウェアへのアップグレードはサポートされません(Oracle Bug#10074804を参照)。11.2.0.1と11.2.0.2は、両方とも共有Oracleホームにインストールするか、または両方とも非共有Oracleホームにインストールする必要があります。
すべてのOracle Grid Infrastructureパッチセット・アップグレードは、アウトオブプレース・アップグレードになります。この場合、パッチセットは新規のOracle Gridホームにインストールしてください(Oracle Bug#10210246を参照)。インプレース・パッチセット・アップグレードはサポートされていません。
データベース・スマート・フラッシュ・キャッシュはSolarisおよびOracle Linuxでのみサポートされます。
次の製品では、インターネット・プロトコル・バージョン6 (IPv6)の使用はサポートされていません。
Oracle RACおよびOracle Clusterware
Oracle Fail Safe
Oracle Ultra Searchのサポートは終了しているため、Oracle Database 11gリリース2 (11.2)には付属しません。
Oracle Database 11gリリース2 (11.2)からリリース10.2.0.3またはリリース10.2.0.4へのダウングレードは、Oracle Database Vaultではサポートされていません。
Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)リソースは、すべてのプラットフォームのOracle Restart構成でサポートされていません。Oracle ACFSドライバは、手動でアンロードおよびロードする必要があります。Oracle ACFSファイル・システムは、手動でアンマウントおよびマウントする必要があります(Oracle ASMインスタンスが実行中の状態になった後)。Oracle ACFSデータベース・ホームのファイル・システムは、登録済の他のOracle ACFSファイル・システムとともにOracle ACFSマウント・レジストリに置くことができます。
Oracle ACFSレプリケーションは、Oracle Restartではサポートされていません。
Oracle Secure Backupにおけるグローバリゼーションの制限事項は、第4.10.1項を参照してください。
Oracle Data Miningで使用できなくなった機能の詳細は、第4.14項を参照してください。
Security-Enhanced Linux (SELinux)は、Oracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)ファイル・システムではサポートされていません。
次の各項では、追加の制限事項について説明します。
この項では、Oracle Database 11gリリース2 (11.2)と旧リリースのデータベースの動作の違いをいくつか説明します。アップグレードおよびダウングレードに関する大部分の情報は、『Oracle Databaseアップグレード・ガイド』に記載されています。
直接挿入では、ロードされるすべてのパーティションでメモリーが必要です。メモリー使用量は、パーティションが圧縮される場合に非常に大きくなります。以前のリリースでは、すべてのパーティションがロードされるかメモリー不足になるまで、ロードされていないパーティションの行が取得されるため、直接挿入ではメモリーの割当てが続行されていました。この場合は、挿入が失敗します。
Oracle Database 11gリリース2 (11.2)からは、直接挿入で割り当てられるメモリーが制限されるようになりました。直接挿入で制限に達し、挿入中にロードされなかったパーティションの行が取得されると、これらの行は直接ロードによって一時表領域に格納されます。すべての行が渡されると、一時表領域に格納されている行が直接ロードによってロードされます。
デフォルトの監査動作の変更は次のとおりです。
監査ファイル名にインスタンス名の接頭辞が付き、最後に順序番号が付くようになりました。次に例を示します。
instanceName_ora_pid_seqNumber.aud / instanceName_ora_pid_seqNumber.xml
既存の監査ファイルに追加されるものがなくなりました。監査ファイルがすでに存在する場合は、順序番号が増分し、instanceName_ora_pid_seqNumber+1.audに書き込まれます。
監査ファイルの増加に事前構成済のしきい値があります。アクティブなセッションに関連付けられている監査ファイルは、次の制限値のいずれかに達するまで開いたままです。
監査レコードが書き込まれると、監査ファイルのサイズは10MB以上になります。
監査レコードが書き込まれると、監査ファイルの期間は5日以上になります。
これらのしきい値のいずれかに達すると、増分した順序番号が付いた新しい監査ファイルが追加の監査レコード用に開かれます。
AUD$への更新はなくなりました。
すべてのログオフ(アクション#101)監査レコードは個別に書き込まれます。
イベントがBY SESSIONで監査される場合は、イベントが発生するたびに、AUD$の新しい監査レコードになります。
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 Universal Installer (OUI)およびDatabase Configuration Assistant (DBCA)では、RAWデバイス(Linuxではブロック・デバイス)がサポートされません。ただし、SQL*PlusやCRSCTLなどのコマンドライン・ユーティリティでは、RAWデバイスまたはブロック・デバイスがサポートされます。
Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)は、Grid_homeと呼ばれる単一のOracleホームにインストールされます。このインストールは、クラスタ用Oracle Grid Infrastructureインストールと呼ばれます。
アップグレードする場合は、Oracle ClusterwareとOracle ASMの両方を同時にアップグレードする必要があります。
次の初期化パラメータは、Oracle ASMインスタンスでは非推奨です。
CLUSTER_DATABASEパラメータ
INSTANCE_TYPEがOracle ASMで、Oracle RACオプションがオンになっている場合は、CLUSTER_DATABASEパラメータを指定する必要はありません。この場合、CLUSTER_DATABASEパラメータはTRUEにデフォルトで設定されます。
COMPATIBLEパラメータ
Oracle ASMインスタンスでは、COMPATIBLEパラメータを設定しないでください。ディスク・グループの互換性を拡張するには、ディスク・グループの
COMPATIBLE.[RDBMS|ASM|ADVM]属性を変更します。
Oracle ASMインスタンスのすべてのパラメータ・ビュー(例: V$PARAMETER)でレポートされるのは、Oracle ASMインスタンスに関連するパラメータのみです。
Oracle Database 10gリリース1 (10.1)から、CLOBまたはNCLOBに書き込むAPIでは、書込みの最初に指定されたオフセットが既存のLOBデータの文字境界上にない場合は、ORA-22831エラーが発生します。
データベースのデフォルト・キャラクタ・セットまたは各国語キャラクタ・セットがマルチバイトの場合、LOB APIでは、CLOBsまたはNCLOBsに対するamountパラメータとoffsetパラメータにUCS2コードポイント・セマンティクスが使用されます。サロゲート・ペアの下位(2番目)サロゲートが指定されている場合、指定されたオフセットは文字境界上にありません。そのような場合には、エラーORA-22831が発生してデータは書き込まれません。これにより、ターゲットLOB内の文字の破損が回避されます。
ORA-22831が戻されないようにデータベースを構成する場合は、Oracleサポート・サービスに連絡してください。
ダイレクト・パスのINSERTを使用して多数のパーティションをロードすると、特にデータ圧縮が指定されている場合にメモリー制限を超える場合があります(Oracle Bug#6749894を参照)。メモリーを確保するために、11.2からはPGA_AGGREGATE_TARGET初期化パラメータに基づいて、同時にロードされるパーティションの数が制限されるようになりました。ロード中のパーティションに格納されない行は、一時表領域に保存されます。パーティションの現在のセットですべての行がロードされた後に、一時表領域に保存されている行から他のパーティションがロードされます。
この動作により、不十分なメモリーによりダイレクト・パスのINSERTが終了することがなくなりました。
Oracle Database 11gリリース2 (11.2)では、不均一なメモリー・アクセスのサポートがデフォルトで無効になりました。この制限は、すべてのプラットフォームおよびオペレーティング・システムに適用されます(Oracle Bug#8450932を参照)。
Oracle Databaseで不均一なメモリー・アクセスの最適化およびサポートが使用できるのは、特定の組合せのOracleバージョン、オペレーティング・システムおよびプラットフォームのみです。不均一なメモリー・アクセスのサポートを有効にするには、Oracleサポート・サービスとハードウェア・ベンダーを使用してください。
次の各項では、Oracle Database 11gリリース2 (11.2)のOracle Automatic Storage Management (Oracle ASM)に関する情報について説明します。
次の各項では、Oracle Database 11gリリース2 (11.2)のDatabase Controlについて説明します。
オブジェクトの再編成には次の内容が適用されます。
再編成スクリプトの生成からそのスクリプトの実行までの間にメタデータの変更が発生すると、データベースに悪影響を与える可能性があります。
再編成中の表に対してDDLが実行されている間にオフライン再編成が試行されると、データベースに悪影響を与える可能性があります。
Oracle Enterprise Managerでオブジェクトの再編成ウィザードまたはローカル管理表領域ウィザードを使用する前に、データベースをバックアップすることをお薦めします。
Oracle Enterprise Managerでは、オブジェクトを編集するためにオープンできるブラウザ・ウィンドウは1つのみです。たとえば、Oracle Enterprise Managerでは一度に1つの表領域のみを編集できます。
|
注意: ウィンドウが読取り専用の場合は、複数のブラウザ・ウィンドウをオープンできます。 |
Oracle Enterprise Manager Database Controlは、192MB (32ビット)/384MB (64ビット)のヒープ・メモリーで構成されます。ただし、Oracle Enterprise Manager Database Controlの特定の機能(変更マネージャなど)では、データベースに多数のオブジェクトが含まれる場合に、多くのメモリー設定が必要になる場合があります。
メモリー設定は、次のemctlコマンドを使用して増加できます。
emctl config dbconsole -heap_size MemorySizeValue M
新しい設定を適用するには、Oracle Enterprise Manager Database Controlを再起動する必要があります。
データベース・セキュリティの次の変更に注意してください。
|
注意: この設定は、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
暗号化と整合性に関する次の変更に注意してください。
既存の表領域をALTER TABLESPACE文を使用して暗号化することはできません。ただし、データ・ポンプ、またはCREATE TABLE AS SELECTやALTER TABLE MOVEのようなSQL文を使用して、既存の表データを暗号化された表領域に移動できます。
暗号化された表領域を使用してデータベースをリカバリする際(SHUTDOWN ABORTまたはデータベース・インスタンスを停止させる致命的なエラーの後など)には、リカバリ・プロセスがデータ・ブロックおよびREDOを復号化できるように、データベースのマウント後でデータベースをオープンする前にウォレットをオープンする必要があります。
透過的データ暗号化(TDE)表領域の暗号化のマスター暗号化キーでは、すべてのキー管理(作成、保存、回転、リタイアなど)にハードウェア・セキュリティ・モジュール(HSM)を利用します。11.1.0.7では、HSMでTDE表領域の暗号化マスター・キーの作成と保存しかできず、回転はできませんでした。TDE表領域の暗号化のマスター・キーは、Oracle WalletからHSMに移行することもできます。
Javaを使用する際は、次の事項に注意してください。
Oracle Database 11gリリース2 (11.2)には、すべての機能を持つJava仮想マシン(JVM)とSun社のJava Development Kit (JDK) 5.0用Javaクラス・ライブラリが組み込まれています。リリース11.2.0.2には、OracleのJDBCおよびSQLJとともに、サーバーベースJavaアプリケーションの開発とデプロイのためのエンタープライズ・クラス・プラットフォームであるOracle JVMが用意されています。次のサイトにあるOracle JVM READMEファイルを参照してください。
ORACLE_HOME/relnotes/readmes/README_javavm.txt
Oracle Database 11gリリース1 (11.1.0.7)から、JDBC用の新しいユニバーサル接続プールがリリースされています。詳細は、次のWebページにある『Oracle Universal Connection Pool for JDBC開発者ガイド』を参照してください。
http://www.oracle.com/technology/tech/java/sqlj_jdbc/UCP_dev_guide.pdf
このため、Oracle Database 10gリリース1(10.1)に導入されていた既存のJDBC接続プール(暗黙的な接続キャッシュ)は非推奨になっています。使用中のアプリケーションは、将来のリリースでサポート終了の通知が出され、正式にサポートが終了するまで引き続き使用できます。
Oracleでは、次のWebページにある『Transitioning to Oracle Universal Connection Pool (UCP)』の指示に従って、新しいアプリケーションにUCPを採用し、既存のアプリケーションの変更を計画するように推奨しています。
http://www.oracle.com/technology/tech/java/sqlj_jdbc/pdf/ucp_transition_guide.pdf
UCPのダウンロードおよびコード・サンプルは次のWebページにあります。
http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/ucp.html
Oracle JDBC製品は、最新のJava/JDBC標準をサポートしています。詳細は、次のサイトにあるJDBCのREADMEを参照してください。
ORACLE_HOME/relnotes/readmes/README_jdbc.txt
Oracle Netのかわりに、Oracle Database Web Servicesでは、標準のWebサービス・メカニズムを介して、非接続でのデータベースへのアクセスが提供されています。これには、XML、SOAPおよびWSDLが含まれ、データベースをWebサービス・プロバイダに転換できます。同様に、データベース自体が、Webサービス・コンシューマとして機能して外部のWebサービスを実行できます。Webサービスには、次の重要な機能があります。
SOAP Clientライブラリに基づくJAX-RPCは、外部Webサービスのデータベース内からの起動をサポートし、その結果に対してSQLの機能を適用します。
Webサービス・コールイン: JPublisherで生成されたJavaクラスをOracle Application Server 10gにデプロイすることで、JavaとPL/SQLのプロシージャとパッケージ、SQL問合せ、DML操作などのデータベース操作を実行できます。
Webサービス・コールアウト: WSDLとそのPL/SQLラッパーからJPublisherで生成されたWebサービス・クライアントをデプロイすることで、外部Webサービスのデータベース内からの起動がサポートされます。
単一のサーバーで構成される環境向けに、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.2)に同梱されています。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 Application Expressインストレーション・ガイド』を参照してください。
Oracle Application Expressは、Oracle Databaseより頻繁にリリースされています。最新のリリースの詳細を確認するには、次のサイトを参照してください。
http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html
新規インストールでOracle Application ExpressにOracle HTTP Serverを構成する場合は、データベース・ユーザーAPEX_PUBLIC_USERのアカウントのロックが解除されている必要があります。データベース・ユーザーAPEX_PUBLIC_USERのアカウントのロックを解除するには、次の手順を実行する必要があります。
SQL*Plusを起動して、Oracle Application ExpressがインストールされているデータベースにSYSとして接続します。次に例を示します。
$ ORACLE_HOME/bin/sqlplus SQL> CONNECT SYS as SYSDBA Enter password: SYS_password
次のコマンドを実行します。
SQL> ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK
『Oracle Databaseインストレーション・ガイド』でOracle Database 11gのネットワーク・サービスの有効化に関する項に記載されているOracle Application Expressのインストール後タスクの例を実行するには、データベースのCOMPATIBLE初期化パラメータが、少なくとも11.1.0.0.0に設定されている必要があります。Oracle Database 11gデータベースでは、デフォルトですでにパラメータが正しく設定されていますが、旧バージョンから11gにアップグレードされたデータベースでは設定されていない場合があります。
データベース初期化パラメータの変更の詳細は、『Oracle Database管理者ガイド』のOracle Databaseの作成および構成に関する項を参照してください。
Oracle Client 11gには、重大なエラーが検出された場合の診断情報のダンプ機能を含む、問題を診断するための拡張機能が含まれています。デフォルトでは、これらのダンプは小さいサブセットの情報に制限されるため、アプリケーション・データはダンプされません。しかし、多くのインストールでは、このようなログのプライバシを確保するために、ダンプ・ファイル用にセキュアな場所が構成される場合があります。このような場合は、フル・ダンプをオンにすることをお薦めします。これにより、問題解決までの時間が大幅に短縮します。フル・ダンプを有効にするには、Oracleクライアント・インストールで使用されるsqlnet.oraファイルに次の行を追加します。
DIAG_RESTRICTED=false
診断機能が正常に動作していることを確認するには、次の手順を実行します。
Oracle Database 11gクライアント・ライブラリを使用できるように、アプリケーションをアップグレードします。
アプリケーションを起動します。
アプリケーションのTNS_ADMINディレクトリのsqlnet.logファイルをチェックし、診断機能が起動できなかった(通常はディレクトリ名または権限が無効であることが原因)ことを示すエラー・メッセージを確認します。
詳細は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
Oracle Configuration Managerの次の内容に注意してください。
cronへのアクセスを拒否されると、次のエラーが表示され、Oracle Configuration Managerの構成が失敗します。
ORACLE_HOME/ccr/bin/setupCCR
** Installing base package **
Deploying core - Version 10.2.5.0.0
Error encountered in package deployment.
インストールの完了後、環境変数CCR_DISABLE_CRON_ENTRYをTRUEに設定し、次のコマンドを使用してOracle Configuration Managerの構成を再度試行します。
ORACLE_HOME/ccr/bin/setupCCR
Oracle Database 11gリリース2(11.2)のOracle Data Miningスコアリング機能は、Oracle Exadata Storage Serverソフトウェアでも使用できます。記憶域レイヤーのスコアリング機能により、膨大なデータセットを迅速にマイニングできるため、すでにOracle Database内の分析により得ている競争上の優位性をさらに高めることができます。Oracle Exadata Storage Serverソフトウェアの詳細は、http://www.oracle.com/technology/products/bi/db/exadata/index.htmlを参照してください。
データベースの組込み機能であるデータ・マイニング・オプションは、Oracle Database Enterprise Editionとともに自動的にインストールされます。データ・マイニング・オプションを使用するデータベースをインストールする場合は、デフォルトの初期化パラメータに最適なデータ・ウェアハウス構成タイプを選択します。
Oracle Database 11gでは、データ・マイニング・モデルはSYSスキーマのデータ・ディクショナリ・オブジェクトとして実装されます。DMSYSスキーマは存在しません。
Data Miningユーザーが独自のスキーマにマイニング・モデルを作成するには、CREATE MINING MODEL権限を持っている必要があります。『Oracle Data Mining管理者ガイド』に記載されているように、その他のデータ・マイニング・アクティビティを実行するには別の権限が必要です。
Oracle Database 11gリリース1 (11.1)には、Oracle Data Mining用の新しいデータ・ディクショナリ・ビューが導入されていました。
USER/ALL/DBA_MINING_MODELS
USER/ALL/DBA_MINING_MODEL_ATTRIBUTES
USER/ALL/DBA_MINING_MODEL_SETTINGS
Data Mining API (PL/SQLおよびJava)を説明するデモ・プログラムは、Oracle Database Examplesとともにインストールされます。手順は、『Oracle Data Mining管理者ガイド』に記載されています。
Oracle Database 10gで個別にインストールしたデータベース・オプションのOracle Data Miningスコアリング・エンジン・オプションは、Oracle Database 11gでは使用できません。Oracle Data Miningスコアリング・エンジン・オプションのすべての機能は、データ・マイニング・オプションで提供されます。
以前Oracle Data MiningでサポートされていたBasic Local Alignment Search Tool (BLAST)は、Oracle 11gでは使用できません。
Oracle Internet Directory製品は、Oracle Application Serverにのみ付属しています。Oracle Database 11gリリース1 (11.1)製品には付属していません。ただし、Oracle Net Services、Oracle Advanced Securityの機能がOracle Internet Directoryを使用することがあるため、ここにOracle Internet Directoryの情報を記載しています。Oracle Internet Directoryの管理アクティビティの多くは、1つのツールOracle Internet Directory Configuration Assistant (OIDCA)に統合されました。OIDCAは、次の条件でエンタープライズ・ユーザー・セキュリティおよびNetwork Names機能と併用してください。
エンタープライズ・ユーザー・セキュリティ
エンタープライズ・ユーザー・セキュリティは、リリース11.2.0.2のアイデンティティ管理レルムでのみ動作します。以前のリリースで使用していたOracleコンテキストは、OIDCAツールを使用してアイデンティティ管理レルムに変換する必要があります。
使用環境でOracle Internet Directoryサーバーを検出するためのldap.ora構成ファイルを作成または更新する場合は、OIDCAを使用します。OIDCAを使用して作成した場合、ldap.oraは、LinuxおよびUNIXオペレーティング・システムではORACLE_HOME/ldap/adminディレクトリに、Windowsオペレーティング・システムではORACLE_HOME\ldap\adminディレクトリに配置されます。
Network Names
Oracleコンテキストを作成、アップグレードおよび削除する場合は、OIDCAを使用します。
初期のリリースのOracleコンテキストをアイデンティティ管理レルムに変換する場合は、OIDCAを使用します。
使用環境でOracle Internet Directoryサーバーを検出するためのldap.ora構成ファイルを設定する場合は、OIDCAを使用します。
Oracle Internet Directoryを使用する際は、次の事項に注意してください。
Oracle Internet Directory Configuration Assistant (OIDCA)を使用すると、Oracleコンテキストの作成、アップグレードおよび削除、ldap.oraファイルの構成、およびOracleコンテキストからアイデンティティ管理レルムへの変換を実行できます。
OIDCAの構文は、次のとおりです。
oidca oidhost=host nonsslport=port | sslport=SSL Port dn=binddn pwd=bindpwd propfile=properties file
OIDCAの使用方法を確認するには、コマンド・プロンプトにoidca -helpを入力してください。
OIDCAでOracleコンテキストを作成するには、次の構文を使用します。各パラメータについては、後続の表を参照してください。
oidca oidhost=host
nonsslport=port
sslport=SSL Port
dn=binddn
pwd=bindpwd
mode=CREATECTX
contextdn=OracleContext DN
| パラメータ | 説明 |
|---|---|
oidhost |
OIDサーバーのホスト(未指定の場合、デフォルトはlocalhostです) |
nonsslport |
OIDサーバーのポート(未指定の場合、デフォルトは389です) |
sslport |
OID SSLポート(未指定の場合、デフォルトは636です) |
dn |
OIDユーザー(cn=orcladminのように指定します) |
pwd |
OIDユーザー・パスワード |
mode |
OIDCAのモード(CREATECTXに設定します) |
contextdn |
OracleContextを作成する必要があるDN (dc=acme、dc=comのように指定します) |
次の点に注意してください。
この操作を正常に実行するには、contextdnが必要です。
OIDには、有効なDN"cn=oraclecontext,dc=acme, dc=com"を指定しないでください。
OIDには、有効なDN"dc=acme,dc=com"が必要です。
modeおよびcontextdnパラメータは、プロパティ・ファイルとして渡すこともできます。
非SSLモードで操作を実行する場合は、パラメータnonsslport=portを指定します。
SSLモードで操作を実行する場合は、パラメータsslport=sslportを指定します。
nonsslportまたはsslportパラメータのいずれかを指定する必要があります(ただし、両方は指定しないでください)。
機能
OIDCAは、contextdnに有効なDN構文があり、Oracle Internet Directoryにエントリがあることを検証します。OIDCAでは、ルートOracleContextを明示的に作成できないことに注意してください。ルートOracleコンテキストがない場合、OIDCAはエラーで終了します。
DNがある場合は、Oracleコンテキストの存在が検証されます。
最新のOracleコンテキストがすでに存在している場合は、「Oracle Context already exists and is up to date」のメッセージが出力され、OIDCAが終了します。
古いバージョンのOracleコンテキストがすでに存在している場合は、「Oracle Context already exists and is of an older version」のメッセージが出力され、OIDCAが終了します。
Oracleコンテキストがない場合は、このDNにOracleコンテキストが作成されます。
OracleContextインスタンスをアップグレードするには、次の構文を使用します。各パラメータについては、後続の表を参照してください。
oidca oidhost=host nonsslport=port sslport=SSL Port dn=binddn pwd=bindpwd mode=UPGRADECTX contextdn=OracleContext DN
| パラメータ | 説明 |
|---|---|
oidhost |
OIDサーバーのホスト(未指定の場合、デフォルトはlocalhostです) |
nonsslport |
OIDサーバーのポート(未指定の場合、デフォルトは389です) |
sslport |
OID SSLポート(未指定の場合、デフォルトは636です) |
dn |
OIDユーザー(cn=orcladminのように指定します) |
pwd |
OIDユーザー・パスワード |
mode |
OIDCAのモード(常にUPGRADECTXに設定します) |
contextdn |
OracleContextを作成する必要があるDN (dc=acme、dc=comのように指定します) |
次の点に注意してください。
この操作を正常に実行するには、contextdnにOracleContextが含まれている必要があります。
"cn=oraclecontext,dc=acme,dc=com"および"dc=acme,dc=com"のDNは、両方とも有効です。
modeおよびcontextdnパラメータは、プロパティ・ファイルとして渡すこともできます。
非SSLモードで操作を実行する場合は、パラメータnonsslport=portを指定します。
SSLモードで操作を実行する場合は、パラメータsslport=sslportを指定します。
nonsslportまたはsslportパラメータのいずれかを指定する必要があります(ただし、両方は指定しないでください)。
機能
OIDCAは、contextdnに有効なDN構文があり、Oracle Internet DirectoryにOracleContextがあることを検証します。OIDCAでは、ルートOracleContextを明示的にアップグレードできません。ルートOracleContextがない場合は、エラー・メッセージが送信されます。
contextdnにOracleContextがある場合は、次の操作が実行されます。
OracleContextがレルムに属しているかどうかが検証され、適切なメッセージが出力されてOIDCAが終了します。レルムに属しているOracleContextインスタンスは、アップグレードできないことに注意してください。
OracleContextが最新であることが確認された場合は、「Oracle Context already exists and is up to date」のメッセージが出力され、OIDCAが終了します。
OracleContextが最新でない場合は、このDNでOracleContextがアップグレードされます。
OracleContextを削除するには、次の構文を使用します。各パラメータについては、後続の表を参照してください。
oidca oidhost=host nonsslport=port sslport=SSL Port dn=binddn pwd=bindpwd mode=DELETECTX contextdn=OracleContext DN
| パラメータ | 説明 |
|---|---|
oidhost |
OIDサーバーのホスト(未指定の場合、デフォルトはlocalhostです) |
nonsslport |
OIDサーバーのポート(未指定の場合、デフォルトは389です) |
sslport |
OID SSLポート(未指定の場合、デフォルトは636です) |
dn |
OIDユーザー(cn=orcladminのように指定します) |
pwd |
OIDユーザー・パスワード |
mode |
OIDCAのモード(常にDELETECTXに設定します) |
contextdn |
OracleContextを作成する必要があるDN (dc=acme、dc=comのように指定します) |
次の点に注意してください。
この操作を正常に実行するには、contextdnにOracleContextが含まれている必要があります。
"cn=oraclecontext, dc=acme,dc=com"および"dc=acme,dc=com"のDNは、両方とも有効です。
modeおよびcontextdnパラメータは、プロパティ・ファイルとして渡すこともできます。
非SSLモードで操作を実行する場合は、パラメータnonsslport=portを指定します。
SSLモードで操作を実行する場合は、パラメータsslport=sslportを指定します。
nonsslportまたはsslportパラメータのいずれかを指定する必要があります(ただし、両方は指定しないでください)。
機能
OIDCAは、contextdnに有効なDN構文があり、Oracle Internet DirectoryにOracleContextがあることを検証します。
contextdnにOracleContextがある場合は、次の操作が実行されます。
OracleContextがレルムに属しているかどうかが検証され、適切なメッセージが出力されてOIDCAが終了します。レルムに属しているOracleContextインスタンスは、削除できないことに注意してください。
OracleContextは、レルムに属していない場合は削除されます。
ldap.oraファイルを構成するには、次の構文を使用します。各パラメータについては、後続の表を参照してください。
oidca oidhost=host nonsslport=port sslport=SSL Port adminctx=Administrative context mode=LDAPORA dirtype=OID or AD -update
| パラメータ | 説明 |
|---|---|
oidhost |
OIDサーバーのホスト(未指定の場合、デフォルトはlocalhostです)。 |
nonsslport |
OIDサーバーのポート(検出APIを使用して判断されます)。 |
sslport |
OIDのSSLポート(検出APIを使用して判断されます)。 |
mode |
OIDCAのモード(常にLDAPORAに設定します)。 |
dirtype |
ディレクトリ・タイプ(可能な値はOIDおよびADで、必須属性です)。 |
adminctx |
デフォルトの管理コンテキスト(dc=acme,dc=comのように指定します)。未指定の場合は、検出APIを使用して判断されます。 |
-update |
このフラグを指定すると、既存のldap.oraが上書きされ、このフラグを指定しないと、ldap.oraは、存在していない場合のみ作成されます。 |
次の点に注意してください。
非SSLまたはSSLのいずれかのポートを指定する必要があります。その他のポートは検出されます。
mode、dirtypeおよびadminctxパラメータは、プロパティ・ファイルとして渡すこともできます。
機能
検出APIを使用して、コマンドラインに指定されていないパラメータすべてが判断されます。
検出APIを使用して、ldap.oraの位置が検証されます。
ldap.oraがあり、-updateパラメータが指定されていない場合は、「ldap.ora exists」のメッセージが出力され、OIDCAが終了します。
ldap.oraがあり、-updateパラメータが指定されていない場合は、検出APIを使用して既存のldap.oraが更新されます。
ldap.oraが存在しない場合は、次の順序で適切な位置に新しいldap.oraファイルが作成されます。
LDAP_ADMIN
ORACLE_HOME/ldap/admin
Oracle Database 10gのエントリは、Oracle Internet Directoryリリース9.0.4サーバーに格納する必要があります。エンタープライズ・ユーザー・セキュリティ(Oracle Database 10gの機能)にも、リリース9.0.4のアイデンティティ管理レルムが必要です。
既存のOracleContextをアイデンティティ管理レルムに変換するには、次の構文を使用します。各パラメータについては、後続の表を参照してください。ルートOracleContextオブジェクトは変換されないことに注意してください。
oidca oidhost=host nonsslport=port sslport=SSL Port dn=binddn pwd=bindpwd mode=CTXTOIMR contextdn=OracleContext DN
| パラメータ | 説明 |
|---|---|
oidhost |
OIDサーバーのホスト(デフォルトはlocalhostです) |
nonsslport |
OIDサーバーのポート(デフォルトは389です) |
sslport |
OIDのSSLポート(デフォルトは636です) |
dn |
OIDユーザー(cn=orcladminのように指定します) |
pwd |
OIDユーザー・パスワード |
mode |
OIDCAのモード(常にCTXTOIMRに設定します) |
contextdn |
OracleContextを作成する必要があるDN (dc=acme、dc=comのように指定します) |
次の点に注意してください。
指定したcontextdnにOracleContextが存在している必要があります。
"cn=oraclecontext, dc=acme,dc=com"および"dc=acme, dc=com"のDNは、両方とも有効です。
modeおよびcontextdnパラメータは、プロパティ・ファイルとして渡すこともできます。
非SSLモードで操作を実行する場合は、パラメータnonsslport=portを指定します。
SSLモードで操作を実行する場合は、パラメータsslport=sslportを指定します。
nonsslportまたはsslportパラメータのいずれかを指定する必要があります(ただし、両方は指定しないでください)。
機能
OIDCAは、contextdnのDN構文が正しいこと、および有効なOracleContextが含まれていることを検証します。
contextdn,にOracleContextがある場合は次の操作が実行されます。
OracleContextがレルムに属しているかどうかが検証されます。属している場合は、適切なエラー・メッセージが出力され、OIDCAが終了します。
OracleContextがレルムに属していない場合は、コンテキストが最新バージョンにアップグレードされてレルムに変換されます。
注意(補足):
ニックネーム属性がcnでない場合は、Oracle Internet Directoryセルフ・サービス・コンソールを使用して、この属性をユーザー構成属性として構成してください。
Oracle Internet Directoryセルフ・サービス・コンソールを使用して、変換されたレルムのユーザーおよびグループを管理する場合は、適切な管理権限を設定する必要があります。詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。
Oracle interMediaの名称が、Oracle Database 11gリリース1 (11.1)でOracle Multimediaに変更されました。機能は同じで、名称のみが変更されました。Oracle interMediaへの参照はOracle Multimediaに置き換えられますが、Oracle interMediaやinterMediaへの参照が、グラフィカル・ユーザー・インタフェース、コード・サンプル、および11gリリース2 (11.2)のOracle Databaseドキュメント・ライブラリの関連ドキュメントに一部残っている場合があります。
その他の情報は、次のOracle MultimediaのREADMEファイルを参照してください。
ORACLE_HOME/ord/im/admin/README.txt
Oracle Databaseでは、インターネット・プロトコル・バージョン6 (IPv6)のアドレッシングおよび接続性のサポートが制限されます。詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
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ホーム・ディレクトリの場合は、この手順を実行する必要はありません。
|
注意: デフォルトでは、名前付きユーザーは誰でもサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するために、特定のユーザーをCRS管理者リストに追加することをお薦めします。CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
ポリシー管理型のOracle RACデータベースを使用する場合は、クラスタ用Oracle Grid Infrastructureのインストールの直後に、ユーザー定義の初期サーバー・プールを作成します。Gridソフトウェアの所有者として、Grid_home/binのパスにある次のSRVCTLコマンドを使用します。
srvctl add srvpool -g srvpool_name -u max
ポリシー管理型データベースをすでにホスティングしているクラスタに、管理者管理型データベースを作成する場合は、管理者管理型データベース用のノードを慎重に選択する必要があります(Oracle Bug#10027250を参照)。これは、ポリシー管理型サーバー・プール内にあるノードを管理者管理型データベース用に選択すると、このプロセスの一環としてそのノードが汎用サーバー・プールに移動されるためです。他のポリシー管理型データベース・インスタンスがすでに実行されているノードを選択すると、DBCAにより、管理者管理型データベースの作成時に停止されるインスタンスとサービスがリストされたメッセージが表示されます。「Do you want to continue?」に対して、ダイアログ・ボックスで「Yes」を選択すると、管理者管理型データベース作成プロセスの結果として、ポリシー管理型データベースのインスタンスとサービスが停止されます。
注意: この状況はsrvctl add instanceコマンドを使用する場合も当てはまります。データベースが停止されることを示す同様のエラー・メッセージが表示されます。srvctl add instanceコマンドで強制オプション(-f)を使用することは、DBCAダイアログで「Yes」を選択するのと同じです。この操作により、汎用サーバー・プールにノードが移動する前に、そのノードで実行されているポリシー管理型データベースが停止します。
ポリシー管理型データベースを実行しているクラスタ内でノードを追加する場合、Oracle Clusterwareは、クローニング・プロシージャが完了する前に新しいインスタンスを起動しようとします。ノードを追加するには、次の手順を使用してください。
新しいノードを追加するには、クラスタ用Oracle Grid InfrastructureでaddNodeを実行します。rootスクリプトを実行するように求められても、ここでは実行しないでください(rootスクリプトは後で実行します)。
ソフトウェアのみのインストールを使用して、Oracle RACデータベース・ソフトウェアをインストールします。OracleがOracle RACオプションでリンクされていることを確認します。
データベース・ホームでrootスクリプト・アクションを実行します。
Oracle Clusterwareホームでrootスクリプト・アクションを実行し、インストールを終了します。
Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)を使用する場合は、次の事項に注意してください。これらは、クラスタ用Oracle Grid Infrastructureのインストールを使用してインストールされます。
すべてのOracle Grid Infrastructureパッチセット・アップグレードは、アウトオブプレース・アップグレードになります。この場合、パッチセットは新規のOracle Gridホームにインストールしてください(Oracle Bug#10210246を参照)。インプレース・パッチセット・アップグレードはサポートされていません。
クラスタ用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 ODBC DriverのREADMEについては、「Oracle ODBC Driver README」を参照してください。
ORACLE_HOME/odbc/html/ODBCRelnotesUS.htm
Oracle OLAPを使用する際は、次の事項に注意してください。
SQL集計管理とは、既存のリレーショナル・マテリアライズド・ビューからキューブ・マテリアライズド・ビューの迅速なデプロイをサポートする、DBMS_CUBEのPL/SQLサブプログラムのグループです。キューブ・マテリアライズド・ビューとは、Oracle Databaseの自動リフレッシュおよびクエリー・リライト機能を使用できるように拡張されたキューブです。単一のキューブ・マテリアライズド・ビューでは、ファクト表上にあるサマリーの多数のリレーショナル・マテリアライズド・ビューを置き換えることができるため、すべてのサマリー・データへのレスポンス時間を均一にできます。
キューブ・マテリアライズド・ビューの作成プロセスでは、DBMS_CUBEによって、キューブおよびキューブ・ディメンションを含む、フル機能のアナリティック・ワークスペースも作成されます。キューブには、リレーショナル・マテリアライズド・ビューのデータを格納する表ではなく、キューブ・マテリアライズド・ビューのデータが格納されます。キューブでは、豊富な情報のコンテンツのデータベースを拡張する様々な分析関数もサポートできます。
PL/SQLパッケージの新しいDBMS_CUBE_LOGでは、ロギングの拡張機能が提供され、4種類のログが用意されています。Analytic Workspace Managerでは、ユーザーおよびデータベース管理者の両方で、アナリティック・ワークスペース・ビルドの進行状況の表示(CUBE_BUILD_LOG)、ロード・エラーの検出(CUBE_REJECTED_RECORDS)、ディメンション階層の妥当性のチェック(CUBE_DIMENSION_COMPILE)、およびOLAPエンジン・イベントの追跡(CUBE_OPERATIONS_LOG)が可能です。
データベースの組込み機能であるOLAPオプションは、Oracle Database Enterprise Editionとともに自動的にインストールされます。OLAPオプションを使用するデータベースをインストールする場合は、デフォルトの初期化パラメータに最適なデータ・ウェアハウス構成タイプを選択します。
Analytic Workspace Manager 11.2.0は、Oracle Database 11gリリース2(11.2)をOracle Database 10gまたはOracle Database 11gの互換性モードで実行する場合に使用してください。Oracle Database 10g形式のアナリティック・ワークスペースは、新しいアナリティック・ワークスペースの作成時にOracle Database 10gのキューブ・タイプを選択することで作成できます。
Oracle Database 11gリリース2(11.2)のデータベース・インスタンスで10g形式のアナリティック・ワークスペースに接続しているOLAP 10gクライアントでは、OLAP APIのバージョンを11.2.0にアップグレードするだけでなく、Javaのバージョンを1.5にアップグレードする必要があります。
Oracle Business Intelligence Beans 10gおよびOracle Discoverer for OLAP 10gは、Oracle Database 11gの10g形式のアナリティック・ワークスペースで使用できます。これらは、11g形式のアナリティック・ワークスペースでは使用できません。OLAP APIクライアントのJARをアップグレードするには、Intelligence BeansまたはDiscoverer (あるいはその両方)のJARファイルの前に、これらの新しいJARをJavaクラスの検索リストに含めます。
OLAPSYSスキーマおよびそのスキーマ内に含まれているCWMメタデータは、Oracle Database 11gリリース2(11.2)で非推奨になりました。OLAP APIでは、データ・ディクショナリ・メタデータを使用したリレーショナル表(ROLAPモード)の問合せが可能です。詳細は、My Oracle Supportのノート445311.1 (https://support.oracle.com)を参照してください。
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リファレンス』の第6章「CTX_CLSパッケージ」の問合せ互換構文に関する項には、doc_id列は数値であると記載されています。これは正しいのですが、この列の値は0-4294967295の範囲である必要があります。値は、符号なしの32ビット値で格納する必要があります。この範囲は、catid、catdocidおよびrescatidにも関連します。
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 Database Examplesメディアに含まれているため、Oracle Database 11gリリース1 (11.1)にアップグレードした直後は使用できません。アップグレード前のナレッジ・ベースに基づくOracle Text機能は、アップグレード後に機能しなくなるため、提供されるナレッジ・ベースをOracle Database Examplesメディアからインストールする必要があります。
アップグレード後は、提供されるナレッジ・ベースに対してすべてのユーザー拡張機能を再生成する必要があります。これらの変更は、指定のORACLE_HOMEにインストールされているすべてのデータベースに影響を与えます。
Oracle Textのアップグレードと提供されるナレッジ・ベースの詳細は、『Oracle Databaseアップグレード・ガイド』の第4章「データベースのアップグレード後」にあるOracle Textのアップグレードに関する項を参照してください。また、『Oracle Textアプリケーション開発者ガイド』には、Oracle Textを以前のリリースからアップグレードする一般的な方法、および提供されるナレッジ・ベースに関する情報が記載されています。
バージョン11.1.0.7から、Oracle Textではドキュメントのフィルタ処理に、Autonomy, Inc.からライセンス供与されたフィルタ処理テクノロジではなく、Oracle Outside In HTML Exportを使用しています。Oracle Outside In HTML Exportに移行することで、複数のドキュメント形式はサポートされなくなりました。フィルタ・サポートのドキュメント形式のすべてのリストおよび11.1.0.7でサポートされなくなった形式のリストについては、『Oracle Textリファレンス』の付録Bを参照してください。
Oracle Ultra Searchのサポートは終了しているため、Oracle Database 11gリリース2 (11.2)には付属しません。2006年3月に、オラクル社はOracle Secure Enterprise Search (SES)を発売しました。Oracle SESは、Ultra Search用に開発されたテクノロジで作成された、より高速でより安全な製品です。Ultra Searchを使用しているユーザーには、Oracle SESに移行することを強くお薦めします。
|
関連項目: Oracle Technology NetworkのOracle Secure Enterprise Searchのページは次のとおりです。 |
Oracle Database 11gリリース2 (11.2)のOracle Warehouse Builder (OWB)の詳細は、『Oracle Warehouse Builderリリース・ノート』参照してください。
Oracle Workflowは、Oracle Database 11gリリース2 (11.2)には同梱されていません。
Oracle XML DBでは、次の機能はサポートされていません。
フラッシュバック・アーカイブ
エディショニング・ビュー
Exadataハイブリッド列圧縮(EHCC)
SecureFile LOB暗号化
同一XMLドキュメントに構造化と非構造化のハイブリッドXMLIndexが設定されているOracle Label Security (OLS)
11.2では、Oracle XML DBスキーマの登録中のxdb:defaultTable注釈のセマンティクスの動作が11.1から変更されています(Oracle Bug#7646934を参照)。xdb:sqlInline="false"を指定せずにxdb:defaultTable="MY_TAB"を指定すると、Oracle XML DBによって必要に応じて表が作成され、表外として暗黙的にマークされます。この動作は、sqlInline設定がない場合にdefaultTable注釈が無視される11.1と異なります。
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データ要素のデフォルト値を指定の値で優先できます。
PL/SQLを使用する際は、次の事項に注意してください。
DBMS_RANDOM PL/SQLパッケージのPUBLIC EXECUTE権限は、将来のOracle Databaseリリースで非推奨になります(Oracle Bug#7591837を参照)。このPL/SQLパッケージを実行する必要がある場合は、明示的なEXECUTE権限を指定してください。
DBMS_SCHEDULER PL/SQLパッケージを使用する際は、次の事項に注意してください。
Oracle Schedulerは、イベントに基づくジョブをサポートしています。このジョブは、メッセージがデータベース・キューにエンキューされると開始します。この目的に使用されるデータベース・キューがセキュアなキューの場合、イベントに基づくジョブのQUEUE_SPEC属性とスケジュールは、queue_name, agent_name形式のペアです。エージェントの指定が必要な理由は、この指定によって、ユーザーに表示できるメッセージの判断をスケジューラが容易に行うことができるためです。セキュアではないキューの場合は、キューに対するデキュー権限があるユーザーが、そのキューにサブスクライブされるエージェントとしてデキューできます。これは、キュー内のすべてのメッセージを参照できることを意味します。セキュアなキューの場合、ユーザーには、キューのみでなくエージェントに対する権限も必要です。
キュー所有者は、デキュー権限の付与に加え、ユーザーが特定のエージェントとしてデキューできるようにdbms_aqadm.enable_db_access()をコールする必要があります。このエージェントは、ユーザーに表示する必要がないメッセージを除去するルールを使用して、キューにサブスクライブできます。
スケジューラは、独自のエージェントSCHEDULER$_EVENT_AGENTを使用して、すべてのキュー(セキュアまたはセキュアではない)を常にサブスクライブします。スケジューラはユーザーSYSで実行するため、キュー内のすべてのメッセージを参照できます。ただし、セキュアなキューの目的は、ユーザーによるキューへのアクセスに対して、キュー所有者がある種の制限を付加できることにあるため、セキュアなキューの場合はすべてのメッセージを参照できるようにしないでください。したがって、スケジューラにはQUEUE_SPEC属性にエージェント名が必要です。このエージェント名は、ユーザーが参照できるメッセージを判断する目的にのみ使用されます。スケジューラは、このエージェントとしてはメッセージをデキューしません。スケジューラは、セキュアなキューにメッセージが届いたことを示す通知を受信すると、そのキューに依存しているイベントに基づく各ジョブごとに、次のチェックを実行します。
ジョブ所有者にキューに対するデキュー権限があるかどうかを確認します。
ジョブ所有者がキュー仕様で提供されるエージェント名を使用できるかどうかを確認します。
現在、エージェントがキューにサブスクライブされているかどうかを確認します。
着信メッセージがエージェントに対して表示可能かどうかを確認します。
前述のすべてのチェックが成功すると、スケジューラはイベントに基づくジョブを起動します。チェックをパスしたかどうかに関係なく、メッセージはエージェントSCHEDULER$_EVENT_AGENTを使用してデキューされます。
QUEUE_SPEC属性にエージェントを指定する場合、ユーザーは、既存のエージェント名を指定するか、またはこのために新規作成したエージェント名を指定することができます。いずれの場合も、ユーザーまたはキュー所有者は、エージェントがメッセージを確実にデキューするようにする責任があります。
Oracle Schedulerは、リモート・ホストでのジョブの実行、およびリモート・ホストとのファイルの送受信をサポートしています。これを実行するには、『Oracle Database管理者ガイド』の第28章のリモートの外部ジョブの有効化および無効化に関する項で説明されている設定をすべて行う必要があります。この機能では、データベースでOracle XML DB HTTP Serverが有効化されている必要があります。
次のコマンドを使用して、Oracle XML DB HTTP Serverが有効化されているかどうかを確認できます。
SQL> SELECT DBMS_XDB.GETHTTPPORT() FROM DUAL;
この文で0が戻された場合は、SYSとしてログインして次のコマンドを発行し、ゼロ以外のポートでOracle XML DB HTTP Serverを有効化する必要があります。
SQL> EXEC DBMS_XDB.SETHTTPPORT (port);
SQL> COMMIT;
portは、使用するOracle XML DB HTTP Serverのポートで置き換えます。
Oracle Database 11gリリース1 (11.1)では、パッケージのセキュリティを強化するため、DBMS_SQLに多くの拡張が行われました。
オープン・カーソル数の推測の防止
オープン・カーソルを指定しないカーソル番号を使用してDBMS_SQLのサブプログラムがコールされると、新しいエラーORA-29471が発生します。エラーが発生すると、アラート・ログにアラートが発行され、セッションが終了するまでDBMS_SQLが操作不能になります。
IS_OPENに対するコールのカーソル番号の実際の値が、現在セッションでオープンされているカーソルを指定している場合、戻り値はTRUEになります。実際の値がNullの場合、戻り値はFALSEになります。それ以外の場合は、ORA-29471エラーが戻されます。
カーソル番号の仮パラメータがないDBMS_SQLサブプログラムは、DBMS_SQL.OPEN_CURSORファンクションのみであることに注意してください。このサブプログラムではカーソル番号が戻されます。そのため、このルールの対象外です。
カーソルの不正使用の防止
既知の既存のカーソルを破損するセキュリティ違反からカーソルが適切に保護されるようになりました。
バインディングおよび実行時に、追加のチェックが常に実行されます。オプションで、すべてのDBMS_SQLサブプログラムのコールに対してチェックを行うこともできます。チェックの内容は次のとおりです。
問題のサブプログラムのコール時のcurrent_userが、最新の解析のコール時と同一であるかどうか。
サブプログラムのコール時に有効化されたロールが、最新の解析のコール時に有効化されたロールのスーパーセットであるかどうか。
どのような場合にも当てはまりますが、定義者の正しいサブプログラムには、ロールは無関係です。
いずれかのチェックが失敗すると、ORA-29470が発生します。
チェックを実行する時期を定義するメカニズムは、仮パラメータsecurity_level(使用可能な値はNULL、1および2)を使用するOPEN_CURSORサブプログラムの新規オーバーロードです。
security_level = 1(またはNULL)の場合は、バインディングおよび実行時にのみチェックが行われます。security_level = 2の場合は、必ずチェックが行われます。
このセキュリティ方式は、10.2以前の旧リリースより強化されています。その結果、DBMS_SQLのユーザーは、アップグレード時にランタイム・エラーを経験する可能性があります。アプリケーションがよりセキュアになる一方で、11.1への移行時に、一時的にセキュリティ・チェックを緩和する必要がある場合も考えられます。その場合は、セキュリティ・チェックを緩和する手順について、Oracleサポート・サービスに問い合せてください。
ファイルがシンボリック・リンクの場合、UTL_FILEパッケージでファイルを開くことができなくなりました。この新しい制限により、UTL_FILEパッケージの既知のセキュリティ・ホールが閉じられます。
このセキュリティの制限によって、移行中に過度の負荷がかかる場合は、Oracleサポート・サービスに問い合せてください。
11.1データベースまたはFormsクライアントと、10.1または10.2データベース間で相互運用を行うには、少なくとも10.1.0.5 (10.1の場合)または10.2.0.2 (10.2の場合)のパッチセット・レベルが必要です。
次に示す状況で、10.1または10.2のPL/SQLユニットやビューの参照を試行すると、10.1または10.2環境に適切なレベルのパッチが適用されていないかぎり、PLS-801[55916]エラーが発生して失敗します。
11.1データベースのPL/SQLユニット、無名ブロック、トリガー、コール文またはSQL文により、データベース・リンク全体の10.1または10.2データベースのPL/SQLユニットが実行される場合。
11.1データベースのPL/SQLユニット、無名ブロック、トリガーまたはコール文がデータベース・リンク全体の10.1または10.2データベースのビューを参照し、そのビューが直接または間接的にPL/SQLファンクションやオブジェクト・タイプを参照する場合。
11.1のFormsクライアントが、RPCを使用して10.1または10.2データベースのPL/SQLユニットを実行する場合。
PLS-801[55916]エラーを回避するには、少なくとも10.1.0.5 (10.1の場合)または10.2.0.2 (10.2の場合)のパッチセット・レベルが必要です。
10.1および10.2環境間には、相互運用性の問題はありません。
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
Oracle Database 11gリリース2 (11.2)のSQLJは、JDK 5.0およびJDK 6.0でサポートされています。
SQL*PlusのREADMEについては、「SQL*Plus README」を参照してください。
ORACLE_HOME/sqlplus/doc/README.htm
サマリー管理を使用する際は、次の事項に注意してください。
特定のマテリアライズド・ビューを使用またはリフレッシュするときは、NLSパラメータが、そのマテリアライズド・ビューで作成した時点のパラメータと同じであることを確認してください。この制限を受けるのは、次の構成メンバーが含まれるマテリアライズド・ビューです。
NLSパラメータの設定に応じて異なる値を戻すことが可能な式
そのような式は、NLSに依存しない方法で記述することをお薦めします。次に例を示します。
(date > DATE '2003-01-02')
または
(rate <= 2.150)
結合の片側が文字データの等価結合
この等価結合の結果は照合によって異なり、セッションごとに変化する可能性があるため、クエリー・リライトの場合は正しい結果が得られず、また、リフレッシュ操作後はマテリアライズド・ビューに一貫性がなくなります。
マテリアライズド・ビューの選択リスト内、またはマテリアライズド集計ビューの集計内に文字データへの内部変換を生成する式
この制限は、数値データのみが含まれる式には適用されません(たとえば、aとbが数値のa+bには適用されません)。
Oracle Streamsを使用する際は、次の事項に注意してください。
ORA-01403 No data foundというメッセージにかわる、追加のOracleエラーORA-26786およびORA-26787を捕捉するには、カスタマイズされたDMLおよびOracle Streamsのエラー・ハンドラを修正する必要があります。ORA-26787エラーは、更新または削除する行がターゲット表に存在しない場合に発生します。ORA-26786エラーは、行はターゲット表に存在するが、一部の列の値がLCRの値に一致しない場合に発生します。
この項では、リリース11.2.0.2での既知の不具合を示します。これ以外に、使用しているプラットフォーム固有のリリース・ドキュメントに補足のリストが含まれている場合があります。
Oracle Bug#9655918
Oracle ACFSデータベース・ホームのOracle ASMディスク・グループ・サイズを増加する必要があります。
回避策: Oracle ACFSにデータベース・ホームを作成する際、ASMCAツールではOracle ACFSデータベース・ホームが最小6GBにデフォルト設定されます。しかし、ディスク・グループのステータスや構成によっては追加の記憶域が必要です。次のメッセージがレポートされた場合は、問題を回避するためにディスク・グループに最小10GBを使用することをお薦めします。
ORA-15032: not all alterations performed
ORA-15041: diskgroup "dg_name" space exhausted
Oracle Bug#9413827
Oracle Cluster Registry (OCR)がOracle ASMにある場合、11.2.0.1 Oracle Clusterwareの11.2.0.2へのローリング・アップグレードが失敗します。
回避策: アップグレードを実行する前に、11.2.0.1クラスタ用Oracle Grid InfrastructureホームでOracle Bug#9413827用のパッチを適用します。
Oracle Bug#9276692
Oracle ASMインスタンスを完全に停止できません。
回避策: SRVCTLを使用してOracle ASMインスタンスが無効にされた場合は、Oracle ASMインスタンスが再起動されないようにOracle ACFS関連リソースの登録を解除する必要があります。そのためには、次のコマンドをrootとして実行します。
acfsroot unregister
Oracle Bug#9925724
rootが所有するディレクトリのすぐ下にGrid_homeを作成した場合、削除ツールではトップレベルのホーム・ディレクトリを削除できません。削除が終了しても、空のOracleホーム・ディレクトリが残ります。
回避策: すべてのノードでrootユーザーを使用してrmdir ORACLE_HOMEを実行します。
Oracle Bug#9924588
新規リリースへのアップグレード後、削除ツールで古いGridホームが削除されません。
回避策: 以前のリリースからアップグレードした後、以前のリリースのOracle Grid Infrastructure Gridホームを削除する場合、以前のリリースのGridホームの権限および所有権を最初に変更する必要があります。rootとしてログインし、次のコマンド構文を使用して以前のリリースのGridホームの権限および所有権を変更します(ここでは、oldGHは以前のリリースのGridホーム、jsmithはOracle Grid Infrastructureのインストール所有者、oldGHParentは以前のリリースのGridホームの親ディレクトリです)。
#chmod -R 755 oldGH #chown -R jsmith oldGH #chown jsmith oldGHParent
インストール・ユーザーとして、11.2.0.2スタンドアロン削除ツールを使用してoldGHを削除します。
Oracle Bug#9871334
削除ツールをOracleホームから起動すると、ORACLE_HOME/deinstallディレクトリの削除が失敗します。この問題は、スタンドアロンの削除ツールでは発生しません。削除終了時に、空のORACLE_HOME/deinstallディレクトリが残ります。
回避策: 削除終了時に、空のORACLE_HOME/deinstallディレクトリとORACLE_HOMEディレクトリを手動で削除します。
Oracle Bug#9406768
11.2削除ユーティリティは、Oracleベースの下の各ホームが同じ中央インベントリを使用しているのではなく、インベントリに登録されているのがそれらのホームだけである場合、すべてのホームを削除します。
回避策: 11.2製品のインストール時に、次のようにします。
複数の中央インベントリを使用することはお薦めしません。可能であればそのようなことは避けてください。
なんらかの理由で異なる中央インベントリが必要な場合は、中央インベントリごとに異なるOracleベース・ディレクトリを使用します。
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#10019796
暗号化が有効になっていないファイルまたはディレクトリに対してacfsutil encr infoコマンドを実行しても、コマンドの出力は生成されません。暗号化が有効になっていないディレクトリに対してacfsutil encr infoコマンドを再帰(-r)オプション付きで実行した場合も、そのディレクトリやそのディレクトリ内のファイルについて、コマンドの出力は生成されません。
回避策: 個々のファイルまたはディレクトリに対してacfsutil encr infoを実行し、コマンドの出力が生成されない場合は、そのファイルまたはディレクトリに対して暗号化が有効でないことを暗示しています。
ディレクトリに対してacfsutil encr infoを再帰(-r)オプション付きで実行し、指定のディレクトリまたはそのいずれかのサブディレクトリについてコマンドの出力が生成されない場合は、そのディレクトリに対して暗号化が有効でないことを暗示しています。そのディレクトリのファイルの暗号化ステータスを確認するには、各ファイルについてacfsutil encr infoを個別に実行します。
Oracle Bug#10069735
パスワードで保護されたキーストアを使用するクラスタでは、暗号化を使用するOracle ACFSファイル・システムがOracle ACFSマウント・レジストリによってマウントされていると、管理者はキーストアのパスワードの入力を求められません。ファイル・システムをマウントする処理は正常に行われても、Oracle ACFSの暗号化が正しく動作するために必要な一部の情報を、ファイル・システムで使用できません。この場合、このファイル・システムでは暗号化は動作せず、ファイル・システムに含まれる暗号化されたファイルは、書き込むことも読み取ることもできません。
回避策: パスワードで保護されたキーストアを使用するクラスタでは、暗号化を使用するファイル・システムのマウントに、Oracle ACFSマウント・レジストリを使用しないでください。Oracle ACFSマウント・レジストリを使用してマウントされたファイル・システムがすでにある場合は、そのようなファイル・システムをアンマウントし、マウント・レジストリから削除して、後で暗号化されたデータが使用できなくなることがないようにしてください。その後、Oracle ACFSマウント・レジストリを使用しないでファイル・システムを再マウントし、リクエストされたら正しいパスワードを入力します。
Oracle Bug#9975343
acfsutil encr setまたはacfsutil sec prepareコマンドを複数のノードから連続して実行する場合に、マウント・ポイントの.Securityディレクトリが正しく作成されないことがあります。
この場合、マウント・ポイントの内容をリストすると、.Securityに対して2つのエントリが表示され、acfsutil sec prepareコマンドが最後の実行コマンドである場合は、コマンドによる各システム・レルムへのログおよびバックアップ・ディレクトリの追加が失敗します。
回避策: acfsutil encr setまたはacfsutil sec prepareコマンドを連続して実行する場合は、これらのコマンドを同じノードから実行すると問題が回避されます。
2番目のコマンドを実行する前に.Securityディレクトリの内容をリストすることで、問題を回避することもできます。
一方、問題が発生した場合は、acfsutil encr set -uおよびacfsutil sec prepare -uを使用してファイル・システムからセキュリティと暗号化の両方を削除した後、.Securityディレクトリを削除することで解決できます。.Securityディレクトリの削除は2回実行する必要があります。
セキュリティと暗号化をファイル・システムから削除し、.Securityディレクトリを削除した後、ファイル・システムに対してacfsutil sec prepareまたはacfsutil encr setコマンドを再度実行します。
Oracle Bug#9958114
レプリケーションのためにスタンバイ・ファイル・システムが初期化され、一方、プライマリ・ファイル・システムは初期化されていない場合、スタンバイのrepl terminateで永久ループになります。
回避策: acfsutil repl terminate standby immediateを使用して、この状況のスタンバイを終了します。
Oracle Bug#9947559
一定の再試行回数の後、リモート・サイトと通信できない場合は、acfsrepl_transportデーモンが別のノードへのフェイルオーバーを試行します。フェイルオーバーするデーモン用の別のノードがない場合、または一定回数のフェイルオーバーが試行された場合、Oracle Clusterwareではフェイルオーバーの試行が停止され、トランスポート・デーモンは実行されません。トランスポート・デーモンが実行されないと、レプリケーションが停止し、結果的にファイル・システムで空き領域が不足することになります。
回避策: 通信の問題を解決した後、acfsutil repl bg start mnptを実行します。
Oracle Bug#9940090
ディスク・グループが強制的にディスマウントされると、リモート・サイトと通信できなくなります。この問題の根本原因は、ディスク・グループが強制的にディスマウントされる際、ファイル・システムに関連付けられているサービス名の登録が解除されないことにあります。
回避策: ディスク・グループが強制的にディスマウントされたファイル・システムをアンマウントします。この操作によりサービスの登録が解除されるため、リモート・サイトでは、ディスク・グループおよびファイル・システムがマウントされている別のノードを通信用に選択できるようになります。
Oracle Bug#9896821
トレース・ファイルを指し示す次のアラート・ログ・メッセージは、実際の問題を表していません。
ORA-19505: failed to identify file "/scratch/primary/.ACFS/repl/ready/receipt.transport.cord242.12786023 69" ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory
回避策: ありません。
Oracle Bug#8644639
Oracle ACFSマウント・ポイントを作成してレジストリに追加する場合、次の条件に該当すると、マウント・ポイントは自動的にマウントされません。
マウント・ポイントのディレクトリがOracle ACFSレジストリで登録済である。
マウント・ポイントのディレクトリがマウント済である。
マウント・ポイントがアンマウントされ、Oracle ACFSレジストリから削除されている。
レジストリからマウント・ポイントが削除されてから、ora.registry.acfsリソースが再起動されていない。
回避策: /tmp/.usm_state_fileファイルからマウント・ポイントのディレクトリを削除します。
Oracle Bug#9683229
Oracle ADVMでは、マウント・バリア・オプションを有効化した状態でOracle ADVMを介してext3ファイル・システムをマウントすることはサポートされていません。SLES10では、マウント・バリア・オプションがデフォルトで有効化されます。
回避策: ext3ファイル・システムを-o barrier=1でマウントします。次に例を示します。
mount -o barrier=0 /dev/asm/myvol-131 /mnt
『Oracle Application Expressリリース・ノート』の未解決の不具合と既知の問題に関する項を参照してください。
Oracle Bug#10062301
ローリング以外のクラスタウェアを11.2.0.1から11.2.0.2にアップグレードした後、clusterware_home _path/crs/install/crsconfig_paramsでCLUSTER_NAMEパラメータが設定されていません。これは、アップグレード後のaddNodeシナリオに影響します。
回避策: 次の手順を実行します。
clusterware_home_path/bin/olsnodes -cを実行し、クラスタ名を調べます。
clusterware_home_path/crs/install/crsconfig_paramsを編集し、CLUSTER_NAMEエントリをCLUSTER_NAME=clustername_acquired_in_step1に更新します。
Oracle Bug#10055232
11.2.0.2から11.2.0.1へのダウングレード後、root.shスクリプトが失敗します。
回避策:
Oracle Cluster Registry (OCR)および投票ディスクがOracle ASMにない場合は、次の手順を使用してダウングレードします。
11.2.0.2ホームからOracle Clusterwareの実行を停止した後、その停止を確認します。次に例を示します。
11.2.0.2_Home/bin/crsctl stop crs 11.2.0.2_Home/bin/crsctl check crs
OLRバックアップ・ファイルをコピーし、olr.locファイルのolrconfig_locおよびcrs_homeプロパティが11.2.0.1.0ホームを指していることを確認します。次に例を示します。
cd location_of_olr_loc
cp olr.loc.bkp olr.loc
location_of_olr_locはプラットフォーム固有です。使用しているシステムのolr.locの位置については、プラットフォーム固有のドキュメントを参照してください。
ダウングレードする最後のノードで、11.2.0.1.0スナップショットを使用してOCRをフォーマットします。次に例を示します。
ocrconfig -import 11202_crshome/cdata/ocr11.2.0.1.0
1つ以上の投票ファイルを削除します。11.2.0.2にアップグレードする前の11.2.0.1のインストールでは、投票ファイルはユーザーが指定した場所に格納されます。通常は、OCRと同じ場所に格納されます。次に例を示します。
rm vote_file
スタックを排他モードで開始します。次に例を示します。
11.2.0.1_Home/bin/crsctl start crs -excl
1つ以上の投票ファイルを追加します。次に例を示します。
crsctl add css votedisk voting_file
排他モードで実行中のスタックを停止し、その停止を確認します。次に例を示します。
11.2.0.1_Home/bin/crsctl stop crs -f 11.2.0.1_Home/bin/crsctl check crs
すべてのノードで、11.2.0.1ホームからOracle Clusterwareを開始します。次に例を示します。
11.2.0.1_Home/bin/crsctl start crs
Oracle Cluster Registry (OCR)および投票ディスクがOracle ASMにある場合は、次の手順を使用してダウングレードします。
OCRディスク・グループのcompatible.asm属性が11.2.0.2に設定されている場合は、ダウングレードの手順を開始する前に、ocrconfig -addコマンドとocrconfig -deleteコマンドを使用して、compatible.asmが11.2.0.1に設定されているディスク・グループに対してOCRを移行する必要があります。
11.2.0.2ホームからOracle Clusterwareの実行を停止した後、その停止を確認します。次に例を示します。
11.2.0.2_Home/bin/crsctl stop crs 11.2.0.2_Home/bin/crsctl check crs
OLRバックアップ・ファイルをコピーし、olr.locファイルのolrconfig_locおよびcrs_homeプロパティが11.2.0.1.0ホームを指していることを確認します。次に例を示します。
cd location_of_olr_loc
cp olr.loc.bkp olr.loc
location_of_olr_locはプラットフォーム固有です。使用しているシステムのolr.locの位置については、プラットフォーム固有のドキュメントを参照してください。
ダウングレードする最後のノードで、11.2.0.2.0 Oracle Clusterwareスタックを排他モードで開始します。次に例を示します。
11.2.0.2_Home/bin/crsctl start crs -excl -nocrs
Oracle ASMディスク・グループから投票ディスクを削除します。次に例を示します。
11.2.0.2_Home/bin/crsctl delete css votedisk <diskgroup>
11.2.0.2ホームから排他モードで実行中のOracle Clusterwareを停止し、その停止を確認します。次に例を示します。
11.2.0.2_Home/bin/crsctl stop crs -f 11.2.0.2_Home/bin/crsctl check crs
ダウングレードする最後のノードで、11.2.0.1.0 Oracle Clusterwareスタックを排他モードで開始します。次に例を示します。
11.2.0.1_Home/bin/crsctl start crs -excl
Oracle Clusterwareデーモンを停止します。次に例を示します。
11.2.0.1_Home/bin/crsctl stop resource ora.crsd -init -f
ダウングレードする最後のノードで、11.2.0.1.0スナップショットを使用してOCRをフォーマットします。次に例を示します。
11.2.0.1_Home/bin/ocrconfig -import 11202_crshome/cdata/ocr11.2.0.1.0
OCRの整合性を確認します。次に例を示します。
11.2.0.1_Home/bin/ocrcheck
排他モードで実行中のスタックを停止し、その停止を確認します。次に例を示します。
11.2.0.1_Home/bin/crsctl stop crs -f 11.2.0.1_Home/bin/crsctl check crs
すべてのノードで、11.2.0.1ホームからOracle Clusterwareを開始します。次に例を示します。
11.2.0.1_Home/bin/crsctl start crs
すべてのノードからOCR整合性を確認します。次に例を示します。
11.2.0.1_Home/bin/cluvfy comp ocr -n all -verbose
Oracle Bug#10044507
インストール、アップグレード時のudev属性の検証、または手動によるcluvfyの実行で、必要なudev属性が適切なudevルール・ファイルに正しく定義されていても、エラーがレポートされることがあります。次に例を示します。
PRVF-5184 : Check of following Udev attributes of "<node>:<path>" failed: "[Permissions: Found='0600' Expected='0660']"
このエラーは、デバイスのudev属性が、udevルール・ファイル内に特定の順序で記載されることが想定されているために発生します。
回避策: udevルール・ファイルにデバイス情報を指定する際は、OWNER、GROUPおよびMODEを、他の特性指定より先に、この順序で指定します。たとえば、udev行にACTION特性を指定する場合は、次のようにします。
KERNEL=="<device>", OWNER="oracle", GROUP="dba", MODE="660", ACTION=="add|change"
次のように指定しないでください。
KERNEL=="<device>", ACTION=="add|change", OWNER="oracle", GROUP="dba", MODE="660"
Oracle Bug#10043601
クラスタ用Oracle Grid Infrastructureのインストールで、NFSのddによって作成されたファイルがOracle ASMディスクとして使用される場合、Oracle ASMデバイスの前提条件チェックで、指定のディスクが有効なパスでないことを示すエラー(PRVF-5150)がレポートされます。
回避策: このエラーは無視しても問題ありません。
Oracle Bug#10041397
Oracle Virtual Machine (Oracle VM)でのクラスタ用Oracle Grid Infrastructureのインストールで、仮想共有ディスクがOracle ASMデバイスとして使用される場合、Oracle ASMデバイスの前提条件チェックで、これらのデバイスが共有されてないことを示す警告が表示されます。次に例を示します。
PRVF-5149 : WARNING: Storage "/dev/xvde1" is not shared on all nodes
回避策: この警告は無視しても問題ありません。
Oracle Bug#10033106
addNode.shを-silentフラグ付きで実行してOracle Clusterwareに新しいノードを追加する際、cluvfy stage -pre nodeaddで障害が発生してもエラー・メッセージが表示されません。addNode操作は終了し、新しいノードは追加されません。
回避策: クラスタの既存のノードからcluvfy stage -pre nodeaddコマンドを実行します。レポートされたエラーを参照し、エラーを修正します。エラーを無視してaddNode操作を続行する場合は、環境変数IGNORE_PREADDNODE_CHECKSをYに設定し、addNode操作を再試行してください。
Oracle Bug#10032601
クラスタ用Oracle Grid Infrastructureのインストール時またはcluvfy stage -pre crsinstコマンドの起動時に、ユーザーの存在を確認する前提条件チェックで、ユーザーIDの数値が6桁を超えるとエラーがレポートされます。ローカル・ユーザーとNISユーザーのいずれの場合もエラーが表示されます。
回避策: レポートされるユーザーの存在の検証エラーは無視しても問題ありません。
Oracle Bug#10025999
Oracle Clusterwareスタックがすでに実行されているときに、Oracle高可用性サービス・デーモン(OHASD)がクラッシュして再起動すると、その後のクラスタ検証ユーティリティ(CVU)チェックで、次の情報メッセージが表示されることがあります。
INFO: PRVF-9656 : The CTSS command to query time offset and reference failed on node nodename with error message ""
INFO: Query of CTSS for time offset failed
回避策: これらの情報メッセージは無視しても問題ありません。
Oracle Bug#9978765
以前のリリースで複数のプライベート・ネットワーク・インタフェースが構成されている場合は、Oracle Clusterwareリリース10gR1、10gR2および11gR1からOracle Grid Infrastructure 11gリリース2パッチセット2に、クラスタ用Oracle Grid Infrastructureをアップグレードできません。これは、アップグレードの前にOIFCFGのgetifコマンドを実行し、cluster_interconnectのマークが設定されているインタフェースの数を調査することで検証できます。
回避策: 次の手順を実行して、クラスタ用Oracle Grid Infrastructureをアップグレードします。この例では、2ノード・クラスタ(AとB)を想定しています。
10gR1、10gR2または11gR1クラスタで、ノードAおよびBのすべてのデータベース・インスタンスおよびOracle ASMの実行を停止します。
ノードAで、OLSNODES -pコマンドを使用して、Oracle Clusterwareによって使用されるプライベート・ネットワーク・インタフェースを識別します。OIFCFG delif -global if_nameコマンドを使用して、cluster_interconnectのマークが設定されている残りのプライベート・ネットワーク・インタフェースを削除します。
10gR1、10gR2または11gR1クラスタで、ノードAおよびBのすべてのデータベース・インスタンスおよびOracle ASMの実行を停止します。
クラスタ11gリリース2(11.2)のOracle Grid Infrastructureのアップグレードを進めます。
crsctl query crs activeversionコマンドを使用して、クラスタ用Oracle Grid Infrastructureのアップグレードが完了したことを確認します。oifcfg setif -global if_name:cluster_interconnectコマンドを使用して、手順2で削除されたプライベート・ネットワーク・インタフェースを追加します。
Oracle Bug#9974223
クラスタ用Oracle Grid Infrastructureには、クラスタ・ノード間で正しく機能する230.0.1.0アドレスのマルチキャスト通信が必要です。
フレッシュ・インストール時またはアップグレードの試行後に、11.2.0.2クラスタ・ノードを開始する最初の試行でノードをクラスタに結合できないことがあります。Oracle Cluster Synchronization Services (OCSS)により、既存のクラスタ・メンバーの結合に失敗したことがレポートされます。
このレポートには、CSSがクラスタの他のアクティブ・メンバーに接続できないことを示すメッセージが記載されます。
この問題は、11.2.0.2のクラスタウェアが230.0.1.0アドレスで通信を開始する際に、マルチキャスト・メッセージを使用するために発生します。これらのアドレスでのマルチキャストがプライベート・インタフェースに使用できない場合は、そのピア・ノードへの接続にクラスタウェアを使用することはできません。
回避策: 社内のネットワークIT部門に連絡し、プライベート・インターコネクト上のクラスタのすべてのノードでマルチキャスト通信が機能しているかどうかの検証を依頼してください。特に、230.0.1.0アドレスでのマルチキャスト通信がクラスタ・ノード間で正しく機能していることを確認してください。
Oracle Bug#9951257
Oracle Cluster Registry (OCR)がディスク・グループにあり、そのディスク・グループを自動的にマウントできない場合、Cluster Ready Services Daemon (CRSD)が開始されません(Oracle Bug#9799693も参照)。
回避策: OCRディスク・グループを手動でリカバリする必要があります。ディスク・グループのマウントに失敗した理由を判断し、問題を解決してディスク・グループをマウントします。リカバリ・オプションについては、メッセージCRS-5019も参照してください。
Oracle Bug#9948549
データベースまたはOracle ASMのインスタンスの起動中にエージェントが終了した場合、インスタンスの起動が完了しない可能性があります。
回避策: srvctlまたはsqlplusを使用し、インスタンスを停止して再起動します。
Oracle Bug#9877357
ポリシー管理型データベースの名前に'_'が使用されている場合または名前が8文字を超える場合は、DBCAでOracle Enterprise Manager構成が失敗します。
回避策: 適切なデータベース名を選択します。
Oracle Bug#8974576
SRVCTL ADD SCAN_LISTENERまたはSRVCTL REMOVE SCAN_LISTENERコマンドの後、REMOTE_LISTENERパラメータが変更されません。
将来のリリースのOracle Clusterwareでは、それぞれ独自のSCANを使用した複数のパブリック・ネットワークをサポートするように、REMOTE_LISTENERがプロジェクトの一部として管理されるようになります。リリース11.2では、11.2より前のアップグレード対象データベースのREMOTE_LISTENERパラメータにノードのVIPを含める必要があるため、REMOTE_LISTENERを適切に更新するために必要なすべてのデータがOracle Clusterwareに保持されているわけではありません。かわりに、DBCAとDBUAで実装するか、手動で実装します。
回避策: REMOTE_LISTENERパラメータを手動で変更するには、次のコマンドを実行します。
SQL> ALTER SYSTEM SET REMOTE_LISTENER='t2000-cluster0-scan.t2000-18.oraclecorp.com' sid='*' scope=memory; System altered. SQL> ALTER SYSTEM REGISTER; SQL> SHOW PARAMETER LISTENER; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ remote_listener string t2000-cluster0-scan.t2000-18.o
Oracle Bug#8737732
Oracle Clusterwareの以前のリリースをクラスタ用Oracle Grid Infrastructure 11gリリース2 (11.2.0.2)にアップグレードする場合、クラスタ用Oracle Grid Infrastructureのインストール所有者に、Oracle Cluster Registryおよび投票ディスク・ファイルが配置されているRAWデバイスに対する適切な権限または所有権がないと、クラスタ検証ユーティリティ(CVU)が失敗する場合があります。
回避策: インストール・ログ・ファイルでCVU出力を確認し、RAWデバイスの権限または所有権を、ログ・ファイルに指定されている設定に変更します。「再試行」をクリックし、構成ツールを再実行します。
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#8668083
Oracle Restart環境で、ローカル・ノードのユーザー等価が存在しない場合、次のコマンドでは検証を実行できず、エラー・メッセージが返されます。
cluvfy stage -pre hacfg cluvfy stage [-pre | -post] cfs cluvfy stage [-pre | -post] acfscfg cluvfy comp admprv cluvfy stage -pre dbcfg cluvfy stage -pre dbinst
回避策: Oracle RestartでSSHを構成します。
これらの不具合のパッチを取得し、Oracle Databaseホームに適用するには、Oracleサポート・サービスに問い合せてください。
Oracle Bug#8666509
Oracle Clusterwareを削除すると、11.2より前のOracle RACホームをOracleインベントリからデタッチするように求められます。
回避策: アップグレードした11.2 Oracle RACホームを構成解除および削除し、クラスタ用Oracle Grid Infrastructureホームの構成解除および削除を続行する場合は、最初に、11.2より前のOracle RACソフトウェア・ホームを中央のインベントリからデタッチします。
Oracle Bug#8657184
2つのネットワーク・インタフェースがクラスタ内でパブリック・ネットワーク・インタフェースとして構成されており、一方のノードのパブリック・インタフェースに障害が発生した場合に、もう一方のパブリック・インタフェースにVIPが自動的にフェイルオーバーされません。
回避策: 複数のパブリック・ネットワーク・インタフェースが存在する場合は、高可用性のためにインタフェースの結合を使用します。Oracle Clusterwareインストーラの「ネットワーク・インタフェースの使用方法の指定」画面で、パブリックとして1つの(結合された)インタフェースのみを選択します。srvctl add nodeappsまたはsrvctl add vipでパブリック・ネットワークを構成する場合は、-Aまたは-S引数に1つのネットワーク・インタフェース名のみを指定します。
Oracle Bug#8288940
DBCAを使用して11.2のクラスタ用Oracle Grid Infrastructure環境に11.2より前のOracle RACデータベースを作成すると、次のメッセージで失敗する場合があります。記憶域としてクラスタ・ファイル・システムを使用しているとき、次のメッセージが表示されます。
ORA-00119: invalid specification for system parameter REMOTE_LISTENER
記憶域としてOracle ASMを使用しているとき、次のメッセージが表示されます。
DBCA could not startup the ASM instance configured on this node
回避策: 11.2データベース・ホームでこの不具合のためのパッチを適用します。このパッチは、10.2.0.4、11.1.0.6および11.1.0.7データベース・リリースに対して必要です。リリース10.2.0.5にはパッチは不要です。
Oracle Bug#3841387、8262786、8373758、8406545、8441769
Oracle Clusterwareを11.2にアップグレードすると、10.1、10.2および11.1のOracle RACデータベースのOracleリソースが正常に動作しない場合があります。
回避策: Oracle Bug#3841387、8262786、8373758、8406545および8441769のためのパッチをOracle Databaseホームに適用します。
Oracle Bug#10013976
11.2データベースから生成されたデータベース・レベル、スキーマ・レベルまたはキュー表のデータベース・エクスポート・ログを11.2データベースにインポートすると、Oracle Streamsアドバンスト・キューイング(AQ)プロシージャ型インポート処理でORA-1403エラーが発生する場合があります。インポートはエラーありで正常に完了します。
回避策: ありません。インポート・ログのORA-1403エラーは重大ではありません。AQキューなどのデータベース・オブジェクトのインポートは正常に完了します。
Oracle Bug#10225918
ローカル・リスナーが正しく構成されていない場合にDatabase Configuration Assistant (DBCA)でDatabase Vaultの構成が試行されると、記載された問題が再現されます。このエラーによりメタデータの移入が一部となるため、Database Vaultの一部の機能が予想どおりに機能しない場合があります。
回避策: 次の手順で、この問題の回避策を説明します。
rdbms/admin/dvremove.sqlを使用して、Database Vaultを完全に削除します。
ローカル・リスナー(LISTENER)が正しく構成されていることを確認します。
Database VaultのインストールおよびDBCAを使用した構成を再試行します。
オプションで、エラーとなったDVCA操作(dvca -action addlanguagesおよびcatmacpost.sqlなど)を手動で実行し、前述の手順に従ってエラーからリカバリできます。ローカル・リスナー(LISTENER)が正しく構成されていることを確認してから、手順を実行してください。
Oracle Bug#8686258
Database Vaultの管理ページに次のメッセージが表示されるため、Database VaultのポリシーをOracle Enterprise Manager Database Controlで管理できません。
"OPERATOR TARGET" privilege does not exist. "You must have OPERATOR TARGET privilege to perform this operation."
回避策: Oracle Enterprise Managerを使用してDatabase Vaultのポリシーを管理するには、Database Vault管理者にEM管理者権限を割り当てる必要があります。EM管理者権限をDatabase Vault管理者に付与しない場合は、「Database Vault Administrator」ページを直接使用します。その他の情報は、『Oracle Database Vault管理者ガイド』を参照してください。
Oracle Bug#8474817
DBMS_MACADM.AUTHORIZE_SCHEDULER_USER APIで、ユーザーにDatabase Vaultスケジューラ・ジョブの認可の権限が付与されている場合、このユーザーを削除しても、認可ユーザーのリストから削除されません。
回避策: DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER APIコールを起動し、ユーザーの認可を手動で削除します。
Oracle Bug#8341283
成功または失敗時に監査するように監査オプションが設定されている場合、DVSYS.AUDIT_TRAIL$表のACTION_NAMEエントリに、失敗したレルム強制のRealm Authorization Auditが表示されます。RETURNCODEには、トリガーされた正しいエラー・コードが表示されます。
回避策: 違反が発生しているかどうかをRETURNCODE値を使用して判断し、レルム強制またはコマンド・ルール強制によって監査が生成されたかどうかをACTION_NAME列を使用して特定します。
Oracle Bug#8247647
ユーザーを削除しても、Oracle Data Pumpの認可ユーザーのリストから自動的に削除されません。
回避策: DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER APIコールを起動し、Oracle Data Pumpのユーザーの認可を手動で削除します。
Oracle Bug#7033772
Enterprise Manager Database Controlのアップグレード後に、Database Vault Administrator (DVA)が機能しません。
回避策: Database Controlのアップグレード後に、DVAを手動で再デプロイします。『Oracle Database Vault管理者ガイド』の付録C、Database Vault Administratorのデータベース・コンソールOC4Jコンテナへのデプロイに関する項で説明している手順を実行します。
Oracle Bug#10107649
相関パッケージのアップグレード時に、ドラフトのサービス・リクエスト(SR)の作成が失敗することがあります。
回避策: 相関パッケージを既存のSR (通常はメイン・パッケージと同じSR)にアップロードします。
Oracle Bug#9951827
トランスポータブル表領域のインポートで、タイムゾーンのバージョンが変更されているタイムスタンプが処理されません。
リリース11.2.0.2で生成されたトランスポータブル・ダンプ・ファイルにタイムゾーン列のあるタイムスタンプを含む表があり、ターゲット・データベースでのタイムゾーン表のバージョンがソース・データベースのものと異なっている場合、インポートは実行されません。
リリース11.2.0.2より前で生成されたダンプ・ファイルのタイムゾーン表のバージョンがターゲットと異なる場合、インポートは実行されません。
回避策: インポート・データベースとエクスポート・データベースのタイムゾーン表が同じであることを確認してください。
Oracle Bug#9859532
ノード固有ネットワーク・インタフェースの現在の実装では、そのノードに対してOracle RACが使用するすべてのネットワークの完全な定義が必要です(つまり、ノードがグローバル・ネットワーク構成に従っているか、またはノードでノード固有のネットワーク構成が定義されていることが必要です)。
そのため、最初のノード固有ネットワーク・インタフェースが特定のノードに対して定義されると、Oracle RACは、すでに構成されていて、同じノードに適用されている可能性のある構成済のグローバル・ネットワーク・インタフェースを考慮しません。
これは正しい動作ですが、問題があります。クラスタに動作しているグローバル・ネットワーク構成がある場合、ユーザーが(oifcfgを使用して)それを更新し、ノード固有のpublicインタフェースを定義するときには、グローバル構成はそのノードに対して考慮されず、ノードは新しく定義されたpublicインタフェースを1つだけ持つようになります。グローバル・ネットワーク構成に存在し、このノードに対してまだ正常に解決を行う可能性のあるすべてのクラスタ・インターコネクトは、有効とは見なされなくなります。したがって、ノードはクラスタ・インターコネクトを失い、PCWスタックはそのノードで停止します。
回避策: ノードがグローバル・クラスタ・ネットワーク構成に属していて、ネットワーク構成をノード固有にする場合は、最初のノード固有インタフェースとしてクラスタ・インターコネクトを定義し、他のクラスタ・ノードとのインターコネクトをノードが失わないようにする必要があります。その後は、必要に応じて他のノード固有インタフェースを定義できます。
Oracle Bug#9181675
権限エラーを避けるために、Oracle ASM上でデータベースを手動で作成している場合は、asmgidwrapスクリプトをコールする必要があります。
回避策: ロール分離インストール(グリッドおよびRDBMSに異なるユーザーとグループがあります)の場合、DBCAを使用して、Oracle ASM上でのデータベース作成時に自動的にasmgidwrapスクリプトをコールするデータベースを作成します。データベースを手動で作成することを選択した場合、権限エラーを避けるために正しいグループを設定できるように、スクリプトを明示的にコールする必要があります。
Oracle Bug#8729627
11.1のDBCAを使用して、11.2のOracle Clusterwareを実行しているクラスタでデータベースを削除する場合、データベース・リソースがロックされるためにPRKP-1061/CRS-2524エラーが表示される場合があります。
回避策: このメッセージは無視しても問題ありません。「OK」をクリックして続行します。
Oracle Bug#8679182
複数のパブリック・サブネットがVIPに定義されているクラスタでデータベースを構成する場合(例: srvctl add vip -k 2 -A ...と同様のコマンドを使用)、データベース・エージェントによって、LOCAL_LISTENERがデフォルト・ネットワークのリスナーに自動的に設定されます。これにより、LISTENER_NETWORKSのリスナー・セットが重複する場合があります。
回避策: デフォルトのパブリック・サブネットにあるLISTENER_NETWORKSにはリスナーを設定しないでください。
Oracle Bug#8671032
Oracle Enterprise Managerで、「自動UNDO管理」ページの「分析の実行」から得られるヒントが正しい内容になっていません。たとえば、ワークロードの変動に許可するUNDO表領域の推奨サイズは最小サイズの3倍ですが、Oracle Enterprise Managerでは異なる値が表示されます。
回避策: ヒントの内容を次のように読み替えてください。
Oracle advises that you configure the undo tablespace to be three times the Recommended Undo Tablespace Size to allow for workload fluctuations
Oracle Bug#8304261
圧縮属性が表レベルとサブパーティション・テンプレートに指定されている場合、新規作成された間隔パーティションでは、サブパーティション・テンプレートで定義された圧縮属性ではなく、表レベルの圧縮が使用されます。
回避策: サブパーティションに圧縮属性を再定義します。
Oracle Bug#10162200
「データベースのクローニング」では、クローニング・プロセス中にDatabase Controlを構成するオプションがあります。Oracle ASMベースのクローン・データベースの作成時にこのオプションが指定されている場合、Database Controlは構成されません。
回避策: Oracle Enterprise Manager Configuration Assistant (EMCA)を手動で実行し、Database Controlを設定します。
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#8350597
Database ControlがIPv6環境で実行されている場合、Database Controlを使用してExadataセルを監視できないため、Exadataセルをターゲットとして追加しないでください。
回避策: ありません。
Oracle Bug#10019209
この不具合は、クラスタ状態モニター(CHM)をサポートしているプラットフォームに当てはまります。Oracle Clusterware管理のデータベース・サービスが停止しているものの無効の状態ではない場合、そのサービスのホストであるサーバーのメモリーが過大割当ての状態であると検出されなければ、サービスはOracle Database QoS Managementにより起動されます。メモリーが過大割当てされている場合は、有効なサービスはすべて、たとえ手動で起動されていても停止されます。メモリーの過剰割当て状態(赤)からせ正常な状態(緑)に遷移するサービスのみを起動するというのが、望ましい動作です。サーバーが赤の状態にあるときに、サービスが手動で起動される場合、そのサービスは停止しないでください。
回避策: Oracle Enterprise Managerコンソールから、停止状態のままにするサービスを停止して無効にするか、QoS管理を無効にします。
Oracle Bug#10019186
サーバーでメモリーがオーバーコミットされるのを防ぐOracle Database QoS Management機能は、クラスタ状態モニター(CHM)もサポートするプラットフォームでのみ使用できます。
回避策: ありません。
Oracle Bug#9917299
インストール・キットで提供されているシードを使用してデータベースがインストールされていて、OLAPオプションが選択されていない場合、インストールの終了時またはしばらくしてから、OLAP Analytic WorkspaceおよびOLAP APIコンポーネントが無効と報告されます。
エラー・メッセージを除くと、これによるインスタンスの実行への影響は何もありません。
回避策: 次のいずれかを行います。
エラーを無視します。
OLAP (または問題のあるオプション)を有効にします。
OLAPを含まない独自のシード・データベースを作成して使用します。
Oracle Bug#9545221
ソース表がターゲット・スキーマの一部ではないマテリアライズド・ビューが有効なキューブまたはキューブ・ディメンションをインポートすると、「Object not found」というエラーで失敗します。
回避策: インポートの前に失敗したオブジェクトに対するマテリアライズド・ビューを無効にし、ソース表が存在するようになったら再び有効にします。
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#10115681
論理変更レコード(LCR)が1000レコードを超えるトランザクションを送信しているときに、クライアント・アプリケーションがインバウンド・サーバーからデタッチすると、リーダー・サーバーから無効なデキュー最低水位標を受信したという理由で、コーディネータ・プロセスが中断されます。
回避策: 大きいトランザクションの途中でのインバウンド・サーバーからのデタッチを回避します。大きいトランザクションのCOMMIT LCRが送信されるまで待機した後デタッチします。
Oracle Bug#10253337
DISPLAYが設定されていない場合、addnode.shでエラーが発生します。
回避策: addnode.shコマンドを-silentフラグ付きで実行します。
Oracle Bug#10096522
ソフトウェア更新の適用を選択している間にインストーラ・セッションが再起動された場合、Oracle Grid Infrastructureソフトウェアまたはデータベース・ソフトウェアのサイレント・インストールの後、configToolAllCommands構成ステップの実行が失敗することがあります。
回避策: ORACLE_HOME/oui/bin/runconfig.shのJRE_LOCATIONプロパティの値をORACLE_HOME/jdk/jreに変更し、再度configToolAllCommandsを実行します。
Oracle Bug#10053840
ソースOracleホームでソフトウェア更新の適用を選択している間にインストーラ・セッションが再起動された場合、cloneまたはaddNode操作が失敗することがあります。
回避策: ORACLE_HOME/oui/oraparam.iniのJRE_LOCATIONプロパティの値を../../jdk/jreに変更します。
Oracle Bug#10053090
インストールの前提条件チェックの手順で、OUIによりテキスト-1のエラーが表示され、前提条件ページに結果として「No results」が表示されることがあります。
回避策: 「Check Again」ボタンをクリックして、前提条件チェックを再実行します。
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#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)
)
)
Oracle Bug#9880435
ウォレットのパスワードとディレクトリ・ユーザーのパスワードが異なる場合、Oracle Wallet Managerによるディレクトリ・サービスへのウォレットのアップロードは失敗します。
回避策: ウォレットとディレクトリ・ユーザーに同じパスワードを使用します。
『Oracle Warehouse Builderリリース・ノート』の未解決の不具合と既知の問題に関する項を参照してください。
Oracle Bug#10010873
Oracle Warehouse Builder (OWB) 11.2.0.1デザイン・センター・クライアントとOWB 11.2.0.2サーバー側コンポーネントとの互換性がありません。11.2.0.2 OWBリポジトリへの接続にOWB 11.2.0.1デザイン・センターを使用すると、予測不可能な動作が発生することがあります(リポジトリが破損している場合もあります)。
回避策: これらの競合を回避するために、接続時にターゲット・リポジトリのバージョンを確認するようにOWB 11.2.0.1を構成します。
各クライアント・インストールでOWB_CLIENT_HOME/owb/bin/admin/Preference.propertiesを編集し、OverrideRuntimeVersionCheckプリファレンスとOverrideRepositoryVersionCheckプリファレンスを次のように更新します。
OverrideRuntimeVersionCheck=false OverrideRepositoryVersionCheck=false
このPreference.propertiesへの変更は、すべてのクライアント・ホストの11.2.0.1デザイン・センター・インストールに適用する必要があります。
OWBデザイン・センターと11.2.0.2データベースを使用するには、OWB 11.2.0.2 Windows 32ビット版デザイン・センターが入手可能になるまでの間、OWB 11.2.0.2 Linux 32ビット版デザイン・センターを使用します。
現在使用している環境でOWB 11.2.0.2 Linux 32ビット版デザイン・センター・クライアントを使用できない場合は、Oracleサポート・サービスに連絡してください。
Oracle Bug#10018899
データベース・オブジェクトへの変更の追跡では演算子の引数がチェックされないため、あるデータベース・オブジェクトが更新される際に、既存の結果のキャッシュを無効にできません。
データベース・オブジェクトを引数として受け入れる演算子と同様に、xmlexists演算子もこの問題の影響を受けます。
回避策: このような演算子を必要とする問合せに対して、結果キャッシュを無効にするか、フラッシュします。
Oracle Bug#9586264
XMLQUERYまたはXMLTABLE問合せを完全に最適化するには、OPTIMIZER_FEATURE_ENABLEを11.1.0.6以降に設定する必要があります。
回避策: ありません。
