What’s different about Oracle RAC from single-instance Oracle databases?
Oracle RAC allows several Oracle instances running on separate machines (nodes) to access a shared database. All physical data files and log files are on shared storage. Oracle RAC requires Oracle Clusterware, the infrastructure component that coordinates interactions between several cluster nodes. By contrast, single-instance Oracle databases have a single Oracle instance accessing and managing data files and log files and do not use Oracle Clusterware.
What are the Delphix pre-requisites for handling Oracle RAC environments?
For the source databases, Delphix requires that the Delphix Toolkit be installed in the same directory on each of the nodes in the source cluster (please see Oracle RAC Environment Requirements for more information). Delphix will also requires that all datafiles and archivelogs be located on storage shared by all of the cluster nodes, this is the only requirement that is different from Oracle Single Instance otherwise for source hosts and source databases everything will be exactly the same for RAC databases.
In order to provision RAC virtual databases (VDBs), Delphix will require that an Oracle Cluster (using Clusterware) be configured ahead of time. Delphix will then be able to provision RAC VDBs to the pre-configured Oracle cluster environment.
Delphix will have two types of environments -- host environments and cluster environments. Host environments are single-node entities with no Oracle Clusterware. Host environments are the equivalent of today’s source hosts and target hosts. With 3.0, Delphix added the notion of a cluster environment. A cluster environment is comprised of one or more hosts that use Oracle Clusterware. When linking or provisioning to a cluster environment, Delphix users will be able to take advantage of clustering features such as automatic failover of SnapSync/LogSync when a node goes down and the ability to provision full RAC VDBs.
How do redo and archive work in the context of RAC databases?
It is Oracle best practice for all of the different instances to write archive and redo to shared storage. Delphix also requires that all datafiles and archivelogs be located on storage shared by all of the cluster nodes. The vast majority of RAC installations are configured this way to enable easy recoverability. For RAC VDBs, all storage is within Delphix, so all of the datafiles and archivelogs will already be using shared storage.
Is there anything different about how RMAN and BCT interact with RAC databases?
No, RMAN has the intelligence to handle cluster configuration and handles the tracking of changed blocks across all nodes. The BCT file is like a datafile and is accessible to all nodes in shared storage. The BCT file will likely be bigger for a RAC cluster than for a single-instance database, depending on the number of nodes.
Are there any nuances in how Delphix handles 10g RAC versus 11gR1 or 11gR2?
There are different versions of Oracle clusterware – 10gR2, 11gR1, 11gR2, etc. – each with different levels of discovery. Delphix will be able to do the best discovery of nodes, SCANs, virtual IPs, and listeners on 11gR2 databases, if these are not found there is the option to enter information manually.
Will Delphix support Oracle 22.214.171.124 RAC source databases or RAC VDBs?
No, Delphix does not support Oracle 126.96.36.199 RAC databases. Delphix support for Oracle 188.8.131.52 is limited to single-instance databases.
When we are sending port/firewall open requests for RAC dSource environments, should I be providing host or VIP (names/IPs).
There are two sets of holes needed. First, holes for the physical IP address of one node for port 22. This is used to discover and configure the cluster when creating the environment. During this discovery:
- If SCAN is configured Delphix will pick this up and use that for JDBC strings etc.
- If VIPs is configured and no SCAN or Delphix can't find the SCAN then Delphix will configure the JDBC strings etc., with the VIPs.
- If Delphix can't find SCAN or VIPs then Delphix will use physical IP for JDBC strings etc.
The second set of holes is needed for these JDBC connections and dSource operations (ports "1521", 8341, 8415). Determine which IP addresses are appropriate (SCAN, VIP, or physical) based on the Oracle config and the above algorithm.
Any nuances for a RAC upgrade?
dSource upgrades from 10g RAC to 11g RAC should work exactly the same as for single-instance dSource upgrades. The user would refresh the cluster after the upgrade, at which point Delphix should be able to detect the new Oracle home.
Can we (or should we) register VDBs with Oracle Cluster Ready Services (CRS)?
It is possible to register a VDB with CRS after it has been provisioned but we generally recommend against doing so. If the cluster moves an instance to another node, the Delphix NFS mount points for that instance would not follow and the VDB could not be started. Starting and stopping a VDB involves more than just calling start and stop of a database (e.g. file systems have to be mounted).