Automatic Storage Management

Overview & Best Practices

-Nitin Vengurlekar RAC/ASM Development

Automatic Storage Management

A new feature introduced in Oracle Database 10g Provides a vertical integration of the file system and volume manager for Oracle database files Spreads database files across all available storage for optimal performance and resource utilization Enables simple and non-intrusive resource allocation and provides automatic rebalancing Works in single-instance and RAC databases

ASM Installation Best Practices

Install ASM in a separate ORACLE_HOME than the database ORACLE_HOME

Provides higher availability and manageability allows independent upgrades of the database and ASM. de-installation of database software can be performed without impacting the ASM instance

ASM upgrade 10.1 -> 10.2

To upgrade ASM from 10.1 to 10.2, simply install the 10.2 binaries and startup ASM Theres no catalog or data dictionary to be upgraded. All data is on raw disk No internal structure change between 10.1 and 10.2

ASM Instance
Only one ASM instance per node

manages storage for all databases instances on the node

In RAC environments, each clustered node will have an ASM instance

ASM instances use the interconnect to synchronize metadata

Sample init.ora parameters

instance_type=asm #SGA sizing large_pool_size=20M shared_pool_size=80M processes=55 #Storage asm_diskstring='ORCL:*' asm_diskgroups='DATA','FLASH','DATA_SOX #RAC parameters +ASM1.instance_number=1 +ASM2.instance_number=2 cluster_database=true # trace files background_dump_dest=/opt/oracle/product/server32/10gr1/admin/+ASM/bdump core_dump_dest=/opt/oracle/product/server32/10gr1/admin/+ASM/cdump user_dump_dest=/opt/oracle/product/server32/10gr1/admin/+ASM/udump

Setting init.ora parameter

Use default values

Only processes parameter may need modification

Processes parameter setting is dependent on the number of databases that connect to ASM
processes= 25 + 15n, where n = # databases connected to ASM

ASM administration
Disks Diskgroups Files
0010 0010 0010 0010 0010 0010 0010 0010 0010 0010

Diskgroup Best Practices

Diskgroup Best Practices

Create two diskgroups. One for database area and another for flash recovery area

Note, no need to separate data from indexes

A Thats old school a

Create diskgroups using large number of similar type disks

same size characteristics same performance characteristics

Diskgroup Best Practices

The size of the Flash Recovery Area Diskgroup will depend on what is stored and how much is retained The FRA size should be driven by recovery time objectives

Diskgroup Best Practices

To minimize search overhead, perform all required mount operations in a single mount command If adding or removing multiple disks, make the change in a single rebalance operation.

This coalesces rebalance operations and reduces overhead

Diskgroup Best Practices

Use ASM External Redundancy when using high end storage arrays Use ASM Redundancy for low-end (modular) or JBOD storage array systems Use failure groups with ASM Redundancy,

determine what failure components your are protecting yourself from.

V$ view for v$asm_diskgroup

To see what diskgroups are discovered by ASM.
Select name, state, type from v$asm_diskgroup Select name, header_status, mode_status from v$asm_disk

This includes all mounted and dismounted diskgroups. To view FREE_MB for diskgroup query the ASM instance and not the database instance.

Disk Best Practices

Disk Best Practices

Make sure disks span multiple backend disk adapters Implement multiple access paths to the storage array using two or more HBAs or initiators Deploy multi-pathing software over these multiple HBAs to provide IO load-balancing and failover capabilities.

Disk Best Practices

If using hardware RAID, make sure LUN stripe size is as close to 1mb as possible Use OS disk labels when possible.

Prevents accidental user overwrites of disks Easier management of disks Make sure the disk (partition) starts at 1Mb a boundary, to insure proper I/O alignment.

Disk Best Practices

With 10.2, you can use block devices For example, use /dev/sda1 instead of /dev/raw/raw

V$ views for disks

Use v$asm_disk for information discovered ASM disks Select name, substr(path,1,21) path, header_status, mode_status from v$asm_disk;

ASMLib Best Practices

Use ASMLib on Linux Use the correct ASMLin version based on the OS kernel; e.g; uname a Use asm_diskstring=ORCL:*. Do not use the /dev/oracleasm/disks/* directly

I/O Stack Best Practices

Most I/O inconsistencies and weirdness is to due incompatiblity between

HBA->Switch/Port->Fibre adapter firmware

Check and update the firmware. Use AWR & iostat baselines to measure performance of database.

Some certification info

We do not certify multipathing tools ASM support in Serviceguard began with 11.17 of Serviceguard. There is a certification for HPUX 11.23 and SG 11.17 - PA RISC. ASM with Symantec-Veritas Volume Manager still in the works.

Database-ASM Best Practices

Database-ASM Best Practices

Use Oracle Management Files (OMF)

Easier Oracle file management Reduces user file management errors Enforcement of OFA standards Automatic deletion of ASM files when database files are dropped

To use OMF set :

db_recovery_file_dest='+FLASH db_create_file_dest=+DATA

Database-ASM Best Practices

Create CRS dependency between database instance and ASM instance

Ensures ASM instance starts up before starting database Allows ASM instance to cleanly shutdown database instance srvctl modify instance -d crm -i crm1 -s asm1

Recommended to use 10g Automatic Memory Management

Database-ASM Best Practices

The following recommendations for database SGA sizing can be used to calculate the SGA_TARGET value

large_pool Processes

= Add additional 600k = Add 16

Database-ASM Best Practices

To support ASM, the following database parameters must be updated:
Shared_pool Aggregate the values from the following queries to obtain current database storage sizes that is either already on ASM or will be stored in ASM. Then determine the redundancy type that is used (or will be used), and calculate the shared_pool, using the aggregated value as input.

select sum(bytes)/(1024*1024*1024) from v$datafile; select sum(bytes)/(1024*1024*1024) from v$logfile a, v$log b where a.group#=b.group#; select sum(bytes)/(1024*1024*1024) from v$tempfile where status='ONLINE';

For diskgroups using external redundancy = (Every 100Gb of space needs 1Mb of extra shared pool) + 2M For diskgroups using Normal redundancy: (Every 50Gb of space needs 1Mb of extra shared pool) + 4M. For diskgroups using High redundancy: needs 1Mb of extra shared pool) + 6M. (Every 33Gb of space

Database-ASM Best Practices

RMAN is the Recommended method for backup/recovery of database

RMAN is completely ASM diskgroup aware

Yes, Transportable Tablespaces work and are supported w/ ASM !! Yes! Database Cloning works and is supported w/ ASM. DataPump dumpsets can be created in diskgroups

Migration to ASM
Database must already be 10g database Use RMAN to migrate to ASM from raw or file system RMAN can be used to migrate entire databases or individual files

More information
See otn.oracle.com

ASM Technical Overview ASM Best Practices ASM-EMC Best Practices ASM-RMAN Dataguard Instantiation ASMLib Overview and installation