HomeOracle Page 2 - Large Database Features In Oracle, conclusion
RAC Architecture - Oracle
When you are working with large databases with Oracle Database 10g, there are certain topics with which you need to be familiar. These topics are covered in this article, which is the second of two parts. It is excerpted from chapter nine of the book Oracle Database 10g A Beginner's Guide, written by Ian Abramson et al (McGraw-Hill/Osborne, 2004; ISBN: 0072230789).
A typical RAC implementation groups multiple Oracle database instances running on multiple machines (or nodes). These nodes communicate with each other and share a common pool of disks. The disks house all of the data files that comprise the database. This architecture is illustrated in Figure 9-9.
Let’s look at a few of the key components in Figure 9-9:
Each node is connected to each other using high bandwidth communications.
Each node has its own set of log (redo) files.
The Cluster Manager monitors the status of each database instance in the cluster and enables communication between the instances. This manager known as the Cluster Synchronization Services (CSS). In previous versions of Oracle, it was just referred to as the “Cluster Manager.” When RAC was first introduced, cluster management was performed by third-party software, which is still supported by Oracle Database 10g.
FIGURE 9-9. Real Application-- conceptual architecture
The Global Cache Service controls data exchange between nodes using the Cache Fusiontechnology. Cache Fusion synchronizes the memory cache in each node using high-speed communications. This allows any node to access any data in the database.
Shared storage consists of data and index files, as well as control files.
This architecture makes RAC systems highly available. For example, if Node 2 in Figure 9-9 fails or requires maintenance, the remaining nodes will keep the database available.
This activity is transparent to the user or application and as long as at least one node is active, all data is available. RAC architecture also allows near-linear scalability and offers increased performance benefits. New nodes can easily be added to the cluster when needed to boost performance.
Administering and maintaining data files on both RAC and single-node systems have always required a good deal of effort, especially when data partitioning is involved. Oracle’s solution to reducing this effort is Automatic Storage Management, which we will discuss next.
CRITICAL SKILL 9.7
Automatic Storage Management: Another Primer
In previous versions of Oracle and with most other databases, management of data files for large databases consumes a good portion of the DBA’s time and effort. The number of data files in large databases can easily be in the hundreds or even thousands. The DBA must coordinate and provide names for these files and then optimize the storage location of files on the disks. The new Automatic Storage Management (ASM) feature in Oracle Database 10g Enterprise Edition addresses these issues.
ASM simplifies the management of disks and data files by creating logical groupings of disks into disk groups. The DBA need only refer to the groups, not the underlying data files. Data files are automatically named and distributed evenly (striped) throughout the disks in the group for optimal throughput. As disks are added or removed from the disk group, ASM redistributes the files among the available disks, automatically, while the database is still running. ASM can also mirror data for redundancy.
ASM Architecture
When ASM is implemented, each node in the database (clustered or nonclustered) has an ASM instance and a database instance, with a communication link between them. The ASM instance manages and works with the disk groups, and the database instance works with the data files. Figure 9-10 illustrates this architecture.
The following points address the key components in Figure 9-10:
The ASM instance manages the disk groups and ASM files. The names of the ASM files in each disk group are system generated. The ASM instance maintains a map of data files and disks.
The database instance accesses the ASM files directly, not the disk groups. In order to do this, the database instance must communicate with the ASM instance to request the names and locations of ASM data files required.
A database can contain both ASM and non-ASM files and the database instance can access either type. FIGURE 9-10.Automatic Storage Management
Ask the Expert
Q: After ASM disk groups are defined, how are they associated with a table?
A: ASM disk groups are referred to during tablespace creation, as in the following example:
This listing creates tablespace ts1 in disk group diskgrp1. Note that this assumes that both diskgrp1 and alias1 have previously been defined.
A table can now be created in tablespace ts1 and it will use ASM data files. While ASM can be implemented in a single-node environment, its real power and benefits are realized when used in RAC environments. This powerful combination is the heart of Oracle Database 10g’s grid computing database architecture.
CRITICAL SKILL 9.8
Grid Computing: The “g” in Oracle Database 10g
In this chapter, we have discussed many issues and demands surrounding large databases—performance, maintenance efforts, and so on. We have also discussed the solutions offered by Oracle Database 10g. Now we will have a high-level look at Oracle Database 10g’s grid-computing capabilities.
NOTE
Oracle Database 10g’s grid computing applies to both database and application layers. We will just be scratching the surface of grid computing and focusing on the database components.
The theory behind grid computing is that all parts of the grid (databases, applications, servers, disks, and so forth) work together in a highly integrated fashion, with each component being able to react appropriately to changes in other components in the grid. This results in efficient use of resources, faster response times, high availability, and so on.
The database components of Oracle Database 10g’s grid computing provide an infrastructure that brings together multiple servers (RAC) with shared storage (ASM), all tied together using the Oracle EnterpriseManager (OEM) Grid Control. Table 9-17 shows how grid computing addresses some of the issues facing large databases.
In order for grid computing to work, a software infrastructure layer needs to be in place to control the hardware and processes, as well as provide some automated maintenance capabilities. This is mainly the function of the OEM and is a core component of the grid. In addition, the Oracle Database 10g has the capability to perform some self-management.
Oracle 
/ 6 
