You can migrate OCR to reside on Oracle ASM, and take advantage of the improvements in managing Oracle Clusterware storage.

1. Ensure the upgrade to Oracle Clusterware 19c is complete. Run the following command to verify the current running version:

   $ crsctl query crs activeversion

2. Use the Oracle ASM Configuration Assistant (ASMCA) to configure and start Oracle ASM on all nodes in the cluster.
3. Use ASMCA to create an Oracle ASM disk group that is at least the same size of the existing OCR and has at least normal redundancy.

   Note:

   • If OCR is stored in an Oracle ASM disk group with external redundancy, then Oracle recommends that you add another OCR location to another disk group to avoid the loss of OCR, if a disk fails in the disk group.

     Oracle does not support storing OCR on different storage types simultaneously, such as storing OCR on both Oracle ASM and a shared file system, except during a migration.

   • If an Oracle ASM instance fails on any node, then OCR becomes unavailable on that particular node.

     If the CRSD process running on the node affected by the Oracle ASM instance failure is the OCR writer, the majority of the OCR locations are stored in Oracle ASM, and you attempt I/O on OCR during the time the Oracle ASM instance is down on this node, then CRSD stops and becomes inoperable. Cluster management is now affected on this particular node.

     Under no circumstances will the failure of one Oracle ASM instance on one node affect the whole cluster.

   • Ensure that Oracle ASM disk groups that you create are mounted on all of the nodes in the cluster.

4. To add OCR to an Oracle ASM disk group, ensure that the Oracle Clusterware stack is running and run the following command as root:

   # ocrconfig -add +new_disk_group

   You can run this command more than once if you add multiple OCR locations. You can have up to five OCR locations. However, each successive run must point to a different disk group.

5. To remove storage configurations no longer in use, run the following command as root:

   # ocrconfig -delete old_storage_location

   Run this command for every configured OCR.

# ocrconfig -add +new_disk_group
# ocrconfig -delete /ocrdata/ocr_1
# ocrconfig -delete /ocrdata/ocr_2

Manage OCR locations using OCRCONFIG.

The Oracle installation process for Oracle Clusterware gives you the option of automatically mirroring OCR. You can manually put the mirrored OCRs on a shared Network File System (NFS), or on any cluster file system that is certified by Oracle. Alternatively, you can place OCR on Oracle ASM and allow it to create mirrors automatically, depending on the redundancy option you select.

You can manually mirror OCR, as described in the Adding an Oracle Cluster Registry Location section, if you:

• Upgraded to Oracle Clusterware 12c but did not choose to mirror OCR during the upgrade

• Created only one OCR location during the Oracle Clusterware installation

Oracle recommends that you configure:

• At least three OCR locations, if OCR is configured on non-mirrored or non-redundant storage. Oracle strongly recommends that you mirror OCR if the underlying storage is not RAID. Mirroring can help prevent OCR from becoming a single point of failure.

• At least two OCR locations if OCR is configured on an Oracle ASM disk group. You should configure OCR in two independent disk groups. Typically this is the work area and the recovery area.

• At least two OCR locations if OCR is configured on mirrored hardware or third-party mirrored volumes.

In addition to mirroring OCR locations, managing OCR locations include:

• Adding an Oracle Cluster Registry Location

• Removing an Oracle Cluster Registry Location

• Replacing an Oracle Cluster Registry Location

• Repairing an Oracle Cluster Registry Configuration on a Local Node

• Overriding the Oracle Cluster Registry Data Loss Protection Mechanism

This section describes how to back up OCR content and use it for recovery. The first method uses automatically generated OCR copies and the second method enables you to issue a backup command manually:

• Automatic backups: Oracle Clusterware automatically creates OCR backups every four hours. At any one time, Oracle Database always retains the last three backup copies of OCR. The CRSD process that creates the backups also creates and retains an OCR backup for each full day and after each week. You cannot customize the backup frequencies or the number of files that Oracle Database retains.

• Manual backups: Run the ocrconfig -manualbackup command on a node where the Oracle Clusterware stack is up and running to force Oracle Clusterware to perform a backup of OCR at any time, rather than wait for the automatic backup. You must run the command as a user with administrative privileges. The -manualbackup option is especially useful when you want to obtain a binary backup on demand, such as before you make changes to OCR. The OLR only supports manual backups.

When the clusterware stack is down on all nodes in the cluster, the backups that are listed by the ocrconfig -showbackup command may differ from node to node.

This section includes the following topics:

• Listing Backup Files

• Changing Backup Location

In addition to using the automatically created OCR backup files, you should also export OCR contents before and after making significant configuration changes, such as adding or deleting nodes from your environment, modifying Oracle Clusterware resources, and upgrading, downgrading or creating a database. Do this by using the ocrconfig -export command, which exports OCR content to a file format.

Using the ocrconfig -export command also enables you to restore OCR using the -import option if your configuration changes cause errors. For example, if you have configuration problems that you cannot resolve, or if you are unable to restart Oracle Clusterware after such changes, then restore your configuration using the procedure for your platform.

Oracle recommends that you use either automatic or manual backups, and the ocrconfig -restore command instead of the ocrconfig -export and ocrconfig -import commands to restore OCR for the following reasons:

• A backup is a consistent snapshot of OCR, whereas an export is not.

• Backups are created when the system is online. You must shut down Oracle Clusterware on all nodes in the cluster to get a consistent snapshot using the ocrconfig -export command.

• You can inspect a backup using the OCRDUMP utility. You cannot inspect the contents of an export.

• You can list backups with the ocrconfig -showbackup command, whereas you must keep track of all generated exports.

This section includes the following topics:

• Importing Oracle Cluster Registry Content on Linux or UNIX Systems

• Importing Oracle Cluster Registry Content on Windows Systems

In Oracle Clusterware 12c, each node in a cluster has a local registry for node-specific resources, called an Oracle Local Registry (OLR), that is installed and configured when Oracle Clusterware installs OCR. Multiple processes on each node have simultaneous read and write access to the OLR particular to the node on which they reside, regardless of whether Oracle Clusterware is running or fully functional.

By default, OLR is located at Grid_base/crsdata/host_name/olr/hostname_release.olr on each node.

Manage OLR using the OCRCHECK, OCRDUMP, and OCRCONFIG utilities as root with the -local option.

• You can check the status of OLR on the local node using the OCRCHECK utility, as follows:

  # ocrcheck -local
  Status of Oracle Local Registry is as follows :         
          Version                  : 4
          Total space (kbytes)     : 491684
          Used space (kbytes)      : 83120
          Available space (kbytes) : 408564
          ID                       : 1260380057
          Device/File Name         : Grid_base/crsdata/dglnx6/olr/dglnx6_19.olr
                                     Device/File integrity check succeeded
          Local registry integrity check succeeded
          Logical corruption check succeeded

• You can display the content of OLR on the local node to the text terminal that initiated the program using the OCRDUMP utility, as follows:

  # ocrdump -local -stdout
  

• You can perform administrative tasks on OLR on the local node using the OCRCONFIG utility.

  • To export OLR to a file:

    # ocrconfig –local –export file_name

    Note:

    • Oracle recommends that you use the -manualbackup and -restore commands and not the -import and -export commands.

    • When exporting OLR, Oracle recommends including "olr", the host name, and the timestamp in the name string. For example:

      olr_myhost1_20090603_0130_export

  • To import a specified file to OLR:

    # ocrconfig –local –import file_name
    

  • To manually back up OLR:

    # ocrconfig –local –manualbackup

    Note:

    Oracle Clusterware backs up OLR after installation or upgrade and, by default, periodically backs up OLR, thereafter. At any time after the initial backup, you can manually back up OLR.

    Oracle also recommends that you create a new backup when you migrate OCR from Oracle ASM to other storage, or when you migrate OCR from other storage to Oracle ASM.

    The default backup location for the OLR is in the path Grid_base/crsdata/host_name/olr/.

  • To view the contents of the OLR backup file:

    ocrdump -local -backupfile olr_backup_file_name
    

  • To change the OLR backup location:

    ocrconfig -local -backuploc new_olr_backup_path
    

  • To restore OLR:

    # crsctl stop crs
    # ocrconfig -local -restore file_name
    # ocrcheck -local
    # crsctl start crs
    $ cluvfy comp olr

You can manually upgrade and downgrade Oracle Cluster Registry configuration.

If you choose to store your voting files in Oracle ASM, then Oracle ASM stores all the voting files for the cluster in the disk group you choose.

Oracle ASM manages voting files differently from other files that it stores. You cannot use voting files stored in Oracle ASM and voting files not stored in Oracle ASM in the same cluster.

Once you configure voting files on Oracle ASM, you can only make changes to the voting files' configuration using the crsctl replace votedisk command. This is true even in cases where there are no working voting files. Despite the fact that crsctl query css votedisk reports zero vote disks in use, Oracle Clusterware remembers the fact that Oracle ASM was in use and the replace verb is required. Only after you use the replace verb to move voting files back to non-Oracle ASM storage are the verbs add css votedisk and delete css votedisk again usable.

The number of voting files you can store in a particular Oracle ASM disk group depends upon the redundancy of the disk group.

By default, Oracle ASM puts each voting file in its own failure group within the disk group. A failure group is a subset of the disks in a disk group. Failure groups define disks that share components, such that if one fails then other disks sharing the component might also fail. An example of what you might define as a failure group would be a set of SCSI disks sharing the same SCSI controller. Failure groups are used to determine which Oracle ASM disks to use for storing redundant data. For example, if two-way mirroring is specified for a file, then redundant copies of file extents must be stored in separate failure groups.

The redundancy level that you choose for the Oracle ASM disk group determines how Oracle ASM mirrors files in the disk group, and determines the number of disks and amount of disk space that you require. If the voting files are in a disk group, then the disk groups that contain Oracle Clusterware files (OCR and voting files) have a higher minimum number of failure groups than other disk groups because the voting files are stored in quorum failure groups.

A quorum failure group is a special type of failure group that is used to store the Oracle Clusterware voting files. The quorum failure group is used to ensure that a quorum of the specified failure groups are available. When Oracle ASM mounts a disk group that contains Oracle Clusterware files, the quorum failure group is used to determine if the disk group can be mounted if there is a loss of one or more failure groups. Disks in the quorum failure group do not contain user data, therefore a quorum failure group is not considered when determining redundancy requirements in respect to storing user data.

An Oracle ASM flex disk group is a disk group type that supports Oracle ASM file groups and quota groups. In general, a flex disk group enables users to manage storage at the granularity of the database, in addition to at the disk group level.

Redundancy levels include:

• External redundancy: An external redundancy disk group requires a minimum of one disk device. The effective disk space in an external redundancy disk group is the sum of the disk space in all of its devices.

  Because Oracle ASM does not mirror data in an external redundancy disk group, Oracle recommends that you use external redundancy with storage devices such as RAID, or other similar devices that provide their own data protection mechanisms.

• Normal redundancy: A normal redundancy disk group requires a minimum of two disk devices (or two failure groups). The effective disk space in a normal redundancy disk group is half the sum of the disk space in all of its devices.

  For Oracle Clusterware files, a normal redundancy disk group requires a minimum of three disk devices (two of the three disks are used by failure groups and all three disks are used by the quorum failure group) and provides three voting files and one OCR and mirror of the OCR. When using a normal redundancy disk group, the cluster can survive the loss of one failure group.

• High redundancy: In a high redundancy disk group, Oracle ASM uses three-way mirroring to increase performance and provide the highest level of reliability. A high redundancy disk group requires a minimum of three disk devices (or three failure groups). The effective disk space in a high redundancy disk group is one-third the sum of the disk space in all of its devices.

  For Oracle Clusterware files, a high redundancy disk group requires a minimum of five disk devices (three of the five disks are used by failure groups and all five disks are used by the quorum failure group) and provides five voting files and one OCR and two mirrors of the OCR. With high redundancy, the cluster can survive the loss of two failure groups.

Using the crsctl replace votedisk command, you can move a given set of voting files from one Oracle ASM disk group into another, or onto a certified file system. If you move voting files from one Oracle ASM disk group to another, then you can change the number of voting files by placing them in a disk group of a different redundancy level as the former disk group.

Oracle Clusterware automatically backs up voting file data in OCR as part of any configuration change and automatically restores the data to any voting file you add.

If all of the voting files are corrupted, then you can use this procedure to restore them.

1. Restore the OCR as described in "Restoring Oracle Cluster Registry", if necessary.

   This step is necessary only if the OCR is also corrupted, or otherwise unavailable, such as if the OCR is on Oracle ASM, and the ASM disk group is no longer available.

2. Run the following command as root from only one node to start the Oracle Clusterware stack in exclusive mode, which does not require voting files to be present or usable:

   # crsctl start crs -excl

3. Run the command crsctl query css votedisk to retrieve the list of voting files currently defined.

   For example:

   $ crsctl query css votedisk
   --  -----    -----------------                --------- ---------
   ##  STATE    File Universal Id                File Name Disk group
    1. ONLINE   6f57843d89464c46ea747362e8a3fa43 (/dev/sdb1) [DATA]
    2. ONLINE   7c54856e98474f61bf349401e7c9fb95 (/dev/sdc1) [DATA]
    3. ONLINE   9c46232b76234f61fc934673d5c8ec59 (/dev/sdd1) [DATA]

   This list may be empty if all voting files were corrupted, or the list may have entries that are marked as status 3, or OFF.

4. Depending on where you store your voting files, do one of the following:

   • If the voting files are stored in Oracle ASM, then run the following command to migrate the voting files to the Oracle ASM disk group you specify:

     crsctl replace votedisk +asm_disk_group

     The Oracle ASM disk group to which you migrate the voting files must exist in Oracle ASM. You can use this command whether the voting files were stored in Oracle ASM or some other storage device.

   • If you did not store voting files in Oracle ASM, then run the following command using the File Universal Identifier (FUID) obtained in the previous step:

     $ crsctl delete css votedisk FUID

     Add a voting file, as follows:

     $ crsctl add css votedisk path_to_voting_disk

5. Stop the Oracle Clusterware stack as root:

   # crsctl stop crs

   Note:

   If the Oracle Clusterware stack is running in exclusive mode, then use the -f option to force the shutdown of the stack.

6. Restart the Oracle Clusterware stack in normal mode as root:

   # crsctl start crs

You can add, remove, and migrate voting files after you install Oracle Clusterware. Note that the commands you use to do this are different, depending on whether your voting files are located in Oracle ASM, or are located in another storage option.