| Oracle® Database Administrator's Guide 10g Release 1 (10.1) Part Number B10739-01 |
|
|
View PDF |
| Oracle® Database Administrator's Guide 10g Release 1 (10.1) Part Number B10739-01 |
|
|
View PDF |
This chapter briefly discusses some of the concepts b ehind Automatic Storage Management and describes how to use it. It contains the following topics:
Automatic Storage Management (ASM) simplifies database administr ation. It eliminates the need for you, as a DBA, to directly manage potentially thousands of Oracle database files. It does this by e nabling you to create disk groups, which are comprised of disks and the files that reside on them. You only need to manage a small number of disk groups.
In the SQL statements that you use for creating database structures such as tablespaces, redo log and archive log files, and control files, you specify file location in terms of disk groups. Automatic Storage Management t hen creates and manages the associated underlying files for you.
Automatic Storage Management extends the power of Oracle-mana ged files. With Oracle-managed files, files are created and managed automatically for you, but with Automatic Storage Management you get the additional benefits of features such as mirroring and striping.
Automatic Storage Management does not eliminate any ex isting database functionality. Existing databases are able to operate as they always have. Existing databases using file systems or w ith storage on raw devices can operate as they always have. New files can be created as ASM files while old ones are administered in the old way. Databases can have a mixture of ASM files, Oracle-managed files, and manually managed files all at the same time.
To create a database that uses storage managed by Automatic Storage Management, you must first start an ASM instance. However, an AS M instance does not require that a database instance is running
Automatic Storage Management is integrated into the database s erver; you do not need to install it as a separate product.
The primary component of Automatic Storage Management is the disk group. You configure Automatic Storage Management by creating disk groups, which, in your database instance, can then be specified as the default location for files created in the database. Oracle provides SQL statements that create and manage disk groups, their contents, and their meta data.
A disk group consists of a grouping of disks that are managed together as a unit. These disks are referred to as ASM disks. Files written on ASM disks are ASM files, whose names are automatically generated by Automatic
Storage Management. You can specify user-friendly alias names for ASM files, but you must create a hierarchical
You can affect how Automatic Storage Management places files on disks by specifying failure groups. Failure groups define disks that share components, such that if one fails then other d isks sharing the component might also fail. An example of what you might define as a failure group would be a set of SCSI disks shari ng the same SCSI controller. Failure groups are used to determine which ASM disks to use for storing redundant data. For example, if two-way mirroring is specified for a file, then redundant copies of file extents must be stored in separate failure groups.
Templates are used to provide the attribute information about ASM files created in ASM disk groups. These templates si
mplify file creation by mapping complex file attribute specifications into a single name. For example, a template named ONLINEL
OG provides the file redundancy and striping attributes for all redo log files written to ASM disks. For each disk group, Auto
matic Storage Management provides a set of initial system templates, as shown in the table in "Managing Disk Grou
p Templates", suitable for most needs, but you can modify the templates or create new ones to meet unique requirements.
|
DBCA eases the configuring and creation of your database while EM provides an integrated approach for managing both your ASM instance and database instance. |
The functionality of an ASM instance can be summarized as follows:
It manages groups of disks, called disk groups.
It protects the data withi n a disk group.
It provides near-optimal I/O balancing without any manual tuning.
It enables the user to manage database objects such as tablespaces without needing to specify and track filenames.
It supports large files.
This section discusses the administration of an ASM instance in terms of its startup and shutdown, and its behavior and interaction with the database instance. The major part of the administration of an ASM instance, once it is started, is the creation and maintenance of disk groups and their metadata. This is discussed in "Configuring the Components of Automatic Storage Management".
This section contains the following topics:
Automatic Storage Management is always installed by the Oracle Universal Inst aller when you install your database software. The Database Configuration Assistant (DBCA) determines if an ASM instance already exis ts, and if not, then you are given the option of creating and configuring an ASM instance as part of database creation and configurat ion. If an ASM instance already exists, then it is used instead.
DBCA also configures your instance parameter file and passwor d file.
Au tomatic Storage Management security considerations derive from the fact that a particular ASM instance is tightly bound to one or mor e database instances operating on the same server. In effect, the ASM instance is a logical extension of these database instances. Bo th the ASM instance and the database instances must have equivalent operating system access rights (read/write) to the disk group mem ber disks. For UNIX this is typically provided through shared UNIX group membership.
ASM instances do not have a data dictiona ry, so the only way to connect to one is as an administrator. This means you use operating system authentication and connect as SYSDB A or SYSOPER, or to connect remotely, use a password file.
Using operating system authentication, the authorization to connect
with the SYSDBA privilege is granted through the use of an operating system group. On UNIX, this is typically the dba group. By default, members of the dba group are authorized to connect with the SYSDBA privilege
on all instances on the node, including the ASM instance. Users who connect to the ASM instance with SYSDBA privilege h
ave complete administrative access to all disk groups that are managed by that ASM instance.
|
See Also: "Database Administrato r Authentication" for information about OS and password file authentication as relating to connecting to a database instance. Adm inistrators are similarly authenticated and connected for an ASM instance. |
Some initialization parameters are specifically relevant to an ASM instance. Of those initialization parameters intende d for a database instance, only a few are relevant to an ASM instance. You can set those parameters at database creation time using D atabase Configuration Assistant or later using Enterprise Manager. The remainder of this section describes setting the parameters man ually by editing the initialization parameter file.
The following initializatio
n parameters relate to an ASM instance. Parameters that start with ASM_ cannot be set in database instances.
| Descript ion | |
|---|---|
IN
STANCE_TYPE |
Must be set to INSTANCE_TYPE = ASM.
Note: This is the only required parameter. All other parameters take suitable defaults for most environments. |
DB_UNIQUE_NAME |
Unique name for this group of ASM instances within the cluster or on a node.
Default: |
ASM_POWER_LIMIT |
The maximum power o
n an ASM instance for disk rebalancing.
Default: 1 See Also: "Tuning Rebalance Operat ions" |
ASM_DISKSTRING
| Limits the set of disks that Automatic Storage Management considers for discovery.
Default: See Also: "Improving Disk Discovery Time" |
ASM_DISKGROUPS |
Lists the names of disk groups to be mounted by an ASM instance at startup, or when the ALTER DISKGROUP ALL MOUNT s
tatement is used.
Default: |
Oracle Database can perform one rebalance at a time on a given instance. The rebalance power is constra
ined by the value of the ASM_POWER_LIMIT initialization parameter. You can adjust this parameter dynamically. The higher
the limit, the faster a rebalance operation may complete. Lower values cause rebalancing to take longer, but consume fewer processin
g and I/O resources. If the POWER clause is not specified, or when rebalance is implicitly invoked by adding or dropping
a disk, the power defaults to the ASM_POWER_LIMIT.
The V$ASM_OPERATION view provides information th
at can be used for adjusting ASM_POWER_LIMIT and the resulting power of rebalance operations. If the DESIRED_POWER
column value is less than the ACTUAL_POWER column value for a given rebalance operation, then ASM_POWER_LI
MIT is impacting the rebalance.
The V$ASM_OPERATION view also gives an estimate in the EST_MINUTES column of the amount of time remaining for the operation to complete. You can see the effect of changing the power of rebalance
by observing the change in the time estimate.
If a rebalance is in progress because a failed disk is being dropped, increasin
g the power of the rebalance shortens the window during which redundant copies on the failed disk are being reconstructed on other di
sks. Lowering ASM_POWER_LIMIT reduces the amount of CPU and I/O bandwidth that Automatic Storage Management consumes for
a rebalance. This leaves these resources available for other applications, such as the database.
The default value errors on the side of minimizing disruption to other applications. The appropriate value is dependent upon your hardware configuration as well as performance and availability requirements.
The value for the ASM_DISKSTRING initialization parameter is an operating system dependent value us
ed by Automatic Storage Management to limit the set of disks considered for discovery. When a new disk is added to a disk group, each
ASM instance that has the disk group mounted must be able to discover the new disk using its ASM_DISKSTRING.
In
many cases, the default value is sufficient. Using a more restrictive value may reduce the time required for Automatic Storage Manage
ment to perform discovery, and thus improve disk group mount time or the time for adding a disk to a disk group. It may be necessary
to dynamically change the ASM_DISKSTRING before adding a disk so that the new disk will be discovered through this param
eter.
If your site is using a third-party vendor ASMLIB, that vendor may have discovery string conventions that should be used
for ASM_DISKSTRING.
If you specify a database instance initialization parameter in an ASM initialization parameter file, it can have one of three e ffects:
If the parameter is not valid in the ASM instance, it produces a ORA-15021 error.
Some database parameters can be specified and are valid in an ASM instance, for example those relating to dump destina tions and some buffer cache parameters. In general, Oracle will select appropriate defaults for any database parameters that are rele vant to the ASM instance.
If you specify any of the ASM specific parameters (names start with ASM_) in
a database instance parameter file, you will receive an ORA-15021 error.
The following is a sample SQL*Plus session where an ASM instance is started:
% sqlplus /nolog SQL> CONNECT / AS sysdba Connected to an idle in stance. SQL> STARTUP ASM instance started Total System Global Area 147936196 bytes Fixed Size 324548 bytes Variable Size 96468992 bytes Database Buffers 50331648 bytes Redo Buffers 811008 bytes ASM diskgroups mounted
ASM instances are smaller than database instances. A 64 MB SGA should be sufficient for all but the largest ASM installations.
When an ASM instance initializes, ASM is able to discover and look at the contents of
all of the disks in the disk groups that are pointed to by the ASM_DISKSTRING initialization parameter. This saves you
from having to specify a path for each of the disks in the disk group.
Disk group mounting requires that an ASM instance doing disk discovery be able to access all the disks within the disk group that any other ASM instance having previously mounted the disk group believes are members of that disk group. It is vital that any disk configuration errors be detected before a disk group is moun ted.
Automatic Storage Management attempts to identify the following configuration errors:
A single disk with different mount points is presented to an ASM instance. This can be caused by multiple paths to a single disk. In
this case, if the disk in question is part of a disk group, disk group mount fails. If the disk is being added to a disk group with
ADD DISK or CREATE DISKGROUP, the command fails. To correct the error, restrict the disk string so that it
does not include multiple paths to the same disk.
Multiple ASM disks, with the same ASM label, passed to separate AS M instances as the same disk. In this case, disk group mount fails.
Disks that were not intended to be ASM disks are passed to an ASM instance by the discovery function. ASM does not overwrite a disk if it recognizes the header as that of an Oracle object.
When an ASM instance fails, then all Oracle database ins tances on the same node as that ASM instance and that use a disk group managed by that ASM instance also fail. In a single ASM instan ce configuration, if the ASM instance fails while ASM metadata is open for update, then after the ASM instance reinitializes, it read s the disk group log and recovers all transient changes.
With multiple ASM instances sharing disk groups, if one ASM instance should fail, another ASM instance automatically recovers transient ASM metadata changes caused by the failed instance. The failure of an Oracle database instance is not significant here because only ASM instances update ASM metadata.
Using SQL*Plus, Automatic S
torage Management shutdown is initiated by issuing the SHUTDOWN command. For example:
% sq lplus /nolog SQL> CONNECT / AS sysdba Connected. SQL> SHUTDOWN NORMAL
The table that follows lists the SHUTDO
WN modes and describes the behavior of the ASM instance in each mode.
| SHUTDOWN Mode | Action Taken By Automatic Storage Management |
|---|---|
NORMAL |
ASM waits for the connected ASM instances (and other ASM SQL sessions) to exit befo re shutting down the instance. |
IMMEDIA
TE |
ASM waits for any in-progress SQL to complete before shutting down the ASM instance, but does not wait for database instances to disconnect. |
TRANSACTIONAL |
Same as IMMEDIATE. |
ABORT |
Automatic Storage Management immediately shuts down. |
A number of fixed tables, visible from both the ASM and database instances are provided for administrative and debugging purposes. These views are discussed i n "Viewing Information About Automatic Storage Management".
This section starts by presenting a brief overview of the components of Automatic Storage Management and di scusses some considerations and guidelines that you should be aware of as you configure your ASM instance. Then, specific operations that you use to configure and maintain the ASM instance are discussed.
If you have a database instance running and are activel y using Automatic Storage Management, you can keep the database open and running while you reconfigure disk groups.
The SQL st atements introduced in this section are only available in an ASM instance. You must first start the ASM instance. This is discussed i n "Administering an ASM Instance".
The following topics are contained in this section:
The following are some consider ations and guidelines to be aware of as you configure Automatic Storage Management.
T he following criteria can help you determine the number of disk groups that you create:
Disks in a given disk group should have similar size and performance characteristics. If you have several different types of disks in terms of size a nd performance, then it would be better to form several disk groups accordingly.
For recovery reasons, y ou might feel more comfortable having separate disk groups for your database files and flash recovery area files. Using this approach , even with the loss of one disk group, the database would still be intact.
With Automatic Storage Management, the definition of the logical volumes of a storage array i s critical to database performance. Automatic Storage Management cannot optimize database data placement when the storage array disks are subdivided or aggregated. Aggregating and subdividing the physical volumes of an array into logical volumes can hide the physica l disk boundaries from Automatic Storage Management. Consequently, careful consideration of storage array configuration is required.< /p>
Automatic Storage Management eliminat es the need for manual disk tuning. However, to ensure consistent performance, you should avoid placing dissimilar disks in the same disk group. For example, the newest and fastest disks might reside in a disk group reserved for the database work area, and slower dr ives could reside in a disk group reserved for the flash recovery area.
Automatic Storage Management load balances file activi ty by uniformly distributing file extents across all disks in a disk group. For this technique to be effective it is important that t he disks used in a disk group be of similar performance characteristics.
There may be situations where it is acceptable to tem porarily have disks of different sizes and performance co-existing in a disk group. This would be the case when migrating from an old set of disks to a new set of disks. The new disks would be added and the old disks dropped. As the old disks are dropped, their stor age is migrated to the new disks while the disk group in online.
Automatic Storage Management automatically rebalances--distributes file data evenly across all the disks of a disk group--whenever disks are added or dropped. ASM allocates files in such a way that rebalancing is not required when the numbe r of disks is static. A disk is not released from a disk group until data is moved off of the disk through rebalancing. Likewise, a n ewly added disk cannot support its share of the I/O workload until rebalancing completes. It is more efficient to add or drop multipl e disks at the same time so that they are rebalanced as a single operation. This avoids unnecessary movement of data.
You can add or drop disks without shutting down the database. However, a performance impact on I/O activity may result.
Mirroring of metadata and user data is achieved through failure groups. ASM requires a t least two failure groups for normal redundancy disk groups and at least three failure groups for high redundancy disk groups. Syste m reliability can be hampered if an insufficient number of failure groups are provided. Consequently, failure group configuration is very important to creating a highly reliable system.
You use the CREATE DISKGROUP statement to create disk groups. This statement enables you to assign a name to the disk grou
p and to specify the disks that are to be formatted as ASM disks belonging to the disk group. You specify the disks as one or more op
erating system dependent search strings that Automatic Storage Management then uses to find the disks.
You can specify the dis
ks as belonging to specific failure groups, and you can specify the redundancy level for the disk group. If you do not specify a disk
as belonging to a failure group, that disk comprises its own failure group. The redundancy level can be specified as NORMAL RE
DUNDANCY or HIGH REDUNDANCY, as defined by the disk group templates. You can also specify EXTERNAL REDUNDAN
CY for external redundancy disk groups, which do not have failure groups. You might do this if you want to use storage array p
rotection features instead.
Automatic Storage Management programmatically determines the size of each disk. If for some reason
this is not possible, or if you want to restrict the amount of space used on a disk, you are able to specify a SIZE cla
use for each disk. Automatic Storage Management creates operating system independent names for the disks in a disk group that you can
use to reference the disks in other SQL statements. Optionally, you can provide your own name for a disk using the NAME
clause.
The ASM instance ensures that any disk being included in a disk group is addressable and usable. This requires readin g the first block of the disk to determine if it already belongs in a disk group. If not, a header is written. It is not possible for a disk to be a member of multiple disk groups.
However, you can force a disk that is already a member of another disk group t
o become a member of the disk group you are creating by specifying the FORCE clause. For example, a disk with an ASM hea
der might have failed temporarily, so that its header could not be cleared when it was dropped from its disk group. Once the disk is
repaired, it is no longer part of any disk group, but it still has an ASM header. The FORCE flag is required to use the
disk in a new disk group. The original disk group must not be mounted, and the disk must have a disk group header, otherwise the oper
ation fails. Note that if you do this, you may cause another disk group to become unusable. If you specify NOFORCE, whic
h is the default, you receive an error if you attempt to include a disk that already belongs to another disk group.
The
CREATE DISKGROUP statement mounts the disk group for the first time, and adds the disk group name to the ASM_DISKGROUPS<
/code> initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used and y
ou want the disk group to be automatically mounted at instance startup, then you must remember to add the disk group name to the initialization parameter before the next time that you shut down and restart the ASM instance.
The following examples assume
that the ASM_DISKSTRING is set to '/devices/*'. Assume the following:
ASM disk discovery id
entifies the following disks in directory /devices.
/devices/diska1/
devices/diska2/devices/diska3/devices/diska4/devices/diskb1/devices/diskb2/devices/diskb3/devices/diskb4The disks diska1 - diska4 are on a separate SCSI controller from disks diskb1 - diskb4.
The following SQL*Plus session illustrates starting an ASM instance and creating a disk gr
oup named dgroup1.
% SQLPLUS /NOLOG SQL> CONNECT / AS SYSDBA Connected to an idle insta nce. SQL> STARTUP NOMOUNT SQL> CREATE DISKGROUP dgroup1 NORMAL REDUNDANCY 2 FAILGROUP controller1 DISK 3 '/devices/diska1 ', 4 '/devices/diska2', 5 '/devices/diska3', 6 '/devices/diska4', 7 FAILGROUP controller2 DISK 8 '/devices/diskb1', 9 '/d evices/diskb2', 10 '/devices/diskb3', 11 '/devices/diskb4';
In this example, dgroup1 is composed of eight
disks that are defined as belonging to either failure group controller1 or controller2. Since NORMAL
REDUNDANCY level is specified for the disk group, then Automatic Storage Management provides redundancy for all files created
in dgroup1 according to the attributes specified in the disk group templates.
For example, in the system default
template shown in the table in "Managing Disk Group Templates", normal redundancy for the online redo log fil
es (ONLINELOG template) is two-way mirroring. This means that when one copy of a redo log file extent is written to a di
sk in failure group controller1, a mirrored copy of the file extent is written to a disk in failure group controll
er2. You can see that to support normal redundancy level, at least two failure groups must be defined.
Since no N
AME clauses are provided for any of the disks being included in the disk group, the disks are assigned the names of dgroup1_00
01, dgroup1_0002, ..., dgroup1_0008.
At a later time after the creation of a disk group, you can change its composition by adding more disks, r
esizing disks, or dropping disks. You use clauses of the ALTER DISKGROUP statement to perform these actions. You can perform multiple operations with one
Automatic Storage Management automatically rebalances file extents when the composition
of a disk group changes. Because rebalancing can be a long running operation, the ALTER DISKGROUP statement does not wai
t until the operation is complete before returning. To monitor progress of these long running operations, query the V$ASM_OPERA
TION dynamic performance view.
The ADD clause of the ALTER DISKGROUP statement lets you add disks
to a disk group, or to add a failure group to the disk group. The ALTER DISKGROUP clauses that you can use when adding
disks to a disk group are similar to those that can be used when specifying the disks to be included when initially creating a disk g
roup. This is discussed in "Creating a Disk Group".
The new disks will gradually start to carry their share of the workload as rebalancing progresses.
Automatic Storage Management behavior when adding disks to a disk group is be st illustrated through examples.
The following statement adds disks to dgroup1:
ALTER DISKGROUP dgroup1 ADD DISK
'/devices/diska5' NAME diska5,
'/devices/diska6' NAME diska6,
'/devices/diska7
' NAME diska7,
'/devices/diska8' NAME diska8;
Since no FAILGROUP clauses are included in the ALTE
R DISKGROUP statement, each disk is assigned to its own failgroup. The NAME clauses assign names to the disks, ot
herwise they would have been assigned system generated names.
The statements presented in this example demonstrate the interactions of disk
discovery with the ADD DISK operation.
Assume that disk discovery now identifies the following disks in directory
/devices:
/devices/diska1 -- member of dgroup1/devices/diska2
-- member of dgroup1/devices/diska3 -- member of dgroup1/devices/diska4 -- member of dgroup1
/devices/diska5 -- candidate disk
/devices/diska6 -- can
didate disk
/devices/diska7 -- candidate disk
/devices/diska8 -- candidate disk
/de
vices/diskb1 -- member of dgroup1
/devices/diskb2 -- member of dgroup1
/devices/diskb3 -- member of dgroup1/devices/diskb4 -- member of dgroup1/devices/diskc1 -- member of dgroup2/devices/diskc2 -- member of dgroup2<
br />
/devices/diskc3 -- member of dgroup3/devices/diskc4 -- candidate disk/devices/diskd1 -- candidate disk/devices/diskd2 -- candidate disk/devices/diskd3 --
candidate disk/devices/diskd4 -- candidate diskIssuing the following statement adds disks /device
s/diska5 - /devices/diska8 to dgroup1. It ignores /devices/diska1 - /devices/diska4 bec
ause they already belong to dgroup1, but does not fail because the other disks that match the search string are not alre
ady members of any other disk group.
ALTER DISKGROUP dgroup1 ADD DISK
'/devices/diska*';
The following statement will fail, since the /devices/diska2 search string only matches a disk that already belongs t
o dgroup1:
ALTER DISKGROUP dgroup1 ADD DISK
'/devices/diska2',
'/devices/diskd4'
;
The following statement to add disks to dgroup1 will fail because the search string matches a disk that is
contained in another disk group. Specifically, /devices/diskc1 belongs to disk group dgroup2.
ALTER DISKGROUP dgroup1 ADD DISK
'/devices/disk*1';
The following statement succeeds in adding /devices/diskd1 - /devices/diskd4 to disk group dgroup1. It does
not matter that /devices/diskd4 is included in both search strings (or that /devices/diska4 and /dev
ices/diskb4 are already members of dgroup1).
ALTER DISKGROUP dgroup1 ADD DISK
'/devices/disk*4',
'/devices/diskd*';
The following use of the FORCE clause allows /devices/dis
kc3 to be added to dgroup2, even though it is a current member of dgroup3.
ALTER DISKGROUP dgroup2 ADD DISK
'/devices/diskc3' FORCE;
For this statement to succeed, dgroup3 c
annot be mounted.
To drop disks from a disk group, use the DISK clause of the ALTER DISKGROUP statement. You can also drop all of the disks in specified failure groups using the DRO
P DISKS IN FAILGROUP clause.
When a disk is dropped, the disk group is rebalance
d by moving all of the file extents from the dropped disk to other disks in the disk group. The header on the dropped disk is cleared
. If you specify the FORCE clause for the drop operation, the disk is dropped even if Automatic Storage Management canno
t read or write to the disk. You cannot use the FORCE flag when dropping a disk from an external redundancy disk group.<
/p>
Dropping Disks from Disk Groups: Example 1
This
example drops diska5 (the operating system independent name assigned to /devices/c0t4d0s2 in "Adding Disks to a Disk Group: Example 1") from disk group dgroup1.
ALTER DISKGROUP dgroup1 DROP DISK diska5;
This example also shows dropping diska5 from disk group dgroup1, but it illustrates how multiple actio
ns are possible with one ALTER DISKGROUP statement.
ALTER DISKGROUP dgroup1 DROP DISK disk
A5
ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;
The RESIZE clause of ALTER DISKGROUP enables you to perform the following operations:
Resize all disks in t he disk group
Resize specific disks
Resize all of the disks in a specified failure group
If you do not specify a new size in the SIZE clause then Automatic Storage Management use
s the size of the disk as returned by the operating system. This could be a means of recovering disk space when you had previously re
stricted the size of the disk by specifying a size smaller than disk capacity.
The new size is written to the ASM disk header record and if the size of the disk is increasing, then the new space is immediately available for allocation. If the size is decreasi ng, rebalancing must relocate file extents beyond the new size limit to available space below the limit. If the rebalance operation c an successfully relocate all extents, then the new size is made permanent, otherwise the rebalance fails.
The following example resizes all o
f the disks in failgroup failgrp1 of disk group dgroup1. If the new size is greater than disk capacity, the
statement will fail.
ALTER DISKGROUP dgroup1
RESIZE DISKS IN FAILGROUP failgrp1 SIZE 100G;
The UNDROP DISKS clause of the ALTER DISKGROUP statement enables you to c
ancel all pending drops of disks within disk groups. If a drop disk operation has already completed, then this statement cannot be us
ed to restore it. This statement cannot be used to restore disks that are being dropped as the result of a DROP DISKGROUP statement, or for disks that are b
eing dropped using the FORCE clause.
The following example cancels the dropping of disks from disk group dgroup1:
ALTER DISKGROUP dgroup1 UNDROP DISKS;
REBALANCE clause of the ALTER DISKGROUP statement. This would normally not be
required, since Automatic Storage Management automatically rebalances disk groups when their composition changes. You might want to d
o a manual rebalance operation if you want to control the speed of what would otherwise be an automatic rebalance operation.
T
he POWER clause of the ALTER DISKGROUP ... REBALANCE statement specifies the degree of parallelization, and
thus the speed of the rebalance operation. It can be set to a value from 0 to 11, where a value of 0 stops rebalancing and a value o
f 11 (the default) causes rebalancing to occur as fast as possible. The power level of an ongoing rebalance operation can be changed
by entering the rebalance statement with a new level. If you specify a power level of 0, rebalancing is halted until the statement is
either implicitly or explicitly reinvoked.
The dynamic initialization parameter ASM_POWER_LIMIT specifies a limi
t on the degree of parallelization for rebalance operations. Even if you specify a higher value in the POWER clause, the
degree of parallelization will not exceed the value specified by the ASM_POWER_LIMIT parameter.
The ALTER
DISK GROUP ... REBALANCE statement uses the resources of the single node upon which it is started. ASM can perform one rebalan
ce at a time on a given instance. The rebalance power is constrained by the value of the ASM_POWER_LIMIT initialization
parameter.
You can query the V$ASM_OPERATION view for help adjusting ASM_POWER_LIMIT and the resulti
ng power of rebalance operations. If the DESIRED_POWER column value is less than the ACTUAL_POWER column va
lue for a given rebalance operation, then ASM_POWER_LIMIT is impacting the rebalance. The EST_MINUTES colum
n indicates the amount of time remaining for the operation to complete. You can see the effect of changing the power of rebalance by
observing the change in the time estimate.
Rebalancing continues across a failure of the ASM instance performing the rebalance .
The following exa
mple manually rebalances the disk group dgroup2:
ALTER DISKGROUP dgroup2 REBALANCE POWER 5 ;
Disk groups that are specified in the ASM_DISKGROUPS initialization parameter are mounted automaticall
y at ASM instance startup. This makes them available to all database instances running on the same node as Automatic Storage Manageme
nt. The disk groups are dismounted at ASM instance shutdown. Automatic Storage Management also automatically mounts a disk group when
you initially create it, and dismounts a disk group if you drop it.
There may be times that you want to mount or dismount dis
k groups manually. For these actions use the ALTER DISKGROUP ... MOUNT or ALTER DISKGROUP ... DISMOUNT stat
ement. You can mount or dismount disk groups by name, or specify ALL.
If you try to dismount a disk group that co
ntains open files, the statement will fail, unless you also specify the FORCE clause.
The following statement dismounts all disk group s that are currently mounted to the ASM instance:
ALTER DISKGROUP ALL DISMOUNT;
The following statement mounts disk
group dgroup1:
ALTER DISKGROUP dgroup1 MOUNT;
A template is a named collection of attributes that are applied to files created within a disk group. Oracle provides a set of initial system default templates that Automatic Storage Management ass ociates with a disk group when it is created. The table that follows lists the system default templates and the attributes they apply to the various file types that Automatic Storage Management supports.
You can add new templates to a disk group, change exist
ing ones, or drop templates using clauses of the ALTER DISKGROUP statement. The V$ASM_TEMPLATE view lists all of the templates known to the ASM instance.
Table 12-1 Automatic Storage Management System Default File Group Templates
| Template Name | File Type | External Redundancy< /th> | Normal Redundancy | High Redundancy | Striped |
|---|---|---|---|---|---|
CONTROL |
Control files | Unprotected | 2-way mirror | 3-way mirror | Fine |
DATAFILE |
Datafiles and copies | Unprotected | 2-way mirror | 3-way mirror | Coarse |
ON
LINELOG |
Online logs | Unprotecte d | 2-way mirror | 3-way mirror | Fine |
ARCHIVELOG |
Archive logs | Unprotected | 2-way mirror | 3-way mirror | Coarse |
TEMPFILE |
Tempfiles | Unprotected | 2-way mirror | 3-way mirror | Coarse |
BACKUPSET |
Datafile backup pieces, datafile incrementa l backup pieces, and archive log backup pieces | Unprotected | 2-way mirror | 3-way mirror | Coarse |
PARAMETERFILE
|
SPFILEs | Unprotected | 2-way mirror | 3-way mirror | Coarse |
DATAGUARDC
ONFIG |
Disaster recovery configurations (used in standby databases) | Unprotected | 2-way mirror | 3-way mirror | Coarse |
FLASHBACK |
Flashback l ogs | Unprotected | 2-way mirror | < td align="left" headers="r10c1-t9 r1c5-t9">3-way mirrorFine | |
CHANGETRACKING |
Block change tracking data (used during incremental backups) | Unprotected< /td> | 2-way mirror | 3-way mirror | Coarse |
DUMPSET |
Data Pump dumpset | Unprotected | 2-way mirror | 3- way mirror | Coarse |
XTRANSPORT |
Cross-platform converted datafile | Unprotected | 2-way mirror | 3-way mirror | Coarse |
AUTOBACKUP |
Automatic backup files | Unprotected | 2-way mirror | 3-way mirror | Coarse |
To add a new templ
ate for a disk group use the ADD TEMPLATE clause of the ALTER DISKGROUP statement. You specify the name of the template, its redundancy attribu
tes, and its striping attribute.
The following statement creates a new template named reliable:
ALTER DISK GROUP dgroup2 ADD TEMPLATE reliable ATTRIBUTES (MIRROR FINE);
This statement creates a template that applies the followin g attributes to files:
| Template Name | External Redundancy | Normal Redundancy | High Redundancy | Striping |
|---|---|---|---|---|
RELIABLE |
You cannot specify RELIABLE for an external redundancy group |
2-way mirror | 3-way mirror | Every 128 KB |
This statement creates a new template named unreliable that specifies files are to be unprotect
ed (no mirroring). Oracle discourages the use of unprotected files; this example is presented only to further illustrate how the attr
ibutes for templates are set.
ALTER DISKGROUP dgroup2 ADD TEMPLATE unreliable
ATTRIBUTES (UNPROTE
CTED);
This statement creates a template that applies the following attributes to files:
| Template Name | < th align="left" valign="bottom" id="r1c2-t11">External RedundancyNormal Redundancy | High Redundancy | Striping | |
|---|---|---|---|---|
UNRELIABLE |
Unprotected | Unprotected | You cannot specify UNRELIABLE for a high redundancy group. |
No |
The ALTER TEMPLATE clause of the ALTER DISKGROUP statement enables you to modify the attribute specifications
of an existing system default or user-defined disk group template. Only specified template properties are changed. Unspecified proper
ties retain their current value.
When you modify an existing template, only new files created by the template will reflect the attribute changes. Existing files maintain their attributes.
The following example changes the striping attribute specification of the dgroup2.
ALTER DISKGROUP dgroup2 ALTER TEMPLATE
reliable
ATTRIBUTES (COARSE);
Use the DR
OP TEMPLATE clause of the A
LTER DISKGROUP statement to drop one or more templates from a disk group. You can only drop templates that are user-define
d; you cannot drop system default templates.
This example drops the previously created unprotected template for dgr
oup2:
ALTER DISKGROUP dgroup2 DROP TEMPLATE unreliable;
Every ASM disk group contains a hierarchical directory structure consisting of the fully qualified names of the files in the disk group, along with alias filename s. A fully qualified filename, also called a system alias, is always generated automatically by Automatic Storage Ma nagement when a file is created.
You can create an additional (more user-friendly) alias for each ASM filename during file cre
ation. You can also create an alias for an existing filename using clauses of the ALTER DISKGROUP statement as described in "Managing Al
ias Names for ASM Filenames". But you must first create a directory structure to support whatever alias file naming convention yo
u choose to use.
This section describes how to use the ALTER DISKGROUP statement to create a directory structure
for alias filenames. It also describes how you can rename a directory or drop a directory.
Use the ADD DIRECTORY clause of the ALTER DISKGROUP statement to create a hierarchical directory structure for alia
s names for ASM files. Use the slash character (/) to separate components of the directory path. The directory path must start with t
he disk group name, preceded by a plus sign (+), followed by any subdirectory names of your choice.
The parent directory must exist before attempting to create a subdirectory or alias in that directory.
The following statement creates a hierarchical directory for disk g
roup dgroup1, which can contain, for example, the alias name +dgroup1/mydir/control_file1:
ALTER DISKGROUP dgroup1 ADD DIRECTORY '+dgroup1/mydir';
Assume no subdirectory exists under the directory +dgoup1/mydir
, then the following statement will fail:
ALTER DISKGROUP dgroup1
ADD DIRECTORY 'dgroup1/my
dir/does_not_exist/second_dir;
The The following stat
ement renames a directory:RENAME DIRECTORY clau
se of the ALTER DISKGROUP statement enables you to rename a directory. System created directories (those containing system alias names) cannot be renamed.
Renaming a Directory: Example
ALTER DISKGROUP dgroup1 RENAME DIRECTORY '+dgroup1/mydir'
TO '+dgroup1/
yourdir';
You can delete a directory using the DROP DIRECTORY clause of the ALTER DISKGROU
P statement. You cannot drop a system created directory. You cannot drop a directory containing alias names unless you als
o specify the FORCE clause.
This statement deletes a directory along with its contents:
ALTER DISKGROUP dgr oup1 DROP DIRECTORY '+dgroup1/yourdir' FORCE;
After you have created the hierarchical directory structure for alias names, you can create alias names in the disk group. Alias names are intended to provide a more user-friendly means of referring to ASM files, rather than using the fully qualified names (system aliases) that Automatic Storage Management always generates when it cr eates a file.
As mentioned earlier, these alias names can be created when the file is created in the database, or by adding an
alias or renaming existing alias names using the ADD ALIAS or RENAME ALIAS clauses of the ALTER DISKGROUP statement. You delete a
n alias using the DROP ALIAS clause. You cannot delete or rename a system alias.
The V$ASM_ALIAS view contains a row for every alias name
known to the ASM instance. It contains a column, SYSTEM_CREATED, that specifies if the alias is system generated
Use the ADD ALIAS clause of the ALTER DISKGROUP statement to create an alias name for an ASM filena
me. The alias name must consist of the full directory path and the alias itself.
The following statement adds a new alias name f or a system generated file name:
ALTER DISKGROUP dgroup1 ADD ALIAS '+dgroup1/mydir/second.dbf'
FOR
'+dgroupA/sample/datafile/mytable.342.3';
This statement illustrates another means of specifying the ASM filename for which the alias is to be created. It uses the numeric form of the ASM filename, which is an abbreviated and derived form of the system gen erated filename.
ALTER DISKGROUP dgroup1 ADD ALIAS '+dgroup1/mydir/second.dbf'
FOR '+dgroupA.342.3
';
Use the RENAME ALIAS clause of
the ALTER DISKGROUP sta
tement to rename an alias for an ASM filename. The old and the new alias names must consist of the full directory paths of the alias
names.
The following statement renames an alias:
ALTER DISKGROUP dgroup1 RENAME ALIAS '+dgroup1/my
dir/datafile.dbf'
TO '+dgroupA/payroll/compensation.dbf';
Use the DROP ALIAS clause of the ALTER DISKGROUP statement to drop an alias for an ASM filename. The alias name must consist of
the full directory path and the alias itself. The underlying file to which the alias refers is unchanged.
The following state ment deletes an alias:
ALTER DISKGROUP dgroup1 DELETE ALIAS '+dgroup1/payroll/compensation.dbf';
The following statement will fail because it attempts to delete a system alias. This is not allowed:
ALTER DISKGROUP dgroup1
DELETE ALIAS '+dgroup1/sample/datafile/mytable.342.3';
You can de
lete ASM files and their associated alias names from a disk group using the DROP FILE clause of the ALTER DISKGROUP statement. You must use a f
ully qualified filename, a numeric filename, or an alias name when specifying the file that you want to delete.
Some reasons w hy you might need to delete files include:
Files created using aliases are not Oracle-managed files. Con sequently, they are not automatically deleted.
A point in time recovery of a database might restore the database to a time before a tablespace was created. The restore does not delete the tablespace, but there is no reference to the tabl espace (or its datafile) in the restored database. You can manually delete the datafile.
Dropping an alias does not drop the underlying file on the file system.
The following statement uses the alias name for the file to delete b oth the file and the alias:
ALTER DISKGROUP dgroup1 DROP FILE '+dgroup1/payroll/compensation.dbf';
Dropping Files and Associated Aliases from a Disk Group: Example 2
In this example the system generated filename is used to drop the file and any associated alias:
ALTER DISKGROUP dgroup1 DROP FILE '+dgroupA/sample/datafile/mytable.342.372642';
You can check the internal cons
istency of disk group metadata using the ALTER DISKGROUP ... CHECK statement. Checking can be specified for specific fil
es in a disk group, specific disks or all disks in a disk group, or specific failure groups within a disk group. The disk group must
be mounted in order to perform these checks.
If any errors are detected, an error message is displayed and details of the erro
rs are written to the alert log. Automatic Storage Management attempts to correct any errors, unless you specify the NOREPAIR clause in your ALTER DISKGROUP ... CHECK statement.
The following statement checks for consistency in the m
etadata for all disks in the dgroup1 disk group:
ALTER DISKGROUP dgroup1 CHECK ALL;
The DROP DISKGROUP stat
ement enables you to delete an ASM disk group and optionally, all of its files. You can specify the INCLUDING CONTENTS c
lause if you want any files that may still be contained in the disk group also to be deleted. The default is EXCLUDING CONTENTS
, which provides syntactic consistency and prevents you from dropping the diskgroup if it has any contents
The ASM inst
ance must be started and the disk group must be mounted with none of the disk group files open, in order for the DROP DISKGROUP
statement to succeed. The statement does not return until the disk group has been dropped.
When you drop a disk group,
Automatic Storage Management dismounts the disk group and removes the disk group name from the ASM_DISKGROUPS initializ
ation parameter if a server parameter file is being used. If a text initialization parameter file is being used, and the disk group i
s mentioned in the ASM_DISKGROUPS initialization parameter, then you must remember to remove the disk group name from th
e ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the ASM instance.
T
he following statement deletes dgroup1:
DROP DISKGROUP dgroup1;
After ensuring
that none of the files contained in dgroup1 are open, Automatic Storage Management rewrites the header of each disk in
the disk group to remove ASM formatting information. The statement does not specify INCLUDING CONTENTS, so the drop oper
ation will fail if the diskgroup contains any files.
This section discusses how you use Automatic Storage Management to manage database files for you. When you use Automatic Storage Management, Oracl e database files are stored in ASM disk groups. These files are not visible to the operating system or its utilities, but are visible to RMAN and other Oracle supplied tools.
This following topics are contained in this section:
What Types of Files Does Automatic Storage Management Support?
Creating Archive Log Files Using Automatic Storage Management
Automatic Storage Management supports most file types requi red by the database. However, most administrative files cannot be stored on a ASM disk group. These include trace files, audit files, alert logs, backup files, export files, tar files, and core files.
Table 12-2 lists file types, indic ates if they are supported, and lists the system default template that provides the attributes for file creation. Some of the file ty pes shown in the table are related to specific products or features, and are not discussed in this book.
Table 12-2 File Types Supported by Automatic Storage Management
| File Type | Supported | Default Templates |
|---|---|---|
| Control files | yes | CONTROLFILE |
| Datafiles | yes | DATAFILE |
| Redo log files | yes | ONLINELO
G |
| Archive log files | yes | ARCHIVELOG |
| Trace files | no | n/a |
| Temporary files | yes | TEMPFILE |
| Datafile backup pi eces | yes | BACKUPSET |
| Datafile incremental backup pieces | yes | BACKUPSET |
| Archive log backup piece | yes | BACKUPSET |
| Datafile copy | yes | < td align="left" headers="r11c1-t13 r1c3-t13">|
| Persistent initialization parameter file (SPFILE) | yes | PARAMETERFILE |
| Disaster recovery configurations | yes | DATAGUARDCONFIG |
| Flashback logs | yes | FLASHBACK |
| C hange tracking file | yes | C
HANGETRACKING |
| Data Pump dumpset | yes | DUMPSET |
| Auto backup | yes | AUTOBACKUP |
| Operating system files | no | n/a |
ASM filenames can take several forms. Some of the forms are used to create ASM files, others are used to reference them. The forms that you use to create files are alias names or incomplete file names, that basically point to a disk group wherein files are created and given full y qualified names by Automatic Storage Management.
When Automatic Storage Management creates a fully qualified name, an alert
log message is written containing this ASM generated name. You can also find the generated name in database views displaying Oracle f
ile names, such as V$DATAFILE, V$LOGFILE, and so forth. You can use this name, or an abbreviated form of it
, if you later need to reference an ASM file in a SQL statement.
Like other Oracle database filenames, ASM filenames are kept in the control file and the RMAN catalog.
These are the forms of an ASM filename:
The following table specifies the valid contexts for each form of a filename
. Single-file creation is relevant for file specifications. Multiple-file creation is relevant in a *_DEST parameter.
| Filename Form | Valid Context | ||
|---|---|---|---|
| Reference | Single-File Creation | Multiple-File Creation | |
| Fully qualified filename | Yes | No | No |
| Numeric filename | Yes | No | No |
| A lias filename | Yes | Yes | No |
| Alias with template filename | No | Yes | No |
| Incomplete filename | No | Yes | Yes |
| Incomplete filename with templat e | No | Yes | < td align="left" headers="r8c1-t15 r1c2-t15">Yes|
|
Note: Fully qualified and numeric filena mes can be used in single-file create if you specify theREUSE flag, as described in "Using ASM File
names in SQL Statements". |
This form of ASM filename can be used for referencing existing ASM files. It is the filen ame that ASM always automatically generates when an ASM file is created. The fully qualified filename is also referred to as the syst em alias filename.
A fully qualified filename is derived by Automatic Storage Management and has the following form:
+group/dbname/file_type/file_type_tag.file.incarnation
Where:
+group is the disk group name.
dbname is the DB_UNIQU
E_NAME of the database to which the file belongs.
file_type is the Oracle f
ile type and can be one of the file types shown in the table that follows.
tag is
type specific information about the file and can be one of the tags shown in the table that follows.
file.incarnation is the file/incarnation pair, used to ensure uniqueness.
An example of a fully q ualified ASM filename is:
+dgroup2/sample/controlfile/CF.257.1
Table 12-3 Oracle File Types and Automatic Storage Management File Type Tags
| Automatic Storage Management file_type | Automatic Storage Management file_type_tag | Comments | |
|---|---|---|---|
CONTROLFILE |
Control files and bac kup control files | Current
Backup |
-- |
DATAFILE |
Datafiles and datafile copies | ts
name |
Tablespace into which the file is added |
ONLINELOG |
Online logs | group_group# |
-- |
A
RCHIVELOG |
Archive logs | thread#_seq_sequence# |
-- |
TEMPFILE |
Tempfiles | tsname |
Tablespace into which the file is added |
BACKUPSET |
Datafile a nd archive log backup pieces; datafile incremental backup pieces | hasspfil
e_timestamp |
hasspfile can t
ake one of two values: s indicates that the backup set includes the spfile; n indicates that the backup set does not include the spfile. |
PARAMETERFILE |
Persistent parameter fil es | spfile |
|
DAATAGUARDCONFIG |
Data Guard configuration file | db_uniqu
e_name |
Data Guard tries to use the service provider name if it is set.
Otherwise the tag defaults to DRCname. |
FLASHBACK |
Flashback logs | log_log# |
-- |
CHANGETRACKING |
Block change tracking data | ctf |
Used during incremental backups |
DUMPSET |
Data Pump dumpset | user_obj#_file# |
Dump set files encode the user name, the job number that created the dump set, and the file number a s part of the tag. |
XTRANSPORT |
Datafile convert | ts
name |
-- |
AUTOBACKUP |
Automatic backup files | hasspfile_timestamp |
hasspfile can take one of two values: s indicates that the ba
ckup set includes the spfile; n indicates that the backup set does not include the spfile. |
The numeric ASM filename can be used for referencing existing files. It is derived from t he fully qualified ASM filename and takes the form:
+group.file.incarnation
Numer ic ASM filenames can be used in any interface that requires an existing file name.
An example of a numeric ASM filename is:
+dgroup2.257.8675309
Alias ASM filenames can be used both for referencing existing ASM files and for creating new ASM files. Alias nam es start with the disk group name, after which you specify a name string of your choosing. Alias filenames are implemented using a hi erarchical directory structure, with the slash (/) character separating name components. You must have already created the directory structure, using the ALTER DISKGROUP ... CREATE DIRECTORY statement as explained in "Managing Disk Group Director ies ".
Alias ASM filenames are distinguished from fully qualified or numeric names because they do not end in a dotted pai r of numbers. It is an error to attempt to create an alias that ends in a dotted pair of numbers. Examples of ASM alias filenames are :
+dgroup1/myfiles/control_file1 +dgroup2/mydir/second.dbf
An alia
s ASM filename is normally used in the CONTROL_FILES initialization parameter.
An alias ASM filename with template is used only for ASM file c reation operations. They are of the format:
+dgroup(template_name)/alias
The crea tion and maintenance of ASM templates is discussed in "Managing Disk Group Templates". The system default tem plates that can be specified and attributes that are assigned from these templates, are shown in the table in that section. You can a lso specify user-defined templates.
An example of an alias ASM filename with template is:
+dgrou p1(spfile)/config1
Explicitly specifying a template name, as in this example, overrides the system default.
Incomplete ASM filenames are used only for f
ile creation operations and are used for both single and multiple-file creation. They consist only of the disk group name. Automatic
Storage Management uses a system default template to determine the ASM file redundancy and striping attributes. The system template t
hat is used is determined by the file type that is being created. For example, if you are creating a datafile for a tablespace, then
the datafile template is used.
An example of an incomplete ASM filename is:
+dgroup 1
Incomplete ASM filenames with templates are used only for file creation operations and are used for both single and multifile creation. They co nsist of the disk group name followed by the template name in parentheses. When you explicitly specify a template in a file name, ASM uses the specified template instead of the default template for that file type to determine redundancy and striping attributes for t he file.
An example of an incomplete ASM filename with template is:
+dgroup1(datafile)
For you to use the functionality of Automatic Storage Management, a database instance requires that an ASM instance is runn ing and that disk groups are configured. Specifically:
Start the ASM Instance.
You start t he ASM instance on the same node as the database before you start the database instance. Starting an ASM instance is discuss ed in "Starting Up an ASM Instance"
Start the database instance
Consider the followin g before you start your database instance:
To start a database instance, you must have the INSTANC
E_TYPE initialization parameter set as follows:
INSTANCE_TYPE = RDBMS
This the default .
Specify an ASM filename for any of the following initialization parameters for which you want Automati c Storage Management to automatically create and manage files (see "Creating ASM Files Using a Default Disk Group Specification":
DB_CREATE_FILE_DEST
DB_CREATE_O
NLINE_LOG_DEST_n
DB_RECOVERY_FILE_DEST
CONTRO
L_FILES
LOG_ARCHIVE_DEST_n
LOG_ARCHIVE_DEST
STANDBY_ARCHIVE_DEST
Some additional initial ization parameter considerations:
LOG_ARCHIVE_FORMAT is ignored if a disk group is specif
ied for LOG_ARCHIVE_DEST (for example, LOG_ARCHIVE_DEST = +dgroup1).
D
B_BLOCK_SIZE must be one of the standard block sizes (2K, 4K, 8K, 16K or 32K bytes).
LARG
E_POOL_SIZE must be set to at least 8 MB.
Your database instance is now able to create AS M files. You can keep your database instance open and running when you reconfigure disk groups. When you add or remove disks from a d isk group, Automatic Storage Management automatically rebalances file data in the reconfigured disk group to ensure a balanced I/O lo ad, even while the database is running.
ASM files are Oracle-managed files unless you created the file using an alias. Any Oracle-managed file is automatically deleted when it is no longer needed. An ASM file is deleted if the creation fails.
Using the Oracle-managed files feature for operatin
g system files, you can specify a directory as the default location for the creation of datafiles, tempfiles, redo log files, and con
trol files. Using the Oracle-managed files feature for ASM, you can specify a disk group, in the form of an ASM filename, as the defa
ult location for creation of these files, and additional types of files, including archived log files. As for operating system files,
the name of the default disk group is stored in an initialization parameter and is used whenever a file specification (for example,
DATAFILE clause) is not explicitly specified during file creation.
The following initialization parameters accept the multifile creation context form of ASM filenames as a destination:
| Initialization Parameter | Description |
|---|---|
DB_CREATE_FILE_DEST
|
Specifies the default disk group location in which to create:
If DB_CREATE_ONLINE _LOG_DEST_n is not specified, then also s pecifies the default disk group for:
|
DB_CREATE_ONLINE_LOG_DEST_n |
Specifies the default disk group location in which to crea
te:
|
DB_RECOVERY_FILE_DEST |
If this parameter is specified and DB_CREATE_ONLINE_LOG_DEST_n and CONTROL_FILES
are not specified, then specifies a default disk group for a flash recovery area that contains a copy of:
If no local archive destination is specified, then t
his parameter implicitly sets |
CONTROL_FILES |
Specifies a disk group in which to create control files. |
The following initialization parameters accept the multifile creation context form of the ASM filenames and ASM dire ctory names as a destination:
| Description | |
|---|---|
LOG_ARCHIVE_DEST_n |
Specifies a default disk group or ASM directory as destination for archiving redo log files | LOG_ARCHIVE_DEST |
Optional parameter to use to specify a default disk group or ASM directory as destination for archiving re do log files. Use when specifying only one destination. |
STANDBY_ARCHIVE_DEST |
Relevant only for a standby databas e in managed recovery mode. It specifies a default disk group or ASM directory that is the location of archive logs arriving from a p rimary database. Not discussed in this book. See Oracle Data Gua rd Concepts and Administration. |
The followi ng example illustrates how an ASM file, in this case a datafile, might be created in a default disk group.
Assume the follow ing initialization parameter setting:
DB_CREATE_FILE_DEST = '+dgroup1'
The following statem
ent creates tablespace tspace1.
CREATE TABLESPACE tspace1;
Automatic Storage M
anagement automatically creates and manages its datafile on ASM disks in the disk group dgroup1. File extents are stored
using the attributes defined by the system default template for a datafile.
You can specify ASM filenames in the file specification clause of your SQ
L statements. If you are creating a file for the first time, then use the creation form of an ASM filename. If the ASM file already e
xists, then the filename must be in a reference context form and, if trying to re-create the file, the REUSE clause spec
ified. The space will be reused for the new file. This usage might occur when, for example, trying to re-create a control file, as sh
own in "Creating a Control File Using Automatic Storage Management".
If a reference context form is us
ed with the REUSE clause, and the file does not exist, the numeric portion of the reference context form is ignored, and
a new file is created as if the incomplete filename had been specified.
Partially created files resulting from system errors are automatically deleted.
The following is an example of specifying an ASM filename in a SQL statement. In this case, it is used in the file creation context:
CREATE TABLESPACE tspace2 DATAFILE '+dgroup2' SIZE 200M AUTOEXTEND ON;
The tablespace tspace2 is created and is comprised of one datafile of size 200M contained in the disk group <
code>dgroup2. The datafile is set to auto-extensible with an unlimited maximum size. An AUTOEXTEND clause can be
used to override this default.
The recommended method of creating your database is to use the Database
Configuration Assistant (DBCA). However, if you choose to create your database manually using the CREATE DATABASE statem
ent, then Automatic Storage Management enables you to create a database and all of its underlying files with a minimum of input from
you.
The following is an example of using the CREATE DATABASE statement, where database files are created and man
aged automatically by Automatic Storage Management.
This example creates a database with the following ASM files:
A SYSTEM tablespace datafile in disk group dgroup1.
A SYSAUX tablespace datafile in disk group dgroup1. The tablespace is locally managed with automatic segme
nt-space management.
A multiplexed online redo log is created with two online log groups, one member of
each in dgroup1 and dgroup2 (flash recovery area).
If automatic undo managemen
t mode is enabled, then an undo tablespace datafile in directory dgroup1.
If no CONTR
OL_FILES initialization parameter is specified, then two control files, one in drgoup1 and another in dgrou
p2 (flash recovery area). The control file in dgroup1 is the primary control file.
The following initialization parameter settings are included in the initialization parameter file:
DB_CREATE_FILE_DE ST = '+dgroup1' DB_RECOVERY_FILE_DEST = '+dgroup2' DB_RECOVERY_FILE_DEST_SIZE = 10G
The following statement is issued at the SQL prompt:
SQL> CREATE DATABASE sample;
When Automatic Storage Management creates a datafi
le for a permanent tablespace (or a tempfile for a temporary tablespace), the datafile is set to auto-extensible with an unlimited ma
ximum size and 100 MB default size. You can use the AUTOEXTEND clause to override this default extensibility and the
Automatic Storage Management applies attributes to the datafile, as specif ied in the system default template for a datafile as shown in the table in "Managing Disk Group Templates". Y ou can also create and specify your own template.
Files in a tablespace may be in both ASM files and non-ASM files as a result of the tablespace history. RMAN commands enable non-ASM files to be relocated to a ASM disk group and enable ASM files to be relocat ed as non-ASM files.
The following are some examples of creating tablespaces using Automatic Storage Management. The examples assume that disk groups have already been configured.
This example illustrates "out of the box" usage of Automatic Storage Management. You let Automatic Storage Management create and manage the tablespace datafile for you, using Oracle supplied defaults t hat are adequate for most situations.
Assume the following initialization parameter setting:
DB_ CREATE_FILE_DEST = '+dgroup2'
The following statement creates the tablespace and its datafile:
CREATE TABLESPACE tspace2;
The following statements create a tablespace that uses a user defined templat e (assume it has been defined) to specify the redundancy and striping attributes of the datafile:
SQL&g t; ALTER SYSTEM SET DB_CREATE_FILE_DEST = '+dgroup1(my_template)'; SQL> CREATE TABLESPACE tspace3;
The fo
llowing statement creates an undo tablespace with a datafile that has an alias name and its attributes are set by the user defined te
mplate my_undo_temp. It assumes a directory has been created in disk group dgroup3 to contain the alias nam
e and that the user defined template exists. Because an alias is used to create the datafile, the file is not an Oracle-managed file
and will not be automatically deleted when the tablespace is dropped.
CREATE UNDO TABLESPACE myundo DATAFILE '+dgroup3(my_undo_temp)/myfiles/my_undo_ts' SIZE 200M;
The following statement drops the file manually after the tablespace has been dropped:
ALTER DISKGROUP dgroup3 DROP FLE '+dgroup3/myfiles/my_undots';
Onl
ine redo logs can be created in multiple disk groups, either implicitly in the initialization parameter file or explicitly in an
All partially created redo log files, created as a result of a system error, are automatically deleted.
The following example creates a log file with a member in each of the disk groups dgroup1 and dgro
up2.
The following parameter settings are included in the initialization parameter file:
DB_CREATE_ONLINE_LOG_DEST_1 = '+dgroup1' DB_CREATE_ONLINE_LOG_DEST_2 = '+dgroup2'
The following statement is issued at th e SQL prompt:
ALTER DATABASE ADD LOGFILE;
Control files can be explicitly created in multiple d isk groups. The filenames for control files are automatically generated. If an attempt to create a control file fails, partially crea ted control files will be automatically be deleted.
There may be times when you need to specify a control file by name. Alias
filenames are provided to allow administrators to reference ASM files with human-understandable names. The use of an alias in the spe
cification of the control file during its creation allows the DBA to later refer to the control file with a human-meaningful name. Fu
rthermore, an alias can be specified as a control file name in the CONTROL_FILES initialization parameter. Control files
created without aliases can be given alias names at a later time. The ALTER DISKGROUP ... CREATE ALI
AS statement is used for this purpose.
When creating a control file, datafiles and log files stored in an ASM disk grou
p should be given to the CREATE CONTROLFILE command using the file reference context form of their ASM file
names. However, the use of the RESETLOGS option requires the use of a file creation context form for the specification o
f the log files.
The following CREATE CONTROLFILE statement is generated by an ALTER DATABASE BACKUP CONTROLFILE TO TRACE command for a dat
abase with datafiles and log files created on disk groups dgroup1 and dgroup2:
CREATE CONTROLFILE REUSE DATABASE "SAMPLE" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 30
MA
XINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 (
'+DGROUP1/db/onlinelog/group_1.258.3',
'+DGROUP2/db/onlinelog/group_1.
256.3'
) SIZE 100M,
GROUP 2 (
'+DGROUP1/db/onlinelog/group_2.257.3',
'+DGROUP2/db/onlinelog/group_2.258.1'
) SIZE 100M
DATAFILE
'+DGROUP1/db/datafile/system.260.3',
'+DGROUP1/db/datafile/sysaux.259.3'
CHARACTER SET US7ASCII
;
This example is a CREATE CONTROLFILE statement for a database with datafiles, but uses a RESETLO
GS clause, and thus uses the creation context form for log files:
CREATE CONTROLFILE REUSE DATAB
ASE "SAMPLE" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 30
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 (
'+DGROUP1',
'+DGROUP2'
) SIZE 100M,
GROUP 2 (
'+DGROUP1',
'+DGROUP2'
) SIZE 100M
DATAFILE
'+DGROUP1/db/datafile/system.260.3',
'+DGROUP1/db/datafile/sysaux.259.3'
CHARACTER SET US7ASCII
;
Disk groups can be s
pecified as archive log destinations in the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DEST_n initialization paramete
rs. When destinations are specified in this manner, the archive log filename will be unique, even if archived twice. Partially create
d archive operations resulting from a system error are deleted and do not leave a half written file.
If LOG_ARCHIVE_DEST
is set to a disk group name, LOG_ARCHIVE_FORMAT is ignored. Unique filenames for archived logs are automatically
created by the Oracle database. If LOG_ARCHIVE_DEST is set to a directory in a disk group, LOG_ARCHIVE_FORMAT has its normal semantics.
The following sample archive log names might be generated with DB_RECOVERY_FILE_DEST set to +dgroup2. SAMPLE is the value of the DB_UNIQUE_NAME parameter:
+DGRO UP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_1_seq_38.614.3 +DGROUP2/SAMPLE/ARCHIVELOG/2003_09_23/thread_4_seq_35.609.3 +DGROUP2/SAMPLE/AR CHIVELOG/2003_09_23/thread_2_seq_34.603.3 +DGROUP2/SAMPLE/ARCHIVELOG/2003_09_25/thread_3_seq_100.621.3 +DGROUP2/SAMPLE/ARCHIVELOG/200 3_09_25/thread_1_seq_38.614.3
RMAN is critical to Automatic Storage Management and is responsible for tracking the ASM filename s and for deleting obsolete ASM files. Since ASM files cannot be accessed through normal operating system interfaces, RMAN is the pre ferred means of copying ASM files; you can also use FTP through XDB. RMAN is the only method for performing backups of a database con taining ASM files.
RMAN can also be used for moving databases or files into ASM storage.
You can use these views to query information about Automatic Storage Management:
| Description | |
|---|---|
V$ASM_DISKGROUP |
In an ASM instance, describes a disk group (number, name, size related info, state, and redundancy t
ype).
In a DB instance, contains one row for every ASM disk group mounted by the local ASM instance. |
V$ASM_CLIENT |
In an ASM instance, identifies databases using disk groups managed by the ASM instance.
In a DB instance, contains one row for the ASM instance if the database has any open ASM files. |
V$ASM_DISK |
In an ASM instance, contains one
row for every disk discovered by the ASM instance, including disks that are not part of any disk group.
In a DB instance, contai ns rows only for disks in the disk groups in use by that DB instance. |
V$ASM_FILE |
In an ASM instance, contain
s one row for every ASM file in every disk group mounted by the ASM instance.
In a DB instance, contains no rows. | V$ASM_TEMPLATE |
In an ASM instance, contains one row for every template present in every disk group mounted by the ASM insta
nce.
In a DB instance, contains no rows |
V$ASM_ALIAS |
In an ASM instance, contains one row for every alias
present in every disk group mounted by the ASM instance.
In a DB instance, contains no rows. |
V$ASM_OPERATION |
In an ASM instance, contains one row for every active ASM long running operation executing in the ASM instance.
In a DB ins tance, contains no rows. |
|
See Also: Oracle Database Reference for details on all of these dynamic performance views |
|
 Copyright © 2001, 2003 Oracle Corporation < font size="-2">All Rights Reserved. |
|
