Storage Challenges for DBAs
- Layout: Complex, time consuming, error prone
- Isolation practice: Inefficient, and costly
- Provisioning: Frequent, often requires new layout
- Performance: Complex problem determination
- Custom deployment: Each deployment is different
- Inflexible: Each configuration is optimized for a specific load
NO good solutions out there:
- Local file systems – too slow
- RAW – fast but complex
- NAS/NFS – too slow but easy to manage
- Cluster FS/VM – very expensive and slow
- SAN FS – Expensive, slow, complex but cross platform
ASM eliminates the need for 3rd party file systems (cluster FS) and volume management software for managing Oracle database files. ASM leverages the Oracle Managed File (OMF) feature of Oracle database and automates file naming and deletion of files associates with database tables.
ASM simplifies the storage solution stack and streamlines installation, configuration and management in a multi platform data center environment offering a one user interface to manage your database files. It also offers a single point of support and troubleshooting that is often a customer pain point.
ASM Variable Size Extents Overview
ASM Variable Size Extents is an automated feature that enables ASM to support larger file size extents while improving memory usage efficiency.
In Oracle Database 11g, ASM supports variable sizes for extents of 1, 4, 16, and 64 MB. ASM uses a predetermined number of extents of each size. As soon as a file cross a certain threshold, the next extent size is used. An ASM file can begin with 1 MB extents and as the file’s size increases, the extent size also increases to 4, 16, or 64 MB based on predefined file size thresholds.
With this feature, fewer extent pointers are needed to describe the file and less memory is required to manage the extent maps in the shared pool, which would have been prohibitive in large file configurations. Extent size can vary both across files and within files.
Variable Size Extents also enable you to deploy Oracle databases using ASM that are several hundred TB even several PB in size.
The management of variable size extents is completely automated and does not require manual administration.
However, external fragmentation may occur when a large number of non-contiguous small data extents have been allocated and freed, and no additional contiguous large extents are available. A defragmentation operation is integrated as part of the any rebalance operation. So, as a DBA, you always have the possibility to defragment your disk group by executing a rebalance operation.
Nevertheless, this should only happen very rarely because ASM also automatically perform defragmentation during extents allocation if the desired size is unavailable. This can potentially render some allocation operations longer.
Note: This feature also enables much faster file opens because of the significant reduction in the amount of memory that is required to store file extents.
SYSASM Overview
This feature introduces a new SYSASM role that is specifically intended for performing ASM administration tasks. Using the SYSASM role instead of the SYSDBA role improves security by separating ASM administration from database administration.
As of Oracle Database 11g Release 1, the OS group for SYSASM and SYSDBA is the same, and the default installation group for SYSASM is dba. In a future release, separate groups will have to be created, and SYSDBA users will be restricted in ASM instances.
Currently, as a member of the dba group you can connect to an ASM instance using the first statement above.
You also have the possibility to use the combination of CREATE USER and GRANT SYSMAN SQL statements from an ASM instance to create a new SYSASM user. This is possible as long as the name of the user is an existing OS user name. These commands update the password file of each ASM instance, and do not need instance to be up and running. Similarly, you can revoke the SYSMAN role from a user using the REVOKE command, and you can drop a user from the password file using the DROP USER command.
Note: With Oracle Database 11g Release 1, if you log in to an ASM instance as SYSDBA, warnings are written in the corresponding alert.log file.
ASM Disk Group Attributes
Whenever you create or alter an ASM disk group, you have the possibility to change its attributes using the new ATTRIBUTE clause of the CREATE DISKGROUP and ALTER DISKGROUP commands. These attributes are briefly summarized in this table:
The AU size and the disk_repair_time, we have already talked about.
Now about the ASM Disk Group Compatibility
There are two kinds of compatibility applicable to ASM disk groups; dealing with the persistent data structures that describe a disk group, and the capabilities of the clients (consumers of disk groups). These attributes are called ASM compatibility and RDBMS compatibility respectively. The compatibility of each disk group is independently controllable. This is required for environments with disk groups from both Oracle Database 10g and Oracle Database 11g. These two compatibility settings are attributes of each ASM disk group:
RDBMS compatibility refers to the minimum compatible version of the RDBMS instance that would allow the instance to mount the disk group.
This compatibility dictates the format of messages that are exchanged between the ASM and database (RDBMS) instances. An ASM instance has the capability to support different RDBMS clients running at different compatibility settings. The database compatible version setting of each instance must be greater than or equal to the RDBMS compatibility of all disk groups used by that database. Database instances are typically run from a different Oracle home than the ASM instance. This implies that the database instance may be running a different software version than the ASM instance. When a database instance first connects to an ASM instance, it negotiates the highest version that they both can support. The compatibility parameter setting of the database, software version of the database and the RDBMS compatibility setting of a disk group determine if a database instance can mount a given disk group.
ASM compatibility refers to the persistent compatibility setting controlling the format of data structures for ASM metadata on disk. The ASM compatibility level of a disk group must always be greater than or equal to the RDBMS compatibility level of the same disk group. ASM compatibility is only concerned with the format of the ASM metadata. The format of the file contents is up to the database instance.
For example, the ASM compatibility of a disk group can be set to 11.0 while its RDBMS compatibility could be 10.1. This implies that disk group can only be managed by ASM software whose software version is 11.0 or higher while any database client whose software version is higher than or equal to 10.1 can use that disk group.
The compatibility of a disk group only needs to be advanced when there is change to either persistent disk structures or protocol messaging. However, advancing disk group compatibility is an irreversible operation. You can set the disk group compatibility by using either the CREATE DISKGROUP or ALTER DISKGROUP commands.
Note: In addition to the disk group compatibilities, the compatible parameter (database compatible version) determines the features that are enabled; it applies to the database or ASM instance depending on the instance_type parameter. For example: Setting it to 10.1 would preclude use of any new features that are introduced in Oracle Database 10g (disk online/offline, variable extents, etc).
ASMCMD Extensions
ASMCMD is extended to include ASM metadata backup and restore functionality. This provides the ability to recreate a pre-existing ASM disk group with exact same template and alias directory structure. Currently if an ASM disk group is lost, it is possible to restore the lost files using RMAN but you have to manually recreate ASM disk group and any required user directories/templates. There is no way to backup and restore ASM metadata. ASM metadata backup and restore (AMBR) works in two modes. In backup mode it parses ASM fixed tables and views to gather information about existing disks and failure group configurations, template and alias directory structure. It then dumps this metadata information to a text file. In restore mode, AMBR reads the previously generated file to reconstruct the disk group and its metadata. You have the possibility to control AMBR behavior in restore mode to do a full, nodg, or newdg restore. The difference between the three sub-modes is to whether you want to include the disk group creation or not, and change its characteristics.
The lsdsk command lists ASM disk information. This command can run in two modes: connected and non-connected. In connected mode, ASMCMD uses the V$ and GV$ views to retrieve disk information. In non-connected mode, ASMCMD scans disk headers to retrieve disk information, using an ASM disk string to restrict the discovery set. The connected mode is always attempted, first.
Bad block repair is a new feature that runs automatically on normal or high redundancy disk groups. When a normal read from an ASM disk group fails with an I/O error, ASM attempts to repair that block by reading from the mirror copy and write to it and by relocating it if the copy failed to produce a good read. This whole process happens automatically only on blocks that are read. It is possible that some blocks and extents on an ASM disk group are seldom read. One prime example is the secondary extents. The ASMCMD repair command is design to trigger a read on these extents, so the resulting failure in I/O can start the automatic block repair process. One can use the ASMCMD repair interface if the storage array returns an error on a physical block, then the ASMCMD repair can initiate a read on that block to trigger the repair.
Note: For more information about the syntax for each of these commands, refer to the Oracle Database Storage Administrator’s Guide 11g Release 1 (11.1)
Lastly, ASM is included as a feature in the database which provides both the cost savings and reduction in complexity as it provides an integrated alternative to the 3rd party cluster files systems and volume managers used by many Oracle customer in the past. This reduces cost by lowing the license fees for 3rd party technology, lowering the support costs and removing the finger pointing which often occurs in a multi vendor on integrated solution. ASM lowers both the cost and the complexity.
© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.
相关文章 | Related posts:
- Oracle Database 10g Automatic Storage Management Concepts and Administration
- Extending Automatic Storage Management to Manage ALL Data Oracle Database 11g Release 2
- Oracle Database 11gr1/10gr2 Automatic Storage Management Overview and Technical Best Practices
- Top 10 Things You Always Wanted to Know About Automatic Storage Management But Were Afraid to Ask
- Automatic Memory Management(AMM) on 11g
- Oracle Database 11g: Change Management Overview eStudy
- Lower Storage Costs by 10x with Oracle Database 11g
- Automatic PGA Memory Management
- CLOBs and NCLOBs character set storage in Oracle Release 8i, 9i, 10g and 11g
- Upgrade to Oracle Database 11g: Single Instance to RAC & ASM
最新评论