ASM in Oracle 11g includes advances that can exploit the performance of SSDs. The features of Preferred Mirror Read and Fast Mirror Resync are the two most prominent features that fit in this category.
Preferred Read Failure Groups
The Preferred Read is not a new idea, but is implemented in Oracle’s volume management in Oracle 11g. The concept is to read from the storage that can present the needed data at a lower latency. Initially, this was designed for WAN or site-specific storage in order to avoid higher-latency site connections. By restricting data reads to the local storage, the application would be able to service requests at nominal read speeds while writes were the only communication needed to traverse the long haul site link. This is a feature that is available to most Operating Systems with their included volume manager and as a feature to Symantec/Veritas through the title Preferred Plex.
As each node of a cluster runs its own instance of ASM, each node can also define its own preferred read failgroup. This allows for each node to operate at top performance with its local storage.
The Preferred Read Failure Groups are assigned in the initialization parameter ASM_PREFERRED_READ_FAILURE_GROUPS. The syntax for the failgroups is designated by DISKGROUP.FAILGROUP and comma-separated if working with multiple diskgroups.
The advantage of Preferred Reads for SSD is not in avoiding the intersite links. Since the concept of preferred reads is to read from a lower latency mirror, the strategy of preferring the reads from a SSD mirrored to HDD can also be employed. This allows SSDs to be deployed with full redundancy at a much lower cost by mirroring to HDD.
The preferred read allows for overall increases in performance. The read performance of course will be serviced at the speed of the SSD where SSDs excel. The writes on the other hand, will be as fast as the slowest disk member. This not a problem for tables and indexes as only reads result in foreground waits, while writes are performed in the background by the lazy writer. Also, since there is no longer a read+write contention on the disk, the disks can now focus performance on solely doing writes. This also emphasizes the gains from write-cached arrays as it allows the disk to service the writes in bursts from Oracle’s lazy writer. This architecture is not recommended for redo, undo, or temp where writes result in foreground waits.
The Preferred Read does not change the application’s read/write ratio. In order for the application to scale with the SSD, the writes must not become the bottleneck prematurely. An excellent option is to deploy a small diskgroup composed of RAM SSDs for the database logs, and deploy FLASH SSDs alongside disks with the preferred read mirror setting for the tables and indexes. This way all of the blocking I/O requests are served from SSD and the HDD merely provides inexpensive redundancy.
Fast Mirror Resync
Oracle 11g includes the Fast Mirror Resync which tracks the changed extents for a given window of repair, a default value of 3.6 hours. If a disk goes offline, then ASM will track the extents associated with the disk. When the disk is recovered and brought online (knowing that all previous data is still intact) the list of changed extents are applied to the recovered disk. This is extremely useful when working with very large LUNs.
For alls systems (SSDs and spinning disks) that undergo offline maintenance or code updates, the Fast Mirror Resync reduces maintenance impact dramatically. The system can be taken offline and quickly serviced and then added back to ASM and only the extents that changed while the service was performed are synchronized. Without the Fast Mirror Resync, ASM would have to completely rebuild the mirror which could take a long time.
The window for disk recovery can be set at a DiskGroup scope with the DISK_REPAIR_TIME attribute or it can be manually set when offlining a disk for scheduled maintenance. If a system is scheduled for 1 hour of maintenance, be sure to allocate enough time for unforeseen issues with a larger maintenance window and longer “DROP AFTER” clause.
ALTER DISKGROUP TIER0 OFFLINE DISK SSD01 DROP AFTER 4h;
This would allow for a recovery window of 4 hours for the expected 30 minute maintenance. When the LUN is reinstated with the ONLINE DISK command, all changed extents are rebalanced to the recovered disk.
Conclusion
The high availability, performance gain, and ease of management lead ASM to a win for storage management. Preventing hot spots on disks intuitively leads to lower mechanical costs. Ease of management incurs lower operations costs. With higher performance, the fundamental cost per transaction is also reduced, and, by using an industry-leading database engine to serve storage, security and availability are not compromised.
The fundamental compliment of ASM with tiered storage gets more value to the investment. SSD technology with ASM management can also ensure uptime without interruption to day-to-day operations, even in times of maintenance. Higher numbers of transactions through lower latency and higher throughput from unburdened disk storage illustrates the raw performance gain of using ASM with tiered storage.
Showing posts with label Oracle ASM. Show all posts
Showing posts with label Oracle ASM. Show all posts
Thursday, April 19, 2012
Friday, April 13, 2012
Oracle Guidelines for ASM
There are many suggestions that Oracle has provided in order to achieve the greatest benefits from ASM. Overall, ASM is a very favorable and proven application. The design of ASM is still progressing, it was a new feature implemented in Oracle 10g and has developed more of its promise in 11g. Remember that a guideline is just that, a guide, not necessarily applicable to your situation, always take any best practice with a grain of salt. The following are considered good practices when using ASM:
1.) Separate the ASM Home from that of any normal database
Since ASM does run as a lightweight and independent database it should have a separate $ORACLE_HOME or $HOME. When using the Oracle Universal Installer (OUI) it places ASM in an independent home automatically. For best practice, the ASM home directory should be kept separate from that of any other database, despite that database’s dependency. By default, when using the DBCA, creating an initial database for ASM will result in a separate ASM directory. To initialize ASM with its own $ORACLE_HOME or $HOME directory, use the Universal Installer and follow the steps from the Oracle Database Installation Guide regarding Installing ASM.
By using a separate $ORACLE_HOME or $HOME for ASM, DBAs can manage the database(s) dependent upon ASM with upgrades, backups and recovery without having to interfere with ASM operations. Also, if multiple databases are reliant upon ASM while one database shares the $ORACLE_HOME or $HOME with ASM, management of the databases becomes exceptionally complicated.
For ASM management, the ASM database can be patched or upgraded independently of the dependent databases as long as home directories are separate. The backwards compatibility of ASM ensures that these steps can proceed without having to migrate storage between upgrades.
2.) Use homogenous diskgroups
Every disk in a diskgroup is treated the same (with the exception of the “Preferred Mirror Read” discussed in the next section). Therefore, high-speed drives will only exhibit their performance if grouped with other high-speed drives. Stripe performance of a hybrid diskgroup will be virtually equivalent to that of a diskgroup of the slowest type disk. This is known as the convoy affect.
3.) Assign task-specific diskgroups for tiered storage
Although ASM makes exceptionally efficient use of available disks, performance characteristics are only chartered through the ASM templates with extent size. Oracle suggests using a limited number, 2 specifically, of diskgroups. In smaller deployments, limiting the number of diskgroups but increasing the number of disk members will highlight the performance of ASM. In large-scale deployments, however, tiered storage with task-specific diskgroups will provide the greatest performance. With the RAM-based SSD as the premier solution for the hot-files atop the tiered storage pyramid, it is necessary to isolate the system into its own diskgroup. Frequently accessed data files should be placed on Flash-based storage, in its own diskgroup, with high performance disk based storage used for the remainder. Again, the performance of these drives is not exhibited if grouped with lower speed storage.
Archive and recovery storage should be kept on a large deployment of slower disks, potentially non-SCSI disks. ASM can provide significant bandwidth of data written to these drives, given the sequential data patterns of the archive storage in Oracle. With a sufficiently large diskgroup, the capacity, availability, and performance requirements can be met for the readily available data files of large-scaled databases.
This strategy conflicts with the concept of a minimal number of diskgroups, but it can be quite favorable to the performance of the database, especially when multiple classes of storage are available. To host multiple databases on a single ASM instance, this strategy can be scaled further to provide an even larger diskgroup for the data files and isolated log file diskgroups for each database.
4.) Take advantage of multipathing
Multipathing provides performance gains in throughput and data protection against path failure. Almost all multipathing solutions available to each Operating System are thoroughly tested and provide full compatibility with ASM.
Taking advantage of cache-enabled SANs can offer better response times than disks can deliver. In such cases, it is important to note the precautions of such a practice; cache front-ends can often fill quickly and as applications grow performance can suffer. In such an event, many disk systems will suffer poorer than average performance because the clients, as well as the cache contents, are continually reading/writing to the spindle. In write-intensive or low latency applications, be wary of using cache-enabled SANs because the de-staging process can be detrimental to the clients and customers.
5.) Allocate enough reserve capacity for groups where disk failures are probable
In the event that a disk failure occurs in a diskgroup with mirroring enabled, a second failure could result it lost data. In order to minimize this risk ASM will attempt to get back to full redundancy as quickly as possible, but space must be available on all other members of the failgroup to accommodate the capacity of the failed disk. This type of protection can be ensured as long as the free space in a diskgroup (taking into account the redundancy level) is greater than the size of a single disk.
For example: Say six 73GB disks are used in a single diskgroup (438 GB total) with normal redundancy (mirroring), and each disk is be holding 50GB of ASM data, leaving approximately 23GB of unused capacity. If a disk member fails, then ASM will immediately rebalance and create new backup extents in order to maintain normal redundancy. The 50GB of ASM data that is no longer available is repopulated evenly amongst the remaining drives in the failgroup. This results in each of the remaining drives using an additional 10GB of data (50GB divided by the remaining 5 disks). The free space available (23*6 = 138 GB) was greater than the size of a single disk so redundancy can quickly be ensured. However, the redundancy will be lost if a second disk fails before a replacement is added. After the first rebalancing each disk member containing now contains 60GB of ASM data and 13 GB of free space (13 * 5 = 65 GB total – less than the size of a single disk). If a 2nd disk were to fail, there would not be sufficient space available to allocate 15GB (60GB divided by remaining 4 disks) to each disk.
6.) Use External Redundancy for diskgroups from Arrays that Provide Mirroring and Replication
Duplicating data onto an already-duplicated storage medium can be overly redundant. This protects against a catastrophic failure, but array level replication may be providing protection against this already. The external redundancy is in effect disabling using ASM to provide redundancy.
7.) The default initialization parameters are fine, except for processes
Set processes according to this formula:
processes = 40 + (10 + [max number of concurrent database file creations, and file extend operations possible])*n
Where n is the number of databases connecting to ASM (ASM clients).
By following these best practices, the highest performance can be achieved using ASM.
1.) Separate the ASM Home from that of any normal database
Since ASM does run as a lightweight and independent database it should have a separate $ORACLE_HOME or $HOME. When using the Oracle Universal Installer (OUI) it places ASM in an independent home automatically. For best practice, the ASM home directory should be kept separate from that of any other database, despite that database’s dependency. By default, when using the DBCA, creating an initial database for ASM will result in a separate ASM directory. To initialize ASM with its own $ORACLE_HOME or $HOME directory, use the Universal Installer and follow the steps from the Oracle Database Installation Guide regarding Installing ASM.
By using a separate $ORACLE_HOME or $HOME for ASM, DBAs can manage the database(s) dependent upon ASM with upgrades, backups and recovery without having to interfere with ASM operations. Also, if multiple databases are reliant upon ASM while one database shares the $ORACLE_HOME or $HOME with ASM, management of the databases becomes exceptionally complicated.
For ASM management, the ASM database can be patched or upgraded independently of the dependent databases as long as home directories are separate. The backwards compatibility of ASM ensures that these steps can proceed without having to migrate storage between upgrades.
2.) Use homogenous diskgroups
Every disk in a diskgroup is treated the same (with the exception of the “Preferred Mirror Read” discussed in the next section). Therefore, high-speed drives will only exhibit their performance if grouped with other high-speed drives. Stripe performance of a hybrid diskgroup will be virtually equivalent to that of a diskgroup of the slowest type disk. This is known as the convoy affect.
3.) Assign task-specific diskgroups for tiered storage
Although ASM makes exceptionally efficient use of available disks, performance characteristics are only chartered through the ASM templates with extent size. Oracle suggests using a limited number, 2 specifically, of diskgroups. In smaller deployments, limiting the number of diskgroups but increasing the number of disk members will highlight the performance of ASM. In large-scale deployments, however, tiered storage with task-specific diskgroups will provide the greatest performance. With the RAM-based SSD as the premier solution for the hot-files atop the tiered storage pyramid, it is necessary to isolate the system into its own diskgroup. Frequently accessed data files should be placed on Flash-based storage, in its own diskgroup, with high performance disk based storage used for the remainder. Again, the performance of these drives is not exhibited if grouped with lower speed storage.
Archive and recovery storage should be kept on a large deployment of slower disks, potentially non-SCSI disks. ASM can provide significant bandwidth of data written to these drives, given the sequential data patterns of the archive storage in Oracle. With a sufficiently large diskgroup, the capacity, availability, and performance requirements can be met for the readily available data files of large-scaled databases.
This strategy conflicts with the concept of a minimal number of diskgroups, but it can be quite favorable to the performance of the database, especially when multiple classes of storage are available. To host multiple databases on a single ASM instance, this strategy can be scaled further to provide an even larger diskgroup for the data files and isolated log file diskgroups for each database.
4.) Take advantage of multipathing
Multipathing provides performance gains in throughput and data protection against path failure. Almost all multipathing solutions available to each Operating System are thoroughly tested and provide full compatibility with ASM.
Taking advantage of cache-enabled SANs can offer better response times than disks can deliver. In such cases, it is important to note the precautions of such a practice; cache front-ends can often fill quickly and as applications grow performance can suffer. In such an event, many disk systems will suffer poorer than average performance because the clients, as well as the cache contents, are continually reading/writing to the spindle. In write-intensive or low latency applications, be wary of using cache-enabled SANs because the de-staging process can be detrimental to the clients and customers.
5.) Allocate enough reserve capacity for groups where disk failures are probable
In the event that a disk failure occurs in a diskgroup with mirroring enabled, a second failure could result it lost data. In order to minimize this risk ASM will attempt to get back to full redundancy as quickly as possible, but space must be available on all other members of the failgroup to accommodate the capacity of the failed disk. This type of protection can be ensured as long as the free space in a diskgroup (taking into account the redundancy level) is greater than the size of a single disk.
For example: Say six 73GB disks are used in a single diskgroup (438 GB total) with normal redundancy (mirroring), and each disk is be holding 50GB of ASM data, leaving approximately 23GB of unused capacity. If a disk member fails, then ASM will immediately rebalance and create new backup extents in order to maintain normal redundancy. The 50GB of ASM data that is no longer available is repopulated evenly amongst the remaining drives in the failgroup. This results in each of the remaining drives using an additional 10GB of data (50GB divided by the remaining 5 disks). The free space available (23*6 = 138 GB) was greater than the size of a single disk so redundancy can quickly be ensured. However, the redundancy will be lost if a second disk fails before a replacement is added. After the first rebalancing each disk member containing now contains 60GB of ASM data and 13 GB of free space (13 * 5 = 65 GB total – less than the size of a single disk). If a 2nd disk were to fail, there would not be sufficient space available to allocate 15GB (60GB divided by remaining 4 disks) to each disk.
6.) Use External Redundancy for diskgroups from Arrays that Provide Mirroring and Replication
Duplicating data onto an already-duplicated storage medium can be overly redundant. This protects against a catastrophic failure, but array level replication may be providing protection against this already. The external redundancy is in effect disabling using ASM to provide redundancy.
7.) The default initialization parameters are fine, except for processes
Set processes according to this formula:
processes = 40 + (10 + [max number of concurrent database file creations, and file extend operations possible])*n
Where n is the number of databases connecting to ASM (ASM clients).
By following these best practices, the highest performance can be achieved using ASM.
Wednesday, April 11, 2012
An Oracle ASM Primer
Oracle Automatic Storage Manager (ASM) is a mature product capable of replacing high-cost disk management software for most Oracle applications. In this first blog of a series on ASM we will review ASM basics.
Automatic Storage Management (ASM) is an all-inclusive approach to storage management, performance, and availability. ASM is an excellent tool for managing mixed storage environments where both SSD and HDD technologies are being used. It is an intrinsic block manager database that balances file access across disks and disk subsystems to eliminate hotspots and increase storage efficiency. By striping extents across diskgroup members and mirroring across failgroups, ASM can generate RAID performance and protection at the file-level of databases. ASM can also be used in conjunction with high-end disk arrays for mixed-storage file management.
ASM operates as a lightweight Oracle database and offers the stability and reliability of a standard Oracle database. Therefore, multiple databases can be clients to a single ASM instance. This will allow a single pool of disks to be efficiently used for various databases. In addition, ASM can be used in a RAC environment where ASM failover can occur nearly seamlessly between active nodes, permitting non-stop uptime for storage management.
ASM does not have to replace, but can complement, disk subsystems and arrangements for efficient use in specific files. ASM will not automatically separate storage areas in diskgroups for log files, archived backups, or database files. ASM templates assist in the striping performance of each type of file, but sequential I/O is not differentiated from random I/O. It is still the duty of the architect to specify storage for specific roles. Sequential access log files should traditionally be held separate from the random-I/O generated by database files. This is not a flaw in ASM but a continuing practice of tiered storage and disk speeds. ASM is most effective when diskgroups are allocated with single homogenous disks as their components.
The use of high-speed SSD highlights the benefits of ASM. When multiple devices are available, the striping performance of ASM can linearly increase the throughput of the storage, reducing the response time to the client. In situations where extremely low-latency is needed, such as log writes, the impact of mirroring with ASM is still negligible and the performance promises of a single SSD are still met.
Figure 1: Tiered Storage Pyramid
ASM Internals
ASM provides its striping through a default of 1MB file extents with normal disk arrays and 4 MB extents if used within an Exadata cell. By striping across files instead of blocks, multiple files can be used on a single ASM instance but have independent levels of redundancy. Log files and database files are often held at a normal redundancy while control files are often in triplicate for extra protection. In addition, the default template for ASM specifies the extent size for each file. Control files and log files are assigned a smaller extent size of 128K while larger, more bandwidth-intensive operations default to 1MB extents. Testing in Oracle’s development labs showed the 1MB size as the most balanced size in bandwidth and latency and concurrency of access.
ASM will utilize disks in what may appear as a very sporadic layout. Extents are not sequential in disks or failgroups. The first extent may be on Disk 1, but the second extent may be on Disk 3 of the third failgroup. In addition, ASM will place extents throughout lengths of disk space. This results in the even use of disk platters and prevents hotspots within the disks themselves. The only guarantee in the placement of extents is the mirrored extent located in a different failgroup. All disks will be used as evenly as possible to prevent any disk having higher utilization than others. This is demonstrated in Figure 2.
Figure 2. ASM Internal Layout
From the layout in Figure 2, each disk contains an original extent and backup extents (B) are assigned to a non-correlating disk in a separate failgroup. It is evident that ASM can take full advantage of the disks included. Reading from the disk provides efficient use of the disks as a fully striped volume. Write performance is equivalent to that of a RAID10 as half the disks are written while the other half serves as a mirror to the file extent. Through this behavior, the performance gain is much greater than a standard mirrored array but still provide the redundancy necessary for file protection. If failgroups are assigned appropriately, then ASM will also continue to serve even amidst a controller failure.
Because ASM is a lightweight database, managing ASM is done with a limited command set nearly equivalent to that of a standard Oracle database. Management such as the assigning of disks to diskgroups and failure groups can also be done through GUI interfaces such as DBCA. The v$ Dynamic Views within ASM call the system-based functions directly to eliminate a layer of administration. When querying the v$asm_disk view with a standard SELECT statement, Oracle will automatically initiate a rescan of the SCSI bus to detect any new devices attached to the server. The v$asm_disk_stat and v$asm_diskgroup_stat return the current rows for the ASM instance without the inherent system calls of scanning for disks.
Diskgroups and Failgroups
A diskgroup is a set of disks defined to work in tandem to provide a single volume. Such as drive letter access in Windows (X:\), a diskgroup is given an ASM pseudo-filesystem to be accessed through the same reference by a file. All files located on ASM are referenced by the following:
“+\\filename”
where the + sign indicates ASM storage.
To navigate the ASM-based storage on disks through a filesystem interface, Oracle provides the ASMCMD executable. ASMCMD operates as an interactive shell for ASM in which you can view, delete, and alias ASM-based files and directories. The DBA may perform the same functions through an SQL terminal, but ASMCMD provides a more direct approach.
Diskgroups can be created with 3 different levels of redundancy: Normal, High, and External. Many expensive disk arrays rely on internal mechanisms for data protection. The External level of protection does not feature any duplication of data in the ASM diskgroup, but simply includes the volume into the ASM volume manager. This feature is commonly used for expensive SANs. These arrays typically hold cache-substitutes for dropped disks or can allocate a replacement disk from a hot-spare almost immediately. However, catastrophic failures are only sustained through mirroring systems.
Normal redundancy offers a 2x to 3x mirror level while High redundancy specifies a 3x mirror. This allows ASM to provide redundancy rather than requiring the purchase of a SAN that guarantees no single point of failure. These mirror levels specify the number of entries each extent will have on a diskgroup. ASM will provide the mirroring across specified failgroups. A failgroup is a subset of a diskgroup that defines a point of failure. This provides consistency across controllers and paths, in addition to disks. With Normal redundancy, each mirrored extent is guaranteed to be located on a failgroup separate from the original extent. With this configuration, the primary copy may fail, along with an entire failgroup, but the corresponding failgroup will contain data fully consistent with that of the original data. The 3x mirror will attempt to mirror across three failgroups. If there are only 2 failgroups in the setup, then the third copy will be duplicated within a failgroup but held on a separate disk if possible.
Enterprise SSDs offer protection against data corruption and power loss. However, uptime during maintenance can only be upheld through mirroring. ASM copies each extent to a non-corresponding location in a different failgroup. For system mirroring, failgroups would be defined as all drives included within a single system. Oracle recommends setting failgroups across controllers. The primary exception to this rule is to apply multipathing. Multipathing will increase throughput, provide failover, and will not require additional space allocated for mirroring the disk.
In my next blog I will discuss good practices for ASM when used with SSDs.
Automatic Storage Management (ASM) is an all-inclusive approach to storage management, performance, and availability. ASM is an excellent tool for managing mixed storage environments where both SSD and HDD technologies are being used. It is an intrinsic block manager database that balances file access across disks and disk subsystems to eliminate hotspots and increase storage efficiency. By striping extents across diskgroup members and mirroring across failgroups, ASM can generate RAID performance and protection at the file-level of databases. ASM can also be used in conjunction with high-end disk arrays for mixed-storage file management.
ASM operates as a lightweight Oracle database and offers the stability and reliability of a standard Oracle database. Therefore, multiple databases can be clients to a single ASM instance. This will allow a single pool of disks to be efficiently used for various databases. In addition, ASM can be used in a RAC environment where ASM failover can occur nearly seamlessly between active nodes, permitting non-stop uptime for storage management.
ASM does not have to replace, but can complement, disk subsystems and arrangements for efficient use in specific files. ASM will not automatically separate storage areas in diskgroups for log files, archived backups, or database files. ASM templates assist in the striping performance of each type of file, but sequential I/O is not differentiated from random I/O. It is still the duty of the architect to specify storage for specific roles. Sequential access log files should traditionally be held separate from the random-I/O generated by database files. This is not a flaw in ASM but a continuing practice of tiered storage and disk speeds. ASM is most effective when diskgroups are allocated with single homogenous disks as their components.
The use of high-speed SSD highlights the benefits of ASM. When multiple devices are available, the striping performance of ASM can linearly increase the throughput of the storage, reducing the response time to the client. In situations where extremely low-latency is needed, such as log writes, the impact of mirroring with ASM is still negligible and the performance promises of a single SSD are still met.
Figure 1: Tiered Storage Pyramid
ASM Internals
ASM provides its striping through a default of 1MB file extents with normal disk arrays and 4 MB extents if used within an Exadata cell. By striping across files instead of blocks, multiple files can be used on a single ASM instance but have independent levels of redundancy. Log files and database files are often held at a normal redundancy while control files are often in triplicate for extra protection. In addition, the default template for ASM specifies the extent size for each file. Control files and log files are assigned a smaller extent size of 128K while larger, more bandwidth-intensive operations default to 1MB extents. Testing in Oracle’s development labs showed the 1MB size as the most balanced size in bandwidth and latency and concurrency of access.
ASM will utilize disks in what may appear as a very sporadic layout. Extents are not sequential in disks or failgroups. The first extent may be on Disk 1, but the second extent may be on Disk 3 of the third failgroup. In addition, ASM will place extents throughout lengths of disk space. This results in the even use of disk platters and prevents hotspots within the disks themselves. The only guarantee in the placement of extents is the mirrored extent located in a different failgroup. All disks will be used as evenly as possible to prevent any disk having higher utilization than others. This is demonstrated in Figure 2.
Figure 2. ASM Internal Layout
From the layout in Figure 2, each disk contains an original extent and backup extents (B) are assigned to a non-correlating disk in a separate failgroup. It is evident that ASM can take full advantage of the disks included. Reading from the disk provides efficient use of the disks as a fully striped volume. Write performance is equivalent to that of a RAID10 as half the disks are written while the other half serves as a mirror to the file extent. Through this behavior, the performance gain is much greater than a standard mirrored array but still provide the redundancy necessary for file protection. If failgroups are assigned appropriately, then ASM will also continue to serve even amidst a controller failure.
Because ASM is a lightweight database, managing ASM is done with a limited command set nearly equivalent to that of a standard Oracle database. Management such as the assigning of disks to diskgroups and failure groups can also be done through GUI interfaces such as DBCA. The v$ Dynamic Views within ASM call the system-based functions directly to eliminate a layer of administration. When querying the v$asm_disk view with a standard SELECT statement, Oracle will automatically initiate a rescan of the SCSI bus to detect any new devices attached to the server. The v$asm_disk_stat and v$asm_diskgroup_stat return the current rows for the ASM instance without the inherent system calls of scanning for disks.
Diskgroups and Failgroups
A diskgroup is a set of disks defined to work in tandem to provide a single volume. Such as drive letter access in Windows (X:\), a diskgroup is given an ASM pseudo-filesystem to be accessed through the same reference by a file. All files located on ASM are referenced by the following:
“+
where the + sign indicates ASM storage.
To navigate the ASM-based storage on disks through a filesystem interface, Oracle provides the ASMCMD executable. ASMCMD operates as an interactive shell for ASM in which you can view, delete, and alias ASM-based files and directories. The DBA may perform the same functions through an SQL terminal, but ASMCMD provides a more direct approach.
Diskgroups can be created with 3 different levels of redundancy: Normal, High, and External. Many expensive disk arrays rely on internal mechanisms for data protection. The External level of protection does not feature any duplication of data in the ASM diskgroup, but simply includes the volume into the ASM volume manager. This feature is commonly used for expensive SANs. These arrays typically hold cache-substitutes for dropped disks or can allocate a replacement disk from a hot-spare almost immediately. However, catastrophic failures are only sustained through mirroring systems.
Normal redundancy offers a 2x to 3x mirror level while High redundancy specifies a 3x mirror. This allows ASM to provide redundancy rather than requiring the purchase of a SAN that guarantees no single point of failure. These mirror levels specify the number of entries each extent will have on a diskgroup. ASM will provide the mirroring across specified failgroups. A failgroup is a subset of a diskgroup that defines a point of failure. This provides consistency across controllers and paths, in addition to disks. With Normal redundancy, each mirrored extent is guaranteed to be located on a failgroup separate from the original extent. With this configuration, the primary copy may fail, along with an entire failgroup, but the corresponding failgroup will contain data fully consistent with that of the original data. The 3x mirror will attempt to mirror across three failgroups. If there are only 2 failgroups in the setup, then the third copy will be duplicated within a failgroup but held on a separate disk if possible.
Enterprise SSDs offer protection against data corruption and power loss. However, uptime during maintenance can only be upheld through mirroring. ASM copies each extent to a non-corresponding location in a different failgroup. For system mirroring, failgroups would be defined as all drives included within a single system. Oracle recommends setting failgroups across controllers. The primary exception to this rule is to apply multipathing. Multipathing will increase throughput, provide failover, and will not require additional space allocated for mirroring the disk.
In my next blog I will discuss good practices for ASM when used with SSDs.
Subscribe to:
Posts (Atom)
