You Asked
hello Tom
what is the Difference between RAC (Real Application Clusters) and oracle 9i Database ? how there working is different, and if RAC and Database support each other in which manner do they support each other???
thanx
and Tom said...
RAC is a "configuration" of Oracle 9i, a "feature", a "capability"
Here is a short excerpt from my book Effective Oracle by Design on this:
<quote>
(2)How Does RAC Work?
A database may be mounted and opened by many instances simultaneously, and that is what RAC is all about. In order to understand how RAC works, we first need to clear up one of the more confusing topics in Oracle: the difference between an instance and a database.
(3)An Instance versus Database Refresher
An instance is simply the set of processes and memory used by these processes (the SGA). An Oracle instance does not need to have a database associated with it at all. You can start an instance without any datafiles whatsoever. An instance is not very useful in that mode, but you can have one.
A database is the set of filesredo, control, data, and temporary filesthat holds your data. A database has no processes or memory; it just has files.
Typically, an Oracle instance is started with the startup command, but Ill take you through the long way, so you can see when we have an instance and when we have an instance that has a database associated with it:
idle> startup nomount
ORACLE instance started.
Total System Global Area 303108296 bytes
Fixed Size 450760 bytes
Variable Size 134217728 bytes
Database Buffers 167772160 bytes
Redo Buffers 667648 bytes
idle>
So, here we have an Oracle instance. If you were to run ps at the operating-system level (or use the equivalent tool on Windows), you would see the Oracle processes are runningthe SGA is allocated. Everything is started, except for a database! In fact, there are even some queries we can run:
idle> select * from dual;
ADDR INDX INST_ID D
0A62D1C0 0 1 X
idle> select * from v$datafile;
select * from v$datafile
*
ERROR at line 1:
ORA-01507: database not mounted
So, DUAL is there (but it looks a tad strange, since it has extra columns), but not many other tables are available. For example, we do not have V$DATAFILE yet, because no datafiles are associated with this instance.
NOTE: This special DUAL table is there for applications that need DUAL but are expected to work against databases that are not yet opened, such as RMAN. As soon as you open the database, the regular DUAL reappears.
So, the Oracle instance is up and running, but has yet to associate itself to a set of files and make them accessible. Well do that now:
idle> alter database mount;
Database altered.
idle> select count(*) from v$datafile;
COUNT(*)
----------
23
idle> alter database open;
Database altered.
idle> @login
sys@ORA920>
And there we go. Now, the database is open and ready for access. The ALTER DATABASE MOUNT command used the control files (specified in the init.ora file) to locate the redo, data, and temporary files. The ALTER DATABASE OPEN command made the database available to anyone via this instance.
Note that an instance here is a transient thing. An instance is simple a set of processes and memory. Once you shut down that instance, it is gone forever. The database persists, but instances are fleeting. Another interesting thing to note is that an instance can mount and open at the most one database during its life. We can see this simply by issuing these commands:
sys@ORA920> alter database close;
Database altered.
sys@ORA920> alter database open;
alter database open
*
ERROR at line 1:
ORA01531: a database already open by the instance
sys@ORA920> !oerr ora 1531
01531, 00000, " a database already open by the instance"
// *Cause: During ALTER DATABASE, an attempt was made to open
// a database on an instance for which there is already
// an open database.
// *Action: If you wish to open a new database on the instance,
// first shutdown the instance and then startup the
// instance and retry the operation.
The reason this is interesting is that the converse is not true. As noted at the beginning of this section, a database may be mounted and opened by many instances simultaneously. The rules for databases and instances in Oracle are as follows:
An instance is transient. It exists only as long as the related set of processes and memory exists.
A database is persistent. It exists as long as the files exist.
An instance may mount and open a single database in its life.
A database may be mounted and opened by many instances, either one after the other or by many simultaneously (that is RAC).
(3)Instances in RAC
In an RAC environment, you run an instance of Oracle on each machine (also known as a node) in the cluster. Each of these instances mount and open the same database, since clusters share disks. It is important to keep in mind that there is only one database. Each Oracle instance has full read/write access to every byte of data in the database.
Each instance is a peer of every other instance in the cluster. You can update the EMP table from node 1. You can update the EMP table from node 2. In fact, you can update the record where ename = KING on both node 1 and node 2, following the same rules you would if you used only a single instance of Oracle. The same locking and concurrency control mechanisms you are familiar with on a single instance of Oracle with a single database hold true for Oracle running RAC.
Figure 10-4 shows what an RAC might look like with a four-node (four-computer) cluster. Each node would be running its own instance of Oracle (the processes/memory). There is a single database image shared by all nodes in the cluster, each having full read/write access to every byte of data in that database.
Figure 4: RAC with a four-node cluster
The basic premise behind Oracle RAC is that you run many instances of Oracle. Each instance is a stand-alone entitya peer of the other instances. There is no master instance, so there is no single point of failure. Each instance will mount and open the same databasethe same files. The instances will work together keeping their caches consistent with each other, to avoid overwriting changes made by other instances and to avoid reading old/stale information. If one of them fails for any reasondue to a hardware failure or a software failureone of the other remaining instances in the cluster will recover any work that the failed instance had in progress, and operations continue as before.
</quote>
Is this answer out of date? If it is, please let us know via a Comment