As downtime (planned and unplanned) trends lower and SLAs continue to increase, it is important to be able maximize online operations as much as possible. In this article, we will be looking at performing a storage upgrade or refresh online, which is possible if you are running on Oracle Automatic Storage Management (ASM).
In order to keep this simple, let’s assume that our database is running on one ASM disk group: DATA. That disk group is composed of one ASM disk: SPINNING. We’re going to create a new disk, FLASH, on our brand new, all-flash storage array. In the example below, you’ll see us migrate from SPINNING to FLASH with no downtime at all.
Oracle Automatic Storage Management(ASM) was introduced in release 10g. ASM is Oracle’s logical volume manager, it uses OMF (Oracle Managed Files) to name and locate the database files. It can use raw disks, filesystems, or files which can be made to look like disks as long as the device is raw.
ASM uses its own database instance to manage the disks. It has its own processes and pfile or spfile and uses ASM disk groups to manage disks as one logical unit. In some ways ASM makes things more complicated – like accessing the files, copying to different locations, and viewing the time stamps of the files. It’s considered good practice to create one disk group for data (DATA) and one for archive logs and fast recovery area(FRA) per ASM instance. One disk group gets created during the cluster install and configuration (OCR). For a larger production database it’s common for it to have its own DATA and FRA disk groups.
In the Oracle 10g release, Automatic Storage Management (ASM) was introduced, which provided a simplified way for DBAs to manage the storage of Oracle-related files. However, ASM did make maintenance of the files more complicated as the files could not be directly accessed using system commands. For the most part, this was not a problem, but it does hinder the use of another Oracle feature: transportable tablespaces.
