Oracle Cluster Registry (OCR) stores Cluster configuration information. You can have up to five OCR locations. Each OCR location resides on shared storage that is accessible by all nodes in the cluster. The OCR relies on distributed shared cache architecture for optimizing queries, and cluster-wide atomic updates against the cluster repository. Each node in the cluster maintains an in-memory copy of OCR, along with the CRSD that accesses its OCR cache. Only one of the CRSD processes actually reads from and writes to the OCR file on shared storage. This process refreshes its own local cache, as well as the OCR cache on other nodes in the cluster. For queries against the cluster repository, the OCR clients communicate directly with the local CRS daemon (CRSD) process on the node from which they originate. When clients need to update the OCR, they communicate through their local CRSD process to the CRSD process that is performing input/output (I/O) for writing to the repository on disk.
The main OCR client applications are CRSCTL, OUI, SRVCTL, Enterprise Manager (EM), the Oracle Database Configuration Assistant (Oracle DBCA), the Oracle Database Upgrade Assistant (Oracle DBUA), Oracle Network Configuration Assistant (Oracle NETCA), and the Oracle ASM Configuration Assistant (Oracle ASMCA). Furthermore, OCR maintains dependency and status information for application resources defined within Oracle Clusterware, specifically databases, instances, services, and node applications.
Note: In the diagram in the slide, note that a client process might also exist on server 2 but is not shown for the sake of clarity.