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:

MySQL是一種開源的關係型數據庫管理系統,主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據,以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題,優化建議包括使用索引、優化查詢和分錶分區。

MySQL是一個開源的關係型數據庫管理系統,適用於數據存儲、管理、查詢和安全。 1.它支持多種操作系統,廣泛應用於Web應用等領域。 2.通過客戶端-服務器架構和不同存儲引擎,MySQL高效處理數據。 3.基本用法包括創建數據庫和表,插入、查詢和更新數據。 4.高級用法涉及復雜查詢和存儲過程。 5.常見錯誤可通過EXPLAIN語句調試。 6.性能優化包括合理使用索引和優化查詢語句。

選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能,支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎,支持事務和查詢優化。 3.易於使用,支持多種操作系統和編程語言。 4.擁有強大的社區支持,提供豐富的資源和解決方案。

InnoDB的鎖機制包括共享鎖、排他鎖、意向鎖、記錄鎖、間隙鎖和下一個鍵鎖。 1.共享鎖允許事務讀取數據而不阻止其他事務讀取。 2.排他鎖阻止其他事務讀取和修改數據。 3.意向鎖優化鎖效率。 4.記錄鎖鎖定索引記錄。 5.間隙鎖鎖定索引記錄間隙。 6.下一個鍵鎖是記錄鎖和間隙鎖的組合,確保數據一致性。

MySQL查询性能不佳的原因主要包括没有使用索引、查询优化器选择错误的执行计划、表设计不合理、数据量过大和锁竞争。1.没有索引导致查询缓慢,添加索引后可显著提升性能。2.使用EXPLAIN命令可以分析查询计划,找出优化器错误。3.重构表结构和优化JOIN条件可改善表设计问题。4.数据量大时,采用分区和分表策略。5.高并发环境下,优化事务和锁策略可减少锁竞争。

在數據庫優化中,應根據查詢需求選擇索引策略:1.當查詢涉及多個列且條件順序固定時,使用複合索引;2.當查詢涉及多個列但條件順序不固定時,使用多個單列索引。複合索引適用於優化多列查詢,單列索引則適合單列查詢。

要優化MySQL慢查詢,需使用slowquerylog和performance_schema:1.啟用slowquerylog並設置閾值,記錄慢查詢;2.利用performance_schema分析查詢執行細節,找出性能瓶頸並優化。

MySQL和SQL是開發者必備技能。 1.MySQL是開源的關係型數據庫管理系統,SQL是用於管理和操作數據庫的標準語言。 2.MySQL通過高效的數據存儲和檢索功能支持多種存儲引擎,SQL通過簡單語句完成複雜數據操作。 3.使用示例包括基本查詢和高級查詢,如按條件過濾和排序。 4.常見錯誤包括語法錯誤和性能問題,可通過檢查SQL語句和使用EXPLAIN命令優化。 5.性能優化技巧包括使用索引、避免全表掃描、優化JOIN操作和提升代碼可讀性。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

ZendStudio 13.5.1 Mac
強大的PHP整合開發環境

Atom編輯器mac版下載
最受歡迎的的開源編輯器

Dreamweaver CS6
視覺化網頁開發工具

MinGW - Minimalist GNU for Windows
這個專案正在遷移到osdn.net/projects/mingw的過程中,你可以繼續在那裡關注我們。 MinGW:GNU編譯器集合(GCC)的本機Windows移植版本,可自由分發的導入函式庫和用於建置本機Windows應用程式的頭檔;包括對MSVC執行時間的擴展,以支援C99功能。 MinGW的所有軟體都可以在64位元Windows平台上運作。

MantisBT
Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。