| Oracle® Databaseアップグレード・ガイド 11g リリース2(11.2) B56310-08 |
|
 前 |
 次 |
Oracle Databaseをアップグレードする手順を実行した後は、必要な作業を行い、新しいリリースの推奨事項を考慮する必要があります。
この章の項目は次のとおりです。
dbupgdiag.sqlスクリプトを実行することで、データ・ディクショナリの現在の状態に関するアップグレードおよび移行の診断情報を収集できます。スクリプトは、アップグレード前にソース・データベース上、およびアップグレード後にSYSユーザーとしてアップグレードされたデータベース上のどちらででも、SQL*Plusで実行できます。
|
関連項目: My Oracle Support (http://support.oracle.com)のNote 556610.1「Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)」 |
ディクショナリの現在の状態を表示するには、次の例のようなSQL問合せを実行します。
SQL> spool /tmp/regInvalid.out
SQL> set echo on
-- query registry
SQL> set lines 80 pages 100
SQL> select substr(comp_id,1,15) comp_id,substr(comp_name,1,30)
comp_name,substr(version,1,10) version,status
from dba_registry order by modified;
無効なオブジェクトを問い合せるには、次のようなSQL問合せを実行します。
SQL> select substr(owner,1,12) owner,substr(object_name,1,30) object,substr(object_type,1,30) type, status from dba_objects where status <> 'VALID'order by owner, type; SQL> spool off SQL> set echo off
Oracle Databaseをアップグレードした後で、新規OracleホームからOPatchコマンドを実行する必要があります。たとえば、システムに現在インストールされているものの正確で完全なインベントリをリストするには、新規Oracleホームからlsinventoryコマンドを実行します。
|
関連項目: OPatchの構文およびコマンドは、Oracle OPatchユーザーズ・ガイドfor Windows and UNIXの付録Aを参照してください。 |
アップグレードを手動で行ったか、Database Upgrade Assistant(DBUA)を使用して自動的に行ったかに関係なく、Oracle Databaseをアップグレードした後、使用環境に対して指定されている必要な作業を完了する必要があります。また、使用している環境についての重要な情報も考慮する必要があります。次の項目で、必要な手順と情報について説明します。
ご使用のオペレーティング・システムがLinuxまたはUNIXで、かつOracle Databaseを手動でアップグレードした場合は、特定の環境変数が新しいOracle Databaseリリースのディレクトリを指していることを確認する必要があります。DBUAでは、自動的に環境変数に対して必要な変更が行われることに注意してください。また、クラスタ・データベースをアップグレードしている場合は、そのクラスタ・データベースのインスタンスが構成されているすべてのノードでこれらを確認してください。
次の環境変数が新しいOracleホームのディレクトリを指していることを確認します。
ORACLE_HOME
PATH
|
関連項目:
|
Oracle Databaseを新しいリリースにアップグレードした後に、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、新しいOracle Database 11gリリース用に作成された新しいOracleホームを指していることを確認する必要があります。DBUAではoratabは自動的に新しいOracleホームを指しますが、アップグレードにどの方法を使用しても、クライアント・スクリプトを確認する必要があります。
|
関連項目: 『Oracle Database管理者ガイド』 |
リカバリ・カタログのアップグレード、およびUPGRADE CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の手順に関する項目を参照してください。
データベースのアップグレードを完了した後、アップグレード前情報ツールによってタイム・ゾーン・ファイルをアップグレードするよう指示された場合は、DBMS_DST PL/SQLパッケージを使用してこのファイルをアップグレードします。
Oracle Databaseでは複数のバージョンのタイム・ゾーン・ファイルが提供されており、互いに関連付けられている2種類のファイルがあります。1つはデータベースで定義されているすべてのタイム・ゾーンを含む大きなファイルで、もう1つは最も一般的に使用されるタイム・ゾーンのみを含む小さいファイルです。大きいバージョンはtimezlrg_version_number.dat、小さいバージョンはtimezone_version_number.datと指定されます。ファイルは、Oracle Databaseホーム・ディレクトリ下のoracore/zoneinfoサブディレクトリにあります。
|
関連項目:
|
DBMS_STATS.CREATE_STAT_TABLEプロシージャを使用して統計表を作成した場合、次のプロシージャを実行してこれらの表をアップグレードします。
EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('scott', 'stat_table');
この例で、SCOTTは統計表の所有者で、STAT_TABLEは統計表の名前です。各統計表にこのプロシージャを実行します。
Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)からのアップグレード時に、外部認証されたSSLユーザーを使用している場合は、SSL外部ユーザー変換(extusrupgrade)スクリプトを実行してそれらのユーザーをアップグレードする必要があります。スクリプトの構文は次のとおりです。
ORACLE_HOME/rdbms/bin/extusrupgrade --dbconnectstring
<hostname:port_no:sid> --dbuser <db admin> --dbuserpassword
<password> -a
|
注意: Oracle Database 10gリリース2(10.2)以上のリリースからアップグレードしている場合は、このコマンドを実行する必要はありません。 |
|
関連項目: extusrupgradeスクリプトの詳細は、を参照してください。 |
Oracle Textナレッジ・ベースはOracle Database 11gリリースの付属製品の一部ですが、新しいOracle Database 11gへのアップグレード後すぐに使用できるようにはなっていません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレード後には機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースをインストール・メディアからインストールする必要があります。
Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、アップグレード後に再生成する必要があります。これらの変更は、指定されたOracleホームにインストールされているすべてのデータベースに影響します。
|
関連項目:
|
元のデータベースにApplication Expressバージョン3.2以上が含まれていた場合は、新しいOracle Database 11gリリースにアップグレードした後に必要な追加の構成はありません。
Oracle Express Edition(XE)データベース以外のデータベースを使用していた場合で、前のバージョンのApplication Express(HTML DB)が含まれている場合は、アップグレード中に最新バージョンが自動的にインストールされます。新しいOracle Database 11gリリースと併用するには、インストール後の一連の手順を実行して、Application Expressを構成する必要があります。
|
関連項目: Application Expressのインストール後作業の詳細は、『Oracle Application Expressインストレーション・ガイド』を参照してください。 |
Oracle Express Edition(XE)データベースを使用している場合は、XE環境向けの前バージョンのApplication Expressが含まれています。次のURLに用意されている、Oracle XEとOracle Application Expressの相違点を説明したOTNのドキュメントを参照してください。
http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html
XEエディションのApplication Expressで使用できるデータベース管理機能はApplication Expressバージョン3.2では使用できませんが、Oracle Enterprise Manager Database Controlを追加でインストールすれば、データベース管理用のグラフィカル・インタフェースが提供されます。
Oracle Database 11gには、Oracle XML DBを使用するUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、またはUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。これらのパッケージを使用するアプリケーションがある場合は、Oracle XML DBがまだインストールされていなければインストールする必要があります。これらのパッケージを前のリリースと同様に動作させるには、データベースのネットワーク・アクセス制御リスト(ACL)を構成することも必要です。
次の例では、最初にhost_nameに現在割り当てられているACLを検索します。見つかると、この例では、user_nameがまだCONNECT権限を持っていない場合にかぎり、ACL内でこの権限をユーザーに付与します。host_name用のACLが存在しない場合、この例では、ACL_nameという新しいACLを作成し、user_nameにCONNECT権限を付与し、このACLをhost_nameに割り当てます。
DECLARE acl_path VARCHAR2(4000); BEGIN SELECT acl INTO acl_path FROM dba_network_acls WHERE host = 'host_name' AND lower_port IS NULL AND upper_port IS NULL; IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(acl_path, 'user_name','connect') IS NULL THEN DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(acl_path, 'user_name', TRUE, 'connect'); END IF; EXCEPTION WHEN no_data_found THEN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('ACL_name.xml', 'ACL description', 'user_name', TRUE, 'connect'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('ACL_name.xml','host_name'); END; COMMIT;
|
注意: 変更を有効にするには、トランザクションをコミットする必要があります。 |
|
関連項目: 一部のユーザーはホストAに接続し、別のユーザーはホストBに接続するなど、より複雑な状況については、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
Oracle Database Vaultを使用している場合は、データベースをアップグレードする前にこれを無効にするように指示がありました。ここで、次を行う必要があります。
Database Vaultの有効化
SYSアカウントからのDatabase VaultのDV_PATCH_ADMINロールの取消
|
関連項目:
|
データベースをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。これらはアップグレードを手動で行ったかDBUAを使用して行ったかに関係なく推奨される作業です。
データベースをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。
必ず本番データベースの全体バックアップを作成してください。
|
関連項目: データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Oracle Database 11gリリース1(11.1)以上では、パスワードに大/小文字の区別を強制できるようになりました。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。これまでのリリースでは、パスワードの大/小文字は区別されませんでした。
パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいデータベース・インスタンスの場合は、追加の作業や追加の管理要件はありません。データベースをアップグレードした場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。
また、デフォルトを変更して、パスワード検証機能で大/小文字が区別されるようにすることもできます。通常のユーザーの場合は、初期化パラメータsec_case_sensitive_logonをfalseに設定します。
sql> alter system set sec_case_sensitive_logon=false;
sysdbaユーザーおよびsysoperユーザーの場合は、新しいコマンドライン・スイッチignorecaseを使用して、新しいorapwファイルを生成できます。
|
注意: Oracle Databaseリリース11gのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
|
関連項目: 『Oracle Databaseセキュリティ・ガイド』 |
Oracle Clusterware 11gリリース2およびOracle ASM 11gリリース2は、両方ともOracle Grid Infrastructureの一部としてインストールされます。
Oracle Grid Infrastructureは、単一サーバーにインストールした場合、Oracle ASMとともにOracle Restartインストールとしてデプロイされます。クラスタにインストールした場合は、Oracle ASMとともにOracle Clusterwareインストールとしてデプロイされます。
Oracle Restartは、単一インスタンス環境におけるOracle Databaseの可用性を向上します。Oracle Restartをインストールし、データベース、リスナー、Oracle ASMインスタンスなどのOracle Databaseソフトウェア・スタックの一部が一時的に失敗した場合、失敗したコンポーネントはOracle Restartによって自動的に再起動されます。また、これらのすべてのコンポーネントは、データベース・ホスト・コンピュータが再起動されるときに、Oracle Restartによって起動されます。コンポーネントは、コンポーネント間の依存性を考慮して適切な順序で起動されます。
Oracle Clusterwareは、単一サーバーを単一システムとして連携するようにクラスタ化できるポータブル・クラスタ・ソフトウェアです。Oracle RACに必須なインフラストラクチャも提供します。また、Oracle Clusterwareでは、クラスタ内の任意のOracleアプリケーションまたはその他のアプリケーションを保護できます。いずれの場合でも、Oracle Clusterwareはそれらのシステムにおけるインテリジェント機能としてクラスタ・ノード間の必要な連携を確実にします。
以前のリリースまでは、Oracle ASMは、Oracle Databaseインストールの一部としてインストールされていました。Oracle Database 11gリリース2(11.2)では、Oracle ASMは、Grid Infrastructureコンポーネントのインストール時にインストールされ、また、Oracle RACなどとともにクラスタにインストールされた場合にはOracle ClusterwareとOracleホームを共有し、スタンドアロンサーバーにインストールされた場合にはOracle RestartとOracleホームを共有します。
既存のOracle ASMインスタンスがある場合は、Oracle Grid Infrastructureのインストール中またはインストール後にアップグレードできます。ただし、Oracle ClusterwareによってOracle ASMが管理されるのは、Oracle ASMがGrid Infrastructureホームで実行されている場合にかぎられるため、Oracle ASMをアップグレードするまでは、いくつかのOracle ASM機能が無効になったり、Oracle ClusterwareによるOracle ASMの管理が正しく機能しないことに注意してください。このことから、Oracle Clusterwareのアップグレードと同時にOracle ASMをアップグレードしない場合は、Oracle ASMを直後にアップグレードすることをお薦めします。
Oracle ASM Configuration Assistant(ASMCA)を使用してOracle ASMインスタンスをアップグレードできます。
旧リリースでは、Database Upgrade Assistant(DBUA)を使用してOracle DatabaseまたはOracle ASMをアップグレードできました。現在はそうではありません。DBUAを使用してアップグレードできるのは、Oracle Databaseインスタンスのみです。Oracle ASMをアップグレードするには、Oracle ASM Configuration Assistant(ASMCA)を使用します。
『Oracle Database新機能ガイド』では、新しいOracle Database 11gリリースで使用可能な多くの新機能について説明されています。どの新機能がデータベースおよびアプリケーションに有効かを判断して、これらの機能を使用する計画を立ててください。
新しいOracle Databaseソフトウェアを使用するためにすぐに変更する必要はありません。データベースおよびそれに対応するアプリケーションに、これらの拡張機能を徐々に取り入れることもできます。
第5章「Oracle Databaseのアップグレード後のアプリケーションのアップグレード」では、新しいOracle Database 11gリリースの機能を利用するためにアプリケーションを拡張する方法について説明します。ただし、新機能を実装する前にアプリケーションをテストし、アップグレードしたデータベース上でアプリケーションを正常に動作させる必要があります。
新しいOracle Database 11gリリースの機能をよく理解したうえで、データベース管理用のスクリプトおよびプロシージャを再確認し、変更が必要かどうかを判断します。
それぞれのアプリケーションに必要な変更を、データベースにも行う必要があります。たとえば、データベースで整合性制約を使用可能にした場合、アプリケーションでのデータ・チェックの一部を削除できます。
アップグレードされたOracle Database 11gリリース1(11.1)データベースでは、表領域アラートが無効になっています(しきい値がNULLに設定されています)。データベース内の監視対象の表領域を指定し、適切なしきい値を設定する必要があります。
新しく作成されたOracle Database 11gリリース1(11.1)データベースのデフォルトのしきい値は次のとおりです。
警告(表領域の使用率が85%の場合)
クリティカル(表領域の使用率が97%の場合)
この項では、ロールバック・セグメント(手動UNDO管理)を使用するデータベースを、アップグレード中に自動UNDO管理へ移行する手順を説明します。
Oracle Database 11gリリース1(11.1)以上では、デフォルトのUNDO領域管理モードは自動UNDO管理です。システムで使用するUNDO領域管理モードは、次のようにUNDO_MANAGEMENT初期化パラメータで指定します。
UNDO_MANAGEMENT=AUTOの場合(またはUNDO_MANAGEMENTを設定しない場合)は、データベース・インスタンスは自動UNDO管理モードで起動します。
UNDO_MANAGEMENT初期化パラメータがNULLの場合のデフォルトは、Oracle Database 11gリリース1(11.1)では自動UNDO管理モードですが、前のリリースでは手動UNDO管理モードです。したがって、前のリリースをOracle Database 11gにアップグレードする際は注意が必要です。
UNDO_MANAGEMENT=MANUALの場合、UNDO領域はロールバック・セグメントとして外部に割り当てられます。
現在ロールバック・セグメントを使用してUNDO領域を管理している場合は、Oracle Database 11gリリース1(11.1)データベースを自動UNDO管理に移行することをお薦めします。移行した場合、新しくアップグレードしたデータベースを自動UNDO管理を使用して開く前に、まずUNDO表領域を作成する必要があります。UNDO表領域に必要なサイズは、システムのワークロードおよびフラッシュバックの要件によって異なります。
自動UNDO管理に移行するには、次の手順を実行します。
UNDO_MANAGEMENT=MANUALに設定します。
インスタンスを再起動して標準的なビジネス・サイクルを一通り実行し、代表的なワークロードを取得します。このようにしてワークロードを評価し、自動UNDO管理で必要なUNDO表領域のサイズを計算します。
標準的なビジネス・サイクルを完了したら次のファンクションを実行し、UNDO表領域のサイズと、UNDO表領域のサイズ変更に関するヘルプを収集します(このファンクションの実行にはDBA権限が必要です)
DECLARE utbsiz_in_MB NUMBER; BEGIN utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION; end; /
このファンクションではPL/SQLプロシージャが実行され、システム構成およびシステムのロールバック・セグメントの使用状況を基にして、新しいUNDO表領域のサイズを求める方法に関する情報が提供されます。このファンクションはサイズ変更に関する情報を直接戻します。
必要なサイズのUNDO表領域を作成し、UNDO_MANAGEMENT=AUTOに設定するかパラメータを削除して、自動UNDO管理を有効にします。
Oracle RAC構成の場合は、すべてのインスタンスでこれらの手順を繰り返します。
Data Guard BrokerのプロパティLocalListenerAddressは、ブローカの通信方法およびREDOの転送の設定方法が変更されたため、リリース11.2.0.1では非推奨となりました。
ブローカのプロパティInitialConnectIdentifierは、DGConnectIdentifierに変更されました。DGConnectIdentifierの値は、常時、すべてのData Guardネットワーク・トラフィック用に使用されます。Oracle Databaseリリース10gの構成をアップグレードする場合は、最初にOracle Database 11gリリース1(11.1)にアップグレードする必要があり、InitialConnectIdentifierの値は、11gデータベースのDGConnectIdentifierの新しい値として保持されます。Oracle RACデータベースをアップグレードする場合、データベース管理者は、InitialConnectIdentifierプロパティの値がすべてのインスタンスに到達できることを確認する必要があります。
LOBデータ型(BFILE、BLOB、CLOBおよびNCLOB)には、LONGデータ型よりも多くのメリットがあります。LONGデータ型とLOBデータ型の違いの詳細は、『Oracle Database概要』を参照してください。
Oracle9iリリース1(9.0.1)以上では、ALTER TABLE文を使用して、LONGデータ型の列をCLOBに、LONG RAWデータ型の列をBLOBに変更できます。
次の例では、long_tab表のlong_colというLONG列が、CLOBデータ型に変更されます。
SQL> ALTER TABLE Long_tab MODIFY ( long_col CLOB );
この方法でLONG列をLOBに変換した後も、表に設定されている既存の制約およびトリガーはすべて使用できます。ただし、表のすべての列で、ドメイン索引およびファンクション索引を含むすべての索引が使用不可となるため、ALTER INDEX ... REBUILD文を使用してすべての索引を再構築する必要があります。また、LONG列上のドメイン索引は、LONG列をLOBに変更する前に削除する必要があります。
|
関連項目: LOBデータを使用するためのアプリケーションの変更の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。 |
テスト・データベースを新しいOracle Database 11gリリースにアップグレードしてテストした場合、新しいOracle Database 11gリリースにアップグレードした本番データベースでも同じテストを繰り返すことができます。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。
新しいOracle Databaseで既存のアプリケーションが正常に動作するかどうかを確認するために、この新しくアップグレードされた本番データベースをテストします。また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。ただし、アプリケーションがアップグレードの前と同様に動作するかどうかを最初に確認してください。
Oracle Database 10gリリース1(10.1)またはOracle Database 10gリリース2(10.2)をアップグレードした後に次の作業を行うことをお薦めしますが、必須の作業ではありません。
Oracle Database 10gリリース2(10.2)以上では、非同期チェンジ・データ・キャプチャ(CDC)に、ソースおよびターゲット・データベースのオペレーティング・システムが同じである必要はなくなりました。この機能を使用すると、異なるオペレーティング・システムおよびOracle Databaseリリースを使用した異機種間CDC設定が可能になり、これによって既存のOracle9iリリース2(9.2)システムをソースとして活用できるようになります。
|
関連項目: Oracle9iリリース2(9.2)またはOracle Database 10gリリース1(10.1)データベースをチェンジ・データ・キャプチャを使用して新しいOracle Database 11gリリースにアップグレードする方法およびチェンジ・データ・キャプチャの分散HotLogモードでサポートされる構成の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。 |
Oracle XML DBへのHTTPSアクセスを構成するには、この項の説明に従って正しい構成情報を指定します。
データベースをOracle Database 10gリリース2(10.2)以上にアップグレードすると、Oracle XML DB構成ファイル用のXMLスキーマは自動的にアップグレードされ、リポジトリ内の/xdbconfig.xmlにあるOracle XML DB構成ファイルにhttp2-portとhttp2-protocolの2つの要素を追加できるようになります。これらの要素は、アップグレード時にデフォルトではOracle XML DB構成ファイルに追加されません。HTTPSに対するサポートが必要な場合は、構成ファイルを編集して、これらの2つの新しい要素(正確な位置についてはXMLスキーマを参照)を追加し、http2-protocolの値をtcpsに設定する必要があります。http2-portの値には、http-portとは異なる値を指定する必要があります。
Oracle XML DB構成ファイルのパラメータhttp2-portおよびhttp2-protocolを指定するのみでなく、Oracle XML DBでHTTPSを使用できるように、データベースおよびリスナーを構成する必要があります。また、次の手順をアップグレード前に実行しなかった場合は、アップグレード後に実行する必要があります。
Oracle XML DBでHTTPSを使用できるようにするには、次の手順を実行します。
HTTPリスナーおよびデータベースでSSLを使用できるようにします。
TCPSディスパッチャを起動できるようにします。
実行方法は、『Oracle XML DB開発者ガイド』を参照してください。
|
注意: まだシステムにOracle XML DBがインストールされていない場合は、アップグレード作業中にインストールする必要があります。Oracle XML DBでは、アクセス制御リスト(ACL)を適切に維持する必要があります。 |
HTTPを介してXML DBリポジトリ・データに匿名アクセスする必要がない場合は、この手順を実行する必要はありません。HTTPを介してXML DBリポジトリ・データに匿名アクセスする必要がある場合は、この項の説明に従って正しい構成情報を指定する必要があります。管理者は、考えられるセキュリティ上の危険性を考慮し、匿名アクセスを許可するかどうかを十分に検討する必要があります。
データベースをOracle Database 10gリリース2(10.2)以上にアップグレードすると、リポジトリ内の/xdbconfig.xmlにあるOracle XML DB構成ファイル用のXMLスキーマは自動的にアップグレードされ、Oracle XML DB構成ファイルにallow-repository-anonymous-accessという要素を追加できるようになります。この要素はブール型で、trueまたはfalseという値を指定できます。この要素を使用すると、ANONYMOUSユーザー・アカウントをロック解除した場合でも、認証されていないアクセスをHTTPを介してOracle XML DBリポジトリ・データに行うことを禁止できます。allow-repository-anonymous-access要素は、アップグレード時にデフォルトではOracle XML DB構成ファイルに追加されませんが、この要素が欠落している場合はfalseと解釈されます。
したがって、Oracle Database 10gリリース2(10.2)以上にアップグレードすると、HTTPを介したXML DBリポジトリ・データへの匿名アクセスが無効になります。HTTPを介してXML DBリポジトリ・データに匿名アクセスする場合は、ANONYMOUSユーザー・アカウントをロック解除すること以外に、構成ファイルを変更してこの新しい要素をtrueに設定する必要があります。
|
注意: リポジトリへの認証されていないアクセスを許可した場合は、セキュリティ上の危険性を伴う可能性があります。 |
|
関連項目: allow-repository-anonymous-access要素、およびOracle XML DBの構成方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。 |
Oracle Express Editionのデータベースに含まれているのは、Standard EditionまたはEnterprise Editionのデータベースで使用できるコンポーネントのサブセットのみです。新しいOracle Database 11gリリースにアップグレードした後、Database Configuration Assistantを使用して追加のコンポーネントをデータベースにインストールできます。DBUAによるアップグレード中にEnterprise Manager Database Controlをインストールしなかった場合は、データベースに追加する他の任意のコンポーネントとあわせてインストールできます。
Oracle Real Application Clusters(Oracle RAC)11gリリース2(11.2)には、単一クライアント・アクセス名(SCAN)が導入されています。SCANは、パブリック・ネットワークで3つのIPアドレスに解決される単一の名前です。以前のリリースのOracle RACデータベースは、11gリリース2(11.2)にアップグレードされると、リモート・リスナーとしてSCANリスナーに登録され、引き続きすべてのノード・リスナーにも登録されます。SCANを使用するか、または引き続きノード・リスナーを使用するようにクライアントを構成できます。SCANを使用するようにすべてのクライアント接続を移行する場合は、REMOTE_LISTENERSパラメータからノード・リスナーを削除できます。ただし、ノード・リスナーのみがデータベースの専用サーバーを作成できるため、リスナー自体を削除することはできません。
|
関連項目: 単一クライアント・アクセス名(SCAN)の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
DBUAを使用せず手動でOracle Databaseのアップグレードを実行している場合は、データベースをアップグレードした後で、追加作業を実行する必要があります。
アップグレード元のリリースによっては、新しいアカウントが提供されている場合があります。SYSおよびSYSTEM以外のオラクル社が提供するアカウントは、すべてロックしてパスワードを期限切れにし、アカウントのロックを解除したときに新しいパスワードの指定が要求されるようにすることをお薦めします。
|
注意: Oracle Database 11gのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
次のSQL文を発行して、すべてのアカウントの状態を確認できます。
SQL> SELECT username, account_status
FROM dba_users
ORDER BY username;
次のSQL文を発行して、パスワードをロックまたは期限切れにします。
SQL> ALTER USER username PASSWORD EXPIRE ACCOUNT LOCK;
REMOTE_LOGIN_PASSWORDFILE初期化パラメータがexclusiveまたはsharedに設定されている場合、ORAPWDでパスワード・ファイルを作成します。
|
関連項目: パスワード・ファイルの作成の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
従来の初期化パラメータ・ファイルを使用している場合は、次の手順でサーバー・パラメータ・ファイルへ移行します。
初期化パラメータ・ファイルがクライアント・コンピュータ上にある場合は、クライアント・コンピュータからサーバー・コンピュータに転送します。
|
注意: Oracle RACを使用している場合は、すべてのインスタンス固有の初期化パラメータ・ファイルを単一の初期化パラメータ・ファイルに結合する必要があります。インスタンス固有の初期化パラメータ・ファイルの結合方法およびクラスタ・データベース用のサーバー・パラメータ・ファイルの使用方法については、次のマニュアルを参照してください。
|
CREATE SPFILE文を使用して、サーバー・パラメータ・ファイルを作成します。この文は、初期化パラメータ・ファイルを読み取り、サーバー・パラメータ・ファイルを作成します。CREATE SPFILE文を発行するために、データベースを起動する必要はありません。
新しく作成されたサーバー・パラメータ・ファイルを使用して、インスタンスを起動します。
|
関連項目:
|
新しいOracle Database 11gリリースへアップグレードした後、次のファイルを以前のOracleホームから新しいOracleホームにコピーします。
ステミング・ユーザー・ディクショナリ・ファイル
ユーザーが変更したKOREAN_MORPH_LEXERディクショナリ・ファイル
USER_FILTER実行可能ファイル
これらのファイルは、指定されたOracleホームにインストールされているすべてのデータベースに影響します。
これらのファイルのリストは、次の方法で取得できます。
$ORACLE_HOME/ctx/admin/ctxf102.txtを検索する
データベース・ユーザーSYS、SYSTEM、またはCTXSYSで、$ORACLE_HOME/ctx/admin/ctxf102.sqlを実行する
Oracle Textの索引でKOREAN_LEXERを使用している場合、これはOracle 9iで非推奨になり、Oracle Database 10gリリース2(10.2)でサポート対象外になっているため、My Oracle SupportのNote 300172.1でKOREAN_LEXERからKOREAN_MORPH_LEXERに手動で移行する方法を参照してください。
|
関連項目:
|
Oracle Clusterwareを使用している場合は、データベースのOracle Clusterwareキーをアップグレードする必要があります。
リリース11.2.0.3のsrvctlを実行してデータベースをアップグレードします。次に例を示します。
%11.2.0.3_ORACLE_HOME/bin/srvctl upgrade database -d <name> -o 11.2.0.3_ORACLE_HOME
|
注意: デフォルトでは、指定したユーザーはサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、特定のユーザーをCRS管理者のリストに追加することをお薦めします。関連項目: CRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください |
Oracle Databaseの新しいリリースごとに新しい初期化パラメータが導入され、非推奨となったり、廃止される初期化パラメータもあります。ご使用のシステムに有効な新しい初期化パラメータを使用するために、これらの変更に対してパラメータ・ファイルを調整する必要があります。また、DBUAを使用しないで手動アップグレードを実行した場合、tnsnames.oraファイルには新しい構成情報と設定が自動的に移入されません。したがって、手動でtnsnames.oraを更新し、local_listenerおよびremote_listenerパラメータ参照を調節する必要がある場合があります(これらを解決する必要がある場合)。
|
関連項目:
|
COMPATIBLE初期化パラメータは、ご使用のデータベースの互換レベルを制御します。データベースを元のリリースにダウングレードする必要がない場合は、新しいデータベースで必要な互換性レベルに基づいてCOMPATIBLE初期化パラメータを設定します。
COMPATIBLE初期化パラメータ値を増やすには、次の手順を実行します。
COMPATIBLE初期化パラメータ値を増やす前に、データベースのバックアップを取ります(オプション)。
COMPATIBLE初期化パラメータ値を増やすことによって、現在のデータベースが以前のリリースのOracle Databaseとは非互換になる可能性があります。バックアップを取っておくと、必要に応じて以前のリリースに戻すことができます。
|
関連項目: バックアップの実行の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
サーバー・パラメータ・ファイルを使用している場合は、次の手順を実行します。
サーバー・パラメータ・ファイルを更新して、COMPATIBLE初期化パラメータの値を設定または変更します。
たとえば、COMPATIBLE初期化パラメータを11.0.0に設定するには、次の文を入力します。
SQL> ALTER SYSTEM SET COMPATIBLE = '11.0.0' SCOPE=SPFILE;
インスタンスを停止し、再起動します。
|
関連項目: HARDストレージの詳細は、『Oracle Database高可用性概要』または『Oracle Database概要』を参照してください。 |
初期化パラメータ・ファイルを使用している場合は、次の手順を実行します。
インスタンスが実行している場合は、停止します。
SQL> SHUTDOWN IMMEDIATE
初期化パラメータ・ファイルを編集して、COMPATIBLE初期化パラメータの値を設定または変更します。
たとえば、COMPATIBLE初期化パラメータを11.0.0に設定するには、初期化パラメータ・ファイルに次のように入力します。
COMPATIBLE = 11.0.0
STARTUPを使用してインスタンスを起動します。
|
注意: ASMディスク・グループを使用している場合、ディスク・グループの互換性属性は、init.oraのデータベース互換性パラメータの値以下である必要があります。 |
手動アップグレードの実行後、tnsnames.oraで解決する必要がある場合は、local_listenerおよびremote_listenerパラメータ参照を調節する必要がある場合があります。DBUAは、自動アップグレード時にネットワーク・ネーミングとリスナーの変更を処理しますが、手動アップグレード時には、tnsnames.oraもリスナーも変更されません。
|
関連項目:
|
まだOracle Enterprise Managerを使用してデータベースを管理していない場合は、Enterprise Manager Database Controlをインストールして構成します。
Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlでデータベースを管理している場合は、次のコマンドを使用して構成を更新します。
emca -upgrade (db | asm | db_asm) [-cluster] [-silent] [parameters]
新しいOracle Database 11gリリースのOracleホームからこれを実行する必要があります。プロンプトが表示されたら、構成のアップグレードを行うOracleホームを入力します。
Enterprise Managerは、DBCAを使用して構成することもできます。「データベース・オプションの構成」オプションを選択してから、「Enterprise Managerリポジトリ」オプションを選択します。
|
関連項目: 『Oracle Enterprise Manager構成ガイド』 |
Oracle RACデータベースのアップグレードについては、「手動アップグレードを行う場合の新しいOracleホームの準備」に、クラスタ・データベースをアップグレードする前にCLUSTER_DATABASE初期化パラメータをfalseに設定するよう指示がありました。アップグレードが完了した時点で、この初期化パラメータをtrueに設定する必要があります。
Oracle ASMリリース11.2以上のリリースは、Oracle Grid Infrastructureインストールの一部としてインストールされます。
クラスタのOracle ClusterwareとOracle ASMをアップグレードすると、Oracle ClusterwareとOracle ASMは両方ともGridホームと呼ばれる同じホームに配置されます。すべてのOracleソフトウェア・インストールを所有するインストール所有者を1人のみ割り当てることも、ロール割当て済の所有者を使用することもできますが、後者の場合は、Grid Infrastructureインストールに別のソフトウェア所有者、1つ以上のOracle Databaseインストールに別々のソフトウェア所有者を使用します。
次の作業は、別のインストール手順で実行されたOracle ASMからOracle Grid Infrastructureの一部としてインストールされるOracle ASMへのアップグレード後に行う必要があります。
|
関連項目: ロール割当て済のインストール所有者の詳細は、ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
ご使用のオペレーティング・システムがLinuxまたはUNIXの場合、アップグレードを実行した後に環境変数の設定を変更する必要がある場合があります。
すべてのインストールに1人のOracleインストール所有者を使用する場合は、Oracle Databaseインスタンスをデータベース管理の一部として管理するかどうか、またはOracle ASMインスタンスをストレージ管理の一部として管理するかどうかに応じて、ORACLE_HOMEなどの環境変数をOracle DatabaseホームまたはGridホームに変更する必要があります。
ロール割当て済のOracleインストール所有者を使用し、Oracle Grid Infrastructure(Oracle ClusterwareとOracle ASM)ソフトウェアに別の所有者を使用する場合は、Grid Infrastructureインストール所有者の次の環境変数を、Grid Infrastructureホーム内のOracle ASMホームのディレクトリを指すように設定します。
ORACLE_HOME
PATH
また、oratabファイルおよびORACLE_HOME値を設定するOracle ASMのすべてのクライアント・スクリプトが、Grid Infrastructureホーム内のOracle ASMホームを指していることを確認します。
|
注意: クラスタOracle ASMインストールをクラスタ用のOracle Grid Infrastructureにアップグレードする場合は、すべてのクラスタ・メンバー・ノードでこれらを確認してください。 |
|
関連項目: ご使用のオペレーティング・システムでのその他の重要な環境変数の設定は、オペレーティング・システム固有のOracle Databaseのインストレーション・ガイドを参照してください。 |
以前のリリースまでは、Oracle ASMは、Oracle Databaseインストールの一部としてインストールされていました。Oracle Database 11gリリース2(11.2)以上では、Oracle ASMは、Grid Infrastructureコンポーネントのインストール時にインストールされます。クラスタにOracle Grid Infrastructureをインストールした場合、Oracle ClusterwareとともにGridホームに格納されます。単一サーバーにOracle Grid Infrastructureをインストールした場合、Oracle ASMはOracleホームをOracle Restartと共有します。
既存のOracle ASMをアップグレードする場合は、Oracle Grid Infrastructureのアップグレードを実行してOracle ASMをアップグレードする必要があります。Oracle ASMがインストールされていない場合、Oracle ASMを記憶域オプションとして使用するには、Oracle Databaseのインストールを開始する前に、Oracle Grid Infrastructureのインストールを完了してください。
|
関連項目: ご使用のプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』または『Oracle Databaseインストレーション・ガイド』を参照してください。 |
Oracle ASM Configuration Assistant(ASMCA)では、Oracle ASMインスタンス、ディスク・グループ、ボリュームおよびOracle ASMクラスタ・ファイルシステム(Oracle ACFS)のインストールおよび構成がサポートされています。さらに、非GUIユーティリティとしてASMCAコマンドライン・インタフェース(コマンド名はasmca)を使用できます。
asmcaコマンドを使用してアップグレードを個別に完了できます。ただし、Oracle ASMがアップグレードされるまでsrvctlなどのOracle ASM管理ツールが動作しないため、Oracle Clusterwareのアップグレード後すぐにasmcaを実行する必要があります。
|
注意: クラスタ・アップグレードの場合、ASMCAによってローリング・アップグレードが実行されるのは、Oracle ASMの以前のリリースが11.1.0.6または11.1.0.7の場合のみです。それ以外の場合は、ASMCAにより、通常のアップグレードが実行され、すべてのOracle ASMインスタンスはクラスタのすべてのノードで停止されてから新しいGrid Infrastructureホームで起動されます。 |
Oracle ASMのローリング・アップグレードを実行する場合は、次の情報に注意してください。
アップグレードの一部としてホームの所有者を変更することはできません。たとえば、ユーザーgridでOracle Grid Infrastructureをインストールする場合、アップグレード前に、既存のOracle ASMのホームがユーザーgridによって所有されている必要があります。
Oracle Clusterwareのアクティブなリリースは、11gリリース2(11.2)である必要があります。アクティブなリリースを確認するには、次のコマンドを入力します。
$ crsctl query crs activeversion
|
関連項目: crsctlおよびCRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください |
単一インスタンスのOracle ASMインストールをクラスタOracle ASMインストールにアップグレードできます。ただし、Oracle ASMがインストールされているノードからインストールを実行した場合、アップグレードできるのは既存の単一インスタンスのOracle ASMインストールのみです。リモート・ノードの単一インスタンスのOracle ASMインストールをアップグレードすることはできません。
アップグレード処理を開始する前に、既存のOracle ASMインストールに対するリバランス操作が完了していることを確認する必要があります。
アップグレード処理中に、Oracle ASMインスタンスをアップグレード状態に変更します。このアップグレード状態によってOracle ASM操作が制限されるため、開始後すぐにアップグレード処理を完了する必要があります。Oracle ASMインスタンスがアップグレード状態のときに実行できる操作は次のとおりです。
ディスク・グループのマウントとディスマウント
データベース・ファイルのオープン、クローズ、サイズ変更または削除
インスタンスのリカバリ
固定ビューとパッケージの問合せ: 固定ビューに問い合せたり、dbms_diskgroupなどの固定パッケージを使用して無名PL/SQLブロックを実行できます。
この項の手順では、Oracle ASM Configuration Assistant(ASMCA)を使用してOracle ASMをアップグレードする方法について説明します。
Oracle ASMをアップグレードするには、次の手順を実行します。
Oracle Grid Infrastructureインストールのインストール所有者としてログオンします。
クラスタでアップグレードを行っており、ノードでアップグレードを開始する場合は、環境変数ASMCA_ROLLING_UPGRADEをtrueとして設定します。次に例を示します。
$ export ASMCA_ROLLING_UPGRADE=true
Oracle Grid Infrastructure 11gリリース2(11.2)のホームから、ASMCAを起動します。次に例を示します。
$ cd /u01/11.2/grid/bin $ ./asmca
「アップグレード」を選択します。
Oracle ASM Configuration Assistantによって、クラスタ内のすべてのノードのOracle ASMが連続的にアップグレードされます。
|
関連項目: Oracle ASMのアップグレード計画の準備、およびOracle ASMアップグレードの開始、完了および停止の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
この項では、Oracle ASMのアップグレード後に必要な作業と追加の考慮点について説明します。
ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の環境変数が新しいOracle Database 11gリリースのディレクトリを指していることを確認します。
ORACLE_HOME
PATH
また、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、新しいOracle Database 11gリリースのOracleホームを指していることを確認します。
|
注意: ORACLE_HOME、PATHおよびoratabを確認する必要があるのは、手動でアップグレードした場合のみです。DBUAでは、oratabファイルは自動的に新しいOracleホームを指します。クライアント・スクリプトは、アップグレード方法に関係なく、確認する必要があります。
クラスタOracle ASMをアップグレードしている場合は、そのクラスタOracle ASMのインスタンスが構成されているすべてのノードでこれらを確認してください。 |
|
関連項目: ご使用のオペレーティング・システムでのその他の重要な環境変数の設定は、オペレーティング・システム固有のOracle Databaseのインストレーション・ガイドを参照してください。 |
次の手順では、Oracleホーム1(OH1)にOracle ASMがインストールされており、オペレーティング・システム・ユーザーがorauserであることが前提となっています。
Oracle ASMの単一インスタンスのアップグレードを実行するには、次の手順を実行します。
OUIおよびASMCAを使用して、orauserでOracle ASMをリリース11.2にアップグレードします。新しいOracle ASMリリース11.2は、Grid Infrastructureホームで実行されます。Oracle ASMは、引き続きorauserで実行されている必要があります。
orauserでOracle ASMインスタンスおよびリスナーを停止します。
rootで/etc/init.d/init.cssd stopを実行してCSSを停止します。
新しいユーザー(asmuser)で、3つめのOracleホーム(OH3)に11.2をインストールします。ここでインストールするのはソフトウェアのみです。
rootで、OH3からlocalconfig resetを実行します。
/etc/oratabを更新し、OH3が+ASMエントリを含むOracleホームになるようにします。
listener.ora、sqlnet.oraおよびtnsnames.oraを、OH2からコピーします。
EMCPを実行し、Oracle ASMインスタンスのパスとconnect-stringロールを変更します。
ディスクの所有者がasmuserおよびOracle ASMのOSASMであることを確認します。これらのユーザーは、O660の権限セットを保持していることも必要です。
asmuserでリスナーを起動します。
asmuserでOracle ASMを起動します(SYSASMとして接続)。
コマンドGRANT sysasm TO sysを実行します。
クラスタでOracle ASMのアップグレードを実行するには、次の手順を実行します。
OUIおよびASMCAを使用して、orauserでOracle ASMをリリース11.2にアップグレードします。新しいOracle ASMリリース11.2は、新しいOracleホーム2(OH2)で実行されている必要があります。Oracle ASMは、引き続きorauserで実行されている必要があります。
Oracle ASMおよびリスナーのリソースをCRSホームから停止します。
新しいユーザー(crsなど)で、Grid Infrastructureホームのリリースと一致するように3つめのOracleホーム(OH3)に11.2をインストールします。ここでインストールするのはソフトウェアのみです。
CRSのホームから、次のコマンドを実行します。
srvctl remove listener -n node_name srvctl add listener -n node_name -o OH3 srvctl modify asm -n node_name -i ASM_instance_name -o ORACLE_HOME_path
|
注意: デフォルトでは、指定したユーザーはサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、特定のユーザーをCRS管理者のリストに追加することをお薦めします。関連項目: CRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください |
/etc/oratabを更新し、OH3が+ASMエントリを含むOracleホームになるようにします。
listener.ora、sqlnet.oraおよびtnsnames.oraを、OH2からコピーします。
EMCPを実行し、Oracle ASMインスタンスのパスとconnect-stringロールを変更します。
ディスクの所有者がasmuserおよびOracle ASMのOSASMであることを確認します。これらのユーザーは、O660の権限セットを保持していることも必要です。
新しいOracle ASM 11gのORACLE_HOMEまたは新しいOracle Database 11gのORACLE_HOMEからOracle ASMおよびリスナーのリソースを起動します。
コマンドGRANT sysasm TO sysを実行します。
Oracle ASMインスタンスがクラスタ化されている場合は、Oracle ASMのローリング・アップグレードを実行することもできます。ローリング・アップグレードを使用すると、データベースの可用性に影響を与えることなく、Oracle ASMノードに対して個別にアップグレードやパッチの適用を行うことができるため、より長時間の稼働が可能になります。
|
関連項目: Oracle ASMのローリング・アップグレードの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
Oracle Grid Infrastructureバイナリのオペレーティング・システム・ユーザー所有権と1つ以上のデータベースのOracle Databaseインストール所有者を分けた場合は、「Oracle ASMのアップグレード後のロール割当て済のソフトウェアの所有者およびデータベースのアップグレード」の記述に従って、アップグレードしたOracle ASMまたはデータベースのホームのオペレーティング・システム・ユーザーを移行する必要があります。
1つのソフトウェア・バイナリ所有者(oracleなど)から複数のロール割当て済のソフトウェア所有者ユーザー・アカウント(grid、oracle1、oracle2など)に移行する場合、既存のOracle ASMインストール所有者をOracle Grid Infrastructureインストールに使用するインストール所有者に変更します。
検討する例は次の3つです。
|
関連項目: Oracle Database 10gおよびOracle Database 11gとOracle ASMディスク・グループの互換性を保つ方法、およびOracle ASMアップグレードの詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。 |
既存のOracle ASMインストールに使用したのと同じオペレーティング・システム・ユーザーをOracle Grid Infrastructureインストールに使用する場合は、Oracle Universal Installer(OUI)を実行してGrid Infrastructureインストールを実行し、アップグレード・オプションを選択します。Oracle Grid Infrastructureホームで、既存のOracle ASMインストールが以前のリリースから11gリリース2(11.2)に自動的にアップグレードされます。
以前のリリースのOracle ASMがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合に、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更する必要があるとします。これが役立つのは、Oracle ASMを使用するデータベースが2つあり、既存のデータベースと同じインストール所有者でOracle ASMをインストールした状態で、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようにOracle ASMのオペレーティング・システム・インストール所有者を変更する必要がある場合です(どちらのOracle Databaseインストール所有者にもOracle Grid Infrastructureバイナリ所有権がない場合)。
Oracle RACデータベースのオペレーティング・システム・ユーザーを変更する必要がある場合があります。たとえば、以前のリリースのデータベースがOracleホーム4(OH4)にインストールされ、現在オペレーティング・システム・ユーザーoracleで実行されている場合は、Oracle ASMのオペレーティング・システム・ユーザーをgridに変更することを検討する必要があります。Oracle Databaseインストール所有者にGrid Infrastructureバイナリ所有権がない場合は、Oracle ASMのオペレーティング・システム・ユーザーを変更すると、別のデータベースを別のオペレーティング・システム・ユーザーで実行できるようになります。
Oracle ASMをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。
次の作業を実行することも検討してください。これらの作業については、この章の前の方で説明しています。
Oracle Database 11gリリース1(11.1)以上では、パスワードに大/小文字の区別を強制できるようになりました。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。これまでのリリースでは、パスワードの大/小文字は区別されませんでした。
パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいOracle ASMインスタンスの場合は、追加の作業や追加の管理要件はありません。アップグレードしたOracle ASMのインスタンスの場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。
|
注意: Oracle Database 11gのデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
|
関連項目: 『Oracle Databaseセキュリティ・ガイド』 |
Oracle Database 11gリリース1(11.1)以上では、ソフトウェア・バージョンをまたいでOracle DatabaseとOracle ASMのディスク・グループの互換性設定を拡張できます。
互換性を拡張することにより、新しいリリースのみで使用可能な新機能が有効になります。ただし、こうすることで、ソフトウェアの古いリリースではディスク・グループが非互換になります。ディスク上の互換性を拡張する操作は元に戻せないことに注意してください。
compatible.rdbmsおよびcompatible.asm属性を使用して、データベース・インスタンスおよびOracle ASMインスタンスからディスク・グループにアクセスするのに必要な最小ソフトウェア・リリースをそれぞれ指定します。たとえば、次のALTER DISKGROUP文によって、ディスク・グループasmdg2のOracle ASMの互換性が拡張されます。
ALTER DISKGROUP asmdg2 SET ATTRIBUTE 'compatible.asm' = '11.1'
この場合、ディスク・グループを管理できるのはリリース11.1以上のOracle ASMソフトウェアのみですが、データベース・クライアントはリリース10.1以上であれば、このディスク・グループを使用できます。
|
関連項目: ディスク・グループの互換性の詳細は『Oracle Databaseストレージ管理者ガイド』を、ALTER DISKGROUP文およびCREATE DISKGROUP文のディスク・グループ互換性属性の詳細は『Oracle Database SQL言語リファレンス』を参照してください。 |
Oracle ASMの管理者は、一部のディスクを他のディスクより優先して読取りI/O操作に使用するよう指定できます。Oracle ASMの優先読取りの障害グループを定義した場合、Oracle ASMでは常にプライマリ・コピーから読み取るのではなく、最も近いエクステントから読み取ることができます。
