Using Enterprise Manager to help you manage your ASM environment is most likely the simplest way to keep on top of the situation. In order to do so, we recommend that you configure Enterprise Manager Grid Control (as described in Chapter 5). This is a particular necessity when running in a RAC environment, as Grid Control allows you to manage all instances in the cluster, as well as all ASM instances from one central location.Navigating Through EM
Enterprise Manager provides a graphical interface for such ASM operations as adding or removing disks from a disk group, dropping and creating new disk groups, mounting and dismounting disk groups, and rebalancing within a disk group. While you cannot create the instance itself through EM, you can modify parameters such as ASM_DISKSTRING or ASM_POWER_LIMT. Additionally, while we mentioned that files in an ASM disk group are not visible at the OS, Enterprise Manager will allow you to look at the file and directory structure used by ASM to manage these files. To end this section, we will go through a HA Workshop that will walk you through the steps needed to navigate ASM through Enterprise Manager.
-------HA Workshop: Managing ASM Through Enterprise Manager
This workshop assumes that Enterprise Manager Grid Control has already been configured in your environment, and also assumes that an ASM instance is running. If EM Grid Control has not been configured, please refer to Chapter 5 for an overview of Grid Control configuration, or refer to the Oracle Database 10g Release 1 Oracle Enterprise Manager Advanced Configuration guide.
Step 1. Log on as SYSMAN to the Enterprise Manager Grid Control screen using the host name of the management repository machine, and port 7777. In this example, rmsclnxclu1 is a node in our cluster, but it also happens to be the host for the EM management repository:
Step 2. Click on the Targets tab across the top, and then choose All Targets from the blue bar. This will list all instances, including ASM instances.
Step 3. Find the ASM instance from the list of targets. The name will be something along the lines of +ASM1_rmsclnxclu1.us .oracle.com, where rmsclnxclu1.us .oracle.com is the host name where the ASM instance is running. Click on the link to the ASM instance. This will bring you to the home page for the ASM instance. Here, you can see a list of disk groups, the databases serviced by the disk groups, and a graphical depiction of the amount of disk space each database is using. In addition, you will see any alerts related to your ASM instance.
Step 4. Click on the Performance link for the ASM instance. (You may be prompted to log in—if so, provide the sysdba password for the ASM instance.) Here you will see a graphical depiction of the throughput, disk I/O per second, and disk I/O response times for all disk groups managed by ASM. Clicking on the Expand All option at the bottom of the page will allow you to see the cumulative statistics for each disk in the disk group.
Step 5. Next click on the Configuration link across the top. Here you can modify the values for the ASM_DISKSTRING, ASM_DISKGROUPS, and ASM_POWER_ LIMITS parameters.
Step 6. Now click on the Administration link. This will provide you a link to each ASM disk group managed by the ASM instance, as shown in Figure 3-7. If there are no disk groups, you can create them from here, or create additional groups by clicking on the Create button. Disk groups can also be mounted or dismounted from here—if you are in a RAC environment, you will be prompted to select which instances you want to dismount the group from. By selecting the options from the drop-down list, you can initiate an immediate rebalance operation as well, as shown in Figure 3-7.
Step 7. Click on the disk group itself now, to again see the disks in the group. This will take you into the General description page for that disk group.
FIGURE 3-7. ASM disk groups in Enterprise Manager
Here you can check the disks’ integrity, add disks to the disk group, or delete disks from the group. You can also drill down further to see performance stats for the individual disks.
Step 8. Next click on the Files link to view the files on the ASM disk group. Choose the Expand All option to view all the files within all of the ASM directories. In Figure 3-8, we have displayed a partial expansion of the directory list. As you can see, Oracle creates a directory structure within the ASM disk group, which it maintains internally. In this example, Oracle managed files are in use, meaning that the parameter DB_CREATE_FILE_DEST is set to +ASM_DISK. Oracle automatically created an ASM directory with the database name, and then within that directory
FIGURE 3-8. Viewing ASM files from within Enterprise Manager
created additional subdirectories for controlfiles, logfiles, datafiles, and so forth. When using Oracle managed files, it is not necessary to specify either the name or the location of the file. Oracle will determine the location based on the ASM file type, and will then assign a filename based on the type of file, the file number, and the version number.
Step 9. Lastly, click on a single file to get a description of how the file is mirrored, the block size and number of blocks in the file, the file type, the creation date, and the striping (either coarse or fine). The output should look something like this:
Block Size (bytes) 8192
Logical Size (KB) 512008 KB
Creation Date 15-FEB-2004 02:43:32
As we have discussed, an ASM instance has no physical storage component associated with it—the ASM instance is purely a logical incarnation, in memory. However, there are physical components to an ASM disk group, essentially stored on disk on each ASM disk. When a disk is made part of an ASM disk group, the header of each disk is updated to reflect information, including the disk group name, the physical size of all disks in the group, the allocation unit size, and so on. The header also contains information relating specifically to that disk, including the size, the failure group, the disk name, and so forth. In addition, metadata is stored in ASM files on the disks themselves, using file numbers below 256. For this reason, when creating a new database on an ASM disk group, the system datafile will generally be file 256, and the rest of the files in the database are numbered upward from there—because file 255 and below are reserved for ASM metadata. The ASM metadata is always mirrored across three disks (if available), even when the external redundancy option is chosen.