Monitoring Memory Resizing Operations

Problem
You’ve implemented automatic memory management in your database and would like to monitor how the database is currently allocating the various dynamically tuned memory components.

Solution
Under an automatic memory management mode, you can view the current allocations of memory in
any instance by querying the V$MEMORY_DYNAMIC_COMPONENTS view. Querying this view provides vital information to help you tune the MEMORY_TARGET parameter. Here’s how you execute a query against this view:

SQL> select * from v$memory_target_advice order by memory_size;
MEMORY_SIZE MEMORY_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR VERSION
———– —————— ———— ——————- ———-
468 .75 43598 1.0061 0
624 1 43334 1 0
780 1.25 43334 1 0
936 1.5 43330 .9999 0
1092 1.75 43330 .9999 0
1248 2 43330 .9999 0
6 rows selected.

Your current memory allocation is shown by the row with the MEMORY_SIZE_FACTOR value of 1 (624 MB in our case). The MEMORY_SIZE_FACTOR column shows alternate sizes of the MEMORY_TARGET parameter as a multiple of the current MEMORY_TARGET parameter value. The ESTD_DB_TIME column shows the time Oracle estimates it will need to complete the current workload with a specific MEMORY_TARGET value. Thus, the query results show you how much faster the database can process its work by varying the value of the MEMORY_TARGET parameter.

How It Works
Use the V$MEMORY_TARGET_ADVICE view to get a quick idea about how optimal your MEMORY_TARGET allocation is. You need to run a query based on this view after a representative workload has been processed by the database, to get useful results. If the view reports that there are no gains to be had by increasing the MEMORY_TARGET setting, you don’t have to throw away precious system memory by allocating more memory to the database instance. Oftentimes, the query may report that potential performance, as indicated by the ESTD_DB_TIME column of the V$MEMORY_TARGET_ADVICE view, doesn’t decrease at a MEMORY_SIZE_FACTOR value that’s less than 1. You can safely reduce the setting of the MEMORY_TARGET parameter in such cases.

You can also use the **V$MEMORY_RESIZE_OPS** view to view how the instance resized various memory components over a past interval of 800 completed memory resizing operations. You’ll see that the database automatically increases or shrinks the values of the SGA_TARGET and PGA_AGGREGATE_TARGET parameters based on the workload it encounters. The following query shows how to use the V$MEMORY_RESIZE_OPS view to understand Oracle’s dynamic allocation of instance memory:

SQL> select component,oper_type,oper_mode,parameter, final_size,target_size
from v$memory_resize_ops
COMPONENT OPER_TYPE OPER_MODE PARAMETER FINAL_SIZE TARGET_SIZE
——————— ———– ——— ————— ———— ————
DEFAULT buffer cache GROW DEFERRED db_cache_size 180355072 180355072
shared pool GROW DEFERRED shared_pool_size 264241152 264241152
…
20 rows selected.

The OPER_TYPE column can take two values - GROW or SHRINK, depending on whether the database grows or shrinks individual memory components as the database workload fluctuates over time. It’s this ability to respond to these changes by automatically provisioning the necessary memory to the various memory components that makes this “automatic” memory management. The DBA will do well by monitoring this view over time, to ensure that automatic memory management works well for his or her databases.

Setting Minimum Values for Memory

Problem
You’re using automatic memory management, but you think that the database sometimes doesn’t
allocate enough memory for the PGA_AGGREGATE_TARGET component.

Solution
Although automatic memory management is supposed to do what it says—automate memory
allocation—there are times when you realize that Oracle isn’t allocating certain memory components
optimally. You can set a minimum value for any of the main Oracle memory components—buffer cache, shared pool, large pool, Java pool, and the PGA memory. For example, even after specifying automatic memory management, you can specify a target for the instance PGA with the following command, without having to restart the database:

SQL> alter system set pga_aggregate_target=1000m;

Oracle will, from this point forward, never decrease the PGA memory allocation to less than the
value you’ve set—this value implicitly sets a minimum value for the memory parameter. The database
will continue to automatically allocate memory to the various components of the SGA, but first it
subtracts the memory you’ve allocated explicitly to the PGA—

in this case, 1,000 MB, from the MEMORY_TARGET parameter’s value. What remains is what the database will allocate to the instance’s SGA.

How It Works
Ever since Oracle introduced the SGA_TARGET (to automate shared memory management) in Oracle
Database 10g and the MEMORY_TARGET parameter (to automate shared memory and PGA memory
management) in Oracle Database 11g, some DBAs have complained that these parameters sometimes
weren’t appropriately sizing some of the components of Oracle memory, such as the buffer cache.
There’s some evidence that under automatic memory management, the database could lag behind
an event that requires a sudden increase in the allocation to either one of the individual components of the SGA or to the PGA. For example, you may have a spurt of activity in the database that requires a quick adjustment to the shared pool component of memory—the database may get to the optimal
shared pool size allocation level only after it notices the events that require the higher memory. As a
result, the database may undergo a temporary performance hit. Several DBAs have, as a result, found
that automatic memory management will work fine, as long as you set a minimum value for, say, the
buffer cache or the PGA or both, by specifying explicit values for the SGA_TARGET and the
PGA_AGGREGATE_TARGET initialization parameters, instead of leaving them at their default value of zero.
The database will still use automatic memory management, but will now use the specific values you set for any of the memory components as minimum values. Having said this, in our experience, automatic memory management works as advertised most of the time; however, your mileage may vary, depending on any special time-based workload changes in a specific database. At times like this, it’s perfectly all right to set minimum values that represent your own understanding of your processing requirements, instead of blindly depending on Oracle’s automatic memory algorithms.

Managing Multiple Buffer Pools

Problem
You’re using automatic memory management, but have decided to allocate a minimum value for the
buffer pool component. You’d like to configure the buffer pool so it retains frequently accessed
segments, which may run the risk of being aged out of the buffer pool.

Solution
You can use multiple buffer pools instead of Oracle’s single default buffer pool, to ensure that frequently used segments stay cached in the buffer pool without being recycled out of the buffer pool. In order to implement multiple buffer pools in your database, you need to do two things: create two separate buffer pools—the KEEP buffer pool and the RECYCLE buffer pool. Once you do this, you must specify the BUFFER_POOL keyword in the STORAGE clause when you create a segment. For example, if you want a segment to be cached (or pinned) in the buffer pool, you must specify the KEEP buffer pool.

Note: Neither the KEEP nor the RECYCLE pool is part of the default BUFFER CACHE. Both of these pools are outside the default buffer cache.

Here’s how you create the two types of buffer pools.
In the SPFILE or the init.ora file, specify the two parameters and the sizes you want to assign to
each of the pools:
db_keep_cache_size=1000m
db_recycle_cache_size=100m

Here’s how you specify the default buffer pool for a segment:

SQL> alter table employees storage (buffer_pool=keep); Table altered.

How It Works
Configuring a KEEP buffer pool is an ideal solution in situations where your database contains tables that are referenced numerous times. You can store such frequently accessed segments in the KEEP buffer cache. By doing this, you not only isolate those segments to a specific part of the buffer pool, but also ensure that your physical I/O is minimized as well. How large the KEEP buffer pool ought to be depends on the total size of the objects you want to assign to the pool. You can get a rough idea by summing up the size of all candidate objects for this pool, or you can check the value of the DBA_TABLES view (BLOCKS column) to figure this out. While we’re on this topic, we’d like to point out the counterpart to the KEEP buffer pool—the RECYCLE buffer pool. Normally, the Oracle database uses a least recently used algorithm to decide which objects it should jettison from the buffer cache, when it needs more free space. If your database accesses very large objects once or so every day, you can keep these objects from occupying a big chunk of your buffer cache, and instead make those objects age right out of the buffer cache after they’ve been accessed.
You can configure such behavior by allowing candidate objects to use the RECYCLED buffer pool either when you create those objects, or even later on, by setting the appropriate storage parameters, as shown in the following examples (note that you must first set the DB_RECYCLE_CACHE_SIZE initialization parameter, as shown in the “Solution” section of this recipe.
You can execute the following query to figure out how many blocks for each segment are currently
in the buffer cache:

SQL> select o.object_name, count() number_of_blocks from dba_objects o, v$bh v where o.data_object_id = v.objd and o.owner !=’SYS’ group by o.object_name order by count();

When your database accesses large segments and retrieves data to process a query, it may
sometimes age out other segments from the buffer pool prematurely. If you need these prematurely
aged-out segments later on, it requires additional I/O. What exactly constitutes a large table or index
segment is subject to your interpretation. It’s probably safe to think of the size of the object you’re
concerned with by considering its size relative to the total memory you have allocated to the buffer
cache. Oracle figures that if a single segment takes up more than 10% of (non-sequential) physical reads, it’s a large segment, for the purpose of deciding if it needs to use the KEEP or RECYCLE buffer pools. So, a handful of such large segments can occupy a significant proportion of the buffer cache and hurt the performance of the database.

If you have other segments that the database accesses, let’s say, every other second, they won’t age
out of the buffer pool since they are constantly in use. However, there may be other segments that will be adversely affected by the few large segments the database has read into its buffer cache. It’s in such situations that your database can benefit most by devoting the RECYCLE pool for the large segments. Of course, if you want to absolutely, positively ensure that key segments never age out at all, then you can create the KEEP buffer cache and assign these objects to this pool.

Automating Memory Management

Problem

You want to automate memory management in your Oracle database. You have both OLTP and batch
jobs running in this database. You want to take advantage of the automatic memory management
feature built into Oracle Database 11g.

Solution

Here are the steps to implement automatic memory management in your database, if you’ve already set
either the SGA_TARGET or the PGA_AGGREGATE_TARGET parameters (or both). We assume that we are going to
allocate 2,000 MB to the MEMORY_MAX_TARGET parameter and 1,000 MB to the MEMORY_TARGET parameter.

1. Connect to the database with the SYSDBA privilege.
2. Assuming you’re using the SPFILE, first set a value for the MEMORY_MAX_TARGET
parameter:

SQL> alter system set memory_max_target=2G scope=spfile;
System altered.

You must specify the SCOPE parameter in the alter system command, because MEMORY_MAX_TARGET isn’t a dynamic parameter, which means you can’t change it on the fly while the instance is running.

3. Note that if you’ve started the instance with a traditional init.ora parameter
file instead of the SPFILE, you must add the following to your init.ora file:
memory_max_target = 2000M
memory_target = 1000M

4. Bounce the database.

5. Turn off the SGA_TARGET and the PGA_AGGREGATE_TARGET parameters by issuing
the following ALTER SYSTEM commands:

SQL> alter system set sga_target = 0;
SQL> alter system set pga_aggregate_target = 0;

6. Turn on automatic memory management by setting the MEMORY_TARGET parameter:

SQL> alter system set memory_target = 1000M;

From this point on, the database runs under the automatic memory management mode, with it shrinking and growing the individual allocations to the various components of Oracle memory according to the requirements of the ongoing workload. You can change the value of the MEMORY_TARGET parameter dynamically anytime, as long as you don’t exceed the value you set for the MEMORY_MAX_TARGET parameter.

■ Tip The term “target” in parameters such as memory_target and pga_memory_target means just that—Oracle will try to stay under the target level, but there’s no guarantee that it’ll never go beyond that. It may exceed the target allocation on occasion, if necessary.

You don’t have to set the SGA_TARGET and PGA_AGGREGATE_TARGET parameters to 0 in order to use automatic memory management. In Recipe 3-3, we show how to set minimum values for these parameters even when you choose to implement automatic memory management. That recipe assumes you’re implementing automatic memory management, but that for some reason, you need to specify your own minimum values for components such as the SGA and the PGA.

How It Works

In earlier releases of the Oracle database, DBAs used to set values for the various SGA components, or would specify values for the SGA and the PGA. Starting with the Oracle Database 11g release, Oracle enables you to completely automate the entire instance memory allocation, by just setting a single initialization parameter, MEMORY_TARGET, under what’s known as automatic memory management. In this Recipe, we show you how to set up the automatic memory management feature in your database.

If you’re creating a new Oracle database with the help of the Database Configuration Assistant (DBCA), you’re given a choice among automatic memory management, shared memory management, and manual memory management. Select the automatic memory management option, and specify the values for two automatic memory-related parameters: MEMORY_TARGET and MEMORY_MAX_TARGET. The first parameter sets the current value of the memory allocation to the database, and the second parameter sets the limit to which you can raise the first parameter if necessary.
Oracle’s memory structures consist of two distinct memory areas. The system global area (SGA) contains the data and control information and is shared by all server and background processes. The SGA holds the data blocks retrieved from disk by Oracle. The program global area (PGA) contains data and control information for a server process. Each server process is allocated its own chunk of the PGA. Managing Oracle’s memory allocation involves careful calibration of the needs of the database. Some database instances need more memory for certain components of the memory. For example, a data warehouse will need more PGA memory in order to perform huge sorts that are common in such an environment. Also, during the course of a day, the memory needs of the instance might vary; during
business hours, for example, the instance might be processing more online transaction processing (OLTP) work, whereas after business hours, it might be running huge batch jobs that involve data warehouse processing, jobs that typically need higher PGA allocations per each process.

In prior versions of the Oracle database, DBAs had to carefully decide the optimal allocation of memory to the individual components of the memory one allocated to the database. Technically, you can still manually set the values of the individual components of the SGA as well as set a value for the PGA, or partially automate the process by setting parameters such as SGA_TARGET and PGA_AGGREGATE_TARGET. Although Oracle still allows you to manually configure the various components of memory, automatic memory management is the recommended approach to managing Oracle’s memory allocation. Once you specify a certain amount of memory by setting the MEMORY_TARGET and MEMORY_MAX_TARGET parameters, Oracle automatically tunes the actual memory allocation, by
redistributing memory between the SGA and the PGA.

■ Tip When you create a database with the Database Configuration Assistant (DBCA), automatic memory management is the default.

Oracle Database 11g lets you automate all the memory allocations for an instance, including shared memory and the PGA memory, if you choose to implement automatic memory management by setting the MEMORY_TARGET and MEMORY_MAX_TARGET parameters. Under an automatic memory management regime, Oracle automatically tunes the total SGA size, the SGA component sizes, the instance PGA size, and the individual PGA size. This dynamic memory tuning by the Oracle instance optimizes database performance, as memory allocations are changed automatically by Oracle to match changing database workloads. Automatic memory management means that once you set the MEMORY_TARGET parameter, you can simply ignore the following parameters by not setting them at all:

• SGA_TARGET
• PGA_AGGREGATE_TARGET
• DB_CACHE_SIZE
• SHARED_POOL_SIZE
• LARGE_POOL_SIZE
• JAVA_POOL_SIZE\

If you’re moving from a system where you were using the SGA_TARGET and PGA_AGGREGATE_TARGET parameters, you can follow the procedures shown in the “Solution” section of this recipe to move to the newer automatic memory management mode of managing Oracle’s memory allocation. Note that while setting the MEMORY_TARGET parameter is mandatory for implementing automatic memory management, the MEMORY_MAX_TARGET parameter isn’t—if you don’t set this parameter, Oracle sets its value internally to that of the MEMORY_TARGET parameter. Also, the MEMORY_MAX_TARGET parameter acts as the upper bound for the MEMORY_TARGET parameter. Oracle has different minimum permissible settings for the MEMORY_TARGET
parameter, depending on the operating system. If you try to set this parameter below its minimum allowable value, the database will issue an error. Some of the memory components can’t shrink quickly and some components must have a minimum size for the database to function properly. Therefore, Oracle won’t let you set too low a value for the MEMORY_TARGET parameter. The following example shows this:

SQL> alter system set memory_target=360m scope=both;
alter system set memory_target=360m scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least
544M

SQL> alter system set memory_target=544m scope=both;
alter system set memory_target=544m scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least
624M

SQL> alter system set memory_target=624m scope=both;
System altered.
SQL>

You’ll notice that Oracle issued an error when we tried to set a very low value for the MEMORY_TARGET
parameter. Note that Oracle took iterations to decide to let you know the minimum allowable level for
the MEMORY_TARGET parameter.

How does one go about setting the value of the MEMORY_MAX_TARGET parameter? It’s simple—you just pick a value that’s high enough to accommodate not only the current workloads, but also the future needs of the database. Since the MEMORY_TARGET parameter is dynamic, you can alter it on the fly and if necessary, re-allocate memory among multiple instances running on a server. Just be sure that you set the value of the MEMORY_MAX_TARGET parameter to a size that’s at least equal to the combined value of the present settings of the SGA_TARGET and the PGA_AGGREGATE_TARGET parameters (if you're migrating from the 10g release). Always make sure to check with your system administrator, so you don’t allocate too high an amount of memory for your Oracle instance, which could result in problems such as paging and swapping at the operating system level, which will affect not only your Oracle database, but also everything else that’s running on that server.

ASM Instance Dynamic Views((G)v$) List

 

To find the list of ASM related dynamic views present in ASM instance, we need to connect to ASM instance and query the v$fixed_table ASM instance dynamic view.

  1 [oracle@rac1 ~]$ ps -ef |grep -v grep|grep smon
  2 oracle    3054     1  0 May24 ?        00:00:06 asm_smon_+ASM1
  3 root      3090     1  4 May24 ?        00:59:49 /u01/app/12.1.0/grid/bin/osysmond.bin
  4 oracle    6687     1  0 07:04 ?        00:00:01 mdb_smon_-MGMTDB
  5 oracle    6804     1  0 07:04 ?        00:00:02 ora_smon_MyDB1
  6 [oracle@rac1 ~]$ . oraenv
  7 ORACLE_SID = [oracle] ? +ASM1
  8 The Oracle base has been set to /u01/app/oracle
  9 [oracle@rac1 ~]$ sqlplus / as sysasm
 10 
 11 SQL*Plus: Release 12.1.0.1.0 Production on Sun May 25 08:10:45 2014
 12 
 13 Copyright (c) 1982, 2013, Oracle.  All rights reserved.
 14 
 15 
 16 Connected to:
 17 Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
 18 With the Real Application Clusters and Automatic Storage Management options
 19 
 20 SQL> select * from v$fixed_table where name like '%ASM%' 
 21   2  /
 22 
 23 NAME                                OBJECT_ID         TYPE     TABLE_NUM     CON_ID
 24 ------------------------------         ----------         ----- ---------- ----------
 25 GV$ASM_TEMPLATE                    4294951861         VIEW         65537        0
 26 V$ASM_TEMPLATE                     4294951862         VIEW         65537        0
 27 GV$ASM_ALIAS                       4294951864         VIEW         65537        0
 28 V$ASM_ALIAS                        4294951865         VIEW         65537        0
 29 GV$ASM_FILE                        4294951867         VIEW         65537        0
 30 V$ASM_FILE                         4294951868         VIEW         65537        0
 31 GV$ASM_VOLUME                      4294952802         VIEW         65537        0
 32 V$ASM_VOLUME                       4294952803         VIEW         65537        0
 33 GV$ASM_FILESYSTEM                  4294952908         VIEW         65537        0
 34 V$ASM_FILESYSTEM                   4294952909         VIEW         65537        0
 35 GV$ASM_ACFSVOLUMES                 4294952902         VIEW         65537        0
 36 V$ASM_ACFSVOLUMES                  4294952903         VIEW         65537        0
 37 GV$ASM_ACFSSNAPSHOTS               4294953048         VIEW         65537        0
 38 V$ASM_ACFSSNAPSHOTS                4294953049         VIEW         65537        0
 39 GV$ASM_ACFSTAG                     4294953498         VIEW         65537        0
 40 V$ASM_ACFSTAG                      4294953499         VIEW         65537        0
 41 GV$ASM_ACFS_SECURITY_INFO          4294953224         VIEW         65537        0
 42 V$ASM_ACFS_SECURITY_INFO           4294953225         VIEW         65537        0
 43 GV$ASM_ACFS_ENCRYPTION_INFO        4294953227         VIEW         65537        0
 44 V$ASM_ACFS_ENCRYPTION_INFO         4294953228         VIEW         65537        0
 45 GV$ASM_ACFS_SEC_RULE               4294953510         VIEW         65537        0
 46 V$ASM_ACFS_SEC_RULE                4294953511         VIEW         65537        0
 47 GV$ASM_ACFS_SEC_REALM              4294953513         VIEW         65537        0
 48 V$ASM_ACFS_SEC_REALM               4294953514         VIEW         65537        0
 49 GV$ASM_ACFS_SEC_REALM_USER         4294953516         VIEW         65537        0
 50 V$ASM_ACFS_SEC_REALM_USER          4294953517         VIEW         65537        0
 51 GV$ASM_ACFS_SEC_REALM_GROUP        4294953519         VIEW         65537        0
 52 V$ASM_ACFS_SEC_REALM_GROUP         4294953520         VIEW         65537        0
 53 GV$ASM_ACFS_SEC_REALM_FILTER       4294953522         VIEW         65537        0
 54 V$ASM_ACFS_SEC_REALM_FILTER        4294953523         VIEW         65537        0
 55 GV$ASM_ACFS_SEC_RULESET            4294953525         VIEW         65537        0
 56 V$ASM_ACFS_SEC_RULESET             4294953526         VIEW         65537        0
 57 GV$ASM_ACFS_SEC_RULESET_RULE       4294953528         VIEW         65537        0
 58 V$ASM_ACFS_SEC_RULESET_RULE        4294953529         VIEW         65537        0
 59 GV$ASM_ACFS_SEC_CMDRULE            4294953531         VIEW         65537        0
 60 V$ASM_ACFS_SEC_CMDRULE             4294953532         VIEW         65537        0
 61 GV$ASM_ACFS_SEC_ADMIN              4294953534         VIEW         65537        0
 62 V$ASM_ACFS_SEC_ADMIN               4294953535         VIEW         65537        0
 63 GV$ASM_ACFSREPL                    4294953588         VIEW         65537        0
 64 V$ASM_ACFSREPL                     4294953589         VIEW         65537        0
 65 GV$ASM_ACFSREPLTAG                 4294953591         VIEW         65537        0
 66 V$ASM_ACFSREPLTAG                  4294953592         VIEW         65537        0
 67 GV$ASM_VOLUME_STAT                 4294952905         VIEW         65537        0
 68 V$ASM_VOLUME_STAT                  4294952906         VIEW         65537        0
 69 GV$ASM_CLIENT                      4294951872         VIEW         65537        0
 70 V$ASM_CLIENT                       4294951873         VIEW         65537        0
 71 GV$ASM_DISKGROUP                   4294951877         VIEW         65537        0
 72 V$ASM_DISKGROUP                    4294951878         VIEW         65537        0
 73 GV$ASM_DISKGROUP_STAT              4294952651         VIEW         65537        0
 74 V$ASM_DISKGROUP_STAT               4294952652         VIEW         65537        0
 75 GV$ASM_DISK                        4294951880         VIEW         65537        0
 76 V$ASM_DISK                         4294951881         VIEW         65537        0
 77 GV$ASM_DISK_STAT                   4294952653         VIEW         65537        0
 78 V$ASM_DISK_STAT                    4294952654         VIEW         65537        0
 79 GV$ASM_DISK_IOSTAT                 4294952225         VIEW         65537        0
 80 V$ASM_DISK_IOSTAT                  4294952226         VIEW         65537        0
 81 GV$ASM_OPERATION                   4294951967         VIEW         65537        0
 82 V$ASM_OPERATION                    4294951968         VIEW         65537        0
 83 GV$ASM_ATTRIBUTE                   4294952221         VIEW         65537        0
 84 V$ASM_ATTRIBUTE                    4294952222         VIEW         65537        0
 85 GV$ASM_USER                        4294952241         VIEW         65537        0
 86 V$ASM_USER                         4294952242         VIEW         65537        0
 87 GV$ASM_USERGROUP                   4294952235         VIEW         65537        0
 88 V$ASM_USERGROUP                    4294952236         VIEW         65537        0
 89 GV$ASM_USERGROUP_MEMBER            4294952238         VIEW         65537        0
 90 V$ASM_USERGROUP_MEMBER             4294952239         VIEW         65537        0
 91 GV$ASM_ESTIMATE                    4294952252         VIEW         65537        0
 92 V$ASM_ESTIMATE                     4294952253         VIEW         65537        0
 93 GV$ASM_AUDIT_CLEAN_EVENTS          4294952275         VIEW         65537        0
 94 V$ASM_AUDIT_CLEAN_EVENTS           4294952276         VIEW         65537        0
 95 GV$ASM_AUDIT_CLEANUP_JOBS          4294952278         VIEW         65537        0
 96 V$ASM_AUDIT_CLEANUP_JOBS           4294952279         VIEW         65537        0
 97 GV$ASM_AUDIT_CONFIG_PARAMS         4294952281         VIEW         65537        0
 98 V$ASM_AUDIT_CONFIG_PARAMS          4294952282         VIEW         65537        0
 99 GV$ASM_AUDIT_LAST_ARCH_TS          4294952284         VIEW         65537        0
100 V$ASM_AUDIT_LAST_ARCH_TS           4294952285         VIEW         65537        0
101 
102 76 rows selected.
103 
104