Arquitectura para aprender a administrar Oracle 11g

Editor's Notes

• #3: The Oracle Database A database is a collection of data treated as a unit. The purpose of a database is to store and retrieve related information. An Oracle Database reliably manages a large amount of data in a multiuser environment so that many users can concurrently access the same data. This is accomplished while delivering high performance. At the same time, the database prevents unauthorized access and provides efficient solutions for failure recovery.
• #4: Oracle Database Architecture An Oracle Database consists of an instance and its associated databases. The instance consists of memory structures and background processes. Every time an instance is started, a shared memory area called the System Global Area (SGA) is allocated and the background processes are started. The database consists of both physical structures and logical structures. Because the physical and logical structures are separate, the physical storage of data can be managed without affecting access to logical storage structures.
• #5: Connecting to the Database Connection and session are closely related to user process but are very different in meaning. A connection is a communication pathway between a user process and an Oracle Database instance. A communication pathway is established using available interprocess communication mechanisms (on a computer that runs both the user process and Oracle Database) or network software (when different computers run the database application and Oracle Database, and communicate through a network). A session represents the state of a current user login to the database instance. For example, when a user starts SQL*Plus, the user must provide a valid username and password, and then a session is established for that user. A session lasts from the time the user connects until the time the user disconnects or exits the database application. In the case of a dedicated connection, the session is serviced by a permanent dedicated process. The session is serviced by an available server process selected from a pool, either by the middle tier or by the Oracle shared server architecture. Multiple sessions can be created and exist concurrently for a single Oracle Database user using the same username. For example, a user with the username/password of HR/HR can connect to the same Oracle Database instance several times.
• #6: Database Structures After starting an instance, the Oracle software associates the instance with a specific database. This is called mounting the database. The database is then ready to be opened, which makes it accessible to authorized users. Multiple instances can execute concurrently on the same computer, each accessing its own physical database. You can look at the Oracle Database architecture as various interrelated structural components. An Oracle instance uses memory structures and processes to manage and access the database. All memory structures exist in the main memory of the computers that constitute the database server. Processes are jobs that work in the memory of these computers. A process is defined as a “thread of control” or a mechanism in an operating system that can run a series of steps.
• #7: Oracle Memory Structures Oracle Database creates and uses memory structures for various purposes. For example, memory stores program code being run, data shared among users, and private data areas for each connected user. Two basic memory structures are associated with an instance: The System Global Area (SGA) is a group of shared memory structures, known as SGA components, that contain data and control information for one Oracle Database instance. The SGA is shared by all server and background processes. Examples of data stored in the SGA include cached data blocks and shared SQL areas. The Program Global Areas (PGAs) are memory regions that contain data and control information for a server or background process. A PGA is nonshared memory created by Oracle Database when a server or background process is started. Access to the PGA is exclusive to the server process. Each server process and background process has its own PGA.
• #8: Oracle Memory Structures (continued) The SGA is the memory area that contains data and control information for the instance. The SGA includes the following data structures: Database buffer cache: Caches blocks of data retrieved from the database Redo log buffer: Caches redo information (used for instance recovery) until it can be written to the physical redo log files stored on the disk Shared pool: Caches various constructs that can be shared among users Large pool: Is an optional area that provides large memory allocations for certain large processes, such as Oracle backup and recovery operations, and I/O server processes Java pool: Is used for all session-specific Java code and data within the Java Virtual Machine (JVM) Streams pool: Is used by Oracle Streams to store information required by capture and apply When you start the instance by using Enterprise Manager or SQL*Plus, the amount of memory allocated for the SGA is displayed. A Program Global Area (PGA) is a memory region that contains data and control information for each server process. An Oracle server process services a client’s requests. Each server process has its own private PGA that is created when the server process is started. Access to the PGA is exclusive to that server process, and the PGA is read and written only by the Oracle code acting on its behalf. With the dynamic SGA infrastructure, the size of the database buffer cache, the shared pool, the large pool, the Java pool, and the Streams pool changes without shutting down the instance. The Oracle database uses initialization parameters to create and configure memory structures. For example, the SGA_TARGET parameter specifies the total size of the SGA components. If you set SGA_TARGET to 0, Automatic Shared Memory Management is disabled.
• #9: Process Architecture The processes in an Oracle Database system can be categorized into two major groups: User processes that run the application or Oracle tool code. Oracle Database processes that run the Oracle database server code. They include server processes and background processes. When a user runs an application program or an Oracle tool such as SQL*Plus, Oracle Database creates a user process to run the user’s application. Oracle Database also creates a server process to execute the commands issued by the user process. In addition, the Oracle server also has a set of background processes for an instance that interact with each other and with the operating system to manage the memory structures and asynchronously perform I/O to write data to disk, and perform other required tasks. The process structure varies for different Oracle Database configurations, depending on the operating system and the choice of Oracle Database options. The code for connected users can be configured as a dedicated server or a shared server. With dedicated server, for each user, the database application is run by a user process that is served by a dedicated server process that executes Oracle database server code. A shared server eliminates the need for a dedicated server process for each connection. A dispatcher directs multiple incoming network session requests to a pool of shared server processes. A shared server process serves any client request.
• #10: Process Structures Server Processes Oracle Database creates server processes to handle the requests of user processes connected to the instance. In some situations when the application and Oracle Database operate on the same computer, it is possible to combine the user process and corresponding server process into a single process to reduce system overhead. However, when the application and Oracle Database operate on different computers, a user process always communicates with Oracle Database through a separate server process. Server processes created on behalf of each user’s application can perform one or more of the following tasks: Parsing and running SQL statements issued through the application Reading necessary data blocks from data files on disk into the shared database buffers of the SGA, if the blocks are not already present in the SGA Returning results in such a way that the application can process the information Background Processes To maximize performance and accommodate many users, a multiprocess Oracle Database system uses some additional Oracle Database processes called background processes. An Oracle Database instance can have many background processes.
• #11: Process Structures (continued) Background Processes (continued) The background processes commonly seen in non-RAC non-ASM environments can include the following: Database Writer process (DBWn) Log Writer process (LGWR) Checkpoint process (CKPT) System Monitor process (SMON) Process Monitor process (PMON) Recoverer process (RECO) Job Queue processes Archiver processes (ARCn) Queue Monitor processes (QMNn) Other background processes may be found in more advanced configurations such as RAC. See the V$BGPROCESS view for more information about the background processes. On many operating systems, background processes are created automatically when an instance is started.
• #12: Oracle Database Storage Architecture The files that constitute an Oracle database are organized into the following: Control files: Contain data about the database itself (that is, physical database structure information). These files are critical to the database. Without them, you cannot open data files to access the data within the database. Data files: Contain the user or application data of the database, as well as metadata and the data dictionary Online redo log files: Allow for instance recovery of the database. If the database server crashes and does not lose any data files, then the instance can recover the database with the information in these files. The following additional files are important to the successful running of the database: Parameter file: Is used to define how the instance is configured when it starts up Password file: Allows sysdba/sysoper/sysasm to connect remotely to the database and perform administrative tasks Backup files: Are used for database recovery. You typically restore a backup file when a media failure or user error has damaged or deleted the original file. Archived redo log files: Contain an ongoing history of the data changes (redo) that are generated by the instance. Using these files and a backup of the database, you can recover a lost data file. That is, archive logs enable the recovery of restored data files.
• #13: Oracle Database Storage Architecture (continued) Trace files: Each server and background process can write to an associated trace file. When an internal error is detected by a process, the process dumps information about the error to its trace file. Some of the information written to a trace file is intended for the database administrator, whereas other information is for Oracle Support Services. Alert log file: These are special trace entries. The alert log of a database is a chronological log of messages and errors. Each instance has one alert log file. Oracle recommends that you review this periodically.
• #14: Logical and Physical Database Structures The database has logical structures and physical structures. Tablespaces A database is divided into logical storage units called tablespaces, which group related logical structures together. For example, tablespaces commonly group all of an application’s objects to simplify some administrative operations. You may have a tablespace for application data and an additional one for application indexes. Databases, Tablespaces, and Data Files The relationship among databases, tablespaces, and data files is illustrated in the slide. Each database is logically divided into one or more tablespaces. One or more data files are explicitly created for each tablespace to physically store the data of all logical structures in a tablespace. If it is a TEMPORARY tablespace, then instead of a data file, the tablespace has a temporary file.
• #15: Logical and Physical Database Structures (continued) Schemas A schema is a collection of database objects that are owned by a database user. Schema objects are the logical structures that directly refer to the database’s data. Schema objects include such structures as tables, views, sequences, stored procedures, synonyms, indexes, clusters, and database links. In general, schema objects include everything that your application creates in the database. Data Blocks At the finest level of granularity, an Oracle database’s data is stored in data blocks. One data block corresponds to a specific number of bytes of physical database space on the disk. A database uses and allocates free database space in Oracle data blocks. Extents The next level of logical database space is called an extent. An extent is a specific number of contiguous data blocks (obtained in a single allocation) that are used to store a specific type of information. Segments The level of logical database storage above an extent is called a segment. A segment is a set of extents allocated for a certain logical structure. For example, the different types of segments include: Data segments: Each nonclustered, non-index-organized table has a data segment with the exception of external tables, global temporary tables, and partitioned tables where each table has one or more segments. All of the table’s data is stored in the extents of its data segment. For a partitioned table, each partition has a data segment. Each cluster has a data segment. The data of every table in the cluster is stored in the cluster’s data segment. Index segments: Each index has an index segment that stores all of its data. For a partitioned index, each partition has an index segment. Undo segments: One UNDO tablespace is created per database instance that contains numerous undo segments to temporarily store undo information. The information in an undo segment is used to generate read-consistent database information and, during database recovery, to roll back uncommitted transactions for users. Temporary segments: Temporary segments are created by the Oracle database when a SQL statement needs a temporary work area to complete execution. When the statement finishes execution, the temporary segment’s extents are returned to the instance for future use. Specify a default temporary tablespace for every user or a default temporary tablespace, which is used databasewide. The Oracle database dynamically allocates space. When the existing extents of a segment are full, additional extents are added. Because extents are allocated as needed, the extents of a segment may or may not be contiguous on the disk.
• #16: Tablespaces and Data Files A database is divided into logical storage units called tablespaces, which can be used to group related logical structures together. Each database is logically divided into one or more tablespaces. One or more data files are explicitly created for each tablespace to physically store the data of all logical structures in a tablespace. Note: You can also create bigfile tablespaces. These tablespaces can have only a single file, which is often very large. The file may be any size up to maximum that the row ID architecture will permit. The maximum size is the block size for the tablespace times 2 to the 36th power, or 128 TB for a 32 KB block size. The traditional smallfile tablespaces (which are the default) usually contain multiple data files, but the files cannot be as large. For more information about the bigfile tablespaces, see the Database Administrator’s Guide.
• #17: SYSTEM and SYSAUX Tablespaces Each Oracle database must contain a SYSTEM tablespace and a SYSAUX tablespace. They are automatically created when the database is created. The system default is to create a smallfile tablespace. You can also create bigfile tablespaces, which enable the Oracle database to manage ultralarge files (up to 8 exabytes in size). A tablespace can be online (accessible) or offline (not accessible). The SYSTEM tablespace is always online when the database is open. It stores tables that support the core functionality of the database, such as the data dictionary tables. The SYSAUX tablespace is an auxiliary tablespace to the SYSTEM tablespace. The SYSAUX tablespace stores many database components, and it must be online for the correct functioning of all database components. Note: The SYSAUX tablespace may be taken offline to do tablespace recovery, whereas this is not possible for SYSTEM tablespace. Neither of them may be made read-only.
• #18: Segments, Extents, and Blocks Database objects, such as tables and indexes, are stored as segments in tablespaces. Each segment contains one or more extents. An extent consists of contiguous data blocks, which means that each extent can exist only in one data file. Data blocks are the smallest unit of I/O in the database. When the database requests a set of data blocks from the operating system (OS), the OS maps this to an actual file system or disk block on the storage device. Because of this, you need not know the physical address of any of the data in your database. This also means that a data file can be striped or mirrored on several disks. The size of the data block is defined by the DB_BLOCK_SIZE parameter. The default size of 8 KB is adequate for most databases. If your database supports a data warehouse application that has large tables and indexes, then a larger block size may be beneficial. If your database supports a transactional application where reads and writes are random, then specifying a smaller block size may be beneficial. The maximum block size depends on your OS. You can have tablespaces with a nonstandard block size. For details, see the Database Administrator’s Guide.
• #19: Database Architecture: Summary of Structural Components In this lesson, you learned, at a high level, about the structural components of Oracle Database: memory, process, and storage structures. More details are covered in the following lessons.
• #20: Automatic Storage Management: Review Automatic Storage Management (ASM) provides a vertical integration of the file system and the volume manager that is specifically built for the Oracle database files. ASM can provide management for single SMP machines, or across multiple nodes of a cluster for Oracle Real Application Clusters (RAC) support. A single ASM instance can provide support for many Oracle databases simultaneously. ASM distributes I/O load across all available resources to optimize performance while removing the need for manual I/O tuning. ASM helps DBAs to manage a dynamic database environment by allowing them to increase the database size without having to shut down the database to adjust the storage allocation. ASM can maintain redundant copies of data to provide fault tolerance, or it can be built on top of vendor-supplied reliable storage mechanisms. ASM may use virtual raw volumes provided in a storage area network (SAN) environment or zero-padded files on a network attached storage (NAS) filer in addition to using local raw devices. Data management is done by selecting the desired reliability and performance characteristics for classes of data rather than with human interaction on a per file basis. ASM capabilities save DBAs’ time by automating manual storage and thereby increasing their ability to manage larger databases and more of them with increased efficiency.
• #21: Automatic Storage Management: Review (continued) ASM divides files into allocation units (AUs) and spreads the AUs for each file evenly across all the disks. ASM uses an index technique to track the placement of each AU. When your storage capacity changes, ASM does not restripe all of the data, but moves an amount of data proportional to the amount of storage added or removed to evenly redistribute the files and maintain a balanced load across the disks. This is done while the database is up. You can increase the speed of a rebalance operation, or lower it to reduce the impact on the I/O subsystem. ASM provides mirroring protection without the need to purchase a third-party Logical Volume Manager. One unique advantage of ASM is that the mirroring is applied on a file basis, rather than on a volume basis. Therefore, the same disk group can contain a combination of files protected by mirroring, along with those that are not protected at all. ASM supports data files, log files, control files, archive logs, temp files, archive log files, SPFILEs, RMAN backup sets, and other Oracle database file types. ASM supports Real Application Clusters and eliminates the need for a Cluster Logical Volume Manager or a Cluster File System.
• #22: ASM: General Architecture To use ASM, you must start a special instance, called an ASM instance, before you start your database instance. ASM instances do not mount databases, instead they manage the metadata needed to make ASM files available to ordinary database instances. Both ASM instances and database instances have access to some common set of disks called disk groups. Database instances access the contents of ASM files directly, communicating with an ASM instance only to get information about the layout of these files. An ASM instance starts several background processes specific to ASM. One process coordinates rebalance activity for disk groups. It is called RBAL. The second one performs the actual rebalance AU movements. There can be many of these at a time, and they are called ARB0, ARB1, and so forth. The GMON process, or Group Monitor, is used for partner and status table, and node membership. An ASM instance also has some of the same background processes as a database instance, including SMON, PMON, LGWR, DBWR, and CKPT. Each database instance using ASM has two extra background processes called ASMB and RBAL. RBAL performs global opens of the disks in the disk groups. At database instance startup, ASMB connects as a foreground process to the ASM instance. Communication between the database and the ASM instance is performed via this bridge. This includes physical file changes such as data file creation and deletion. Over this connection, periodic messages are exchanged to update statistics and to verify that both instances are healthy.
• #23: Creating an ASM Instance You create an ASM instance by running the Database Configuration Assistant (DBCA). On the first page, select the Configure Automatic Storage Management option, and then follow the steps. The ASM instance is created and started for you. Then you are guided through the process of defining disk groups for the instance. As part of the ASM instance creation process, the DBCA automatically creates an entry into the oratab file. This entry is used for discovery purposes. On the Windows platform where a services mechanism is used, the DBCA automatically creates an Oracle Service and the appropriate registry entry to facilitate the discovery of ASM instances. In addition, you are prompted to run the localconfig script that configures Cluster Synchronization Services to manage the ASM instance. When an ASM instance is configured, the DBCA creates an ASM instance parameter file and an ASM instance password file. If you were to create an ASM-enabled database, the DBCA determines whether an ASM instance already exists on your host. If ASM instance discovery returns an empty list, the DBCA creates a new ASM instance.
• #24: ASM Instance Initialization Parameters An ASM instance is controlled by a parameter file in the same way as a regular database instance. Parameters commonly set there include: INSTANCE_TYPE should be set to ASM for ASM instances. This is the only parameter that must be defined. DB_UNIQUE_NAME specifies the service provider name for which this ASM instance manages disk groups. ASM_POWER_LIMIT controls the speed for a rebalance operation. Values range from 1 through 11, with 11 being the fastest. If omitted, this value defaults to 1. ASM_DISKSTRING is an operating system–dependent value used by ASM to limit the set of disks considered for discovery. ASM_DISKGROUPS is the list of names of disk groups to be mounted by an ASM instance at startup, or when the ALTER DISKGROUP ALL MOUNT command is used. Note: Automatic memory management (see lesson 14) is enabled by default on ASM instances, even when the MEMORY_TARGET parameter is not explicitly set. This is the only parameter that you need to set for complete ASM memory management. Oracle Corporation strongly recommends that you use automatic memory management for ASM.
• #25: Starting Up an ASM Instance ASM instances are started similarly to database instances except that the initialization parameter file contains the entry INSTANCE_TYPE=ASM. When this parameter is set to the value ASM, it informs the Oracle executable that an ASM instance is starting, not a database instance. Also, the ORACLE_SID variable must be set to the ASM instance name. When the ASM instance starts up, the mount stage attempts to mount the disk groups specified by the ASM_DISKGROUPS initialization parameter rather than mounting a database, as is done with non-ASM instances. Other STARTUP clauses have comparable interpretation for ASM instances as they do for database instances. OPEN is invalid for an ASM instance. NOMOUNT starts up the ASM instance without mounting the database.
• #26: SYSASM Role The SYSASM role 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. In 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 in the slide. You can also use the combination of CREATE USER and GRANT SYSASM 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 username. These commands update the password file of each ASM instance, and do not need the instance to be up and running. Similarly, you can revoke the SYSASM role from a user using the REVOKE command, and you can drop a user from the password file using the DROP USER command. The V$PWFILE_USERS view includes a new column called SYSASM that indicates whether the user can connect with SYSASM privileges (TRUE) or not (FALSE). Note: In Oracle Database 11g Release 1, if you log in to an ASM instance as SYSDBA, warnings are written in the corresponding alert.log file.
• #27: Accessing an ASM Instance ASM instances do not have a data dictionary, so the only way to connect to one is by using OS authentication, that is, SYSASM, SYSDBA, or SYSOPER. To connect remotely, a password file must be used. Users who connect to the ASM instance with the SYSASM or SYSDBA privileges have administrative access to all disk groups in the system. The SYSOPER privilege is supported in ASM instances and limits the set of allowable SQL commands to the minimum required for basic operation of an already configured system. The following commands are available to SYSOPER users: STARTUP/SHUTDOWN ALTER DISKGROUP MOUNT/DISMOUNT ALTER DISKGROUP ONLINE/OFFLINE DISK ALTER DISKGROUP REBALANCE ALTER DISKGROUP CHECK SELECT all V$ASM_* views All other commands, such as CREATE DISKGROUP, ADD/DROP/RESIZE DISK, and so on, require the SYSASM or SYSDBA privilege and are not allowed with the SYSOPER privilege.
• #28: Using Enterprise Manager to Manage ASM Users Enterprise Manager allows you to manage the users who access the ASM instance through remote connection (using password file authentication). These users are reserved exclusively for the ASM instance. You have this functionality only when you are connected as the SYSASM user. It is hidden if you connect as SYSDBA or SYSOPER users. When you click the Create button, the Create User page is displayed. When you click the Edit button the Edit User page is displayed. By clicking the Delete button, you can delete the created users. Note: Oracle Database 11g adds the SYSASM role to the ASM instance login page.
• #29: Shutting Down an ASM Instance When you attempt to shut down an ASM instance in the NORMAL, IMMEDIATE, or TRANSACTIONAL modes, it succeeds only if there are no database instances connected to the ASM instance. If there is at least one connected instance, you receive the following error:  ORA-15097: cannot SHUTDOWN ASM instance with connected RDBMS instance If you perform a SHUTDOWN ABORT on the ASM instance, it shuts down, and it will require recovery at the time of the next startup. Any connected database instances will also eventually shut down, reporting the following error: ORA-15064: communication failure with ASM instance In a single–ASM instance configuration, if the ASM instance fails while disk groups are open for update, then after the ASM instance reinitializes, it reads the disk group’s log and recovers all transient changes. With multiple ASM instances sharing disk groups, if one ASM instance fails, another ASM instance automatically recovers transient ASM metadata changes caused by the failed instance. The failure of a database instance does not affect ASM instances. The ASM instance should be started automatically whenever the host is rebooted. The ASM instance is expected to use the automatic startup mechanism supported by the underlying operating system. Note that file system failure usually crashes a node.
• #30: ASM Storage: Concepts ASM does not eliminate any existing database functionality. Existing databases are able to operate as they always have. New files may be created as ASM files, whereas existing ones are administered in the old way or can be migrated to ASM. The diagram depicts the relationships that exist between the various storage components inside an Oracle database. On the left and center parts of the diagram, you can find the relationships that exist in previous releases. The right part of the diagram shows you the new concepts introduced by ASM in Oracle Database 10g. However, these new concepts are used only to describe file storage, and do not replace any existing concepts such as segments and tablespaces. With ASM, database files can now be stored as ASM files. At the top of the new hierarchy, you can find what are called ASM disk groups. Any single ASM file is contained in only one disk group. However, a disk group may contain files belonging to several databases, and a single database may use storage from multiple disk groups. As you can see, one disk group is made up of ASM disks, and each ASM disk belongs to only one disk group. Also, ASM files are always spread across all the ASM disks in the disk group. ASM disks are partitioned in allocation units (AUs) of one megabyte each. An AU is the smallest contiguous disk space that ASM allocates. ASM does not allow physical blocks to be split across AUs. Note: This graphic deals with only one type of ASM file: data file. However, ASM can be used to store other database file types.
• #31: ASM Disk Groups A disk group is a collection of disks managed as a logical unit. Storage is added and removed from disk groups in units of ASM disks. Every ASM disk has an ASM disk name, which is a name common to all nodes in a cluster. The ASM disk name abstraction is required because different hosts can use different names to refer to the same disk. An ASM file can begin with 1 MB extents and as the file size increases, the extent size also increases to 8 MB and 64 MB at a predefined number of extents. Therefore, the size of extent map defining a file can be smaller by a factor of 8 and 64 depending on the size of the file. The initial extent size is equal to the AU size and it increases by the 8 and 64 factor at predefined thresholds. This is automatic for newly created files after the COMPATIBLE.ASM and COMPATIBLE.RDBMS parameters have been advanced to 11.1 ASM always spreads files evenly across all the disks in a disk group. This is called coarse striping. That way, ASM eliminates the need for manual disk tuning. However, disks in a disk group should have similar size and performance characteristics to obtain optimal I/O. For most installations, there is only a small number of disk groups—for instance, one disk group for a work area, and one for a recovery area. For files, such as log files, that require low latency, ASM provides fine-grained (128 KB) striping. Fine striping stripes each AU.
• #32: ASM Disk Groups (continued) Fine striping breaks up medium-sized I/O operations into multiple smaller I/O operations that execute in parallel. While the number of files and disks increase, you have to manage only a constant number of disk groups. From a database perspective, disk groups can be specified as the default location for files created in the database. Note: Each disk group is self-describing, containing its own file directory and disk directory.
• #33: Failure Group A failure group is a set of disks, inside one particular disk group, sharing a common resource whose failure needs to be tolerated. An example of a failure group is a string of SCSI disks connected to a common SCSI controller. A failure of the controller leads to all the disks on its SCSI bus becoming unavailable, although each of the individual disks is still functional. What constitutes a failure group is site specific. It is largely based upon failure modes that a site is willing to tolerate. By default, ASM assigns each disk to its own failure group. When creating a disk group or adding a disk to a disk group, administrators may specify their own grouping of disks into failure groups. After failure groups are identified, ASM can optimize file layout to reduce the unavailability of data due to the failure of a shared resource.
• #34: Disk Group Mirroring ASM has three disk group types that support different types of mirroring: External redundancy: Do not provide mirroring. Use an external-redundancy disk group if you use hardware mirroring or if you can tolerate data loss as the result of a disk failure. Failure groups are not used with these types of disk groups. Normal-redundancy: Support two-way mirroring High-redundancy: Provide triple mirroring ASM does not mirror disks; rather, it mirrors AUs. As a result, you need only spare capacity in your disk group. When a disk fails, ASM automatically reconstructs the contents of the failed disk on the surviving disks in the disk group by reading the mirrored contents from the surviving disks. This spreads the I/O hit from a disk failure across several disks. When ASM allocates a primary AU of a file to one disk in a disk group, it allocates a mirror copy of that AU to another disk in the disk group. Primary AUs on a given disk can have their mirror copies on one of several partner disks in the disk group. ASM ensures that a primary AU and its mirror copy never reside in the same failure group. If you define failure groups for your disk group, ASM can tolerate the simultaneous failure of multiple disks in a single failure group.
• #35: Disk Group Dynamic Rebalancing With ASM, the rebalance process is very easy and happens without any intervention from the DBA or system administrator. ASM automatically rebalances a disk group whenever disks are added or dropped. However, rebalancing will be delayed when disk groups are dropped because of errors. By using index techniques to spread AUs on the available disks, ASM does not need to restripe all of the data, but instead needs to only move an amount of data proportional to the amount of storage added or removed to evenly redistribute the files and maintain a balanced I/O load across the disks in a disk group. With the I/O balanced whenever files are allocated and whenever the storage configuration changes, the DBA never needs to search for hot spots in a disk group and manually move data to restore a balanced I/O load. However, because the database needs to resync cached ASM metadata, rebalances will have less impact if done in quiet periods. It is more efficient to add or drop multiple disks at the same time so that they are rebalanced as a single operation. This avoids unnecessary movement of data. With this technique, it is easy to achieve online migration of your data. All you need to do is add the new disks in one operation and drop the old ones in one operation. You can control how much of a load the rebalance operation has on the system by setting the ASM_POWER_LIMIT parameter. Its range of values is 1 through 11. The lower the number, the lighter the load; a higher setting has more of a load and finishes sooner.
• #36: Managing Disk Groups The main goal of an ASM instance is to manage disk groups and protect their data. ASM instances also communicate file layout to database instances. In this way, database instances can directly access files stored in disk groups. There are several disk group administrative commands. They all require the SYSASM or SYSDBA privilege and must be issued from an ASM instance. You can add new disk groups. You can also modify existing disk groups to add new disks, remove existing ones, and perform many other operations. You can remove existing disk groups.
• #37: Creating and Dropping Disk Groups Assume that ASM disk discovery identified the following disks in the /devices directory: A1, A2, A3, B1, B2, and B3. Also, assume that disks A1, A2, and A3 are on a separate SCSI controller from disks B1, B2, and B3. The first example in the slide illustrates how to configure a disk group called DGROUPA with two failure groups: CONTROLLER1 and CONTROLLER2. The example also uses the default redundancy characteristic, NORMAL REDUNDANCY, for the disk group. You can optionally provide a disk name and size for the disk. If you do not supply this information, ASM creates a default name and attempts to determine the size of the disk. If the size cannot be determined, an error is returned. FORCE indicates that a specified disk should be added to the specified disk group even though the disk is already formatted as a member of an ASM disk group. Using the FORCE option for a disk that is not formatted as a member of an ASM disk group returns an error. As shown by the second statement in the slide, you can delete a disk group along with all its files. To avoid accidental deletions, the INCLUDING CONTENTS option must be specified if the disk group still contains any files besides internal ASM metadata. The disk group must be mounted in order for it to be dropped. After ensuring that none of the disk group files are open, the group and all its drives are removed from the disk group. Then the header of each disk is overwritten to eliminate the ASM formatting information.
• #38: Adding Disks to Disk Groups This example shows how to add disks to a disk group. You execute an ALTER DISKGROUP ADD DISK command to add the disks. The first statement adds four new disks to the DGROUPA disk group. The second statement demonstrates the interactions of discovery strings. Consider the following configuration: /devices/A1 is a member of disk group DGROUPA. /devices/A2 is a member of disk group DGROUPA. /devices/A3 is a member of disk group DGROUPA. /devices/A4 is a candidate disk. The second command adds A4 to the DGROUPA disk group. It ignores the other disks, even though they match the discovery string, because they are already part of the DGROUPA disk group. As shown by the diagram, when you add a disk to a disk group, the ASM instance ensures that the disk is addressable and usable. The disk is then formatted and rebalanced. The rebalance process is time consuming because it moves AUs from every file onto the new disk. Note: Rebalancing does not block any database operations. The main impact that a rebalance process has is on the I/O load on the system. The higher the power of the rebalance, the more I/O load it puts on the system. Thus less I/O bandwidth is available for database I/Os.
• #39: 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 to enable heterogeneous 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.
• #40: ASM Disk Group Compatibility (continued) The compatibility parameter setting of the database, software version of the database, and the RDBMS compatibility setting of a disk group determine whether 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 concerned only 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 the disk group can be managed only by ASM software whose software version is 11.0 or higher, whereas 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 needs to be advanced only when there is a 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 features introduced in Oracle Database 11g (disk online/offline, variable extents, and so on).
• #41: ASM Disk Group Attributes Whenever you create or alter an ASM disk group, you have the ability to change its attributes using the new ATTRIBUTE clause of the CREATE DISKGROUP and ALTER DISKGROUP commands. These attributes are briefly summarized in the table given in the slide: ASM enables the use of different allocation unit (AU) sizes that you specify when you create a disk group. The AU can be 1, 2, 4, 8, 16, 32, or 64 MB in size. RDBMS compatibility: See the slide “ASM Disk Group Compatibility” for more information. ASM compatibility: See the slide “ASM Disk Group Compatibility” for more information. You can specify the DISK_REPAIR_TIME in units of minute (M), hour (H), or day (D). If you omit the unit, then the default is H. If you omit this attribute, then the default is 3.6H. You can override this attribute with an ALTER DISKGROUP ... DISK OFFLINE statement. You can also specify the redundancy attribute of the specified template. You can also specify the striping attribute of the specified template. Note: For each defined disk group, you can look at all defined attributes through the V$ASM_ATTRIBUTE fixed view.
• #42: Using Enterprise Manager to Edit Disk Group Attributes Enterprise Manager provides a simple way to store and retrieve environment settings related to disk groups. You can set the compatible attributes from both the create disk group page and the edit disk group advanced attributes page. The disk_repair_time attribute is added to the edit disk group advanced attributes page only. Note: For pre-11g ASM instances, the default ASM compatibility and client compatibility is 10.1. For 11g ASM instances, the default ASM compatibility is 10.1 and database compatibility is 10.1.
• #43: Miscellaneous ALTER Commands The first statement in the slide shows how to remove one of the disks from the DGROUPA disk group. The second statement shows how you can add and drop a disk in a single command. The big advantage in this case is that rebalancing is not started until the command completes. The third statement shows how to cancel a disk drop operation. The UNDROP command operates only on pending drops of disks; it has no effect on drops that have completed. The following statement rebalances the DGROUPB disk group, if necessary: ALTER DISKGROUP dgroupB REBALANCE POWER 5; This command is generally not necessary because it is automatically done as disks are added, dropped, or resized. However, it is useful if you want to use the POWER clause to override the default speed defined by the initialization parameter ASM_POWER_LIMIT. You can change the power level of an ongoing rebalance operation by reentering the command with a new level. A power level of zero causes rebalancing to halt until the command is either implicitly or explicitly reinvoked. The following statement dismounts DGROUPA: ALTER DISKGROUP dgroupA DISMOUNT; The MOUNT and DISMOUNT options allow you to make one or more disk groups available or unavailable to the database instances. The ability to manually unmount and mount is useful in a clustered ASM environment supporting a single instance, when that instance is failed over to a different node.
• #44: ASMCMD Utility ASMCMD is a command-line utility that you can use to view and manipulate files and directories within ASM disk groups. ASMCMD can list the contents of disk groups, perform searches, create and remove directories and aliases, display space utilization, and more. ASMCMD works with ASM files, directories, and aliases. Every file created in ASM gets a system-generated file name, otherwise known as a fully qualified file name. This is the same as a complete path name in a local file system. As in other file systems, an ASM directory is a container for files, and an ASM directory can be part of a tree structure of other directories. The fully qualified file name represents a hierarchy of directories in which the plus sign (+) represent the root directory. ASMCMD> ls -l +DGROUP1/ORCL/DATAFILE Type Redund Striped Time Sys Name DATAFILE MIRROR COARSE OCT 05 21:00:00 Y HRAPPS.257.570923611 You can create your own directories as subdirectories of the system-generated directories using the ASMCMD mkdir command: ASMCMD> mkdir +dgroup1/sample/mydir
• #45: ASMCMD Utility (continued) ASMCMD can perform ASM metadata backup and restore functionality. This provides the ability to re-create a preexisting ASM disk group with the exact same template and alias directory structure. 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’s repair command is designed 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’s 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.
• #46: ASM Scalability and Performance ASM Variable Size Extents is an automated feature that enables ASM to support larger file size while improving memory usage efficiency. An ASM file begins with an extent equal to one AU. As the file size increases, the extent size also increases to 8 AU and then to 64 AU at a predefined number of extents. The size of the extent map that defines a file can be smaller by a factor of 8 and 64 depending on the file size. The initial extent size is equal to the allocation unit size and it increases by a factor of 8 and 64 at predefined thresholds. 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 storage 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 rebalance operation. So, as a DBA, you always have the possibility to defragment your disk group by executing a rebalance operation.
• #47: ASM Scalability and Performance (continued) ASM imposes the following limits: 63 disk groups in a storage system 10,000 ASM disks in a storage system 4 petabyte maximum storage for each ASM disk 40 exabyte maximum storage for each storage system 1 million files for each disk group Maximum files sizes depending on the redundancy type of the disk groups used: 140 PB for external redundancy (value currently greater than possible database file size), 42 PB for normal redundancy, and 15 PB for high redundancy