1. Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ
  2. シナリオ: 手動で構成されたOracle Data Guardを使用したデータベースのアップグレード
機械翻訳について

6 シナリオ: 手動で構成されたOracle Data Guardを使用したデータベースのアップグレード

このシナリオでは、DCSスタックのOracle Database Applianceに手動で構成されたOracle Data Guardを持つデータベースのアップグレードについて説明します。

ノート:

次の項は、ODACLIコマンドで設定されたOracle Data Guardには適用されません。 ODACLIコマンドを使用して、データベースをアップグレードします。
  • 「すべてのコンポーネントのアップグレード」
    Oracle Database Appliance環境のアップグレードは、DCS、サーバー、ストレージおよびデータベース・コンポーネントのアップグレードで構成されます。
  • 「Oracle Databaseリリース19.12以前のアップグレード」
    このセクションの目的は、プライマリ・スタンバイ設定のアップグレード・プロセスの概要を提供することです。
  • 「Oracle Databaseリリース19.12以前のパッチ適用」
    Oracle Database Applianceのデータベースへのパッチ適用は、オンライン操作です。     次のステップでは、スタンバイ構成のデータベースにパッチを適用する方法について説明します。 これらのステッピングは、ベア・メタル上のデータベースおよびDBシステム上のデータベースに適用されます。
  • 「Oracle Database ApplianceでのNFSサーバーの構成」
    NASまたはOracle Object Storageのいずれかがオプションではない場合、Oracle Database ApplianceのいずれかでNFSを構成して、ソース・データベースのバックアップを取得し、ターゲット・システムでスタンバイとしてリストアします。

すべてのコンポーネントのアップグレード

Oracle Database Appliance環境のアップグレードは、DCS、サーバー、ストレージおよびデータベース・コンポーネントのアップグレードで構成されます。

スタンバイ・システムがすでに実装されているOracle Database Appliance環境をアップグレードする場合、スタンバイ・システムを使用して、アップグレード・アクティビティの完了に必要な停止時間を短縮できます。 このセクションの目的は、プライマリ・スタンバイ設定のアップグレード・プロセスの概要を提供することです。

  1. 事前チェックの実行、ハードウェアおよびシステム・プロセスの検証、およびORAChkを使用したシステム構成の検証によって、システムが正しく動作していることを確認します。
  2. プライマリ環境のオペレーティング・システム、Oracle Grid Infrastructure、Oracleホームおよびデータベースのバックアップを取得します。 「My Oracle Supportノート2466177.1 - ODA (Oracle Database Appliance): ODABRシステム・バックアップ/リストア・ユーティリティ」を参照してください。
  3. スタンバイOracle Database ApplianceシステムのDCSおよびサーバー・コンポーネントをアップグレードします。
  4. プライマリ・データベース・ロールおよびアプリケーション接続をスタンバイ・システムにスイッチオーバーします。
  5. 現在のスタンバイ、つまり以前のプライマリ・システム上のDCSおよびサーバー・コンポーネントをアップグレードします。
  6. 19.12より前のOracle Database Applianceリリースを使用するデプロイメントの場合、データベースにパッチを適用またはアップグレードします。 Oracle Database Applianceリリース19.12以降のベア・メタル・デプロイメントでは、ODACLIコマンドを使用してデータベースにパッチを適用するステップは、「Oracle Database Applianceデプロイメントおよびユーザー・ガイド」を参照してください。 ODACLIは、Oracle Data GuardデプロイメントがODACLIコマンドを使用して構成されている場合、データベースへのパッチ適用およびアップグレードを含むOracle Data Guard環境の完全なライフサイクル管理を提供します。

このアップグレード・プロセスでは、アップグレード中の停止時間が最小化され、システム可用性が影響を受けるのは、データベース・コンポーネントのアップグレードまたはパッチ適用の間のみです。

親トピック: シナリオ : 手動で構成されたOracle Data Guardを使用したデータベースのアップグレード

Oracle Databaseリリース19.12以前のアップグレード

このセクションの目的は、プライマリ・スタンバイ設定のアップグレード・プロセスの概要を提供することです。

DCS、サーバー、オペレーティング・システム、Oracle Grid Infrastructureおよび一般的なファームウェア、スイッチオーバーとスイッチバックを備えたストレージをアップグレードすると、アップグレード時のダウンタイムの短縮に役立ちます。 データベース・コンポーネントをアップグレードするのみの場合、アクティブ/アクティブのOracle GoldenGateソリューションなどのゼロ・ダウンタイム・ソリューションを使用していないかぎり、アプリケーションの停止時間が予想されます。 スタンバイ構成が存在する場合のデータベース・アップグレードのプロセスは次のとおりです:
  1. 事前チェックの実行、ハードウェアおよびシステム・プロセスの検証、およびORAChkを使用したシステム構成の検証によって、システムが正しく動作していることを確認します。
  2. データベースおよびOracleホームのバックアップを作成します。
  3. スタンバイ・データベースを停止します。
    [oracle@stbydb1]$ srvctl stop database -d boston
  4. 新しいデータベース・ホームを作成するか、データベースをプライマリでアップグレードするバージョンのスタンバイ上の既存のデータベース・ホームを使用します。
    [oracle@stbydb1]# odacli create-dbhome -v 19.14.0.0.220118
  5. プライマリでのログ送信を停止します。
    [oracle@ proddb1] dgmgrl connect sys/welcome1@chicago 
DGMGRL> SHOW DATABASE 'boston' 'LogShipping'; LogShipping = 'ON' 
DGMGRL> edit database 'boston' SET PROPERTY 'LogShipping'='OFF'; Property "LogShipping" updated 
DGMGRL> SHOW DATABASE 'boston' 'LogShipping'; LogShipping = 'OFF'
  6. 新しいデータベース・ホームを作成するか、データベースをアップグレードするバージョンのプライマリ上の既存のデータベース・ホームを使用します。
    # odacli create-dbhome -v 19.14.0.0.220118
  7. アプリケーションを停止します。
  8. odacli upgrade databaseコマンドを使用してプライマリ・データベースをアップグレードします。
    [root@proddb1]# odacli list-databases
ID DB Name DB Type DB Version CDB Class Shape Storage Status DbHomeID 
---------------------------------------- ---------- -------- ----------------------------------- 
e97cc2f3-bdd8-4775-b959-d5f79a6c59fc chicago Rac 18.11.0.0.200714 false Oltp Odb1 Asm Configured 
88ce2c7-fa3d-4f93-802a-bfa50d180758
[root@proddb1]# odacli list-dbhomes
ID Name DB Version Home Location Status 
---------------------------------------- -------------------- ---------------------------------------- --------------------------------------------- ---------- 
863c8cbe-1c5f-450e-866c-15c384580ad3 OraDB19000_home1 19.14.0.0.220118 /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 Configured 
288ce2c7-fa3d-4f93-802a-bfa50d180758 OraDB18000_home1 18.11.0.0.200714 /u01/app/oracle/product/18.0.0.0/dbhome_1 Configured 
[root@proddb1]# odacli upgrade-database -i 713b68d3-8c43-4d10-973e-90a3fa88a84a -destDbHomeId 863c8cbe-1c5f-450e-866c-15c384580ad3 -sourceDbHomeId 288ce2c7-fa3d-4f93-802a-bfa50d180758
[root@proddb1]# odacli list-databases
ID DB Name DB Type DB Version CDB Class Shape Storage Status DbHomeID 
---------------------------------------- ---------- -------- -------------------- ---------- -------- -------- ---------- ------------ ---------------------------------- 
713b68d3-8c43-4d10-973e-90a3fa88a84a chicago Rac 19.14.0.0.220118 false Oltp Odb1 Asm Configured 
863c8cbe-1c5f-450e-866c-15c384580ad3
  9. アプリケーションを起動します。
  10. スタンバイのtnsnames.oraファイルを古いOracleホームからすべてのノードの新しいOracleホームにコピーします。
  11. パスワード・ファイルをプライマリからスタンバイにコピーします。
    [oracle@proddb1]$ srvctl config database -d chicago |grep Password Password file: +DATA/CHICAGO/PASSWORD/pwdchicago.277.1023633847 [grid@proddb1 ~]$ asmcmd ASMCMD> pwcopy +DATA/CHICAGO/PASSWORD/pwdchicago.277.1023633847 /tmp/pwdboston copying +DATA/CHICAGO/PASSWORD/pwdchicago.277.1023633847 -> /tmp/pwdboston 
[oracle@proddb1]$ scp /tmp/pwdboston oracle@stbydb1: /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/orapwboston 
[grid@stbydb1 ~]$ asmcmd ASMCMD> pwcopy /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/orapwboston +DATA/BOSTON/PASSWORDFILE/pwdboston copying /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1/dbs/orapwboston -> +DATA/BOSTON/PASSWORDFILE/pwdboston
  12. スタンバイのOracle ClusterwareからOracle Database 18cデータベースを削除します。
    [oracle@ stbydb1]# srvctl remove database -db boston 
Remove the database boston? (y/[n]) y
  13. データベースをスタンバイのClusterwareに戻します。 Oracleホームは、新しいバージョンのホームを指している必要があります。 
    Example with single-instance Oracle Database:
[oracle@stbydb1]$ srvctl add database -db boston -oraclehome /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 -dbtype SINGLE -instance boston1 -node stbydb1 -dbname chicago -diskgroup 'DATA,REDO,RECO' -role physical_standby -spfile '+DATA/BOSTON/PARAMETERFILE/spfileboston' -pwfile '+DATA/BOSTON/PASSWORDFILE/pwdboston' -startoption mount

Example with Oracle RAC Database:
[oracle@stbydb1]$ srvctl add database -db boston -oraclehome /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 -dbtype RAC -dbname chicago -diskgroup 'DATA,RECO,REDO' -role physical_standby -spfile '+DATA/BOSTON/PARAMETERFILE/spfileboston' -pwfile '+DATA/BOSTON/PASSWORDFILE/pwdboston' -startoption mount 
[oracle@stbydb1]$ srvctl add instance -database boston -instance boston1 -node stbydb1 
[oracle@stbydb1]$ srvctl add instance -database boston -instance boston2 -node stbydb2
[oracle@stbydb1]$ srvctl start instance -db boston -instance boston1 -o mount 
[oracle@stbydb1]$ srvctl start instance -db boston -instance boston2 -o mount
  14. ログの送付を有効にし、Oracle Data Guard構成を検証します。
    [oracle@stbydb1]$ dgmgrl 
DGMGRL> connect sys/welcome1@chicago 
DGMGRL> edit database 'boston' SET PROPERTY 'LogShipping'='ON'; Property "LogShipping" updated 
DGMGRL> SHOW DATABASE 'boston' 'LogShipping'; LogShipping = 'ON' DGMGRL> show configuration verbose 
DGMGRL> show database verbose chicago 
DGMGRL> show database verbose boston 
DGMGRL> validate database chicago DGMGRL> validate database boston
  15. スイッチオーバーおよびフェイルオーバー操作を確認します。

    スイッチオーバー・テストは次のとおりです:

    $ dgmgrl DGMGRL> connect sys/welcome1@boston 
DGMGRL> switchover to boston 
DGMGRL> connect sys/welcome1@chicago 
DGMGRL> switchover to chicago;

    フェイルオーバー・テストは次のとおりです:

    //Connect to standby before failover: 
$ dgmgrl 
DGMGRL> connect sys/welcome1@boston DGMGRL> failover to boston 
DGMGRL> reinstate database chicago

//Connect to former primary before failover: 
DGMGRL> connect sys/welcome1@chicago DGMGRL> failover to chicago; 
DGMGRL> reinstate database boston

//Health check:
DGMGRL> show database verbose chicago 
DGMGRL> show database verbose boston 
DGMGRL> validate database chicago 
DGMGRL> validate database boston
  16. スタンバイ・システムでレジストリを同期します:
    [root@ stbydb1~]# odacli list-databases
ID DB Name DB Type DB Version CDB Class Shape Storage Status DbHomeID 
---------------------------------------- ---------- -------- -------------------- ---------- --- 
e6450a56-5a7d-4dab-9ca9-25b004b66646 chicago Rac 18.11.0.0.200714 false Oltp Odb1 Asm Configured 
755b4b5d-6211-4d94-81e8-cf611868fe39
Sync up registry entries
[root@ stbydb1~]# odacli update-registry -n db -f 
[root@ stbydb1~]# odacli describe-job -i 25ec2987-4c93-4d25-97db-bad2f6f602f6
Job details 
---------------------------------------------------------------- 
ID: 25ec2987-4c93-4d25-97db-bad2f6f602f6 
Description: Discover 
Components : db 
Status: Success 
Created: November 6, 2021 11:00:50 PM CET 
Message: 
Task Name Start Time End Time Status 
---------------------------------------- ----------------------------------- --------------------
Rediscover DBHome November 6, 2019 11:00:54 PM CET November 6, 2019 11:00:56 PM CET Success 
Rediscover DB: boston November 6, 2019 11:00:56 PM CET November 6, 2019 11:01:02 PM CET Success
Confirm the changes in the registry
[root@ stbydb1~]# odacli list-databases
ID DB Name DB Type DB Version CDB Class Shape Storage Status bHomeID 
---------------------------------------- ---------- -------- -------------------- ----
e6450a56-5a7d-4dab-9ca9-25b004b66646 chicago Rac 19.14.0.0.220118 false Oltp Odb1 Asm Configured 
17f68bbf-b812-42e5-96ba-1433c30f75ed

    合計停止時間には、データベース・アップグレードの期間が必要です。 データベースのアップグレードには、スイッチオーバーおよびスイッチバックは必要ありません。 レジストリの更新操作では、すべてのデータベースのバックアップ、dbdomain、CPUプールおよび関連するネットワーク設定が削除されます。 バックアップ、CPUプールおよび関連するネットワーク設定は、odacli modify-databaseコマンドで再度追加できます。

親トピック: シナリオ : 手動で構成されたOracle Data Guardを使用したデータベースのアップグレード

Oracle Databaseリリース19.12以前のパッチ適用

Oracle Database Applianceのデータベースへのパッチ適用は、オンライン操作です。 次のステップでは、スタンバイ構成のデータベースにパッチを適用する方法について説明します。 これらのステッピングは、ベア・メタル上のデータベースおよびDBシステム上のデータベースに適用されます。

データベースでOracle JVMを使用している場合、最初にスタンバイ・システムにパッチを適用することはできません。 OJVMの使用を確認するには、「My Oracle Supportノート2217053.1 - 「Oracle JavaVM Component Database PSU/RU」用のRACローリング・インストール・プロセス」を参照してください。 このような場合は、プライマリ・システムでのログの送付を遅延し、最初にプライマリ・システムにパッチを適用します。

次のステップを実行します。
  1. 事前チェックの実行、ハードウェアおよびシステム・プロセスの検証、およびORAChkを使用したシステム構成の検証によって、システムが正しく動作していることを確認します。
  2. データベースのバックアップを作成します。
  3. プライマリでのログ送信を停止します。
    $ dgmgrl DGMGRL> connect sys/welcome1@chicago 
DGMGRL> edit database 'CHICAGO' SET STATE="LOG-TRANSPORT-OFF"; 
DGMGRL> SHOW DATABASE 'boston' 'LogShipping'; LogShipping = 'ON' 
DGMGRL> edit database 'boston' SET PROPERTY 'LogShipping'='OFF'; Property "LogShipping" updated 
DGMGRL> SHOW DATABASE 'boston' 'LogShipping'; LogShipping = 'OFF'
  4. スタンバイ・データベースを停止し、read onlyモードで再起動します。
    [oracle@stbydb1]$ srvctl stop database -d boston 
[oracle@stbydb1]$ srvctl start database -db boston -o "read only"
  5. まず、スタンバイ・データベースにパッチを適用します。 データベースのOracleホームを特定します。 
    [root@ocboda10 ~]# odacli list-databases
ID DB Name DB Type DB Version CDB Class Shape Storage Status DbHomeID 
---------------------------------------- ---------- -------- -------------------- ---------- ----------------------------------- 
667a0eec-910c-404b-9820-aedcddf668d7 chicago Rac 19.11.0.0.210420 false Oltp Odb1 Asm Configured 
863c8cbe-1c5f-450e-866c-15c384580ad3 
[oracle@stbydb1]# odacli list-dbhomes
ID Name DB Version Home Location Status 
---------------------------------------- -------------------- ---------------------------------------- --------------------------------- 
863c8cbe-1c5f-450e-866c-15c384580ad3 OraDB19000_home1 19.11.0.0.210420 /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 Configured
    Oracleホームで事前チェックを実行します。
    [oracle@stbydb1]# odacli update-dbhome -p -i 6d05e3f1-e948-4482-bcba-c560d9c8e5e5 -v 19.14.0.0 
[oracle@stbydb1]# odacli describe-job -i b4ee24d9-2b82-4c80-b789-ced90013e4b3
Job details 
---------------------------------------------------------------- 
ID: b4ee24d9-2b82-4c80-b789-ced90013e4b3 
Description: DB Home 
Prechecks Status: Success 
Created: November 7, 2021 6:26:51 PM CET
    パッチを適用します。
    [oracle@stbydb1]# odacli update-dbhome -i 6d05e3f1-e948-4482-bcba-c560d9c8e5e5 -v 19.14.0.0 
[oracle@stbydb1]# odacli describe-job -i "e3556125-7ce6-4560-9f22-3fdd9738f955"
Job details 
---------------------------------------------------------------- 
ID: e3556125-7ce6-4560-9f22-3fdd9738f955 
Description: DB Home Patching: Home Id is e4e9fcbd-63d4-4c56-bb0c-b239a4e749f3 
Status: Success 
Created: November 7, 2021 7:09:52 PM CET
    結果を確認します。
    [oracle@stbydb1]# odacli list-dbhomes
ID Name DB Version Home Location Status 
---------------------------------------- -------------------- ----------------------------------------- 
e4e9fcbd-63d4-4c56-bb0c-b239a4e749f3 OraDB19000_home2 19.14.0.0.220118 /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_2 Configured 
863c8cbe-1c5f-450e-866c-15c384580ad3 OraDB19000_home1 19.11.0.0.210420 /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1 Configured
[oracle@stbydb1]# odacli list-databases
ID DB Name DB Type DB Version CDB Class Shape Storage Status DbHomeID
---------------------------------------- ---------- -------- -------------------- ---------- -------- -------- ---------- ------------ 
667a0eec-910c-404b-9820-aedcddf668d7 chicago Rac 19.14.0.0.220118 false Oltp Odb1 Asm Configured 
e4e9fcbd-63d4-4c56-bb0c-b239a4e749f3
  6. スタンバイ・データベースにパッチを適用するステップと同様に、プライマリ・データベースにパッチを適用します。
  7. プライマリでログ送信を開始し、Oracle Data Guard構成を確認します。
    DGMGRL> connect sys/welcome1@chicago 
DGMGRL> edit database 'boston' SET PROPERTY 'LogShipping'='ON'; Property "LogShipping" updated 
DGMGRL> SHOW DATABASE 'boston' 'LogShipping'; LogShipping = 'ON' 
DGMGRL> show configuration verbose 
DGMGRL> show database verbose chicago 
DGMGRL> show database verbose boston 
DGMGRL> validate database chicago 
DGMGRL> validate database boston

親トピック: シナリオ : 手動で構成されたOracle Data Guardを使用したデータベースのアップグレード

Oracle Database ApplianceでのNFSサーバーの構成

NASまたはOracle Object Storageのいずれかがオプションではない場合、Oracle Database ApplianceのいずれかでNFSを構成して、ソース・データベースのバックアップを取得し、ターゲット・システムでスタンバイとしてリストアします。

ベア・メタル・システムまたはDBシステムの両方のOracle Data Guardについて、NFSサーバーをプライマリおよびスタンバイのベア・システムのロケーションで構成する必要があります。

次のステップを実行します。
  1. gridオペレーティング・システム・ユーザーとして、ソース・ベア・メタル・システムnode0にADVMボリュームを作成します。 
    [grid@odabm1 ~]$ asmcmd 
asmcmd> volcreate -G data -s 100G backup
ASMCMD> volinfo -G data backup 
Diskgroup Name: DATA 
Volume Name: BACKUP 
Volume Device: /dev/asm/backup-322 
State: ENABLED 
Size (MB): 102400 
Resize Unit (MB): 64 
Redundancy: HIGH 
Stripe Columns: 8 
Stripe Width (K): 4096 
Usage: Mountpath:
  2. ボリュームをOracle ACFSとしてフォーマットします。 
    [grid@odabm1 ~]$ mkfs -t acfs /dev/asm/backup-322 
mkfs.acfs: version = 19.0.0.0.0 
mkfs.acfs: on-disk version = 46.0 
mkfs.acfs: volume = /dev/asm/backup-322 
mkfs.acfs: volume size = 107374182400 ( 100.00 GB ) 
mkfs.acfs: Format complete.
  3. 両方のノードでマウント・ポイントを作成します。 ベア・メタル・システム上の両方のノードでコマンドを実行します: 
    # mkdir /backup
  4. ファイル・システムをOracle Clusterwareに登録し、rootオペレーティング・システム・ユーザーとして起動します。 
    [root@odabm1 ~]# /u01/app/19.15.0.0/grid/bin/srvctl add filesystem -d /dev/asm/backup-322 -path /backup -mountowner oracle -mountgroup dba 
[root@odabm1 ~]# /u01/app/19.15.0.0/grid/bin/srvctl start filesystem -d /dev/asm/backup-322
  5. ベア・メタル・システムのnode0の/etc/exportsに追加し、アクティブにします。 
    [root@odabm1 ~]# vi /etc/exports 
/backup *(rw,sync,no_root_squash) 

//or add each source and target nodes separately:
/backup primary1(rw,sync,no_root_squash) 
/backup primary2(rw,sync,no_root_squash) 
/backup standby1(rw,sync,no_root_squash) 
/backup standby2(rw,sync,no_root_squash)
 
//where primary1, primary2 nodes refer to the nodes hosting the primary database and standby1, 
//standby2 refer to the nodes hosting the standby
[root@odabm1 ~]# exportfs -a 
[root@odabm1 ~]# exportfs -v 
... 
/backup *(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
  6. 同じマウント・ポイント名を使用して、ソース・ノードとターゲット・ノードにマウント・ポイントを作成します。
    # mkdir /odabackup
  7. ソース・ベア・メタル・システムでパブリックIPアドレスnode0を使用して、両方のノードにファイル・システムをマウントします。
    # mount -t nfs 192.168.17.2:/backup /odabackup
  8. oracleユーザーIDはソースとターゲットの間で異なる可能性があるため、/odabkpの下にサブフォルダを作成し、その所有権をoracle:dbaに変更します。
    # mkdir /odabackup/db 
In case the DB is TDE enabled then one more folder is required: 
# mkdir /odabackup/tde # chown -R oracle:dba /odabackup
  9. ソースとターゲットの両方でNFSを構成した後、Oracle Data Guard構成プロセスに従って、データベースをスタンバイとしてリストアします。
  10. データベースをリストアする前に、ターゲットで所有権をoracle:dbaに変更します。 ユーザーIDとグループIDは、ソースとターゲットで異なる場合があります。 
    # chown -R oracle:dba /odabackup
  11. Oracle Data Guard構成を完了します。
  12. Oracle Data Guardを構成したら、すべてのNFS関連の変更を元に戻します。
    1. ソース・ノードおよびターゲット・ノードで/odabkpをアンマウントします。
      # unmount /odabkp
    2. すべてのベア・メタル・システム・ノードで/backupをアンマウントします。
      # unmount /backup
    3. /etc/exportsから/backupを削除します。
    4. 最初のベア・メタル・システム・ノードでNFS構成を更新します。
      [root@odabm1 ~]# exportfs -a
    5. Oracle Clusterware構成からバックアップOracle ACFSファイル・システムを削除します。
      [root@odabm1 ~]# /u01/app/19.15.0.0/grid/bin/srvctl stop filesystem -d /dev/asm/backup-322 
[root@odabm1 ~]# /u01/app/19.15.0.0/grid/bin/srvctl remove filesystem -d /dev/asm/backup-322
    6. ベア・メタル・システム・ノードのgridオペレーティング・システム・ユーザーとして、バックアップ関連のOracle ADVMボリュームを削除します。
      [grid@odabm1 ~]$ asmcmd 
ASMCDM> voldelete -G data backup
    7. 元のバックアップ構成をプライマリ・データベースに再割当てします。 デフォルトでは、値はdefaultです。 
      [root@proddb1 ~]# odacli modify-database -in databasename -bin default

親トピック: シナリオ : 手動で構成されたOracle Data Guardを使用したデータベースのアップグレード