SCAN listener loses services; Setting remote listener throws ORA-132 Oracle 19c 2-node RAC, RHEL 7 Problem: After SCAN listeners are relocated to the other node, `lsnrctl service LISTENER_SCAN' shows no service registered. DB alert log, alert_.log, keeps showing ORA-00132: syntax error or unresolved network name ' :1521' once every 10 seconds. Inside Oracle, "alter system register" does not help. Parameters local_listener and remote_listener are never explicitly set and their values look fine, showing ' (ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1521))' and ' :1521', respectively. `tnsping' either string shows "OK" (the latter requires $DBHOME/network/admin/sqlnet.ora to have "EZCONNECT" added to "NAMES.DIRECTORY_PATH"). But sqlplus /@ throws ORA-12514 (TNS:listener does not currently know of service requested in connect descriptor). Trying to alter system set either listener parameter to its current value as shown throws ORA-00132 (syntax error or unresolved network name). Cause: Bug 13066936 - Instance does not register services when scan fails over(Doc ID 13066936.8) Bug 12659561 - after scan listener failover, database instance might not register to the scan listener(Doc ID 12659561.8) which talk about the same problem. Also Issue #5 of Top Issues That Cause Troubles with SCAN VIP and Listeners(Doc ID 1373350.1) The bug (or bugs?) was fixed in 11.2.0.4. But we hit it again in 19c. Solution: The suggested workaround works well: set remote_listener to a null string and then back to the original value. Then `lsnrctl service LISTENER_SCAN' shows the service and sqlplus /@ works. Comment: Another emergency workaround is to change the connect identifier definition in clients' tnsnames.ora (or OID if you use it). Instead of one SCAN as hostname, e.g. (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=))) we can use the pre-11g format, splitting the address into two addresses, each using a VIP as host, because it was the SCAN listeners which listen on the SCAN that have lost service, not the regular listeners which listen on the VIP's. (Unfortunately, in our case, we had too many clients using their own tnsnames.ora, not a centralized one. So this workaround won't help.) A general comment: Computer hardware can be restarted by power off and power back on. Software can be restarted by stopping and re-starting it. A software parameter can be "restarted" by setting it to a null string and then setting it back to its original value, not simply by setting it to its current value without setting it to null first. Remaining problem: After the fix, DB alert log continues to show ORA-00132. To find the source or what process keeps writing in here, run as root: auditctl -w .log> tail -f /var/log/audit/audit.log auditctl -W .log> <-- run this after audit.log shows one line of "ORA-00132" in alert_.log (Ref: https://unix.stackexchange.com/questions/13776/how-to-determine-which-process-is-creating-a-file) /var/log/audit/audit.log shows that process 73994 is doing I/O to alert_.log: type=SYSCALL msg=audit(1618257850.520:99864): arch=c000003e syscall=92 success=yes exit=0 a0=7ffe63fa7244 a1=ffffffff a2=3e9 a3=1 items=1 ppid=1 pid=73994 auid=1000 uid=1000 gid=1001 euid=1000 suid=1000 fsuid=1000 egid=1003 sgid=1003 fsgid=1003 tty=(none) ses=5 comm="oracle_73994_fs" exe="/u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle" key=(null) type=CWD msg=audit(1618257850.520:99864): cwd="/u01/app/oracle/product/19.0.0/dbhome_1/dbs" type=PATH msg=audit(1618257850.520:99864): item=0 name="/u01/app/oracle/diag/rdbms///trace/alert_.log" inode=15690384 dev=fd:03 mode=0100640 ouid=1000 ogid=1001 rdev=00:00 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 Process 73994 is oraagent.bin. `ps -ef | grep oraagent' shows two such processes. According to `lsof ', it's the one that opens crsd_oraagent_oracle.trc that is writing to alert_.log. This can be verified by reading crsd_oraagent_oracle.trc, which contains the similar lines as in alert_.log: 2021-04-12 15:26:48.386 : USRTHRD:3604920064: [ INFO] {2:21138:2031} LsnrRegThd::setRemoteListener 860 error during isListenerNetworkSettingNeeded 2021-04-12 15:26:48.386 : USRTHRD:3604920064: [ INFO] {2:21138:2031} Thread:DedicatedThread DbAgent::DedicatedThread::run 260 setRemoteListener Exception OCIException ORA-02097: parameter cannot be modified because specified value is invalid ORA-00119: invalid specification for system parameter REMOTE_LISTENER ORA-00141: all addresses specified for parameter REMOTE_LISTENER are invalid ORA-00132: syntax error or unresolved network name ':1521' The solution is to kill 73994 (no need to kill -9), or kill the database sessions whose module is like 'oraagent.bin@%'. There may be several sessions on behalf of the oraagent process. Then a new oraagent process will be spawned, and alert_.log will be clean. If you accidentally killed the other oraagent, which is for ohasd, the CRS stack will NOT crash. The process will be re-spawned and everything will continue to run.