What is snapshot Standby Database? What are benefits?

Converting a physical standby database to a snapshot standby database in Oracle 19c involves several steps. A snapshot standby database allows read/write access to the standby database while remaining able to fall back to the physical standby database. A snapshot standby database provides many advantages over a physical standby database in an Oracle environment. A snapshot standby database is a fully updatable standby database that is created by converting a physical standby database into a snapshot standby database. A snapshot standby database receives and archives, but does not apply redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.

Here are the main benefits: 

1. Read-Write Capability

A snapshot standby database can be opened in read-write mode, allowing users to perform updates and test applications using production-like data without affecting the primary database. This is particularly useful for development and testing scenarios where real-time data is required for validation.

2. Temporary Testing Environment

Organizations can utilize snapshot standby databases to create a temporary testing environment. This allows teams to experiment with changes or new applications on a copy of the production data, ensuring that any potential issues can be identified before deployment in the live environment. After testing, the snapshot can be reverted back to its original state. 

3. Data Protection

While a snapshot standby is open for updates, it continues to receive redo data from the primary database. This ensures that the integrity of the primary database is maintained, as the snapshot standby can be converted back to a physical standby at any time, applying any received redo data and discarding local changes made during the testing phase.

4. Guaranteed Restore Point

Whenever a physical standby database is converted into a snapshot standby database, a guaranteed restore point is automatically created. Once the updateable transactions are completed for testing purposes on the snapshot standby database and when you are converting back the snapshot standby to physical standby, oracle flashbacks to the restore point that was created earlier which means the transactions that were made in the standby database while it was open in READ WRITE mode will be flushed out.

5. Flexibility in Database Management

The ability to switch back and forth between snapshot and physical standby modes provides flexibility in database management. Organizations can conduct necessary testing and development while still maintaining a robust disaster recovery setup, as the snapshot can be reverted to a physical standby without loss of data protection capabilities.

6. Reduced Administrative Overhead

Using a snapshot standby can reduce the need for cloning production databases for testing purposes, simplifying administrative tasks. Since the snapshot is derived from an existing physical standby, it minimizes the overhead associated with managing multiple copies of the database.

Snapshot standby databases provide a versatile solution for testing and development while ensuring data protection and recovery capabilities, making them a valuable tool in Oracle database management. This process allows for testing and development on a standby database without affecting the primary database, while still maintaining the ability to revert changes easily

Please feel free to ask. thank you 🙂

Toufique Khan

The cluvfy (Cluster Verification Utility)

The cluvfy (Cluster Verification Utility) is a tool provided by Oracle to verify the state of various components in an Oracle RAC (Real Application Clusters) environment before and after installation, patching, or other system changes. Here are the key points about the cluvfy utility:

The cluvfy utility performs system checks to ensure the required configuration and preinstallation steps have been completed successfully, so that the Oracle update or patch operation can complete without issues.

Some of the key checks performed by cluvfy include verifying node reachability, node connectivity, shared storage accessibility, free space in the CRS home, CRS integrity, and more.

To use cluvfy, you need to run the commands as the "grid" user. If the Grid Infrastructure is not yet installed, you can run cluvfy from the software files directory (e.g. /u01/orasw/grid). Otherwise, run it from the $ORACLE_HOME.

The cluvfy utility is included with the Grid Infrastructure installation, but you can also download the latest standalone version from My Oracle Support.

The standalone version is backward compatible and can be used with older Oracle RAC versions. Running cluvfy before and after patching Grid Infrastructure is recommended to ensure the patch can be applied successfully and the cluster is in a healthy state after the patch.

In summary, the cluvfy utility is an essential tool for verifying the readiness and health of an Oracle RAC environment and should be used regularly during the installation, configuration, and maintenance of the cluster.

Using the Cluster Verification Utility(CVU)

The CVU can verify the primary cluster components during an operational phase or stage. A component can be basic, such as free disk space, or it can be complex, such as checking Oracle Clusterware integrity. For example, CVU can verify multiple Oracle Clusterware subcomponents across Oracle Clusterware layers. Additionally, CVU can check disk space, memory, processes, and other important cluster components. A stage could be, for example, database installation, for which CVU can verify whether your system meets the criteria for an Oracle RAC installation. Other stages include the initial hardware setup and the establishment of system requirements through the fully operational cluster setup.

When verifying stages, CVU uses entry and exit criteria. In other words, each stage has entry criteria that define a specific set of verification tasks to be performed before initiating that stage. 

This check prevents you from beginning a stage, such as installing Oracle Clusterware, unless you meet the Oracle Clusterware stage's prerequisites.

The exit criteria for a stage define another set of verification tasks that you need to perform after the completion of the stage. Post-checks ensure that the activities for that stage have been completed. 

Post-checks identify stage-specific problems before they propagate to subsequent stages.

The node list that you use with CVU commands should be a comma-delimited list of host names without a domain. The CVU ignores domains while processing node lists. If a CVU command entry has duplicate node entries after removing domain information, then CVU eliminates the duplicate node entries. Wherever supported, you can use the -n all option to verify all of your cluster nodes that are part of a specific Oracle RAC installation. You do not have to be the root user to use the CVU and the CVU assumes that the current user is the Oracle user.

Cluster Verification Utility Requirements

The CVU requirements are:

• At least 30MB of free space for the CVU software on the node from which you run the CVU
• A location for the current JDK, Java 1.4.1 or later
• A working directory with at least 25MB of free space on each node

Verify the Post-installation Configuration of a Cluster

[oracle@collabn1 ~]$ cluvfy stage -post crsinst -n collabn1,collabn2

Performing post-checks for cluster services setup

Checking node reachability...

Node reachability check passed from node "collabn1"

Checking user equivalence...

User equivalence check passed for user "oracle"

Checking node connectivity...

Checking hosts config file...

Verification of the hosts config file successful

Check: Node connectivity using interfaces on subnet "192.168.78.0"

Node connectivity passed for subnet "192.168.78.0" with node(s) collabn2,collabn1

TCP connectivity check passed for subnet "192.168.78.0"

Check: Node connectivity using interfaces on subnet "172.16.100.0"

Node connectivity passed for subnet "172.16.100.0" with node(s) collabn1,collabn2

TCP connectivity check passed for subnet "172.16.100.0"

Checking subnet mask consistency...

Subnet mask consistency check passed for subnet "192.168.78.0".

Subnet mask consistency check passed for subnet "172.16.100.0".

Subnet mask consistency check passed.

Node connectivity check passed

Checking multicast communication...

Checking subnet "172.16.100.0" for multicast communication with multicast group "224.0.0.251"...

Check of subnet "172.16.100.0" for multicast communication with multicast group "224.0.0.251" passed.

Check of multicast communication passed.

Checking whether the ASM filter driver is active and consistent on all nodes

ASM filter driver library is not installed on any of the cluster nodes.

ASM filter driver configuration was found consistent across all the cluster nodes.

Time zone consistency check passed

Checking Cluster manager integrity...

Checking CSS daemon...

Oracle Cluster Synchronization Services appear to be online.

Cluster manager integrity check passed

UDev attributes check for OCR locations started...

UDev attributes check passed for OCR locations

UDev attributes check for Voting Disk locations started...

UDev attributes check passed for Voting Disk locations

Default user file creation mask check passed

Checking cluster integrity...

Cluster integrity check passed

Checking OCR integrity...

Checking the absence of a non-clustered configuration...

All nodes free of non-clustered, local-only configurations

Checking daemon liveness...

Liveness check passed for "CRS daemon"

Checking OCR config file "/etc/oracle/ocr.loc"...

OCR config file "/etc/oracle/ocr.loc" check successful

Disk group for ocr location "+OCRVOTE/collabn-cluster/OCRFILE/registry.255.934671619" is available on all the nodes

Checking OCR backup location "/u01/app/12.1.0/grid/cdata/collabn-cluster"

OCR backup location "/u01/app/12.1.0/grid/cdata/collabn-cluster" check passed

NOTE:

This check does not verify the integrity of the OCR contents. Execute 'ocrcheck' as a privileged user to verify the contents of OCR.

OCR integrity check passed

Checking CRS integrity...

Clusterware version consistency passed.

CRS integrity check passed

Checking node application existence...

Checking existence of VIP node application (required)

VIP node application check passed

Checking existence of NETWORK node application (required)

NETWORK node application check passed

Checking existence of ONS node application (optional)

ONS node application check passed

Checking Single Client Access Name (SCAN)...

Checking TCP connectivity to SCAN listeners...

TCP connectivity to SCAN listeners exists on all cluster nodes

Checking name resolution setup for "collabn-cluster-scan.racattack"...

Checking integrity of name service switch configuration file "/etc/nsswitch.conf" ...

All nodes have same "hosts" entry defined in file "/etc/nsswitch.conf"

Check for integrity of name service switch configuration file "/etc/nsswitch.conf" passed

Checking SCAN IP addresses...

Check of SCAN IP addresses passed

Verification of SCAN VIP and listener setup passed

Checking OLR integrity...

Check of existence of OLR configuration file "/etc/oracle/olr.loc" passed

Check of attributes of OLR configuration file "/etc/oracle/olr.loc" passed

WARNING:

This check does not verify the integrity of the OLR contents. Execute 'ocrcheck -local' as a privileged user to verify the contents of OLR.

OLR integrity check passed

Checking Oracle Cluster Voting Disk configuration...

Oracle Cluster Voting Disk configuration check passed

User "oracle" is not part of "root" group. Check passed

Oracle Clusterware is installed on all nodes.

CTSS resource check passed

Query of CTSS for time offset passed

CTSS is in Active state. Proceeding with check of clock time offsets on all nodes...

Check of clock time offsets passed

Oracle Cluster Time Synchronization Services check passed

Checking VIP configuration.

Checking VIP Subnet configuration.

Check for VIP Subnet configuration passed.

Checking VIP reachability

Check for VIP reachability passed.

    Reference: https://docs.oracle.com/en/database/oracle/oracle-database/19/cwadd/cluster-verification-utility-reference.html#GUID-0CBB99C2-6F24-46E5-8A9B-A1A0C581E86A

Please feel free to ask. thank you 🙂

Toufique Khan