11g リリース1（11.1）
E05758-02
 目次 |
 索引 |
| Oracle Database アップグレード・ガイド 11g リリース1（11.1） E05758-02 |
|
この章では、データベースのアップグレード後に行う手順について説明します。 この章では、次の項目について説明します。
アップグレードを手動で行ったか、Database Upgrade Assistant（DBUA）を使用して行ったかに関係なく、データベースをアップグレードした後、次の作業を行います。
ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の環境変数が新しいOracle Database 11gリリース1（11.1）のディレクトリを指していることを確認します。
また、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、Oracle Database 11gリリース1（11.1）のホームを指していることを確認します。
リカバリ・カタログのアップグレード、およびUPGRADE CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
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ユーザーを使用している場合は、次のコマンドを実行してそれらのユーザーをアップグレードする必要があります。
ORACLE_HOME/rdbms/bin/extusrupgrade --dbconnectstring <hostname:port_no:sid> --dbuser <db admin> --dbuserpassword <password> -a
Oracle Textナレッジ・ベースはOracle Database 11gリリース1（11.1）の付属製品の一部です。Oracle Database 11gリリース1（11.1）へのアップグレード後すぐに使用できるようにはなっていません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレードすると機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースをインストール・メディアからインストールする必要があります。
Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、アップグレード後に再生成する必要があります。これらの変更は、指定されたOracleホームにインストールされているすべてのデータベースに影響します。
元のデータベースにApplication Expressバージョン3.0が含まれていた場合は、Oracle Database 11gリリース1（11.1）にアップグレードした後に必要な追加の構成はありません。
Oracle Express Edition（XE）データベース以外のデータベースを使用していた場合で、旧バージョンのApplication Express（HTML DB）が含まれている場合は、アップグレード中にバージョン3.0が自動的にインストールされます。Oracle Database 11gと併用するには、インストール後の一連の手順を実行して、Application Expressバージョン3.0を構成する必要があります。 構成手順は、『Oracle Database Application Expressインストレーション・ガイド』のインストール後の作業に関する項を参照してください。
Oracle Express Edition（XE）データベースを使用していた場合は、XE環境向けの旧バージョンのApplication Expressが含まれています。Oracle Database XE Application ExpressとApplication Express 3.0の相違点を説明したOTNのドキュメントを参照してください。参照先は次のとおりです。
http://www.oracle.com/technology/products/database/application_express/html/upgrade_apex_for_xe.html
XEバージョンのApplication Expressで使用できるデータベース管理機能はApplication Expressバージョン3.0では使用できませんが、Oracle Enterprise Manager DB Controlを追加でインストールすれば、データベース管理用のGraphical Interfaceが提供されます。
Oracle Database 11gリリース（11.1）には、Oracle XML DBを使用するUTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTP、またはUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。これらのパッケージのいずれかを使用するアプリケーションがある場合は、Oracle XML DBがまだインストールされていなければインストールする必要があります。これらのパッケージを前のリリースと同様に動作させるには、データベースのネットワーク・アクセス制御リスト（ACL）を構成することも必要です。
次の例では、最初にhost_nameに現在割り当てられているACLを検索します。ACLが見つかったら、この例では、user_nameがまだCONNECT権限を持っていない場合にかぎり、このユーザーにACL内のCONNECT権限を付与します。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;
Oracle Database Vaultを使用している場合は、データベースをアップグレードする前にこれを無効にするように指示がありました。今度は、もう一度Database Vaultを有効にする必要があります。
|
参照:
|
Database Vault Administrator（DVA）は、次のOracle Application Server Containers for J2EE（OC4J）のホームに、手動でデプロイできます。
$ORACLE_HOME/oc4j/j2ee/home
次の手順に従って、手動でDVAアプリケーションをデプロイします。
$ORACLE_HOME/oc4j/j2ee/home/config/server.xmlファイルを編集します。次の行を、</application-server>を読み込む最後の行の直前に挿入します。
<application name="dva" path="$ORACLE_HOME/dv/jlib/dva_webapp.ear" auto-start="true" />
次に例を示します。
<application name="dva" path="/u00/app/oracle/oracle/product/dv12/dv/jlib/dva_ webapp.ear" auto-start="true" />
$ORACLE_HOME/oc4j/j2ee/home/config/http-web-site.xmlファイルを編集します。次の行を、</web-site>を読み込む最後の行の直前に挿入します。
<web-app application="dva" name="dva_webapp" root="/dva" />
$ORACLE_HOME/oc4j/j2ee/home/config/global-web-application.xml ファイルを編集します。<servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>という文字列を検索します。この文字列の後にある次の行のコメントを解除します。
<init-param> <param-name>main_mode</param-name> <param-value>justrun</param-value> </init-param>
mkdir -p $ORACLE_HOME/dv/jlib/sysman/config
emoms.propertiesを作成します。次の行をファイルに追加します。
oracle.sysman.emSDK.svlt.ConsoleMode=standalone oracle.sysman.eml.mntr.emdRepRAC=FALSE oracle.sysman.eml.mntr.emdRepDBName=ORACLE_SID oracle.system.eml.mntr.emdRepConnectDescriptor=TNS_connection_string
ORACLE_SID=orcl export ORACLE_SID ORACLE_HOME=/u00/app/oracle/product/10.2/dv export ORACLE_HOME LD_LIBRARY_PATH=$ORACLE_HOME/bin:$ORACLE_HOME/lib:$ORACLE_HOME/jdbc/lib export LD_LIBRARY_PATH PATH=$ORACLE_HOME/bin:$ORACLE_HOME/jdk/bin:$PATH export PATH
次の構文を使用して、OC4Jを起動します。
$ORACLE_HOME/jdk/bin/java -Djava.awt.headless=true -DEMDROOT=$ORACLE_HOME/dv/jlib -jar $ORACLE_HOME/oc4j/j2ee/home/oc4j.jar -userThreads -config $ORACLE_ HOME/oc4j/j2ee/home/config/server.xml
http://hostname:8888/dva
データベースをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。これらはアップグレードを手動で行ったかDBUAを使用して行ったかに関係なく推奨される作業です。
データベースをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。
必ず本番データベースの全体バックアップを作成してください。
Oracle Database 11gリリース1（11.1）以上では、パスワードに大/小文字の区別を強制できるようになりました。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。これまでのリリースでは、パスワードの大/小文字は区別されませんでした。
パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいデータベース・インスタンスの場合は、追加の作業や追加の管理要件はありません。データベースをアップグレードした場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。
また、デフォルトを変更して、パスワード検証機能で大/小文字が区別されるようにすることもできます。 通常のユーザーの場合は、init.oraパラメータsec_case_sensitive_logonをfalseに設定します。
sql> alter system set sec_case_sensitive_logon=false;
sysdbaユーザーおよびsysoperユーザーの場合は、新しいコマンドライン・スイッチignorecaseを使用して、新しいorapwファイルを生成できます。
DBUAを使用する場合は、Oracle Databaseインスタンスのアップグレード、ASMインスタンスのアップグレード、または両方を選択できますが、 手動でアップグレードを実行する場合は、Oracle Databaseのアップグレードとは別にASMのアップグレードを行う必要があります。
『Oracle Database新機能ガイド』では、Oracle Database 11gリリース1（11.1）で使用可能な多くの新機能について説明されています。どの新機能がデータベースおよびアプリケーションに有効かを判断して、これらの機能を使用する計画を立ててください。
新しいOracle Databaseソフトウェアを使用するためにすぐに変更する必要はありません。データベースおよびそれに対応するアプリケーションに、これらの拡張機能を徐々に取り入れることもできます。
第5章「アプリケーションのアップグレード」では、Oracle Database 11gリリース1（11.1）の新機能を利用するためにアプリケーションを拡張する方法について説明します。ただし、新機能を実装する前にアプリケーションをテストし、アップグレードしたデータベース上でアプリケーションを正常に動作させる必要があります。
Oracle Database 11gリリース1（11.1）の新機能をよく理解したうえで、データベース管理用のスクリプトおよびプロシージャを再確認し、変更が必要かどうかを判断します。
それぞれのアプリケーションに必要な変更を、データベースにも行う必要があります。たとえば、データベースで整合性制約を使用可能にした場合、アプリケーションでのデータ・チェックの一部を削除できます。
アップグレードされたOracle Database 11gリリース1（11.1）データベースでは、表領域アラートが無効になっています（しきい値がNULLに設定されています）。データベース内の監視対象の表領域を指定し、適切なしきい値を設定する必要があります。
新しく作成されたOracle Database 11gリリース1（11.1）データベースのデフォルトのしきい値は次のとおりです。
この項では、ロールバック・セグメント（手動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リリース1（11.1）にアップグレードする際は注意が必要です。
UNDO_MANAGEMENT=MANUALの場合、UNDO領域はロールバック・セグメントとして外部に割り当てられます。
現在ロールバック・セグメントを使用してUNDO領域を管理している場合は、Oracle Database 11gリリース1（11.1）データベースを自動UNDO管理に移行することをお薦めします。移行した場合、新しくアップグレードしたデータベースを自動UNDO管理を使用して開く前に、まずUNDO表領域を作成する必要があります。UNDO表領域に必要なサイズは、システムのワークロードおよびフラッシュバックの要件によって異なります。
自動UNDO管理に移行するには、次の手順を実行します。
UNDO_MANAGEMENT=MANUALに設定します。
DECLARE utbsiz_in_MB NUMBER; BEGIN utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION; end; /
このファンクションではPL/SQLプロシージャが実行され、システム構成およびシステムのロールバック・セグメントの使用状況を基にして、新しいUNDO表領域のサイズを求める方法に関する情報が提供されます。このファンクションはサイズ変更に関する情報を直接戻します。
UNDO_MANAGEMENT=AUTOに設定するかパラメータを削除して、自動UNDO管理を有効にします。
Data Guard BrokerのプロパティLocalListenerAddressは、非推奨になる予定です。 ブローカの通信方法およびREDOの転送の設定方法が変更される予定であるため、LocalListenerAddressの値はOracle Database 11gリリース1（11.1）では維持されません。
ブローカのプロパティInitialConnectIdentifierは、DGConnectIdentifierに変更される予定です。DGConnectIdentifierの値は、常時、すべてのData Guardネットワーク・トラフィック用に使用されます。 Oracle Database 10gからOracle Database 11gリリース1（11.1）に構成をアップグレードする際に、InitialConnectIdentifierの値は、11gデータベース用の新しいDGConnectIdentifierの値として保持されます。Oracle Real Application Clusters（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に変更する前に削除する必要があります。
テスト・データベースをOracle Database 11gリリース1（11.1）にアップグレードしてテストした場合、Oracle Database 11gリリース1（11.1）にアップグレードした本番データベースでも同じテストを繰り返すことができます。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。
新しいOracle Databaseで既存のアプリケーションが正常に動作するかどうかを確認するために、この新しくアップグレードされた本番データベースをテストします。 また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。 ただし、アプリケーションがアップグレードの前と同様に動作するかどうかを最初に確認してください。
Oracle Database 10gリリース1（10.1）またはOracle Database 10gリリース2（10.2）をアップグレードした後に次の作業を行うことをお薦めしますが、必須の作業ではありません。
Oracle Database 10gリリース2（10.2）以上では、非同期チェンジ・データ・キャプチャ（CDC）に、ソースおよびターゲット・データベースのオペレーティング・システムが同じである必要はなくなりました。 この機能を使用すると、異なるオペレーティング・システムおよびOracleバージョンを使用した異機種間CDC設定が可能になります。これによって、既存のOracle9iリリース2（9.2）システムをソースとして扱えるようになります。
Oracle9iリリース2（9.2）またはOracle Database 10gリリース1（10.1）をチェンジ・データ・キャプチャを使用してOracle Database 11gリリース1（11.1）にアップグレードする方法の詳細は、『Oracle Databaseデータ・ウェアハウス・ガイド』を参照してください。チェンジ・データ・キャプチャの分散HotLogモードでサポートされる構成および制限について説明しています。
Oracle XML DBへのHTTPSアクセスを構成するには、この項の説明に従って正しい構成情報を指定します。
データベースをOracle Database 10gリリース2（10.2）以上にアップグレードすると、XDB構成ファイル用のXMLスキーマは自動的にアップグレードされ、リポジトリ内の/xdbconfig.xmlにあるXDB構成ファイルにhttp2-portとhttp2-protocolの2つの要素を追加できるようになります。これらの要素は、アップグレード時にデフォルトではXDB構成ファイルに追加されません。HTTPSに対するサポートが必要な場合は、構成ファイルを編集して、これらの2つの新しい要素（正確な位置についてはXMLスキーマを参照）を追加し、http2-protocolの値をtcpsに設定する必要があります。http2-portの値には、http-portとは異なる値を指定する必要があります。
XDB構成ファイルのパラメータhttp2-portおよびhttp2-protocolを指定するのみでなく、XML DBでHTTPSを使用できるように、データベースおよびリスナーを構成する必要があります。また、次の手順をアップグレード前に実行しなかった場合は、アップグレード後に実行する必要があります。
これを行う方法の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
HTTPを介してXML DBリポジトリ・データに匿名アクセスする必要がない場合は、この手順を実行する必要はありません。HTTPを介してXML DBリポジトリ・データに匿名アクセスする必要がある場合は、この項の説明に従って正しい構成情報を指定する必要があります。管理者は、考えられるセキュリティ上の危険性を考慮し、匿名アクセスを許可するかどうかを十分に検討する必要があります。
データベースをOracle Database 10gリリース2（10.2）以上にアップグレードすると、リポジトリ内の/xdbconfig.xmlにあるXDB構成ファイル用のXMLスキーマは自動的にアップグレードされ、XDB構成ファイルにallow-repository-anonymous-accessという要素を追加できるようになります。この要素はブール型で、trueまたはfalseという値を指定できます。これを使用すると、ANONYMOUSユーザー・アカウントをロック解除した場合でも、認証されていないアクセスをHTTPを介してOracle XML DBリポジトリ・データに行うことを禁止できます。この要素は、アップグレード時にデフォルトではXML DB構成ファイルに追加されませんが、この要素が欠落している場合はfalseと解釈されます。
したがって、Oracle 10gリリース2にアップグレードすると、HTTPを介したXML DBリポジトリ・データへの匿名アクセスは無効になります。HTTPを介してXML DBリポジトリ・データに匿名アクセスする場合は、ANONYMOUSユーザー・アカウントをロック解除すること以外に、構成ファイルを変更してこの新しい要素をtrueに設定する必要があります。
Oracle Express Editionのデータベースに含まれているのは、Standard EditionまたはEnterprise Editionのデータベースで使用できるコンポーネントのサブセットのみです。Oracle Database 11gリリース1（11.1）にアップグレードした後、Database Configuration Assistantを使用して追加のコンポーネントをデータベースにインストールできます。DBUAによるアップグレード中にEnterprise Manager DB Controlをインストールしなかった場合は、データベースに追加する他の任意のコンポーネントと併せてインストールできます。
DBUAを使用せず手動でアップグレードを実行している場合は、データベースをアップグレードした後で、次の作業を実行する必要があります。
アップグレード元のリリースによっては、新しいアカウントが提供されている場合があります。SYSおよびSYSTEM以外のオラクル社が提供するアカウントは、すべてロックしてパスワードを期限切れにし、アカウントのロックを解除したときに新しいパスワードの指定が要求されるようにすることをお薦めします。
次のSQL文を発行して、すべてのアカウントの状態を確認できます。
SQL> SELECT username, account_status FROM dba_users ORDER BY username;
次のSQL文を発行して、パスワードをロックまたは期限切れにします。
SQL> ALTER USER username PASSWORD EXPIRE ACCOUNT LOCK;
従来の初期化パラメータ・ファイルを使用している場合は、次の手順でサーバー・パラメータ・ファイルへ移行します。
CREATE SPFILE文を使用して、サーバー・パラメータ・ファイルを作成します。この文は、初期化パラメータ・ファイルを読み込み、サーバー・パラメータ・ファイルを作成します。CREATE SPFILE文を発行するために、データベースを起動する必要はありません。
Oracle Database 11gリリース1（11.1）へアップグレードした後、次のファイルを以前のOracleホームから新しいOracleホームにコピーします。
これらのファイルは、指定されたOracleホームにインストールされているすべてのデータベースに影響します。
前述のファイルのリストは、次の方法で取得できます。
$ORACLE_HOME/ctx/admin/ctxf102.txtを検索する
SYS、SYSTEM、またはCTXSYSで、$ORACLE_HOME/ctx/admin/ctxf102.sqlを実行する
KOREAN_LEXERはOracle 9iで非推奨になり、Oracle 10gリリース2でサポート対象外になりましたが、Oracle Textの索引でKOREAN_LEXERを使用している場合は、Support Note 300172.1で、KOREAN_LEXERからKOREAN_MORPH_LEXERへの手動による移行の詳細を参照してください。
Oracle Clusterwareを使用している場合は、データベースのOracle Cluster Registry（OCR）キーをアップグレードする必要があります。
OCR構成は、次のいずれかの方法で11gにアップグレードします。
srvconfigを使用します。次に例を示します。
% srvconfig -upgrade -dbname db_name -orahome pre-11g_Oracle_home
srvctlを実行します。次に例を示します。
pre-11g_Oracle_home/bin/srvctl remove database -d db_name 11g_Oracle_home/bin/srvctl add database -d db_name -o 11g_Oracle_home 11g_Oracle_home/bin/srvctl add instance -d db_name -i instance -n node
Oracle Databaseの新しいリリースごとに新しい初期化パラメータが導入され、非推奨となったり、廃止される初期化パラメータもあります。ご使用のシステムに有効な新しい初期化パラメータを使用するために、これらの変更に対してパラメータ・ファイルを調整する必要があります。
|
参照:
|
COMPATIBLE初期化パラメータは、ご使用のデータベースの互換レベルを制御します。データベースを元のバージョンにダウングレードする必要がない場合は、新しいデータベースで必要な互換性レベルに基づいてCOMPATIBLE初期化パラメータを設定します。
COMPATIBLE初期化パラメータ値を増やすには、次の手順を実行します。
COMPATIBLE初期化パラメータ値を増やす前に、データベースのバックアップを取ります（オプション）。COMPATIBLE初期化パラメータ値を増やすことによって、現在のデータベースが以前のリリースのOracle Databaseとは非互換になる可能性があります。バックアップを取っておくと、必要に応じて以前のリリースに戻すことができます。
COMPATIBLE初期化パラメータの値を設定または変更します。たとえば、COMPATIBLE初期化パラメータを11.0.0に設定するには、次の文を入力します。
SQL> ALTER SYSTEM SET COMPATIBLE = '11.0.0' SCOPE=SPFILE;
まだ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ホームの準備」に、クラスタ・データベースをアップグレードする前にCLUSTER_DATABASE初期化パラメータをfalseに設定するよう指示がありました。アップグレードが完了した時点で、この初期化パラメータをtrueに設定する必要があります。
ASMのアップグレード後、次の作業を実行する必要があります。
ご使用のオペレーティング・システムがLinuxまたはUNIXの場合は、次の環境変数が新しいOracle Database 11gリリース1（11.1）のディレクトリを指していることを確認します。
また、oratabファイルおよびORACLE_HOME値を設定するすべてのクライアント・スクリプトが、Oracle Database 11gリリース1（11.1）のホームを指していることを確認します。
Oracleホーム1（OH1）にASMバージョン10.2がインストールされており、オペレーティング・システム・ユーザーがorauserの場合は、次の手順を実行します。
orauserでASMをリリース11.1にアップグレードします。新しいASMリリース11.1は、新しいOracleホーム2（OH2）で実行されている必要があります。ASMは、引き続きorauserで実行されている必要があります。
orauserでASMインスタンスおよびリスナーを停止します。
rootで/etc/init.d/init.cssd stopを実行してCSSを停止します。
asmuser）で、3つめのOracleホーム（OH3）に11.1をインストールします。ここでインストールするのはソフトウェアのみです。
rootで、OH3からlocalconfig resetを実行します。
/etc/oratabを更新し、OH3が+ASMエントリを含むOracleホームになるようにします。
listener.ora、sqlnet.oraおよびtnsnames.oraを、OH2からコピーします。
connect-stringロールを変更します。
asmuserおよびASMのOSDBAであることを確認します。これらのユーザーは、O660の権限セットを保持していることも必要です。
asmuserでリスナーを起動します。
asmuserでASMを起動します（SYSASMとして接続）。
GRANT sysasm TO sysを実行します。
クラスタASMをアップグレードする場合は、次の手順を実行します。
orauserでASMをリリース11.1にアップグレードします。新しいASMリリース11.1は、新しいOracleホーム2（OH2）で実行されている必要があります。ASMは、引き続きorauserで実行されている必要があります。
asmuser）で、3つめのOracleホーム（OH3）に11.1をインストールします。ここでインストールするのはソフトウェアのみです。
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
/etc/oratabを更新し、OH3が+ASMエントリを含むOracleホームになるようにします。
listener.ora、sqlnet.oraおよびtnsnames.oraを、OH2からコピーします。
connect-stringロールを変更します。
asmuserおよびASMのOSDBAであることを確認します。これらのユーザーは、O660の権限セットを保持していることも必要です。
GRANT sysasm TO sysを実行します。
ASMインスタンスがクラスタ化されている場合は、ASMのローリング・アップグレードを実行することもできます。 ローリング・アップグレードを使用すると、データベースの可用性に影響を与えることなく、ASMノードに対して個別にアップグレードやパッチの適用を行うことができるため、より長時間の稼働が可能になります。
ASMをアップグレードした後に次の作業を実行することをお薦めしますが、必須の作業ではありません。
次の作業を実行することも検討してください。これらの作業については、この章の前の方で説明しています。
Oracle Database 11gリリース1（11.1）以上では、パスワードに大/小文字の区別を強制できるようになりました。たとえば、hpp5620QRまたはhPp5620Qrと入力した場合、パスワードhPP5620qrは失敗します。これまでのリリースでは、パスワードの大/小文字は区別されませんでした。
パスワードの大/小文字区別の強制を活用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。新しいASMインスタンスの場合は、追加の作業や追加の管理要件はありません。アップグレードしたASMのインスタンスの場合は、各ユーザーのパスワードをALTER USER文でリセットする必要があります。
Oracle Database 11gリリース1（11.1）以上では、ソフトウェア・バージョンをまたいでOracle DatabaseとASMのディスク・グループの互換性設定を拡張できます。
互換性を拡張することにより、新しいバージョンのみで使用可能な新機能が有効になります。ただし、こうすることで、ソフトウェアの古いバージョンではディスク・グループが非互換になります。ディスク上の互換性を拡張する操作は元に戻せないことに注意してください。
compatible.rdbmsおよびcompatible.asm属性を使用して、データベース・インスタンスおよびASMインスタンスからディスク・グループにアクセスするのに必要な最小ソフトウェア・バージョンをそれぞれ指定します。たとえば、次のALTER DISKGROUP文によって、ディスク・グループasmdg2のASMの互換性が拡張されます。
ALTER DISKGROUP asmdg2 SET ATTRIBUTE 'compatible.asm' = '11.1'
この場合、ディスク・グループを管理できるのはバージョン11.1以上のASMソフトウェアのみですが、データベース・クライアントはバージョン10.1以上であれば、このディスク・グループを使用できます。
ASMの管理者は、一部のディスクを他のディスクより優先して読取りI/O操作に使用するよう指定できます。ASMの優先読取りの障害グループを定義した場合、ASMでは常にプライマリ・コピーから読み取るのではなく、最も近いエクステントから読み取ることができます。
優先読取り機能を使用するには、ASMクライアントとASMの両方にOracle Database 11gリリース1（11.1）以上が必要です。compatible.asmおよびcompatible.rdbms属性はディスク・グループ属性で、この新しい機能を使用するには、これらの属性をリリース11.1まで拡張する必要があります。
ASMおよび1つ以上のデータベースに属するOracleホームのオペレーティング・システム所有権を分けた場合は、次の項に示す手順を実行して、アップグレードしたASMまたはデータベースのOracleホームのオペレーティング・システム・ユーザーを移行する必要があります。
別のオペレーティング・システム・ユーザーを使用する環境に移行する場合は、ASMをアップグレードした後にデータベースをアップグレードする必要があります。データベース・ユーザーは、ASMのOSDBAのメンバーであることが必要です。
検討する例は次の3つです。
オペレーティング・システム・ユーザーをorauserとして維持する場合は、DBUAを実行して、ASMのOracleホーム（OH3）とは別の新しいOracleホーム（OH4）でデータベースを10.2から11.1にアップグレードします。
10.2のデータベースがOracleホーム4（OH4）にインストールされていて、現在orauserをオペレーティング・システム・ユーザーとして実行しているとします。
orauserでDBUAを実行し、新しいOracleホーム（OH5）でデータベースを10.2から11.1にアップグレードします。
orauserでデータベース・インスタンスを停止します。
newuserで、別のOracleホーム（OH6）に11.1をインストールします。
/etc/oratabを更新し、OH6がデータベース・エントリを含むOracleホームになるようにします。
sqlnet.oraをコピーします。listener.oraを更新し、OH5となっている部分をすべてOH6にします。
SPFILEを変更し、OH5のかわりにOH6が使用されるようにします。
OH5からOH6にコピーします。
connect-stringロールを変更します。
この手順は、ASMを使用するデータベースが2つある場合に有効です。必要に応じて、別のデータベースは別のオペレーティング・システム・ユーザーで実行できるように、データベースのオペレーティング・システム・ユーザーを変更できます。
10.2のデータベースがOracleホーム4（OH4）にインストールされていて、現在orauserをオペレーティング・システム・ユーザーとして実行しているとします。
orauserでDBUAを実行し、新しいOracleホーム（OH5）でデータベースを10.2から11.1にアップグレードします。
orauserでデータベース・インスタンスを停止します。
srvctl remove <db-name>を実行します。
newuserで、別のOracleホーム（OH6）に11.1をインストールします。
/etc/oratabを更新し、OH6がデータベース・エントリを含むOracleホームになるようにします。
sqlnet.oraをコピーします。listener.oraを更新し、OH5となっている部分をすべてOH6にします。
SPFILEを変更し、OH5のかわりにOH6が使用されるようにします。
OH5からOH6にコピーします。
connect-stringロールを変更します。
srvctl add <db-name>を実行します。
DBUAを使用せず手動でアップグレードを実行している場合は、ASMをアップグレードした後、次の作業を実行する必要があります。
Oracle Clusterwareを使用している場合は、次のコマンドを実行して、ASMのOracle Cluster Registry（OCR）キーをアップグレードする必要があります。
srvctl modify asm -n node [-p spfile] -o asm_home -i instance
-pオプションが必要なのは、SPFILEを使用中で、このファイルを移動した場合のみです。
Oracle Databaseの新しいリリースごとに新しい初期化パラメータが導入され、非推奨となったり、廃止される初期化パラメータもあります。ご使用のシステムに有効な新しい初期化パラメータを使用するために、これらの変更に対してパラメータ・ファイルを調整する必要があります。
|
参照:
|
ASMでEnterprise Manager Database Controlを使用する場合は、Enterprise Manager Database Controlをインストールして構成する必要があります。
|
 Copyright © 2008 Oracle Corporation. All Rights Reserved. |
|