This section details selected mount options that are related to Oracle and provides guidance to help users decide how to configure the copy mount. Some options are dependent upon the intended use case. Settings such as the host to choose, options when RecoverPoint or VPLEX are part of the environment, and other aspects that are not related to Oracle are not described. See the AppSync User and Administration Guide for more details on the various settings.
Choosing the appropriate mount operation and mount path, however, are critical because Oracle must have a proper location for mounting, especially when recovering.
Mount to path
There are three types of mount-path options which are applicable for file systems only, and not for ASM-managed environments. Depending on the host mounting to, some may not apply.
- Default Path: Indicates a root path /appsync-mounts, for UNIX hosts, which serve as a mount point, and the original mount point is appended to this location. If this root path is not acceptable, replace the words Default Path with the root mount point of preference. This default option can apply when the copy is mounted back to the same production host, alternate node of a cluster, or to an alternate location.
- Mapped Path: Customizes specific file-system targets to change, rather than changing the root mount point. For instance, changing /prd/db1 and /prd/db2 to /test/db1 and /test/db2.
- Same as original path: Is only available if mounting to an alternate mount host, uses the same mount points and paths as the original source system.
The alternate path options mount file systems to different locations from where they were originally located on the production host. You can achieve this result by changing the default path of the mount point, or using the mapped path in the mount phase dialog or mount wizard. This option only applies to file systems and has no effect on ASM diskgroups.
You can use these options to resolve path conflicts when several copies containing the same file system are mounted on the same host. Also, when the production host is the mount host, the alternate path option is critical, to avoid collisions with the original production data. For this reason, the alternate path feature is mandatory if the mount host is the production host.
There are different settings which only apply when recovering the database, or when creating scripts that are used manually to recover the database. These settings include choosing Read-only or Read-write, as seen in Figure 1 and Figure 2, respectively. None of these options apply when mounting as a file system (no recovery), and if they apply when creating an RMAN catalog entry, it is depicted. Settings are depicted as to which type of mount operation they apply: RMAN cataloging, recovery, preparing scripts for manual recovery, or RAC cluster recovery.
Figure 1. Recovery Settings: Read-only
Figure 2. Recovery Settings: Read-write
- Open-mode: Only applies when recovering the database copy. Oracle can be recovered in two types of modes as mentioned below:
- Read-only: Opens the database in read-only mode, thus not allowing any changes to the copy, other than what is required for the recovery to take place.
This mode is used when the user wants to examine data on the mount host, but not alter it in any way.
The copy itself is altered, in that it has been recovered and logs have been applied.
The data that the database contains is not changed.
- Read-write: This mode is almost identical to the read-only mode because AppSync performs the same steps to bring up the instance, and updates the paths to the relevant components.
The major difference relates to how AppSync opens the database at the end of the mount operation. As the name suggests, AppSync opens the database in read-write mode, thus allowing further changes to the database once it is mounted.
In general, copies that have been mounted and recovered should not be restored to the production database, whether the reset logs clause was used or not. Whenever a database is mounted, there is a possibility that the data may have changed in undesired ways during the mount. This mode is mostly used in repurposing situations where restore is not part of the scenario, such as when working in a testing and development environment.
- ORACLE_HOME: Applies when creating an RMAN catalog and all recovery types. Specify the ORACLE_HOME path parameter, which is strictly used when there is no reliable way for AppSync to validate the accuracy of the selected ORACLE_HOME directly that is used by the mount host. This reason is because it differs from the production host in some way. Verify the value for this parameter before changes are made.
AppSync relies heavily on the ORACLE_HOME of the mount host to:
- Find the SQL*Plus utility and run recovery scripts.
- Connect to the Oracle instance being started on the host.
- Check the Oracle version.
- Copy the initialization file in the dbs subdirectory.
- Access any Oracle utilities that are located in the ORACLE_HOME/bin directory.
- Failure to provide an accurate ORACLE_HOME results in a range of errors that may not always be easy to diagnose.
- Database Name: Only applies when recovering the database copy. The database rename feature is a common option, typically used in repurposing use cases which allows the database to be renamed to something else. This functionality allows multiple copies of the same database to co-exist on a single host and under a single ORACLE_HOME. The %DB% token in the mount options dialog indicates you may insert a prefix or suffix or both. It is also possible to use a new name for the entire database.
- SID Name: Only applies when recovering the database copy. The SID rename feature is rarely used by itself because it is associated with database rename. The SID rename changes the name of the Oracle instance (process) that is started on the mount host. You can accomplish a SID rename by renaming the initialization file and some key parameters inside it, such as the instance_name. Adding the prefix and or suffix is possible, however, you must work within the Oracle eight-character limit on the SID because it will be truncated as part of the recovery.
Since an Oracle SID manages an Oracle database, users often choose to change both for consistency. However, the SID rename operation does not alter the copy in any way.
Note: AppSync creates directories that are based on the SID name when performing mounts. You can use the SID rename action to allow several copies that are mounted on a host to avoid directory structure collisions, but with no plan to start the database. In such cases, the use of SID rename is necessary to avoid clashes of directory structures that have the SID name that is embedded. It can also be necessary to avoid overwriting files containing the SID name, such as the initialization file or password file.
One example in which SID rename is useful has mounts to the production host. For example, a database that is called PROD, with a corresponding SID called PROD, can have a copy that is mounted onto the same production host, yet to an alternate path, without starting it. Select the Mount on standalone server and prepare scripts for manual database recovery option and choose to rename the SID. For example, renaming the SID to PROD2 informs AppSync that the database copy must not be started. The alternate SID name, PROD2, is provided so the directory structure does not collide, or clash with PROD. To start PROD2 on the production host, rename the database, to prevent a database clash with PROD at startup time.
- ASM Diskgroup Name: Applies when creating an RMAN catalog and all recovery types. AppSync offers the ability to rename ASM diskgroups using the original name as a token - %DG%.
In the mount settings, you can apply a prefix or postfix to this value to alter the name of the diskgroups as part of the mount. For example, diskgroups that are named DG1, DG2, and DG3, can be renamed to NEWDG1, NEWDG2, and NEWDG3 respectively, by changing this parameter to NEW%DG%. - Customize Initialization Parameters: Applies when creating an RMAN catalog and all recovery types. Use the AppSync Console to enter customized initialization parameters for mounting Oracle data. When the mount operation runs, these parameters are appended to the copy of the initialization parameters that are used with the mounted database.
AppSync internally overrides certain init parameters to apply the database changes that are required to mount or recover the database copy with the options that you specify. The parameters that are specified in customize initialization parameters window should be used to customize any parameters that must have a different value than production. We recommend that you refrain from overriding init parameters that AppSync itself overrides, such as the following parameters:
- log_archive_dest_<n>
- dbname
- db_create_file_dest
- db_create_online_log_dest_<n>
- control_files
- local_listener
- remote_listener
- db_recovery_file_dest
- Restart database after reboot: Applies only when AppSync recovers the database. This check box allows AppSync to add an entry for auto starting Oracle after the mount host is rebooted.
- Create SPFile: Only applies to when AppSync recovers the database in a standalone environment, not applicable with RAC. This option creates the SPFile on the mount host. If selected, optionally copy the SPFile to the ASM diskgroup, if applicable.
- Advanced Recovery Settings: Applicable for standalone recovery only. Other recovery options include creating up to three additional control files, using Automatic Diagnostic Repository (ADR), changing the DBID, or disabling archive log mode.
Figure 3. Advanced Recovery Settings
For all recovery types of options, see AppSync User and Administration Guide.