Shulou(Shulou.com)06/01 Report--

[ASM] basic knowledge of ASM

Market share

ASM automatic storage management technology has been around for more than 10 years and has been widely used in database storage solutions in various fields. By 2014, the adoption rate of ASM on RAC was close to 60%, and more than 25% in stand-alone environments.

There are three storage solutions in RAC cluster environment: ASM, cluster file system and bare devices; although some users still insist on using the old bare devices, with the upgrade of the version, more and more users begin to adopt the free solution provided by ORACLE such as ASM.

External Redundancy is generally used in domestic scenarios where ASM is used (except for storing the DG of ocr/votedisk in 11gR2). Generally, ASM is relatively stable on versions after 10.2.0.5 and 11.2.0.2.

The following picture shows some well-known foreign enterprises that use ASM in the product environment:

ASM FILE

The high-level interaction between the ORACLE RDBMS Kernel kernel and ASM is based on the file stored in ASM, namely ASM FILE. This is no different from the way ORACLE RDBMS uses file systems or other logical volumes. ASM can store data files, log files, control files, archive logs, etc., for the storage of database files is basically the same as the file system.

An ASM FILE name usually begins with a "+" and DiskGroup name. When the ORACLE RDBMS KERNEL kernel's file iMaple O layer encounters a file that starts with "+", it goes to the code layer of the relevant ASM instead of calling the operating system-dependent file system. This is only recognized at the File I OS FILE O level that this is a file in ASM, and the upper kernel code looks like ASM FILE and OS FILE are the same.

ASM has no effect on RDBMS elements such as ROWID and SEGMENT, but the data files are stored in ASM, and ASM does not break these classic elements in the ORACLE database.

Only known ORACLE file types are allowed to be stored in an ASM Diskgroup. Assuming a file is copied into ASM Diskgroup via FTP, the first block of the file will be validated to confirm its type, and other information will be collected to build the full ASM file name of the file. If its header is not recognized, the creation of the file in DiskGroup will report an error.

Only the following file types can be stored in ASM Diskgroup:

Control FileDatafileTemporary data fileOnline Redo LogArchive LogRMAN backupDatafile CopySPFILEDisaster Recovery ConfigurationFlashback LogChange Tracking BitmapDataPump? Dumpset

ORACLE binary executables and ASCII files, such as alert.log and other trace files, are not recommended and cannot be stored in ASM Diskgroup.

File Blocks

All file types supported by ASM still use their file block as the basic unit of reading and writing. Files in ASM retain their original Block Size such as Datafile is still 2k~32k (default 8k), and ASM does not affect these things.

It is worth mentioning that the BLOCK SIZE corresponding to each FILE TYPE is recorded in the FILEDIR of ASM FILE NUmber 1, for example:

Kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82kfbh.type: 4; 0x002: KFBTYP_FILEDIRkfbh.datfmt: 1; 0x003: 0x01kfbh.block.blk: 256; 0x004: blk=256kfbh.block.obj: 1 0x008: file=1kfbh.check: 567282485; 0x00c: 0x21d00b35kfbh.fcn.base: 220023; 0x010: 0x00035b77kfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0; 0x01c: 0x00000000kfffdb.node.incarn: 838529807; 0x000: Aspir1 NUMM=0x18fd7987kfffdb.node.frlist.number: 4294967295 0x004: 0xffffffffkfffdb.node.frlist.incarn: 0; 0x008: Amal0 NUMM=0x0kfffdb.hibytes: 20; 0x00c: 0x00000014kfffdb.lobytes: 8192; 0x010: 0x00002000kfffdb.xtntcnt: 35488; 0x014: 0x00008aa0kfffdb.xtnteof: 35488; 0x018: 0x00008aa0 kfffdb.blkSize: 8192; 0x01c: 0x00002000 kfffdb.flags: 17 0x020: A=0kfffdb.fileType: 2; 0x021: 0x02kfffdb.dXrs: 17; 0x022: SCHE=0x1 NUMB=0x1kfffdb.iXrs: 17; 0x023: SCHE=0x1 NUMB=0x1kfffdb.dXsiz [0]: 20000; 0x024: 0x00004e20

The kfffdb.blkSize here is the Block Size of a data file.

Since this blocksize is always to the power of 2, a block is always in one AU allocation Unit, not across two AU.

Data Extents

The data disk Data Extents is bare storage for storing the contents of the file. Each Data Extent corresponds to an Allocation Unit on an ASM disk before 11g, and an Extent can correspond to multiple AU after 11g. For more information, please see [Oracle ASM] Variable Extent Size principle.

Extent Map

The Extent Map extent chart is a list of extent pointers that expend all data extents that belong to one file. These sectors are the bare storage space for real data storage. Each extent pointer gives its disk number and AU information. To ensure credibility, each extent pointer also contains a checksum byte to confirm that the pointer is not corrupted. ORA-600 errors may occur when this checksum value does not match the actual stored Extent information, such as ORA-00600: internal error code, arguments: [kffFdLoadXmap_86], [0], [1], [68], [54], [29], [].

Virtual Data Extents

A virtual data area Virtual Data Extent is a collection of several data extent that contain the same data. Mirrored Mirror is implemented at the virtual Extent level. Each virtual extent provides a disk address space for the file block. Each write to the file block is written to each Online online data extent in a virtual extent. Each read of a file block is also redirected to the primary mirror extent (primary Extent) in a virtual extent, unless the Disk where the primary extent is located is OFFLINE. For files that have no redundancy (that is, FILE on external redundancy disk group), a virtual Extent is actually a data Extent.

For Normal redundancy+ normal database files, a virtual Extent is actually two Data Extent.

For High redundancy+ normal database files, a virtual Extent is actually three Data Extent.

Coarse-grained striped Coarse Grain Striping

Coarse-grained striping is a simple join to a virtual data Extent. Similar to traditional volume managers that use 1MB as stripe size.

Fine-grained striped Fine Grain Striping

The difference between fine-grained and coarse-grained is that file blocks are not linearly laid out on each virtual Extent, but the files will grow at 1 Extent and 8 virtual Extent, thus the file blocks are distributed at a striped depth of 1 Extent 8 within the diskgroup. Thus, when the block size of the file is 8k, block 0x15 is above virtual Virtual Extent 0, while block 16-31 is above Vritual Extent 1, blocks 12127is on vritual extent 7, and block 128143is still on virtual extent 0 after block 0-15.

File Templates

The File Template file template is used to specify striping (coarse or FINE) and redundancy (external, normal, high) when the file is created. By default, ORACLE has provided a default template for each ORACLE database file. You can modify the default template or customize the template. Modifying a template affects only newly created files, not existing files. You can specify a template to be used when creating a file.

The default templates are as follows:

Failure Group

ASM provides redundancy, and failure group is used to ensure that a single point of error does not cause multiple copies of the same data to become unavailable at the same time. If multiple ASM DISK LUN used by ASM belong to the same hardware, such as the same disk array, and the hardware failure will cause the multiple disks to be unavailable, then the failure of the hardware should be fault-tolerant, and these disks are generally planned into the same failure group in ASM. Multiple redundant copies are not stored on the same failure group disk, in other words, there is only one copy of data in a failure group, not a second copy.

Because the configuration of Failure Group is largely related to the user's local planning, ASM allows users to specify the planning and composition of Failure group. But if the user does not specify a Failure Group plan, ASM automatically allocates disks to the necessary Failure Group.

Diskgroup that uses External Redundancy has no Failure Group. Normal redundancy Disk Groups requires at least 2 Failure Group,High Redundancy Disk Groups requires 3 Failure Group.

If there are more than 2 Failure Group in the Normal redundancy Disk Groups, such as Failure Group A, B, C, then one Virtual Extent will automatically find two Failure Group between A, B and C to store two mirror extent instead of three copies.

High Redundancy Disk Groups is similar.

In fact, the vast majority of domestic operations of ASM do not rely on ASM to implement redundancy, but use External Redundancy. External Redundancy accounts for more than 70% of the scenarios encountered by Maclean.

In practical applications, Normal/High is usually combined with multiple storage controllers Controller to allocate failure group, or there are multiple storage available.

The following is an example where there are eight Disk in the Diskgroup of one normal redundancy and two Failure Group are used:

When disk Disk H fails, this failure requires that all Extent on the failed disk be repaired, and Extent 3 and 5 will be copied from existing copies to available areas in Failgroup 2. In this example, Extent 5 is copied from Disk A to Disk F range 3 from Disk C to Disk G, and finally the failed disk is drop out of Diskgroup.

Disk Partners

Disk Partnership is based on a symmetrical relationship between two disks and exists in the redundancy diskgroup of high or normal. The Disk in Diskgroup forms a partnership with several other disk in the same Diskgroup. ASM automatically creates and maintains this relationship. Mirror copy data is allocated only on disks that have formed an partners relationship with the master data mirror primary data extent.

Disk partnering is used to reduce the probability of data loss due to simultaneous disk failures. The reason is that when more disks are used in the ASM configuration (for example, thousands), if the data mirroring is randomly looking for secondary disks to store mirrored copies, there is a higher probability of data loss when 2 disks are lost. The reason is that if the mirrored data is stored randomly, the probability that the primary of the data and the mirrored data exist on two failed disks at the same time is high. If we don't take the disk partnering,2 disk failure, the probability of data loss caused by it is greatly increased.

The Disk partnering policy limits the number of disks used to protect copies of a disk's data. ASM limits the total number of disk partners to 8 for one disk. The smaller the number, the less likely it is to lose data due to simultaneous failure of both disks. But the smaller the number, it will also cause other inconvenience. So the ORACLE ASM R & D team finally chose the number 8.

ASM selects the partners disk from a FG other than the Failure group where this disk resides, and since an ASM DISK has multiple partners, some of its partners disk may be in the same failure Group. Partners is chosen in as many different Failure Group as possible, and the purpose of doing so is clear, to improve the fault tolerance of disk failure. Askmaclean.com

If an ASM DISK fails, its protected extents can be rebuilt through its partners. Because there are multiple partners, its additional I _ partners O load is balanced among multiple ASM disk. This reduces the failure time to repair failures, because more disks are involved, resulting in higher Icano throughput, thus speeding up the refactoring of lost data mirrors. Partners is selected in as many different Failure Group as possible, so that the load of rebuilding lost disks is evenly distributed over as many hard disk resources as possible. All these considerations are based on the assumption that no two failgroup will fail at the same time.

Note that Partnering is not a partition partitioning,Partnering is just a symmetrical relationship. If Disk A lists Disk B as partner, then Disk B also lists Disk An as partner. But partnering is not a temporary relationship. At the same time, it is assumed that disk An and Disk B are partners, while Disk B and Disk C are also partners, but this does not mean that An and C are partners.

In fact, if there is enough transitivity to the partnering relationship, it may appear as a partition, as shown in the example in the following figure. But partitioning is only one possibility that partnering can offer.

Partitioning partitioning is only a special manifestation of Partnering, and Partnering itself has been able to guarantee the same load balancing when Disk disks are organized in irregular geometric arrangements, removing many of the limitations when additional capacity needs to be added to existing systems. Of course, this is still not guaranteed to be perfect in all configurations, but ASM will take the best solution based on the existing given configuration.

Here is an example of Partning:

ASM mirror protection

ASM mirror Mirror Protection prevents data loss due to the loss of individual disks. Each file has its own ASM mirroring policy attribute, which is also based on that mirroring policy for all virtual extent governed by the file. This mirror policy property is set when the file is created and cannot be modified in the future. ASM mirroring is more flexible than operating system mirroring disks, or at least it can specify the required redundancy at the file level.

ASM mirror distinguishes between primary and secondary copies of mirrored extent, but all copy mirrors are written at the same time when updating extent. ASM always tries to read the primary copy first and reads the secondary copy only if the primary copy is not available.

ASM metadata

Asm Metadata is the data that exists in ASM disk header to store ASM Diskgroup control information. Metadata includes which disks are in the disk group, how much space is available, the name of the File stored in it, what Extent is in a file, and so on.

Because Asm metadata is stored in ASM DISK HEADER, ASM disk group is self-explanatory. All metadata metadata is stored in individual metadata block (default block size 4096). This information includes the type of the metadata block and its logical location. There is also checksum information to confirm whether the block is damaged. All metadata block are 4k in size. In actual use, the ASM instance caches these ASm metadata. Askmaclean.com

ASM Instance

One of the main tasks of ASM instance is to manage ASM metadata metadata; ASM Instance is similar to ORACLE RDBMS INSTANCE with its SGA and most major background processes. Use the same binary software as RDBMS in 10.2 and separate in 11.2. But instead of loading the database, ASM instance loads Disk Group; and is responsible for telling RDBMS database instance the necessary ASM file information. Both ASM instance and DB instance need to access ASM DISK. The ASM instance manages metadata metadata, which is sufficient to describe the information of FILE in ASM. The database instance still accesses the file directly, although it needs to obtain the information such as the file Extent Map disk chart through the ASM instance, but it still completes it by itself, rather than saying that after using ASM, the DB file IWeiO needs to be implemented through ASM; it only interacts with ASM instance to obtain file location, status and other information.

There are some operations that need to be handled by the ASM instance. For example, if the DB instance needs to create a data file, the database service process connects directly to the ASM instance to implement some operations; each database maintains a connection pool to its ASM instance to avoid repeated connections caused by file operations.

ASM metadata is managed by a separate ASM instance to reduce the possibility of corruption. ASM instance is very similar to db instance, although it generally uses only a small portion of the code in the ORACLE KERNEL kernel, so it is less likely to encounter bug corruption or write corruption to disk than DB instances. The database instance itself never updates ASM metadata. Each pointer in an ASM metadata generally has a check byte for verification.

Like DB RAC, ASM instance itself can be clustered, using the ORACLE Distributed Lock Manager (DLM) distributed lock manager architecture. There can be one ASM instance on each node in a cluster. If there are multiple databases and multiple instances on a node, they share an ASM instance.

If the ASM instance on a node fails, all using that ASM instance will fail. However, ASM and database instances on other nodes will recover and continue to operate.

Disk Discovery

Disk Discovery disk discovery refers to finding disks that are worth accessing by ASM at the OS level. It is also used to find the disk ASM DISK that needs to be added to the diskgroup of mount, and the Disk that the administrator wants to add to the diskgroup, or the Disk that the administrator will consider adding it to the diskgroup. Discovery takes a discovery string (asm_diskstring) as the input parameter and returns a series of possible DISK. Note that one is to specify asm_diskstring, and the other is to require that the permissions of these disk can be used by oracle/grid users. The exact asm_diskstring discovery syntax depends on the operating system platform and the ASMLIB library. Matches generated by pathnames that are acceptable to OS are generally also available for discovery strings. It is generally recommended that there is only ASM Disk under this path to avoid management problems.

The ASM instance opens and reads every file matched by the pathname specified by the asm_diskstring and reads the block of the first 4k in order to determine the status of the disk header; if it finds that this is an ASM disk header, it thinks it is part of a diskgroup that can be mount. If it is found that the 4k block is not recognized, it is considered that the disk can be added to the ASM diskgroup (candidate).

The ASM instance needs to specify the discovery strings through an initialization parameter, which is actually asm_diskstring;. Note that multiple path strings can be added to the asm_diskstring, such as'/ dev/raw*','/dev/asm-disk*'; the same disk will not be found twice (unless you cheat ASM). In RAC cluster, if a disk is not visible throughout the cluster, then the disk cannot be added to the ASM DISKGROUP of RAC. In practice, the name of the disk on each node can be different, but the actual media should be identified by the operating system, but the actual MACLEAN also strongly recommends that you keep the name of the disk on each node the same, otherwise it is troublesome to manage. Therefore, it is necessary to introduce rules such as UDEV.

Disk Group Mount load disk group

Before the database instance can use the files on Diskgroup, you need the ASM instance to mount the local diskgroup. Mount Diskgroup involves finding all the disks and finding the disk that already has metadata data on it, and trying to match the DISK mount to a diskgroup. If you can mount, you also need to verify the metadata to ensure that there are enough disks there now. For example, if you create an external diskgroup with 3 DISK, and there are only 2 Disk hanging under the OS, you obviously cannot mount this diskgroup. You also need to initialize the SGA to update and manage these metadata later.

You can dismount a diskgroup explicitly, but if the file on the diskgroup is being used by client (such as DB), dismount will report an error. If the disk is lost within the fault tolerance of the ASM redundancy algorithm, the diskgroup will not be forced to dismount. However, if the fault tolerance is exceeded, the dismount will be forced. This forced dismount causes the DB instance that uses the files on it to be kill.

Disk ADD add disk

Adding a disk to an existing Diskgroup to expand space and increase throughput is a common requirement. The simplest add disk command such as: alter diskgroup Data add disk'/ dev/asm-disk5'; as mentioned earlier in RAC cluster if a disk is not visible in the entire cluster range, then the disk cannot be added to the ASM DISKGROUP of RAC.

If the disk header of the disk specified by add disk finds information about other diskgroup or some information about the operating system, you need alter diskgroup Data add disk'/ dev/asm-disk5' force; to add the FORCE option. Avoid using the FORCE option as much as possible in practice.

It should be noted that when the add disk command returns, it only means that disk header has completed the necessary metadata writes, but it does not mean that the disk has completed the rebalance operation. Subsequent rebalance will be triggered and moved to the newly added disk. It is generally recommended that if you want to join multiple ASM DISK, then join at the same time, rather than multiple times. However, it is generally not recommended to do both add disk and drop disk.

Disk Drop kick disk

You can drop the disk from the existing Diskgroup, and these disk can be used as another way. Of course, due to asm disk failure, it is also common for ASM instances to automatically drop the failed asm disk. If an ASM DISK often has some non-fatal errors, it is generally recommended that the Disk drop be released to avoid possible data loss if a real disk failure occurs one day. However, it is important to note that when drop disk, do not specify its pathname, but specify ASM DISK NAME.

The drop disk command may return in a short time, but the diskgroup must complete the rebalance before this disk can be used for other purposes. Rebalance will read the data that is about to be drop disk and copy the data to other disks. The FORCE option can be used to avoid reading the disk that is being drop. The FORCE option should be misappropriated immediately when the disk fails or the disk does need to be misappropriated immediately. The original extent that needs to be copied is read from redundant backups after using the FORCE option, so external redundancy does not support the use of the FORCE option. Of course, if using the FORCE option will eventually result in data loss under NORMAL/HIGH redundant Diskgroup, then the FORCE option will not be available.

DROP DISK NOFORCE:

DROP DISK FORCE:

If a serious error occurs in writing to the disk, it will also cause ASM to automatically force to DROP the Disk. If the drop of the disk causes data loss, then the diskgroup is forced to dismount, and the dismount also causes the database instance to be kill.

Rebalance

Rebalance diskgroup will move data across its DISK within the scope of diskgroup to ensure that files are evenly distributed across all disks in diskgroup, taking into account the size of each ASM DISK. When files are evenly distributed across all disks, the usage of each disk will be very similar. This ensures load balancing. Rebalance's algorithm is based on neither Istroke O statistics nor other statistical results; it all depends on the size of the disk in the Diskgroup.

Once there are some storage configuration changes in the diskgroup, such as disk add/drop/resize, the rebalance will be triggered automatically. The power parameter determines how many slave processes concurrently move parameter data. All slave processes start and work from the strength of the rebalance that occurs. Rebalance can be controlled manually, and even if you are already in the process of rebalance, you can specify instances on other nodes to do rebalance, as long as the planner wants to do so. If the instance unexpected crash, then the unfinished rebalance will automatically restart.

Note that every extent move in rebalance is coordinated with the database instance, because the database instance may need to read or write the extent at the same time, so the database works properly in the rebalance at the same time. Its impact on the database is generally small because only one extent is locked to move at a time, and only writes are blocked.

ASMLIB

ASMLIB provides the standard asmlib O interface by installing the asmlib package on the ASM so that ASM can discover and access the ASM disk. For more information about ASMLIB, please see:

For questions about udev and asmlib and Multipath, read this before you ask.

Disk Header

The first 4096 bytes of an ASM DISK is disk header, which is block 0 (blkn=0) for ASM; many operating systems retain the first block of LUN to hold partition tables or other OS information. ASM is generally not allowed to base on this block, because ASM will not hesitate to overwrite this block. ORACLE skips these operating system blocks from the code layer on some specified platforms, but in practice it is common practice to only use LUN DISK for ASM that do not have a partition table on it.

For this point, the detailed expansion is, for example, if you use PV as ASM DISK on the AIX operating system, then there can be no PVID on PV, and if a PV has been assigned to ASM, but due to the negligence of the system administrator and assigned a PVID to PV, then the ASM disk header of the PV header will be covered, which will directly lead to the loss of disk header; if it is External Redundancy, then the diskgroup will not be directly mount up. So be cautious about operations that affect ASM disk header, and it's best to back up disk header regularly.

ASM disk header describes the properties of the ASM disk and diskgroup, and by loading the existing disk header, the ASM instance can know the overall information of the diskgroup.

The following is a part of a typical disk header with disk number 0, redundancy KFDGTP_HIGH,diskname, DATA1_0000,diskgroup name, DATA1,failgroup name and DATA1_0000:

Kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82kfbh.type: 1; 0x002: KFBTYP_DISKHEADkfbh.datfmt: 1; 0x003: 0x01kfbh.block.blk: 0; 0x004: blk=0kfbh.block.obj: 2147483648 0x008: disk=0kfbh.check: 3107059325; 0x00c: 0xb931f67dkfbh.fcn.base: 0; 0x010: 0x00000000kfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0; 0x01c: 0x00000000kfdhdb.driver.provstr: ORCLDISK 0x000: length=8kfdhdb.driver.reserved [0]: 0; 0x008: 0x00000000kfdhdb.driver.reserved [1]: 0; 0x00c: 0x00000000kfdhdb.driver.reserved [2]: 0; 0x010: 0x00000000kfdhdb.driver.reserved [3]: 0; 0x014: 0x00000000kfdhdb.driver.reserved [4]: 0; 0x018: 0x00000000kfdhdb.driver.reserved [5]: 0; 0x01c: 0x00000000kfdhdb.compat: 186646528 0x020: 0x0b200000 kfdhdb.dsknum: 0; 0x024: 0x0000kfdhdb.grptyp: 3; 0x026: KFDGTP_HIGHkfdhdb.hdrsts: 3; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA1_0000; 0x028: length=10kfdhdb.grpname: DATA1; 0x048: length=5kfdhdb.fgname: DATA1_0000 0x068: length=10 kfdhdb.capname:; 0x088: length=0kfdhdb.crestmp.hi: 32999670; 0x0a8: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7dekfdhdb.crestmp.lo: 1788720128; 0x0ac: USEC=0x0 MSEC=0x36d SECS=0x29 MINS=0x1akfdhdb.mntstmp.hi: 32999670; 0x0b0: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7dekfdhdb.mntstmp.lo: 1812990976; 0x0b4: USEC=0x0 MSEC=0x3 SECS=0x1 MINS=0x1bkfdhdb.secsize: 512; 0x0b8: 0x0200kfdhdb.blksize: 4096 0x0ba: 0x1000kfdhdb.ausize: 4194304; 0x0bc: 0x00400000kfdhdb.mfact: 454272; 0x0c0: 0x0006ee80kfdhdb.dsksize: 32375; 0x0c4: 0x00007e77kfdhdb.pmcnt: 2; 0x0c8: 0x00000002kfdhdb.fstlocn: 1; 0x0cc: 0x00000001kfdhdb.altlocn: 2; 0x0d0: 0x00000002kfdhdb.f1b1locn: 2 0x0d4: 0x00000002kfdhdb.redomirrors [0]: 0; 0x0d8: 0x0000kfdhdb.redomirrors [1]: 0; 0x0da: 0x0000kfdhdb.redomirrors [2]: 0; 0x0dc: 0x0000kfdhdb.redomirrors [3]: 0; 0x0de: 0x0000kfdhdb.dbcompat: 186646528; 0x0e0: 0x0b200000kfdhdb.grpstmp.hi: 32999670; 0x0e4: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7dekfdhdb.grpstmp.lo: 1783335936 0x0e8: USEC=0x0 MSEC=0x2e3 SECS=0x24 MINS=0x1akfdhdb.vfstart: 0; 0x0ec: 0x00000000kfdhdb.vfend: 0; 0x0f0: 0x00000000kfdhdb.spfile: 0; 0x0f4: 0x00000000kfdhdb.spfflg: 0; 0x0f8: 0x00000000kfdhdb.ub4spare [0]: 0; 0x0fc: 0x00000000kfdhdb.ub4spare [1]: 0 0x100: 0x00000000kfdhdb.ub4spare [2]: 0; 0x104: 0x00000000kfdhdb.ub4spare [3]: 0; 0x108: 0x00000000

The following information is copied on the header of all disk in the same diskgroup:

Disk group name and creation timestampPhysical sector size of all disks in the disk groupAllocation unit sizeMetadata block sizeSoftware version compatibilityDefault redundancyMount timestamp

The following information is unique to each asm disk:

ASM disk name (not OS path name) Disk number within disk groupFailure group nameDisk size in allocation units

Freespace Table

AU=0 's blkn=1 contains free space table;, which contains approximate information about the remaining FREE SPACE free space available on each allocation table in the AU. By referring to the free space table, you can avoid looking for space in the allocated allocation table.

[oracle@mlab2 dbs] $kfed read / oracleasm/asm-disk01 blkn=1 aun=0 aus=4194304 | less kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82 kfbh.type: 2; 0x002: KFBTYP_FREESPC kfbh.datfmt: 2; 0x003: 0x02kfbh.block.blk: 1 0x004: blk=1kfbh.block.obj: 2147483648; 0x008: disk=0kfbh.check: 3847932395; 0x00c: 0xe55ac9ebkfbh.fcn.base: 22557; 0x010: 0x0000581dkfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0 0x01c: 0x00000000kfdfsb.aunum: 0; 0x000: 0x00000000kfdfsb.max: 1014; 0x004: 0x03f6kfdfsb.cnt: 73; 0x006: 0x0049kfdfsb.bound: 0; 0x008: 0x0000kfdfsb.flag: 1; 0x00a: B=1kfdfsb.ub1spare: 0 0x00b: 0x00kfdfsb.spare [0]: 0; 0x00c: 0x00000000kfdfsb.spare [1]: 0; 0x010: 0x00000000kfdfsb.spare [2]: 0; 0x014: 0x00000000kfdfse [0] .fse: 0; 0x018: FREE=0x0 FRAG=0x0kfdfse [1] .fse: 0 0x019: FREE=0x0 FRAG=0x0kfdfse [2] .fse: 0; 0x01a: FREE=0x0 FRAG=0x0kfdfse [3] .fse: 0; 0x01b: FREE=0x0 FRAG=0x0kfdfse [4] .fse: 0; 0x01c: FREE=0x0 FRAG=0x0kfdfse [5] .fse: 0; 0x01d: FREE=0x0 FRAG=0x0kfdfse [6] .fse: 0 0x01e: FREE=0x0 FRAG=0x0kfdfse [7] .fse: 0; 0x01f: FREE=0x0 FRAG=0x0kfdfse [8] .fse: 0; 0x020: FREE=0x0 FRAG=0x0kfdfse [9] .fse: 0; 0x021: FREE=0x0 FRAG=0x0kfdfse [10] .fse: 0; 0x022: FREE=0x0 FRAG=0x0kfdfse [11] .fse: 119 0x023: FREE=0x7 FRAG=0x7kfdfse [12] .fse: 16; 0x024: FREE=0x0 FRAG=0x1kfdfse [13] .fse: 16; 0x025: FREE=0x0 FRAG=0x1kfdfse [14] .fse: 16; 0x026: FREE=0x0 FRAG=0x1kfdfse [15] .fse: 16; 0x027: FREE=0x0 FRAG=0x1kfdfse [16] .fse: 16 0x028: FREE=0x0 FRAG=0x1kfdfse [17] .fse: 16; 0x029: FREE=0x0 FRAG=0x1kfdfse [18] .fse: 16; 0x02a: FREE=0x0 FRAG=0x1kfdfse [19] .fse: 16; 0x02b: FREE=0x0 FRAG=0x1kfdfse [20] .fse: 16; 0x02c: FREE=0x0 FRAG=0x1kfdfse [21] .fse: 16 0x02d: FREE=0x0 FRAG=0x1kfdfse [22] .fse: 16; 0x02e: FREE=0x0 FRAG=0x1kfdfse [23] .fse: 16; 0x02f: FREE=0x0 FRAG=0x1kfdfse [24] .fse: 16; 0x030: FREE=0x0 FRAG=0x1kfdfse [25] .fse: 16; 0x031: FREE=0x0 FRAG=0x1kfdfse [26] .fse: 16 0x032: FREE=0x0 FRAG=0x1kfdfse [27] .fse: 16; 0x033: FREE=0x0 FRAG=0x1kfdfse [28] .fse: 16; 0x034: FREE=0x0 FRAG=0x1

Aunum_kfdfsb First AU of first ATB of this FSB

Max_kfdfsb Max number of FSEs per FSB

Cnt_kfdfsb Number of FSEs up to end of disk

Spare_kfdfsb spares for future

Kfdfse-Kernel Files Disk Free Space Entry.

Max_kfdfsb describes the number of free space entries which would

Be used in this free space table if the disk were large enough to

Provide all of the AUs which can be described by a single physical

Metadata AU. Cnt_kfdfsb describes the number of free space entries

Which correspond to AUs which are actually present on the disk. In

The case where there are additional physical metadata AUs beyond the

One containing this kfdfsb, then max_kfdfsb will equal cnt_kfdfsb.

There are complications with the interpretation of cnt_kfdfsb when

A disk is being grown or shrunk. It is possible in these cases to

Have allocated AUs past the range indicated by cnt_kfdfsb which have

Not yet been relocated into the new area of the disk.

The Free Space Table provides a summary of which allocation table

Blocks have free space. There is one kfdfse in the FST for each

Allocation Table block described by the FST.

The first key parameter is the stripe width of the array. Stripe width refers to the number of parallel stripes that can be written to or read from simultaneously. This is of course equal to the number of disks in the array. So a four-disk striped array would have a stripe width of four.

Allocation Table

The last 254metadata block of Aun=0 are used to store AU allocation information. Each metadata describes the status of 448 AU, and if an AU has been assigned to a file, the allocation table records its ASM file number and data extent number. For AU, which is still FREE, it is link to free list.

Kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82kfbh.type: 3; 0x002: KFBTYP_ALLOCTBLkfbh.datfmt: 2; 0x003: 0x02kfbh.block.blk: 2; 0x004: blk=2kfbh.block.obj: 2147483648 0x008: disk=0kfbh.check: 2376540464; 0x00c: 0x8da72130kfbh.fcn.base: 44495; 0x010: 0x0000adcfkfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0; 0x01c: 0x00000000kfdatb.aunum: 0 0x000: 0x00000000kfdatb.shrink: 448; 0x004: 0x01c0kfdatb.ub2pad: 0; 0x006: 0x0000kfdatb.auinfo [0] .link.next: 112; 0x008: 0x0070kfdatb.auinfo [0] .link.prev: 112; 0x00a: 0x0070kfdatb.auinfo [1] .link.Next: 120; 0x00c: 0x0078kfdatb.auinfo [1] .link.prev: 120 0x00e: 0x0078kfdatb.auinfo [2] .link.next: 136; 0x010: 0x0088kfdatb.auinfo [2] .link.prev: 136; 0x012: 0x0088kfdatb.auinfo [3] .link.next: 20; 0x014: 0x0014kfdatb.auinfo [3] .link.prev: 20; 0x016: 0x0014kfdatb.auinfo [4] .link.next: 168; 0x018: 0x00a8kfdatb.auinfo [4] .link.prev: 168 0x01a: 0x00a8kfdatb.auinfo [5] .link.next: 296; 0x01c: 0x0128kfdatb.auinfo [5] .link.prev: 296; 0x01e: 0x0128kfdatb.auinfo [6] .link.next: 552; 0x020: 0x0228kfdatb.auinfo [6] .link.prev: 3112; 0x022: 0x0c28kfdatb.spare: 0; 0x024: 0x00000000kfdate [0] .comparator: 1 0x028: 0x00000001kfdate [0] .allo.lo: 0; 0x028: XNUM=0x0kfdate [0] .allo.hi: 8388608; 0x02c: Vladi1 Iron0 Hallo0 FNUM=0x0kfdate [1] .comparator: 1; 0x030: 0x00000001kfdate [1] .allo.lo: 0; 0x030: XNUM=0x0kfdate [1] .allo.hi: 8388608; 0x034: Vambi1 Iron0 Hallo0 FNUM=0x0kfdate [2] .comparator: 1 0x038: 0x00000001kfdate [2] .allo.lo: 0; 0x038: XNUM=0x0kfdate [2] .allo.hi: 8388609; 0x03c: Vladi1 Iron0 Hallo0 FNUM=0x1kfdate [3] .comparator: 1; 0x040: 0x00000001kfdate [3] .allo.lo: 8; 0x040: XNUM=0x8kfdate [3] .allo.hi: 8388611; 0x044: Vambi1 Iron0 Hallo0 FNUM=0x3kfdate [4] .comparator: 1 0x048: 0x00000001kfdate [4] .allo.lo: 19; 0x048: XNUM=0x13kfdate [4] .allo.hi: 8388611; 0x04c: Vladi1 Iron0 Hallo0 FNUM=0x3kfdate [5] .comparator: 1; 0x050: 0x00000001kfdate [5] .allo.lo: 29; 0x050: XNUM=0x1dkfdate [5] .allo.hi: 8388611; 0x054: Vladi1 Iron0 Haz0 FNUM=0x3kfdate [6] .comparator: 1 0x058: 0x00000001kfdate [6] .allo.lo: 30; 0x058: XNUM=0x1ekfdate [6] .allo.hi: 8388611; 0x05c: Vladi1 Iron0 Hallo0 FNUM=0x3kfdate [7] .comparator: 1; 0x060: 0x00000001kfdate [7] .allo.lo: 0; 0x060: XNUM=0x0kfdate [7] .allo.hi: 8388612; 0x064: Vladi1 Iron0 Haz0 FNUM=0x4kfdate [8] .comparator: 1; 0x068: 0x00000001

Partner and Status Table

Aun=1 is generally reserved for use by copies of Partner and Status Table (PST). Typically, 5 ASM DISK will contain a copy of PST. Most PST content must be the same and validated. Otherwise, it is impossible to determine which ASM DISK actually has the relevant data.

The Blkn=0 of the PST table is the header of PST and holds the following information:

Timestamp to indicate PST is validVersion number to compare with other PST copiesList of disks containing PST copiesBit map for shadow paging updates

The last block of PST is heartbeat block, which is updated every 3 seconds when diskgroup mount occurs.

The following is PST header

Kfed read / oracleasm/asm-disk01 aun=1 blkn=0 aus=4194304 | less kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82kfbh.type: 17; 0x002: KFBTYP_PST_METAkfbh.datfmt: 2; 0x003: 0x02kfbh.block.blk: 1024 0x004: blk=1024kfbh.block.obj: 2147483648; 0x008: disk=0kfbh.check: 3813974007; 0x00c: 0xe3549ff7kfbh.fcn.base: 0; 0x010: 0x00000000kfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0 0x01c: 0x00000000kfdpHdrPairBv1.first.super.time.hi:32999670; 0x000: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7dekfdpHdrPairBv1.first.super.time.lo:1788841984; 0x004: USEC=0x0 MSEC=0x3e4 SECS=0x29 MINS=0x1akfdpHdrPairBv1.first.super.last: 2; 0x008: 0x00000002kfdpHdrPairBv1.first.super.next: 2; 0x00c: 0x00000002kfdpHdrPairBv1.first.super.copyCnt: 5; 0x010: 0x05kfdpHdrPairBv1.first.super.version: 1; 0x011: 0x01kfdpHdrPairBv1.first.super.ub2spare: 0; 0x012: 0x0000kfdpHdrPairBv1.first.super.incarn: 1 0x014: 0x00000001kfdpHdrPairBv1.first.super.copy [0]: 0; 0x018: 0x0000kfdpHdrPairBv1.first.super.copy [1]: 1; 0x01a: 0x0001kfdpHdrPairBv1.first.super.copy [2]: 2; 0x01c: 0x0002kfdpHdrPairBv1.first.super.copy [3]: 3; 0x01e: 0x0003kfdpHdrPairBv1.first.super.copy [4]: 4; 0x020: 0x0004kfdpHdrPairBv1.first.super.dtaSz: 15; 0x022: 0x000fkfdpHdrPairBv1.first.asmCompat:186646528; 0x024: 0x0b200000kfdpHdrPairBv1.first.newCopy [0]: 0 0x028: 0x0000kfdpHdrPairBv1.first.newCopy [1]: 0; 0x02a: 0x0000kfdpHdrPairBv1.first.newCopy [2]: 0; 0x02c: 0x0000kfdpHdrPairBv1.first.newCopy [3]: 0; 0x02e: 0x0000kfdpHdrPairBv1.first.newCopy [4]: 0; 0x030: 0x0000kfdpHdrPairBv1.first.newCopyCnt: 0; 0x032: 0x00kfdpHdrPairBv1.first.contType: 1; 0x033: 0x01kfdpHdrPairBv1.first.spares [0]: 0; 0x034: 0x00000000kfdpHdrPairBv1.first.spares [1]: 0 0x038: 0x00000000kfdpHdrPairBv1.first.spares [2]: 0; 0x03c: 0x00000000kfdpHdrPairBv1.first.spares [3]: 0; 0x040: 0x00000000kfdpHdrPairBv1.first.spares [4]: 0; 0x044: 0x00000000kfdpHdrPairBv1.first.spares [5]: 0; 0x048: 0x00000000kfdpHdrPairBv1.first.spares [6]: 0; 0x04c: 0x00000000kfdpHdrPairBv1.first.spares [7]: 0; 0x050: 0x00000000kfdpHdrPairBv1.first.spares [8]: 0; 0x054: 0x00000000kfdpHdrPairBv1.first.spares [9]: 0 0x058: 0x00000000kfdpHdrPairBv1.first.spares [10]: 0; 0x05c: 0x00000000kfdpHdrPairBv1.first.spares [11]: 0; 0x060: 0x00000000kfdpHdrPairBv1.first.spares [12]: 0; 0x064: 0x00000000kfdpHdrPairBv1.first.spares [13]: 0; 0x068: 0x00000000kfdpHdrPairBv1.first.spares [14]: 0; 0x06c: 0x00000000kfdpHdrPairBv1.first.spares [15]: 0; 0x070: 0x00000000kfdpHdrPairBv1.first.spares [16]: 0; 0x074: 0x00000000kfdpHdrPairBv1.first.spares [17]: 0 0x078: 0x00000000kfdpHdrPairBv1.first.spares [18]: 0; 0x07c: 0x00000000kfdpHdrPairBv1.first.spares [19]: 0; 0x080: 0x00000000

Super.time wall clock time of last PST commitsuper.last last committed content version numbersuper.next next available content version numbersuper.copyCnt # of disks holding PST copiessuper.version version of PST header formatsuper.ub2spare pad to ub4 alignsuper.incarn incarnation of listsuper.copy [0] disks holding the PST copiessuper.dtaSz data entries in PSTnewCopy [0] new disks holding PST copiesnewCopyCnt new # disks holding PST copies

The following is PST table block:

Kfed read / oracleasm/asm-disk02 aun=1 blkn=3 aus=4194304 | less kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82kfbh.type: 18; 0x002: KFBTYP_PST_DTAkfbh.datfmt: 2; 0x003: 0x02kfbh.block.blk: 1027 0x004: blk=1027kfbh.block.obj: 2147483649; 0x008: disk=1kfbh.check: 4204644293; 0x00c: 0xfa9dc7c5kfbh.fcn.base: 0; 0x010: 0x00000000kfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0 0x01c: 0x00000000kfdpDtaEv1 [0] .status: 127th; 0x000: Iron1 Ventr1 Ventur1 D=1kfdpDtaEv1 1 D=1kfdpDtaEv1 [0] .fgNum: 1; 0x002: 0x0001kfdpDtaEv1 [0] .addts: 2022663849; 0x004: 0x788f66a9kfdpDtaEv1 [0] .partner [0]: 49154; 0x008: Pumb1 Play1 PART=0x2kfdpDtaEv1 [0] .partner [1]: 49153; 0x00a: Play1 Play1 PART=0x1kfdpDtaEv1 [0] .partner [2]: 49155 0x00c: paired 1 PART=0x3kfdpDtaEv1 [0] .partner [3]: 49166; 0x00e: paired 1 PART=0xekfdpDtaEv1 [0] .partner [4]: 49165; 0x010: paired 1 PART=0xdkfdpDtaEv1 [0] .partner [5]: 49164; 0x012: paired 1 PART=0xckfdpDtaEv1 [0] .partner [6]: 49156; 0x014: paired 1 PART=0x4kfdpDtaEv1 [0] .partner [7]: 49163; 0x016: paired 1 PART=0xbkfdpDtaEv1 [0] .partner [8]: 10000 0x018: paired 0 PART=0x2710kfdpDtaEv1 [0] .partner [9]: 0; 0x01a: paired 0 PART=0x0kfdpDtaEv1 [0] .partner [10]: 0; 0x01c: paired 0 paired 0 PART=0x0kfdpDtaEv1 [0] .partner [11]: 0; 0x01e: paired 0 paired 0 PART=0x0kfdpDtaEv1 [0] .partner [12]: 0; 0x020: paired 0 paired 0 PART=0x0kfdpDtaEv1 [0] .partner [13]: 0; 0x022: paired 0 paired 0 PART=0x0kfdpDtaEv1 [0] .partner [14]: 0 0x024: paired 0 PART=0x0kfdpDtaEv1 [0] .partner [15]: 0; 0x026: paired 0 PART=0x0kfdpDtaEv1 [0] .partner [16]: 0; 0x028: paired 0 paired 0 PART=0x0kfdpDtaEv1 [0] .partner [17]: 0; 0x02a: paired 0 paired 0 PART=0x0kfdpDtaEv1 [0] .partner [18]: 0; 0x02c: paired 0 PART=0x0kfdpDtaEv1 [0] .partner [19]: 0; 0x02e: paired 0 paired 0 PART=0x0kfdpDtaEv1 [1] .status: 127 0x030: 0x030: 0x0002kfdpDtaEv1 [1] .fgNum: 2; 0x032: 0x0002kfdpDtaEv1 [1] .addts: 2022663849; 0x034: 0x788f66a9kfdpDtaEv1 [1] .partner [0]: 49155; 0x038: paired 1 PART=0x3kfdpDtaEv1 [1] .partner [1]: 49152; 0x03a: paired 1 PART=0x0kfdpDtaEv1 [1] .partner [2]: 49154; 0x03c: paired 1 PART=0x2kfdpDtaEv1 [1] .partner [3]: 49166 0x03e: paired 1 PART=0xekfdpDtaEv1 [1] .partner [4]: 49157; 0x040: paired 1 PART=0x5kfdpDtaEv1 [1] .partner [5]: 49156; 0x042: paired 1 PART=0x4kfdpDtaEv1 [1] .partner [6]: 49165; 0x044: paired 1 PART=0xdkfdpDtaEv1 [1] .partner [7]: 49164; 0x046: paired 1 PART=0xckfdpDtaEv1 [1] .partner [8]: 10000; 0x048: paired 0 Play1 PART=0x2710kfdpDtaEv1 [1] .partner [9]: 0 0x04a: paired 0 PART=0x0kfdpDtaEv1 [1] .partner [10]: 0; 0x04c: paired 0 PART=0x0kfdpDtaEv1 [1] .partner [11]: 0; 0x04e: paired 0 paired 0 PART=0x0kfdpDtaEv1 [1] .partner [12]: 0; 0x050: paired 0 paired 0 PART=0x0kfdpDtaEv1 [1] .partner [13]: 0; 0x052: paired 0 PART=0x0kfdpDtaEv1 [1] .partner [14]: 0; 0x054: paired 0 paired 0 PART=0x0kfdpDtaEv1 [1] .partner [15]: 0 0x056: pendant 0 PART=0x0kfdpDtaEv1 [1] .partner [16]: 0; 0x058: pound0 Play0 PART=0x0

KfdpDtaEv1 [0] .status: 127. 0x000: 0x008 1 PART=0x2 partner list 1 PART=0x2 partner list 1 PART=0x2 partner list

A copy of KFBTYP_DISKHEAD is backed up in the last second block of aun=1

[oracle@mlab2 hzy] $kfed read / oracleasm/asm-disk02 aun=1 blkn=1022 aus=4194304 | less kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82kfbh.type: 1; 0x002: KFBTYP_DISKHEADkfbh.datfmt: 1; 0x003: 0x01kfbh.block.blk: 1022 0x004: blk=1022kfbh.block.obj: 2147483649; 0x008: disk=1kfbh.check: 3107059260; 0x00c: 0xb931f63ckfbh.fcn.base: 0; 0x010: 0x00000000kfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0 0x01c: 0x00000000kfdhdb.driver.provstr: ORCLDISK; 0x000: length=8kfdhdb.driver.reserved [0]: 0; 0x008: 0x00000000kfdhdb.driver.reserved [1]: 0; 0x00c: 0x00000000kfdhdb.driver.reserved [2]: 0; 0x010: 0x00000000kfdhdb.driver.reserved [3]: 0; 0x014: 0x00000000kfdhdb.driver.reserved [4]: 0; 0x018: 0x00000000kfdhdb.driver.reserved [5]: 0 0x01c: 0x00000000kfdhdb.compat: 186646528; 0x020: 0x0b200000kfdhdb.dsknum: 1; 0x024: 0x0001kfdhdb.grptyp: 3; 0x026: KFDGTP_HIGHkfdhdb.hdrsts: 3; 0x027: KFDHDR_MEMBERkfdhdb.dskname: DATA1_0001; 0x028: length=10kfdhdb.grpname: DATA1; 0x048: length=5kfdhdb.fgname: DATA1_0001 0x068: length=10kfdhdb.capname:; 0x088: length=0kfdhdb.crestmp.hi: 32999670; 0x0a8: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7dekfdhdb.crestmp.lo: 1788720128; 0x0ac: USEC=0x0 MSEC=0x36d SECS=0x29 MINS=0x1akfdhdb.mntstmp.hi: 32999670; 0x0b0: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7dekfdhdb.mntstmp.lo: 1812990976; 0x0b4: USEC=0x0 MSEC=0x3 SECS=0x1 MINS=0x1bkfdhdb.secsize: 512; 0x0b8: 0x0200kfdhdb.blksize: 4096 0x0ba: 0x1000kfdhdb.ausize: 4194304; 0x0bc: 0x00400000

The last block of AUN=1 is the KFBTYP_HBEAT heartbeat table:

[oracle@mlab2 hzy] $kfed read / oracleasm/asm-disk02 aun=1 blkn=1023 aus=4194304 | less kfbh.endian: 1; 0x000: 0x01kfbh.hard: 130; 0x001: 0x82kfbh.type: 19; 0x002: KFBTYP_HBEATkfbh.datfmt: 2; 0x003: 0x02kfbh.block.blk: 2047 0x004: blk=2047kfbh.block.obj: 2147483649; 0x008: disk=1kfbh.check: 1479766671; 0x00c: 0x5833728fkfbh.fcn.base: 0; 0x010: 0x00000000kfbh.fcn.wrap: 0; 0x014: 0x00000000kfbh.spare1: 0; 0x018: 0x00000000kfbh.spare2: 0 0x01c: 0x00000000kfdpHbeatB.instance: 1; 0x000: 0x00000001kfdpHbeatB.ts.hi: 32999734; 0x004: HOUR=0x16 DAYS=0x9 MNTH=0x2 YEAR=0x7dekfdpHbeatB.ts.lo: 3968041984; 0x008: USEC=0x0 MSEC=0xe1 SECS=0x8 MINS=0x3bkfdpHbeatB.rnd [0]: 1065296177; 0x00c: 0x3f7f2131kfdpHbeatB.rnd [1]: 857037208; 0x010: 0x33155998kfdpHbeatB.rnd [2]: 2779184235; 0x014: 0xa5a6fc6bkfdpHbeatB.rnd [3]: 2660793989; 0x018: 0x9e987e85

KfdpHbeatB.instance instance idkfdpHbeatB.ts.hi timestampkfdpHbeatB.rnd [0] randomly add salt

External Redundancy generally has one PSTNormal Redundancy, at most three PSTHigh Redundancy, and at most five PST.

PST may be relocated in the following scenarios:

The ASM DISK with PST is not available (when ASM Qidong) ASM DISK OFFLINE occurred when reading and writing to PST occurred IWeiO error disk was normal DROP

The PST is checked before reading other ASM metadata. When the ASM instance is required to mount diskgroup, the GMON process reads all the disks in the diskgroup to find and confirm the PST copy. If he finds that there is enough PST, then after the mount diskgroup, the PST will be cached in the ASM cache and GMON's PGA and use an exclusive PT.n.0 lock to protect other ASM instances in the same cluster. PST will also be cached to GMON's PGA. And use a shared PT.n.o lock to protect only the GMON that holds the exclusive lock can update the PST information on the disk AUN=1 on each ASM DISK is reserved for PST, but only a few disks actually have PST data

Extents Set

Extents set is a collection of data extent to maintain redundant copies of virtual extent. The extent pointer in ASM FILE1 is contiguous in extent map, as in the following data:

SQL > select pxn_kffxp,xnum_kffxp from x$kffxp where number_kffxp=257 PXN_KFFXP XNUM_KFFXP--0 0 1 0 2 0 3 1 4 1 5 1 6 2 7 2 8 2 9 3 10 3

In the above query, PXN_KFFXP is the physical extent number of file number 257, and XNUM_KFFXP is the logical extent number. This file is on a High redundancy diskgroup, so one extent set contains 3 copies of the same virtual extent data.

You can think of the above query as the extent map of the file number 257, and its logical extent number is incremented continuously.

The first extent in an extent sets is primary extent. There is only one primary extent in external redundancy mode. There is a second-level extent under Normal redundancy after primary and two second-level extent in the case of high.

For files under normal redundancy, each extent set consists of two data extent distributed on different disks as well as two different failure group. These two data extent are next to each other on extent map. The extent number of primary extent is always even, and its only secondary extent is always odd. When an extent is moved, it usually triggers the movement of all the extent in the extent set to meet the redundancy requirements.

High Redundancy diskgroup uses three-way mirrors by default. The Vritual Extent under three-way mirrors has one primary and two secondary secondary data extents. Secondary data extents needs to be stored in different failure group, so it requires at least three failure group to implement high redundancy.

There may be loss of data extent in special cases, such as when the failure group is unavailable and there is no place to put it.

The secondary extent will be evenly distributed on the disk partners corresponding to the primary extent; even if there are disk failures, the write-out to the extent set will be load balanced.

File Directory (file # 1)

For more information, please refer to Oracle ASM (2): ASM File number 1 file directory http://www.askmaclean.com/archives/asm-file-number-1-the-file-directory.html

Start the ASM instance

Before the ASM file can be accessed through the ASM instance, the ASM instance must be started. Under 11.2, both RAC and StandAlone ASM instances will be started automatically with the system BOOT. Starting an ASM instance is similar to starting a database instance. SGA and a set of background processes are created during startup. The initialization parameter instance_type determines whether it is an ASM instance or a database instance. Unless the NOMOUNT option is used in STARTUP, the default STARTUP executes ALTER DISKGROUP ALL MOUNT.

The ASM instance will be added to the + ASM member group in CSS during startup. This will allow this instance to share locks with other + ASM instances. The database instance will not be added to this member group because the instance name of the database instance cannot start with "+".

Discovery Discovery disk

The Discovery process is about finding the disk for subsequent operations. Discovery goes to the location where the DISK STRING matches to find the disks and returns those they think are appropriate. Discovery generally exists in two scenarios; the first is to use all the strings specified in asm_diskstring to find out the disks that all ASM instances must access. The second is to specify the disk path for create diskgroup or add disk to diskgroup.

The first discovery, also called shallow discovery, returns only the disks specified by asm_diskstring. The second, also known as deep discovery, reads the first block of each disk. Disk header is used here to sort whether the disk is available, whether it is useful by something other than ASM (such as LVM), or whether it has been used by other diskgroup. The discovery operation does not mount diskgroup or write any disk heads.

Create Disk Group creates a disk group

To create a diskgroup, you need to specify multiple disk paths, and these disks need to pass the following tests:

It cannot be part of an already mount diskgroup it cannot have a valid ASM disk header, unless it adds the FORCE option it cannot have a valid ORACLE DATAFILE HEADER, unless it adds the FORCE option unless necessary, do not use the FORCE option it cannot have 2 different pathnames visible to the ASM. It must be discoverable through asm_diskstring

All disks are verified by writing a disk header. The mount timestamp in this disk header is 0, which shows that diskgroup has not been mount yet. Free space block and allocation table blocks metadata blocks are then written.

Some of the disks are selected to store Partnership and Status Table and PST tables. PST is initialized to record that all disks are online. High redundancy disk group each failure group corresponds to one PST, up to 5 copies. Up to 3 PST copies of normal redundancy group. External redundancy disk group has a PST.

Then the subsequent metadata block will be initialized and distributed evenly across all the disks of the newly created diskgroup.

File Directory (file # 1): each record corresponds to an ASM FILE: for more information, please refer to Oracle ASM (2): ASM File number 1 file directory http://www.askmaclean.com/archives/asm-file-number-1-the-file-directory.htmlASM Disk Directory (file # 2): each record corresponds to a disk Active Change Directory added to the CREATE DISKGROUP (file # 3): a log area is divided for the first mount With Continuing Operations Directory (file # 4): initialize only Unassigned Template Directory (file # 5): create a system template for all ORACLE file types. Redundancy in template is consistent with diskgroup's Alias Directory (file # 6): there is no alias for the time being. Metadata files doesn't actually have a name.

[Oracle ASM Metadata] Alias Directory (file # 6)

[Oracle ASM] Continuing Operations Directory (file # 4)

[Oracle ASM Metadata] Template Directory (file # 5)

[Oracle ASM] ASM FILE NUMBER 3 Active Change Directory

In-depth understanding of Oracle ASM (2): ASM File number 1 file directory

[Oracle ASM] ASM FILE NUMBER # 2 DISK Directory

When the diskgroup is fully initialized, the mount timestamp is written to disk header. This will mark that the diskgroup is formatted and can be mount. Other instances can also mount the disk group.

Drop Disk Group

Diskgroup can be dropped by drop as long as all files on it are closed and only the local instance is in mount it. You can confirm these two points by communicating over all the ASM of clusterware. Drop diskgroup will write all the disk heads under the DG to the FORMER state of header_status.

Mount Disk Group

Mount Disk Group makes Disk Group available to the local ASM instance and the database instance connected to that instance. The files in the diskgroup must be started by the local ASM instance mount; before the ASM is started. It is more efficient to mount multiple diskgroup at the same time. Typically, all diskgroup matched by ASM_DISKGROUPS are mount when the ASM instance is started through ALTER DISKGROUP ALL MOUNT.

Here are the steps for mount a diskgroup:

Discovery

Will pass ASM_DISKSTRING. Make a deep discovery; each disk header contains the diskgroup; to which it belongs. This step should find all the disks that are subordinate to the diskgroup to be mount. Get the following information on disk header:

Disk NameDisk number's last timestampDisk Group Name of mount

When discovery, if you find that the disk header of two disks is the same, you may report an error in order to avoid damaging the disk group.

Note that the OS device names of each ASM DISK may change after creation from diskgroup, or may be different on each node in the cluster, which does not matter as long as discovery can find them and pass verification.

An example of the first mount

The Instance Lock instance lock is used to determine whether the ASM instance is the first mount that should be diskgroup, or whether it has been mount by other ASM instances. If it is the first to do mount, the lock will be held exclusively until the mount disk group initialization is complete, to prevent other instances from doing the same mount in the process. If it is not the first mount, wait for the ASM of the first mount to complete its mount operation.

PST discovery

When a set of disks for diskgroup is found, the disks that contain PST must be found. The first block of AUN=1 on each disk will be read. This identifies that those disks have PST copies in AUN=1. Most of the same PST copies must be found to ensure that a valid PST is read.

For example, if you have five PST, you need to find three PST with the same content and read them out.

Once the PST is read, the ASM instance will know which disk number the mount disk group must have.

Heartbeat

If this is the first instance of mount, a heartbeat check heartbeat check is done. This is to prevent instances on two different hosts from believing that the first mount should be diskgroup, which may occur in scenarios where lock manager is improperly configured. When the disk group is instantiated mount, the last block on the PST table, the heartbeat block, is written to a new value every 3 seconds, and this write is performed by one of the instances that have mount the DG. If an instance considers itself to be the first mount, but fails to find heartbeat, its mount fails. If it finds that there is no heartbeat, it will start heartbeat.

Header validation

If the first instance of mount dg, a new mount timestamp timestamp is written to each disk. If it is not the first instance of mount, the mount timestamp is validated. This ensures that when two instances may find multiple identical copies of a disk, they can still tell that they are actually different disks.

If this is the first instance of mount, it is possible that some disks have become unavailable since the last mount, but these disks are still marked online in PST, but they cannot be found. This difference will be discovered by ASM and OFFLINE the lost disks, provided their redundancy allows those disks to OFFLINE.

If it is not the first instance of mount, all disks marked as ONLINE in PST need to be discovered by it. If other instances can find all the disks under DG, then this instance must also be able to see them.

Redo recovery

If this example is the first mount DG, it has the obligation to do crash recovery. If any redo thread in ACD is marked as open in their checkpoint record, they need to be recover. This process is very similar to the crash recovery of the database. The redo between the checkpoint and the last write record is scanned to find out which blocks need to be restored. These blocks will be read and redo applied.

Redo thread selection

You need to find an unused area in the ACD to store the redo generated by this example. For the first instance of mount DG, you need to make sure that all thread is turned off, so that the smallest thread will be available. If it is not the first instance of MOUNT DG, the entire ACD may have been used. If you encounter this scenario, the instance in mount will require the mount instance to extend ACD. Once the ACD expands the new area to hold the generated redo, another redo thread will be marked as OPEN in the form of writing out to checkpoint block.

First done

If it is the first instance of mount DG, it will begin to allow other instances to mount the DG as well. If the first instance is crash before this step, the other instances will consider themselves to be the first instance of mount DG. Then the subsequent mount can run in parallel in a cluster with more than 2 instances.

Registration

The instance registers the DG information of its mount with the CSS. The database instance that attempts to access these DG will discover the CSS registration information and connect to the ASM instance to access the DG.

COD recovery

If it is the first instance of mount DG, it checks the records in COD and rolls back any actions that need to be rolled back. If a rebalance job is still in progress, the RBAL of the instance will restart rebalance.

Dismount Disk Group

Just as mount is a local operation of an ASM instance, so is dismount. Under normal circumstances, regular dismount is not allowed when the local database instance also accesses files in diskgroup. If no files are opened for access, dirty blocks in ASM buffer cache will be written out to disk, and checkpoint records in ACD will be marked as thread closed. And the part of the SGA that describes the diskgroup will be released.

Mandatory FORCE Dismount Disk Group is also a common occurrence, and a mandatory dismount is automatically triggered when a disk failure results in an intolerable redundant algorithm. For example, when the data under external redundancy is not mirrored, there is no choice but to force dismount when the cache cannot be written out in ASM.

Add Disk

The command to add disk add disk will identify the disk for the specified discovery strings. If the disk found at this time is already part of disk group, it will be ignored by default. The disk will be allowed to be added to the diskgroup if:

The disk cannot be part of an already mount diskgroup without a valid ASM disk header, unless the FORCE option must be used without a valid ORACLE data file header, unless the FORCE option FORCE option is used if the user must not be advised not to use it, to avoid abuse it must not be visible with 2 different pathnames at the same time it must be matched by asm_diskstring

When all disks have been verified above, the following steps will be performed:

The records Free Space block and allocation table added to the disk in Disk Directory will be written to the disk Disk header will be updated with the current timestamp the disk will be added to PST, but there is no partners yet, but it is already ONLINE capable of reading and writing. This will make the disk really a part of the diskgroup, even if the instance crash once rebalance will be started, which will find the partners for the new disk and move the data to it. It is generally recommended to add more than one disk at a time, rather than one at a time.

The add disk operation is returned when the rebalance starts. The disk is not fully involved in disk group until the end of rebalance.

ASM Drop Disk

Disks can be drop out of diskgroup as long as there is enough unused space on the remaining disks. Even if it is still in active use, it can still be drop. Regular drop can be done when the disk is still working but is not necessary for diskgroup. You can use the FORCE option if the disk fails. Drop disks will affect all instances of mount diskgroup. It is not an instance local operation.

ASM DROP Normal regular drop

Under a regular drop disk, the disk will be marked as non-redistributable and a rebalance will be started. The drop command returns when rebalance starts. During the rebalance process, the disk in the drop will continue to be moved to other disks. When the rebalance is complete, the disk will be removed from the disk group and can be reused. You can confirm that the disk is still part of disk group by querying V$ASM_DISK.

While rebalance is still in progress, disk will be in the state of being drop, that is, dropping. You can also reverse the effect of this unfinished drop command by calling alter diskgroup undrop. In this way, non-redistributable flags on the disk will be removed and a rebalance will be restarted. This rebooted rebalance will re-evaluate the partnerships of the disk we are drop and may move the data data extent back to the disk being dropping. This rebooted rebalance only needs to undo the work done by the previous rebalance, so the time it takes depends on the amount of rebalance of the previous drop work. The final distribution may be slightly different from the beginning, but it will still be balanced.

ASM DROP Force force drop

For Normal or High Redundancy disk group, a disk can be DROP using the FORCE option. The FORCE option is not available for external redundancy's disk group because it is not possible to properly reconstruct data from the disk that was dropped by drop. For disk group of normal or high redundancy, FORCE DROP may not be allowed if one or more disks partners is already OFFLINE. It is always not allowed when FORCE DROP may cause the loss of data on the file.

FORCE DROP immediately sets the disk state to OFFLINE. All extent on this disk will be separated from their corresponding extent set collections, which means less redundancy. The disk will be removed from disk directory, as will be the case with PST.

The disk header of the disk will be written to indicate that it is no longer part of disk group. Rebalance will also be started. When the drop force command returns, it means that the disk has been completely removed from the disk group and can be reused or disconnected from the operating system.

The redundancy of all files on the disk group where the operation takes place will not be improved until rebalance. Unlike regular drop, it is obvious that force drop cannot be undrop. The disk will be completely removed from diskgroup, so undrop cannot undo this operation; all you can do is add the disk back to diskgroup, add disk.

How to connect a database instance to ASM

When a database instance tries to open or create a file whose name starts with "+", it uses CSS to view disk group and mount the information of the ASM instance of the DG. If the database instance has previously accessed files in other Disk Group, the same ASM instance will be used. If this is the first time to access a file on ASM, the database instance needs to connect to the ASM instance. The following steps are prepared for the database instance to access files on ASM:

The background process ASMB starts and connect connects to the ASM instance. The extent map disk chart of any file opened by the database instance is sent to the ASMB background process. It has an obligation to maintain extent map. If any extent shift occurs, the ASM instance updates the ASMB process sent to the database instance. The ASMB O statistics are periodically fed back to the ASM instance by the ASM process.

The RBAL background process starts, which opens all disks under disk group globally, which is similar to the DBWR process opening data files globally. This global open allows the database instance to access any file in diskgroup. If there are other diskgroup to be accessed, RBAL will also open all the disks under the corresponding diskgroup. RBAL also opens and closes disks that add joins or drop. Messages about the disk are first sent to ASMB, and then ASMB is forwarded to RBAL.

A connection pool is created and a set of slave processes establishes a connection to the ASM instance. Database processes need to use these slave processes if they need to send information to ASM instances. For example, if you open a file, a request for OPEN will be sent to ASM through slave. However, slave is not used for long-running operations such as creating files.

ASM file Create file creation

The process of file creation is that the database sends a request to the ASM instance, and the ASM creates the file and responds to the request.

When you create a file, it allocates space for it and opens it for reading and writing. Once the file is initialized, the creation is submitted. If the created file is not submitted, the file is automatically deleted. The steps are as follows:

The database process calls the service layer code to create a file whose name starts with "+", and the system will automatically return a generated name. If the full path is given in the file name, a user alias will be created and returned. The call also includes file type, block size, initial file size, and other information about the file name claimed by the build system.

The database process connects to the ASM instance, where connection pool connection pooling is not used because file creation requires that the connection be kept within the same connection. This avoids the deadlock that can be caused by using too many connection pooled connections.

The database process sends a creation request to the ASM instance and needs to wait for the extent map of the new file to be loaded into the database instance

The ASM foreground process assigns a record in the file directory to the new file and creates a rollback record in COD continuing operations directory to delete the file. If the connection is broken, the ASM foreground process crashes, or the database aborts the creation, the file is automatically deleted when the operation is rolled back.

The ASM process allocates extent to the file so that it is evenly distributed across all disks in the disk group.

The ASM instance sends extent map to the ASMB process of the database instance

The ASM foreground process returns the file name to the database process, and the database process keeps the connection with the ASM process open

The database process initializes the contents of the new file and can make a resize request to expand or shrink the file

When the content and size of the file are initialized, a request to submit the creation will be sent to the ASM foreground process

The ASM foreground process creates a record of the system-generated file name in the alias directory. If there is a user-specified alias, the alias filename will also be added to the alias directory

ASM marks the file as created successfully and deletes the rollback record

Because the commit creation will also close the file, the ASM instance tells the database ASMB process to release its extent map

The ASM foreground process returns information that the file was successfully created to the database process. The database process closes the connection to the ASM instance, which terminates the corresponding ASM foreground process

The above files have been successfully created and can be opened by any process

Extent Allocation extent allocation

Allocate the extent Allocating extents and publish the files evenly on all disks in the disk Group. Each disk has a weight, which is based on its size. Data extents under extent set must be assigned between disk partnerships. The primary extent allocation of each extent set will distribute the files according to the weight of the disk. The next primary extent of the file will be allocated as much as possible on disks that make the file distribution more balanced. In this way, the primary extent of the same file on the same disk will be as far as possible.

The secondary extents for Normal or high redundancy files must be allocated for multiple redundant copies of primary extent. The secondary extents ideal is evenly distributed over the partners disk of the disk where the primary extent is located, which is also based on the disk weight. Another requirement for high redundancy is that two secondary extents need to be allocated on different failure group.

FILE Delete ASM file deletion

Files on ASM can be deleted through the database instance or by entering a SQL command in the ASM instance. The database instance can send a delete delete request through the slave process in the connection pool. If the file is still open, the file cannot be deleted temporarily. For an open file, each ASM instance will hold a global lock to prevent it from being deleted. The rollback record will also step in to ensure that if the deletion starts, it must be completed.

FILE OPEN ASM file open

When a process under a database instance opens an ASM file, it uses the connection pool slave process to send a request to the ASM instance. The ASM foreground process looks at the files under alias directory or uses the file number and incarnation information in the system-generated file name. The ASM foreground process acquires the file lock and sends extent map to the ASMB process of the database, which is stored in SGA. Once the extent map is successfully loaded, ASM returns the success information to the database process. The database process uses extent map to convert file access to the appropriate disk IO. Each extent pointer stores a check detection value to capture the presence of corrupted extent map.

If one process of the database instance opens a file, other processes can use the same extent map. So only the first process needs to contact the ASM instance. The other processes of the database instance sit back and enjoy the success.

FILE Close closes files

When all processes in the database instance close a file, the connection pool connection pool slave process sends a close message to the ASM instance. The ASM instance notifies the ASMB process of the database to shut down extent map and free the memory occupied by extent map. When ASMB shuts down the process, it releases the file lock.

IPUBO error

Normal or high redundancy's disk group can tolerate a variety of IO errors. The way these IO errors are handled is based on the type of Ihand O: read or write? And the reason of its Icano. The most common way to deal with this is to drop the problem disk OFFLINE when an IZP O error occurs. If dropping the disk OFFLINE will make part of the data unavailable, the mandatory Disk Group Dismount will be started. Doing so makes it possible to attempt to restore rewrites from other nodes or after the problem has been fixed. The disk cannot be offline under external redundancy. Two disks that are partners each other under normal redundancy cannot be OFFLINE at the same time. 2 partners under high redundancy can be OFFLINE, while other partners can no longer be OFFLINE. If an error causes disk group to be forced dismount, no disk will be OFFLINE. If there is a problem with writing two pieces of data under normal disk group, it will not OFFLINE the disk.

If a disk wants to OFFLINE, first require all database instances and ASM instances to mark it as OFFLINE in their own SGA, in case it is still being read. The behavior of the disk OFFLINE due to the IPUBO error is not considered complete until all processes stop reading the disk.

ASM FILE read file reading

Note that the reading of the file data is still done by the database instance itself, not the ASM instance. Typically, primary extent is always read unless the corresponding disk OFFLINE. Secondary extents is used if the disk on which primary extent is located is OFFLINE or if the read fails. If both primary and secondary extents fail to read, an I _ secondary extents O error will be returned to client. Failure to read files usually does not result in disk OFFLINE or disk group dismount.

ASM FILE Write writes files

Writing file data is also done by the database instance itself, not by the ASM instance. If an IO error occurs in any write, the error is sent to the ASM instance through the connection pool slave connection pool subprocess. The ASM instance either OFFLINE or dismount diskgroup the disk, and updates the disk status through the connection to ASMB. The database process or restart the previous write-out. Because writing out will no longer be written to OFFLINE's disk, retrying to write will generally succeed, unless diskgroup is also given to dismount.

Instance Recovery instance recovery

ASM instance recovery instance recovery is very similar to database instance recovery. The biggest difference is that ASM instances mount multiple disk group, and different disk group can be used by multiple instances. Instance recovery is based on each disk group. In RAC, if an instance forcibly dismount a diskgroup, another ASM instance must be the instance recovery of the diskgroup, even if the previous dismount instance of the diskgroup is not terminated. ASM instances only do instance recovery for disk group that they have already mount. In RAC, if an ASM instance has already mount 2 disk group and crashes unexpectedly, the recovery of these two disk group may be completed by other ASM instances of the cluster.

Instance recovery instance recovery first scans the redo in ACD to build a list of blocks that need to be restored. Redo will be applied to the block, and the block will be written back to diskgroup. The new lock can then be requested to access the metadata metadata on the diskgroup. Note that the instance recovery of the ASM instance is only related to ASM metadata. The data in the file is recovered by the database instance itself.

The ASM instance that is executing the instance recovery after the redo application will detect the data in the COD, and if there was a rebalance running in the previous crashed instance, consider restarting the rebalance if necessary. Any rollback operation left by the previously crashed ASM instance will be completed.

Rebalance

When one or more disks are added, drop, or resize, disk group does rebalance to ensure that all storage is used evenly. Rebalance mobile data is not based on IWeibo statistics, nor is it the result of other statistics. Based entirely on the size of each disk in disk group. It starts automatically when the storage configuration changes, or it can be initiated manually. Manual intervention is generally not recommended. Manual intervention is required when you need to modify the rebalance power or transfer the rebalance operation to other nodes. Rebalance occurs on the instance on which the command is executed when manually intervening.

Here are the brief steps for rebalance:

Repartner re-pairing

When a disk is added to the diskgroup, it needs to pair the partners so that its own primary extent of the data can store the mirrored copy of its paired partners disk. Since ideally each disk already has the maximum number of paired partners, adding a new disk pairing relationship often means breaking some existing partners pairs. When drop the disk, its existing pairing relationship partnerships will have to be broken. This will cause some disks to have less than the ideal number of pairs. So the first step in rebalance is to recalculate a new set of pairing combinations. The new partnerships is selected based on moving the minimum amount of data. This is why it is best to add and drop multiple disks at the same time.

Calculate weights calculates weights

The goal of rebalance is to allocate each disk in disk group in the same proportion. So larger disks hold more file data. Here, a weight is calculated for each disk to determine how much data is stored on it. The weight is affected by disk size and pairing relationship.

Scan files scan files

Rebalance is made of one file, one file, and the extent map of the file will be scanned to determine how it should be balanced. To achieve balance, the existing extent set may be moved to other disks so that it can be balanced. This usually results in moving to the newly added disk. It is also possible to make the necessary movements for a new pairing relationship.

Extent relocation disk area shift

Shifting an extent requires the coordination of any Icano that occurs on that extent. All ASM instances in the cluster are notified of the start of the shift. This information will also be forwarded to all ASMB processes that have the database instance that opened the file, thus locking the corresponding extent. Any new writes to the corresponding extent will be blocked, but reads will not be affected. When the relocate operation ends, the existing write operation will be triggered again. The extent extent is read from the old location and written out to the new location based on the 1MB Imax O. The message of unlocking after the relocation is completed will be communicated and contain a new extent pointer. The extent map will be updated and the lock tag on it will be clear. Any outstanding writes will be allowed to continue to work. Any active query will be retriggered because the old extent may have been reused by other data.

There may be multiple slave processes that do relocation,power limit parameters at the same time to control the number of slave processes.

Restart starts over

There can be only one rebalance at a time. If the rebalance in progress is interrupted, it usually restarts automatically. If a node that is doing rebalance fails, rebalance will restart from its remnant. If the administrator manually modifies the power limit, it will also cause a restart. If another storage change occurs during the rebalance process, the entire rebalance will restart from the beginning

Check Disk Group detection disk group

The check disk group command compares redundant data structures in an disk group to ensure that no corruption occurs. The data structure will be locked during the detection, and the following actions will occur during the detection:

PST will be validated to ensure that all pairing relationships are symmetrical and valid. If disk A uses Disk B as the partner, Disk B is also the partner of Disk A. If Disk B does not exist or Disk An is not on the partner list of Disk B, an error is generated. An and B are certainly on different failure groups.

Extent Map will be checked against allocation tables. The allocation tables of all online disks will be scanned, and each assigned AU on the extent map will be confirmed. An allocation tables record for an assigned AU indicates the file number and data extent information for using the AU. The disk and AU information in the extent map of the file will be verified. If the file does not exist, or if the extent map points to a different AU, it will result in an error. Detection will also find AU that appear to have been assigned but are not part of any file.

Allocation tables will be checked against Extent Map. The extent maps of all files will be scanned, and the allocation record of each data extent will be confirmed to point to the file extent. The extent map record of data extent gives the disk number and AU number to which the extent is assigned. The allocation table record will be validated. If the disk is too small, or if the AU is not actually allocated, or if the AU is actually assigned to another file, or if the AU is actually assigned to another extent, it will cause an error. This detection can find AU that has been allocated twice, or AU that is marked as idle but has actually been used.

All the extent set were verified against the pairing relationship partnerships. Each secondary extent in each extent set is verified to be on the partner of the disk containing the primary extent. This will detect the loss of a pairing relationship.

If any of the above problems occur, an error will be reported, but the test will continue. Fixing inconsistencies often requires manual operations, such as the use of KFED.

Links to related articles:

Asm Instance Parameter Best Practice

Why is there no ASMLIB on RHEL 6?

How to view TRACE files with the file name beginning with "+ asm" on Unix

The influence of asm_power_limit on IO

Recovery measures for 11.2 RAC loss of OCR and ASM Diskgroup where Votedisk is located

10g ASM lost disk log

Uncover the secret of 11gR2 RAC ASM startup

Modify the ASM DISK Path disk path in 11gR2 RAC

Using UDEV on Linux 6 to resolve RAC ASM storage device name issues

Script: find the Spfile parameter file in ASM

How to diagnose ASMLIB faults

Script: collecting ASM diagnostic information

Comparation between ASM note [ID 373242.1] and note [ID 452924.1]

Why ASMLIB and why not?

ASM file metadata operation wait event

Several questions about oracle 11g ASM

Using UDEV Service to solve RAC ASM Storage device name

Discover Your Missed ASM Disks

Oracle Internal View X$KFFXP

Fixed X$ Tables in ASM

Understand the MAP files generated by the AMDU tool

Use the AMDU tool to extract data files from DISKGROUP that cannot be MOUNT

In-depth understanding of Oracle ASM (1): basic concepts

About Me

.

● this article is compiled from the network http://www.askmaclean.com/archives/know-oracle-asm-basic-html.html

● article is updated synchronously on itpub (http://blog.itpub.net/26736162), blog Park (http://www.cnblogs.com/lhrbest) and personal Wechat official account (xiaomaimiaolhr).

● article itpub address: http://blog.itpub.net/26736162/abstract/1/

● article blog park address: http://www.cnblogs.com/lhrbest

● pdf version of this article and wheat seedling cloud disk address: http://blog.itpub.net/26736162/viewspace-1624453/

● database written examination interview questions database and answers: http://blog.itpub.net/26736162/viewspace-2134706/

● QQ group: 230161599 WeChat group: private chat

● contact me, please add QQ friend (646634621), indicate the reason for adding

● was completed in Mordor from 09:00 on 2017-06-02 to 22:00 on 2017-06-30.

The content of the ● article comes from the study notes of wheat seedlings, and some of it is sorted out from the Internet. Please forgive me if there is any infringement or improper place.

Copyright ● all rights reserved, welcome to share this article, please reserve the source for reprint

.

Pick up your phone and use Wechat client to scan the picture on the left below to follow the Wechat official account of wheat seedlings: xiaomaimiaolhr, scan the QR code on the right to join the QQ group of wheat seedlings, and learn the most practical database technology.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.