What you will learn
Oracle RAC runs multiple instances against one database. Each instance has its own memory and processes, while database files are shared. A service is the application connection target and can move between instances. You will verify those layers without stopping the cluster.
Before you begin
Use an isolated Oracle Database 19c Linux lab with a certified patch level. Names host1.sample.com and host2.sample.com identify distinct lab hosts; replace them consistently with your own addresses. Use oracle for database software and grid for Grid Infrastructure where ownership is separated. Connect through local operating-system authentication or a configured wallet; no example includes a password. Preserve a tested backup and record the database identity before changes. Use a configured two-node administrator-managed RAC lab with DB_UNIQUE_NAME DEMO, instances DEMO1 and DEMO2, and an existing application service.
1. Inspect registered resources
olsnodes -s -t
crsctl status resource -t
srvctl config database -db DEMO
srvctl status database -db DEMO
Run from the appropriate Grid or database home as the authorized owner. A registered resource is not necessarily running. Compare configured membership with the intended inventory before treating a missing instance as a failure.
2. Confirm database identity
SELECT name,db_unique_name,database_role,open_mode FROM v$database;
SELECT inst_id,instance_name,host_name,status FROM gv$instance ORDER BY inst_id;
GV$ combines observations from instances and identifies each with INST_ID. Do not confuse instance names with DB_UNIQUE_NAME. In a CDB, also check the intended PDB; an open CDB does not establish application availability.
3. Trace the application service
srvctl config service -db DEMO
srvctl status service -db DEMO
SELECT sys_context('USERENV','SERVICE_NAME') AS service_name,
sys_context('USERENV','INSTANCE_NAME') AS instance_name FROM dual;
Run SQL through an application-style service connection. Repeat with new sessions to inspect placement. Existing sessions do not necessarily move when new connections begin using another instance. SCAN and local listeners are connection infrastructure, not separate database copies.
4. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
INSTANCE_NAME HOST_NAME STATUS
DEMO1 host1.sample.com OPEN
DEMO2 host2.sample.com OPEN
A service may intentionally run on only one instance. Compare placement with its configured policy.
Verify the result
Match membership, registered instances, SQL identity, and successful application service connections. Record a committed fixture query through the service and use it as the baseline before maintenance.
Troubleshooting
An OPEN instance with an unavailable service suggests service, listener, or PDB configuration rather than a need to restart the cluster. Investigate resource-specific errors before broad CRS commands.
Recovery and next steps
These checks are read-only. Preserve the results. Plan a separate service-relocation exercise after understanding connection-pool behavior; membership alone is not an application availability test.