Now lets examine our 11g AWR report:

WORKLOAD REPOSITORY report for

DB Name DB Id Instance Inst Num Startup Time Release RAC
———— ———– ———— ——– ————— ———– —
BEN11G 3769640271 ben11g 1 18-Jun-09 15:17 11.1.0.6.0 NO

Host Name Platform CPUs Cores Sockets Memory(GB)
—————- ——————————– —- —– ——- ———-
sandiego.localdo Linux IA (32-bit) 1 .99

Snap Id Snap Time Sessions Curs/Sess
——— ——————- ——– ———
Begin Snap: 24 04-Aug-09 12:55:42 37 1.2
End Snap: 30 07-Aug-09 18:11:18 36 1.0
Elapsed: 4,635.59 (mins)
DB Time: 1.47 (mins)

Cache Sizes Begin End
~~~~~~~~~~~ ———- ———-
Buffer Cache: 76M 76M Std Block Size: 8K
Shared Pool Size: 156M 156M Log Buffer: 5,988K

Scroll down to the following section of the AWR report:

Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ————— ————— ———- ———-
DB Time(s): 0.0 0.0 0.00 0.03
DB CPU(s): 0.0 0.0 0.00 0.03
Redo size: 62.9 5,874.9
Logical reads: 1.2 113.1
Block changes: 0.3 31.5
Physical reads: 0.0 2.0
Physical writes: 0.0 2.0
User calls: 0.0 1.0
Parses: 0.1 9.9
Hard parses: 0.0 0.1
W/A MB processed: 8,664.4 808,959.0
Logons: 0.0 0.3
Executes: 0.2 18.8
Rollbacks: 0.0 0.0
Transactions: 0.0

Under the heading for Load Profile generated by the AWR, you can examine redo size generated by second, per transaction, per execution or per system call. So in our example above, we had a grand total of 62.9K of redo per second. We can correlate this to the V$ data dictionary performance views with the following SQL*PLUS script that queries against the V$LOG and V$DATABASE performance views:

SELECT Start_Date,
Start_Time,
Num_Logs,
Round(Num_Logs * (Vl.Bytes / (1024 * 1024)),
2) AS Mbytes,
Vdb.NAME AS Dbname
FROM (SELECT To_Char(Vlh.First_Time,
‘YYYY-MM-DD’) AS Start_Date,
To_Char(Vlh.First_Time,
‘HH24′) || ‘:00′ AS Start_Time,
COUNT(Vlh.Thread#) Num_Logs
FROM V$log_History Vlh
GROUP BY To_Char(Vlh.First_Time,
‘YYYY-MM-DD’),
To_Char(Vlh.First_Time,
‘HH24′) || ‘:00′) Log_Hist,
V$log Vl,
V$database Vdb
WHERE Vl.Group# = 1
ORDER BY Log_Hist.Start_Date,
Log_Hist.Start_Time;

START_DATE START NUM_LOGS MBYTES DBNAME
———- —– ———- ———- ———
2009-03-21 15:00 8 400 BEN11G
2009-03-21 16:00 1 50 BEN11G
2009-03-22 10:00 1 50 BEN11G
2009-03-23 17:00 4 200 BEN11G
2009-03-25 21:00 2 100 BEN11G
2009-03-26 13:00 2 100 BEN11G
2009-04-06 22:00 1 50 BEN11G

We can then take the number of redo logs from the NUM_LOGS column of the above query and multiply by size of each online redo log (ORL) file.

SQL> select group#, members, bytes, archived, status
2 from v$log
3 ;

GROUP# MEMBERS BYTES ARC STATUS
———- ———- ———- — —————-
1 1 52428800 YES INACTIVE
2 1 52428800 NO CURRENT
3 1 52428800 YES INACTIVE

I will leave the math calculations up to you.

For those of you who cannot afford the AWR licensed option for 10g/11g, in this down economy, I will provide you with a low cost low tech way to figure out how much redo is generated by Oracle.

Another method to calculate redo generated for Oracle is to examine the pattern of log switches that occur within your Oracle database. Upon examination of your alert.log file, you can take a differential of log switches to assess exactly how much redo is generated at peak and idle times.

First lets perform some log switches in our test 11g database!

SQL> alter system switch logfile;

System altered.

Note: we are using 11gR1 on Oracle Enterprise Linux 5.2 for the examples here. So we start a new ADRCI session

[oracle@sandiego ~]$ adrci

ADRCI: Release 11.1.0.6.0 – Beta on Fri Aug 7 18:41:22 2009

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

ADR base = “/u01/app/oracle”
adrci> show alert

Choose the alert log from the following homes to view:

1: diag/rdbms/ben11g/ben11g
2: diag/clients/user_oracle/host_3399978961_11
3: diag/clients/user_unknown/host_411310321_11
4: diag/tnslsnr/sandiego/listener
Q: to quit

2009-08-07 18:45:58.653000 -07:00
Thread 1 advanced to log sequence 21
Current log# 3 seq# 21 mem# 0: /u01/app/oracle/oradata/ben11g/redo03.log
2009-08-07 18:46:03.171000 -07:00
Thread 1 advanced to log sequence 22
Current log# 1 seq# 22 mem# 0: /u01/app/oracle/oradata/ben11g/redo01.log
Thread 1 cannot allocate new log, sequence 23
Checkpoint not complete
Current log# 1 seq# 22 mem# 0: /u01/app/oracle/oradata/ben11g/redo01.log
2009-08-07 18:46:05.556000 -07:00
Thread 1 advanced to log sequence 23
Current log# 2 seq# 23 mem# 0: /u01/app/oracle/oradata/ben11g/redo02.log
2009-08-07 18:46:07.060000 -07:00
Thread 1 advanced to log sequence 24
Current log# 3 seq# 24 mem# 0: /u01/app/oracle/oradata/ben11g/redo03.log
2009-08-07 18:46:09.209000 -07:00
Thread 1 advanced to log sequence 25
Current log# 1 seq# 25 mem# 0: /u01/app/oracle/oradata/ben11g/redo01.log

So you can add up the total number of logs between log switches and divide by total time to obtain a rough estimate.

By understanding how to calculate redo generation, you will be prepared to understand one key component of planning for your Data Guard, Streams or replication environments as this will give you some idea on how much network bandwidth you will require to efficiently move the redo logs between source and target databases.

UPDATE:

Fellow Oracle professional, Coskan Gundogar provided a SQL script to examine redo log generation. Here is the sample output:

SQL*Plus: Release 11.1.0.6.0 – Production on Sun Aug 9 17:06:48 2009

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

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select trunc(first_time),sum(blocks*block_size)
from (select distinct first_change#,first_time,blocks,block_size,completion_time
from v$archived_log)
group by trunc(first_time)
order by trunc(first_time);

TRUNC(FIR SUM(BLOCKS*BLOCK_SIZE)
——— ———————-
26-MAR-09 51228160
06-APR-09 44119040
18-JUN-09 35488768
07-AUG-09 51233280

The primary difference in this script is that it queries redo generation from the V$ARCHIVED_LOG dynamic performance view rather than the earlier script that queries the V$LOG_HISTORY and V$LOG dynamic performance views.

So there you have it, multiple ways to calculate exactly how much redo is generated by your Oracle database! Stay tuned, next time we will provide some quick tips on tuning network and disk I/O for your Oracle database.

There is no greater happiness than freedom from worry, and there is no greater wealth than contentment.

_______________________________________________________________________________________________

Data Recovery Advisor

Oracle Database includes a Data Recovery Advisor tool that automatically diagnoses persistent data failures, presents appropriate repair options, and executes repairs at your request. Data Recovery Advisor provides a single point of entry for Oracle backup and recovery solutions. You can use Data Recovery Advisor through the Enterprise Manager Database Control or Grid Control console or through the RMAN command-line client.

A database failure usually manifests itself as a set of symptoms: error messages, alerts, trace files and dumps, and failed data integrity checks. Data Recovery Advisor automatically diagnoses and informs you of these failures. Within the context of Data Recovery Advisor, a failure is a persistent data corruption that can be directly mapped to a set of repair actions. Each failure has a status of open or closed. Each failure also has a priority of critical, high, or low.

Failures are detected by data integrity checks, which are diagnostic procedures executed to assess the health of the database or its components. If a data integrity check reveals a failure, then Data Recovery Advisor automatically assesses the effect of a set of failures and maps it to a set of repair options. In most cases, Data Recovery Advisor presents both automated and manual repair options.

Data Recovery Advisor determines the best automated repair option and its effect on the database. The repair option may include repairs such as datafile restore and recovery, media recovery, Flashback Database, and so on. Before presenting an automated repair option, Data Recovery Advisor validates it for the specific environment and the availability of media components required to complete the proposed repair.

If you choose an automated repair option, then RMAN coordinates sessions on the Oracle database to perform the repair for you. The Data Recovery Advisor tool verifies the repair success and closes the appropriate failures.

||||||||||||||||||||||||||||        Today’s OO ..Looks like some Electronics.. ||||||||||||||||||||||||||||

This Overwhelming Offer Has Not Started Yet

What is it? Here is a hint: Shake it to shuffle…

If we command our wealth, we shall be rich and free. If our wealth commands us, we are poor indeed.

Edmund Burke

___________________________________________________________________________________________________________

Send EMAIL using UTL_MAIL in Oracle 10g

The UTL_MAIL package is introduced in Oracle 10g and it is easier to use when compared to UTL_SMTP. In order to use Oracle UTL_MAIL package you need to set a new init.ora parameter “SMTP_OUT_SERVER”, set to your outgoing mailserver.

Follow the simple steps to send an email using UTL_MAIL package

Step 1: Install UTL_MAIL package
To install the UTL_MAIL package, run the below files as user “SYS”
$ORACLE_HOME/rdbms/admin/utlmail.sql
$ORACLE_HOME/rdbms/admin/prvtmail.plb

Step 2: Grant permissions
Grants the execute permission on UTL_MAIL privilege to PUBLIC or the user which will use the package. Run the beow command as user “SYS”
SQL> GRANT EXECUTE ON UTL_MAIL TO PUBLIC;
-or-
SQL> GRANT EXECUTE ON UTL_MAIL TO ;

Step 3: Set SMTP_OUT_SERVER parameter
SQL> ALTER SYSTEM SET smtp_out_server=’smtp.domain.com’ SCOPE=both;

Step 4: Create procedure to send email
CREATE OR REPLACE PROCEDURE test_email AS
BEGIN
UTL_MAIL.SEND(sender => ‘xxx@oracleracexpert.com’,
recipients => ‘xxx@oracleracexpert.com’,
cc => ‘xxx@oracleracexpert.com’,
bcc => ‘xxx@oracleracexpert.com’,
subject => ‘Test Mail’,
message => ‘Hi, This is just a test mail’);
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001,’The following error has occured:’ ||sqlerrm);
END;

SQL> exec test_email;

Step 5: Send email using UTL_MAIL with attachments
You must set UTL_FILE_DIR to a directory, where the attachment files exists

CREATE OR REPLACE PROCEDURE test_email_attach AS
BEGIN
UTL_MAIL.SEND_ATTACH_VARCHAR2(sender => ‘xxx@oracleracexpert.com’,
recipients => ‘xxx@oracleracexpert.com’,
cc => ‘xxx@oracleracexpert.com’,
bcc => ‘xxx@oracleracexpert.com’,
subject => ‘Test Mail’,
message => ‘Hi, This is just a test mail’
attachment => ‘text’
att_filename => ‘test_attach.txt’);
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001,’The following error has occured: ‘
sqlerrm);
END;

Please note that with att_inline you can specify, whether the attachment is viewable inline with the message body or not.

You can also use the below parameters
attachment – A text attachment.
priority – The message priority, the default is NULL.
mime_type – The mime type of the message, default is ‘text/plain; charset=us-ascii‘.
att_inline - Specifies whether the attachment is viewable inline with the message body, default is TRUE.
att_mime_type – The mime type of the attachment, default is ‘text/plain; charset=us-ascii‘.
att_filename - The string specifying a filename containing the attachment, default is NULL.

Regards,
Satishbabu Gunukula

http://www.oracleracexpert.com

___________________________________________________________________________________________________________

Today’s OO

06-18-2010

$50 Off Gifts for Dad at Sears ((Excludes Gift Cards)
Today at 12PM ET
List Price: $100.00
You Save: $50.00 (50%)
$50 Cash Rebate
Overwhelming Price:
$50.00
(Price before Tax, S&H)

Offer applies to Entire Online Selection In-Stock (Excludes Gift Cards). Purchase can be picked up in store but cannot be altered.

====

Sandisk Cruzer Micro 4GB U3 USB Flash Drive Black $5 through Ebay

Great minds have purposes; others have wishes.

Washington Irving

_____________________________________________________________________________________________________________

Performing a Backup Validation with RMAN

You can use the VALIDATE keyword of the BACKUP command to do the following:

• Check datafiles for physical and logical corruption
• Confirm that all database files exist and are in the correct locations

RMAN does not actually produce backup sets, but rather scans the specified files to determine whether they can be backed up and are not corrupted. In this sense, theBACKUP VALIDATE command is similar to the RESTORE VALIDATE command, except for backups rather than restore jobs. If the backup validation discovers corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions. After a corrupt block is repaired, the row identifying this block is deleted from the view.

For example, you can validate that all database files and archived redo logs can be backed up by running a command as follows:

BACKUP VALIDATE DATABASE ARCHIVELOG ALL;

RMAN displays the same output that it would if it were really backing up the files. If RMAN cannot validate the backup of one or more of the files, then it displays an error message. For example, RMAN may show output similar to the following:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/29/2001 14:33:47
ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option.

When the power of love overcomes the love of power, the world will know peace.

Jimi Hendrix

_____________________________________________________________________________________________

Determining When to Back Up Standby Database Archived Redo Logs

If you are making all your backups at the standby site, then you must ensure that you have backed up all the archived logs generated by the primary database. You have two methods for determining whether you need to back up a standby database archived log so that RMAN can use it for recovery:

• Running LIST command
• Querying RC_ARCHIVED_LOG

Using the LIST Command to Determine When to Back Up Standby Logs

Use the LIST BACKUP OF ARCHIVELOG ALL command to determine which logs RMAN has backed up.

To determine whether a log backup is needed by using the LIST command:

1. Query the recovery catalog to determine the locations of the archived redo logs. For example, issue:

   SELECT SEQUENCE#, IS_STANDBY
   FROM RC_ARCHIVED_LOG;
   
    SEQUENCE# IS_
   ---------- ---
          113 YES
          114  NO
          115  NO
          116  NO
   

   This output indicates that log sequence 113 is at the standby site but not at the primary site, and archived logs 114 through 116 are at the primary site but not the standby site.

2. Determine which logs are backed up by connecting to the recovery catalog and running a LIST BACKUP command in RMAN. For example:

   LIST BACKUP OF ARCHIVELOG ALL;
   
   List of Backup Sets
   Key     Recid      Stamp      LV Set Stamp  Set Count  Completion Time
   ------- ---------- ---------- -- ---------- ---------- ----------------------
   319     4          394624547  0  394624546  5          11-APR-00
   
       List of Backup Pieces
       Key     Pc# Cp# Status      Completion Time        Piece Name
       ------- --- --- ----------- ---------------------- ------------------------
       320     1   1   AVAILABLE   11-APR-00              /vobs/oracle/dbs/05boavh2_1_1
   
       List of Archived Logs Included
       Thrd Seq     Low SCN    Next SCN   Low Time        Next Time
       ---- ------- ---------- ---------- --------------- ---------------
       1    116     95153      95156      07-APR-00       07-APR-00
   

   This output shows that RMAN has backed up archived log 116, but has not backed up archived log 113. Because log 113 exists only at the standby site, you should either back up this log or copy it to the primary site.

Querying RC_ARCHIVED_LOG to Determine When to Back Up Standby Logs

You can query the recovery catalog to determine which logs RMAN has backed up.

To determine whether a log backup is needed by querying the catalog:

1. Query the RC_ARCHIVED_LOG recovery catalog view to determine whether all archived logs necessary for recovery are on disk. For example, issue the following query, where first_log_needed_for_recovery is the sequence number of the log that begins recovery and expected_num_of_logs is the number of logs that should be applied during complete recovery:

   SELECT 1 FROM RC_ARCHIVED_LOG
   WHERE SEQUENCE# >= first_log_needed_for_recovery
   AND IS_STANDBY='NO'
   AND STATUS='A'
   HAVING COUNT(*) = expected_num_of_logs;
   

   If the query returns no rows, then you do not have all logs necessary for complete recovery on disk. If the query does return rows, then you do have the necessary logs for complete recovery on disk.

2. Query the RC_BACKUP_REDOLOG view to determine whether you have backups of the logs necessary for complete recovery. For example, issue the following query, wherefirst_log_needed_for_recovery is the sequence number of the log that begins recovery and expected_num_of_logs is the number of logs that should be applied during complete recovery:

   SELECT 1 FROM RC_BACKUP_REDOLOG
   WHERE SEQUENCE# >= first_log_needed_for_recovery
   AND STATUS='A'
   HAVING COUNT(DISTINCT SEQUENCE#) = expected_num_of_logs;
   

   If the query returns no rows, then you do not have backups of all logs necessary for complete recovery. If the query does return rows, then you do have backups of all logs necessary for complete recovery.

________________________________________________

This Overwhelming Offer Has Not Started Yet

What is it? Here is a hint: Black(Mii + Mii) = ?..

There is more to life than increasing its speed.
Mahatma Ghandi

FIFA Soccer World Cup 2010 Starts Today….

Today’s Game

Game1 : South Africa V Mexico

Game2 : Uruguay  V France

________________________________________________________________________________________________

Recover in a Flash
By Arup Nanda

Reduce database recovery time, using the Oracle flash recovery area.

If you are using Oracle Recovery Manager (RMAN) as a backup tool for your Oracle database, you probably already know that you have two options for the backup location: disk and tape. If you choose the former, you may back up to any location available to the server, but you must make sure the location has enough space for the backups. You also have to remove the old backups to make room for the new ones, keep track of the redundant backups, and make sure that backups and archive logs are available.

Flash Recovery Area

To help manage disk backups, in Oracle Database 10g Release 1 and later, you can define a special disk area that serves as a location for all types of backups. This location is the flash recovery area (FRA). Oracle Database manages the space inside this area; keeps track of backups that are needed; and if necessary, deletes old ones to make room for new ones. By default, the Oracle RMAN backups (both regular and image copies), online redo logs, archived logs, control files, and flashback logs are created in the FRA. When new backups or files demand more room, Oracle Database automatically removes the nonessential backups, freeing the DBA from this chore. The files in the FRA are considered nonessential when they become obsolete according to the retention policy, or when they have already been backed up to tape with Oracle RMAN.

Setting Up

To set up the FRA, first decide on its location and size. To set /home/oracle/FRA as the location and 2GB as the size, you issue the following while logged in as the SYS user:

alter system set
db_recovery_file_dest_size = 2G;
alter system set
db_recovery_file_dest = '/home/oracle/FRA';

To ensure that the values are set after the database is restarted, put the following lines in the initialization parameter file:

db_recovery_file_dest_size = 2G
db_recovery_file_dest = '/home/oracle/FRA'

If you are setting up the FRA on an Oracle Real Application Clusters (Oracle RAC) database, the FRA location must be visible to all database nodes. So it must be one of the following: a shared file system, an NFS-mounted file system, or an Automatic Storage Management (ASM) disk group. If you use ASM, the parameter is set as

db_recovery_file_dest = '+DISKGROUP1'

You can check the values of the FRA parameters set by querying the V$RECOVERY_FILE_DEST data dictionary view:

select *
from v$recovery_file_dest;

For my example, the result shows that there are 51 files in the FRA (the NUMBER_OF_FILES column). To determine the file types, you can check the V$FLASH_RECOVERY_AREA_USAGE view. This view shows the used and reclaimable spaces of each type of file as percentages of this total space. To get a more useful picture, you can combine these two views in a single query, shown in Listing 1, which shows the total size of the files instead of percentages. As you can see from the output, there are 34 archived log files, 16 Oracle RMAN backup files, and 1 flashback log file. The nonessential backups that can be deleted show up as RECLAIMABLE. If there is not sufficient space, the Oracle RMAN backup will return with an error:

Code Listing 1: Space, by file type, consumed in the FRA

select file_type, space_used*percent_space_used/100/1024/1024 used,
space_reclaimable*percent_space_reclaimable/100/1024/1024 reclaimable, frau.number_of_files
from v$recovery_file_dest rfd, v$flash_recovery_area_usage frau;

FILE_TYPE       USED      RECLAIMABLE    NUMBER_OF_FILES
-----------     ----      -----------    ---------------
CONTROLFILE      .00              .00                  0
ONLINELOG        .00              .00                  0
ARCHIVELOG    664.86           547.20                 34
BACKUPPIECE   573.23           520.73                 16
IMAGECOPY        .00              .00                  0
FLASHBACKLOG    6.07              .00                  1

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 104857600 bytes disk space from 1073741824 limit

To create enough space for the Oracle RMAN backups to complete successfully, either manually remove some backups or increase the size of the FRA. To see the list of image copies in the FRA made by Oracle RMAN, you can use the Oracle RMAN list copy of database command, shown in Listing 2.

Code Listing 2: RMAN report of image copy datafiles in the FRA

RMAN> list copy of database;
List of Datafile Copies
Key    File   S   Completion Time  Ckp SCN   Ckp Time     Name
----   ----   -   ---------------  -------   ---------    -------------------------------------------------------------
4404   1      A   26-SEP-06        1607862   26-SEP-06    /home/oracle/FRA/PRODB2/datafile/o1_mf_system_2kmqnygd_.dbf
4407   2      A   26-SEP-06        1607935   26-SEP-06    /home/oracle/FRA/PRODB2/datafile/o1_mf_undotbs1_2kmqqy2b_.dbf
4405   3      A   26-SEP-06        1607907   26-SEP-06    /home/oracle/FRA/PRODB2/datafile/o1_mf_sysaux_2kmqpcnz_.dbf
4408   4      A   26-SEP-06        1607939   26-SEP-06    /home/oracle/FRA/PRODB2/datafile/o1_mf_users_2kmqr57t_.dbf
4406   5      A   26-SEP-06        1607926   26-SEP-06    /home/oracle/FRA/PRODB2/datafile/o1_mf_example_2kmqqgto_.dbf

In addition to storing the backups of datafiles and flashback logs, the FRA can also be configured to store archived logs, control files, and online redo logs. For information on these storage options, see “Configuring the Flash Recovery Area: Advanced Topics.”

Image Copy

Backup sets are the Oracle RMAN default backups, in which only the used blocks in the datafiles are captured in the backup files. Oracle RMAN image copies are exact copies of the datafiles, withall the blocks—used or not. Oracle RMAN takes this image copy while the database is up and running, and the database need not be put into any special mode. Here is how to make an Oracle RMAN image copy backup:

run {
  backup as copy
  database;
}

This command, when run from the Oracle RMAN command prompt, creates the copies of the datafiles in the FRA with an Oracle-generated name such as o1_mf_users_2kmqr57t_.dbf.

Instant Recovery

Image copies in the FRA become truly useful when you need an “instant recovery.” Remember that these image copies are copies of the datafiles—a fact recorded in the Oracle RMAN catalog and the control file. In case of a disaster, you don’t need to restore the file; you can use the copy as the principal datafile immediately.

Suppose that one of your datafiles has become corrupted and needs recovery. Traditionally, you follow this general approach:

1. Take the tablespace offline.
2. Restore the datafile from the backup.
3. Recover the datafile to the point of failure.
4. Place the tablespace online.

Step 2 may take a long time, depending on the size of the file, the speed of the underlying disks, the transfer rate from backup to the original datafile location, and the other processes running on the system. Suppose that on your system, it takes more than two hours to complete this step, making the tablespace data unavailable for the entire duration. This motivates you to take a look at minimizing recovery time. You consider using image copies to speed up the recovery.

Using image copies, step 2 in the recovery is replaced by “Instruct the database to use the copy of the datafile instead of the original.” This reduces the time taken by the step from hours to seconds. Here is the description of the recovery process, assuming that the USERS tablespace has been damaged:

First, check the file ID (number) and name of the datafile of the tablespace. The output is shown in vertical format:

select file_id, file_name
from dba_data_files
where tablespace_name  = 'USERS';
FILE_ID : 4
NAME    : /home/oracle/oradata/PRODB2/
              users01.dbf

Connect to Oracle RMAN and complete the rest of the recovery activities, which are similar to the steps listed above except that Step 2 is now “Switch datafile 4 to the copy in the FRA.” All the operations are shown in Listing 3.

Code Listing 3: RMAN operations to switch to the FRA

RMAN> sql 'alter tablespace users offline';
sql statement: alter tablespace users offline
RMAN> switch datafile 4 to copy;
datafile 4 switched to datafile copy "/home/oracle/FRA/PRODB2/datafile/o1_mf_users_2kmqr57t_.dbf"
RMAN> recover datafile 4;
Starting recover at 26-SEP-06
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 26-SEP-06
RMAN> sql 'alter tablespace users online';
sql statement: alter tablespace users online

After the tablespace is brought online, check the filename:

select name from v$datafile
where file# = 4;

NAME
----------------------------------
/home/oracle/FRA/PRODB2/datafile/
o1_mf_users_2kmqr57t_.dbf

Note that the filename is no longer /home/oracle/oradata/PRODB2/users01.dbf; rather, the copy in the FRA is shown as the original datafile. The tablespace becomes usable very quickly without a restore operation. Figure 1 shows original and copy datafile status before and after switching from a damaged datafile 4.

Figure 1. Using a copy of a datafile

Switchback

Even though the datafile has been quickly brought online to minimize downtime, it is now in the backup location, which may be on slower disks than what the main database is on. You may not want to run the database with the datafile at this location for long; you would typically want to move the datafile back to the original location—/home/oracle/oradata/PRODB2/—as soon as it becomes available. You can use Oracle RMAN to accomplish this. Here is a summary of the steps:

1. Make an image copy of the datafile at the original location.
2. Take the tablespace offline.
3. Switch the datafile to the “copy” (however, in this case, the “copy” is at the original location).
4. Recover the tablespace.
5. Place the tablespace online.

These steps are presented in Listing 4. After the switchover, you can make sure the datafile is back in its original location:

select name from v$datafile
where file# = 4;

NAME
---------------------------------------
/home/oracle/oradata/PRODB2/users01.dbf

Code Listing 4: Switching back from the FRA to the original location

RMAN> backup as copy datafile 4 format '/home/oracle/oradata/PRODB2/users01.dbf';

Starting backup at 27-SEP-06
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile fno=00004 name=/home/oracle/FRA/PRODB2/datafile/o1_mf_users_2kmqr57t_.dbf
output filename=/home/oracle/oradata/PRODB2/users01.dbf tag=TAG20060927T103710 recid=45 stamp=602246230
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01
Finished backup at 27-SEP-06

Starting Control File Autobackup at 27-SEP-06
piece handle=/home/oracle/FRA/PRODB2/autobackup/2006_09_27/
o1_mf_n_602246232_2ko34s42_.bkp comment=NONE
Finished Control File Autobackup at 27-SEP-06
RMAN> sql 'alter tablespace users offline';
...
RMAN> switch datafile 4 to copy;

datafile 4 switched to datafile copy "/home/oracle/oradata/PRODB2/users01.dbf"

RMAN> recover datafile 4;
...
RMAN> sql 'alter tablespace users online';
...

In case of a failure, you save valuable time by quickly using the image copy of the datafile in the FRA, and there is no need to restore it first. The same concept can be applied to the entire database as well. If the original location of all the datafiles is damaged, you can easily switch the entire database to the copy stored in the FRA. To switch to the FRA copy, issue the following, which directs the whole database to use all the latest image copies in the FRA location as its datafiles:

RMAN> switch database to copy;

Note that you can also perform the above operations on the image copies in any location without using the FRA. However, using the FRA moves the burden of managing the space from the DBA to the database.

Back Up to Tape

Although the backup to the FRA comes with great benefits, it is still not foolproof for normal disaster protection. Disks can fail, making these FRA backups disappear. Similarly, unlike tapes, disks cannot be removed easily and stored at a different location. Therefore, you still need to back up the FRA to tape. To do so, use the following command in RMAN. It backs up all contents of the FRA, including archived logs:

run {
  allocate channel c1 type sbt_tape;
  backup recovery area;
}

Conclusion

The primary objective of any backup design is to enhance the process of recovery—to make it faster and more reliable. Using the flash recovery area, DBAs can direct all backups to a single location that is managed by Oracle Database. Using the Oracle RMAN image copies in the FRA, DBAs can very quickly recover from damage to a datafile without using a traditional restore-and-recovery operation.

====

Today’s OO looks useless as well.

It seems today’s OO is Barns and Nobels gift card

====

Success is the sum of small efforts, repeated day in and day out.
Robert Collier

_____________________________________________________________________________________________

Oracle Flashback Technology reduces recovery time from hours to minutes.

According to many studies, 40% of application outages are caused by operator or user errors. Part of being human is making mistakes. But these errors are extremely difficult to avoid and can be particularly difficult to recover from without advance planning and the right technology. Such errors can result in “logical” data corruption, or cause downtime of one or more components of the IT infrastructure. While it is relatively simple to rectify the failure of an individual component, detection and repair of logical data corruption, such as accidental deletion of valuable data, is a time consuming operation that causes enormous loss of business productivity. Typical user-errors may include accidental deletion of valuable data, deleting the wrong data, and dropping the wrong table.

Guarding Against Human Errors
The Oracle Database architecture leverages the unique technological advances in the area of database recovery due to human errors. Oracle Flashback Technology provides a set of new features to view and rewind data back and forth in time. The Flashback features offer the capability to query historical data, perform change analysis, and perform self-service repair to recover from logical corruptions while the database is online. With Oracle Flashback Technology, you can indeed undo the past!

Oracle9i introduced Flashback Query to provide a simple, powerful and completely non-disruptive mechanism for recovering from human errors. It allows users to view the state of data at a point in time in the past without requiring any structural changes to the database.

Oracle Database 10g extended the Flashback Technology to provide fast and easy recovery at the database, table, row, and transaction level. Flashback Technology revolutionizes recovery by operating just on the changed data. The time it takes to recover the error is now equal to the same amount of time it took to make the mistake. Oracle 10g Flashback Technologies includes Flashback Database, Flashback Table, Flashback Drop, Flashback Versions Query, and Flashback Transaction Query.

Flashback technology can just as easily be utilized for non-repair purposes, such as historical auditing with Flashback Query and undoing test changes with Flashback Database. Oracle Database 11g introduces an innovative method to manage and query long-term historical data with Flashback Data Archive. This release also provides an easy, one-step transaction backout operation, with the new Flashback Transaction capability.

New Features in Oracle Database 11g

Flashback Data Archive

Flashback Data Archive can be used to automatically track and maintain historical changes to all Oracle data in a highly application transparent, secure and efficient manner. Part of the Oracle Total Recall Option, Flashback Data Archive provides enterprises with a quick, centralized and extremely efficient solution to meet all historical data management needs. Flashback Data Archive automatically tracks every single change made to the data stored inside the database and maintains a secure, efficient and easily accessible archive of historical data. The captured historical data can be retained for as long as the business demands and is easily accessible using Flashback SQL queries. Historical data tracking can be enabled on both existing and new tables instantaneously and more importantly, in a completely application transparent manner.

Flashback Data Archive presents a high-performance, storage optimized solution with a centralized management interface for satisfying data retention and change control requirements for organizations. The primary advantages of using Flashback Data Archive for historical data tracking include:

• Application Transparent: Enabling historical data capture on one or more tables can be done instantaneously with no or minimal application changes. Customers can therefore use this feature to capture historical data for both packaged as well as home grown applications.
• Seamless Access: Historical data can be easily accessed using familiar Flashback SQL constructs. Flashback Data Archive includes support for Flashback Queries. Applications can seamlessly query the history of table data, as it existed in different points in time. No special snapshots need to be taken to take advantage of this feature.
• Security: Historical data, once generated, is immutable to all users. This is enabled out-of-the-box and no special or extra setup is required. Access to the internal history tables is restricted to reads only. No DML operations are allowed to users, including administrators. Applications need not query the internal history tables directly as seamless access is provided through the Flashback Query mechanism.
• Minimal performance overhead: Regular user transactions will see negligible impact. Flashback Data Archive employs a lightweight mechanism to mark DML operations on tracked tables for archiving. The actual history generation and archiving is done asynchronously through a background process as explained later.
• Storage Optimized: The history data is internally partitioned and highly compressed to reduce the storage footprint. Flashback Data Archive employs a highly efficient compression scheme to compress the internal history tables. In addition, it automatically partitions the internal history tables based on a range-partitioning scheme. Both compression and partitioning in flashback data archive are managed automatically and require no special administration.
• Centralized Management: Flashback Data Archive provides a centralized and policy-based management interface to automate a number of ongoing administrative tasks. With Flashback Data Archive, you can easily group tables and set a common retention policy. New tables will automatically inherit the retention parameter from the flashback data archive in which it resides. Oracle will automatically purge aged-out history data for all tracked tables based on the specified retention. This frees up the administrator from the repetitive management of history data and avoids costly errors associated with manual maintenance, such as purging incorrect history data.

Flashback Transaction

Large-scale database applications rely on complex sequences of transactions, to ensure atomicity and consistency of a group of inserts, updates, or deletes. In the event of a ‘bad’ transaction, the administrator must trail back-in-time to see what changes were effected by the transaction and ascertain any dependencies (e.g. transactions that modified the same data after the ‘bad’ transaction), to ensure that undoing the transaction preserves the original, good state of the data and any related data. Performing this type of transaction analysis can be laborious, especially for very complex applications.

With Flashback Transaction, a single transaction, and optionally, all of its dependent transactions, can be flashed back with a single PL/SQL operation or by using an intuitive EM wizard to identify and flashback the problem transactions. Flashback Transaction relies on the availability of undo data and archived redo logs for the given transaction and its dependents, to backout the changes.

New Features in Oracle Database 10g Release 2

Restore Points

When an Oracle database point-in-time recovery operation is required, a DBA must determine a time or SCN to which the data must be rolled back. Oracle Database 10g Release 2 simplifies point in time recovery with restore points. A restore point is a user-defined name that can be substituted for an SCN or clock time when used in conjunction with Flashback Database, Flashback Table, and Recovery Manager (RMAN), and can be created at the command-line with SQL*Plus or RMAN, or through Enterprise Manager. Restore points eliminate the need to investigate the SCN or time of a transaction and provides users with the ability to bookmark a database transaction event. Guaranteed restore points ensure that sufficient flashback logs are always maintained to get back to that restore point. This means that flashback logs will not be deleted by the Flash Recovery Area, unless they are not needed for the current guaranteed restore points. These special restore points can be created before major database changes, such as a database batch job or schema upgrade, and used for flashback if the changes need to be undone.

Flashback Database Through RESETLOGS

Flashback Database through RESETLOGS allows flashback logs created prior to a RESETLOGS operation to be utilized for Flashback Database operations. In Oracle Database 10g Release 2, flashback logs are preserved after opening the database with RESETLOGS. This new feature is useful when a long-standing logical error is not discovered until after RESETLOGS is performed, and a flashback prior to RESETLOGS is needed. In an Oracle Data Guard environment, this capability allows a physical standby database that has been opened read-write to later flashback the changes and be converted back to a physical standby database. If a logical error is discovered after a switchover operation, the primary and standby databases can be flashed back to an SCN or a point in time prior to the switchover operation.

New Features in Oracle Database 10g Release 1

Flashback Database

Flashback Database quickly rewinds an Oracle database to a previous time, to correct any problems caused by logical data corruptions or user errors. Flashback Database is like a ‘rewind button’ for your database. It provides database point in time recovery without requiring a backup of the database to first be restored. When you eliminate the time it takes to restore a database backup from tape, database point in time recovery is fast

The Flashback Database capability, accessible from both RMAN and SQL*Plus by using the FLASHBACK DATABASE command, is similar to conventional point-in-time recovery in its effects. It allows you to return a database to its state at a time in the recent past. To enable the Flashback Database capability, a DBA configures the Flash Recovery Area. The Flash Recovery Area is a new feature in Oracle Database 10g that provides a unified storage location for all recovery related files and activities in an Oracle database. Besides Flashback Database logs, the recovery area contains archived redo logs and RMAN backups. For more information on the Flash Recovery Area, consult the Oracle Backup and Recovery documentation.

Oracle automatically creates and manages Flashback Logs within the Flash Recovery Area. Since the Flash Recovery Area is configured with a space quota, the Flashback Logs are subject to those disk space restrictions. The size of Flashback Logs can vary considerably, depending on the read/write ratio of database changes during a given flashback-logging interval. A copy of the old block version is written to the Flashback Log. If, over the course of a day, 10% of the database blocks are updated, then the size of Flashback Logs for 24 hours is approximately one-tenth the size of your database. The DBA may change this disk quota dynamically if more disk space is required to recover the database to an earlier time in the past.

Flashback provides Data Guard with an easy-to-use method to correct user errors. Flashback Database can be used on both the primary and standby database to quickly revert the databases to an earlier point in time to back out user errors. If the administrator decides to failover to a standby database, but those user-errors were already applied to the standby database (for example, because Real Time Apply was enabled), the administrator can simply flashback the standby database to a safe point in time.

The performance overhead of enabling Flashback Database is less than 2%. While you may not be willing to sacrifice any performance overhead for your production database, think about the trade-off. If you could recover the database in minutes instead of hours, saving your company millions of dollars in lost revenue, would you then give 2% of the resources to Flashback Database? Enabling Flashback Database functionality provides the following benefits.

• Eliminate the time to restore a backup. When a database is down because it runs into a catastrophic problem, considerable revenue can be lost because the company cannot do business.
• Eliminate standby database redo apply delay. Flashback database is seamlessly integrated with Data Guard. A standby database can now be quickly and easily flashed back to an arbitrary point in time, so a delay in redo apply is not necessary.
• Unanticipated error correction. Flashback Database provides a continuous snapshot of the Oracle database. The database can be rewound back to a SCN or timestamp.

Flashback Table

When a human or application error occurs, you want to be able to restore the state of one or more tables to a point in time before the problem occurred. Flashback Table provides the DBA the ability to recover a table or a set of tables to a specified point in time quickly, easily, and online. Flashback Table restores the tables while automatically maintaining its associated attributes such as – the current indexes, triggers and constraints, not requiring the DBA to find and restore application specific properties. Flashback Table alleviates the need for you to perform more complicated point in time recovery operations. The following command flashes back the ORDERS and ORDER_ITEMS tables to 2:33 PM on July 7.

FLASHBACK TABLE orders, order_items TO TIMESTAMP (JUL-07-2003, 02:33:00);

Like Flashback Query, Flashback Table also relies on the undo data to recover the tables. The undo data, therefore, must be available in order for a Flashback Table to be successful. The Automatic Undo Management feature allows you to specify how long they wish to retain the undo data using the UNDO_RETENTION initialization parameter. By using this parameter and sizing the undo tablespace appropriately, DBAs can control how far back in time a table can be repaired using Flashback Table.

While a DBA can use the Flashback Table feature to quickly recover from human errors, it also serves as a self-service repair tool to recover from accidental modifications or deletions. An application developer can incorporate the Flashback Table functionality into their customized application. This tool provides significant benefits over media recovery in terms of ease of use, availability and faster restoration with point-in-time object based recovery. Flashback Table

• Performs the restore operation online
• Restores all data in a specified table to a previous point in time described by a timestamp or SCN
• Automatically restores all of the table attributes, such as indexes, triggers, and the like that are necessary for an application to function with the flashed back table
• Maintains any remote state in a distributed environment. For example, all of the table modifications required by replication are flashed back.
• Maintains data integrity as specified by constraints. Oracle preserves all dependent objects and the referential integrity.
• Provides the ability to revert it back to its original state even after a flashback operation.

Flashback Drop
Dropping of objects by accident has always been a problem for users and DBAs alike. Users soon realize their mistake but then it’s too late and historically there is no easy way to recover those dropped tables, indexes, constraints, triggers, etc. Flashback Drop provides a safety net when dropping objects in Oracle Database 10g. When a user drops a table, Oracle automatically places it into the Recycle Bin.

What is the Recycle Bin?

The Recycle Bin is a virtual container where all dropped objects reside. Underneath the covers, the objects are occupying the same space as when they were created. If table EMP was created in the USERS tablespace, the dropped table EMP remains in the USERS tablespace. Dropped tables and any associated objects such as indexes, constraints, nested tables, and other dependant objects are not moved, they are simply renamed with a prefix of BIN$$. You can continue to access the data in a dropped table or even use Flashback Query against it. Each user has the same rights and privileges on Recycle Bin objects before they were dropped. You can view your dropped tables by querying the new RECYCLEBIN view. Objects in the Recycle Bin will remain in the database until the owner of the dropped objects decides to permanently remove them using the new PURGE command. The Recycle Bin objects are counted against a user’s quota. But Flashback Drop is a non-intrusive feature. Objects in the Recycle Bin will be automatically purged by the space reclamation process if

• a user creates a new table or adds data that causes their quota to be exceeded.
• the tablespace needs to extend its file size to accommodate create/insert operations.

Dropped the wrong table? No problem. Just undrop it with Flashback Drop.

Flashback Query

Introduced with Oracle9i, Flashback Query provides the ability to view the data as it existed in the past. By default, operations on the database use the most recent committed data available. If you want to query the database as it was at some time in the past, you can do so with the Flashback Query feature. It lets you specify either a time or a system change number (SCN) and query using the committed data from the corresponding time. The Flashback Query mechanism is most effective when you use Automatic Undo Management.

The Oracle database treats undo as a first class database object. Undo is persistent and can survive database system crash or, shutdown. It also shares the database buffer cache with other database objects for better performance. The Oracle database uses undo beyond transaction commit to provide read consistency for long running queries and also, to recover from logical corruptions.

The Oracle database provides a means of explicitly specifying the amount of undo to retain. The system automatically recycles expired undo to make space for new transactions to generate undo. The choice of undo retention value depends upon the length of the long running queries and the logical corruption recovery requirements. Users can, however, choose not to specify the undo retention and allow the system to provide the best retention for the given undo space. This best retention allows for best possible coverage for the long running queries and also, to recover from logical corruptions. The default undo retention is not guaranteed. The system can use oldest un-expired undo if it runs out of expired undo to use for an ongoing transaction.

New in Oracle Database 10g Release 1 is the ability to query data in the past for more than 5 days if the UNDO_RETENTION is set for greater then 5 days. Oracle will maintain the undo for that period of time as long as the Undo Tablespace datafiles are allocated enough disk space The following describes the steps required to ensure a database is enabled to use the Flashback Query and other flashback features that are dependent upon undo information:

1. Ensure that the database is using an undo tablespace. Setting the UNDO_MANAGEMENT initialization parameter to AUTO specifies this.
2. Set the UNDO_RETENTION initialization parameter to a value that causes undo to be kept for a length of time that allows success of your longest query back in time or to recover from human errors.
3. To guarantee that unexpired undo will not be overwritten, set the RETENTION GUARANTEE clause for the undo tablespace.

The unique feature of Flashback Query allows you to see the data as it was in the past, then choose exactly how to process the information. You might perform an analysis and then undo the changes, or capture changed data for further processing. The Flashback Query mechanism is flexible enough to be used in many situations. You can:

• query data as it existed in the past.
• compare current data with past data. You can compare individual rows or do more complex comparisons such as finding the intersection or union.
• recover deleted or changed data.

Flashback Versions Query

Flashback Versions Query provides a way to audit the rows of a table and retrieve information about the transactions that changed the rows. It retrieves all committed versions of the rows that exist or ever existed between the time the query was issued and a point in time in the past. It accomplishes this by utilizing Automatic Undo Management.

The Flashback Versions Query is an extension to SQL that allows you to retrieve the different versions of rows in a given table that existed in a specific time interval. For any given table, a new row version is created every time the COMMIT statement is executed. The Flashback Versions Query returns a row for each version of the row that existed in the time interval you specify. You invoke the Flashback Versions Query functionality by using the VERSIONS BETWEEN clause of the SELECT statement.

Flashback Versions Query offers new additional columns that provide transaction details on the row data that allows a DBA to pinpoint when and how data is changed in the Oracle database.

• VERSIONS_XID – The transaction id that created this version of the row
• VERSIONS_OPERATION – The action that created this version of the row (such as delete, insert, and update)
• VERSIONS_STARTSCN – The SCN in which this row version first occurred
• VERSIONS_ENDSCN — The SCN in which this row version was changed.

The Flashback Versions Query is a powerful tool for the DBA to run analysis and answer the question, ‘How did this happen?’ Not only can the DBA run manual analysis, but this is a powerful tool for the application’s developer as well. You can build customized applications for auditing purposes. Now everyone really is accountable for his or her actions.

Flashback Transaction Query

You may discover that somehow data in a table has been inappropriately changed. To research this change, you can use multiple flashback queries to view row data at specific points in time. More efficiently, you can use Flashback Versions Query feature to view all changes to a row over a period of time and the associated transaction id’s. This feature allows you to append VERSIONS BETWEEN clause to a SELECT statement that specifies an SCN or timestamp range between which you want to view changes to row values.

Once you identify an erroneous transaction, you can then use the Flashback Transaction Query feature to identify other changes that were done by the transaction, and to request the undo SQL to reverse those changes. The FLASHBACK_TRANSACTION_QUERY view is the means by which you obtain transaction history and undo SQL.

If you need to reverse the effects of the erroneous transaction, the undo SQL statements can be manually executed, allowing easy recovery from user or application errors. Flashback Transaction Query can increase online diagnosability of problems in your database and facilitate analysis and audits of transactions.

Summary

Human errors are one of the predominant causes of system failure. These errors are extremely difficult to avoid and can be particularly difficult to recover without advance planning and the right technology. The ‘right’ technology is here: Oracle Database 11g. Why should an error that takes seconds to execute take hours or days to recovery from? It shouldn’t and now it doesn’t. Flashback revolutionizes recovery by operating on just the changed data. A single command surgically repairs corruptions from human errors. Flashback technology removes the complexity of recovery while decreasing the time it takes to recover from unpredictable human errors.

You’re happiest while you’re making the greatest contribution.
Robert F. Kennedy

____________________________________________________________________________________________

Making Incremental Backups with RMAN

You can make consistent or inconsistent incremental backups of the database or individual tablespaces or datafiles. If the database is in NOARCHIVELOG mode, then you can only make consistent incremental backups, so the database must be closed cleanly. In ARCHIVELOG mode the database can be open or closed.

To make an incremental backup:

1. After starting RMAN, run the BACKUP INCREMENTAL command at the RMAN prompt. This example makes a level 0 backup:

   BACKUP INCREMENTAL LEVEL = 0 DATABASE;
   

   This example makes a differential level 1 backup of the SYSTEM tablespace and datafile sales.f; it will only back up those data blocks changed since the most recent level 1 or level 0 backup:

   BACKUP INCREMENTAL LEVEL = 1
     TABLESPACE SYSTEM
     DATAFILE '?/oradata/trgt/tools01.dbf';
   

   This example makes a cumulative level 2 backup of the tablespace users; it will only back up those data blocks changed since the most recent level 1 or level 0 backup:

   BACKUP INCREMENTAL LEVEL = 2 CUMULATIVE TABLESPACE users;
   

2. Optionally, issue a LIST BACKUP command to see a listing of backup sets and pieces. For example:

   LIST BACKUP OF DATABASE;

Inspiration and genius–one and the same.
Victor Hugo

________________________________________________________________________________________________

Configuring and Allocating Channels for Use in Backup and Copy Jobs

You have the following mutually exclusive options for executing backup and copy jobs:

• Configure automatic channels with the CONFIGURE command, and then issue BACKUP and COPY commands at the RMAN prompt or within a RUN block
• Allocate channels manually and issue BACKUP and COPY commands within a RUN block

The easiest way to make backups is to configure automatic channels. For example, so long as you have already configured an sbt device type, you can configure a defaultsbt channel as follows (note that the PARMS value is vendor-specific):

CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(NSR_SERVER=bksvr1)';

Then, you can back up the database to tape at the RMAN prompt as follows:

BACKUP DATABASE;

RMAN preconfigures a DISK channel for you, so you can make disk backups using automatic channels without performing any configuration whatsoever.

The other method is to allocate channels manually within a run job. For example, this command allocates multiple disk channels and then backs up the database and archived redo logs:

RUN
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE DISK;
  ALLOCATE CHANNEL ch2 DEVICE TYPE DISK;
  ALLOCATE CHANNEL ch3 DEVICE TYPE DISK;
  BACKUP DATABASE PLUS ARCHIVELOG;
}

This example manually allocates an sbt channel (with a vendor-specific PARMS value) and backs up a datafile copy:

RUN
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt PARMS 'ENV=(NSR_SERVER=bksvr1)';
  BACKUP DATAFILECOPY '/tmp/system01.dbf';
}

For the most part, the procedures in this chapter assume that you have configured automatic channels.

================================================================================================

Wel-Come back to work day after memorial day weekend..

Try not to become a man of success but a man of value.
Albert Einstein

__________________________________________________________________________________________________

Each week I check statistics for our web site, just to see if anyone is stopping by and what they might be interested in. One of the questions that has popped up more than once is “how do I know if my database (instance) was started with a pfile or an spfile?”Probably the best way to determine if an spfile was used to start the instance is to query the data dictionary view v$spparameter. According to the Oracle documentation (bolded is my note) "V$SPPARAMETER displays information about the contents of the server parameter file. If a server parameter file (spfile) was not used to start the instance, then each row of the view will contain FALSE in theISSPECIFIED column.” The documentation further states that if an spfile was not used to start the instance, then The value column will be null for all rows. The ordinal column will be 0 for all rows. It is possible to use both a pfile and an spfile at instance startup. In this situation, when starting the database, you would use a pfile, and then specify an spfile using the startup parameter spfile. If the instance is not using an spfile at startup, then spfile parameter value will be null. SELECT name, value FROM   v$parameter WHERE  name = ‘spfile’; NAME —————————————————————- VALUE ——————————————————————————– spfile <null> If the instance is using an spfile, then the query will return the location of the spfile. If the instance is started using an spfile in the default location, Oracle will default the value, as in the query below. SELECT name, value FROM   v$parameter WHERE  name = ‘spfile’; NAME —————————————————————- VALUE ——————————————————————————– spfile %ORACLE_HOME%\DATABASE\SPFILE%ORACLE_SID%.ORA Note: This tip was tested using Oracle9i.

]]> http://newdelhitime.wordpress.com/2010/06/01/tech-town-06012010/feed/ 5 newdelhitime