Three highly available cluster scenarios for Oracle ____oracle

reproduced from: Http://www.cnblogs.com/baiboy/p/orc2.html#_label1 three highly available cluster scenarios for Oracle

1 RAC (real application clusters)

Multiple Oracle servers form a shared cache, and these Oracle servers share a network-based storage. This system can tolerate the failure of stand-alone/or multiple machines. However, multiple nodes within the system need high-speed network interconnection, which is basically to put everything in a room, or a data center. If the engine room fails, for example, the network is not working, that would be bad. Therefore, only with RAC can not meet the needs of the general Internet company's important business, the important business needs of many rooms to tolerate the accident of a single room.

2 Data Guard. (The main function is redundancy)

Data Guard This scheme is suitable for multiple computer rooms. A production database in a computer room, and other computer room to deploy standby database. The standby database is divided into physical and logical. The physical standby database is mainly used for switching after production failure. And the logical standby database can share the read load of production database at ordinary times.

3 MAA

MAA (Maximum availability architecture) is not the third, but the first two kinds of combination, to provide the highest availability. A RAC cluster is deployed in each room, with data guard synchronized between the multiple rooms. RAC Overview

Shared storage File System (NFS), or even clustered file systems (such as: OCFS2) are primarily used for storage area networks (where all nodes directly access the memory on the shared file system), which causes the node to fail without affecting access to the file system from other nodes, typically the shared disk file system is used for highly available clusters.

The core of Oracle RAC is the shared disk subsystem, in which all nodes in the cluster must be able to access all data, redo log files, control files, and parameter files, the data disks must be globally available, allow all nodes to access the database, and each node has its own redo logs and control files, However, other nodes must be able to access them to recover from a system failure in that node.

Oracle RAC runs on top of the cluster, providing the highest level of availability, scalability, and low cost computing capabilities for Oracle databases. If one node in the cluster fails, Oracle will be able to continue running on the remaining nodes. Oracle's main innovation is a technology called cache merging. Cache merging enables nodes in a cluster to efficiently synchronize their memory caches through high-speed trunking, thereby minimizing disk I/O. The most important advantage of caching is that it enables the disk of all nodes in the cluster to share access to all data. Data does not need to be partitioned between nodes. Oracle is the only vendor to provide an open system database with this capability. Other database software that claims to be able to run on the cluster needs to partition the database data, which is impractical. The enterprise grid is a future data center built on a large configuration of standardized commercial components, including processors, networks, and storage. The cache consolidation technology for Oracle RAC delivers the highest levels of availability and scalability. Oracle databases 10g and ORACLERAC 10g significantly reduce operational costs and enhance flexibility, giving the system greater adaptability, foresight, and flexibility. Dynamically providing nodes, storage, CPUs, and memory can reduce costs by increasing utilization while achieving the required service levels. RAC integrated cluster components management

Oracle RAC 10g delivers a fully integrated cluster management solution on all platforms where Oracle database 10g runs. This set of groupware features includes cluster connectivity, message processing services and locking, cluster control and recovery, and a workload management framework (to be explored below). Oracle RAC 10g integrated cluster Management has the following advantages:

(i) Low cost. Oracle provides this feature free of charge.

(b) Single vendor support. Eliminates the problem of reciprocal prevarication.

(iii) Simpler installation, configuration and continuous maintenance. Oracle RAC 10g cluster components are installed, configured, and maintained using standard Oracle database management tools. This process requires no additional integration steps.

(iv) All platforms with consistent quality. Oracle has more stringent testing of new software versions than third-party products.

(v) All platforms with consistent functionality. For example, some third-party cluster products limit the number of nodes that can be supported within a cluster. With Oracle RAC 10g, all platforms can support up to 64 nodes. Users can also achieve a consistent response experience across all platforms, effectively addressing high availability challenges, including server node failures, interconnect failures, and I/O isolation.

(vi) Support for advanced functions. This includes integrated monitoring and notification capabilities to enable fast, coordinated recovery between the database and the application tier in the event of a failure. the architecture of the RAC

RAC is a cluster solution for Oracle databases, with two or more database nodes working in coordination. The RAC chart as shown in the following illustration:

The

Cluster Manager (Cluster Manager) consolidates other modules in a clustered system, providing communication between cluster nodes through high-speed, internal connections. The internal connection between the nodes uses the heartbeat line interconnection, the information function on the heartbeat line determines the node member information and the node update situation on the cluster logic, and the node's running state at some point in time, ensuring the cluster system running normally. Communication layer manages communication between nodes. Its responsibility is to configure, interconnect cluster node information, use the information generated by the heartbeat mechanism in the Cluster Administrator, transmit by the communication layer to ensure the correct arrival of the information. There are also cluster monitoring processes that continually validate the different areas of the system's health. For example, heartbeat monitoring constantly verifies that the heartbeat mechanism is functioning well. In an application environment, all servers use and manage the same database, in order to spread the workload of each server. Hardware requires at least two servers and a shared storage device, as well as two types of software, cluster software and a RAC component in an Oracle database. The OS on all servers should be the same type of OS, depending on the load-balancing configuration strategy, when a client sends a request to a listener of a service, the server, depending on the load-balancing policy, sends the request to the local RAC component, or it may be sent to another server's RAC Component processing, and after processing the request, RAC accesses the shared storage device through the cluster software. Logically, each node participating in the cluster has a separate instance that accesses the same database. Nodes communicate with each other through the communication layer (communication Layer) of the cluster software. At the same time, to reduce I/O consumption, there is a global caching service, so each instance of the database retains an identical database cache. The characteristics of RAC are as follows: L  Each node instance has its own SGA; l  each node instance has its own background process l  Each node's strength has its own redo logs l  every instance of each node Has its own undo tablespace l  all nodes share a copy of the datafiles and controlfiles RAC structure and mechanism

Before Oracle9i, the RAC is called OPS (Oracle Parallel Server). A big difference between RAC and OPS is that RAC uses cache Fusion (high cache merging) technology, which is updated by another node before it is written to disk by a node that has been removed, and then written to disk in the final version. In OPS, data requests between nodes require that data be written to disk before the requesting node can read the data. When cache Fusion is used, the data buffer between each node of RAC is transmitted through the internal network with high speed and low latency. The following figure is a typical schematic of the RAC external service, and an Oracle RAC Cluster contains the following sections

cluster node (Cluster node)-2 to N nodes or hosts running Oracle Database Server. Private networks (network interconnect)--RAC require a high-speed Internet-connected private network to handle communications and cache Fusion. Shared Storage--rac requires a shared storage device so that all nodes can access the data file. An external service network (Production Network)--rac A network of external services. Both the client and the application are accessed through this network. RAC Background Process

Oracle RAC has its own unique background processes that do not play a role in a single instance. As shown in the following illustration, some background processes for RAC running are defined. The features of these background processes are described below.

(1) LMS (global cache service processes) process is mainly used to manage the data block access in the cluster, and transmit the data block image in the Buffer cache of different instances. Copies a block of data directly from the cache of the control instance, and then sends a copy to the requested instance. and ensure that a mirror image of a block of data in all instances of Buffer cache can only occur once. The LMS process coordinates access to a block of data by passing messages in the instance. When an instance requests a block of data, the LMD process of the instance emits a request for a block resource that points to the LMD process of the instance of the main block, and the LMD process of the main instance and the LMD process of the instance being used release the resource. The LMS process that owns the instance of the resource then creates a consistent read of the data Block mirror and passes the block to the buffer CACHE of the instance requesting the resource. The LMS process guarantees that only one instance can be allowed to update the block at a time, and is responsible for maintaining the mirrored record of the block (the state FLAG that contains the update block). The RAC provides 10 LMS processes (0~9), which increase with the increase in the number of messages passed between nodes. (2) Lmon (lock monitor process, lock monitoring processes) is the global Queue Service monitor, each instance of the Lmon process will periodically communicate to check the health status of each node in the cluster, when a node failure, responsible for cluster reconfiguration, GRD recovery, and other operations, The service it provides is called the Cluster Group Service (CGS).

The Lmon mainly uses two kinds of heartbeat mechanism to complete the health examination.

(a) The network heartbeat between nodes (Network Heartbeat): Can be imagined as a timed between nodes to send Ping packet detection node state, if you can receive a response within the specified time, the other side of the normal state.

(ii) by controlling the file's disk heartbeat (Controlfile heartbeat): Each node's CKPT process updates the control file block every 3 seconds, which is called the Checkpoint Progress record, and the control file is shared. So the instances can check each other to see if they are updated in time to judge.

(iii) LMD (the Global enqueue Service daemon, lock Management daemon) is a background process, also known as the Global Queue Service daemon, because of the management requirements for resources to control access blocks and global queues. Within each instance, the LMD process manages the input remote resource request (that is, a lock request from another instance in the cluster). In addition, it is responsible for deadlock checking and monitoring conversion timeouts.

(iv) LCK (the lock process, lock processes) manages the non-cache fusion, and the lock request is a local resource request. LCK processes manage resource requests for instances of shared resources and invoke operations across instances. During the recovery process, it establishes a list of invalid lock elements and verifies the elements of the lock. Because of the primary function of LMS lock management during processing, only a single LCK process exists in each instance.

(v) DIAG (the diagnosability daemon, Diagnostic daemon) is responsible for capturing information about process failures in the RAC environment. and write trace information for failure analysis, the information generated by DIAG is very useful in working with Oracle Support Technical cooperation to find the cause of failure. Each instance requires only one DIAG process.

(vi)  GSD (the Global Service daemon) interacts with the management tools DBCA, Srvctl, and OEMs of the RAC to complete administrative transactions such as the startup shutdown of the instance. To ensure that these management tools are working properly, you must start GSD on all nodes, and a GSD process supports multiple RAC.GSD processes in one node Oraclehome/bin directory, and its log file is Oraclehome/bin directory. Its log file is Oracle_home/srvm/log/gsdaemon.log. GCS and GES Two processes are responsible for maintaining the state information of the files and cache blocks of each data through the global resource directory (the Globally Resource directory GRD). When an instance accesses the data and caches the data, other instances in the cluster get a corresponding block mirror, so that other instances can access the data without having to read the disk, and instead read the cache directly from the SGA. The GRD exists in the memory structure of each active instance, which causes the SGA of the RAC environment to be larger than the SGA in the Single-instance database system. Other processes and memory structures have little difference from single-instance databases. RAC shared storage

RAC requires shared storage, independent of instances of information, such as OCR and Votedisk mentioned above and data files stored in this shared store. There are some storage methods such as OCFS, OCFS2, RAW, NFS, ASM, and so on. OCFS (Oracle Cluster file system) and OCFS2 are just file systems, which, like NFS, provide a file system for shared storage in a clustered environment. Raw bare devices are also a way of storage, the way in which RAC is supported in previous versions of oracle11g, before oralce9i, Ops/rac support can only be used in such a way that it maps shared storage to RAW Device and then chooses the data Oracle needs Choose raw Device storage, but raw relative to the file system is not intuitive, not easy to manage, and raw Device has a number of limitations, raw obviously need to have a new scheme to replace, so there is a file system such as OCFS. Of course, this is just a set of file systems for Oracle's own implementation, and there are other vendor-supplied file systems that can be used as storage alternatives. ASM is just a schema for database storage, not a cluster solution, so the ASM should be different from the same level of raw and OCFS/OCFS2, raw and OCFS/OCFS2 can be used not only as a database storage scheme, but also as a Clusterwa The storage solution in the RE is the storage required in CRS, and ASM is only stored as a database, strictly only one node application (Nodeapps) in the RAC. ASM does not support the OCR and Votedisk required for clusterware installations, after all, the ASM itself needs an instance, and CRS is completely outside the architecture, which is why the ASM scheme is used, but it always adds OCFS/OCFS2 and R AW one of the reasons. The comparison of various RAC shared storage methods is as follows: Clustered file Systems--The GPFS of Windows and Linux under OCFS/OCFS2 AIX--The advantages are easy to manage and intuitive to represent, but the downside is file-based management software and OS cache Processing, performance and stability are deficient, so it is not suitable for use in the production environment. can support CRS cluster software files and database files. Raw bare Device Mode--a shared storage system that is supported by hardware, stored directly with raw devices and canSupport for cluster software files and database files. Network File System (NFS)-shared storage via NFS, but requires Oracle-certified NFS to support the CRS cluster software files and database files. asm--Collection RAW mode I/O high-performance and clustered file system Easy management advantages, oracle10g under the shared storage approach, but the ASM is the need for Oracle instance support, so ASM only support the database files, not the CRS file.the difference between a RAC database and a single-instance database

In order for all instances in the RAC to have access to the database, all datafiles, control files, pfile/spfile, and redo log files must be kept on a shared disk and be accessible to all nodes simultaneously. It involves bare devices and cluster file systems. The RAC database is structurally different from a single instance: Configure at least one redo thread for each instance-for example, a cluster of two instances will have at least 4 redo log group. Two redo group per instance. In addition, you need to prepare an UNDO table space for each instance.

1, redo and undo, each instance in the database modification of who with the redo and undo section, each lock their own modified data, the operation of different instances of independent open to avoid inconsistent data. Consider the special considerations for backup or recovery redo log and archive logs in this case.

2, memory and process each node of the instance has its own memory structure and process structure. The structure of each node is basically the same. Through cache fusion (buffer fusing) technology, RAC can synchronize the cached information in the SGA between nodes to improve the access speed and ensure the consistency.