Oracle归档日志

Oracle日志的分类

Alter log  files:警报日志

Trace files:跟踪日志(用户和进程)

redo log :重做日志(记录数据库的更改)

重做日志

分为在线重做日志和归档重做日志

在线重做日志:又称联机重做日志,指Oracle以SQL脚本的形式记录数据库的数据更新,换句话说,实时保存已执行的SQL脚本到在线日志文件中

归档重做日志:简称归档日志,是指,当条件满足时,Oracle将在线重做日志以文件形式保存到硬盘(持久化)

重做日志的简单原理:在数据更新操作commit前,将更改的SQL脚本写入重做日志。主要用于数据库的增量备份和增量恢复。

重做日志直接对应于硬盘的重做日志文件(有在线和归档俩种),重做日志文件以组的形式组织,一个重做日志组包括一个或多个日志文件。

归档重做日志

其实,所谓的归档,就是指,将在线日志进行归档,持久化成固定的文件到硬盘,便于以后的恢复和查询。当然,前提条件是数据库要处于归档模式。

在线重做日志大小毕竟是有限的,当都写满了的时候,就面临着俩个选择,第一个就是把以前在线重做日志从头擦除开始继续写,第二种就是把以前的在线重做日志先进行备份,然后对被备份的日志擦除开始写新的在线Redo  File。这种备份的在线重做日志就是归档日志。而数据库如果采用这种生成归档日志的模式的话,就是归档日志模式(ARCHIVELOG模式),反之如果不生成归档日志,就是非归档日志模式(NOARCHIVELOG模式)。

有了归档日志有什么好处?

比如在这个月1号的时候备份了一次数据,然后过了10天,这个10天生成了很多在线重做日志,突然发现其中有一个数据磁盘出问题了,不能用了,那我该如何是好呢?

如果没有采用归档日志,那么实际上磁盘中只会有几个最新的在线重做日志。那么我只能把出问题的数据磁盘上所占据的表空间都删除掉。但是如果是SYSTEM表空间所设计的磁盘出错了,就没办法这么做了,只能用第二种方法。第二种方法就是把1号备份的数据拿出来恢复。那么1号到10号之间的10天的数据都丢了,如果是关键系统,比如证券金融什么的系统,就要让你赔钱赔死掉。

但是如果有了归档日志,那么你这10天的重做日志都会存放起来,那么DBA首先会把1号的备份数据恢复,然后再拿这10天的Redo日志来进行一次数据操作重放,那么就可以完全恢复最新的数据库,不会有什么后果了。

在软件开发的时候,由于测试服务器的配置有限,特别是磁盘空间有限,所以可能要限制Redo文件的大小,有可能把系统设置为NOARCHIVELOG模式了。但是在实际的生产环境下,基本上一定要使用ARCHIVELOG模式,否则万一出了问题,真是苦都来不及。

有人可能会怕归档日志造成性能损失。其实这个完全是杞人忧天的,归档日志只是做一个备份,其实也就是多耗一些磁盘空间而已。在当前的软件系统中,硬盘的存储容量成本已经属于低到可以忽略的地步,而最重要的是数据库的安全。DBA的任务本来就是确保数据的安全,如果连安全都保证不了,那点微乎其微的性能提高又有什么用呢。

归档日志(Archive Log)是非活动的重做日志备份。通过使用归档日志,可以保留所有重做历史记录,当数据库处于Archive Log模式并进行日志切换时,后台进程ARCH会将重做日志的内容保存到归档日志中,当数据库出现介质失败时,使用数据文件备份,归档日志和重做日志可以完全恢复数据库。

查看数据库当前是否为归档模式

SELECT  LOG_MODE FROM  V$DATABASE;

ARCHIVELOG(归档模式)、NOARCHIVELOG(非归档模式)

切换数据库为归档模式

shutdown   immediate             #关闭数据库

startup   mount                        #开启数据库到挂载状态

alter database archivelog;     #改变模式为ARCHIVELOG

archive log  start;                   #开启归档日志

alter datebase open;               #打开数据库

查找归档日志目录

SELECT  destination  FROM  V$archive_dest;

在线重做日志的原理


 对于在线重做日志,Oracle 11g默认对于每个数据库实例,建立3个在线日志组,每组一个日志文件,文件名称为REDO01.LOG,REDO02.LOG,REDO03.LOG。(用户可以通过视图操作添加/修改/删除日志组合日志文件来自定义在线重做日志)

        每组内的日志文件的内容完全相同,且保存在不同的位置,用于磁盘日志镜像,以做多次备份提高安全性。默认情况这3组通常只有一组处于活动状态,不断地同步写入已操作的脚本,当日志文件写满时(达到指定的空间配额),如果当前数据库处于归档模式,则将在线日志归档到硬盘,成为归档日志;若当前数据库处于非归档模式,则不进行归档操作,而当前在线日志的内容会被下一次重新写入覆盖而无法保存。因此,通常数据库在运行时,是处于归档模式下的,以保存数据更新的日志。

       当前归档日志组写满够,Oracle会切换到下一日志组,继续写入,这样循环切换;处于归档模式下,切换至原已写满的日志组,若该日志组归档完毕则则覆盖写入,若没有则只能使用日志缓冲区,等待归档完毕之后才能覆盖写入。当然,处于非归档模式下是直接覆盖写入的。


最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,219评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,363评论 1 293
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,933评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,020评论 0 206
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,400评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,640评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,896评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,597评论 0 199
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,327评论 1 244
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,581评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,072评论 1 261
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,399评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,054评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,083评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,849评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,672评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,585评论 2 270

推荐阅读更多精彩内容