Beginners Gude to Oracle RAC One Node

Oracle RAC One Node

Oracle RAC One Node is a single instance of an Oracle RAC-enabled database running on one node in the cluster, only, under normal operations. This option adds to the flexibility that Oracle offers for database consolidation while reducing management overhead by providing a standard deployment for Oracle databases in the enterprise. Oracle RAC One Node database requires Oracle Grid Infrastructure and, therefore, requires the same hardware setup as an Oracle RAC database.

Oracle supports Oracle RAC One Node on all platforms on which Oracle RAC is certified. Similar to Oracle RAC, Oracle RAC One Node is certified on Oracle Virtual Machine (Oracle VM). Using Oracle RAC or Oracle RAC One Node with Oracle VM increases the benefits of Oracle VM with the high availability and scalability of Oracle RAC.

With Oracle RAC One Node, there is no limit to server scalability and, if applications grow to require more resources than a single node can supply, then you can upgrade your applications online to Oracle RAC. If the node that is running Oracle RAC One Node becomes overloaded, then you can relocate the instance to another node in the cluster. With Oracle RAC One Node you can use the Online Database Relocation feature to relocate the database instance with no downtime for application users. Alternatively, you can limit the CPU consumption of individual database instances per server within the cluster using Resource Manager Instance Caging and dynamically change this limit, if necessary, depending on the demand scenario.

Creating an Oracle RAC One Node Database

You can create Oracle RAC One Node databases by using the Database Configuration Assistant (DBCA), as with any other Oracle database (manually created scripts are also a valid alternative). Oracle RAC One Node databases may also be the result of a conversion from either a single-instance Oracle database (using rconfig, for example) or an Oracle RAC database. Typically, Oracle-provided tools register the Oracle RAC One Node database with Oracle Clusterware. Depending on your configuration, automatic registration of an Oracle RAC One Node database with Oracle Clusterware may not have happened. If this is the case, then follow the steps in this section to register the Oracle RAC One Node database with Oracle Clusterware.

If your Oracle RAC One Node database did not register automatically with Clusterware, then use the srvctl add database command to add an Oracle RAC One Node database to your cluster. For example:

$ srvctl add database -dbtype RACONENODE [-server server_list] [-instance instance_name] [-timeout timeout]

Use the -server option and the -instance option when adding an administrator-managed Oracle RAC One Node database.

For Oracle RAC One Node databases, you must configure at least one dynamic database service (in addition to and opposed to the default database service). When using an administrator-managed Oracle RAC One Node database, service registration is performed as with any other Oracle RAC database. When you add services to a policy-managed Oracle RAC One Node database, SRVCTL does not accept any placement information, but instead configures those services using the value of the SERVER_POOLS attribute.

Verifying an Existing RAC One Node Database

Executing the srvctl config database command displays Oracle RAC One Node database configuration data. The data in the output specific to Oracle RAC One Node includes Type, Online relocation timeout, and candidate servers. As you can see in the example in the slide, the RAC One Node database orcl can run on host01 or host02 and the online relocation timeout value is 30 minutes.

Executing the srvctl config database command without the –db option returns a list of all databases that are registered with Oracle Clusterware.

[oracle@host01 ~]$ srvctl config database -db orcl
Database unique name: orcl
Database name: orcl
Oracle home: /u01/app/oracle/product/12.2.0/dbhome_1
Oracle user: oracle
Spfile: +DATA/orcl/spfileorcl.ora
Password file: +DATA/orcl/orapworcl
Domain: cluster01.example.com
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: orcldb
Database instances:
Disk Groups: DATA
Mount point paths:
Services: SVC1
Type: RACOneNode
Online relocation timeout: 30
Instance name prefix: orcl
Candidate servers: host01,host02
...

Oracle RAC One Node Online Relocation

Oracle RAC One Node allows the online relocation of an Oracle RAC One Node database from one server to another, which provides increased availability for applications based on an Oracle Database. The relocation period can be customized up to 12 hours. You can now move a database for workload balancing as well as for performing planned maintenance on the server, on the operating system, or when applying patches to the Oracle software in a rolling fashion.

Only during a planned online database relocation is a second instance of an Oracle RAC One Node database created, so that any database sessions can continue while the database is relocated to a new node. If your Oracle RAC One Node database is administrator managed, then the target node to which you want to relocate the database must be in the candidate list or in the Free server pool. If the target node is in the Free server pool, then the node is added to the candidate list.

When you relocate a database instance to a target node that is not currently in the candidate server list for the database, you must copy the password file, if configured, to the target node. Oracle Corporation recommends using OS authentication, instead, or using Oracle Clusterware to start and stop the database, and defining users in the data dictionary for other management.

Use the srvctl relocate database command to initiate relocation of an Oracle RAC One Node database:

$ srvctl relocate database –db db_unique_name {[-node target] [-timeout timeout_value] | -abort [-revert]} [-verbose]

-db [db_unique_name] Unique name of database to relocate
-node [target] Target node to which to relocate database
-timeout [timeout] Online relocation timeout in minutes
-abort Abort failed online relocation
-revert Remove target node of failed online relocation request
from the candidate server list of administrator-managed RAC One
Node database
-verbose Verbose output
-help Print usage

Online Relocation Considerations

Using the Single Client Access Name (SCAN) to connect to the database, clients can locate the service independently of the node on which it is running. Relocating an Oracle RAC One Node instance is therefore mostly transparent to the client, depending on the client connection. Oracle recommends to use either Application Continuity and Oracle Fast Application Notification or Transparent Application Failover to minimize the impact of a relocation on the client..

If you do not use Application Continuity, FAN or TAF, any in-flight transactions will be allowed to complete as long as they complete within the timeout period entered, after which the clients will receive an ORA-3113 error when their session is terminated due to the shutdown of the Oracle RAC One Node instance (ORA3113 End of Line on communication channel). Because the new instance will be running, the client can immediately log in again.

If the shutdown of the original instance takes longer than the set timeout, this database instance is aborted. The new instance will then perform recovery to clean up any transactions that were aborted due to the shutdown.

Performing an Online Relocation

Execute the srvctl relocate database command specifying the database to be migrated, the host to which it will be migrated to, and optionally a timeout value used to allow connections with active transactions to finish. If no value is specified, the default is 30 minutes.

[oracle@host01 ~]$ srvctl relocate database -db orcl -node host02 -timeout 15 -verbose

Configuration updated to two instances
Instance orcl_2 started
Services relocated
Waiting for 15 minutes for instance orcl_1 to stop.....
Instance orcl_1 stopped
Configuration updated to one instance

If you retrieve the status of the database before the relocation starts, you should see something like this:

[oracle@host01 ~]$ srvctl status database -db orcl
Instance orcl_2 is running on node host01
Online relocation: INACTIVE

During the relocation:

[oracle@host01 ~]$ srvctl status database -db orcl
Instance orcl_1 is running on node host01
Online relocation: ACTIVE
Source instance: orcl_1 on host01
Destination instance: orcl_2 on host02

After the relocation is complete:

[oracle@host01 ~]$ srvctl status database -db orcl
Instance orcl_2 is running on node host02
Online relocation: INACTIVE

Online Relocation Illustration

In the example configuration shown above, you have five single-instance Oracle RAC One Node databases running in a cluster of three servers. Server 1 is hosting Oracle RAC One Node databases DB-A (database A) and DB-B (database B), server 2 is hosting database DB-C (database C) and server 3 is hosting databases DB-D (database D) and DB-E (database E).

Each server runs one OS. In servers 1 and 3, multiple databases are consolidated onto a single OS. This deployment itself provides many consolidation benefits. However, online database relocation, a unique feature of Oracle RAC One Node that provides live relocation of databases across nodes in the cluster, enables many additional benefits.

Online database relocation allows an online relocation of a database from one server to another server. Online database relocation leverages the ability of Oracle Real Application Clusters to simultaneously run multiple instances servicing a single database. In the figure in the slide, the database B RAC One Node database on server 1 is migrated to server 2. Oracle RAC One Node starts up a second DB-B instance on server 2, and for a short period of time runs in an active-active configuration.

As connections complete their transactions on server 1, they are migrated to the instance on server 2.

Once all the connections have migrated to the database B instance on server 2, the instance on server 1 is shut down and the relocation is complete. To sum up, you have migrated database B from server 1 to server 2 while the database was online and performing work. To extend the example, you could initiate an operating system upgrade or patch including a reboot of server 1 by simply migrating database A (DB-A).

Online Maintenance: Rolling Patches

RAC One Node administrators can online migrate the databases off the server to a spare server, and then perform all types of maintenance on the idle server, including hardware maintenance, OS upgrades, OS patches, and database patches. With online database relocation, a new database instance is created on a new server (running in a different operating system), and work is online migrated to the new instance. Thus, the old operating system and database home remain on the former host server, and can be upgraded (OS) or patched (DB).

You continue with your deployment example from the previous slide. The illustration in the slide depicts a RAC One Node deployment after using online database relocation to move database B from server 1 to server 2. After the relocation, the database binaries that had hosted the instance formerly running on server 1 remain available for patching.

Once the database binaries on server 1 have been patched, database B can be migrated via online database relocation back to server 1. Because online database relocation supports relocation between instances at different patch levels, the operation is completely online and requires no disruption to end users. In this case, the online database relocation migrates the connections back to server 1, then the instance on server 2 is shut down, completing the relocation. Similarly, online database relocation can be used to move all databases off a node in preparation for an online operating system upgrade.