CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/backup/ora_df%t_s%s_s%p’;
backup as compressed backupset database include current controlfile for standby plus archivelog
crosscheck archivelog all;
crosscheck backup;
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT 'C:\tmp\backup_files\GINESYS_RMAN_%t_s%s_s%p’;
backup as compressed backupset database include current controlfile for standby plus archivelog;
crosscheck archivelog all;
crosscheck backup;
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
backup backupset database include current controlfile for standby plus archivelog;
====================================================
orapwd file=C:\tmp\backup_files\ORAPWGINESYS_NEW password=GINESYS entries=2
SELECT table_name, owner FROM user_tables where owner='SAURAV';
backupset compression standby archivelog controlfile
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/backup/ora_df%t_s%s_s%p’;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘+FLASHDG’;
crosscheck backup;
crosscheck archivelog all;
report obsolete;
rman TARGET SYS/pwd@target
RMAN>backup database include current controlfile for standby plus
archivelog;
backup as compressed backupset database include current controlfile for standby plus archivelog
RESET DATABASE command
Inform RMAN that the SQL statement ALTER DATABASE OPEN RESETLOGS has been executed and that a new incarnation of the target database has been created, or reset the target database to a prior incarnation.
RMAN> RESET DATABASE TO INCARNATION 3;
alter-database-open-resetlogs
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT 'C:\backup\df%t_s%s_s%p';
RMAN> CONFIGURE COMPRESSION ALGORITHM 'BZIP2';
RMAN> CONFIGURE COMPRESSION ALGORITHM 'ZLIB'; --Oracle 11g R1
RMAN> CONFIGURE COMPRESSION ALGORITHM 'LOW'; --11g R2,corresponds to LZO
RMAN> CONFIGURE COMPRESSION ALGORITHM 'MEDIUM'; --11g R2,corresponds to ZLIB
RMAN> CONFIGURE COMPRESSION ALGORITHM 'HIGH'; --11g R2,corresponds to unmodified BZIP2
RMAN> CONFIGURE COMPRESSION ALGORITHM 'BASIC'; --Oracle 11g R2,corresponds to BZIP2
RMAN> CONFIGURE DB_UNIQUE_NAME 'standby' CONNECT IDENTIFIER 'standby_cs';
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK FOR DB_UNIQUE_NAME 'standby';
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK FOR DB_UNIQUE_NAME ALL;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT FOR DB_UNIQUE_NAME po;
RMAN> run
2> {
3> ALLOCATE CHANNEL d1 DEVICE TYPE disk
4> FORMAT = ‘D:\tmp\newTest\ORCL_RMAN_%d_%s_%p.bak’;
5> backup as compressed backupset archivelog from sequence 680;
6> }
RMAN> SHOW RETENTION POLICY;
RMAN> SHOW RETENTION POLICY FOR DB_UNIQUE_NAME ALL;
RMAN> SHOW DEVICE TYPE;
RMAN> SHOW DEVICE TYPE FOR DB_UNIQUE_NAME prod3;
RMAN> SHOW DEFAULT DEVICE TYPE;
RMAN> SHOW CHANNEL;
RMAN> SHOW MAXSETSIZE;
RMAN> SHOW BACKUP OPTIMIZATION;
RMAN> SHOW SNAPSHOT CONTROLFILE NAME;
RMAN> SHOW CONTROLFILE AUTOBACKUP;
RMAN> SHOW COMPRESSION ALGORITHM;
RMAN> SHOW ENCRYPTION ALGORITHM;
RMAN> SHOW ALL FOR DB_UNIQUE_NAME ALL;
RMAN> SHOW ALL FOR DB_UNIQUE_NAME 'STANDBY';
RMAN NOTES:
=================================================================================
Backing Up Standby Databases
The RMAN BACKUP command backs up the standby database exactly the same as a primary database, except that the backup takes place on the standby site. The primary database has no influence on the backup of the standby database.
When you connect to the standby database to perform the backup, use the TARGET keyword and not the AUXILIARY keyword.
The state of the standby database when the backup is made determines whether the backup is consistent or inconsistent. To make a consistent backup, the standby database must shutdown cleanly and be mounted, but not placed in recovery mode. Any other status results in an inconsistent backup and must be restored using media recovery.
=================================================================================
Backups in a Data Guard Environment
A recovery catalog is required when you are performing RMAN operations in a Data Guard environment. The catalog enables all RMAN operations to be transparently executable at any primary or standby database. You can offload primary database backups onto any standby database in the environment; the RMAN backups are interchangeable. If you use RMAN in NOCATALOG mode, then RMAN uses only the metadata in the mounted control file.
In a Data Guard environment, the database that creates a backup or copy is associated with the file. For example, if RMAN connects as TARGET to database prod and backs it up, then this database backup is associated with prod. A backup remains associated with the database that created in unless you use the CHANGE ... RESET DB_UNIQUE_NAME to associate the backup with a different database.
The association of a backup is different from its accessibility. The recovery catalog considers disk backups as accessible only to the database in the Data Guard environment on which it was created, whereas tape backups created on one database are considered accessible to all databases. If a backup file is not associated with any database, then the row describing it in the recovery catalog view shows null for the SITE_KEY column. By default, RMAN associates files whose SITE_KEY is null with the database to which RMAN is connected as TARGET.
In a Data Guard environment, RMAN commands can operate on any backups that are accessible. For example, assume that databases prod and standby1 reside on different hosts. RMAN backs up data file 1 on prod to /prodhst/disk1/df1.dbf on the production host and also to tape. RMAN backs up data file 1 on standby1 to /sby1hst/disk2/df1.dbf on the standby host and also to tape. If RMAN is connected to database prod as TARGET, then you cannot use RMAN to perform operations with the /sby1hst/disk2/df1.dbf backup located on the standby host. However, RMAN considers the tape backup made on standby1 as eligible to be rest
=================================================================================
AS BACKUPSET
Creates backup sets on the specified device. This is the default backup type.
AS BACKUPSET is the only possibility when backing up to tape, and for creating level 1 incremental backups to any destination. Backup sets are RMAN-specific logical structures. The backup set is the smallest unit of a backup.
The FILESPERSET parameter of the BACKUP command determines the maximum number of files in each backup set. Archived redo log files and data files are never combined into a single backup set.
When using encrypted backups (see "Encryption of Backup Sets"), data files from tablespaces with different encryption settings are never written into the same backup set.
RMAN cannot back up files with different block sizes into the same backup set. RMAN can back up tablespaces with different block sizes, but puts each differently sized data file into its own backup set.
When unused block compression is applied, RMAN reads only the blocks that are currently allocated to a table. RMAN still checks each of the blocks to see whether the header has marked the block as unused. If a block has been unused, it is not written to the backup.
Unused block compression is turned on automatically when all of the following five conditions are true:
The COMPATIBLE initialization parameter is set to 10.2 or higher.
Note: If COMPATIBLE is set to 10.2, then only tablespaces created with 10.2 compatibility are optimized to exclude blocks that do not currently contain data. If COMPATIBLE is set to 11.0.0 or higher, however, then the first backup that produces backup sets after COMPATIBLE is set to 11.0.0 or higher updates the headers of all locally managed data files so that all locally managed data files can be optimized.
There are currently no guaranteed restore points defined for the database.
The data file is locally managed
The data file is being backed up to a backup set as part of a full backup or a level 0 incremental backup
The backup set is created on disk or Oracle Secure Backup is the media manager.
Note: When backing up to a media manager that is not Oracle Secure Backup, RMAN copies all the blocks regardless of whether they contain data or not.
Note: A corrupt unused block is not harmful. This is because when a block is corrupt and RMAN does not read it because of unused block compression, RMAN does not detect the corruption.
See Also: Oracle Backup and Recovery User's Guide for a discussion of null block compression and unused block compression.
Each backup set contains at least one backup piece, which is an RMAN-specific physical file containing the backed up data. You can also use the BACKUP command to generate a proxy copy, which is a backup in which the entire data transfer is conducted by a media manager.
RMAN only records complete backup sets in the RMAN repository. There are no partial backup sets. When a BACKUP command creates backup pieces but does not produce a complete backup set, the backup pieces are discarded.
Note: You cannot stripe a single backup set across multiple channels. You also cannot stripe a single input file across multiple backup sets.
========================================================================================
Compressed
Enables binary compression.
RMAN compresses the data written into the backup set to reduce the overall size of the backup set. All backups that create backup sets can create compressed backup sets. Restoring compressed backup sets is no different from restoring uncompressed backup sets.
RMAN applies a binary compression algorithm as it writes data to backup sets. This compression is similar to the compression provided by many media manager vendors. When backing up to a locally attached tape device, compression provided by the media management vendor is usually preferable to the binary compression provided by BACKUP AS COMPRESSED BACKUPSET. Therefore, use uncompressed backup sets and turn on the compression provided by the media management vendor when backing up to locally attached tape devices. You should not use RMAN binary compression and media manager compression together.
Some CPU overhead is associated with compressing backup sets. If the target database is running at or near its maximum load, then you may find the overhead unacceptable. In most other circumstances, compressing backup sets saves enough disk space to be worth the CPU overhead.
================================================================================
Encryption of Backup Sets
RMAN can transparently encrypt data written to backup sets and decrypt those backup sets when they are needed in a RESTORE operation. To create encrypted backups on disk, the database must use the Advanced Security Option. To create encrypted backups directly on tape, RMAN must use the Oracle Secure Backup SBT interface, but does not require the Advanced Security Option. RMAN issues an ORA-19916 error if you attempt to create encrypted RMAN backups using an SBT library other than Oracle Secure Backup.
RMAN can encrypt backups by using several different encryption algorithms, which are listed in V$RMAN_ENCRYPTION_ALGORITHMS. RMAN supports three modes of encryption for backups:
Transparent encryption, in which RMAN can create and restore encrypted backups with no special DBA intervention, if the required Oracle public key infrastructure (PKI) is available
Password-based encryption, where a password is specified during the backup, and the same password must be supplied to restore the backup
Dual-mode encryption, where backups can be created using either as with transparent encryption or password-based encryption, and where decryption can be performed based upon either the Oracle Wallet, or a password the DBA supplies at decryption time
=================================================================================
Backing Up Standby Databases
The RMAN BACKUP command backs up the standby database exactly the same as a primary database, except that the backup takes place on the standby site. The primary database has no influence on the backup of the standby database.
When you connect to the standby database to perform the backup, use the TARGET keyword and not the AUXILIARY keyword.
The state of the standby database when the backup is made determines whether the backup is consistent or inconsistent. To make a consistent backup, the standby database must shutdown cleanly and be mounted, but not placed in recovery mode. Any other status results in an inconsistent backup and must be restored using media recovery.
==================================================================================
Configuring Compressed Backupsets as Default for Tape or Disk
You can configure RMAN to use compressed backupsets by default on a particular device type, by using the CONFIGURE DEVICE TYPE command with the BACKUP TYPE TO COMPRESSED BACKUPSET option, as shown in the following examples.
The following commands let you set the default backup type to compressed backup sets for different device types:
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;
https://docs.oracle.com/cd/B14117_01/server.101/b10735/setup.htm
================================================================================
Important details on FRA
http://satya-dba.blogspot.in/2009/02/flash-recovery-area.html
Programming is Fun 