Home Database Mysql Tutorial 聊聊RMAN的ARCHIVELOG DELETION参数

聊聊RMAN的ARCHIVELOG DELETION参数

Jun 07, 2016 pm 02:54 PM

RMAN是Oracle推出的官方备份还原工具。经过几个大版本的发展,RMAN已经支持多种备份介质和恢复策略的主要工具,也是业界普遍认可

RMAN是Oracle推出的官方备份还原工具。经过几个大版本的发展,RMAN已经支持多种备份介质和恢复策略的主要工具,也是业界普遍认可是Oracle备份还原官方策略。

Archivelog是Oracle备份还原策略的重要组成元素,不完全备份+连续的归档日志可以让我们将数据库恢复到发生故障点,实现数据的无损失恢复。但是,现实生活中archive log给没有经验的运维人员也带来了不少的问题,归档空间占满引起Hang住、瞬间归档日志过多生成引起问题等。一些前辈也在不断强调“归档模式不美好”。

在RMAN工作参数中,针对archive log,是可以设置专门的删除策略(Deletion)。在实践领域中,已经备份过或者确保安全传输的归档日志,其实就可以删除了,特别是在有限的Fast Recovery Area管理模式下。对于自动删除archive log的策略,比较常见的是applied to standby和shipped to standby,也就是Data Guard场景下。

本篇介绍简单的backed up参数使用情况,并通过一系列实验去研究该参数影响下Oracle和RMAN的工作行为特性。

1、基本参数和实验环境

笔者使用Oracle 11gR2进行测试,具体版本编号为11.2.0.4。

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

PL/SQL Release 11.2.0.3.0 - Production

CORE    11.2.0.3.0    Production

TNS for Linux: Version 11.2.0.3.0 - Production

NLSRTL Version 11.2.0.3.0 – Production

默认情况下,archivelog deletion policy参数为NONE。

RMAN> show all;     

RMAN configuration parameters for database with db_unique_name XXXXDB are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

(篇幅原因,有省略……)

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

该参数常见的集中取值如下:

configure archivelog deletion policy to backed up 2 times to sbt;

configure archivelog deletion policy to backed up 1 times to device type disk;

configure archivelog deletion policy to applied on standby;  --DG专用

configure archivelog deletion policy to shipped on standby;  --DG专用

configure archivelog deletion policy clear;

研究archivelog行为最好的工具视图是v$archived_log。很多DBA喜欢从操作系统层面删除归档日志,但是这种方式是不会直接被Oracle控制文件认可,所以建议使用RMAN或者官方工具来做。

--已归档未删除日志

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

13

2、第一轮备份测试实验

首先我们修改archivelog deletion policy参数,设置为“两次备份后即可以删除”。

RMAN> configure archivelog deletion policy to backed up 2 times to device type disk;

new RMAN configuration parameters:

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;

new RMAN configuration parameters are successfully stored

手工备份数据库和归档日志,不进行删除动作。

RMAN> backup database plus archivelog;

Starting backup at 21-SEP-15

current log archived

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=16 device type=DISK

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=100 RECID=12 STAMP=890690423

input archived log thread=1 sequence=101 RECID=13 STAMP=890712061

input archived log thread=1 sequence=102 RECID=14 STAMP=890727732

input archived log thread=1 sequence=103 RECID=15 STAMP=890776815

input archived log thread=1 sequence=104 RECID=16 STAMP=890776833

input archived log thread=1 sequence=105 RECID=17 STAMP=890805616

input archived log thread=1 sequence=106 RECID=18 STAMP=890814181

input archived log thread=1 sequence=107 RECID=19 STAMP=890820201

input archived log thread=1 sequence=108 RECID=20 STAMP=890859629

input archived log thread=1 sequence=109 RECID=21 STAMP=890892046

input archived log thread=1 sequence=110 RECID=22 STAMP=890900632

input archived log thread=1 sequence=111 RECID=23 STAMP=890906655

input archived log thread=1 sequence=112 RECID=24 STAMP=890942416

input archived log thread=1 sequence=113 RECID=25 STAMP=890990204

channel ORA_DISK_1: starting piece 1 at 21-SEP-15

channel ORA_DISK_1: finished piece 1 at 21-SEP-15

piece handle=/u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_annnn_TAG20150921T091644_bzypmwty_.bkp tag=TAG20150921T091644 

(篇幅原因,省略部分……)

Finished Control File and SPFILE Autobackup at 21-SEP-15

此时,归档日志被备份,并且没有删除。

--多出来的两个是由于进行备份时候自动会有switch log

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

15

下面进行第二次实验。

RMAN> backup database plus archivelog;

Starting backup at 21-SEP-15

current log archived

using channel ORA_DISK_1

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=100 RECID=12 STAMP=890690423

input archived log thread=1 sequence=101 RECID=13 STAMP=890712061

input archived log thread=1 sequence=102 RECID=14 STAMP=890727732

input archived log thread=1 sequence=103 RECID=15 STAMP=890776815

input archived log thread=1 sequence=104 RECID=16 STAMP=890776833

input archived log thread=1 sequence=105 RECID=17 STAMP=890805616

input archived log thread=1 sequence=106 RECID=18 STAMP=890814181

input archived log thread=1 sequence=107 RECID=19 STAMP=890820201

input archived log thread=1 sequence=108 RECID=20 STAMP=890859629

input archived log thread=1 sequence=109 RECID=21 STAMP=890892046

input archived log thread=1 sequence=110 RECID=22 STAMP=890900632

input archived log thread=1 sequence=111 RECID=23 STAMP=890906655

input archived log thread=1 sequence=112 RECID=24 STAMP=890942416

input archived log thread=1 sequence=113 RECID=25 STAMP=890990204

input archived log thread=1 sequence=114 RECID=26 STAMP=890990263

input archived log thread=1 sequence=115 RECID=27 STAMP=890990391

channel ORA_DISK_1: starting piece 1 at 21-SEP-15

channel ORA_DISK_1: finished piece 1 at 21-SEP-15

piece handle=/u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_annnn_TAG20150921T091951_bzypsqj3_.bkp tag=TAG20150921T091951 

(篇幅原因,有省略……)

Finished Control File and SPFILE Autobackup at 21-SEP-15

第二次备份,之前备份过的日志还出现在自动备份的列表中。但是,在第二次备份的时候,已经备份过两次(deletion policy)的日志并没有自动删除。

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

17

归档日志还在fast recovery area中。

[oracle@Databaseintrawebpro fast_recovery_area]$ du -h

19M    ./XXXXDB/autobackup/2015_09_21

9.4M    ./XXXXDB/autobackup/2015_09_17

29M    ./XXXXDB/autobackup

151M    ./XXXXDB/onlinelog

6.0G    ./XXXXDB/backupset/2015_09_21

108K    ./XXXXDB/backupset/2015_09_17

6.0G    ./XXXXDB/backupset

125M    ./XXXXDB/archivelog/2015_09_19

27M    ./XXXXDB/archivelog/2015_09_21

4.0K    ./XXXXDB/archivelog/2015_09_15

127M    ./XXXXDB/archivelog/2015_09_18

121M    ./XXXXDB/archivelog/2015_09_20

4.0K    ./XXXXDB/archivelog/2015_09_16

32M    ./XXXXDB/archivelog/2015_09_17

431M    ./XXXXDB/archivelog

9.4M    ./XXXXDB/controlfile

6.6G    ./XXXXDB

6.6G    .

此时,归档日志和备份次数,在v$archived_log中可以方便的找出来。

SQL> alter system switch logfile;

System altered

SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO';

COUNT(*)

----------

18

--注意这些已经备份过两次的recid编号

SQL> select recid, sequence#, archived, deleted, backup_count from v$archived_log where backup_count>1;

RECID  SEQUENCE# ARCHIVED DELETED BACKUP_COUNT

---------- ---------- -------- ------- ------------

12        100 YES      NO                2

13        101 YES      NO                2

14        102 YES      NO                2

15        103 YES      NO                2

16        104 YES      NO                2

17        105 YES      NO                2

18        106 YES      NO                2

19        107 YES      NO                2

20        108 YES      NO                2

21        109 YES      NO                2

22        110 YES      NO                2

23        111 YES      NO                2

24        112 YES      NO                2

25        113 YES      NO                2

26        114 YES      NO                2

15 rows selected

进行第三次备份。

RMAN> backup database plus archivelog;

Starting backup at 21-SEP-15

current log archived

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=498 device type=DISK

skipping archived logs of thread 1 from sequence 100 to 114; already backed up

channel ORA_DISK_1: starting archived log backup set

channel ORA_DISK_1: specifying archived log(s) in backup set

input archived log thread=1 sequence=115 RECID=27 STAMP=890990391

input archived log thread=1 sequence=116 RECID=28 STAMP=890990481

input archived log thread=1 sequence=117 RECID=29 STAMP=890990667

input archived log thread=1 sequence=118 RECID=30 STAMP=890993128

channel ORA_DISK_1: starting piece 1 at 21-SEP-15

channel ORA_DISK_1: finished piece 1 at 21-SEP-15

piece 

(篇幅原因,有省略…….)

Finished Control File and SPFILE Autobackup at 21-SEP-15

注意:备份过两次的日志,没有出现在RMAN自动备份的列表中。这里我们定义到了删除策略的一个行为:当满足删除条件的时候,归档日志是不会进入备份集合列表的。

归档日志信息:

SQL> select recid, sequence#, archived, deleted, backup_count from v$archived_log where backup_count>1;

RECID  SEQUENCE# ARCHIVED DELETED BACKUP_COUNT

---------- ---------- -------- ------- ------------

12        100 YES      YES                2

13        101 YES      YES                2

14        102 YES      YES                2

15        103 YES      YES                2

16        104 YES      YES                2

17        105 YES      YES                2

18        106 YES      YES                2

19        107 YES      YES                2

20        108 YES      YES                2

21        109 YES      YES                2

22        110 YES      YES                2

23        111 YES      YES                2

24        112 YES      YES                2

25        113 YES      YES                2

26        114 YES      NO                2

27        115 YES      NO                2

28        116 YES      NO                2

17 rows selected

注意:一部分归档日志被删除,但是并没有所有上次备份过两次的日志都删除掉了,比如recid=26的日志。此时,备份fast recovery area空间情况发生了变化。

[oracle@Databaseintrawebpro fast_recovery_area]$ du -h

29M    ./XXXXDB/autobackup/2015_09_21

4.0K    ./XXXXDB/autobackup/2015_09_17

29M    ./XXXXDB/autobackup

151M    ./XXXXDB/onlinelog

5.5G    ./XXXXDB/backupset/2015_09_21

4.0K    ./XXXXDB/backupset/2015_09_17

5.5G    ./XXXXDB/backupset

4.0K    ./XXXXDB/archivelog/2015_09_19

2.5M    ./XXXXDB/archivelog/2015_09_21

4.0K    ./XXXXDB/archivelog/2015_09_15

4.0K    ./XXXXDB/archivelog/2015_09_18

4.0K    ./XXXXDB/archivelog/2015_09_20

4.0K    ./XXXXDB/archivelog/2015_09_16

4.0K    ./XXXXDB/archivelog/2015_09_17

2.6M    ./XXXXDB/archivelog

9.4M    ./XXXXDB/controlfile

5.7G    ./XXXXDB

5.7G    .

在alert log中,我们看到了Oracle自动删除的动作。

Mon Sep 21 09:24:27 2015

Expanded controlfile section 11 from 28 to 56 records

Requested to grow by 28 records; added 1 blocks of records

Archived Log entry 29 added for thread 1 sequence 117 ID 0x774e158c dest 1:

Mon Sep 21 10:05:28 2015

ALTER SYSTEM ARCHIVE LOG

Mon Sep 21 10:05:28 2015

Thread 1 advanced to log sequence 119 (LGWR switch)

Current log# 2 seq# 119 mem# 0: /u01/app/oracle/oradata/XXXXDB/onlinelog/o1_mf_2_bxzzjj5w_.log

Current log# 2 seq# 119 mem# 1: /u01/app/oracle/fast_recovery_area/XXXXDB/onlinelog/o1_mf_2_bxzzjj80_.log

Archived Log entry 30 added for thread 1 sequence 118 ID 0x774e158c dest 1:

Mon Sep 21 10:05:47 2015

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_17/o1_mf_annnn_TAG20150917T195557_bzoblfck_.bkp

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_17/o1_mf_1_100_bzokvqj0_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/autobackup/2015_09_17/o1_mf_s_890682958_bzoblglw_.bkp

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_101_bzp6zx31_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_102_bzpp9nln_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_103_bzr67h1h_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_18/o1_mf_1_104_bzr6812s_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_105_bzs2cj5y_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_106_bzsbq54p_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_107_bzsjm99v_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_19/o1_mf_1_108_bztq3f2v_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_109_bzvprgf1_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_110_bzvz4rj7_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_111_bzw50zmb_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_20/o1_mf_1_112_bzx7yj9g_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/archivelog/2015_09_21/o1_mf_1_113_bzypmw8c_.arc

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_annnn_TAG20150921T091644_bzypmwty_.bkp

Mon Sep 21 10:05:58 2015

Deleted Oracle managed file /u01/app/oracle/fast_recovery_area/XXXXDB/backupset/2015_09_21/o1_mf_nnndf_TAG20150921T091647_bzypn055_.bkp

Mon Sep 21 10:06:15 2015

ALTER SYSTEM ARCHIVE LOG

Mon Sep 21 10:06:15 2015

Thread 1 advanced to log sequence 120 (LGWR switch)

Current log# 3 seq# 120 mem# 0: /u01/app/oracle/oradata/XXXXDB/onlinelog/o1_mf_3_bxzzjl0z_.log

Current log# 3 seq# 120 mem# 1: /u01/app/oracle/fast_recovery_area/XXXXDB/onlinelog/o1_mf_3_bxzzjl35_.log

Archived Log entry 31 added for thread 1 sequence 119 ID 0x774e158c dest 1:

Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn

Hot AI Tools

Undresser.AI Undress

Undresser.AI Undress

AI-powered app for creating realistic nude photos

AI Clothes Remover

AI Clothes Remover

Online AI tool for removing clothes from photos.

Undress AI Tool

Undress AI Tool

Undress images for free

Clothoff.io

Clothoff.io

AI clothes remover

Video Face Swap

Video Face Swap

Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Tools

Notepad++7.3.1

Notepad++7.3.1

Easy-to-use and free code editor

SublimeText3 Chinese version

SublimeText3 Chinese version

Chinese version, very easy to use

Zend Studio 13.0.1

Zend Studio 13.0.1

Powerful PHP integrated development environment

Dreamweaver CS6

Dreamweaver CS6

Visual web development tools

SublimeText3 Mac version

SublimeText3 Mac version

God-level code editing software (SublimeText3)

When might a full table scan be faster than using an index in MySQL? When might a full table scan be faster than using an index in MySQL? Apr 09, 2025 am 12:05 AM

Full table scanning may be faster in MySQL than using indexes. Specific cases include: 1) the data volume is small; 2) when the query returns a large amount of data; 3) when the index column is not highly selective; 4) when the complex query. By analyzing query plans, optimizing indexes, avoiding over-index and regularly maintaining tables, you can make the best choices in practical applications.

Can I install mysql on Windows 7 Can I install mysql on Windows 7 Apr 08, 2025 pm 03:21 PM

Yes, MySQL can be installed on Windows 7, and although Microsoft has stopped supporting Windows 7, MySQL is still compatible with it. However, the following points should be noted during the installation process: Download the MySQL installer for Windows. Select the appropriate version of MySQL (community or enterprise). Select the appropriate installation directory and character set during the installation process. Set the root user password and keep it properly. Connect to the database for testing. Note the compatibility and security issues on Windows 7, and it is recommended to upgrade to a supported operating system.

Explain InnoDB Full-Text Search capabilities. Explain InnoDB Full-Text Search capabilities. Apr 02, 2025 pm 06:09 PM

InnoDB's full-text search capabilities are very powerful, which can significantly improve database query efficiency and ability to process large amounts of text data. 1) InnoDB implements full-text search through inverted indexing, supporting basic and advanced search queries. 2) Use MATCH and AGAINST keywords to search, support Boolean mode and phrase search. 3) Optimization methods include using word segmentation technology, periodic rebuilding of indexes and adjusting cache size to improve performance and accuracy.

Difference between clustered index and non-clustered index (secondary index) in InnoDB. Difference between clustered index and non-clustered index (secondary index) in InnoDB. Apr 02, 2025 pm 06:25 PM

The difference between clustered index and non-clustered index is: 1. Clustered index stores data rows in the index structure, which is suitable for querying by primary key and range. 2. The non-clustered index stores index key values ​​and pointers to data rows, and is suitable for non-primary key column queries.

MySQL: Simple Concepts for Easy Learning MySQL: Simple Concepts for Easy Learning Apr 10, 2025 am 09:29 AM

MySQL is an open source relational database management system. 1) Create database and tables: Use the CREATEDATABASE and CREATETABLE commands. 2) Basic operations: INSERT, UPDATE, DELETE and SELECT. 3) Advanced operations: JOIN, subquery and transaction processing. 4) Debugging skills: Check syntax, data type and permissions. 5) Optimization suggestions: Use indexes, avoid SELECT* and use transactions.

Can mysql and mariadb coexist Can mysql and mariadb coexist Apr 08, 2025 pm 02:27 PM

MySQL and MariaDB can coexist, but need to be configured with caution. The key is to allocate different port numbers and data directories to each database, and adjust parameters such as memory allocation and cache size. Connection pooling, application configuration, and version differences also need to be considered and need to be carefully tested and planned to avoid pitfalls. Running two databases simultaneously can cause performance problems in situations where resources are limited.

The relationship between mysql user and database The relationship between mysql user and database Apr 08, 2025 pm 07:15 PM

In MySQL database, the relationship between the user and the database is defined by permissions and tables. The user has a username and password to access the database. Permissions are granted through the GRANT command, while the table is created by the CREATE TABLE command. To establish a relationship between a user and a database, you need to create a database, create a user, and then grant permissions.

RDS MySQL integration with Redshift zero ETL RDS MySQL integration with Redshift zero ETL Apr 08, 2025 pm 07:06 PM

Data Integration Simplification: AmazonRDSMySQL and Redshift's zero ETL integration Efficient data integration is at the heart of a data-driven organization. Traditional ETL (extract, convert, load) processes are complex and time-consuming, especially when integrating databases (such as AmazonRDSMySQL) with data warehouses (such as Redshift). However, AWS provides zero ETL integration solutions that have completely changed this situation, providing a simplified, near-real-time solution for data migration from RDSMySQL to Redshift. This article will dive into RDSMySQL zero ETL integration with Redshift, explaining how it works and the advantages it brings to data engineers and developers.

See all articles