Key Facts
- The RDBMS instance ( ASMB process ) connects to the ASM instance ( UFG process ) via BEQ as SYSDBA ( CSS provides this info )
- ASM tracks all the file an RDBMS instance has open
- During RDBMS startup ASM sends an extend map of the first 60 AUs to the RDBMS ( note SGA is not initialized yet )
- RDBMS ( LGWR, DBWR ) performs I/O directly the the ASM disks
- Open/close and create/delete operations of ASM files are maintained by ASM
- ASM doesn’t balance I/O based on I/O statistics and if disk size is different the space allocation is different
- An read error in a RDBMs inacte never causes a disk to go OFFLINE
- If RDBMs instance gets I/O error reading from primary extend it reads from mirrors extend and fixes the I/O problem by writing the fixed data to the primary extend
- ASM uses bad block replacement
- ASM takes the disk offline on write errors
- ASM provides better data integrity during DISK resilvering after incomplete/lost writes
Overview ASM and The Oracle Grid Infrastructure
Oracle Clusterware, ASM, Oracle ACFS, Kernel Services Driver (OKS), and Oracle ADVM software components.
These components are installed into the Grid Infrastructure home using the Oracle Universal Installation (OUI) tool.
Following a Grid Infrastructure installation on Linux and UNIX platforms, a root script is executed that copies
the Oracle ACFS, Oracle ADVM, and OKS drivers and command-line tools into operating system-specific locations.
On Linux systems, these three drivers are copied into the /lib/modules/Linux_kernel_version/kernel/drivers
directory and the command-line tools are copied into the Linux /sbin directory.
On Windows, the three drivers are copied into the %systemroot%\system32\drivers folder and the command-line tools
are copied into the %systemroot%\Program Files\Oracle folder. For single-instance homes, Oracle ACFS,
Kernel Services Driver (OKS), and Oracle ADVM drivers are installed and initially loaded into the operating
system kernel memory during execution of the Oracle Grid Infrastructure root script. However, if the server
is restarted, the three drivers must be manually loaded into the operating system kernel memory by executing
the driver load command acfsload as shown below. To execute the command, the user must have root privileges.
$ORACLE_HOME/bin/acfsload start –s Oracle Restart is part of the single server Grid Infrastructure installation
but is covered in a different eStudy.
Grid Infrastructure Home The Grid Infrastructure home directory must be separate from any database home directory.
Even though ASM and Clusterware are separate products they are installed in the same home directory. By separating
the Grid Infrastructure home directory from the database home directory, it is possible to have job role separation
for the ASM administrator from database administrators. This change facilitates patching, but has the side effect
that clusterware and ASM must be patched together. If ASM is already installed, a new ORACLE_HOME directory must
be created for the 11.2 software. ASM and Clusterware software will be installed into the new directory.
ASM Privileges
ASM Privileges There are three defined privileges for ASM: SYSASM, SYSDBA, and SYSOPER. The SYSASM privilege provides
full administrative privileges for the ASM instance. Users with the SYSASM privilege can start and stop the ASM
instance and manage ASM disks and diskgroups. In the ASM instance the SYS user has the SYSASM privilege.
The SYSDBA privilege on the ASM instance grants access to data stored on ASM. To use SQL*Plus or ASMCMD commands
to manage ASM components associated with the database connect AS SYSDBA to the database instance rather than the
ASM instance. Users connected AS SYSDBA can: Create and delete files, aliases, directories, and templates, examine
various ASM instance views, operate on files that were created by this user ....
During installation, the ASMSNMP user with SYSDBA privileges is created for monitoring the Oracle ASM instance.
Users granted the SYSOPER privilege on the ASM instance, are allowed to startup, shutdown, mount, dismount, and
check disk groups (but not repair). Other operations, such as CREATE DISKGROUP, and ADD/DROP/RESIZE DISK,
requires SYSASM privilege and are not allowed with SYSOPER privilege. Note: the SYSOPER privilege does not
allow access to system views, e.g. v$asm_*.
ASM Privileged OS Groups Prior to Oracle Database 11g Release 2 there were only three privileged groups.
The oraInventory group is defined as the group that owns the oracle software installation. This group is often
called oinstall. The OSDBA group for the database, often called dba, owns the database files, and has all privileges
on the database. The OSOPER group for the database, called oper, has limited privileges to start, stop, and perform
limited management operations.
Users connected with the SYSDBA privilege cannot create or resize a disk group when connected with the SYSDBA privilege.
During installation, the ASMSNMP user with SYSDBA privileges is created for monitoring the Oracle ASM instance.
Users granted the SYSOPER privilege on the ASM instance, are allowed to startup, shutdown, mount, dismount, and check
disk groups (but not repair).
Other operations, such as CREATE DISKGROUP, and ADD/DROP/RESIZE DISK, requires SYSASM privilege and are not allowed
with SYSOPER privilege. Note: the SYSOPER privilege does not allow access to system views, e.g. v$asm_*.
On short : SYSASM = SYSDBA + SYSOPER priv
Group For OS Group Priv New on 11.2?
oraInventrory Group DB and ASM oinstall no
OSDBA DB dba SYSDBA no
OSOPER DB oper SYSOPER no
OSASM ASM asmadmin SYSASM yes
OSDBA ASM asmdba SYSDBA yes
OSOPER ASM asmoper SYSOPER yes
Group Sepration
User Privs
grid OSASM/asmadmin/SYSASM
OSDBA/asmdba/SYSDBA
OSOPER/asmoper/SYSOPER
disk owner : grid/asmadmin
oracle1 asmdba/SYSDBA
dba1 / SYSDBA for db1
oper1 / SYSOPERfor db1
oracle2 asmdba/SYSDBA
dba2 / SYSDBA for db2
oper2 / SYSOPERfor db2
#
SYSASM priv
- The owner of the Grid Infrastructure software installation must be a member of the OSASM group,
and automatically receives the SYSASM privilege.
- The SYSASM privilege is required to create, drop diskgroups,and to add and delete disks from disk groups.
- The SYSASM privilege is not granted to database owners.
- Database software owners must have the SYSDBA privilege in the ASM instance.
- The ASMSNMP user is created during install with the SYSDBA privilege
ASM and ACLs
- Access Control Lists are not enabled by default.
- ACLs do prevent a database owner from inadvertently deleting an ASM file in the same disk group belonging
to another database when properly configured.
- ASM Compatibility must be set to 11.2 or higher
- Job role separation must be implemented for ACls. The ACL uses the OS id and groups to control file access privileges
- ACLs can be managed with SQL or ASMCMD commands, or through Enterprise Manager
ACFS
- ACFS is a general purpose file system that can be used to hold any type of file.
But Grid binaries required to access ACFS cannot be stored in an ACFS file system.
- ACFS does not support Direct IO. For best performance, database files should be placed directly in ASM.
- ACFS can be used in clustered and non-clustered env
- With ACFS you can search a snapshot for older version of a file
- Copy-On-Write saves changed blocks to the ACFS snapshot
- You can backup and restore ACFS snapshots
ASM and 4K Sector Disk
- You must use 4 KB log files on 4 KB native mode disks
- Intellgent Data Properties ( Hot / cold regions ) will take place after next rebalance operation
- Changing Intellgent Data Properties will not trigger a rebalance operation
- Only 1 voting file can be stored per fail group in the same disk group :1
ASM versons dependencies 11.2 ( COMPATIBLE.ASM COMPATIBLE.RDBMS COMPATIBLE.ADVM )
Attribute parameter
Compatibility
COMPATIBLE.ASM determines the minimum software version for an ASM instance that can mount a disk group
This setting also affects the format of the data structures for the Oracle ASM metadata
on the disk.
COMPATIBLE.RDBMS determines the minimum COMPATIBLE parameter setting for any database instance that is
allowed to open this DG
COMPATIBLE.ASM will always be greater than COMPATIBLE.RDBMS
COMPATIBLE.ASM COMPATIBLE.RDBMS COMPATIBLE.ADVM ASM Instance Version COMPATIBLE Setting
for RDBMS Instance
10.1 10.1 n/a >= 10.1 >= 10.1
11.1 10.1 n/a >= 11.1 >= 10.1
11.2 11.1 11.2 >= 11.2 >= 11.1
11.2 11.2 11.2 >= 11.2 >= 11.2
Features enabled by disk group compatibility attribute settings
Disk Group Features Enabled COMPATIBLE.ASM COMPATIBLE.RDBMS COMPATIBLE.ADVM
Support for larger AU sizes (32 or 64 MB) >= 11.1 >= 11.1 n/a
Attributes are displayed in the V$ASM_ATTRIBUTE view >= 11.1 n/a n/a
Fast mirror resync >= 11.1 >= 11.1 n/a
Variable size extents >= 11.1 >= 11.1 n/a
Exadata storage >= 11.1.0.7 >= 11.1.0.7 n/a
Intelligent Data Placement >= 11.2 >= 11.2 n/a
OCR and voting files in a disk group >= 11.2 n/a n/a
Sector size set to nondefault value >= 11.2 >= 11.2 n/a
Oracle ASM SPFILE in a disk group i >= 11.2 n/a n/a
Oracle ASM File Access Control >= 11.2 >= 11.2 n/a
Volumes in disk groups >= 11.2 n/a >= 11.2
ASM_POWER_LIMIT value up to 1024 >= 11.2.0.2 n/a n/a
Encryption, replication, security, tagging on Linux systems >= 11.2.0.2 n/a >= 11.2.0.2
Encryption, replication, security, tagging on Windows systems >= 11.2.0.3 n/a >= 11.2.0.3
Read-write snapshots >= 11.2.0.3 n/a >= 11.2.0.3