ASM ACFS
1. Get CPU information -
cat /proc/cpuinfo
cat /proc/meminfo
dmesg
lspci
2. To determine connect ORACLEASM Package
uname -rm
3. Download Oracle ASM package
4. use below command to update it directly from Linux server
update2date -i oracleasm-support oracleasmlib oracleasm-u'uname -r'
5. Install ASM package -
rpm -Uvh oracleasm-support-version.arch.rom \
oracleasm-kernel-version.arch.rpm \
oracleasmlib-version.arch.rpm
6. Configure ASM LIB -
/usr/sbin/oracleasm configure -i
(To check current configuration- /usr/sbin/oracleasm configure)
7. Mark ASM disk Partition -
/usr/sbin/oracleasm createdisk ASM_DISK_NAME candidate_disk
8. Make ASM disks available to the other cluster nodes -
/usr/sbin/oracleasm scandisks
====================
Installing Oracle ASMLib
ASMLib is a support library for the Automatic Storage Management feature of the Oracle Database. This document is a set of tips for installing the library and its supporting driver. The complete installation guide is part of the Oracle Database Documentation .
Installing ASMLib - This document describes the steps required to install the Linux specific ASM library and its associated driver. This library is provided to enable ASM I/O to Linux disks without the limitations of the standard Unix I/O API. The steps below are steps that the system administrator must follow.
Locating the ASMLib Packages - The ASMLib software must first be installed. The easiest way is via the Unbreakable Linux Network. For other environments, please download ASMLib from OTN.
Once the ASMLib software is installed, you are ready to configure it.
Configuring ASMLib - Now that the ASMLib software is installed, a few steps have to be taken by the system administrator to make the ASM driver available. The ASM driver needs to be loaded, and the driver filesystem needs to be mounted. This is taken care of by the initialization script, /etc/init.d/oracleasm.
Run the /etc/init.d/oracleasm script with the 'configure' option. It will ask for the user and group that default to owning the ASM driver access point. If the database was running as the 'oracle' user and the 'dba' group, the output would look like this:
[root@ca-test1 /]# /etc/init.d/oracleasm configure
Configuring the Oracle ASM library driver.
This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets ('[]'). Hitting without typing an
answer will keep that current value. Ctrl-C will abort.
Default user to own the driver interface []: oracle
Default group to own the driver interface []: dba
Start Oracle ASM library driver on boot (y/n) [n]: y
Fix permissions of Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration [ OK ]
Creating /dev/oracleasm mount point [ OK ]
Loading module "oracleasm" [ OK ]
Mounting ASMlib driver filesystem [ OK ]
Scanning system for ASM disks [ OK ]
This should load the oracleasm.o driver module and mount the ASM driver filesystem. By selecting enabled = 'y' during the configuration, the system will always load the module and mount the filesystem on boot. The automatic start can be enabled or disabled with the 'enable' and 'disable' options to/etc/init.d/oracleasm:
[root@ca-test1 /]# /etc/init.d/oracleasm disable
Writing Oracle ASM library driver configuration [ OK ]
Unmounting ASMlib driver filesystem [ OK ]
Unloading module "oracleasm" [ OK ]
[root@ca-test1 /]# /etc/init.d/oracleasm enable
Writing Oracle ASM library driver configuration [ OK ]
Loading module "oracleasm" [ OK ]
Mounting ASMlib driver filesystem [ OK ]
Scanning system for ASM disks [ OK ]
| Making Disks Available to ASMLib | |
| The system administrator has one last task. Every disk that ASMLib is going to be accessing needs to be made available. This is accomplished by creating an ASM disk. The/etc/init.d/oracleasm script is again used for this task: [root@ca-test1 /]# /etc/init.d/oracleasm createdisk VOL1 /dev/sdg1 Creating Oracle ASM disk "VOL1" [ OK ] Disk names are ASCII capital letters, numbers, and underscores. They must start with a letter. Disks that are no longer used by ASM can be unmarked as well: [root@ca-test1 /]# /etc/init.d/oracleasm deletedisk VOL1 Deleting Oracle ASM disk "VOL1" [ OK ] Any operating system disk can be queried to see if it is used by ASM: [root@ca-test1 /]# /etc/init.d/oracleasm querydisk /dev/sdg1 Checking if device "/dev/sdg1" is an Oracle ASM disk [ OK ] [root@ca-test1 /]# /etc/init.d/oracleasm querydisk /dev/sdh1 Checking if device "/dev/sdh1" is an Oracle ASM disk [FAILED] Existing disks can be listed and queried: [root@ca-test1 /]# /etc/init.d/oracleasm listdisks VOL1 VOL2 VOL3 [root@ca-test1 /]# /etc/init.d/oracleasm querydisk VOL1 Checking for ASM disk "VOL1" [ OK ] When a disk is added to a RAC setup, the other nodes need to be notified about it. Run the 'createdisk' command on one node, and then run 'scandisks' on every other node: [root@ca-test1 /]# /etc/init.d/oracleasm scandisks Scanning system for ASM disks [ OK ] | |
Discovery Strings for Linux ASMLib
ASMLib uses discovery strings to determine what disks ASM is asking for. The generic Linux ASMLib uses glob strings. The string must be prefixed with "ORCL:". Disks are specified by name. A disk created with the name "VOL1" can be discovered in ASM via the discovery string "ORCL:VOL1". Similarly, all disks that start with the string "VOL" can be queried with the discovery string "ORCL:VOL*".
Disks cannot be discovered with path names in the discovery string. If the prefix is missing, the generic Linux ASMLib will ignore the discovery string completely, expecting that it is intended for a different ASMLib. The only exception is the empty string ( ""), which is considered a full wildcard. This is precisely equivalent to the discovery string "ORCL:*".
oracleasm config file
ASMLib uses configuration file /etc/sysconfig/oracleasm, which is a link to file /etc/sysconfig/oracleasm-_dev_oracleasm. Tools read file /etc/sysconfig/oracleasm-_dev_oracleasm so make sure that it's link from /etc/sysconfig/oracleasm is not broken. User should run /usr/sbin/oracleasm configure -I to modify configuration parameters
====================
Configuring Oracle ASMLib on Multipath Disks
This document describes the steps required to configure the Linux specific ASM library provided by Oracle (herin "ASMLib") to access multipath disks. It assumes that the multipath disks are already configured with whatever tools are provided by the storage. This document gives multipath disks the name " multipatha", so as to be storage vendor agnostic.
Issues Involving Multipath Disks
There are two issues with using multipath disks in ASM. ASM cannot handle seeing the same disk twice. If it does, it will cause an error. A single disk can appear three times in a multipath configuration:
The first path to the disk
The second path to the disk
The multipath access point
Here's an example: say a system has one local disk, /dev/sda, and one disk attached via external storage. The machine has two connections, or paths, to that external storage. The Linux SCSI driver will see both paths. They will appear as /dev/sdb and /dev/sdc. The system may access sdb or sdc, the access ends up in the same place.
If multipathing is enabled, there will be a multipath disk, for example /dev/multipatha, that can access both paths. That is, any I/O to multipatha can use either path. If a system were using the sdb path, and that cable is unplugged, the system will get an error. But the multipath disk will know to switch to the sdc path.
Most system software will be unaware of the multipath configuration. It can use any of the paths, sdb, sdc, or multipatha, and it won't know the difference. ASMLib is the same way. The default configuration does not care which path it uses.
ASMLib will choose only one of the paths, because ASM cannot handle seeing the same disk twice. This solves the first issue. ASM only sees one path, and it is happy. Here is the second issue: which path does ASM see? In its default configuration, ASMLib will choose the first path it finds. This is the first path as reported by Linux. Depending on your storage driver, it could be the multipath, or it could be one of the single paths.
The system administrator wants ASMLib to always use the multipath disk. What's the point of having it if Oracle is not using it? There is no way, however, for ASMLib to know what a multipath looks like. It must be told via its configuration.
Disk Scan Ordering
Disks are marked for ASMLib using a process described in ASMLib Installation. ASMLib learns what disk are marked during a process called disk scanning. ASMLib runs this scan every time it starts up. The system administrator can also force a scan via the /etc/init.d/oracleasm scandisks command.
ASMLib examines each disk in the system. It checks if the disk has been marked for ASMLib. Any disk that has been marked will be made available to ASMLib. Normally, ASMLib checks each disk in the exact order the OS lists them. This is fine for most systems.
In the last section, we described a case where the OS order isn't good enough. The system administrator wants ASMLib to see multipath disks before it sees single path disks. This allows ASMLib to choose the multipath disk and make it available to Oracle.
ASMLib allows two modifications to the disk scan order. First, it allows exclusion of certain disks. In other words, ASMLib will ignore those disks completely. Second, the system administrator can specify disks that are to be scanned first. Disks in this list are scanned before the rest of the disks in the system.
A multipath configuration can use either facility. The system administrator could choose to exclude all the single path disks. ASMLib will then ignore them, only scanning the multipath disks. Conversely, the administrator could specify that the multipath disks are scanned first. ASMLib will see them first, and prefer them over the single paths.
Configuring the Scan Order
The Oracle ASMLib configuration file is located at /etc/sysconfig/oracleasm. It is a link to file /etc/sysconfig/oracleasm-_dev_oracleasm and tools actually read the later file. It contains all the startup configuration that the system administrator specified via the /etc/init.d/oracleasm configure command. That command cannot configure scan ordering.
The configuration file contains many configuration variables. The ORACLEASM_SCANORDER variable specifies disks to be scanned first. The ORACLEASM_SCANEXCLUDE variable specifies the disks that are to be ignored.
The variables take a whitespace-seperated list of prefix strings to match. In other words, if a disk starts with one of the prefix strings, it matches. For example, the prefix string sd will match all SCSI devices. The disk sda starts with sd. Note that these are not globs. They do not use wildcards. They are simple prefixes. Also note that the /dev/ path is not part of the prefix.
NOTE: When scanning, only the device names known by the kernel are scanned. With device-mapper, the kernel sees the devices as /dev/dm-XX. The /dev/mapper/XXX names are created by udev for human readability. Any configuration of ORACLEASM_SCANORDER or ORACLEASM_SCANEXCLUDE must use the dm prefix.
A couple examples:
NOTE: If you are hand editing file /etc/sysconfig/oracleasm, make sure the link to /etc/sysconfig/oracleasm-_dev_oracleasm is not broken.
Multipath Disks First
The system administrator configures ASMLib to scan the multipath disks first. In the ASMLib configuration file she edits the ORACLEASM_SCANORDER variable to look like so:
ORACLEASM_SCANORDER="multipath sd"
During a scan, ASMLib first tries all disks that start with "multipath". The multipath device /dev/multipatha certainly matches. It is scanned first. Next, ASMLib tries all disks that start with "sd". This is all the SCSI disks. The local disk /dev/sda will be scanned, but it is not an ASM disk. The single path disks /dev/sdb and /dev/sdc are also scanned. They are ASM disks, but ASMLib will see that it already has a path to that disk. It will ignore them. Finally, ASMLib will scan any other disks that did not match either prefix.
Excluding Single Path Disks
The system administrator configures ASMLib to ignore the single path disks. In the ASMLib configuration, he edits the ORACLEASM_SCANEXCLUDE variable to look like so:
ORACLEASM_SCANEXCLUDE="sdb sdc"
Here, the system administrator has been more specific. ASMLib should ignore exactly the disks /dev/sdb and /dev/sdc. It should not ignore other SCSI disks. While scanning, ASMLib will ignore those paths, only seeing the /dev/multipath disk. Once again, Oracle will use the multipath disk.
EMC PowerPath and ASMLib
A lot of administrators want to use EMC PowerPath for multipathing and ASMLib for disk access.
However, PowerPath and the 2.4 kernels are not supported by EMC. Systems with the Linux 2.6 kernel, such as RHEL 4 or SLES 9, and the 2.0 ASMLib kernel driver are supported. Please reference the EMC Support Matrix to verify that any/all interoperability requirements are met.
If you have ANY issue related to support for ASMLib and PowerPath on systems using the Linux 2.4 kernel, such as RHEL 3 or SLES 8, please contact EMC.
=====================================================================================================================================
- Query the V$ASM_DISKGROUP and V$ASM_DISK views.
After a disk is successfully discovered, it appears in the V$ASM_DISK view. Disks that belong to a disk group—that is, that have a disk group name in the disk header—have a header status of MEMBER. Disks that were discovered but that have not yet been assigned to a disk group have a header status of either CANDIDATE or PROVISIONED.
Note:
The PROVISIONED header status implies that an additional platform-specific action has been taken by an administrator to make the disk available for ASM. For example, on Windows, the administrator used asmtool or asmtoolg to stamp the disk with a header, or on Linux, the administrator used ASMLib to prepare the disk for ASM.
The following query shows six MEMBER disks and one CANDIDATE disk.
>SQL> select name, header_status, path from v$asm_disk;NAME HEADER_STATUS PATHCANDIDATE /dev/rdsk/disk07------------ ------------- -------------------------DISK05 MEMBER /dev/rdsk/disk05DISK06 MEMBER /dev/rdsk/disk06 DISK04 MEMBER /dev/rdsk/disk04DISK01 MEMBER /dev/rdsk/disk01DISK03 MEMBER /dev/rdsk/disk03 DISK02 MEMBER /dev/rdsk/disk027 rows selected.<
For a drop operation, when rebalance is complete, ASM takes the disk offline momentarily, and then drops it, setting disk header status to FORMER.
You can add or drop disks without shutting down the database. However, a performance impact on I/O activity may result.
The REQUIRED_MIRROR_FREE_MB column shows that 1 GB of extra capacity must be available to restore full redundancy after one or more disks fail. Note that the first three numeric columns in the query results are raw numbers. That is, they do not take redundancy into account. Only the last column is adjusted for normal redundancy. Notice that:The following query shows capacity metrics for a normal redundancy disk group that consists of six 1 GB (1024 MB) disks, each in its own failure group:select name, type, total_mb, free_mb, required_mirror_free_mb, usable_file_mb from v$asm_diskgroup;------------ ------ ---------- ---------- ----------------------- --------------NAME TYPE TOTAL_MB FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MBDISKGROUP1 NORMAL 6144 3768 1024 1372
Negative Values of USABLE_FILE_MB Due to the relationship between FREE_MB, REQUIRED_MIRROR_FREE_MB, and USABLE_FILE_MB, USABLE_FILE_MB can go negative. Although this is not necessarily a critical situation, it does mean that:FREE_MB - REQUIRED_MIRROR_FREE_MB = 2 * USABLE_FILE_MBor 3768 - 1024 = 2 * 1372 = 2744
- Depending on the value of FREE_MB, you may not be able to create new files.
- The next failure may result in files with reduced redundancy.
On a server that runs Unix, Solaris, or Linux and that does not have ASMLib installed, issuing the following statement would successfully add disks /devices/diska5 through /devices/diska8 to dgroup1.Adding Disks to a Disk Group: Example 2 </span>The statements presented in this example demonstrate the interactions of disk discovery with the ADD DISK operation.Assume that disk discovery now identifies the following disks in directory /devices -- member of dgroup1 /devices/diska2 -- member of dgroup1/devices/diska7 -- candidate disk/devices/diska3 -- member of dgroup1 /devices/diska4 -- member of dgroup1 /devices/diska5 -- candidate disk /devices/diska6 -- candidate disk /devices/diska8 -- candidate disk
The following statement would successfully add disks /devices/diska5 and /devices/diskd5 to dgroup1.ALTER DISKGROUP dgroup1 ADD DISK'/devices/diska5';
The following statement would fail because /devices/diska1 - /devices/diska4 already belong to dgroup1.ALTER DISKGROUP dgroup1 ADD DISK'/devices/disk*5';
The following statement would fail because the search string matches disks that are contained in other disk groups. Specifically, /devices/diska4 belongs to disk group dgroup1and /devices/diskb4 belongs to disk groupdgroup2.ALTER DISKGROUP dgroup1 ADD DISK'/devices/diska*';
The following statement would successfully add /devices/diska5 and /devices/diskd1 through /devices/diskd8 to disk group dgroup1. It does not matter that /devices/diskd5 is included in both search strings. This statement runs with a rebalance power of 5, and does not return until the rebalance operation is complete.ALTER DISKGROUP dgroup1 ADD DISK'/devices/disk*4';
The following use of the FORCE clause enables /devices/diskc3 to be added to dgroup2, even though it is a current member of dgroup3.ALTER DISKGROUP dgroup1 ADD DISK'/devices/disk*5',REBALANCE POWER 5 WAIT;'/devices/diskd*'
For this statement to succeed, dgroup3 cannot be mounted.ALTER DISKGROUP dgroup2 ADD DISK'/devices/diskc3' FORCE;
Dropping Disks from Disk Groups -
To drop disks from a disk group, use the DROP DISK clause of the ALTER DISKGROUP statement. You can also drop all of the disks in specified failure groups using the DROP DISKS IN FAILGROUP clause.
When a disk is dropped, the disk group is rebalanced by moving all of the file extents from the dropped disk to other disks in the disk group. A drop disk operation may fail if not enough space is available on the other disks. If you intend to add some disks and drop others, it is prudent to add disks first to ensure that enough space is available for the drop operation. The best approach is to perform both the add and drop with the same ALTER DISKGROUPstatement. This can reduce total time spent rebalancing.
WARNING:
The ALTER DISKGROUP...DROP DISK statement returns before the drop and rebalance operations are complete. Do not reuse, remove, or disconnect the dropped disk until theHEADER_STATUS column for this disk in the V$ASM_DISK view changes to FORMER. You can query the V$ASM_OPERATION view to determine the amount of time remaining for the drop/rebalance operation to complete. For more information, see Oracle Database SQL Reference and Oracle Database Reference.
If you specify the FORCE clause for the drop operation, the disk is dropped even if Automatic Storage Management cannot read or write to the disk. You cannot use the FORCEflag when dropping a disk from an external redundancy disk group.
Caution:
A DROP FORCE operation leaves data at reduced redundancy for as long as it takes for the subsequent rebalance operation to complete. This increases your exposure to data loss if there is a subsequent disk failure during rebalancing. DROP FORCE should be used only with great care.
Dropping Disks from Disk Groups: Example 1 This example drops diska5 (the operating system independent name assigned to /devices/diska5 in "Adding Disks to a Disk Group: Example 1") from disk group dgroup1.
Dropping Disks from Disk Groups: Example 2 This example drops diska5 from disk group dgroup1, and also illustrates how multiple actions are possible with one ALTER DISKGROUP statement.ALTER DISKGROUP dgroup1 DROP DISK diska5;
ALTER DISKGROUP dgroup1 DROP DISK diska5ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;
Undropping Disks in Disk Groups: Example The following example cancels the dropping of disks from disk group dgroup1:
ALTER DISKGROUP dgroup1 UNDROP DISKS;
Manually Rebalancing a Disk Group
You can manually rebalance the files in a disk group using the REBALANCE clause of the ALTER DISKGROUP statement. This would normally not be required, because ASM automatically rebalances disk groups when their composition changes. You might want to do a manual rebalance operation if you want to control the speed of what would otherwise be an automatic rebalance operation.
The POWER clause of the ALTER DISKGROUP...REBALANCE statement specifies the degree of parallelization, and thus the speed of the rebalance operation. It can be set to a value from 0 to 11. A value of 0 halts a rebalancing operation until the statement is either implicitly or explicitly reinvoked. The default rebalance power is set by theASM_POWER_LIMIT initialization parameter. See "Tuning Rebalance Operations" for more information.
The power level of an ongoing rebalance operation can be changed by entering the rebalance statement with a new level.
The ALTER DISKGROUP...REBALANCE command by default returns immediately so that you can issue other commands while the rebalance operation takes place asynchronously in the background. You can query theV$ASM_OPERATION view for the status of the rebalance operation.
If you want the ALTER DISKGROUP...REBALANCE command to wait until the rebalance operation is complete before returning, you can add the WAIT keyword to the REBALANCEclause. This is especially useful in scripts. The command also accepts a NOWAIT keyword, which invokes the default behavior of conducting the rebalance operation asynchronously. You can interrupt a rebalance running in wait mode by typing CTRL-C on most platforms. This causes the command to return immediately with the messageORA-01013: user requested cancel of current operation, and to continue the rebalance operation asynchronously.
Additional rules for the rebalance operation include the following:
- The ALTER DISKGROUP...REBALANCE statement uses the resources of the single node upon which it is started.
- ASM can perform one rebalance at a time on a given instance.
- Rebalancing continues across a failure of the ASM instance performing the rebalance.
- The REBALANCE clause (with its associated POWER and WAIT/NOWAIT keywords) can also be used in ALTER DISKGROUP commands that add, drop, or resize disks.
Manually Rebalancing a Disk Group: Example The following example manually rebalances the disk group dgroup2. The command does not return until the rebalance operation is complete.
ALTER DISKGROUP dgroup2 REBALANCE POWER 5 WAIT;
Checking Internal Consistency of Disk Group Metadata
You can check the internal consistency of disk group metadata using the ALTER DISKGROUP...CHECK statement. Checking can be specified for specific files in a disk group, specific disks or all disks in a disk group, or specific failure groups within a disk group. The disk group must be mounted in order to perform these checks.
If any errors are detected, an error message is displayed and details of the errors are written to the alert log. Automatic Storage Management attempts to correct any errors, unless you specify the NOREPAIR clause in your ALTER DISKGROUP...CHECK statement.
The following statement checks for consistency in the metadata for all disks in the dgroup1 disk group:
ALTER DISKGROUP dgroup1 CHECK ALL;
Dropping Disk Groups
The DROP DISKGROUP statement enables you to delete an ASM disk group and optionally, all of its files. You can specify the INCLUDING CONTENTS clause if you want any files that may still be contained in the disk group also to be deleted. The default is EXCLUDING CONTENTS, which provides syntactic consistency and prevents you from dropping the disk group if it has any contents
The ASM instance must be started and the disk group must be mounted with none of the disk group files open, in order for the DROP DISKGROUP statement to succeed. The statement does not return until the disk group has been dropped.
When you drop a disk group, ASM dismounts the disk group and removes the disk group name from the ASM_DISKGROUPS initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used, and the disk group is mentioned in the ASM_DISKGROUPS initialization parameter, then you must remember to remove the disk group name from the ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the ASM instance.
The following statement deletes dgroup1:
DROP DISKGROUP dgroup1;
iewing Information About Automatic Storage Management
You can use these views to query information about Automatic Storage Management:
| View | Description |
|---|---|
| V$ASM_DISKGROUP | In an ASM instance, describes a disk group (number, name, size related info, state, and redundancy type). In a DB instance, contains one row for every ASM disk group mounted by the local ASM instance. This view performs disk discovery every time it is queried. |
| V$ASM_DISK | In an ASM instance, contains one row for every disk discovered by the ASM instance, including disks that are not part of any disk group. In a DB instance, contains rows only for disks in the disk groups in use by that DB instance. This view performs disk discovery every time it is queried. |
| V$ASM_DISKGROUP_STAT | Has the same columns as V$ASM_DISKGROUP, but to reduce overhead, does not perform a discovery when it is queried. It therefore does not return information on any disks that are new to the storage system. For the most accurate data, use V$ASM_DISKGROUP instead. |
| V$ASM_DISK_STAT | Has the same columns as V$ASM_DISK, but to reduce overhead, does not perform a discovery when it is queried. It therefore does not return information on any disks that are new to the storage system. For the most accurate data, use V$ASM_DISK instead. |
| V$ASM_FILE | In an ASM instance, contains one row for every ASM file in every disk group mounted by the ASM instance. In a DB instance, contains no rows. |
| V$ASM_TEMPLATE | In an ASM or DB instance, contains one row for every template present in every disk group mounted by the ASM instance. |
| V$ASM_ALIAS | In an ASM instance, contains one row for every alias present in every disk group mounted by the ASM instance. In a DB instance, contains no rows. |
| V$ASM_OPERATION | In an ASM instance, contains one row for every active ASM long running operation executing in the ASM instance. In a DB instance, contains no rows. |
| V$ASM_CLIENT | In an ASM instance, identifies databases using disk groups managed by the ASM instance. In a DB instance, contains one row for the ASM instance if the database has any open ASM files. |
No comments:
Post a Comment