Home > Storage > PowerStore > Databases and Data Analytics > Dell PowerStore: Oracle Best Practices > Oracle Automatic Storage Management
Dell Technologies and Oracle recommend using Oracle Automatic Storage Management (ASM) as the preferred storage management solution for either a single-instance database or RAC database. ASM takes the place of the traditional Linux volume manager and file system. ASM takes over the management of disks and disk groups where database data reside. Disks are either raw LUNs or single partitioned LUNs. Both types of LUNs are stamped with a disk header that identifies them as ASM disks. Logical collections of ASM disks are known as ASM disk groups.
This section reviews general guidelines and additional considerations for an Oracle database.
ASM offers many advantages over the traditional Linux storage management solution such as Logical Volume Manager (LVM). The main benefits include:
When creating an Oracle ASM disk group, consider the following guidelines:
SQL> create tablespace DATATS datafile '+DATADG' size 10G autoextend on next 1024M maxsize unlimited;
SQL > ALTER DISKGROUP DATADG SET ATTRIBUTE '_rebalance_compact'='FALSE';
For Oracle pre-12c releases, this phase can only be disabled on the ASM-instance level which affects all ASM disk groups. Because PowerStore 3.0 uses all NVMe SSDs in the base enclosure, turning off the compact phase should not adversely impact performance. Because all applications are different and have their own data usage patterns, test this feature disabled before implementing the change in production.
For more information about ASM compact-rebalancing, see Oracle KB Doc ID 1902001.1 on Oracle Support.
The following table shows an example of how ASM disk groups can be organized:
Purpose | ASM disk group | LUN size | PowerStore volume group | Description |
OCR | GIDATA | 10 GB | N/A | Clusterware-related information such as the OCR and voting disks. Also used for Oracle Restart. |
Grid Infrastructure Management Repository | MGMT | 50 GB | mgmt_cg | Starting with 12cR2, a separate disk group is created for the GI Management Repository data. |
Test database (testdb) | DATADG | 200 GB | testdb_cg | Disk group that holds the database files, temporary table space, and online redo logs; contains system-related table spaces such as SYSTEM and UNDO. Contains only testdb data. |
FRADG | 100 GB | Disk group for database archive logs and backup data. Contains only testdb logs. | ||
Development database (devdb) | DATA2DG | 200 GB | devdb_cg | Disk group for database files, temporary table space, online redo logs; contains system-related table spaces such as SYSTEM and UNDO. Contains only devdb data. |
FRA2DG | 100 GB | Disk group for database archive logs and backup data. Contains only devdb logs. |
For performance reasons, it is common for a database to span across multiple LUNs to increase I/O parallelism to the storage devices. Group the LUNs of a database (Standalone or RAC) into a PowerStore volume group and enable the Apply write-order consistency to protect all volume group members option in PowerStore Manager. This grouping ensures data consistency when taking storage snapshots.
The PowerStore snapshot feature is a quick and space-efficient way to create a point-in-time snapshot of the entire database. For information about using PowerStore snapshots and thin clones to reduce database recovery time and create space-efficient copies of the database, see Snapshots and recoveries with Oracle and Thin clones.
In the following figure, all volumes belonging to database db1 are members of Volume Group ora-asm-db1. Within ASM, those volumes belong to two ASM disk groups: +DATA, and +FRA.
Volume groups defined with the write-order attribute selected, allow consistent snapshots to be taken of a database spanning multiple LUNs within the same appliance. With Oracle 12c and later versions, if PowerStore is used, there is no need to issue BEGIN and END BACKUP command options in Oracle. For more information about:
Note: Because a PowerStore volume group cannot span multiple appliances, do not use storage from multiple appliances for the same Standalone or RAC database. Storage snapshots that are taken on a multiple-LUN database without a volume group might not be usable to refresh or restore a database successfully.
Ensure that proper Linux user ownership, group ownership, and permissions are set correctly on ASM disks. The operating-system user that owns the ASM instance must own the LUNs and have read/write privilege to them. For example, if user grid with primary group oinstall is the owner of the ASM instance, grid:oinstall should be assigned to the LUNs. These settings must be persistent across host reboots, and across all nodes in a RAC cluster.
Persistent device ownership and permission can be managed through various software. The following section describes how to use ASMLib to accomplish this management task. ASMFD can also be used to manage device persistence, ownership, and permissions.
Note: If ASMLib or ASMFD are intended to manage ASM disks created from NVMe volumes, review the NVMe information available on Oracle Support.
Oracle ASMLib simplifies storage management and reduces kernel resource usage. It provides persistency for the device file name, ownership, permission, and reduces the number of open file handles that the database processes require. Using udev rules is not required when ASMLib is used.
When LUNs are initialized with ASMLib, special device files are created in the /dev/oracleasm/disks folder with proper ownership and permission automatically applied. When the system reboots, the ASMLib driver restarts and re-creates the device files. ASMLib consists of three packages:
Each Linux vendor maintains their own kernel driver RPM (oracleasm-kernel-version.arch.rpm). With Oracle Linux, the kernel driver is already included with Oracle Linux Unbreakable Enterprise Kernel, so do not install it. For more information about ASMLib and to download the software, see Oracle ASMLib.
The ownership of the ASMLib devices is defined in the /etc/sysconfig/oracleasm configuration file which is generated by running oracleasm configure -i. Update the configuration file if necessary to reflect the proper ownership, the disk scanning order, and the disk scanning exclude list.
Note: If Dell PowerPath is used, ORACLEASM_SCANORDER should be set to “emcpower”.
This configuration file indicates grid:oinstall for the ownership and it searches for multipath devices (dm) and excludes any single path devices (sd).
Note: The asterisk (*) cannot be used in the value for ORACLEASM_SCANORDER or ORACLEASM_SCANEXCLUDE.
Oracle requires partitioning the LUNs for ASMLib use. First, create a partition with parted, and use oracleasm to label the partition. ASMLib does not provide multipath capability and relies on native or third-party multipath software to provide the function. The following example shows creating an ASMLib device on a partition of a Linux Multipath device. The oracleasm command writes the ASMLib header to /dev/mapper/mpathap1 and generates the ASMLib device file in /dev/oracleasm/disks with ownership as indicated in the /etc/sysconfig/oracleasm file.
oracleasm createdisk DATA01 /dev/mapper/ora-asm-data-001
ASM instance parameter asm_diskstring tells ASM the location of the ASM devices. During the Grid Infrastructure installation, the parameter defaults to null and it should be updated to reflect the correct location of the device files.
The following table provides examples of values for asm_diskstring.
Device files | asm_diskstring setting |
Linux native multipath | asm_diskstring=’/dev/mapper/<dm-device-alias-intended-for-oracle-usage>*’ |
Dell PowerPath | asm_diskstring=’/dev/emcpowerc*’,’/dev/emcpowerh*’ |
Oracle ASMLib with block devices | asm_diskstring=’ORCL:*’ |
Oracle ASMLib with ASM disks residing on NAS NFS shares | asm_diskstring=’/<NFS share mntpt>/<path>/<asm-disk>*’ |
Oracle ASMFD | asm_diskstring=’AFD:*’ |
As the storage consumption grows over time, increasing and growing the existing storage capacity both in PowerStore and in the database might be necessary. PowerStore is ideal because it supports adding capacity online with minimal business interruptions. PowerStore has the flexibility to expand the current storage system with no interruption to the application. The following nondisruptive operations can be performed online in PowerStore Manager:
The following sections discuss the different ways to increase ASM storage capacity. Each method has advantages and disadvantages.
Storage capacity can be added to an ASM disk group by adding new LUNs to the disk group. The advantage of this method is that the process is relatively simple and safe because no changes are made to the existing LUNs.
The general process is as follows:
Because ASM automatically rebalances the data after a LUN is added, adding multiple LUNs in a single operation is recommended. This approach minimizes the amount of rebalancing work required. The following example shows the ALTER DISKGROUP ADD DISK Oracle SQL statement to add multiple devices to a disk group:
ALTER DISKGROUP DATADG ADD DISK 'AFD:DATADG_VOL1', 'AFD:DATADG_VOL2' REBALANCE POWER 10 NOWAIT;
# asmcmd lsdsk -gk -G datadg
# asmcmd lsdg –g datadg