찾다
데이터 베이스MySQL 튜토리얼聊聊RMAN的ARCHIVELOG DELETION参数

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:

성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
MySQL에서 사용 가능한 다른 스토리지 엔진은 무엇입니까?MySQL에서 사용 가능한 다른 스토리지 엔진은 무엇입니까?Apr 26, 2025 am 12:27 AM

mysqloffersvariousStorageEngines, 각각의 everitedforentUsecases : 1) innodbisidealforapplicationsneedingAcidCoInceandHighConcurrency, 지원 트랜잭션 및 foreignKeys.2) myIsAmisbestforread-heverworkloads, memoryengineis

MySQL의 일반적인 보안 취약점은 무엇입니까?MySQL의 일반적인 보안 취약점은 무엇입니까?Apr 26, 2025 am 12:27 AM

MySQL의 일반적인 보안 취약점에는 SQL 주입, 약한 암호, 부적절한 권한 구성 및 업데이트되지 않은 소프트웨어가 포함됩니다. 1. 전처리 명령문을 사용하여 SQL 주입을 방지 할 수 있습니다. 2. 강력한 비밀번호 전략을 사용하여 약한 암호는 피할 수 있습니다. 3. 정기적 인 검토 및 사용자 권한 조정을 통해 부적절한 권한 구성을 해결할 수 있습니다. 4. Unupdated 소프트웨어는 MySQL 버전을 정기적으로 확인하고 업데이트하여 패치 할 수 있습니다.

MySQL에서 느린 쿼리를 어떻게 식별 할 수 있습니까?MySQL에서 느린 쿼리를 어떻게 식별 할 수 있습니까?Apr 26, 2025 am 12:15 AM

느린 쿼리 로그를 활성화하고 임계 값을 설정하여 MySQL에서 느린 쿼리를 식별 할 수 있습니다. 1. 느린 쿼리 로그를 활성화하고 임계 값을 설정하십시오. 2. 느린 쿼리 로그 파일을보고 분석하고 심층 분석을 위해 MySQLDumpSlow 또는 PT-Query 소수성과 같은 도구를 사용하십시오. 3. 인덱스 최적화, 쿼리 재 작성 및 select*의 사용을 피함으로써 느린 쿼리 최적화를 달성 할 수 있습니다.

MySQL 서버 건강 및 성능을 어떻게 모니터링 할 수 있습니까?MySQL 서버 건강 및 성능을 어떻게 모니터링 할 수 있습니까?Apr 26, 2025 am 12:15 AM

MySQL 서버의 건강 및 성능을 모니터링하려면 시스템 건강, 성능 지표 및 쿼리 실행에주의를 기울여야합니다. 1) 시스템 건강 모니터링 : CPU, 메모리, 디스크 I/O 및 네트워크 활동을 볼 수 있도록 상단, HTOP 또는 ShowGlobalStatus 명령을 사용하십시오. 2) 성능 표시기 추적 : 초당 쿼리 번호, 평균 쿼리 시간 및 캐시 적중률과 같은 주요 표시기를 모니터링합니다. 3) 쿼리 실행 최적화 확인 : 실행 시간이 설정 임계 값을 초과하는 쿼리를 느린 쿼리 로그를 활성화하고 기록 및 최적화하십시오.

MySQL 및 Mariadb를 비교하고 대조하십시오.MySQL 및 Mariadb를 비교하고 대조하십시오.Apr 26, 2025 am 12:08 AM

MySQL과 Mariadb의 주요 차이점은 성능, 기능 및 라이센스입니다. 1. MySQL은 Oracle에 의해 개발되었으며 Mariadb는 포크입니다. 2. MariaDB는 높은 하중 환경에서 더 나은 성능을 발휘할 수 있습니다. 3. Mariadb는 더 많은 스토리지 엔진과 기능을 제공합니다. 4.MySQL은 듀얼 라이센스를 채택하고 MariaDB는 완전히 오픈 소스입니다. 선택할 때 기존 인프라, 성능 요구 사항, 기능 요구 사항 및 라이센스 비용을 고려해야합니다.

MySQL의 라이센스는 다른 데이터베이스 시스템과 어떻게 비교됩니까?MySQL의 라이센스는 다른 데이터베이스 시스템과 어떻게 비교됩니까?Apr 25, 2025 am 12:26 AM

MySQL은 GPL 라이센스를 사용합니다. 1) GPL 라이센스는 MySQL의 무료 사용, 수정 및 분포를 허용하지만 수정 된 분포는 GPL을 준수해야합니다. 2) 상업용 라이센스는 공개 수정을 피할 수 있으며 기밀이 필요한 상업용 응용 프로그램에 적합합니다.

MyISAM을 통해 언제 innodb를 선택 하시겠습니까?MyISAM을 통해 언제 innodb를 선택 하시겠습니까?Apr 25, 2025 am 12:22 AM

MyISAM 대신 InnoDB를 선택할 때의 상황에는 다음이 포함됩니다. 1) 거래 지원, 2) 높은 동시성 환경, 3) 높은 데이터 일관성; 반대로, MyISAM을 선택할 때의 상황에는 다음이 포함됩니다. 1) 주로 읽기 작업, 2) 거래 지원이 필요하지 않습니다. InnoDB는 전자 상거래 플랫폼과 같은 높은 데이터 일관성 및 트랜잭션 처리가 필요한 응용 프로그램에 적합하지만 MyISAM은 블로그 시스템과 같은 읽기 집약적 및 트랜잭션이없는 애플리케이션에 적합합니다.

MySQL에서 외국 키의 목적을 설명하십시오.MySQL에서 외국 키의 목적을 설명하십시오.Apr 25, 2025 am 12:17 AM

MySQL에서 외국 키의 기능은 테이블 간의 관계를 설정하고 데이터의 일관성과 무결성을 보장하는 것입니다. 외국 키는 참조 무결성 검사 및 계단식 작업을 통해 데이터의 효과를 유지합니다. 성능 최적화에주의를 기울이고 사용할 때 일반적인 오류를 피하십시오.

See all articles

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

Video Face Swap

Video Face Swap

완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

Eclipse용 SAP NetWeaver 서버 어댑터

Eclipse용 SAP NetWeaver 서버 어댑터

Eclipse를 SAP NetWeaver 애플리케이션 서버와 통합합니다.

ZendStudio 13.5.1 맥

ZendStudio 13.5.1 맥

강력한 PHP 통합 개발 환경

맨티스BT

맨티스BT

Mantis는 제품 결함 추적을 돕기 위해 설계된 배포하기 쉬운 웹 기반 결함 추적 도구입니다. PHP, MySQL 및 웹 서버가 필요합니다. 데모 및 호스팅 서비스를 확인해 보세요.

PhpStorm 맥 버전

PhpStorm 맥 버전

최신(2018.2.1) 전문 PHP 통합 개발 도구