Thursday, 29 November 2012

Copy and Rename an Oracle Database

Copy and Rename an Oracle Database - (without export/import)


You may find it necessary to duplicate (clone) an Oracle database. One method is to use import/export. This method can work fine, but what if your database is too big? Another method is to make a copy of the current database and rename it. This month I will present an article that explains the steps necessary to copy and rename a database. This article will assume that the original database is called PROD and you want to create a TEST duplicate database.
1.) Copy production database files and init.ora

The first step is to locate and copy all database files to their new location. You can use the view V$DATAFILE in the PROD database to locate these files. Before running the query from V$DATAFILE, ensure that you are connected to the PROD database by selecting from V$DATABASE:
  SQL> select name from v$database;

  NAME
  ---------------------------------------
  PROD


  SQL> select name from v$datafile;

  NAME
  ---------------------------------------
  /u08/app/oradata/PROD/system01.dbf
  /u06/app/oradata/PROD/rbs01.dbf
  /u07/app/oradata/PROD/temp01.dbf
  /u10/app/oradata/PROD/userd01.dbf
  /u09/app/oradata/PROD/userx01.dbf
After recording these files, shutdown the PROD database and perform an operating system copy of all database files to another location and/or machine. In my example, I will copy all datafiles to a new location as shown in the following table:
Old LocationNew Location
/u08/app/oradata/PROD/system01.dbf /u08/app/oradata/TEST/system01.dbf
/u06/app/oradata/PROD/rbs01.dbf /u06/app/oradata/TEST/rbs01.dbf
/u07/app/oradata/PROD/temp01.dbf /u07/app/oradata/TEST/temp01.dbf
/u10/app/oradata/PROD/userd01.dbf /u10/app/oradata/TEST/userd01.dbf
/u09/app/oradata/PROD/userx01.dbf /u09/app/oradata/TEST/userx01.dbf
After copying all files to their new location, startup the PROD database.
From the production database, get a copy of the initPROD.ora file and copy it to initTEST.ora. In the initTEST.ora file, change the value of "db_name" from PROD to TEST. Keep in mind that you may also need to change:
  • audit_file_dest
  • background_dump_dest
  • control_files
  • core_dump_dest
  • log_archive_dest
  • user_dump_dest
If the TEST database is going to be on a different machine, copy the initTEST.ora file to that machine in the proper directory.
2.) Create the script that will re-create the controlfile

Using SVRMGR on the PROD database, create a script that will be able to re-create the controlfile for the database.
  PROD on testdb: svrmgrl
  SVRMGR> connect internal
  Connected.
  SVRMGR> alter database backup controlfile to trace;
  Statement processed.
The above statement will put a text copy of the controlfile in the USER_DUMP_DEST directory. You will need to search for the newest trace file in this directory. In UNIX you can use the "ls -lt" command. Once you find the correct trace file, rename it to cr_control.sql and edit it as follows:
  • Remove everything up to the "START NOMOUNT" statement and everything after the semicolon at the end of the "CREATE CONTROLFILE" statement.
  • Edit the line starting with "CREATE CONTROLFILE" and replace the word "REUSE" with the word "SET" right before the keyword DATABASE.
  • On the same line, modify the database name changing it from PROD to TEST.
  • On the same line, change the keyword NORESETLOGS to RESETLOGS.
Your script should now read:
Edited file cr_control.sql
STARTUP NOMOUNT
CREATE CONTROLFILE SET DATABASE "TEST" RESETLOGS NOARCHIVELOG
    MAXLOGFILES 32
    MAXLOGMEMBERS 5
    MAXDATAFILES 600
    MAXINSTANCES 10
    MAXLOGHISTORY 1000
LOGFILE
  GROUP 1 (
    '/u03/app/oradata/TEST/redo_g01a.log',
    '/u04/app/oradata/TEST/redo_g01b.log',
    '/u05/app/oradata/TEST/redo_g01c.log'
  ) SIZE 200K,
  GROUP 2 (
    '/u03/app/oradata/TEST/redo_g02a.log',
    '/u04/app/oradata/TEST/redo_g02b.log',
    '/u05/app/oradata/TEST/redo_g02c.log'
  ) SIZE 200K,
  GROUP 3 (
    '/u03/app/oradata/TEST/redo_g03a.log',
    '/u04/app/oradata/TEST/redo_g03b.log',
    '/u05/app/oradata/TEST/redo_g03c.log'
  ) SIZE 200K
DATAFILE
  '/u08/app/oradata/TEST/system01.dbf',
  '/u06/app/oradata/TEST/rbs01.dbf',
  '/u07/app/oradata/TEST/temp01.dbf',
  '/u10/app/oradata/TEST/userd01.dbf',
  '/u09/app/oradata/TEST/userx01.dbf'
;
If the TEST database is on a different machine move this file to that machine.
3.) Create the new controlfile for TEST

Make sure that your Oracle environment variable "ORACLE_SID" is set to TEST. (i.e. export ORACLE_SID=TEST). Now use SVRMGR and the CREATE CONTROLFILE script (cr_control.sql) to create your controlfile for TEST:
  TEST on testdb: svrmgrl
  SVRMGR> connect internal
  Connected to an idle instance.
  SVRMGR> @cr_control
  ORACLE instance started.
  Total System Global Area      32798752 bytes
  Fixed Size                       39816 bytes
  Variable Size                 22600856 bytes
  Database Buffers               9994240 bytes
  Redo Buffers                    163840 bytes
  Statement processed.
  SVRMGR>
NOTE: Stay logged into SVRMGR and proceed to the next step.
4.) Open the TEST database

Before opening the TEST database, you will need to perform incomplete recovery. After recovery you can open the database using the RESETLOGS option as show below:
  SVRMGR> alter database recover database until cancel using backup controlfile;
  SVRMGR> alter database recover cancel;
  Statement processed.
  SVRMGR> alter database open resetlogs;
  Statement processed.
  SVRMGR>
You can verify that the database was renamed to TEST by querying from V$DATABASE:
    SVRMGR> select name from v$database;
    NAME
    ---------
    TEST
    1 row selected.
    SVRMGR>

Tuesday, 27 November 2012

Custom Schemas Naming Convention in Oracle Applications.

Have we ever questioned ourselves, why custom schema names always start with ‘XX<some_name>‘? Before getting into the detail let’s check what happens if the custom schema name doesn’t start with ‘XX’.

If you don’t have a custom schema name starting with ‘XX’, be assured that this schema will be no longer available in our instance when we perform an UPGRADE. During upgrade Oracle apps will clear all unregistered schemas, which doesn’t start with ‘XX’.

Oracle had assured its customers that it would not touch any schemas that start with ‘XX’. This is the main reason why we find custom schema names starting with ‘XX’.

Oracle 11i forms crash in IE

Unable to open forms due to IE Error in 11i or Forms crashes with IE Error or Jinitiator Issue.This is due to jvm incompatibility used by other Application or tools.

Solution : o Go to program files java ==> jre1.6.0_07 (Or recent jre we can download from java.sun.com). Path : C:\Program Files\Java\jre1.6.0_07\bin\client
o Copy the jvm.dll file o Go to C:\Program Files\Oracle\JInitiator 1.3.1.21\bin\hotspot o Take the backup of current jvm.dll file o Copy the jvm.dll file, which you have copied from the above jre directory. o Close all the browsers and restart Now can access the forms now.

to disable some programs to connect to the database


CREATE OR REPLACE TRIGGER SYS.block_tools_from_prod
AFTER LOGON ON DATABASE
DECLARE
v_prog sys.v_$session.program%TYPE;
BEGIN 
SELECT program INTO v_prog FROM sys.v_$session
WHERE audsid = USERENV('SESSIONID') AND audsid != 0   ; 
-- Don't Check SYS Connections AND rownum = 1; -- Parallel processes will have the same AUDSID's

IF
  UPPER(v_prog) LIKE '%TOAD%' 
    OR UPPER(v_prog) LIKE '%T.O.A.D%' OR -- Toad
UPPER(v_prog) LIKE '%SQLNAV%' OR -- SQL Navigator
UPPER(v_prog) LIKE '%PLSQLDEV%' OR -- PLSQL Developer
UPPER(v_prog) LIKE '%BUSOBJ%' OR -- Business Objects
UPPER(v_prog) LIKE '%EXCEL%' -- MS-Excel plug-in   
THEN
RAISE_APPLICATION_ERROR(-20000, 'Development tools are not allowed on PROD DB!');
END IF;
END  ;
/
RMAN Mirroring Backups
It is possible to multiplex up to 4 copies per set at runtime:
run {
    set backup copies 2;
    backup full
           format '/orabackup1/rman/TARGDB/backup_db_%d_S_%s_P_%p_T_%t'
                , '/orabackup2/rman/TARGDB/backup_db_%d_S_%s_P_%p_T_%t'
           (database);
}
RMAN Incremental Backups
This example performs an incremental (online) backup of the Oracle database using RMAN. In this example, it is assumed that you want to take one full database backup once a week, and one incremental database backup every day. The backup cycle starts on Friday. A full backup is taken on Friday, and an incremental backup is then taken every day.
Also in this example, it is assumed that I will be using RMAN default configurations. One of the parameters I set is "CONFIGURE RETENTION POLICY TO REDUNDANCY 3". The retention policy of REDUNDANCY 3 applies only to full (not incremental) backups, so the combination of that policy and this backup schedule ensures that you can restore to any incremental backup time for the last 3 weeks.

run {
    # -----------------------------------------------------------
    # The following RMAN commands are run each Friday to start 
    # the backup cycle.
    # The steps are:
    #   - Backup database with incremental level 0.
    #   - Backup (and then delete) all archivelog files.
    # -----------------------------------------------------------
    backup
        incremental level 0
        filesperset 4
        (database);
    backup
        archivelog all
        delete input;
}
Now, let's look at what happens on those other days. The following commands can be run from Saturday through Thursday to take cumulative incremental backups. Notice that LEVEL 1 is specified with the BACKUP command. Also notice that the options LEVEL 1 CUMULATIVE indicate that only the blocks that have changed since the last level 0 backup will be backed up. If the CUMULATIVE option was not specified, then only the blocks that have changed since the last LEVEL 1 backup will be backed up. The advantage of a cumulative backup is that only one incremental backup ever needs to be applied during recovery.
run {
    backup
        incremental level 1 cumulative
        filesperset 4
        (database);
}
RMAN Online Backup - (using configured defaults)
This example performs an online (hot) backup of the Oracle database using RMAN. Before performing an online backup, the Oracle database must be in archive log mode. You can use the command "archive log list" to confirm that the database is in archive log mode:
SQL> archive log list

Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /u06/app/oradata/TARGDB/archive
Oldest online log sequence     16
Next log sequence to archive   17
Current log sequence           17
Oracle9i introduced the ability to perform an RMAN backup of the database along with all archived redo logs in one command. The details of what will happen from the command below have been already talked about. The only thing in this example is that all of the commands are put into one line.
% rman target /

RMAN> backup database plus archivelog delete input;

Starting backup at 23-DEC-04
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=17 devtype=DISK
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=16 recid=6 stamp=545696327
channel ORA_DISK_1: starting piece 1 at 23-DEC-04
channel ORA_DISK_1: finished piece 1 at 23-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_38_P_1_T_545696328 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archive log(s)
archive log filename=/u06/app/oradata/TARGDB/archive/arch_t1_s16.dbf recid=6 stamp=545696327
Finished backup at 23-DEC-04

Starting backup at 23-DEC-04
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u06/app/oradata/TARGDB/system01.dbf
input datafile fno=00002 name=/u06/app/oradata/TARGDB/undotbs01.dbf
input datafile fno=00011 name=/u06/app/oradata/TARGDB/perfstat01.dbf
input datafile fno=00007 name=/u06/app/oradata/TARGDB/example01.dbf
input datafile fno=00003 name=/u06/app/oradata/TARGDB/cwmlite01.dbf
input datafile fno=00004 name=/u06/app/oradata/TARGDB/drsys01.dbf
input datafile fno=00005 name=/u06/app/oradata/TARGDB/odm01.dbf
input datafile fno=00006 name=/u06/app/oradata/TARGDB/xdb01.dbf
input datafile fno=00008 name=/u06/app/oradata/TARGDB/indx01.dbf
input datafile fno=00009 name=/u06/app/oradata/TARGDB/tools01.dbf
input datafile fno=00010 name=/u06/app/oradata/TARGDB/users01.dbf
channel ORA_DISK_1: starting piece 1 at 23-DEC-04
channel ORA_DISK_1: finished piece 1 at 23-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_39_P_1_T_545696330 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:04:15
Finished backup at 23-DEC-04

Starting backup at 23-DEC-04
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=17 recid=7 stamp=545696585
channel ORA_DISK_1: starting piece 1 at 23-DEC-04
channel ORA_DISK_1: finished piece 1 at 23-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_40_P_1_T_545696585 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archive log(s)
archive log filename=/u06/app/oradata/TARGDB/archive/arch_t1_s17.dbf recid=7 stamp=545696585
Finished backup at 23-DEC-04

Starting Control File and SPFILE Autobackup at 23-DEC-04
piece handle=/orabackup/rman/TARGDB/c-2528050866-20041223-06 comment=NONE
Finished Control File and SPFILE Autobackup at 23-DEC-04
Observations
  • The key thing to mention here is that we needed to drop the keyword "all" that appeared after the "archivelog" token used in the example of backing up archived redo logs.
  • Notice that RMAN performs a log switch since we included the "... plus archivelog" clause.
  • After performing the log switch, RMAN first creates a backup set of any archived redo logs (including the on that was just created from the log switch). This is backup set "backup_db_TARGDB_S_38_P_1_T_545696328" in the example above.
  • After created the backup set for all archived redo logs, RMAN then creates a backup set for the actual backup of all Oracle database files. In the example above, this is done in backup set "backup_db_TARGDB_S_39_P_1_T_545696330".
  • During the backup of the Oracle database files, changes were being made to the data contained in those files. This information is being made to the online redo logs during that time. It is for this reason that RMAN performs another log switch and creates an archived redo log backup set. This is backup set "backup_db_TARGDB_S_40_P_1_T_545696585" in this example.
  • Finally, since the RMAN configuration parameter "CONTROLFILE AUTOBACKUP" was set to ON, RMAN creates a backup set for the control file (and SPFILE).
RMAN CHANNEL CONFIGURATION
Specifies the standard or AUXILIARY channel that you are configuring or clearing, as well as the device type (DISK or sbt) of the channel. You can either configure a "generic channel" or specify a channel by number, where "integer" is less than 255. Next let's look at setting defaults for channels. You can either set default settings for all channels with the configure channel device type command or you can set defaults for a specific channel using the configure channel n device type, where n is the channel you want to set for.
Now, let's take a look at the general syntax:
    CHANNEL integer DEVICE TYPE deviceSpecifier allocOperandList;

            integer              You can specify a channel by number. You may
                                 also exclude an integer, in which case you
                                 are specifying a general channel.
            deviceSpecifier      {DISK | SBT}
            allocOperandList     /* Specifies control options for the  */
                                 /* allocated channel                  */
                                 [PARMS         = 'channel_parms']
                                 [CONNECT       = (quoted string)]
                                 [FORMAT        = 'format_sring']
                                 [MAXPIECESIZE  = integer [K|M|G]]
                                 [RATE          = integer [K|M|G]]
                                 [MAXOPENFILES  = integer]
                                 [SEND          = 'command']
I generally use this parameter to configure the location (directory) and file format where RMAN will write disk backups to. Here are some of the substitution variables that can be used in the backup set file name: |
    %d      Database name
    %s      Backup set number
    %p      Backup piece number
    %t      4-byte timestamp
When automated channels are allocated, Oracle assigns default names to these channels. These default names depend on the type of default device used. The following table provides the default name format that will be used for each device:
Default Device TypeDefault Name FormatExample
DiskORA_DISK_nORA_DISK_1, ORA_DISK_2
TapeORA_SBT_TAPE_nORA_SBT_TAPE_1, ORA_SBT_TAPE_1



Now let's look at setting the number of channels to be allocated during an automated backup or recovery operation. This example will set the default level of parallelism for disk operations to two. Now, if an automated backup is started, two channels will be allocated to perform the backup in parallel:
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/orabackup1/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t';
RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/orabackup2/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t';
NOTE: When setting the default level of parallelism, you should set it to the number of disks or tape drives attached to which you will be backing up.

You can also control the size of a backup set piece or the entire backup itself. In the following example, I will limit channel 1 to create each individual backup piece at a maximum size of 1024MB. Take note that this command does not limit the overall size of the backup:
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/orabackup1/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m;

You can also set to limit all channels to have a limit of 1024MB by using:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m;

You can also limit the speed or rate of the backup channel:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m RATE 5m;

NOTE: If you configure a generic channel (that is, if you do not specify a channel number), then RMAN uses the generic settings for every parallelized channel except any channel number that you have explicitly configured. In other words, a generic channel setting specifies options for all channels not configured explicitly.


NOTE: The RATE parameter is intended to slow down a backup so that you can run it in the background with as little effect as possible on OLTP operations. The RATE parameter specifies units of bytes/second. Test to find a value that improves performance of your queries while still letting RMAN complete the backup in a reasonable amount of time. Note that RATE is not designed to increase backup throughput, but to decrease backup throughput so that more disk bandwidth is available for other database operations.


NOTE: The CONNECT parameter specifies a connect string to the database instance where RMAN should conduct the backup or restore operations. Use this parameter to spread the work of backup or restore operations across different instances in an Oracle Real Application Clusters configuration. If you do not specify this parameter, and if you did not specify the AUXILIARY option, then RMAN conducts all operations on the target database instance specified by the command-line parameter or the instance connected to when you issued the CONNECT command. Typically, you should not use the CONNECT parameter in conjunction with the AUXILIARY option.


NOTE: We can also assign specify an assigned name to channels that you allocate when using the allocate channel command. For example the following command will create a channel named c1:
RMAN> run {...
allocate channel c1 device type disk;
...}


NOTE: If AUXILIARY is specified, then this configuration is used only for channels allocated at the auxiliary instance. If no auxiliary device configuration is specified, and if RMAN needs to automatically allocate auxiliary channels, then RMAN uses the target database device configuration. It is not necessary to specify configuration information for auxiliary channels unless they require different parameters from the target channels.


NOTE: For generic channels of a specified device type, a new command erases previous settings for this device type. Assume that you run these commands:
CONFIGURE CHANNEL DEVICE TYPE sbt MAXPIECESIZE 1G;
CONFIGURE CHANNEL DEVICE TYPE sbt RATE 1700K;
The second command erases the MAXPIECESIZE setting of the first command.


NOTE: It is useful to understand how the CLEAR command works for this parameter. CLEAR Clears the specified channel. For example, CONFIGURE CHANNEL 1 DEVICE TYPE DISK CLEAR returns only channel 1 to its default, whereas CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR returns the generic disk channel to its default. Note that you cannot specify any other channel options (for example, PARMS) when you specify CLEAR.


Monday, 26 November 2012

RMAN Offline Backup - (without using configured defaults)
This example assumes that the target database is not configured with and will not be using any configured defaults (i.e. automatic channels). The following will perform an offline backup. Notice that you can use RMAN to shutdown and startup the database (which is required for performing an offline backup):
% rman target /

RMAN> shutdown
RMAN> startup mount
RMAN> run {
2>  allocate channel c1 device type disk format '/orabackup/rman/TARGDB/backup_db_%d_S_%s_P_%p_T_%t';
3>  allocate channel c2 device type disk format '/orabackup/rman/TARGDB/backup_db_%d_S_%s_P_%p_T_%t';
4>  setlimit channel c1 maxpiecesize 25m;
5>  set maxcorrupt for datafile 1 to 0;
6>  backup full
7>      skip inaccessible
8>      tag rman_backup_hot_full
9>      filesperset 4
10>     (database include current controlfile);
11> # backup current controlfile;
12> }

allocated channel: c1
channel c1: sid=13 devtype=DISK

allocated channel: c2
channel c2: sid=14 devtype=DISK


executing command: SET MAX CORRUPT

Starting backup at 22-DEC-04
channel c1: starting full datafile backupset
channel c1: specifying datafile(s) in backupset
input datafile fno=00011 name=/u06/app/oradata/TARGDB/perfstat01.dbf
input datafile fno=00007 name=/u06/app/oradata/TARGDB/example01.dbf
input datafile fno=00004 name=/u06/app/oradata/TARGDB/drsys01.dbf
input datafile fno=00006 name=/u06/app/oradata/TARGDB/xdb01.dbf
channel c1: starting piece 1 at 22-DEC-04
channel c2: starting full datafile backupset
channel c2: specifying datafile(s) in backupset
input datafile fno=00002 name=/u06/app/oradata/TARGDB/undotbs01.dbf
input datafile fno=00003 name=/u06/app/oradata/TARGDB/cwmlite01.dbf
input datafile fno=00005 name=/u06/app/oradata/TARGDB/odm01.dbf
input datafile fno=00008 name=/u06/app/oradata/TARGDB/indx01.dbf
channel c2: starting piece 1 at 22-DEC-04
channel c1: finished piece 1 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_18_P_1_T_545604600 comment=NONE
channel c1: starting piece 2 at 22-DEC-04
channel c1: finished piece 2 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_18_P_2_T_545604600 comment=NONE
channel c1: starting piece 3 at 22-DEC-04
channel c1: finished piece 3 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_18_P_3_T_545604600 comment=NONE
channel c1: starting piece 4 at 22-DEC-04
channel c1: finished piece 4 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_18_P_4_T_545604600 comment=NONE
channel c1: starting piece 5 at 22-DEC-04
channel c1: finished piece 5 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_18_P_5_T_545604600 comment=NONE
channel c1: starting piece 6 at 22-DEC-04
channel c2: finished piece 1 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_19_P_1_T_545604600 comment=NONE
channel c2: backup set complete, elapsed time: 00:02:11
channel c2: starting full datafile backupset
channel c2: specifying datafile(s) in backupset
including current controlfile in backupset
input datafile fno=00001 name=/u06/app/oradata/TARGDB/system01.dbf
input datafile fno=00009 name=/u06/app/oradata/TARGDB/tools01.dbf
input datafile fno=00010 name=/u06/app/oradata/TARGDB/users01.dbf
channel c2: starting piece 1 at 22-DEC-04
channel c1: finished piece 6 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_18_P_6_T_545604600 comment=NONE
channel c1: backup set complete, elapsed time: 00:02:14
channel c2: finished piece 1 at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/backup_db_TARGDB_S_20_P_1_T_545604731 comment=NONE
channel c2: backup set complete, elapsed time: 00:01:58
Finished backup at 22-DEC-04

Starting Control File and SPFILE Autobackup at 22-DEC-04
piece handle=/orabackup/rman/TARGDB/c-2528050866-20041222-04 comment=NONE
Finished Control File and SPFILE Autobackup at 22-DEC-04
released channel: c2
released channel: c1

RMAN> exit;

% ls -l /orabackup/rman/TARGDB/*
-rw-r-----   1 oracle   dba      26214400 Dec 22 20:50 backup_db_TARGDB_S_18_P_1_T_545604600
-rw-r-----   1 oracle   dba      26214400 Dec 22 20:50 backup_db_TARGDB_S_18_P_2_T_545604600
-rw-r-----   1 oracle   dba      26214400 Dec 22 20:51 backup_db_TARGDB_S_18_P_3_T_545604600
-rw-r-----   1 oracle   dba      26214400 Dec 22 20:51 backup_db_TARGDB_S_18_P_4_T_545604600
-rw-r-----   1 oracle   dba      26214400 Dec 22 20:51 backup_db_TARGDB_S_18_P_5_T_545604600
-rw-r-----   1 oracle   dba      19333120 Dec 22 20:52 backup_db_TARGDB_S_18_P_6_T_545604600
-rw-r-----   1 oracle   dba      343392256 Dec 22 20:52 backup_db_TARGDB_S_19_P_1_T_545604600
-rw-r-----   1 oracle   dba      331636736 Dec 22 20:54 backup_db_TARGDB_S_20_P_1_T_545604731
-rw-r-----   1 oracle   dba      7946240 Dec 22 20:54 c-2528050866-20041222-04
Observations
  • Notice first, that like all offline backups, we need to first shutdown and startup (mount) the database. This can all be done within the RMAN session.
  • Next, we have a run block, which will contain one or more statements contained within the braces and all will execute as one block. Oracle will not run any of the commands within the braces of the run block until all statements have been entered. The run block is completed with the closing brace, at which time Oracle will be compiled and executed.
  • Then we see the allocate channel statements. In this example, we have two channels allocated. Each time a you create a channel, Oracle will create one or more backup sets for that one channel. In most cases, each channel will create one backup set - but it is possible to have a channel create more than one backup set. In this example, I will show that my configuration will be the exception to the rule and it will create multiple backup sets for one channel. You show also notice that with each channel, I can define the format it will use for each backup piece.
  • Now that I created two channels, RMAN will automatically try to parallelize the backup stream amoung those channels.
  • When using multiple channels, you can configure and control the maximum piece size, read rate, rate, and maximum open files for each backup piece by using the channel name you assigned to it. In my example, I have two defined channels - c1 and c2.
    • I put no limits on the second channel c2.
    • You will notice that I did define limits on the first channel c1. In this example, I am asking RMAN to limit each backup piece to 25MB. This can be seen with the listing that I do after the backup has completed. Notice that each backup piece in backup set 18 is a maximum of 25MB in size. When writting to the backup piece, once it hit 25MB, RMAN will start another backup piece. In the listing you can see that all together, that channel c1 created 6 backup pieces.
  • Notice that with the backup command, I am including many options and that it spans several lines. One of the key options I would like to point out is filesperset 4. This is the exception to the rule "one channel will create one backup set" that I talked about earlier. With the filesperset option, I am telling RMAN that I only want a maximum of 4 Oracle datafiles to be backed in each backup set. Looking at the listing I performed (and the output of the RMAN run), you will see that RMAN created two backup sets for channel c2 to store a total of 7 Oracle datafiles:
    • Backup Set 19
      • /u06/app/oradata/TARGDB/undotbs01.dbf
      • /u06/app/oradata/TARGDB/cwmlite01.dbf
      • /u06/app/oradata/TARGDB/odm01.dbf
      • /u06/app/oradata/TARGDB/indx01.dbf
    • Backup Set 20
      • /u06/app/oradata/TARGDB/system01.dbf
      • /u06/app/oradata/TARGDB/tools01.dbf
      • /u06/app/oradata/TARGDB/users01.dbf
    Also note that the filesperset 4 option I provided in the backup command applies to all channels in the backup. As a note, notice that channel c1 creates one backup set with 4 Oracle datafiles.
    • Backup Set 18
      • /u06/app/oradata/TARGDB/perfstat01.dbf
      • /u06/app/oradata/TARGDB/example01.dbf
      • /u06/app/oradata/TARGDB/drsys01.dbf
      • /u06/app/oradata/TARGDB/xdb01.dbf

Sunday, 25 November 2012

Renaming / Moving Data Files, Control Files, and Online Redo Logs


Contents

  1. Overview
  2. Moving Datafiles while the Instance is Mounted
  3. Moving Datafiles while the Instance is Open
  4. Moving Online Redo Log Files
  5. Moving Control Files



Overview
Once a data file has been created in the database, it may be necessary to move it in order to better manage its size or I/O requirements. This article will provide several methods used by DBAs for moving datafiles, online redo log files and control files. In all of these methods, operating system commands are used to move the files while the Oracle commands serve primarily to reset the pointers to those files. There are two methods for moving / renaming physical database files within Oracle. The first is to shut the database down, move (or rename) the file(s) using O/S commands, and finally, use the ALTER DATABASE command to reset the pointers to those files within Oracle.
The second method can be done while the database is running and uses the ALTER TABLESPACE command. The tablespace will need to be taken offline during the time the file(s) are being moved or renamed. Once the files are moved (or renamed), use the ALTER TABLESPACE command to reset the pointers within Oracle and finally, bring the tablespace back online. This method only applies to datafiles whose tablespaces do not include SYSTEM, ROLLBACK or TEMPORARY segments.
Following is an example of how to manipulate datafiles in a tablespace using both the alter database method and the alter tablespace method. All examples will use an Oracle9i databse (9.2.0.5.0) running on Sun Solaris 2.9.



Moving Datafiles while the Instance is Mounted
Moving or renaming a datafile while the database is in the MOUNT stage requires the use of the ALTER DATABASE command. When using the ALTER DATABASE method to move datafiles, the datafile is moved after the instance is shut down. A summary of the steps involved follows:
  1. Shutdown the instance
  2. Use operating system commands to move or rename the files(s).
  3. Mount the database and use the ALTER DATABASE to rename the file within the database.
  4. Opening the Database

% sqlplus "/ as sysdba"

SQL> shutdown immediate

SQL> !mv /u05/app/oradata/ORA920/indx01.dbf /u06/app/oradata/ORA920/indx01.dbf

SQL> startup mount

SQL> alter database rename file '/u05/app/oradata/ORA920/indx01.dbf' to '/u06/app/oradata/ORA920/indx01.dbf';

    Do not disconnect after this step. Stay logged in 
    and proceed to open the database!

SQL> alter database open;

SQL> exit



Moving Datafiles while the Instance is Open
Moving or renaming a datafile while the database is in the 'OPEN' stage requires the use of the ALTER TABLESPACE command. When using the ALTER TABLESPACE method to move datafiles, the datafile is moved while the instance is running. A summary of the steps involved follows:
  1. Take the tablespace OFFLINE.
  2. Use operating system commands to move or rename the file(s).
  3. Use the ALTER TABLESPACE command to rename the file within the database.
  4. Bring the tablespace back ONLINE.

NOTE: This method can only be used for non-SYSTEM tablespaces. It also cannot be used for tablespaces that contain active ROLLBACK segments or TEMPORARY segments.


% sqlplus "/ as sysdba"

SQL> alter tablespace INDX offline;

SQL> !mv /u05/app/oradata/ORA920/indx01.dbf /u06/app/oradata/ORA920/indx01.dbf

SQL> alter tablespace INDX 
  2  rename datafile '/u05/app/oradata/ORA920/indx01.dbf' to '/u06/app/oradata/ORA920/indx01.dbf';

    Do not disconnect after this step. Stay logged in 
    and proceed to bring the tablespace back online!

SQL> alter tablespace INDX online;

SQL> exit



Moving Online Redo Log Files
Online redo log files may be moved while the database is shutdown. Once renamed (or moved) the DBA should use the ALTER DATABASE command to update the data dictionary. A summary of the steps involved follows:
  1. Shutdown the instance
  2. Use operating system commands to move the datafile.
  3. Mount the database and use ALTER DATABASE to rename the log file within the database.
  4. Opening the Database

% sqlplus "/ as sysdba"

SQL> shutdown immediate

SQL> !mv /u06/app/oradata/ORA920/redo_g03a.log /u03/app/oradata/ORA920/redo_g03a.log
SQL> !mv /u06/app/oradata/ORA920/redo_g03b.log /u04/app/oradata/ORA920/redo_g03b.log
SQL> !mv /u06/app/oradata/ORA920/redo_g03c.log /u05/app/oradata/ORA920/redo_g03c.log

SQL> startup mount

SQL> alter database rename file '/u06/app/oradata/ORA920/redo_g03a.log' to '/u03/app/oradata/ORA920/redo_g03a.log';
SQL> alter database rename file '/u06/app/oradata/ORA920/redo_g03b.log' to '/u04/app/oradata/ORA920/redo_g03b.log';
SQL> alter database rename file '/u06/app/oradata/ORA920/redo_g03c.log' to '/u05/app/oradata/ORA920/redo_g03c.log';

    Do not disconnect after this step. Stay logged in 
    and proceed to open the database!

SQL> alter database open;

SQL> exit



Moving Control Files
The following method can be used to move or rename a control file(s). A summary of the steps involved follows:
  1. Shutdown the Instance
  2. Move the Control File
  3. Edit the init<ORACLE_SID>.ora
  4. Startup the Instance

% sqlplus "/ as sysdba"

SQL> shutdown immediate

SQL> !mv /u06/app/oradata/ORA920/control01.ctl /u03/app/oradata/ORA920/control01.ctl
SQL> !mv /u06/app/oradata/ORA920/control02.ctl /u04/app/oradata/ORA920/control02.ctl
SQL> !mv /u06/app/oradata/ORA920/control03.ctl /u05/app/oradata/ORA920/control03.ctlWithin the init.ora file, there will be an entry for the 
"control_files" parameter. Edit this entry to reflect the change(s) 
made to the physical control file(s) moved in the previous example.

...
control_files   = (/u03/app/oradata/ORA920/control01.ctl,
                   /u04/app/oradata/ORA920/control02.ctl,
                   /u05/app/oradata/ORA920/control03.ctl)
...


SQL> startup open

SQL> exit
Resetting Initialization Parameters

After starting your Oracle database, you are confronted with the following warning:
SQL> startupORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1260420 bytes
Variable Size             180356220 bytes
Database Buffers          100663296 bytes
Redo Buffers                2932736 bytes
Database mounted.
Database opened.
 
After a bit of research, you determine that someone inadvertently set an Oracle initialization parameter that is marked as obsolete and/or deprecated. For the purpose of this example, let's assume that someone set "log_archive_start=true" in your Oracle10g database.
You now want to correct this action and remove the setting. No problem. If you are using a text-based initialization parameter file (init<ORACLE_SID>.ora), simply remove the entry from the text file and restart the database. Problem solved.
However, what if you are using an Oracle SPFILE? You think about this for a few seconds and decide to set the value of log_archive_start back to its default setting of FALSE in an effort to clear the setting. To your surprise, the warning still exists:
SQL> alter system set log_archive_start=false scope=spfile;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startupORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1260420 bytes
Variable Size             180356220 bytes
Database Buffers          100663296 bytes
Redo Buffers                2932736 bytes
Database mounted.
Database opened.
At this point, you are tempted to just open the binary SPFILE and remove the entry! I don't think I have to tell you this would be a very bad idea!
Well, the solution is simple - simply reset the initialization parameter. Take note that you must supply the SID= option to the ALTER SYSTEM command.
The following statement will reset the above initialization parameter (removing it from the SPFILE):
SQL> alter system reset log_archive_start scope=spfile sid='*';

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1260420 bytes
Variable Size             180356220 bytes
Database Buffers          100663296 bytes
Redo Buffers                2932736 bytes
Database mounted.
Database opened.
Say good-bye to your warning message!
Change Static Parameters Through the SPFILE

Oracle9i introduced the ability to dynamically set certain instance parameters thorugh the use of an SPFILE. Although, not every parameter can be set dynamically, for example, audit_trail. These are known as static parameters. Here is an example of what happens and the errors received when you try to change a static parameter within Oracle:
SQL> alter system set audit_trail=DB scope=both;
alter system set audit_trail=DB scope=both
               *
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified
The problem - You need to change a static parameter value in the SPFILE to be used at instance startup.
To apply the parameter change, SCOPE=BOTH applies the modification at the instance level and in the spfile used at startup. Use the value that applies the modification in the spfile only, provided that the spfile was used at startup:
SQL> alter system set audit_trail=DB scope=spfile;

System altered.
If no spfile was used at startup, you would get another error message such as:
SQL> alter system set audit_trail=DB scope=spfile;
alter system set audit_trail=DB scope=spfile
*
ERROR at line 1:
ORA-32001: write to SPFILE requested but no SPFILE specified at startup
According to the definition of a static parameter, it cannot be modified during instance life, but only in the init or spfile parameter file.
Dropping a database

Dropping a database is nothing more than deleting all physical database files. These files include all datafiles, control files and redo logs.
  • Locate all physical database files
      SELECT file_name FROM dba_data_files;
      SELECT name      FROM v$controlfile;
      SELECT member    FROM v$logfile;
  • Shutdown the database (abort)
      SVRMGRL> SHUTDOWN ABORT;
  • Remove all of the files from the server
    • UNIX - use the "rm" command
    • NT - use the "del" command
Resizing / Recreating Online Redo Log Files

One of the best ways I have found to resize or recreate online redo log files and keep the current sequence is to perform it online. In this example, we will resize all online redo logs from 100MB to 250MB while the database is running and use SQL*Plus to drop/recreate them in stages.
Before looking at the tasks involved to perform the resize, let's look at the current online redo log groups and their sizes:
SQL> SELECT a.group#, a.member, b.bytes
  2  FROM v$logfile a, v$log b WHERE a.group# = b.group#;

    GROUP# MEMBER                                          BYTES
---------- ---------------------------------------- ------------
         1 /u03/app/oradata/ORA920/redo_g01a.log     104,857,600
         1 /u04/app/oradata/ORA920/redo_g01b.log     104,857,600
         1 /u05/app/oradata/ORA920/redo_g01c.log     104,857,600
         2 /u03/app/oradata/ORA920/redo_g02a.log     104,857,600
         2 /u04/app/oradata/ORA920/redo_g02b.log     104,857,600
         2 /u05/app/oradata/ORA920/redo_g02c.log     104,857,600
         3 /u03/app/oradata/ORA920/redo_g03a.log     104,857,600
         3 /u04/app/oradata/ORA920/redo_g03b.log     104,857,600
         3 /u05/app/oradata/ORA920/redo_g03c.log     104,857,600

9 rows selected.
Now let's take a look at the steps involved to resize / recreate all online redo log groups:

  1. Make the last redo log CURRENT
    Force a log switch until the last redo log is marked "CURRENT" by issuing the following command:
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 CURRENT
             2 INACTIVE
             3 INACTIVE
    
    SQL> alter system switch logfile;
    
    SQL> alter system switch logfile;
    
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 INACTIVE
             2 INACTIVE
             3 CURRENT
  2. Drop first redo log
    After making the last online redo log file the CURRENT one, drop the first online redo log:
    SQL> alter database drop logfile group 1;
    
    Database altered.
      As a DBA, you should already be aware that if you are going to drop a logfile group, it cannot be the current logfile group. I have run into instances; however, where attempting to drop the logfile group resulted in the following error as a result of the logfile group having an active status:
    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 ORA920 (thread 1)
    ORA-00312: online log 1 thread 1: '<file_name>'
    Easy problem to resolve. Simply perform a checkpoint on the database:
    SQL> ALTER SYSTEM CHECKPOINT GLOBAL;
    
    System altered.
    
    SQL> ALTER DATABASE DROP LOGFILE GROUP 1;
    
    Database altered.
  3. Re-create dropped online redo log group
    Re-create the dropped redo log group with different size (if desired):
    SQL> alter database add logfile group 1 (
      2  '/u03/app/oradata/ORA920/redo_g01a.log',  
      3  '/u04/app/oradata/ORA920/redo_g01b.log',
      4  '/u05/app/oradata/ORA920/redo_g01c.log') size 250m reuse;
    
    Database altered.
  4. Force another log switch
    After re-creating the online redo log group, force a log switch. The online redo log group just created should become the "CURRENT" one:
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 UNUSED
             2 INACTIVE
             3 CURRENT
    
    SQL> alter system switch logfile;
    
    SQL> select group#, status from v$log;
    
        GROUP# STATUS
    ---------- ----------------
             1 CURRENT
             2 INACTIVE
             3 ACTIVE
  5. Loop back to Step 2 until all logs are rebuilt
    After re-creating an online redo log group, continue to re-create (or resize) all online redo log groups until all of them are rebuilt.

After rebuilding (resizing) all online redo log groups, here is a snapshot of all physical files:
SQL> SELECT a.group#, a.member, b.bytes
  2  FROM v$logfile a, v$log b WHERE a.group# = b.group#;

    GROUP# MEMBER                                          BYTES
---------- ---------------------------------------- ------------
         1 /u03/app/oradata/ORA920/redo_g01a.log     262,144,000
         1 /u04/app/oradata/ORA920/redo_g01b.log     262,144,000
         1 /u05/app/oradata/ORA920/redo_g01c.log     262,144,000
         2 /u03/app/oradata/ORA920/redo_g02a.log     262,144,000
         2 /u04/app/oradata/ORA920/redo_g02b.log     262,144,000
         2 /u05/app/oradata/ORA920/redo_g02c.log     262,144,000
         3 /u03/app/oradata/ORA920/redo_g03a.log     262,144,000
         3 /u04/app/oradata/ORA920/redo_g03b.log     262,144,000
         3 /u05/app/oradata/ORA920/redo_g03c.log     262,144,000

9 rows selected.