Showing posts with label RMAN. Show all posts
Showing posts with label RMAN. Show all posts

Wednesday, May 29, 2019

Avamar rman backup generates large amount of trace files

Avamar RMAN Backup Trace Files Management

When performing RMAN backups using Avamar, it is common to observe the generation of a large number of trace files. These trace files can consume significant disk space and may not always be necessary for routine operations. This document outlines common methods to manage and reduce the generation of these trace files.

1. Avamar GUI Configuration

The primary method to control trace file generation from the Avamar side is through its graphical user interface (GUI).

  • Action: The Avamar team (or administrator) needs to set the tracing level to 'TRACE 0' within the Avamar GUI for the relevant RMAN backup policies or configurations.

  • Impact: Setting TRACE 0 typically disables detailed tracing, significantly reducing the volume of trace files generated by the Avamar client during RMAN operations.

2. Oracle Database Event Setting

Database administrators (DBAs) can configure an Oracle database event to disable specific kernel-related tracing, which often contributes to the generation of numerous trace files during backup operations.

Permanent Fix (Requires Database Restart)

To make the change persistent across database restarts, set the event in the SPFILE.

  • Command:

    ALTER SYSTEM SET EVENT='trace[krb.*] disk disable, memory disable' SCOPE=SPFILE SID='*';
    
    
  • Explanation:

    • trace[krb.*]: Targets tracing related to the krb (kernel resource broker) component, which is often involved in backup and recovery processes.

    • disk disable: Prevents trace information from being written to disk.

    • memory disable: Prevents trace information from being stored in memory.

    • SCOPE=SPFILE: Ensures the change is written to the server parameter file and will persist after a database restart.

    • SID='*': Applies the change to all instances in a Real Application Clusters (RAC) environment. For a single instance, you can omit SID='*' or specify the instance SID.

  • Effectiveness: This change will take effect only after a full database restart.

Temporary Fix (No Database Restart Required)

For an immediate, temporary reduction in trace file generation without a database restart, the event can be set at the session or system level without SCOPE=SPFILE.

  • Command:

    ALTER SYSTEM SET EVENT='trace[krb.*] disk disable, memory disable';
    
    
  • Explanation:

    • This command applies the event setting to the current running instance(s) immediately.

    • Limitation: This change is not persistent across database restarts. If the database is restarted, this command would need to be re-executed.

By implementing both the Avamar GUI setting and the Oracle database event, you can effectively manage and significantly reduce the large amount of trace files generated during Avamar RMAN backup operations. Both steps are generally recommended for comprehensive trace file management.

Tuesday, May 2, 2017

RMAN LEVEL 0 , LEVEL 1 and Arch Backup & restore script [Networker]

Oracle RMAN Backup and Restore Examples

This document provides practical examples of RMAN (Recovery Manager) scripts for performing various backup and restore operations in an Oracle Database environment. These examples cover full database backups, incremental backups, archive log backups, and database restores to a point in time.

RMAN Backup Examples

1. Full/Level 0 Incremental Backup to Tape (SBT_TAPE) with Archive Log Backup and Deletion

This script performs a Level 0 incremental backup of the database, including the current control file, to tape. It then archives the current log, crosschecks existing archive logs, backs up archive logs not yet backed up to tape, and finally deletes archive logs that have been backed up at least once to tape and are older than 1/24th of a day (2.5 minutes).

RUN {
  ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE';
  ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE';
  ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE';
  ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE';

  -- Perform a Level 0 incremental backup of the database
  -- filesperset 1: Each backup set will contain only one datafile.
  -- format: Defines the naming convention for backup pieces.
  -- include current controlfile: Ensures the latest control file is part of the backup.
  backup incremental level 0 filesperset 1 format '%d_LEVEL0_%s_%t_%p.dbf' database include current controlfile;

  -- Force an archive log switch to ensure all committed transactions are in an archive log.
  sql 'alter system archive log current';

  -- Crosscheck archive logs to update their status in the RMAN catalog (e.g., AVAILABLE/EXPIRED).
  change archivelog all crosscheck;

  -- Backup archive logs that have not been backed up at least once to tape.
  backup NOT BACKED UP 1 TIMES archivelog all filesperset 1 format '%d_arch_%s_%t_%p.arc';

  -- Delete archive logs that have been backed up at least once to tape and are older than 2.5 minutes.
  DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-1/24';

  -- Release the allocated channels.
  RELEASE CHANNEL CH1;
  RELEASE CHANNEL CH2;
  RELEASE CHANNEL CH3;
  RELEASE CHANNEL CH4;
}

2. Archive Log Backup and Deletion to Tape (SBT_TAPE)

This script focuses solely on backing up and deleting archive logs to tape. It's often run more frequently than full database backups.

RUN {
  ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE' ;
  ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE' ;
  ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE' ;
  ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE' ;

  -- Crosscheck archive logs to update their status in the RMAN catalog.
  change archivelog all crosscheck;

  -- Backup archive logs that have not been backed up at least once to tape.
  backup NOT BACKED UP 1 TIMES archivelog all filesperset 1 format '%d_arch_%s_%t_%p.arc' ;

  -- Delete archive logs that have been backed up at least once to tape and are older than 2.5 minutes.
  -- NOPROMPT: Suppresses the confirmation prompt for deletion.
  DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-1/24';

  -- Release the allocated channels.
  RELEASE CHANNEL CH1;
  RELEASE CHANNEL CH2;
  RELEASE CHANNEL CH3;
  RELEASE CHANNEL CH4;
}

3. Level 1 Incremental Backup to Disk (Compressed)

This example performs a Level 1 incremental backup (only blocks changed since the last Level 0 or Level 1 backup) to disk, with compression.

run {
  -- Allocate disk channels. Note: Each channel should ideally have a unique format string
  -- if you intend to write to different physical locations or distinct backup pieces.
  -- The example below uses the same format for all, which might overwrite or lead to issues
  -- if not managed carefully (e.g., using %U for unique filenames).
  ALLOCATE CHANNEL backup_disk1 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf';
  ALLOCATE CHANNEL backup_disk2 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf'; -- Corrected channel name
  ALLOCATE CHANNEL backup_disk3 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf'; -- Corrected channel name
  ALLOCATE CHANNEL backup_disk4 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf'; -- Corrected channel name

  -- Perform a Level 1 incremental backup.
  -- as compressed backupset: Enables compression for the backup.
  -- filesperset 1: Each backup set contains one datafile.
  -- tag: Assigns a tag to the backup set for easier identification.
  -- include current controlfile: Includes the control file in the backup.
  backup as compressed backupset incremental level 1
  filesperset 1 tag  'TEST_STANDARD_LEVEL1'  database include current controlfile;

  -- Release the allocated channels.
  RELEASE CHANNEL backup_disk1;
  RELEASE CHANNEL backup_disk2; -- Corrected channel name
  RELEASE CHANNEL backup_disk3; -- Corrected channel name
  RELEASE CHANNEL backup_disk4; -- Corrected channel name
}

Correction Note: In the original allocate channel commands for disk backup, all channels were named backup_disk1. For parallel operation, they should be distinct (e.g., backup_disk1, backup_disk2, etc.) and released accordingly. The example above has been corrected for clarity.

RMAN Restore Examples

1. Restoring Control File from Tape (SBT_TAPE)

This script is used to restore the control file from a tape backup. This is typically done when the control file is lost or corrupted, and the database cannot be mounted.

run
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt_tape;

  -- Send environment variables to the media management software (MMS).
  -- NSR_SERVER, NSR_CLIENT, NSR_DATA_VOLUME_POOL are NetWorker specific variables.
  send 'NSR_ENV=(NSR_SERVER=*****,NSR_CLIENT=*****,NSR_DATA_VOLUME_POOL=*****)'; -- Replace with actual values

  -- Restore the control file using its backup piece name or tag.
  restore controlfile from 'MYSID_c-569933170-20171012-03'; -- Replace with actual backup piece name/tag

  RELEASE CHANNEL ch1;
}

2. Full Database Restore to a Point in Time (using Shell Script)

This section shows how to automate a full database restore to a specific point in time using a shell script to invoke RMAN.

invoke_restore_MYSID.ksh (Shell Script):

export ORACLE_SID=MYSID # Set the Oracle SID
export ORACLE_HOME=/applic/oracle/product/11.2.0/dbhome_1 # Set the Oracle Home
export PATH=$PATH:$ORACLE_HOME/bin # Add Oracle binaries to PATH

# Execute RMAN, targeting the database, logging output, and using a command file.
rman target / log=MYSID_restore_$(date '+%Y%m%d_%H%M%S').log cmdfile=restore_MYSID.rcv

restore_MYSID.rcv (RMAN Command File for Restore):

run
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch2 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch3 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch4 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch5 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch6 DEVICE TYPE sbt_tape;

  -- Set the point in time for the restore operation.
  set until time "to_date('10/12/2017 15:01:39', 'mm/dd/yyyy hh24:mi:ss')";

  -- Send environment variables to the media management software (MMS).
  send 'NSR_ENV=(NSR_SERVER=*****,NSR_CLIENT=*****,NSR_DATA_VOLUME_POOL=*****)'; -- Replace with actual values

  -- Set new names for datafiles if relocating the database or restoring to a different storage.
  -- This example sets all datafiles to an ASM diskgroup named +DATA_DG.
  set newname for database to '+DATA_DG';

  -- Restore the entire database.
  restore database;

  -- Update the control file with the new datafile locations after restore.
  switch datafile all;

  RELEASE CHANNEL ch1;
  RELEASE CHANNEL ch2;
  RELEASE CHANNEL ch3;
  RELEASE CHANNEL ch4;
  RELEASE CHANNEL ch5;
  RELEASE CHANNEL ch6;
}

3. Database Recovery to a Point in Time (using Shell Script)

This script is used after a database restore to apply archive logs and recover the database to the specified point in time.

recover_MYSID.rcv (RMAN Command File for Recover):

run
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch2 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch3 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch4 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch5 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch6 DEVICE TYPE sbt_tape;

  -- Set the point in time for the recovery operation. This must match the restore point.
  set until time "to_date('10/12/2017 15:01:39', 'mm/dd/yyyy hh24:mi:ss')";

  -- Send environment variables to the media management software (MMS).
  send 'NSR_ENV=(NSR_SERVER=*****,NSR_CLIENT=*****,NSR_DATA_VOLUME_POOL=*****)'; -- Replace with actual values

  -- Recover the database by applying necessary archive logs.
  recover database;

  RELEASE CHANNEL ch1;
  RELEASE CHANNEL ch2;
  RELEASE CHANNEL ch3;
  RELEASE CHANNEL ch4;
  RELEASE CHANNEL ch5;
  RELEASE CHANNEL ch6;
}

4. Restore Specific Archive Log Range

This command can be used to restore a specific range of archive logs.

restore archivelog from logseq 330570 until logseq 330590;

This restores archive logs with sequence numbers from 330570 up to (and including) 330590.

Saturday, April 12, 2014

Parallel Backup of the Same Datafile (Intrafile parallel backup)

RMAN Intrafile Parallel Backup (SECTION SIZE)

This document describes the concept of Intrafile Parallel Backup in Oracle Recovery Manager (RMAN), specifically focusing on the SECTION SIZE feature, which allows for parallel backup of a single large datafile.

Understanding Intrafile Parallel Backup

Traditionally, when you allocate multiple channels in RMAN, each channel backs up a separate datafile. This means that even with several channels, a single large datafile is still backed up by only one channel at a time, which might not fully utilize the parallel capabilities of your backup infrastructure.

Starting with Oracle Database 11g RMAN, the concept of Intrafile Parallel Backup was introduced. This allows RMAN channels to break a single large datafile into smaller, independent units called "sections." Each section can then be backed up concurrently by a different channel, truly parallelizing the backup of a single large file.

How SECTION SIZE Works

The SECTION SIZE clause in the RMAN BACKUP command allows you to specify the maximum size of each section. RMAN will then divide the datafile into chunks of this specified size, and each chunk can be processed by an available channel in parallel.

Example RMAN Command

Here's an example demonstrating how to use SECTION SIZE to back up a large datafile in parallel:

RMAN> run {
2>      allocate channel c1 type disk format '/backup1/%U';
3>      allocate channel c2 type disk format '/backup2/%U';
4>      backup
5>      section size 500m
6>      datafile 6;
7> }

Explanation:

  • allocate channel c1 type disk format '/backup1/%U'; and allocate channel c2 type disk format '/backup2/%U';: These commands allocate two disk channels, c1 and c2, and specify their respective backup destinations (/backup1 and /backup2).

  • backup section size 500m datafile 6;: This is the core command. It instructs RMAN to back up datafile 6. The SECTION SIZE 500m clause tells RMAN to divide datafile 6 into 500MB sections. Each of these sections will then be backed up concurrently by the allocated channels (c1 and c2).

This setup allows for a significant speedup when backing up very large individual datafiles, as multiple channels can work on different parts of the same file simultaneously.

Listing Backed-Up Sections

When a datafile is backed up using SECTION SIZE, the backup pieces reflect these sections.

RMAN> list backup of datafile 6;

Example Output:

...
...
    List of Backup Pieces for backup set 901 Copy #1
    BP Key  Pc# Status      Piece Name
    -------    ---  -----------      ----------
    2007    1   AVAILABLE   /backup1/9dhk7os1_1_1
    2008    2   AVAILABLE   /backup2/9dhk7os1_1_1
    2009    3   AVAILABLE   /backup1/9dhk7os1_1_3
    2009    3   AVAILABLE   /backup2/9dhk7os1_1_4

Notice how the backup pieces (/backup1/9dhk7os1_1_1, /backup2/9dhk7os1_1_1, etc.) correspond to different sections of the datafile. Since each section can go to a different channel, you can direct them to different mount points (like /backup1 and /backup2 in the example), enabling parallel writing to disk or even tape.

Important Consideration for Disk Performance

While SECTION SIZE offers great parallelization benefits, it's crucial to consider the underlying storage.

  • No Advantage on Single Disk: If the large datafile resides entirely on a single physical disk, there is generally no performance advantage to using parallel backups with SECTION SIZE. In such a scenario, the disk head would have to constantly move back and forth to access different sections of the file, which can outweigh the benefits of parallel processing and actually degrade I/O performance.

  • Benefit with Striped/Multiple Disks: The true benefit of SECTION SIZE comes when the large datafile is spread across multiple physical disks (e.g., via RAID, ASM, or striped file systems) or when the backup pieces are written to different physical backup destinations. This allows the parallel I/O operations to be truly concurrent.

Thursday, April 10, 2014

RMAN LEVEL 0 Backup

RUN {
ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE'; 
ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE'; 
ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE'; 
ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE';  
backup incremental level 0 filesperset 1 format '%d_LEVEL0_%s_%t_%p.dbf' database include current controlfile; 
sql 'alter system archive log current'; 
change archivelog all crosscheck; 
backup NOT BACKED UP 1 TIMES archivelog all  filesperset 1 format '%d_arch_%s_%t_%p.arc';
DELETE ARCHIVELOG ALL  BACKED UP 1 TIMES TO DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-1/24';
RELEASE CHANNEL CH1; 
RELEASE CHANNEL CH2; 
RELEASE CHANNEL CH3; 
RELEASE CHANNEL CH4;  
}

Friday, November 1, 2013

RMAN new features

9i 

CONFIGURE BACKUP OPTIMIZATION ON 

10G

Fast Incremental Backups (Block Change Tracking)

Cataloging Backup Pieces

Automatic Instance Creation for RMAN TSPITR

Backupset Compression

Restore Preview

Automatic Datafile Creation 

11G

Improved Integration with Data Guard

Archived Log Deletion Policy Enhancements

Network-Enabled Database Duplication Without Backups

Recovery Catalog Enhancements (virtual private catalog)


IMPORT CATALOG

Archived Redo Log Failover

Undo Optimization

Improved Block Media Recovery Performance

Block Change Tracking Support for Standby Databases

Backup of Read-Only Transportable Tablespaces