This paper describes procedures to dramatically reduce downtime during the process of migrating Oracle databases residing on raw partitions, volumes or conventional file systems to Automatic Storage Management (ASM) by using Oracle Recovery Manager (RMAN) and Oracle Data Guard. This paper is equally relevant to existing Data Guard users who want to migrate to ASM, and users who do not currently use Data Guard, but who seek to minimize downtime during migration to ASM.
There are several alternative approaches to performing ASM migration. Oracle recommends using one of the following methods:
• ASM migration using Oracle Data Guard physical standby: Use this method if your requirement is to minimize downtime during the migration. It is possible to reduce total downtime to just seconds by using the best practices described in this white paper.
• ASM migration using Oracle RMAN: A simpler approach, but one that can result in downtime measured in minutes to hours, depending on the method used for migration. This RMAN procedures for migrating your database to ASM are documented in the Oracle Database Backup and Recovery Advance User’s Guide 10g Release 2, Chapter 16
ORACLE AUTOMATIC STORAGE MANAGEMENT :
Oracle Database 10g Automatic Storage Management (ASM) is an integrated volume manager and file system for Oracle database files. ASM simplifies database storage administration by automating the layout of Oracle database files, such as datafiles, control files, redo log files, and backup files. ASM brings significant key values to Oracle Database platforms at no additional cost. ASM improves manageability by simplifying storage provisioning, storage array migration, and storage consolidation. ASM provides flexible easy-to-manage interfaces including the SQL*Plus, Oracle Enterprise Manager GUIs and a UNIX-like command line interface.
ASM provides sustained best-in-class performance because of its
MAA Best Practices - Minimal Downtime Migration to ASM Page 3
Maximum Availability Architecture innovative rebalancing feature that distributes data evenly across all storage resources, providing for an even distribution of I/O and optimal performance.
ASM is the preferred file system and volume manager for Oracle database files because ASM:
• Simplifies and automates storage management
• Increases storage utilization, uptime, and agility
• Delivers predictable performance and availability service level agreements
ORACLE DATA GUARD :
Data Guard is a central component of an integrated Oracle Database High Availability (HA) solution set that helps organizations ensure business continuity by minimizing the various kinds of planned and unplanned downtime that can affect the business.
Data Guard provides the management, monitoring, and automation software infrastructure to create, maintain, and monitor one or more standby databases, to protect enterprise data from failures, disasters, errors, and data corruptions. Going beyond traditional Disaster Recovery (DR) solutions, you can configure Data Guard to automatically fail over the production database to a standby system if the primary database fails, thus achieving a level of high availability required for mission critical applications. In addition to providing HA/DR, Data Guard standby databases also support production functions for reporting, queries, backups and testing, while in a standby database role.
The procedures described in this paper provide an example of how Data Guard can also help reduce planned downtime. The following list summarizes the procedures described in this paper:
1. Create a Data Guard standby database.
2. Migrate the standby database to ASM and test until you are satisfied that the migration has been successful.
3. Execute a planned switchover, transforming the standby database into the new primary database. The switchover can be executed in seconds. This is the only downtime required for the migration.
4. If you are using Data Guard as an HA/DR solution, you can then migrate the new standby (old primary database) into ASM, resulting in all databases in your Data Guard configuration having been migrated to ASM.
ASM MIGRATION STEPS USING ORACLE DATA GUARD :
The steps described in this section assume you create a physical standby database for the sole purpose of minimizing downtime during your migration to ASM.
Maximum Availability Architecture Note: If you have an existing Data Guard configuration with a physical standby database that you can use to perform the migration to ASM, use the procedures described in Chapter 16 of the Oracle Database Backup and Recovery Advance User’s Guide 10g Release 2 to perform the migration. Of course, when following this procedure it is always recommended that you convert standby databases first, then perform a switchover to minimize the downtime required to convert your primary database.
For clarity (and because this paper assumes you will use Data Guard for a one-time migration), the instructions use SQL*Plus commands to create the standby database, enable the Data Guard configuration, and perform a Data Guard switchover. However, if you plan to use Data Guard on an ongoing basis, consider using the Data Guard Broker management interface (DGMGRL) or Enterprise Manager, to greatly simplify creation and management of your Data Guard configuration [2].
These steps have been verified on a configuration running Oracle Database 10g Release 2 (10.2).
Migration to ASM can occur on either the same or a different server or cluster. The steps differ slightly depending on if the target is on a different server or cluster. The differences are highlighted, where necessary.
The high-level steps include:
• Prepare the Source database
• Prepare the Data Guard standby database
• Instantiate the Standby database in ASM
• Enable Oracle Data Guard 10g
• Move production to ASM with Data Guard switchover
• Perform post ASM migration steps
The Appendix contains a copy of the database parameter files used to migrate a database called sales for two scenarios where:
• The target database is on the same machine
• The target database is on a different machine
*****************************************************************************
Prepare the Source Database :
To prepare the source database for migration, run the following steps:
1. Using RMAN, create a backup of the database including a copy of the current controlfile that you will use for the standby database.
RMAN> connect target /
RMAN> backup database include current controlfile for standby;
MAA Best Practices - Minimal Downtime Migration to ASM Page 5
Maximum Availability Architecture :
2. Make the backups accessible to the target system. The path to the backup files on the source and standby system must be the same for these procedures to work.
3. Using SQL*Plus, create a copy of the source database parameter file, which you will use as a template for the standby database parameter file.
SQL> create pfile=’/tmp/pfile.ora’ from spfile;
Copy the parameter file you created to the standby system
4. Using the Oracle Network Configuration Assistant (NETCA) utility create an Oracle Net Service name on the source system that connects back to the standby database.
Prepare the Data Guard Standby Database :
The following steps assume that the ASM instance is running and the ASM disk group has already been created
[4]. To prepare the standby database, perform the following steps:
1. Edit the parameter file you copied from the source database to make the following changes.
a. Remove the current reference to the CONTROL_FILES parameter.
b. Edit or Add the DB_CREATE_FILE_DEST parameter to point to the ASM disk group for the data files.
c. Edit or Add the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE parameters to point to the ASM disk group and define the size for the flash recovery area.
d. Optionally, if the online redo log files should be located in a specific ASM disk group other than what was specified by DB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST, Edit or Add the DB_CREATE_ONLINE_LOG_DEST_n parameter to point to the ASM disk group for the redo log files.
e. Add the FAL_SERVER parameter that refers to a net service name that points to the source database.
f. Add the FAL_CLIENT parameter that refers to a net service name that points to the standby database.
The FAL_SERVER and FAL_CLIENT parameters should be prefixed with the Oracle SID of the standby database.
Note: If you create the standby database locally on the same resources, then you also need to set the following parameters.
Maximum Availability Architecture :
g. Edit the DB_UNIQUE_NAME parameter to be unique. This parameter is referenced in the file names created in the ASM Disk Group.
h. Edit or Add the LOG_ARCHIVE_CONFIG parameter to reference the two DB_UNIQUE_NAME that will be in the configuration. The LOG_ARCHIVE_CONFIG parameter will be: ‘dg_config=(
2. Create the Oracle Password file using the orapwd utility. For example: $ orapwd file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID} password=sys password
3. Create a net service name on the standby system that connects back to the source database and a net service name on the standby system that refers to the standby database.
Instantiate the Standby Database in ASM :
RMAN provides a single command that instantiates the standby database using the information from the source database. In RMAN, you connect to the source database using the CONNECT TARGET command, and you connect to the standby database using the CONNECT AUXILIARY command. Before you can instantiate the database, you must create the server parameter file for the standby database.
1. Create the server parameter file using the parameter file you edited above:
SQL> create spfile from pfile=’/tmp/pfile.ora’;
2. Start the standby instance and instantiate the standby database:
SQL> startup force nomount
RMAN> connect target sys/
RMAN> connect auxiliary /
RMAN> duplicate target database for standby;
At the end of the duplicate command, a physical standby database will be created on the standby system.
Note: If the standby database will be an Oracle RAC database or if you want to store the SPFILE in ASM, then you must move the SPFILE into an ASM disk group, as follows:
a. Create a pfile from the spfile:
SQL> create pfile='/tmp/pfile.asm' from spfile;
b. Shutdown the standby database:
Maximum Availability Architecture :
SQL> shutdown
c. Start the standby database using the pfile created in step a:
SQL> startup mount pfile='/tmp/pfile.asm';
d. Create the spfile in the ASM Disk Group using the db_unique_name value that you specified earlier:
SQL> create spfile='+data/salesasm/spfilesalesasm' from pfile='/tmp/pfile.asm';
e. Shut down the standby database to leverage the changes:
SQL> shutdown
f. Create an initialization parameter file that references the spfile created above on all nodes in the cluster:
$ echo "spfile='+data/salesasm/spfilesalesasm'" > ${ORACLE_HOME}/dbs/init${ORACLE_SID}.ora
g. Remove the spfile created in step 1:
$ rm ${ORACLE_HOME}/dbs/spfile${ORACLE_SID}.ora
h. Start all instances of the standby database:
SQL> startup mount
Enable Oracle Data Guard 10g :
To enable Oracle Data Guard 10g, perform the following steps:
1. Configure the LOG_ARCHIVE_DEST_n parameter on the source database to transmit redo data to the standby database:
SQL> alter system set log_archive_dest_n=’service=
Note: If you create the standby database on the same server or cluster as the source database, then you must also set the following parameters on the source database.
a. Edit or Add the LOG_ARCHIVE_CONFIG parameter to reference the two DB_UNIQUE_NAME parameters that will be in the configuration. The LOG_ARCHIVE_CONFIG parameter will be similar to the following: *.log_archive_config='dg_config=(sales,salesasm)'
Oracle Data Guard has the ability toperform synchronous and asynchronous log shipping as well asreal-time apply. To configure these options, see Chapters 5 and 6 in the Oracle Data Guard Concepts and Administration manual [1].
Maximum Availability Architecture :
2. Start Redo Apply on the standby database to apply the redo received from the source database: SQL> alter database recover managed standby database nodelay disconnect;
You can find additional information about configuring and monitoring Oracle Data Guard in the Oracle Data Guard Concepts and Administration manual and on the Maximum Availability Architecture Oracle Technology Network (OTN) Web site [3].
Use Data Guard Switchover to Move Production to ASM
Downtime occurs while you perform a Data Guard switchover to transition the standby database already using ASM to the primary production role. The switchover process requires a brief outage, typically requiring only seconds to complete.
1. If the primary database is an Oracle RAC database, then you must shut down all but one instance.
SQL> shutdown
Alternatively, you can shut down the instances of an Oracle RAC database using the Server Control (srvctl) utility.
2. On the source database, archive the current redo log:
SQL> alter system archive log current;
3. Verify that the source database is ready to perform an Oracle Data Guard switchover operation:
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO STANDBY
The output should show ‘TO STANDBY” or “SESSIONS ACTIVE.” If any other output displays, then it is not possible to perform a switchover at this time. Contact Oracle Support for diagnosing the problem that is preventing a switchover operation.
4. If the standby database is an Oracle RAC database, then all but one instance must be shut down:
SQL> shutdown
Alternatively, you can shut down the instances of an Oracle RAC database using the Server Control (srvctl) utility.
5. Stop all users accessing the source database.
Maximum Availability Architecture :
6. Issue the following command to initiate the Oracle Data Guard switchover operation. Any connections to the source database will be terminated, and the database transitions to a quiesced state: SQL> alter database commit to switchover to standby with session shutdown;
7. By the time step 6 completes, the last of the redo data from the source database will have been sent to the standby database, and the changes will be applied. Query the V$DATABASE view as shown in the following example, and when the query returns “TO PRIMARY” on the standby database, you can safely proceed.. The time it takes for the status to return “TO PRIMARY” depends on a number of factors including, but not limited to, the amount of redo data that still needs to be applied to the standby database. For example:
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
8. On the standby database, complete the Oracle Data Guard switchover operation:
SQL> alter database commit to switchover to primary;
9. Open the standby database:
SQL> alter database open;
10. If the standby database is an Oracle RAC database, then start the remaining instances:
SQL> startup
Alternatively, you can shutdown the instances of an Oracle RAC database using the Server Control (srvctl) utility.
11. Instruct clients to connect to the new primary database using ASM.
Perform Post ASM Migration Steps :
This section assumes that Data Guard is used only one-time to perform the ASM migration. Once the standby database has become the primary database, perform the following steps to remove the original source database:
1. Invoke SQL*Plus and issue the following statements to reset the FAL_SERVER and FAL_CLIENT parameters on the standby system:
SQL> alter system reset fal_server sid=’
SQL> alter system reset fal_client sid=’
Maximum Availability Architecture :
Note: If you create the standby database on the same server or cluster as the source database, then the following parameters also need to be reset on the standby database:
SQL> alter system reset log_archive_config sid='
2. Shutdown the original source database.
3. Delete the original source database using the Database Configuration Assistant (DBCA).
***********************************************************************************
Maximum Availability Architecture APPENDIX: SAMPLE PARAMETER FILES
Database Parameter files for Different Server or Cluster Migration
Source Database Parameter File
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.compatible='10.2.0.3.0'
*.control_files='/ocfs2/oradata/SALES/controlfile/o1_mf_31tdysbf_.ctl','/ocfs2/flash_recovery_area/SALES/controlfile/o1_mf_31tdysz7_.ctl'
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
*.db_block_size=8192
*.db_create_file_dest='/ocfs2/oradata'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='/ocfs2/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.job_queue_processes=10
*.log_archive_dest_4='service=salesasm ARCH valid_for=(online_logfiles,primary_role)'#for ASM instantiation
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=164626432
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=170
*.sga_target=494927872
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
Standby Database Parameter File
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.compatible='10.2.0.3.0'
*.control_files='+DATA/sales/controlfile/current.262.619624429','+RECO/sales/controlfile/current.256.619624431'#Restore Controlfile
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='+RECO'
*.db_recovery_file_dest_size=2147483648
sales.fal_client='salesasm'
sales.fal_server='sales'
*.job_queue_processes=10
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=164626432
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=170
*.sga_target=494927872
*.undo_management='AUTO'
Example standby database parameter file for different server configuration or cluster migration
Example source database parameter file for different server configuration or cluster migration
MAA Best Practices - Minimal Downtime Migration to ASM Page 12
Maximum Availability Architecture
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
Source Database Parameter File Oracle RAC
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.cluster_database_instances=2
*.cluster_database=true
*.compatible='10.2.0.3.0'
*.control_files='/ocfs2/oradata/SALES/controlfile/o1_mf_31t6o4xt_.ctl','/ocfs2/flash_recovery_area/SALES/controlfile/o1_mf_31t6o6bp_.ctl'
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
*.db_block_size=8192
*.db_create_file_dest='/ocfs2/oradata'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='/ocfs2/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
sales1.instance_number=1
sales2.instance_number=2
*.job_queue_processes=10
*.log_archive_dest_3='service=salesasm ARCH valid_for=(online_logfiles,primary_role) db_unique_name=sales'#for ASM instantiation
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=164626432
*.processes=150
*.remote_listener='LISTENERS_SALES'
*.remote_login_passwordfile='exclusive'
*.sessions=170
*.sga_target=494927872
sales2.thread=2
sales1.thread=1
*.undo_management='AUTO'
sales2.undo_tablespace='UNDOTBS2'
sales1.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
Standby Database Parameter File Oracle RAC
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.cluster_database_instances=2
*.cluster_database=true
*.compatible='10.2.0.3.0'
*.control_files='+DATA/sales/controlfile/current.256.619614529','+RECO/sales/controlfile/current.256.619614531'#Restore Controlfile
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='+RECO'
*.db_recovery_file_dest_size=2147483648
sales1.fal_client='salesasm'
sales2.fal_client='salesasm'
sales1.fal_server='sales'
sales2.fal_server='sales'
Example source RAC database parameter file for different server configuration or cluster migration
Example standby RAC database parameter file for different server configuration or cluster migration
Maximum Availability Architecture sales1.instance_number=1
sales2.instance_number=2
*.job_queue_processes=10
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=164626432
*.processes=150
*.remote_listener='LISTENERS_SALES'
*.remote_login_passwordfile='exclusive'
*.sessions=170
*.sga_target=494927872
sales2.thread=2
sales1.thread=1
*.undo_management='AUTO'
sales2.undo_tablespace='UNDOTBS2'
sales1.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
Database Parameter Files for Same Server or Cluster Migration
Source Database Parameter File
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.compatible='10.2.0.3.0'
*.control_files='/ocfs2/oradata/SALES/controlfile/o1_mf_31sz6kbf_.ctl','/ocfs2/flash_recovery_area/SALES/controlfile/o1_mf_31sz6kyr_.ctl'
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
*.db_block_size=8192
*.db_create_file_dest='/ocfs2/oradata'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='/ocfs2/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.job_queue_processes=10
*.log_archive_config='dg_config=(sales,salesasm)'
*.log_archive_dest_2='service=salesasm ARCH valid_for=(online_logfiles,primary_role) db_unique_name=salesasm'#for ASM instantiation
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=164626432
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=170
*.sga_target=494927872
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
Standby Database Parameter File
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.compatible='10.2.0.3.0'
*.control_files='+DATA/salesasm/controlfile/current.267.619609569','+RECO/salesasm/controlfile/current.260.619609571'#Restore Controlfile
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
Example source database parameter file for same server configuration or cluster migration
Example standby database parameter file for same server configuration or cluster migration
MAA Best Practices - Minimal Downtime Migration to ASM Page 14
Maximum Availability Architecture *.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='+RECO'
*.db_recovery_file_dest_size=2147483648
*.db_unique_name='salesasm'
salesasm.fal_client='salesasm'
salesasm.fal_server='sales'
*.job_queue_processes=10
salesasm.log_archive_config='dg_config=(sales,salesasm)'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=164626432
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sessions=170
*.sga_target=494927872
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
Source Database Parameter File Oracle RAC
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.cluster_database_instances=2
*.cluster_database=true
*.compatible='10.2.0.3.0'
*.control_files='/ocfs2/oradata/SALES/controlfile/o1_mf_31r3txv4_.ctl','/ocfs2/flash_recovery_area/SALES/controlfile/o1_mf_31r3tzbr_.ctl'
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
*.db_block_size=8192
*.db_create_file_dest='/ocfs2/oradata'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='/ocfs2/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
sales2.instance_number=2
sales1.instance_number=1
*.job_queue_processes=10
*.log_archive_config='dg_config=(sales,salesasm)'
*.log_archive_dest_2='service=salesasm ARCH valid_for=(online_logfiles,primary_role) db_unique_name=salesasm'#or ASM instantiation
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=148897792
*.processes=150
*.remote_listener='LISTENERS_SALES'
*.remote_login_passwordfile='exclusive'
*.sessions=170
*.sga_target=446693376
sales2.thread=2
sales1.thread=1
*.undo_management='AUTO'
sales2.undo_tablespace='UNDOTBS2'
sales1.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
Example source Oracle RAC database parameter file for same server configuration or cluster migration
MAA Best Practices - Minimal Downtime Migration to ASM Page 15
Maximum Availability Architecture
Standby Database Parameter File Oracle RAC
*.audit_file_dest='/u01/app/oracle/admin/sales/adump'
*.background_dump_dest='/u01/app/oracle/admin/sales/bdump'
*.cluster_database_instances=2
*.cluster_database=true
*.compatible='10.2.0.3.0'
*.control_files='+DATA/salesasm/controlfile/current.256.619600145','+RECO/salesasm/controlfile/current.256.619600147'#Restore Controlfile
*.core_dump_dest='/u01/app/oracle/admin/sales/cdump'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='sales'
*.db_recovery_file_dest='+RECO'
*.db_recovery_file_dest_size=2147483648
*.db_unique_name='salesasm'
salesasm1.fal_client='salesasm'
salesasm2.fal_client='salesasm'
salesasm1.fal_server='sales'
salesasm2.fal_server='sales'
salesasm2.instance_number=2
salesasm1.instance_number=1
*.job_queue_processes=10
salesasm1.log_archive_config='dg_config=(sales,salesasm)'
salesasm2.log_archive_config='dg_config=(sales,salesasm)'
*.log_archive_format='%t_%s_%r.dbf'
*.open_cursors=300
*.pga_aggregate_target=148897792
*.processes=150
*.remote_listener='LISTENERS_SALES'
*.remote_login_passwordfile='exclusive'
*.sessions=170
*.sga_target=446693376
salesasm2.thread=2
salesasm1.thread=1
*.undo_management='AUTO'
salesasm2.undo_tablespace='UNDOTBS2'
salesasm1.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/u01/app/oracle/admin/sales/udump'
REFERENCES
1. Oracle Data Guard Concepts and Administration, 10g Release 2, http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14239/title.htm
2. Oracle Data Guard Broker, 10g Release 2, Part Number B14230 http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14230/title.htm
3. Maximum Availability Architecture on OTN http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
4. Oracle Database Administrator's Guide, 10g Release 2 (10.2) http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14231/toc.htm
Example standby RAC database parameter file for different server configuration or cluster migration
No comments:
Post a Comment