3.5 Dynamic components

 < Day Day Up > 



It is now possible to dynamically reconfigure the sizes of the shared pool, buffer cache, Java pool, and the large pool. During the dynamic reconfiguration of the size of the SGA, memory is allocated in units called granules. Basically, granules are a unit of allocation used during dynamic reconfiguration of the SGA.

A granule can be 4 MB or 16 MB, depending on the total size of the SGA determined during instance startup. If the size of the SGA is less than 12 MB, the granules are allocated in 4 MB sizes; otherwise they are allocated in 16 MB chunks. The values for the various memory areas are allocated as a multiple of a granule size. If, on instance startup, Oracle determines that the size mentioned is not a multiple of the granule size, Oracle will round the value to the nearest multiple. For example, if the granule size is 16 MB and the DB_CACHE_SIZE allocated is 46 MB, then, Oracle will change the value to 48 MB during instance startup.

Oracle keeps information about the components and their granules in a scoreboard. For each component that owns granules, the scoreboard contains the number of granules allocated to the component, any pending operations against this component, the target size in granules, and the progress made toward the target size. The start time of the operation is also logged. Oracle maintains the initial number of granules and the maximum number of granules for each component.

For operations that modify the number of granules, Oracle logs the operation, the target size, and the start time to the appropriate SGA component in the scoreboard. Oracle updates the progress field until the operation is complete at which time Oracle replaces the current size with the target size and clears the target size field and the progress field. At the end of the operation, a database administrator can see how the number of granules was changed. Oracle updates the initialization parameter values to reflect the updated amount of SGA in use.

Oracle maintains a circular buffer of the last 100 operations made to the scoreboard. Fixed views show the state of the scoreboard and the current contents of the last 100 operations to the scoreboard.

A database administrator grows a component's SGA use with ALTER SYSTEM statements to modify the initialization parameter values. Oracle takes the new size, rounds it up to the nearest multiple of 16 MB and adds or takes away granules to meet the target size. Oracle must have enough free granules to satisfy the request. If the current amount of SGA memory is less than SGA_MAX_SIZE, Oracle can allocate more granules until the SGA size reaches SGA_MAX_SIZE.

3.5.1 Oracle database configuration

As discussed above, Oracle RDBMS configuration consists of foreground and background processes that aid in accepting the user process to move data from various areas of Oracle's memory into the physical database. A basic configuration of Oracle RDBMS consists of a single instance (also called stand-alone instance) with a single copy of the database. In the sections above we have looked at the various background (Figure 3.6) and foreground processes that constitute the single instance configuration.

In a configuration of this type, where there is only one database and a corresponding instance to support, the instance and the database are identified by the same name. Users accessing the system will make a connection to an instance and, with the help of the background and foreground processes, retrieve and manipulate data in the database.

A single node or system could contain more than one instance; in fact, there are no limits to the number of instances that a single node could hold. It is more of a practical performance limitation to have many instances of Oracle on a single node rather than a physical limitation. Figure 3.10 illustrates how multiple instances can be housed in a single node (node A) and attached to two separate physical databases.


Figure 3.10: One node/ instance accessing one database.

3.5.2 Oracle clustered configuration

Oracle's clustered, or multi-instance, configurations comprise multiple nodes working as a cohesive unit with each node in the cluster consisting of one or more instances talking to a common shared database.

RAC is a configuration where two or more instances are connected to one single shared physical database and users access the database from any of the available instances to retrieve and process data. Unlike the data guard and advanced replication features, the RAC provides availability with data consistency. Because there is no data being transferred between databases, there is only one physical copy of the database, and only one database is shared by multiple instances.

Oracle's clustered, or multi-instance, configuration is an extension to the single, stand-alone instance configuration. Under this configuration, each instance has its own set of background and foreground processes. These background and foreground processes on each instance talk to one common shared database. Under the multi-instance configuration, the instance and the database do not have the same name or are not identified by the same name. Because there are multiple instances, each instance needs to be uniquely identified. The database that is common has its own identity.

Figure 3.11 illustrates a clustered database configuration, where two nodes, Node 1 and Node 2, containing instance 1 and instance 2 respectively, connect to a common shared Oracle 9i database. Users are connected to both instances and can perform database operations.

click to expand
Figure 3.11: Multiple instance/clus tered database configuration.

Having a single, common, shared physical database means that all instances sharing the common database access the same set of data files and control files. This also implies that multiple instances could be requesting the same information.

However, because there are multiple instances accessing the shared database, the instance-specific information, such as the rollback information, redo logs, and archive logs, are maintained uniquely for a specific instance. However, because these files are stored on a shared disk array, they are visible to the other instances. Visibility to these files is critical, especially when a system or instance fails. By having these files on a common shared device, the instance that noticed the failure first would read these files for recovery of failed instance.

Oracle 9i 

New Feature: With the introduction of new data transfer architecture called cache fusion, Oracle has renamed OPS to RAC.

In the next section some of the changes between the two versions of the clustered database will be examined.

Table 3.2 provides the difference between a single instance stand-alone configuration and a clustered database configuration.

Table 3.2: Single Instance vs. Clustered Configuration

Single Instance

Real Application Cluster

One instance maps to a single database

Two or more instances share a common physical database

Can run on a single processor hardware configuration or a multi- processor configuration. However, requires only a single node or machine for implementation

Can also run on a single processor hardware configuration or a multi- processor configuration. However, requires hardware clustering and a clustered operating system

Consists of one system global area (SGA) and a set of background and foreground processes

Every instance requires its own SGA (to store instance-specific information), and background and foreground processes. It also consists of additional background processes like LMS and GCS

One copy of the physical database and redo log files

Separate copies of redo logs and archive logs are maintained for every instance

With just one instance attached to one copy of the physical database, no instance level synchronization is required

Multinode synchronization is required. Synchronization between instances is performed using the cache fusion technology via the cluster interconnect

V$ views to monitor and manage instance

V$ views are available and provide visibility to a single instance. For monitoring at the cluster level, Oracle provides GV$ views

Meeting some of the business require- ments (availability, scalability) is limited to a single instance configuration

Modern business requirements of high availability and linear scalability are provided by multiple instances sharing a common physical database



 < Day Day Up > 



Oracle Real Application Clusters
Oracle Real Application Clusters
ISBN: 1555582885
EAN: 2147483647
Year: 2004
Pages: 174

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net