X

Maximum Availability Architecture – Oracle’s industry-leading set of database high availability capabilities

Database-Oriented Storage Management

Jim Williams
Product Manager

This is the second blog post in a series covering Oracle’s Automatic Storage Management. This post discusses a remarkable new way of managing storage with ASM features introduced in Oracle Database 12c Release 2, and available in the latest 18c release. This new mode of storage management is called Database-Oriented Storage Management. To fully understand the value of these features, it’s worth going back and consider the original intent with the invention of ASM. The ASM mission was to simplify the deployment and management of storage for Oracle databases. Before ASM, achieving optimal performance for mission critical databases meant hand crafting storage resources for the many tablespaces in typical a database. It was common to have dedicated storage resources and individual file systems for each individual database. For example, tablespaces belonging to one database might be placed on particular storage hardware and file system, while another database had its own dedicated storage resources and file system. This strategy sort of worked for smaller environments, but as systems grew, administrators had an enormous and ongoing challenge of upgrading and changing physical storage configurations and file systems to keep pace with changing needs. It was a game of whack-a-mole and much of this work had to be done offline—meaning administrators worked late nights and weekends to minimize application impact. ASM simplified these tasks by providing a few disk groups for consolidating all the customer’s databases. The magic ingredient in ASM is wide-striping database files across all available storage resources. Additionally, through ASM, additional storage could be dynamically added to disk groups, all the while the databases remained online. The result is that database administrators have fewer things to manage and worry by through consolidating databases into a single or small number of disk groups. 

This organizational model is described as Disk Group-Oriented Storage Management and is represented by the figure below. With this model all database files are stored in a shared disk group. Files for database DB1 (pictured below) are not treated any differently than files for database DB2 or DB3.

Disk Group-Oriented Storage Management

While disk group-oriented storage management greatly simplifies storage management, it limits the flexibility for customers wanting to consolidate databases having different requirements. To that end, we sometimes observed customers deploying many disk groups so they could separate databases with different requirements and priorities. For example, production databases might be isolated into separate disk groups from test and development databases having their own disk groups. While separating databases into distinct disk groups provides finer management granularity, it works against an objective of reducing management overhead. 

Flex Disk Groups

In response to how we observed customers using ASM, Oracle introduced the concept of Database-Oriented Storage Management in Oracle Database 12c Release 2. This management mode introduces a new disk group type called a Flex Disk Group. With flex disk groups, all files belonging to an individual database are collectively identified with a new ASM object called a File Group. For the purposes of this blog, we refer to both non-multitenant databases and multitenant PDBs as simply databases. A file group works with all database representations. 

A file group provides a way for referring to all files in a disk group belonging to database with a single name. Additionally, there is a separate file group for each disk group when a database has files in multiple disk groups. This allows databases to span disk groups without leading to a file group name conflict.

Typically, a file group will have the same name as the database. When a database is initially created, a file group with that name is also created. However, if a disk group already has an existing file group with the same name, then the existing file group is used for recording the file names associated with the database. 

The figure below shows this logical representation. In each of the two flex disk groups are file groups representing databases DB1, DB2, and DB3.

Database-Oriented Storage Management

One important benefit of flex disk groups is that different file groups within a flex disk group can have different redundancies. Furthermore, the redundancies are changeable as needs dictate. For example, a production database can use HIGH redundancyproviding three copies, while a test database, in the same disk group, can have MIRROR redundancy, providing two copies, or even UNPROTECTED having only one copy. If required, the redundancy of a database, i.e. the file group, can be altered dynamically using the alter diskgroup command. When a file group’s redundancy is changed, ASM invokes an operation similar to an ASM rebalance operation causing the redundancy change in storage.

Quota Groups

From a storage management perspective, a critical requirement for consolidating databases is storage quota management. Without the means of providing quota management, a single database can consume all the space in a disk group without consideration to other databases. To address this need, flex disk groups provide a new feature called quota groups. A quota group is a logical container specifying the amount of disk group space that one or more file groups are permitted to consume. As an example, in figure below, quota group A contain file groups DB1 and DB2, whereas quota group B contains file group DB3. The databases in quota group A are then limited by the specification of available space in that quota group.

Figure 3: Quota Space Management

Every flex disk group has a default quota group. If a file group i.e. database, is not explicitly assigned a quota group during creation, then the file group is assigned to the default quota group for that disk group. Furthermore, the sum of space represented by all the quota groups can exceed the total physical space available. Consequently, quota groups represent a logical capacity constraint of available space. 

Changing quota groups requires ASM administrative privileges. An ASM administrator can create a set of quota groups in which subsequent databases are allocated. Quota groups facilitate consolidating many databases into a single flex disk group by preventing any single database from consuming more than its fair share of storage and inhibiting the correct operation of the other databases. 

In conclusion, in Oracle Database 12c Release 2 Oracle introduced a new and powerful set of storage management features collectively referred to as database-oriented storage management. These features are available in all releases following, including Oracle database 18c. Database-oriented storage management improves database consolidation, but with the ease of management that DBAs have come to expect with ASM. For more information please refer to ASM’s Administration guide. For more information on all new ASM 18c features please review the 18c ASM New Features White Paper

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.