Oracle 11g new features

Automatic memory management and variable automatic storage

management (ASM) extent size

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Solution configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Best practices and results . . . . . . . . . . . . . . . . . . . . . . . . . 4

Automatic memory management . . . . . . . . . . . . . . . . . . . . 4

Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Implementing . . . . . . . . . . . . . . . . . . . . . . . . . . 4

MEMORY_MAX_TARGET . . . . . . . . . . . . . . . . . . . 4

STATISTICS_LEVEL . . . . . . . . . . . . . . . . . . . . . . . 5

Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Variable ASM extent sizes . . . . . . . . . . . . . . . . . . . . . . . 7

Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Implementing . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

We value your feedback . . . . . . . . . . . . . . . . . . . . . . . . 12

For more information . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

HP technical references . . . . . . . . . . . . . . . . . . . . . . . . 13

HP solutions and training . . . . . . . . . . . . . . . . . . . . . 13

Overview
Oracle 11g has many new features and capabilities. This project evaluated a subset of the Oracle
11g new features that influence HP server and storage decisions: automatic memory management
and variable automatic storage management (ASM) extent sizes. This paper:

• Describes each feature

• Addresses the benefits of each feature

• Explains how to implement each feature

• Demonstrates monitoring techniques for each feature

2
Solution configuration
All testing for this project was performed on a two-node Oracle 11g RAC database using ASM on a
RHEL4 Update 4 x86_64 operating system. A 1 TB industry-standard online transaction processing
(OLTP) benchmark application was created in the Oracle 11g database.

3
Best practices and results
Automatic memory management
Prior to 11g, Oracle offered automatic management of the SGA and PGA regions, but each was
managed independently. Automatic memory management brings the management of the SGA and
PGA regions under a single point of control. With this new feature, the database administrator
selects the total amount of memory Oracle is permitted to utilize on a server, and Oracle dynamically
manages the distribution of that memory between the SGA and PGA regions.

Note
Memory utilization of the SGA and PGA regions is managed separately on each node in a RAC cluster. It is likely that the
current region sizes and the individual SGA component sizes will vary across nodes.

Benefits

• Continuously measures memory requirements

• Reallocates available memory without down time and without manual intervention

The benefits are particularly advantageous in an environment supporting heterogeneous workloads.

For example, in an environment hosting OLTP and DSS workloads during different times of day, PGA
region use will vary. With automatic memory management enabled, Oracle dynamically moves
memory between the SGA and PGA regions, optimizing the performance of both workloads.

Implementing

By default, the Database Configuration Assistant (DBCA) enables automatic memory management
when performing a basic installation. However, if you are upgrading from an earlier release
or modifying an existing 11g database configured with manual memory management, you must
explicitly set the MEMORY_TARGET parameter. MEMORY_TARGET is a dynamic parameter and can
be increased up to the value of MEMORY_MAX_TARGET without incurring downtime.

MEMORY_MAX_TARGET

MEMORY_MAX_TARGET is a new, static parameter that represents the maximum amount of

memory the database instance can use without being restarted. It will default to the value of
MEMORY_TARGET if not explicitly set. HP recommends setting MEMORY_MAX_TARGET to the
highest practical value given your server resources and other memory requirements.

Best practice
Set MEMORY_MAX_TARGET to the highest practical value given your server resources and other memory requirements.

SGA_TARGET and PGA_AGGREGATE_TARGET are the predecessors of MEMORY_TARGET. Prior to

the introduction of automatic memory management:

• SGA_TARGET represented the total amount of memory available to the components of the SGA.

• PGA_AGGREGATE_TARGET represented the target amount of memory shared by all processes

attached to an instance.

4
These parameters, when set using automatic memory management, serve as the minimum values
for SGA and PGA. By assigning these parameters a value greater than 0, you ensure that Oracle
will never resize the regions below that value. However, unless you have done the analysis of
your environment and have a valid reason for setting these parameters, it is best to omit them and
allow Oracle to dynamically allocate memory.

Best practice
Do not set SGA_TARGET and PGA_AGGREGATE_TARGET without careful analysis of your environment.

STATISTICS_LEVEL

STATISTICS_LEVEL is the parameter that influences how much information is gathered about your
system to enable Oracle to make decisions on memory sizing. There are three possible values
for this parameter: ALL, TYPICAL, and BASIC.

Setting STATISTICS_LEVEL to BASIC disables the collection of data required for automatic memory
management and will cause an ORA- error upon instance startup if automatic memory management
is enabled.

Note
An ORA-00824 error will be generated if STATISTICS_LEVEL=BASIC and MEMORY_TARGET > 0.

The only difference between TYPICAL and ALL is the amount of data gathered. TYPICAL provides
better performance and, in most cases, will gather sufficient data for Oracle to accurately assess the
memory needs.

Best practice
Set STATISTIC_LEVEL=TYPICAL for best performance.

Monitoring

Query the global view GV$MEMORY_RESIZE_OPS to monitor the dynamic memory adjustments
performed by Oracle when automatic memory management is enabled. This view continuously tracks
the last 800 completed resizing operations for each RAC instance. Figure 1 illustrates an example of
the resizing operations that occur on a single node during OLTP testing.

Note
In a single instance environment, query view V$MEMORY_RESIZE_OPS.

5
Figure 1. GV$MEMORY_RESIZE_OPS list of memory resizing operations

Each row in Figure 1 lists a resizing activity. The frequency of resizing operations shown here is
typical during the initial phase of a new workload. After just a few minutes of our testing, the
memory regions were properly sized and resizing operations were very infrequent. Every time the
PGA increased, the SGA, and in this case specifically the DEFAULT buffer cache, decreased. In other
words, memory was taken from the DEFAULT buffer cache component of the SGA and distributed
to the PGA, and yet the overall memory utilization never exceeded MEMORY_TARGET. Note that
all resizing operations occurred in increments of 64 MB. 64 MB is the granule size used in our
configuration and represents the unit of allocation in which SGA components are adjusted during
automatic memory management operations. Granule size is determined by the platform running
Oracle and the SGA size.1

Figure 2 illustrates output from the ipcs -m command when automatic memory management
is enabled.

Figure 2. 4K shared memory segment when automatic memory management is enabled

Note the 4 KB shared memory segment owned by Oracle in Figure 2. With automatic memory
management enabled, shared memory segments are stored in files in the /dev/shm file system. The
size of the files will either be 0 bytes or “granule sized” bytes. Oracle requires that the/dev/shm file
system be large enough to support the maximum possible SGA size.

1For further information on granule size, see Oracle® Database Administrator’s Guide 11g, Release 1 (11.1).

6
Note
ORA-00845 will be generated at startup if MEMORY_MAX_TARGET > /dev/shm free space.

Warning!
In a RAC environment on RHEL4 Update 4 x86_64, the /dev/shm file system is not cleaned up after instance shutdown
on node 1. If there is insufficient free space remaining in /dev/shm to accommodate the entire SGA, the instance will be
unable to restart. Oracle Bug 6820987 addresses this issue.

One workaround is to manually remove the files in /dev/shm prior to restarting the instance. Be
aware, however, that if there are multiple instances hosted on the same server (such as an ASM
instance), there may be active files in/dev/shm. The files to safely remove are easily identified
with the instance SID in the name.

Variable ASM extent sizes

An allocation unit is defined as the fundamental unit of allocation in a disk group.2 It is the physical
size in which Oracle stripes data across the LUNs of an ASM disk group. An extent is the logical
unit of measurement that Oracle uses to manage space at a database file level. A new feature in
Oracle 11g is the ability to dynamically vary the size of an extent.

Benefit

One benefit of variable sized extents is a smaller SGA. Oracle uses an ASM extent pointer array
stored within the SGA to track all extents associated with the database. For every extent managed,
regardless of its size, the ASM extent pointer array increases by 8 bytes. Therefore, the larger the
size of the extents, the fewer there are to manage and the smaller the ASM extent pointer array will
be. Table 1 illustrates the difference in SGA growth with and without variable sized extents. For
brevity, only three AU sizes are shown.

2Oracle® Database Storage Administrator’s Guide 11g, Release 1, page 1-6

7
Table 1. ASM extent pointer array size

File size AU size Without variable sized With variable sized extents
extents

100 GB

1 MB 800 KB 237 KB

16 MB 50 KB 50 KB

64 MB 12.5 KB 12.5 KB

1 TB

1 MB 8192 KB 418 KB

16 MB 512 KB 201 KB

64 MB 128 KB 128 KB

10 TB

1 MB 80 MB 1570 KB

16 MB 5 MB 370 KB

64 MB 1280 KB 296 KB

1 PB

1 MB 8192 MB 128 MB

16 MB 512 MB 8 MB

64 MB 128 MB 2 MB

10 PB

1 MB 81920 MB 1280 MB

16 MB 5120 MB 80 MB

64 MB 1280 MB 20 MB

Table 1 illustrates how the difference in SGA growth between variable sized extents and static extent
sizes does not vary significantly until the database reaches the petabyte range. In the last example
listed, a 10 PB data file with a 64 MB AU size realizes a 98% ((1280 MB - 20 MB) / 1280 MB)
savings in SGA growth by taking advantage of variable sized extents.

Best practice
Make use of variable sized extents for databases in the petabyte range.

Implementing

You cannot directly set the size of an extent. However, you can indirectly set the size of an extent by
selecting an AU size when creating an ASM disk group. The following SQL statement illustrates the
creation of a disk group using external redundancy with a 64 MB AU size.

CREATE DISKGROUP FTS EXTERNAL REDUNDANCY

DISK ’ORCL:FTS1’ SIZE 102398 M ,

’ORCL:FTS2’ SIZE 102398 M ,

’ORCL:FTS3’ SIZE 102398 M ,

’ORCL:FTS4’ SIZE 102398 M

ATTRIBUTE ’compatible.rdbms’ = ’11.1’,

’compatible.asm’ = ’11.1’,

’au_size’ = ’64M’;

8
Note
Set compatible.rdbms and compatible.asm to Oracle Release 11 or higher to enable the variable ASM extent size feature.

The extent size is dictated by the size of the AU, and there are only three possible sizes for an extent
in any single data file. Table 2 depicts the simple algorithm that determines the extent size.

Table 2. Extent growth algorithm

Number of extents Extent size

< 20,000 AU

AU x 8
20,000 and 40,000

AU x 64
40,000

If there are fewer than 20,000 extents in a single data file, the extent size is equal to the AU size.
Once the data file grows above 20,000 extents but fewer than 40,000 extents, the extent size
jumps to eight times the AU size. After 40,000 extents are created, the extent size increases to
and remains at 64 times the AU size.

Monitoring

The ASM extent pointer array and the variable ASM extent sizes can be monitored with two simple
SQL queries.

Using the following SQL, we will select data on the extent mapping for a single data file.

SELECT DISK_KFFXP, PXN_KFFXP, SIZE_KFFXP FROM X$KFFXP

WHERE GROUP_KFFXP=1 AND NUMBER_KFFXP=268;

Note
Select GROUP_KFFXP and NUMBER_KFFXP values that are appropriate to your environment.

9
Figure 3. Extent mapping in X$KFFXP

Note
See MetaLink Note 351117.1 for useful queries against X$KFFXP.

Figure 3 illustrates the output from the first query. The output reveals not only the even striping across
ASM disks, but also the AU size and extent size growth as the number of extents increases.

The first column represents the ASM disk number. Note how the extents are written in a round
robin fashion across four disks (LUNs) in our disk group. The second column tracks the sequential
numbering of each extent. The third column lists the AU size and verifies the extent growth.

The first 19,999 extents are 1 MB in size. According to the algorithm in Table 2, this is the AU size
of this disk group. At extent number 20,000, the extent size increased to 8 MB. At extent number
40,000 the extent size increased to 64 MB.

10
The current size of the ASM pointer array can be monitored with the following SQL:

SELECT INST_ID, BYTES FROM GV$SGASTAT

WHERE NAME = ’ASM extent pointer array’;

Note
In a single instance environment query, view V$SGASTAT and omit INST_ID from the query.

11
Conclusion
Oracle 11g offers many new features. This paper highlighted two of the new features:

• Automatic memory management

• Variable ASM extent sizes

It is important for you to fully understand any new feature before implementing it into a production
environment. The description of each feature, along with the benefits and implementation steps,
provides you the information needed to decide whether the new features are appropriate for your
environment.

We value your feedback

In order to develop technical materials that address your information needs, we need your feedback.
We appreciate your time and value your opinion. The following link will take you to a short survey
regarding the quality of this paper:

http://hpwebgen.com/Questions.aspx?id=12046&pass=41514

12
 For more information
HP technical references
HP solutions and training

• HP StorageWorks Customer Focused Testing

• http://www.hp.com/go/hpcft

• HP ORACLE Solutions

• http://www.hp.com/go/ORACLE

• HP data storage and HP StorageWorks products

• http://www.hp.com/go/storage

• HP Blade servers

• http://www.hp.com/go/blades

• HP ProLiant servers

• http://www.hp.com/go/proliant

© 2008 Hewlett-Packard Development Company, L.P. The information contained

herein is subject to change without notice. The only warranties for HP products
and services are set forth in the express warranty statements accompanying such
products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
4AA1-5662ENW, March 2008

13