What you will learn
A node replacement affects Clusterware, database homes, instances, networking, and services. The historical notes mixed forced removal and inventory edits. This tutorial organizes the task around evidence and a release-specific add/remove workflow instead of copying old root scripts.
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. Prepare host3.sample.com as the replacement with compatible packages, storage visibility, network, time synchronization, and naming. Keep surviving nodes healthy. These commands are prerequisite and acceptance checks for a separately reviewed replacement plan.
1. Inventory the departing node
olsnodes -s -t
crsctl status resource -t
srvctl config database -db DEMO
srvctl config service -db DEMO
srvctl status database -db DEMO
List every home, instance, service preference, VIP, listener, and local dependency. Identify client reconnection behavior. Relocating a service does not remove an instance or software home.
2. Check replacement prerequisites
cluvfy stage -pre nodeadd -n host3 -verbose
Use the appropriate Grid home and the hostname form registered with the cluster. Resolve network, storage, package, and user-equivalence findings. Read proposed fixups before execution; a fixup flag does not replace diagnosis.
3. Use the supported addition and removal workflow
Drain services and remove the departing instances and node through the procedure matching the release and node condition. Extend Grid and each required database home, complete instructed privileged scripts, and add instances with supported tools. Do not parallel-edit inventory lists or run old forced-deconfiguration commands on a healthy cluster.
4. Check the resulting topology
cluvfy stage -post nodeadd -n host3 -verbose
olsnodes -s -t
srvctl status database -db DEMO
srvctl status service -db DEMO
SELECT inst_id,instance_name,host_name,status FROM gv$instance ORDER BY inst_id;
Verify instance-specific undo and redo threads, matching patch inventories, and intended service placement. Test a new application connection to verify routing.
5. 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.
Cluster member host3: active
Required homes: patch-aligned
Database instance: OPEN
Service connection: passed
Surviving nodes: healthy
Node-add completion alone does not establish application recovery.
Verify the result
Compare final membership, instances, and services with the intended design. Commit an application probe and verify backup and monitoring coverage under representative load.
Troubleshooting
A node may join Clusterware while its database home or instance is absent. Diagnose the specific layer. Compare stale names against the recorded departing node rather than broadly deleting similar resources.
Recovery and next steps
Maintain service capacity on surviving nodes if addition fails. Preserve logs and use cleanup appropriate to the exact stage. Operating-system replacement does not automatically restore database configuration.