Oracle RAC - /etc/hosts of the nodes
Oracle RAC Solution · Config document · referenced from Network and DNS plan
The local name table of the two RAC nodes: every name of the installation with its address. The notes say only that the file is not currently used because every record is in DNS; the names are resolved by the DNS server dns1 alone.
| Item | Value |
|---|---|
| Path on the host | /etc/hosts |
| Written for | the RAC nodes oradb01 and oradb02; the notes show one file and no per-node difference |
| State | not in use; all records are in the zone example.net on dns1 |
| Resolver actually used | /etc/resolv.conf with search example.net and nameserver 10.30.40.13 |
The file
# The loopback must not carry the host name. The Oracle cluster services are unhappy about it # and the cluster will not come up, at least not on the second and later nodes. 127.0.0.1 localhost.localdomain localhost # Oracle RAC - public IP 10.30.10.11 oradb01.example.net oradb01 10.30.10.12 oradb02.example.net oradb02 # Oracle RAC - virtual IP 10.30.10.21 oradb01-vip.example.net oradb01-vip 10.30.10.22 oradb02-vip.example.net oradb02-vip # Oracle RAC - scan IP 10.30.10.31 oradb-scan.example.net oradb-scan 10.30.10.32 oradb-scan.example.net oradb-scan 10.30.10.33 oradb-scan.example.net oradb-scan # Oracle RAC - interconnect IP 10.30.20.11 oradb01-int.example.net oradb01-int 10.30.20.12 oradb02-int.example.net oradb02-int # Oracle RAC - symantec backend 10.30.30.11 oradb01-bck.example.net oradb01-bck 10.30.30.12 oradb02-bck.example.net oradb02-bck # Oracle RAC - Symantec backend (in case the Oracle listener also listens on these addresses) # 10.30.30.21 oradb01-bck-vip.example.net oradb01-bck-vip # 10.30.30.22 oradb02-bck-vip.example.net oradb02-bck-vip # Oracle RAC - OS/DB management 10.30.40.11 oradb01-mng.example.net oradb01-mng 10.30.40.12 oradb02-mng.example.net oradb02-mng # Oracle RAC - OS/DB management (in case the Oracle listener also listens on these addresses) # 10.30.40.21 oradb01-mng-vip.example.net oradb01-mng-vip # 10.30.40.22 oradb02-mng-vip.example.net oradb02-mng-vip
What to read in it
| Lines | Meaning |
|---|---|
127.0.0.1 localhost.localdomain localhost | The loopback line carries only localhost. The comment above it is the one finding in this file that holds whether the file is used or not |
| public, virtual, scan | The same names and addresses as in the forward zone; the SCAN name is listed three times |
oradb01-bck-vip, oradb02-bck-vip, commented out | Prepared in case the Oracle listener should also listen in the backup network; never activated |
oradb01-mng-vip, oradb02-mng-vip, commented out | The same idea for the management network; never activated |
The comment on the loopback line is worth keeping even without the file. If the host name stands on the 127.0.0.1 line, the node resolves its own name to the loopback address, and according to my notes the cluster services then do not come up, "at least not on the second and later nodes".
The file has no iSCSI names, no dns1 and no backup server; the forward zone has them.
Checked against Oracle Grid Infrastructure 26ai
| As built | Today |
|---|---|
| Loopback line without the host name | Still valid. The 11.2 guide lists root.sh failures caused by a wrong hosts file in its troubleshooting chapter |
| All names in DNS, hosts file not used | The current network checklist wants the public node name "configured in the DNS and in /etc/hosts", so both, not DNS alone |
| The SCAN name three times in the hosts file | "Oracle strongly recommends that you do not configure SCAN VIP addresses in the hosts file. If you use the hosts file to resolve SCANs, then the SCAN can resolve to one IP address only." The 11.2 guide has the same sentence |
So the file as written would have been wrong in one place had it been used: the three SCAN lines. A hosts file with the public, virtual and private names of the nodes and without the SCAN is what the guides describe.