| Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2) Part Number B14197-02 |
|
|
View PDF |
| Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2) Part Number B14197-02 |
|
|
View PDF |
This chapter describes storage topics such as Automatic Storage Management (ASM). The topics in this chapter are:
Storage for RAC databases must be shared. In other words, datafiles must reside in an Automatic Storage Management (ASM) disk group, on a cluster file system, or on shared raw devices. This must include space for an undo tablespace for each instance if you are using automatic undo management. Additionally, for each instance you must create at least two redo log files that reside on shared storage. In addition, as Oracle recommends, you can use one shared server parameter file (SPFILE) with instance-specific entries. Or you can use a local file system to store client side parameter files (PFILEs).
Unless otherwise noted, Oracle storage features such as ASM, Oracle Managed Files (OMF), automatic segment-space management, and so on, function the same in RAC environments as they do in single-instance Oracle database environments. Refer to Oracle Database 2 Day DBA and the Oracle Database Administrator's Guide for additional information about these storage features.
If you do not use ASM, if your platform does not support a cluster file system, or if you do not want to use a cluster file system to store datafiles, then create additional raw devices as described in your platform-specific Oracle Real Application Clusters installation and configuration guide. However, Oracle recommends that you use ASM for datafile storage which is described later in this chapter in the section titled "Automatic Storage Management in Real Application Clusters". The remainder of this section describes the following topics:
|
Note: To create a RAC database using the Oracle Database 10g Standard Edition, you must use ASM for your datafile storage. |
All RAC instances must be able to access all datafiles. If a datafile needs to be recovered when the database is opened, then the first RAC instance to start is the instance that performs the recovery and verifies access to the file. As other instances start, they also verify their access to the datafiles. Similarly, when you add a tablespace or datafile or bring a tablespace or datafile online, all instances verify access to the file or files.
If you add a datafile to a disk that other instances cannot access, then verification fails. Verification also fails if instances access different copies of the same datafile. If verification fails for any instance, then diagnose and fix the problem. Then run the ALTER SYSTEM CHECK DATAFILES statement on each instance to verify datafile access.
Each instance has its own online redo log groups which are referred to as an instance's thread of online redo. Create these online redo log groups and establish group members as described in the Oracle Database Administrator's Guide.
Each instance must have at least two groups of online redo log files in its thread. When the current group fills, an instance begins writing to the next log file group. If your database is in ARCHIVELOG mode, then each instance must save filled log files into its own archive log thread and update the control file with the status of its thread.
Oracle automatically manages undo segments within a specific undo tablespace that is assigned to an instance. Only the instance assigned to the undo tablespace can modify the contents of that tablespace. However, all instances can always read all undo blocks throughout the cluster environment for consistent read purposes. Also, any instance can update any undo tablespace during transaction recovery, as long as that undo tablespace is not currently used by another instance for undo generation or transaction recovery. You assign undo tablespaces in your RAC database by specifying a different value for the UNDO_TABLESPACE parameter for each instance in your SPFILE or individual PFILEs. You cannot simultaneously use automatic undo management and manual undo management in a RAC database. In other words, all instances of a RAC database must operate in the same undo mode.
|
See Also: Oracle Database Administrator's Guide for detailed information about creating and managing undo tablespaces |
ASM automatically optimizes storage to maximize performance by managing the storage configuration across the disks that ASM manages. ASM does this by evenly distributing the storage load across all of the available storage within your cluster database environment. ASM partitions your total disk space requirements into uniformly sized units across all disks in a disk group. ASM can also automatically mirror data to prevent data loss. Because of these features, ASM also significantly reduces your administrative overhead.
To use ASM in RAC, select ASM as your storage option when you create your database with the Database Configuration Assistant (DBCA). As in single-instance Oracle databases, using ASM in RAC does not require I/O tuning. The following topics describe ASM and ASM administration as follows:
When you create your database, Oracle creates one ASM instance on each node in your RAC environment if one does not already exist. Each ASM instance has either an SPFILE or PFILE type parameter file. You may need to back up the parameter files and the TNS entries for nondefault Oracle Net Listeners.
When you create a disk group for a cluster or add new disks to an existing clustered disk group, you only need to prepare the underlying physical storage on shared disks. The shared disk requirement is the only substantial difference between using ASM in a RAC database compared to using it in a single-instance Oracle database. ASM automatically rebalances the storage load after you add or delete a disk or disk group.
In a cluster, each ASM instance manages its node's metadata updates to the disk groups. In addition, each ASM instance coordinates disk group metadata with other nodes in the cluster. As in single-instance Oracle databases, you can use Enterprise Manager, the DBCA, SQL*Plus, and the Server Control Utility (SRVCTL) to administer disk groups for ASM in RAC. The Oracle Database Administrator's Guide explains how to use SQL*Plus to administer ASM instances. The following sections describe how to use the other tools.
When you create a database using the DBCA and you select the ASM storage option, the DBCA creates the ASM instances for you if they do not already exist. However, you can also use the standalone ASM disk group management feature to create and manage an ASM instance and its associated disk groups independently of creating a new database. You can use Enterprise Manager or the DBCA to add disks to a disk group, to mount a disk group or to mount all of the disk groups, or to create ASM instances. Additionally, you can use Enterprise Manager to dismount and drop disk groups or to delete ASM instances.
To create an ASM instance without creating a database with the DBCA, select the Configure Automatic Storage Management option on the DBCA Database Options page. You can also use this option to add or mount one or more ASM disk groups. The DBCA then displays the Node Selection page on which you can identify the nodes on which you want to create the ASM instance or on which you want to manage disk groups. If necessary, the next page you must complete is the DCBA Create Instance Page on which you add the information about the ASM instance parameter file and SYS password and, for Windows-based systems, the owner of the ASM-related service.
The DBCA session provides the same ASM Disk Groups page for standalone ASM management as it does for database creation using ASM storage. Use this page to create new disk groups, to add disks to existing disk groups, or to mount disk groups that are not currently mounted. You can also use the standalone ASM feature, where you have the ability to manage ASM instances independent of the database, in DBCA silent mode to create an ASM instance or to manage ASM disk groups. The syntax for the DBCA silent mode command is:
dbca -silent -nodeList nodelist -configureASM -asmPassword asm_pwd [-diskList disk_list] [-redundancy redundancy_option] [-diskGroupName dgname] [-diskString disk_discovery_string] [-recoveryGroupName recovery_dgname] [-recoveryRedundancy redundancy_option]
Where:
nodelist is a comma-delimited list of nodes and these are the nodes on which you want to perform the ASM activities
asm_pwd is the password for the SYS account in the ASM instance
disk_list is a comma-delimited list of disks to be added to disk group
redundancy_option is NORMAL, HIGH, or EXTERNAL
dgname is either the name of an existing disk group, in which case the disk group is mounted on all of the selected nodes, or dgname is the name of a new disk group, in which case the disk group is created and started on all of the selected nodes
disk_recovery_string identifies the location or identifier for the ASM-ready disks
recovery_dgname is the name for a recovery disk group
You can perform administrative operations on ASM disk groups with Enterprise Manager such as adding and deleting them. You can also monitor ASM disk group performance as well as control disk group availability at the instance level. For example, some of the RAC-specific ASM-related Enterprise Manager tasks that you can perform are:
When you add a disk group, the disk group definition includes a checkbox to indicate whether the disk group is automatically mounted to all of the cluster database instances.
The default Disk Group Performance page displays instance-level performance details when you click a performance characteristic such as Write Response Time or I/O Throughput.
When you mount and dismount ASM disk groups, you can use a checkbox to indicate which instances should mount or dismount a particular ASM Disk Group.
|
See Also: Oracle Database Administrator's Guide and Oracle Database 2 Day DBA for detailed information about using Enterprise Manager |
You can use the Server Control Utility (SRVCTL) to add, remove, enable, and disable an ASM instance as described in the following procedures:
Use the following syntax to add configuration information about an existing ASM instance:
srvctl add asm -n node_name -i asm_instance_name -o oracle_home
|
Note: For all of the SRVCTL commands in this section for which the-i option is not required, if you do not specify an instance name, then the command applies to all of the ASM instances on the node. |
Use the following syntax to remove an ASM instance:
srvctl remove asm -n node_name [-i asm_instance_name]
Use the following syntax to enable an ASM instance:
srvctl enable asm -n node_name [-i ] asm_instance_name
Use the following syntax to disable an ASM instance:
srvctl disable asm -n node_name [-i asm_instance_name]
You can also use SRVCTL to start, stop, and obtain the status of an ASM instance as in the following examples.
Use the following syntax to start an ASM instance:
srvctl start asm -n node_name [-i asm_instance_name] [-o start_options] [-c <connect_str> | -q]
Use the following syntax to stop an ASM instance:
srvctl stop asm -n node_name [-i asm_instance_name] [-o stop_options] [-c <connect_str> | -q]
Use the following syntax to show the configuration of an ASM instance:
srvctl config asm -n node_name
Use the following syntax to obtain the status of an ASM instance:
srvctl status asm -n node_name
