About RAC SCAN IP

A SCAN (Single Client Access Name) is a special case of VIP. The SCAN should also be defined in DNS, and not assigned to any host or interface. There should be three IPs associated with the SCAN name in DNS, and the DNS entry should be defined so that one of the three IPs is returned each time DNS is queried, in a round robin fashion.

At clusterware startup time, each of the three VIPs that make up the SCAN will be assigned to a different node in the cluster. (Except in the special case of a two node cluster, one of the nodes will have a 2 SCAN VIPs assigned to it.) The point of the SCAN, is that no matter how many nodes are added to or removed from the cluster, all the Net Service Name definitions in your tnsnames.ora (or LDAP equivalent) will not need to ever change, because they all refer to the SCAN, which doesn't change, regardless of how many node additions or drops are made to the cluster.

Additionally, you may have the SCAN defined as: rac-scan with three IPs, 10.1.1.7, 10.1.1.8, 10.1.1.9. Again, the DNS definition would be defined so those IPs are served up in a round robin order.

CRS-5019:All OCR locations are on ASM disk groups [DATA], and none of these disk groups are mounted.

In my case ,  from ASM alert.log , actually it is due to ASM failed to start because of ORA-00600 as shown below.


ORA-00600: internal error code, arguments: [kfcema35], [0], [742], [0], [4368], [], [], [], [], [], [], []CRS-2674: Start of 'ora.asm' on 'rac1' failed


However, I don't have solution to overcome this ora-00600. In the end, I decided to rebuild the cluster. 

about data guard FAL setting

FAL_SERVER = Specifies one or more Oracle Net service names for the databases from which this standby database can fetch (request) missing archived redo log files.

FAL_CLIENT = This parameter is no longer required. If it is not set, the fetch archive log (FAL) server will obtain the client's network address from the LOG_ARCHIVE_DEST_n parameter that corresponds to the client's DB_UNIQUE_NAME.


With broker configured

Yes the broker handles it. FAL_CLIENT would not be set at all but FAL_SERVER would default itself to the primary db_unique_name. That´s the beauty of the Broker - it really sorts these things out for you, so in my experience the best setup with Broker is to not set anything before hand, but let the Broker sort all those parameters for you. And if you need to change something, always do it from the dgmgrl interface - not sql*plus - as that would cause inconsistencies with the Broker configuration.

Key things leared from VNC Server setup

1.Commands: to setup different desktop.  Note that the desktops used by VNC server shall not be the same as that for direct access' desktop. e.g. I use KDE for local desktop, then my remote desktop is gnome.

-- for gnome desktop

xsetroot -solid grey
vncconfig -iconic &
dbus-launch --exit-with-session gnome-session &


-- for xfce4

 startxfce4 &
-- for kde
startkde &

2. commands to start/stop vncserver. Note that avoid to use sudo, otherwise the vncserver will be started as root instead of logon user. In the end, it causes file permission issue of .Xauthority

start :  vncserver
stop :  vncserver -kill :1


Ref: https://www.teknotut.com/en/install-vnc-server-with-gnome-display-on-ubuntu-18-04/