ORACLEAUTOMATICSTORAGEMANAGEMENT-Chapter 2 ASMInstance (4)

The ASM security section describes various security configuration topics related to ASM, such as configuring userids and groupids required by ASM, and permissions for ASM, such as SYSOPER, SYSDBA, and SYSASM, finally, there is the ORACLE password file used by ASM, orapwd.

If multiple UNIX Userids in an ASM instance use a user different from an RDBMS instance and an independent ASM_HOME, the ORACLE user of each RDBMS instance must be a member of the dba group of the ASM instance; ORACLE users of ASM do not have to be members of the DBA group of RDBMS instances. If you want to use different UNIX userids and use multiple ASM instances created by other UNIX userids to manage their own storage, you can create your own dba group for each database (different from the ASM dba group). For example, you can use DBA groups such as dba1 and dba2. If you want RDBMS instances to share the same disk group, all RDBMS instances need to access the disk group with the read/write permission. The ASM instance needs to access all disks with the read/write permission. For RDBMS instances, You can restrict the disks that can be accessed by the instance.

The ASM permission is 10 Gb in ORACLE, and the access to the ASM instance through SQLPLUS is the same as that to access the standard database instance. It can be accessed with the SYSDBA or SYSOPER permission. However, note that there is no data dictionary in the ASM instance. Permission authentication is completed through the operating system level or the ORACLE password file. Typically, SYSDBA permissions are granted through the operating system user group. In UNIX systems, dba groups are generally used. The default dba group has the SYSDBA permission to access all instances on the node, including the ASM instance. Use SYSDBA permissions to connect to ASM and have full management access permissions to manage the ephemeral System Disk groups. Note: In WINDOWS, ORACLE generally runs under the local system or administrator. The OSOPER and OSDBA groups are hard-coded and are associated with ora_scheduler and ORA_DBA respectively. Since oracle database 11g, a permission called SYSASM has become the main means to access the ASM instance. Most management commands on the ASM instance are no longer used with SYSDBA. SYSDBA is still backward compatible. If SYSDBA is used, the following information will be written into the ASM alert Log: Warning: Deprecated privilege SYSDBA for command 'startup'

The purpose of SYSASM permission is to separate ASM authentication from RDBMS authentication. The SYSASM permission has full control over the ASM instance. The user group that passes the OSASM authentication is similar to the SYSDBA permission, but the SYSDBA authentication is implemented through OSDBA. For ORACLE Database 11g ASM, replacing SYSDBA with SYSASM is the best practice. The following shows how to use SYSASM and configure a new user with the SYSASM role: [oracle11 @ racnode1 ~] $ Sqlplus "/as sysasm"
To create an ASMUSER, run the following command:
SQL> CREATE USER ASMUSER IDENTIFIED BY ASMUSER1;
SQL> GRANT SYSASM, SYSOPER TO ASMUSER;

Use ASMUSER to connect to the ASM instance:
[Oracle @ racnode1 ~] $ Sqlplus "ASMUSER/ASMUSER as sysasm"
SQL> select * from v $ pwfile_users;
USERNAME SYSDBA SYSOPER SYSASM
----------------------------------------------
SYS TRUE FALSE
ASMUSER FALSE TRUE

In oracle asm 10 Gb, the user's permission to connect to the ASM instance using SYSOPER is roughly the same as the permission to connect to the ASM instance using SYSDBA, except for the permission to query the v $ view. Use the following command to connect to the ASM instance using SYSOPER: [oracle11 @ racnode1 ~] $ Sqlplus "as sysoper"

Since oracle database 11g, asm sysoper has the same permissions as database sysoper. The following command is available for the SYSOPER User: STARTUP/SHUTDOWN
Alter diskgroup mount/DISMOUNT
Alter diskgroup online/OFFLINE DISK
ALTER DISKGROUP REBALANCE
ALTER DISKGROUP CHECK

All other commands such as create diskgroup, ADD/DROP/resize disk, and so on require SYSASM permissions, which cannot be used by SYSOPER users. All management commands, including STARTUP, SHUTDOWN, and ALTER/CREATE/drop diskgroup, are logged on to the ASM instance. For example, all the alter diskgroup commands are always recorded in the alert log after the instance issues the command. If necessary, all operations sent from the ASM instance through the sys user are recorded in the. aud file. To do this, you need to configure the following initialization parameter: audit_sys_operations = TRUE
_ Disable_instance_params_check = TRUE

Note: Unlike RDBMS instances, audit trail information cannot be stored in the AUD $ of the ASM instance because ASM does not have a database to store these tables. Therefore, the output is usually dump to The. aud file, which is usually stored in the default location -- $ ORACLE_HOME/rdbms/audit. AUDIT_FILE_DEST in init. ora controls the default location of the audit file. In WINDOWS, these logs are printed to the windows system log.

The ASM and orapwd ASM instances use the ORACLE password file for remote ASM access, much like RDBMS instances for remote database access. Note:

The RDBMS instance and the ASM instance are completely separated. Therefore, ASM has its own password file and is not shared with the RDBMS instance. To configure EM to remotely access ASM, the password file of ASM does not need to exist. If the ASM instance is configured by DBCA, The orapwd file is automatically created. If the ASM instance is manually configured, you must use the owapwd command to manually create the password file: [oracle11 @ racnode1 ~] $ Orapwd file = $ ORACLE_HOME/asm/orapw + ASM1 \
Password = oracle

The standard orapwd tool is used to manage the password file of the ASM instance. It only restricts the modification of the sys password. Note that in the RAC system, each ASM instance in the cluster must have the owapwd file. Use the V $ PWFILE_USERS view in the ASM instance to view the password file content: SQL> SELECT * FROM V $ PWFILE_USERS;
USERNAME SYSDB SYSOP SYSAS
---------------------------------------------
SYS TRUE FALSE

In oracle database 11g, you can use the same command as in RDBMS to modify the ASM password file. However, you can only update the local orapwd file.

With the emergence of ASM, the responsibility for volume management and storage management seems to be blurred. The ASM management definition role can have some variants that depend on the organization layer (management layer ). The following are some typical deployments (cases): An ASM administrator manages specific ASM instances. The ASM administrator can install software from Sysadmin (sa) ASM by RDBMS users. In this way, the management role of ASM can be enhanced. Manages enterprise database DBA or ORACLE software owner and ASM instance storage. The system administrator (SA) manages the OS LUNs (logical unit numbers), modifies the file owner Group of the device, and simultaneously associates the ASM disk with the logical volume manager of other hosts.

Regardless of how rights and responsibilities are divided, the following actions should be performed for the ASM storage: Determine the storage type of the ASM storage according to the application/database needs, such as SATA (Serial Advanced Technology Attachment) or FC (fiber Channel ). If you deploy a Hierarchical Storage, this is a very important issue. For example, a DATA disk may require a high-end FC disk, while a Flash disk only requires a SATA disk. Determine the amount of space required by the database. Determine the IOPS of database operations. Determine the database's requirements for backend storage Disks Based on IOPS requirements. This step must be completed by the storage administrator and system administrator system.

Create a LUNs from the storage array from the pre-allocated disk. These LUNs can be divided from RAID (RAID 10 or RAID 5) groups and mapped to suitable hosts. Pre-allocate disks at the host layer. The root user confirms on the OS that these LUNs can be recognized by the host. Adjust permissions and groups for these LUNs.

After the group and permissions are modified, ASM can find these disks. These disks can be added to an existing disk group or used to create a new disk group.

After creating the required disk group ASM to identify the disks provided by the storage array, determine how to allocate these disks to the disk group. Use an existing disk or create a new disk group.

The following ASM v $ view describes the data structure and structure of ASM: V $ ASM_ALIAS This view displays all system-and user-defined aliases.
There is one row for every alias present in every diskgroup mounted by
ASM instance. The RDBMS instance displays no rows in this view.

V $ ASM_ATTRIBUTE This Oracle Database 11 gview displays one row
For each ASM attribute defined. These attributes are listed when they are
Defined in CREATE DISKGROUPor ALTER DISKGROUPstatements.
DISK_REPAIR_TIMERis an example of an attribute.

V $ ASM_CLIENT This view displays one row for each RDBMS instance
That has an opened ASM diskgroup.

V $ ASM_DISK This view contains specifics about all disks discovered
The ASM instance, including mount status, disk state, and size. There is one
Row for every disk discovered by the ASM instance.

V $ ASM_DISK_IOSTAT This displays information about disk I/O statistics
For each ASM client. If this view is queried from the database instance, only
The rows for that instance are shown.

V $ ASM_DISK_STAT This view contains similar content as the V $ ASM _
DISK, category t v $ ASM_DISK_STATreads disk information from cache and
Thus performs no disk discovery. This view is primarily used for quick access
To the disk information without the overhead of disk discovery.

V $ ASM_DISKGROUPV $ ASM_DISKGROUPdisplays one row for every ASM
Diskgroup discovered by the ASM instance on the node.

V $ ASM_DISKGROUP_STAT This view contains all the similar view contents
As the V $ ASM_DISKGROUP, snapshot t that V $ ASM_DISK_STATreads disk
Information from the cache and thus performs no disk discovery. This view
Is primarily used for quick access to the diskgroup information without
Overhead of disk discovery.

V $ ASM_FILE The V $ ASM_FILEview displays information about ASM
Files. There is one row for every ASM file in every diskgroup mounted by
ASM instance. In a RDBMS instance, V $ ASM_FILEdisplays no rows.

V $ ASM_OPERATION This view describes the progress of an influx ASM
Rebalance operation. In a RDBMS instance, V $ ASM_OPERATIONdisplays
No rows.

V $ ASM_TEMPLATE This view contains information on user-and systemdefined templates.

V $ ASM_TEMPLATEdisplays one row for every template
Present in every diskgroup mounted by the ASM instance. In a RDBMS
Instance, V $ ASM_TEMPLATEdisplays one row for every template present
In every diskgroup mounted by the ASM instance with which the RDBMS
Instance communicates

The following view can be accessed in RDBMS and ASM instances. See P68

Summarize the management of ASM metadata by ASM instances. The ASM instance is very similar to the ORACLE instance, and there are also SGA and the vast majority of background processes. ASM can execute commands similar to RDBMS instances. The ASM instance is not attached to the database but attached to the disk group. ASM manages metadata so that the ASM data file can be used by the database. The ASM instance and database instance must be able to access all the ASM disks. When a file is opened or created, the ASM instance provides extent map to the RDBMS instance. An RDBMS instance reads and writes data directly to a disk based on extent map. The ASM instance is not in the I/0 path.