rman incremental merge 增量备份自动合并 不再需要做多次0级备份

本文主要是介绍rman incremental merge 增量备份自动合并 不再需要做多次0级备份,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

There are several ways to use a Merged Incremental Backup Strategy. However, before implementing the strategy, there are several things to consider when not using the basic Oracle Suggested Strategy as given in EM.  This note will cover the different ways to implement your strategy tailored to fit your business needs.

What is a Merged Incremental Backup?

Merged Incremental creates a level 0 image copy backup of all of your database's datafiles in a disk location.  All datafiles are backed up using the same tag name. The Oracle Database 10g feature Block Change Tracking can be used for the incremental level 1 backups for Fast Incremental Backups.

Once a level 0 backup copy is created on disk there is no need for future level 0 backups to be taken.  This reduces the load and backup window for VLDB systems. All future backups will be level 1 backupsets and are used to recover the image copies on disk thus making the current level 0 image backup copies more current each time the level 1 incremental is applied.  Having the level 0 image copy newer with each level 1 incremental backupsets means there is no need to make another level 0 backup/image copy of your database. 

SOLUTION

First let look at the Enterprise Manager Merged Incremental "Oracle-Suggested Strategy".

Daily Script:
run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA$OEM_LEVEL_0';
backup incremental level 1 copies=1 for recover of copy with tag 'ORA$OEM_LEVEL_0' database;
}

By default the Merged Incremental Strategy creates differential incremental backups. If there are no level 0 copies then the first execution will make level 0 datafile copy backups to the specified location or to the Flash Recovery Area if one is defined in the parameter file of the database.

With the default EM script the image copies will always be 24 hours behind the current incremental backup taken. If the business requires that you keep the image backup more current you can change the recover command to be executed after the backup command so the most current changes are applied to the image copies.

Default behavior for Merged Incremental Backups

First Execution, Day 1:  The 'recover copy' command will show ' no copy of datafile 1 found to recover' as this is the first execution and   no  level 0 backup existing.   The 'backup incremental....' command will make a new level 0 copy as there is no existing level 0.

Second Execution, Day 2:  The 'recover copy' command will show 'no copy of datafile 1 found to recover' as there  is still no previous level 1 backup.  The 'backup incremental...' command will create a level 1 datafile backupset.

Third Execution, Day 3:  The 'recover copy' command will recover the level 0 image copy and displays 'recovering datafile copy fno=....'.   不是recover 生产database的数据

The 'backup incremental....' command will create a new level 1 datafile backupset.   



Future Executions:  Each backup taken after the 3rd should show the same behavior as in backup on Day 3.

The following is an example of making the Merged Incremental Backups so the image copies remain 24 hours behind the incremental backups taken.  This is the same as one described above through EM.  

run {
recover copy of database with tag 'MIB_LEVEL_0';
backup incremental level 1 copies=1 for recover of copy with tag 'MIB_LEVEL_0' database;
}

In this example, the backup and recover commands are flipped.  The backup is taken before the recover statement.  The recover command will apply the most recent level 1 backup.  Thus the image copy backups have the incremental backup applied to them directly after they're taken. This keeps the image copies most current and can be executed several times a day according to your business requirements.

run {
backup incremental level 1 copies=1 for recover of copy with tag 'MIB_LEVEL_0' database;
recover copy of database with tag 'MIB_LEVEL_0';
}

If there is not enough space in the Flash Recovery Area or on a single mount to make image copies of the  entire database, they can be spread across multiple disk mounts. To do this, the initial level 0 image copy must be executed manually. For example, the following performs a backup by tablespace written to different mount points. The key is is using the same tag for backup then again for subsequent recovery commands.

run {
backup as copy incremental level 0 format '/<path>/<mount1>/%U' tag 'MIB_LEVEL_0'
tablespace SYSTEM, UNDOTBS1;
backup as copy incremental level 0 format '/<path>/<mount2>/%U' tag 'MIB_LEVEL_0'
tablespace SYSAUX, USERS;
backup as copy incremental level 0 format '/<path>/<mount3>/%U' tag 'MIB_LEVEL_0'
tablespace <user tablespace name separated by comma>;
 }

After the level 0 image copy backup is created to the respective mount points, the daily script to create incremental backupsets to recover the image copies can be executed. Although the image copies are on different mount points, their use of the same tag will cause RMAN to find the most recent copy with the respective tag to apply the recovery.

It should be noted, that in this case, it is the DBA's responsibility to maintain/take Incremental Level 0 Backups if for example NEW TABLESPACES or DATAFILES are added to the Database. Of course the RMAN Incremental Level 1 Backups will do automatically a Incremental Level 0 Backup if there is none available, but then this automatically created Incremental Level 0 Backup does not go to one of the Destination Mount Points, but to a DEFAULT Location i.e. FRA or $ORACLE_HOME/dbs is FRA is not specified.

run {
backup incremental level 1 for recover of copy with tag 'MIB_LEVEL_0' database;
recover copy of database with tag 'MIB_LEVEL_0';
 }

When using the Oracle-Suggested Strategy or daily Merged Incremental Backup and using a Flash Recovery Area then keep the RMAN Retention Policy set for Redundancy 1.

This will ensure that Oracle space management will automatically remove the level 1 incremental backups from the FRA after they have been applied to the image copy based on space pressure in the FRA. If you increase the redundancy or set a Recovery Window the space will no longer be automatically reclaimed by Oracle. This works only when retention policy is set to the default of redundancy=1. If the configured retention policy is set  to recovery window or to a redundancy > 1, then RMAN cannot satisfy the retention policy if there is only one copy of database and it is at a later point in time. So, in order to satisfy the retention policy Oracle keeps all the incrementals and archivelogs since database creation because ideally a datafile can be re-created and archivelogs can be applied to satisfy the retention policy (though not followed in practical case).

Review:  
Merged Incremental Backup & Backup Retention (Doc ID 351455.1)

When the business requires a retention policy to recovery window of 7 days.  The retention policy can be configured as such by the user. In addition, a customized script using a UNTIL CLAUSE of 8 days must be created.  This will keep the copy of the database to at least 8 days older. This will satisfy the retention policy and make the archivelogs and incremental delete-able from FRA.

Another image copy can be made back to lag the recover using 'SYSDATE-x' for the 'recover the copy' command.  The only caveat is the tag being used and another incremental backup is required using the tag for the copy you wish to recover.

 RECOVER COPY OF DATABASE WITH TAG 'MIB_LEVEL_0' UNTIL TIME "SYSDATE-8" FROM TAG 'MIB_LEVEL_0';

This would keep the copy of database to satisfy the retention policy of 7 days.

Block Change Tracking and Merged Incrementals

If using BCT Block Change Tracking for the level 1 incremental backups you must note the BCT file will only allow up to 8 bitmaps by default. So it can only trace 8 days or 8 incremental backups between each recover command.

 The limit can be increased using the underscore parameter listed in Note: 452455.1

A database with Block Change Tracking enabled and if more than 8 RMAN incremental backups are executed without consolidating them into image copies, then the backup process will be very slow since the Block Change Tracking won't be used in subsequent backups.

The limit is set by the "_bct_bitmaps_per_file" parameter. This parameter sets the number of bitmaps to be stored for each datafile, and its default value is 8. In order to avoid this limit one can either run less than 8 incremental backups or can increase the "_bct_bitmaps_per_file" parameter.

Note:
Verified by Documentation checking clause "FOR RECOVER OF COPY"
to find DEFAULT used for INCREMENTAL MERGE Backup:
.
10gR2: "FOR RECOVER OF COPY" Incremental Merge Backups are by default CUMULATIVE.   (up to a including 10.2.0.4 )
11gR1: "FOR RECOVER OF COPY" Incremental Merge Backups are by default CUMULATIVE.   (up to a including 11.1.0.7 )
11gR2: "FOR RECOVER OF COPY" Incremental Merge Backups are by default DIFFERENTIAL.  >= 11.2.
---------

Reference:
(Doc ID 6459358.8) Bug 6459358 - Differential incremental backups not created for "RECOVER OF COPY WITH TAG"
 Versions confirmed as being affected     
    11.1.0.7
    10.2.0.4
 This issue is fixed in    
    11.2.0.1 (Base Release)
    10.2.0.5 (Server Patch Set)
    10.2.0.4 Patch 32 on Windows Platforms

PURPOSE

To understand and use oracle recommended strategy (incremental merge) for disk only backups to achieve a recovery window of N days.

This note is essentially written to clarify bug# 3826979.

SCOPE

All users of RMAN that have the need of backing up the database to disk only and may use flash recovery area. 

DETAILS

 1.Disk Backup Strategy

The Oracle recommended disk backup strategy is to have:
  a) retention policy is redundancy 1
  b) create a copy of database on disk in flash recovery area
  c) take cumulative incrementals over this copy
  d) rollforward the copy of database daily

To achieve this...

a) configure retention policy once

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

b, c & d)

The backup script would be like:

run {
 recover copy of database with tag 'ORA_BACKUP';
 backup incremental level 1 Tag 'ORA_BACKUP' for recover of copy Tag 'ORA_BACKUP' database;
}

The first command roll forwards the copy of database with tag ORA_BACKUP to latest point in time by applying incrementals over the backup.

The second command creates an incremental backup with parent as copy of database with tag ORA_BACKUP. If there is no copy of database with tag ORA_BACKUP, then it will create a copy.

  Timeline      first command                       second command
  ========      =============                       ==============
  Day 1         no copy of rollforward              creates a copy of database
  Day 2         no incr to be applied               creates incremental
  Day 3         copy roll forwarded through Day2    creates incremental --- 第三天增量合并,可以恢复到前天
  Day 4         copy roll forwarded through Day3    creates incremental--- 只可以恢复到昨天,如果交换顺序只能当天。
  ...


As you can see that the above script will make the copy one day older at given time. Hence, the script is good to attain a recovery window of 1 days assuming the script is executed every night.
 

2. How to obtain recovery window of N days using disk backup strategy?

Now instead of attaining 1 day recovery window on disk, user may wish to achieve a recovery window of N days. For example, assume user want a recovery window of 15 days.

There are two changes that needed to be done -
  a) change retention policy to recovery window of 15 days;
  b) change backup script to keep copy 15 days older

To achieve this...


a) configure the retention policy once:

RMAN> configure retention policy to recovery window of 15 days;

This configuration is optional. We can obtain recovery window of 15 days with redundancy 1 and using below script. The advantage of changing the configuration is to make sure that RMAN doesn't mark any tape backups (if any) as obsolete that are require to attain 15 day recovery window.


b) The backup script is similar to the below:

     run {
        recover copy of database with tag ORA_BACKUP until time 'sysdate - 16';
        backup device type disk incremental level 1 for recover of copy with TAG ORA_BACKUP database;
     }
 

 We use one day more as 'sysdate-16' to take care of daylight savings.

The first command roll forwards the copy of database with tag ORA_BACKUP to a point in time 16 days older by applying incrementals over the backup.

The second command creates an incremental backup with parent as copy of database with tag ORA_BACKUP. If there is no copy of database with tag ORA_BACKUP, then it will create a copy.

  Timeline      first command                       second command
  ========      =============                       ==============
  Day 1         no copy of rollforward              creates a copy of database
  Day 2         no incr to applied                  creates incremental
  ...
  Day 15        no incr to applied                  creates incremental
  Day 16        copy roll forwarded through Day2    creates incremental------15天内的增量都在,0级还是15天前的。
  Day 17        copy roll forwarded through Day3    creates incremental
  ...


As you can see you can achieve a recovery window of 15 days on disk.

这篇关于rman incremental merge 增量备份自动合并 不再需要做多次0级备份的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/450342

相关文章

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

hdu2241(二分+合并数组)

题意:判断是否存在a+b+c = x,a,b,c分别属于集合A,B,C 如果用暴力会超时,所以这里用到了数组合并,将b,c数组合并成d,d数组存的是b,c数组元素的和,然后对d数组进行二分就可以了 代码如下(附注释): #include<iostream>#include<algorithm>#include<cstring>#include<stack>#include<que

业务中14个需要进行A/B测试的时刻[信息图]

在本指南中,我们将全面了解有关 A/B测试 的所有内容。 我们将介绍不同类型的A/B测试,如何有效地规划和启动测试,如何评估测试是否成功,您应该关注哪些指标,多年来我们发现的常见错误等等。 什么是A/B测试? A/B测试(有时称为“分割测试”)是一种实验类型,其中您创建两种或多种内容变体——如登录页面、电子邮件或广告——并将它们显示给不同的受众群体,以查看哪一种效果最好。 本质上,A/B测

day-51 合并零之间的节点

思路 直接遍历链表即可,遇到val=0跳过,val非零则加在一起,最后返回即可 解题过程 返回链表可以有头结点,方便插入,返回head.next Code /*** Definition for singly-linked list.* public class ListNode {* int val;* ListNode next;* ListNode() {}*

负债不再是障碍?银行信贷“白名单“揭秘

谈及银行信贷产品,常闻有言称存在无需考量负债与查询记录之奇品,此等说法十有八九为中介诱人上钩之辞。轻信之下,恐将步入连环陷阱。除非个人资质出类拔萃,如就职于国央企或事业单位,工龄逾年,五险一金完备,还款能力卓越,或能偶遇线下产品对查询记录稍显宽容,然亦非全然无视。宣称全然不顾者,纯属无稽之谈。 银行非慈善机构,不轻易于困境中援手,更偏爱锦上添花之举。若无坚实资质,即便求助于银行亦难获青睐。反

基于51单片机的自动转向修复系统的设计与实现

文章目录 前言资料获取设计介绍功能介绍设计清单具体实现截图参考文献设计获取 前言 💗博主介绍:✌全网粉丝10W+,CSDN特邀作者、博客专家、CSDN新星计划导师,一名热衷于单片机技术探索与分享的博主、专注于 精通51/STM32/MSP430/AVR等单片机设计 主要对象是咱们电子相关专业的大学生,希望您们都共创辉煌!✌💗 👇🏻 精彩专栏 推荐订阅👇🏻 单片机

rman compress

级别         初始         备完    耗时    low          1804       3572    0:10     High         1812       3176   2:00     MEDIUM  1820       3288    0:13    BASIC      1828   3444    0:56 ---不如MEDIUM,

【每日一题】LeetCode 2181.合并零之间的节点(链表、模拟)

【每日一题】LeetCode 2181.合并零之间的节点(链表、模拟) 题目描述 给定一个链表,链表中的每个节点代表一个整数。链表中的整数由 0 分隔开,表示不同的区间。链表的开始和结束节点的值都为 0。任务是将每两个相邻的 0 之间的所有节点合并成一个节点,新节点的值为原区间内所有节点值的和。合并后,需要移除所有的 0,并返回修改后的链表头节点。 思路分析 初始化:创建一个虚拟头节点

Python3 BeautifulSoup爬虫 POJ自动提交

POJ 提交代码采用Base64加密方式 import http.cookiejarimport loggingimport urllib.parseimport urllib.requestimport base64from bs4 import BeautifulSoupfrom submitcode import SubmitCodeclass SubmitPoj():de

【Python从入门到进阶】64、Pandas如何实现数据的Concat合并

接上篇《63.Pandas如何实现数据的Merge》 上一篇我们学习了Pandas如何实现数据的Merge,本篇我们来继续学习Pandas如何实现数据的Concat合并。 一、引言 在数据处理过程中,经常需要将多个数据集合并为一个统一的数据集,以便进行进一步的分析或建模。这种需求在多种场景下都非常常见,比如合并不同来源的数据集以获取更全面的信息、将时间序列数据按时间顺序拼接起来以观察长期趋势等