In Oracle Database 10g/11g there are two types of instances: database and ASM instances. The ASM instance, which is generally named +ASM, is started with the INSTANCE_TYPE=ASM init.ora parameter. This parameter, when set, signals the Oracle initialization routine to start an ASM instance and not a standard database instance. Unlike the standard database instance, the ASM instance contains no physical files; such as logfiles, controlfiles or datafiles, and only requires a few init.ora parameters for startup.
Upon startup, an ASM instance will spawn all the basic background processes, plus some new ones that are specific to the operation of ASM. The STARTUP clauses for ASM instances are similar to those for database instances. For example, RESTRICT prevents database instances from connecting to this ASM instance. NOMOUNT starts up an ASM instance without mounting any disk group. MOUNT option simply mounts all defined diskgroups For RAC configurations, the ASM SID is +ASMx instance, where x represents the instance number.
A disk group consists of multiple disks and is the fundamental object that ASM manages. Each disk group contains the metadata that is required for the management of space in the disk group. The ASM instance manages the metadata about the files in a Disk Group in the same way that a file system manages metadata about its files. However, the vast majority of I/O operations do not pass through the ASM instance. In a moment we will look at how file I/O works with respect to the ASM instance.
As all DBAs knows, the database software instantiation on a server is called a database instance. ASM’s nomenclature is the same in that there is an ASM instance. Like the database, ASM has a shared memory footprint called the SGA. The database and ASM instances communicate with each other through high-performance O/S primitives. There is one ASM instance per server. Even when there are several database instances on a single server, each database shares a single ASM instance on that server.
- In a RAC configuration, each server in the cluster has an ASM instance. Each of these instances communicates amongst themselves in the management and presentation of the file system.
- Each database instance coordinates file access through the ASM instance on the server for which it operates.
- Lastly, each ASM instance gathers performance related data from its associated database instance on its server.
ASM is a very passive instance in that it doesn’t have a lot concurrent transactions or queries. So the memory footprint is quite small.
Even if you have 20 dbs connected to ASM , the ASM SGA does not need to change. This is b/c the ASM metadata is not directly tied to the number of clients
The 11g MEMORY_TARGET (DEFAULT VALUE) will be more than sufficient.
The processes parameter may need to be modified. Use the formula to determine the approp value:
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).
The source of concurrent file creations can be any of the following:
- Several concurrent create tablespace commands
- Creation of a Partitioned table with several tablespaces creations
- RMAN backup channels
- Concurrent archive logfile creations
1A. Database issues open of a database file
1B. ASM sends the extent map for the file to database instance. Starting with 11g, the RDBMS only receives first 60 extents the remaining extents in the extent map are paged in on demand, providing a faster open
2A/2B. Database now reads directly from disk
3A.RDBMS foreground initiates a create tablespace for example
3B. ASM does the allocation for its essentially reserving the allocation units for the file creation
3C. Once allocation phase is done, the extent map is sent to the RDBMS
3D. The RDBMS initialization phase kicks in. In this phase the initializes all the reserved AUs
3E. If file creation is successful, then the RDBMS commits the file creation
Going forward all I/Os are done by the RDBMS.
Review what the use of FILESYSTEMIO_OPTIONS parameter; essentially FILESYSTEMIO_OPTIONS is used for filesystem/block storage.
This parameter controls which IO options are used. The value may be any of the following:
*asynch – This allows asynchronous IO to be used where supported by the OS.
*directIO – This allows directIO to be used where supported by the OS. Direct IO bypasses any Unix buffer cache. *setall – Enables both ASYNC and DIRECT IO. “none” – This disables ASYNC IO and DIRECT IO so that Oracle uses normal synchronous writes, without any direct io options.
RDBMS does raw IO against the ASM disks, so need for FILESYSTEMIO_OPTIONS parameter. The only parameter that needs to be set is disk_asyncio=true, which is true by default. If using ASMLIB then even the disk_async does not need to be set.
ASM is also supported for NFS files as ASM disks. In such cases, the required NFS mount options eliminate the need to set FILESYSTEMIO_OPTIONS.
To reduce the complexity of managing ASM and its diskgroups, Oracle recommends that generally no more than two diskgroups be maintained and managed per RAC cluster or single ASM instance
Database work area: This is where active database files such as datafiles, control files, online redo logs, and change tracking files used in incremental backups are stored. This location is indicated by DB_CREATE_FILE_DEST.
Flash recovery area: Where recovery-related files are created, such as multiplexed copies of the current control file and online redo logs, archived redo logs, backup sets, and flashback log files. This location is indicated by DB-RECOVERY_FILE_DEST.
Having one DATA container means only place to store all your database files, and obviates the need to juggle around datafiles or having to decide where to place a new tablespace.
By having one container for all your files also means better storage utilization. Making the IT director very happy. If more storage capacity or IO capacity is needed, just add an ASM disk….all online activities.
You have to ensure that this storage pool container houses enough spindles to accommodate the IO rate of all the database objects
Bottom line, one container == one pool manage, monitor, and track
Note however, that additional diskgroups may be added to support tiered storage classes in Information Lifecycle Management (ILM) or Hierarchical Storage Management (HSM) deployments
These custs mapped certain tablespaces to specific tiers; eg, system/rollback/syaux and latency senstive tablespaces in Tier1, and not as IO critical on Tier2, etc.
For 10g VLDBs its best to set an AU size of 16MB, this is more for metadata space efficiency than for performance. The 16MB recommendation is only necessary if the diskgroup is going to be used by 10g databases. In 11g we introduced variable size extents to solve the metadata problem. This requires compatible.rdbms & compatible.asm to be set to 11.1.0.0. With 11g you should set your AU size to the largest I/O that you wish to issue for sequential access (other parameters need to be set to increase the I/O size issued by Oracle). For random small I/Os the AU size does not matter very much as long as every file is broken into many more extents than there are disks.
In most cases the storage team will dictate to you what the standardized LUN size is. This is based on several factors,
including RAID LUN set builds (concatenated, striped, hypers, etc..). Having too many LUNs elongates boot
time and is it very hard to manage On the flip side, having too few LUNs makes array cache management difficult to
control and creates un-manageable large LUNs (which are difficult to expand). The ASM adminstrator merely has to communicate to SA/storage folks that you need equally sized/performance LUNs and what the capacity requirement is, say 10TB. Using this info, the workload characteristic (random r/w, sequential r/w), and their standards, the storage folks should build a nice LUN group set for you
Having too many LUNs elongates boot time and is it very hard to manage (zoning, provisioning, masking, etc..)…there’s a $/LUN barometer!
Operating system authentication using membership in the group or groups designated
as OSDBA, OSOPER, and OSASM is valid on all Oracle platforms.
A typical deployment could be as follows: ASM administrator: User : asm Group: oinstall, asmdba(OSDBA), asmadmin(OSASM) Database administrator: User : oracle Group: oinstall, asmdba(OSDBA of ASM), dba(OSDBA)
ASM disk ownership : asm:oinstall
Remember that Database instance connects to ASM instance as sysdba. The user id the database instance runs as needs to be the OSDBA group of the ASM instance.
A typical deployment could be as follows: ASM administrator: User : asm Group: oinstall, asmdba(OSDBA), asmadmin(OSASM) Database administrator: User : oracle Group: oinstall, asmdba(OSDBA of ASM), dba(OSDBA)
© 2010, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.
相关文章 | Related posts:
- 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
- Automatic PGA Memory Management
- Automatic Memory Management(AMM) on 11g
- ORA-1092 During Startup Using AUM (Automatic Undo Management)
- Storage Portfolio:Oracle is a Storage Company
- Physical and Logical Block Corruptions. All you wanted to know about it.
- Everything you ever wanted to know about the Cluster Health Monitor (CHM)
- Automatic Checkpoint Tuning
- CLOBs and NCLOBs character set storage in Oracle Release 8i, 9i, 10g and 11g
最新评论