Pages

Sunday 25 December 2011

SINGLE CLIENT ACCESS NAME (SCAN) in 11gR2


By Sangamesh B Satihal, Oracle DBA

SCAN is a new feature of 11gR2 that provides a user or client to connect to the cluster(RAC database) using sinlge virtual hostname. This virtual hostname is called as SCAN and this will work as cluster alias for a database in the cluster. This SCAN needs to be resolved to minimun one IP address but oracle strongly recommends three IP addresses.

 In previous releases(10g and 11gR1), whenever user has to connect RAC database, he was supposed to connect using virtual IPs through VIP listener and each instance in a cluster had it's own virtual IP to connect to the database. But note that even we could connect RAC database using public IP also but our purpose of high availability will be lost if we use public IP. So if there are n number of instances, we had n number of VIPs and same should be used by a client in his TNS entry. It impies that when we add or remove a node or nodes from a cluster, then client has to update his tns enty in his tnsnames.ora file. In order to avoid this, Oracle introduced SCAN concept. By using which client can use only one host to connect to cluster database, independenet of how many instances are running on that cluster. One more advantage of SCAN is it  automatically provides both failover and load balancing of connects, where the new connection will be directed to the least busy instance in the cluster by default. Having a single name to access the cluster allows clients to use the EZConnect client and the simple JDBC thin URL to access any database running in the cluster, independently of which server(s) in the cluster the database is active.  RAC Instances register to SCAN listeners as remote listeners. Example of EZconnect method in oracle and JDBC connection is shown below.


EZconnet :sqlplus system/manager@testdb-scan:1521/testdb
( EZconnecxt format is CONNECT username/password@[//]host[:port][/service_name])

JDBC connect:  jdbc:oracle:thin:@testdb-scan:1521/testdb

Note : Since  EZconnect is used with SCAN, the SQLNET.ora file should include EZconnect as one of the naming methods, for example:

NAMES.DIRECTORY_PATH=(tnsnames,ezconnect,ldap)


How SCAN works


For clients connecting using Oracle SQL*Net 11g Release 2, three IP addresses will be received by the client by resolving the SCAN name through DNS. The client will then go through the list it receives from the DNS and try connecting through one of the IPs received. If the client receives an error, it will try the other addresses before
returning an error to the user or application. This is similar to how client connection failover works in previous releases when an address list is provided in the client connection string. When a SCAN Listener listening on a SCAN IP address receives a connection request, Because all services on the cluster are registered with the SCAN listener, the SCAN listener checks with VIP listener(local listener) and replies with the address of the local listener on the least-loaded node (Each scan listener keeps updated cluster load statistics) where the service is currently being offered to the client. Finally, the client establishes connection to the service through the listener on the node where service is offered. All of these actions take place transparently to the client without any explicit configuration required in the client.




How we can configure SCAN

The SCAN is configured during the installation of Oracle Grid Infrastructure that is distributed with Oracle Database 11g Release2. Oracle Grid Infrastructure is a single Oracle Home that contains Oracle Clusterware and Oracle Automatic Storage Management. You must install Oracle Grid Infrastructure first in order to use Oracle RAC 11g Release 2. During the installation phase of the Oracle Grid Infrastructure installation, you will be prompted to provide a SCAN name. The default value for SCAN is cluster_name.GNS_sub_domain, or, cluster_name-scan.domain_name if GNS is not used. For example, in a cluster that does not use GNS, if your cluster name is salesRAC, and your domain is example.com, then the default SCAN address is salesRAC-scan.example.com:1521.

During the installation of Oracle Grid Infrastructure, several Oracle Clusterware resources are created for SCAN:

A SCAN VIP is created for each IP address that SCAN resolves to
A SCAN listener is created for each SCAN VIP
A dependency on the SCAN VIP is configured for the SCAN listener

SCAN VIPs function like node VIPs, except that SCAN VIPs can run on any node in the cluster. Also, if you have three SCAN VIPs but only two nodes in your cluster, you can have two SCAN VIPs running on the same server. Clients (users or applications) that connect using SCAN instead of the node VIPs do not have to update the list of VIP addresses in their local tnsnames.ora file when nodes are added to or removed from the cluster.


During Oracle Grid Infrastructure installation, SCAN listeners are created for as many IP addresses as there are addresses assigned to resolve to the SCAN. Oracle recommends that the SCAN resolves to three addresses, to provide high availability and scalability. If the SCAN resolves to three addresses, then there are three SCAN listeners created.

The addresses for the SCAN listeners resolve with either the domain name service (DNS), or within the cluster for the Grid Naming Service (GNS), using a round-robin method. SCAN listeners can run on any node in the cluster.

The database parameter LOCAL_LISTENER specifies the listening endpoint of the local database listener, and the database parameter REMOTE_LISTENER parameter identifies the SCAN listeners. The database registers with the local and SCAN listeners by using the connect description information contained in these parameters. Oracle Database 11g release 2 and later instances only register with SCAN listeners as remote listeners. Upgraded databases register with SCAN listeners as remote listeners, and also continue to register with all node listeners.

Starting with Oracle Database 11g release 2, the REMOTE_LISTENER parameter is always set to the SCAN address. Do not set it to an Oracle Net alias that has a single address that uses SCAN for the host name (HOST=scan). For example, if SCAN for the cluster is myscan, and the GNS subdomain for the cluster is mycluster.example.com, then the REMOTE_LISTENER parameter has the following value:

myscan.mycluster.example.com:1521

IP Addresses required for RAC 11gr2 configuration are

A Public IP on each node
A Local VIP for each noe
A Privated IP for each node for Interconnect
SCAN IP for the cluster. At least one, recommended three.
A Public IP for GNS VIP

You can configure SCAN Name resolution using :

1. Define the SCAN in your corporate DNS (Domain Name Service)
2. Use the Grid Naming Service (GNS)


1. Define the SCAN in your corporate DNS (Domain Name Service)
Ih this method, hostname which is used for SCAN will be resolved to  3 IP addresses using a round-robin algorithm in DNS server. This will be taken care by system admin or network admin. Three IP addresses are recommended considering load balancing and high availability requirements regardless of the number of servers in the cluster. The IP addresses must be on the same
subnet as your public network in the cluster. The name must be 15 characters or less in length, not including the
domain, and must be resolvable without the domain suffix (for example: “sales1-scan’ must be resolvable as opposed
to “scan1-scan.example.com”). The IPs must not be assigned to a network interface (on the cluster), since Oracle
Clusterware will take care of it.

You can check the SCAN configuration in DNS using “nslookup”. If your DNS is set up to provide round-robin access to the IPs resolved by the SCAN entry, then run the “nslookup” command at least twice to see the round-robin algorithm work. The result should be that each time, the “nslookup” would return a set of 3 IPs in a different order.

testdb1-scan.example.com        IN A 133.21.69.194
                                                  IN A 133.21.69.193
                                                  IN A 133.21.69.192






2. Use the Grid Naming Service (GNS): GNS is a Grid naming service that services subdomain. This subdomain is a portion of the corporate DNS domain. The only requirement is that a GNS Sub domain must be made and the DNS must be configured so that each request for this Sub Domain will be delegated to the GNS Sub domain, so that GNS can handle the request. DNA administrator (Network admin) creates a subdomain and delegates the subdomain name resolution to GNS.

This DNS subdomain must be created before grid installation. GNS listens on any fixed IP address of the RAC node within the cluster for the resolution of the name for that subdomain. The GNS VIP address is the ip address of the server that will host the GNS. You need to make sure this one is available for use. This GNS is managed by a CRS agent.  GNS and GNS VIP run on any one node of the cluster and it listens on default port 53. If the node on which GNS was running fails, then Oracle clusterware fails GNS and along with the GNS VIP to another node in the cluster.

During GRID installation, the option "Configure GNS" is checked, as shown below, if we are using GNS. If the option "Configure GNS" is not checked, then DNS will be used for SCAN name resolution.






After installation you will find three listener processes running (separated on all cluster nodes).  For each SCAN listener there will be a dedicated network interface running with the same IP as configured in DNS:



Client Connection to database “TESTDB” using SCAN would use this tnsnames entry:

TESTDB =

 (DESCRIPTION=

 (ADDRESS=(PROTOCOL=tcp)(HOST=testdbrac-scan.sangam.de)(PORT=1521))

 (CONNECT_DATA=(SERVICE_NAME=TESTDB))

 )




The ”old fashioned” way, we can connect to db as below


TESTDB_old =

 (DESCRIPTION=

 (ADDRESS_LIST=

 (ADDRESS=(PROTOCOL=tcp)(HOST=testdbrac1-vip.sangam.de)(PORT=1521))

 (ADDRESS=(PROTOCOL=tcp)(HOST=testdbrac2-vip.sangam.de)(PORT=1521))

 )

 (CONNECT_DATA=(SERVICE_NAME=TESTDB))

 )


Connecting to a named instance:


TESTDB1 =

 (DESCRIPTION=

 (ADDRESS=(PROTOCOL=tcp)(HOST=rac-scan.sangam.de)(PORT=1521))

 (CONNECT_DATA=(SERVICE_NAME=TESTDB)

 (INSTANCE_NAME=TESTDB1))

 )



Tuesday 20 December 2011

About Semaphores



Semaphores are used to protect critical regions of code or data structures. Remember that each access of a critical piece of data such as a VFS inode describing a directory is made by kernel code running on behalf of a process. It would be very dangerous to allow one process to alter a critical data structure that is being used by another process. One way to achieve this would be to use a buzz lock around the critical piece of data that is being accessed, but this is a simplistic approach that would degrade system performance.

Instead Linux uses semaphores to allow just one process at a time to access critical regions of code and data; all other processes wishing to access this resource will be made to wait until it becomes free. The waiting processes are suspended, other processes in the system can continue to run as normal.

A Linux semaphore data structure contains the following information:

count
This field keeps track of the count of processes wishing to use this resource. A positive value means that the resource is available. A negative or zero value means that processes are waiting for it. An initial value of 1 means that one and only one process at a time can use this resource. When processes want this resource they decrement the count and when they have finished with this resource they increment the count,
waking
This is the count of processes waiting for this resource which is also the number of process waiting to be awakened when this resource becomes free,
wait queue
When processes are waiting for this resource they are put onto this wait queue,
lock
A buzz lock used when accessing the waking field.
Suppose the initial count for a semaphore is 1, the first process to come along will see that the count is positive and decrement it by 1, making it 0. The process now ``owns'' the critical piece of code or resource that is being protected by the semaphore. When the process leaves the critical region it increments the semphore's count. The most optimal case is where there are no other processes contending for ownership of the critical region. Linux has implemented semaphores to work efficiently for this, the most common case.

If another process wishes to enter the critical region whilst it is owned by a process it too will decrement the count. As the count is now negative (-1) the process cannot enter the critical region. Instead it must wait until the owning process exits it. Linux makes the waiting process sleep until the owning process wakes it on exiting the critical region. The waiting process adds itself to the semaphore's wait queue and sits in a loop checking the value of the waking field and calling the scheduler until waking is non-zero.

The owner of the critical region increments the semaphore's count and if it is less than or equal to zero then there are processes sleeping, waiting for this resource. In the optimal case the semaphore's count would have been returned to its initial value of 1 and no further work would be neccessary. The owning process increments the waking counter and wakes up the process sleeping on the semaphore's wait queue. When the waiting process wakes up, the waking counter is now 1 and it knows that it may now enter the critical region. It decrements the waking counter, returning it to a value of zero, and continues. All access to the waking field of semaphore are protected by a buzz lock using the semaphore's lock.

About swap space


By Sangamesh B Satihal, Oracle DBA

Linux divides its physical RAM (random access memory) into chucks of memory called pages. Swapping is the process whereby a page of memory is copied to the preconfigured space on the hard disk, called swap space, to free up that page of memory. The combined sizes of the physical memory and the swap space is the amount of virtual memory available.

Swapping is necessary for two important reasons. First, when the system requires more memory than is physically available, the kernel swaps out less used pages and gives memory to the current application (process) that needs the memory immediately. Second, a significant number of the pages used by an application during its startup phase may only be used for initialization and then never used again. The system can swap out those pages and free the memory for other applications or even for the disk cache.

However, swapping does have a downside. Compared to memory, disks are very slow. Memory speeds can be measured in nanoseconds, while disks are measured in milliseconds, so accessing the disk can be tens of thousands times slower than accessing physical memory. The more swapping that occurs, the slower your system will be. Sometimes excessive swapping or thrashing occurs where a page is swapped out and then very soon swapped in and then swapped out again and so on. In such situations the system is struggling to find free memory and keep applications running at the same time. In this case only adding more RAM will help.

Linux has two forms of swap space: the swap partition and the swap file. The swap partition is an independent section of the hard disk used solely for swapping; no other files can reside there. The swap file is a special file in the filesystem that resides amongst your system and data files.
To see what swap space you have, use the command swapon -s.

The output will look something like this:
Filename  Type       Size       Used Priority
/dev/sda5 partition  859436       0       -1


Each line lists a separate swap space being used by the system. Here, the 'Type' field indicates that this swap space is a partition rather than a file, and from 'Filename' we see that it is on the disk sda5. The 'Size' is listed in kilobytes, and the 'Used' field tells us how many kilobytes of swap space has been used (in this case none). 'Priority' tells Linux which swap space to use first. One great thing about the Linux swapping subsystem is that if you mount two (or more) swap spaces (preferably on two different devices) with the same priority, Linux will interleave its swapping activity between them, which can greatly increase swapping performance.











Saturday 17 December 2011

Oracle Database Architecture

In this article, I will try to explain Oracle Database Architecture. The general purpose of a database is to store and retrieve related information. First thing that strikes to our mind when we talk about database is table which contains the data in the form of rows and columns. In oracle database, this table is a  logical structure that is inside another  logical entity called tablespace, which is mapped to physical files and are called as datafiles.  So for any database we need a storage. 

In order to perform any operation in the database, like inserting data into a table, fetching data from a table, we need an area called memory. This memory exist in database server main(or primary) memory.  All these database activities are carried out by processes, threads in case of windows.  In general a process is defined as a “thread of control” or a mechanism in an operating system that can run a series of steps and these are jobs that work in the memory of the computers.  Oracle database uses memory structures and processes to manage and access the database. 

So any database structure involves three components which are
  • Memory structures
  • Processes structures and 
  • Storage structures

Oracle Database Architecture
In oracle, Memory and Background processes together called as Instance. Database is a set of physical files on disk created by  CREATE DATABASE statement. However, in common language Instance and Database together called Database. Above diagram depicts the simple architecture of a database.

Let us understand how both Instance and Database are structured.

Instance

Database files themselves are useless without the memory structures and processes to interact with the database. When a database is started on a database server, the Oracle software allocates a shared memory area called the System Global Area (SGA) and starts several Oracle background processes. On Windows, an Oracle background process is a thread of execution within a process.This combination of the SGA and the Oracle background processes is called an Oracle instance.  After starting an instance, the Oracle software associates the instance with a specific database by reading the controlfile. This is called mounting the database. The database is then ready to be opened, which makes it accessible to authorized users. Multiple instances can execute concurrently on the same computer, each accessing its own physical database.Server processes, and the process memory allocated in these processes, also exist in the instance. The instance continues to function when server processes terminate.

The basic memory structures associated with Oracle Database include

The System Global Area(SGA) :is a shared memory region that contains data and control information for one Oracle instance. Oracle allocates the SGA when an instance starts and deallocates it when the instance shuts down. Each instance has its own SGA. Note that Oracle uses shared memory for implementing the SGA, which needs to be visible to all database sessions. The total size can't exceed the SHMMAX kernel parameter set at OS level.the The SGA consists of several memory components, which are pools of memory used to satisfy a particular class of memory allocation requests. All SGA components except the redo log buffer allocate and deallocate space in units of contiguous memory called granules. Granule size is platform-specific and is determined by total SGA size.
 The SGA contains, among other things, the database buffer cache that is used to cache information read from the data files, a data dictionary cache used to cache metadata information, and a library cache that caches recently used SQL and PL/SQL statements.

The SGA includes the following data structures:
  • Database buffer cache: Caches blocks of data retrieved from the database 
  • Redo log buffer: Caches redo information (used for instance recovery) until it can be written to the physical redo log files stored on the disk
  • Shared pool: Caches various constructs that can be shared among users.It has two sub components namely data dictionary cache and Library cache. data dictionary cache is used to cache metadata information and a library cache caches recently used SQL and PL/SQL statements.
  • Large pool: Is an optional area that provides large memory allocations for certain large processes, such as Oracle backup and recovery operations, and I/O server processes
  • Java pool: Is used for all session-specific Java code and data within the Java Virtual Machine (JVM)
  • Streams pool: Is used by Oracle Streams


The Program Global Area : also known as the Private Global Area (PGA) is a nonshared memory region  that contains data and control information that is private to a particular oracle process. . The PGA is created by Oracle Database when an Oracle process is started. One PGA exists for each server process and background process. The collection of individual PGAs is the total instance PGA, or instance PGA. Database initialization parameters set the size of the instance PGA, not individual PGAs. The PGA is used to allocate memory for information such as sort space, variables, arrays, and cursor information that is private to each process.

User Global Area (UGA): The UGA is session memory, which is memory allocated for session variables, such as logon information, and other information required by a database session. Essentially, the UGA stores the session state. The UGA must be available to a database session for the life of the session. UGA cannot be stored in the PGA when using a shared server connection because the PGA is specific to a single process. Therefore, the UGA is stored in the SGA when using shared server connections, enabling any shared server process access to it. When using a dedicated server connection, the UGA is stored in the PGA 

Software code areas :Software code areas are portions of memory used to store code that is being run or can be run. Oracle Database code is stored in a software area that is typically at a different location from user programs—a more exclusive or protected location.  


A database instance contains or interacts with the following types of processes 

1. Client processes run the application or Oracle tool code. This also called as user process. 
2. Oracle processes run the Oracle database code. Oracle processes including the following subtypes: 
  • Background processes start with the database instance and perform maintenance tasks such as performing instance recovery, cleaning up processes, writing redo buffers to disk, and so on. 
The most common background processes are the following:
       System Monitor (SMON): Performs crash recovery when the instance is started following    a failure
       Process Monitor (PMON): Performs process cleanup when a user process fails
       Database Writer (DBWn): Writes modified blocks from the database buffer cache to the data files on the disk
       Checkpoint (CKPT): Updates all the data files and control files of the database to indicate the most recent checkpoint
        LogWriter (LGWR): Writes redo log entries to the disk
        Archiver (ARCn): Copies redo log files to the archival storage when a log switch occurs


  •      Server processes perform work based on a client request. For example, these processes parse SQL queries, place them in the shared pool, create and execute a query plan for each query, and read buffers from the database buffer cache or from disk. 
  •  Slave processes perform additional tasks for a background or server process. 

The process structure varies depending on the operating system and the choice of Oracle Database options. For example, the code for connected users can be configured for dedicated server or shared server connections. In a shared server architecture, each server process that runs database code can serve multiple client processes. 












Friday 16 December 2011

Migrating an Oracle database from non-ASM to ASM


 By Sangamesh B Satihal, Oracle DBA

We can configure an ASM using DBCA or manually. Once the ASM is configured on the server and diskgroup is created, any database that resides on that server can start using ASM for its data storage. We can achieve this by migrating all datafiles, controlfiles, redolog files, archive logs and, if required, parameter files to ASM.

Use the following steps to migrate an existing Oracle database from a local file system to ASM. These steps are applicable for both 10g and 11g releases.

1. In this example, we will use MYASMDB database to migrate from file system to ASM. Get the details of all files of the database MYASMDB as below. All of the files listed in this query will be relocated from the local file system to ASM:

#> . oraenv
ORACLE_SID = [oracle] ? MYASMDB
The Oracle base for ORACLE_HOME=/orasw/app/oracle/product/11_2_0_2 is /orasw/app/oracle
#= Testing Env =oracle@sangam /var/opt/oracle
#> sqlplus '/as sysdba'

SQL*Plus: Release 11.2.0.2.0 Production on Wed Dec 7 05:10:09 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> SQL> SELECT
  2      d.tablespace_name                     tablespace
  3    , d.file_name                           filename
  4    , d.bytes                               filesize
  5    , d.autoextensible                      autoextensible
  , d.increment_by * e.value              increment_by
  6    7    , d.maxbytes                            maxbytes
  8  FROM
  9      sys.dba_data_files d
 10    , v$datafile v
 11    , (SELECT value
 12       FROM v$parameter
 13       WHERE name = 'db_block_size') e
 14  WHERE
 15    (d.file_name = v.name)
 16  UNION
 17  SELECT
 18      d.tablespace_name                     tablespace
 19    , d.file_name                           filename
 20    , d.bytes                               filesize
 21    , d.autoextensible                      autoextensible
 22    , d.increment_by * e.value              increment_by
 23    , d.maxbytes                            maxbytes
 24  FROM
    sys.dba_temp_files d
 25   26    , (SELECT value
 27       FROM v$parameter
 28       WHERE name = 'db_block_size') e
 29  UNION
 30  SELECT
 31      '[ ONLINE REDO LOG ]'
 32    , a.member
 33    , b.bytes
 34    , null
 35    , TO_NUMBER(null)
  , TO_NUMBER(null)
 36   37  FROM
 38      v$logfile a
 39    , v$log b
 40  WHERE
 41      a.group# = b.group#
 42  UNION
 43  SELECT
 44      '[ CONTROL FILE    ]'
 45    , a.name
 46    , TO_NUMBER(null)
 47    , null
 48    , TO_NUMBER(null)
 49    , TO_NUMBER(null)
 50  FROM
 51      v$controlfile a
 52  ORDER BY 1,2
/ 53

Tablespace Name / File Class  Filename                                                               File Size Auto            Next             Max
----------------------------- ---------------------------------------------------------------- --------------- ---- --------------- ---------------
CISTS_01                      /oradata_01/MYASMDB/cists01.dbf                                 536,870,912 YES        8,388,608  34,359,721,984
SYSAUX                        /oradata_01/MYASMDB/SYSAUX.dbf                                  188,743,680 YES       10,485,760  34,359,721,984
SYSTEM                        /oradata_01/MYASMDB/system01.dbf                                501,219,328 YES       10,485,760  34,359,721,984
TEMP                          /oradata_01/MYASMDB/temp01.dbf                                   67,108,864 YES        8,388,608  34,359,721,984
TOOLS                         /oradata_01/MYASMDB/tools01.dbf                                  67,108,864 YES        8,388,608  34,359,721,984
UNDOTBS1                      /oradata_01/MYASMDB/UNDOTBS1.dbf                                379,584,512 YES            8,192  34,359,721,984
USERS                         /oradata_01/MYASMDB/user01.dbf                                  536,870,912 YES        8,388,608  34,359,721,984
XMLDBTS_01                    /oradata_01/MYASMDB/xmldbts01.dbf                               536,870,912 YES        8,388,608  34,359,721,984
[ CONTROL FILE    ]           /oradata_01/MYASMDB/control01.ctl
[ CONTROL FILE    ]           /oradata_01/MYASMDB/control02.ctl
[ CONTROL FILE    ]           /oradata_01/MYASMDB/control03.ctl
[ ONLINE REDO LOG ]           /oradata_01/MYASMDB/redo01.log                                   10,485,760
[ ONLINE REDO LOG ]           /oradata_01/MYASMDB/redo02.log                                
[ ONLINE REDO LOG ]           /oradata_01/MYASMDB/redo03.log                                   10,485,760
                                                                                             

14 rows selected.

2. With the target database open, edit the initialization parameter control_files and db_create_file_dest to point to the ASM disk group + DATA.  Also configure db_recovery_file_dest to point to the ASM disk group +DATA as below.

SQL> ALTER SYSTEM SET control_files='+DATA' scope=spfile;
ALTER SYSTEM SET control_files='+DATA' scope=spfile
*
ERROR at line 1:
ORA-32001: write to SPFILE requested but no SPFILE is in use

Since DB was brought up with pfile so we got above error. Let us create spfile and bring up the database with spfile as blow.

SQL> shut immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> create spfile from pfile;

File created.

SQL> startup;
ORACLE instance started.

Total System Global Area 1603887104 bytes
Fixed Size                  2158744 bytes
Variable Size             419434344 bytes
Database Buffers         1174405120 bytes
Redo Buffers                7888896 bytes
Database mounted.
Database opened.
SQL>
SQL> ALTER SYSTEM SET control_files='+DATA' scope=spfile;

System altered.

SQL> ALTER SYSTEM SET db_create_file_dest='+DATA' scope=spfile;

System altered.

SQL> ALTER SYSTEM SET db_recovery_file_dest='+DATA' scope=spfile;

System altered.

3. Startup the target database in NOMOUNT mode:

SQL> SHUTDOWN IMMEDIATE;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup nomount;
ORACLE instance started.

Total System Global Area 1603887104 bytes
Fixed Size                  2158744 bytes
Variable Size             436211560 bytes
Database Buffers         1157627904 bytes
Redo Buffers                7888896 bytes
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
#= Testing Env =oracle@sangam /var/opt/oracle

4. From an RMAN session, copy one of your controlfiles from the local file system to its new location in ASM. The new controlfile will be copied to the value specified in the initialization parameter control_files

#> rman target /

Recovery Manager: Release 11.2.0.2.0 - Production on Wed Dec 7 05:25:46 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: MYASMDB (not mounted)

RMAN> RESTORE CONTROLFILE FROM '/oradata_01/MYASMDB/control01.ctl';

Starting restore at 07-DEC-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1345 device type=DISK

channel ORA_DISK_1: copied control file copy
output file name=+DATA/MYASMDB/controlfile/current.502.769238817
Finished restore at 07-DEC-11

5. From an RMAN or SQL*Plus session, mount the database. This will mount the database using the controlfile stored in ASM

RMAN> ALTER DATABASE MOUNT;

database mounted
released channel: ORA_DISK_1

6. From an RMAN session, copy the database files from the local file system to ASM

RMAN> BACKUP AS COPY DATABASE FORMAT '+DATA';

Starting backup at 07-DEC-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1345 device type=DISK
channel ORA_DISK_1: starting datafile copy
input datafile file number=00005 name=/oradata_01/MYASMDB/cists01.dbf
output file name=+DATA/MYASMDB/datafile/cists_01.503.769238853 tag=TAG20111207T052733 RECID=1 STAMP=769238942
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:35
channel ORA_DISK_1: starting datafile copy
input datafile file number=00006 name=/oradata_01/MYASMDB/user01.dbf
output file name=+DATA/MYASMDB/datafile/users.504.769238949 tag=TAG20111207T052733 RECID=2 STAMP=769239026
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:25
channel ORA_DISK_1: starting datafile copy
input datafile file number=00007 name=/oradata_01/MYASMDB/xmldbts01.dbf
output file name=+DATA/MYASMDB/datafile/xmldbts_01.505.769239035 tag=TAG20111207T052733 RECID=3 STAMP=769239111
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:25
channel ORA_DISK_1: starting datafile copy
input datafile file number=00001 name=/oradata_01/MYASMDB/system01.dbf
output file name=+DATA/MYASMDB/datafile/system.506.769239119 tag=TAG20111207T052733 RECID=4 STAMP=769239191
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:15
channel ORA_DISK_1: starting datafile copy
input datafile file number=00003 name=/oradata_01/MYASMDB/UNDOTBS1.dbf
output file name=+DATA/MYASMDB/datafile/undotbs1.507.769239195 tag=TAG20111207T052733 RECID=5 STAMP=769239239
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:55
channel ORA_DISK_1: starting datafile copy
input datafile file number=00002 name=/oradata_01/MYASMDB/SYSAUX.dbf
output file name=+DATA/MYASMDB/datafile/sysaux.508.769239249 tag=TAG20111207T052733 RECID=6 STAMP=769239273
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004 name=/oradata_01/MYASMDB/tools01.dbf
output file name=+DATA/MYASMDB/datafile/tools.509.769239275 tag=TAG20111207T052733 RECID=7 STAMP=769239286
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15
channel ORA_DISK_1: starting datafile copy
copying current control file
output file name=+DATA/MYASMDB/controlfile/backup.510.769239289 tag=TAG20111207T052733 RECID=8 STAMP=769239290
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 07-DEC-11
channel ORA_DISK_1: finished piece 1 at 07-DEC-11
piece handle=+DATA/MYASMDB/backupset/2011_12_07/nnsnf0_tag20111207t052733_0.511.769239291 tag=TAG20111207T052733 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 07-DEC-11



7. From an RMAN session, update the control file / data dictionary so that all database files point to the RMAN copy made in ASM

RMAN> SWITCH DATABASE TO COPY;

datafile 1 switched to datafile copy "+DATA/MYASMDB/datafile/system.506.769239119"
datafile 2 switched to datafile copy "+DATA/MYASMDB/datafile/sysaux.508.769239249"
datafile 3 switched to datafile copy "+DATA/MYASMDB/datafile/undotbs1.507.769239195"
datafile 4 switched to datafile copy "+DATA/MYASMDB/datafile/tools.509.769239275"
datafile 5 switched to datafile copy "+DATA/MYASMDB/datafile/cists_01.503.769238853"
datafile 6 switched to datafile copy "+DATA/MYASMDB/datafile/users.504.769238949"
datafile 7 switched to datafile copy "+DATA/MYASMDB/datafile/xmldbts_01.505.769239035"

RMAN> exit
Recovery Manager complete.
#= Testing Env =oracle@sangam /var/opt/oracle

8. From a SQL*Plus session, perform incomplete recovery and open the database using the RESETLOGS option

#> sqlplus '/as sysdba'

SQL*Plus: Release 11.2.0.2.0 Production on Wed Dec 7 05:35:40 2011

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
ORA-00279: change 717263 generated at 12/07/2011 05:24:55 needed for thread 1
ORA-00289: suggestion : +DATA
ORA-15173: entry 'ARCHIVELOG' does not exist in directory 'MYASMDB'
ORA-00280: change 717263 for thread 1 is in sequence #177


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> ALTER DATABASE OPEN RESETLOGS;

Database altered.

SQL> select name,status from v$database,v$instance;

NAME      STATUS
--------- ------------
MYASMDB  OPEN


9. From a SQL*Plus session, re-create any tempfiles that are still currently on the local file system to ASM. This is done by simply dropping the tempfiles from the local file system and re-creating them in ASM as below.
SQL> select tablespace_name, file_name, bytes from dba_temp_files;

TABLESPACE_NAME
------------------------------
FILE_NAME
--------------------------------------------------------------------------------
     BYTES
----------
TEMP
/oradata_01/MYASMDB/temp01.dbf
  67108864


SQL> alter database tempfile '/oradata_01/MYASMDB/temp01.dbf' drop including datafiles;

Database altered.

SQL> alter tablespace temp add tempfile size 512m;

Tablespace altered.

SQL> select tablespace_name, file_name, bytes from dba_temp_files;

TABLESPACE_NAME
------------------------------
FILE_NAME
--------------------------------------------------------------------------------
     BYTES
----------
TEMP
+DATA/MYASMDB/tempfile/temp.512.769239527
 536870912


10. From a SQL*Plus session, re-create any online redo logfiles that are still currently on the local file system to ASM. This is done by simply dropping the logfiles from the local file system and re-creating them in ASM as below.

Note : While dropping  redolog group, make sure that it is not current redolog  group.  If you do so, you will get error as
SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance MYASMDB (thread 1)
ORA-00312: online log 1 thread 1: '<file_name>'

It cab resolved by making that redogroup inactive by switching log file or by performing checkpoint on the database.

SQL> set linesize 500;
SQL> select a.group#, a.member, b.bytes from v$logfile a, v$log b where a.group# = b.group#;

    GROUP#
----------
MEMBER
--------------------------------------
     BYTES
----------
         1
/oradata_01/MYASMDB/redo01.log
  10485760

         2
/oradata_01/MYASMDB/redo02.log
  10485760

    GROUP#
----------
MEMBER

      BYTES
----------

         3
/oradata_01/MYASMDB/redo03.log
  10485760


SQL> set pagesize 500;
SQL> /

    GROUP#
----------
MEMBER

     BYTES
----------
         1
/oradata_01/MYASMDB/redo01.log
  10485760

         2
/oradata_01/MYASMDB/redo02.log
  10485760

         3
/oradata_01/MYASMDB/redo03.log
  10485760


SQL> select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 CURRENT
         2 UNUSED
         3 UNUSED

SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 CURRENT
         2 INACTIVE
         3 INACTIVE

SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> select group#,status from v$log;

    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 INACTIVE
         3 CURRENT

SQL> alter database drop logfile group 1;

Database altered.

SQL> alter database add logfile group 1 size 100m;

Database altered.

SQL> select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 UNUSED
         2 INACTIVE
         3 CURRENT

SQL> alter database drop logfile group 2;

Database altered.

SQL> alter database add logfile group 2 size 100m;

Database altered.

SQL> select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 UNUSED
         2 UNUSED
         3 CURRENT

SQL> alter system switch logfile;

System altered.

SQL> select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 CURRENT
         2 UNUSED
         3 ACTIVE

SQL>  alter system switch logfile;

System altered.

SQL> select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 ACTIVE
         2 CURRENT
         3 ACTIVE

SQL> alter system switch logfile;

System altered.

SQL>  select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 ACTIVE
         2 ACTIVE
         3 CURRENT

SQL> alter system switch logfile;
/
System altered.

SQL> /

System altered.

SQL> select group#, status from v$log;

    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 CURRENT
         3 INACTIVE

SQL> alter database drop logfile group 3;

Database altered.

SQL> alter database add logfile group 3 size 100m;

Database altered.

11. Verify that all online redo logfiles have been created in ASM

SQL> select a.group#, a.member, b.bytes from v$logfile a, v$log b where a.group# = b.group#;

    GROUP#
----------
MEMBER

     BYTES
----------
         1
+DATA/MYASMDB/onlinelog/group_1.513.769239709
 104857600

         2
+DATA/MYASMDB/onlinelog/group_2.515.769239751
 104857600

         3
+DATA/MYASMDB/onlinelog/group_3.517.769239855
 104857600

         1
+DATA/MYASMDB/onlinelog/group_1.514.769239709
 104857600

         2
+DATA/MYASMDB/onlinelog/group_2.516.769239751
 104857600

         3
+DATA/MYASMDB/onlinelog/group_3.518.769239855
 104857600


6 rows selected.

12. Perform the below steps to relocate the SPFILE from the local file system to an ASM disk group.

SQL> create pfile from spfile;

File created.

SQL> CREATE SPFILE='+DATA/MYASMDB/spfileMYASMDB.ora' from pfile;

File created.

SQL> SHUTDOWN IMMEDIATE;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.

Total System Global Area 1603887104 bytes
Fixed Size                  2158744 bytes
Variable Size             452988776 bytes
Database Buffers         1140850688 bytes
Redo Buffers                7888896 bytes
Database mounted.
Database opened.

13. Verify that all database files have been created in ASM

SQL>
SQL> SELECT
  2      d.tablespace_name                     tablespace
  3    , d.file_name                           filename
  4    , d.bytes                               filesize
  5    , d.autoextensible                      autoextensible
  6    , d.increment_by * e.value              increment_by
  7    , d.maxbytes                            maxbytes
  8  FROM
  9      sys.dba_data_files d
 10    , v$datafile v
 11    , (SELECT value
 12       FROM v$parameter
 13       WHERE name = 'db_block_size') e
 14  WHERE
 15    (d.file_name = v.name)
UNION
 16   17  SELECT
 18      d.tablespace_name                     tablespace
 19    , d.file_name                           filename
  , d.bytes                               filesize
 20   21    , d.autoextensible                      autoextensible
 22    , d.increment_by * e.value              increment_by
 23    , d.maxbytes                            maxbytes
 24  FROM
 25      sys.dba_temp_files d
 26    , (SELECT value
 27       FROM v$parameter
 28       WHERE name = 'db_block_size') e
 29  UNION
 30  SELECT
 31      '[ ONLINE REDO LOG ]'
 32    , a.member
 33    , b.bytes
 34    , null
 35    , TO_NUMBER(null)
 36    , TO_NUMBER(null)
 37  FROM
 38      v$logfile a
 39    , v$log b
 40  WHERE
 41      a.group# = b.group#
 42  UNION
SELECT
 43   44      '[ CONTROL FILE    ]'
 45    , a.name
 46    , TO_NUMBER(null)
 47    , null
 48    , TO_NUMBER(null)
 49    , TO_NUMBER(null)
 50  FROM
 51      v$controlfile a
 52  ORDER BY 1,2
 53  /

Tablespace Name / File Class  Filename                                                               File Size Auto            Next             Max
----------------------------- ---------------------------------------------------------------- --------------- ---- --------------- ---------------
CISTS_01                      +DATA/MYASMDB/datafile/cists_01.503.769238853                       536,870,912 YES        8,388,608  34,359,721,984
SYSAUX                        +DATA/MYASMDB/datafile/sysaux.508.769239249                         188,743,680 YES       10,485,760  34,359,721,984
SYSTEM                        +DATA/MYASMDB/datafile/system.506.769239119                         501,219,328 YES       10,485,760  34,359,721,984
TEMP                          +DATA/MYASMDB/tempfile/temp.512.769239527                           536,870,912 YES      262,144,000  34,359,721,984
TOOLS                         +DATA/MYASMDB/datafile/tools.509.769239275                           67,108,864 YES        8,388,608  34,359,721,984
UNDOTBS1                      +DATA/MYASMDB/datafile/undotbs1.507.769239195                       379,584,512 YES            8,192  34,359,721,984
USERS                         +DATA/MYASMDB/datafile/users.504.769238949                          536,870,912 YES        8,388,608  34,359,721,984
XMLDBTS_01                    +DATA/MYASMDB/datafile/xmldbts_01.505.769239035                     536,870,912 YES        8,388,608  34,359,721,984
[ CONTROL FILE    ]           +DATA/MYASMDB/controlfile/current.502.769238817
[ ONLINE REDO LOG ]           +DATA/MYASMDB/onlinelog/group_1.513.769239709                       104,857,600
[ ONLINE REDO LOG ]           +DATA/MYASMDB/onlinelog/group_1.514.769239709                       104,857,600
[ ONLINE REDO LOG ]           +DATA/MYASMDB/onlinelog/group_2.515.769239751                       104,857,600
[ ONLINE REDO LOG ]           +DATA/MYASMDB/onlinelog/group_2.516.769239751                       104,857,600
[ ONLINE REDO LOG ]           +DATA/MYASMDB/onlinelog/group_3.517.769239855                       104,857,600
[ ONLINE REDO LOG ]           +DATA/MYASMDB/onlinelog/group_3.518.769239855                       104,857,600
                                                                                             
15 rows selected.

14. At this point, the target database(MYASMDB) is open with all of its datafiles, controlfiles, online redo logfiles, tempfiles, and SPFILE stored in ASM. If we want to remove the database files that were stored on the local file system , this can be done from an RMAN session by executing below command. You could also then remove the old version of the controfile(s) that were stored on the local file system. All local file system files can be removed manually also.

RMAN> DELETE NOPROMPT FORCE COPY;