最近检查测试机器(Linux6-Oracle112040 RAC)ASM目录发现归档日志有断档,目录里遗留了2019、2020年的一些不连续归档。断档的这一部分在控制文件中没有记录,故此归档文件一直没有被发现。这些不连续的归档日志都属于无效日志,需要清理。
由于业务增长,频繁的备份还原对于磁盘空间有了更大的空间需求,基本每周500G的磁盘,空间使用率都会达到85%以上,故编写Oracle清理脚本结合crond自动清理Oracle归档日志。
最近在某银行进行OGG迁移时,遇到一个超过1T的数据库,由于开始没有注意到一些细节,导致在导入过程中出现了一些问题。现在将这些问题总结记录下来,防止之后再发生类似问题。
对于基于日志复制的主备数据库来说,由于配置不当或者备库空间问题造成主数据库的日志被自动清理,造成主备数据库同步中断,对于管理人员来说,也许就是一种失责甚至灾难(如果主发生故障),同样基于日志复制的同步软件来说,存在同样的问题,日志由于各种原因被删除,造成同步数据被中断,如果有定时备份日志,无非就是延迟的问题,如果无日志,可能重新初始化,尤其对于架构复杂以及多链路的复制,修复数据也是头疼事情。
wal全称是write ahead log,是postgresql中的online redo log,是为了保证数据库中数据的一致性和事务的完整性。而在PostgreSQL 7中引入的技术。它的中心思想是“先写日志后写数据”,即要保证对数据库文件的修改应放生在这些修改已经写入到日志之后,同时,在PostgreSQL 8.3以后又加入了WalWriter日志写进程,可以保证事务提交记录不是在提交时同步写入到磁盘,而是异步写入,这样就极大的减轻了I/O的压力。所以说WAL日志很重要。对保证数据库中数据的一致性和事务的完整性。
ORA-03113: end-of-file on communication channel
熊军(老熊) 云和恩墨西区总经理 Oracle ACED,ACOUG核心会员 在11g里面,随着ASM、RAC、Data Guard(包括Active Data Guard)的成熟,使用RAC+ASM+Data Guard越来越成为一种可靠的、维护简单、稳定的高可用性和容灾保护方案。这篇文章谈谈如何管理Oracle 11g Data Guard环境中的归档日志。 归档日志是重要的,备份恢复需要它,而Data Guard也需要它。在早期版本的Data Guard环境中,常常面临着归档日志管理问题,,但11g做
Oracle的归档模式( ARCHIVELOG ) 一般用于数据库的复制和备份,相对重要的企业应用都会打开该模式,每当执行了增删改的操作,Oracle就会自动归档,当归档分区剩余空间不足90%时,Oracle的服务将不可用,这时就需要清理归档日志。
听说过还原(restore)数据库,表空间及数据库文件,使用归档日志恢复(recover)数据库,表空间,数据库文件。咦,还有还原归档日志这一说法呢?没错,可能我们忽略了还原归档日志这一个过程,原因是还原归档日志通常情况下是oracle在recover时自动完成的。大多数情况下我们是先还原数据库,恢复数据库,打开数据库。实际上在恢复数据库之前有一个动作,那就是还原归档日志,也就是将日志文件还原到缺省的归档位置,如果我们在备份归档日志时使用了delete [all] input子句的话。本文对此给出了单独还原归档日志以及恢复归档日志的示例以及restore archivelog的一些用法,仅仅是为了更好来的理解还原与恢复的过程,因为大多数情形下,数据文件被还原到缺省路径。如果是还原到非缺省路径,那就需要手动restore archivelog。
原文:http://www.enmotech.com/web/detail/1/703/1.html
在开发环境及UAT环境经常碰到需要清除归档日志的情形,对于这个问题方法有很多。可以直接使用rm方式清除归档日志,也可以使用find命令来查找符合条件的记录来清除归档日志,或者直接写个shell脚本来搞定。这样在DEV或者UAT还可以,但是在Prod环境还是建议使用RMAN提供的命令来搞定比较妥当。因为rm,find方式删除了实际的归档日志也释放了空间,但对应的存储在控制文件中的归档信息并没有彻底清除。依旧占用着一些空间未能及时清除而需要控制文件通过age out方式来释放空间。本文描述了使用RMAN方式来清除归档日志,同时也可以将其部署到shell脚本中使用。
“为什么之前发送的数据在知行EDI平台的页面上都没有了呢?” “我想查询下之前的数据是否有成功发送给我们的客户应该如何确认呢?” “业务数据量太大,文件占用磁盘空间太多,我该如何快速地确认一些不需要的数据来清理释放磁盘空间呢?”
随着企业业务数据量的增大,现有服务器环境可能无法提供足够的磁盘空间存放数据处理的日志和文件,磁盘空间不足是影响EDI环境正常运行的一大原因,会导致数据无法正常处理,日志信息无法写入,影响业务正常进行。本文将为大家介绍出现磁盘空间不足,导致EDI系统运行异常的紧急处理方法。
之前在《Win环境下Oracle小数据量数据库的物理备份》这篇文章中,介绍了在win平台下对于小数据量的数据库的物理备份设计。 文中重点提到,强烈建议备份文件有单独的存储,防止存储单点故障时备份文件亦不可用。 当我在实验环境实际去模拟这种使用单独存储的环境时,出现意料之外的问题:备份到映射的盘符无法成功,报错如下:
很多刚入行的DBA往往一看有ORA-600这类错误就不知所措,直接就想寻求中高级DBA支持,甚至在网上还看到有人说,判断一个Oracle DBA是否达到中级以上,就是看其是否可以独立思考处理ORA-600这类问题,而实际上ORA-600这个错误集合中的确有很多跟bug相关,有些甚至是MOS也搜不到的,但同样也有很多是很简单的,并不需要你去深入分析trc,比对call stack匹配bug什么的。就比如今天遇到的一则案例,客户发现DG备库应用出现了问题,进一步查看告警日志发现有报错ORA-600[2619],并因此导致mrp进程异常终止。
其中fast_recovery_area文件夹占用了2.3G,应该是开启了归档,这是一台开发库,没有那么高级别保障的要求,因此可以关闭归档,删除旧的日志文件。
Oracle 11g中对于归档日志的删除,除了遵循RMAN保留策略外,也可以通过RMAN来配置归档日志的删除策略,也就是归档日志何时可以被删除。归档日志删除策略适用于所有归档位置(使用快速闪回区FRA/不使用FRA)。本文主要描述归档日志删除策略并给出了具体的演示。
查看当前归档日志路径,空间的使用率已经到了100%,于是在rman中,删除30天之前的归档日志文件,
最近有客户的 shareplex 因为一些稀奇古怪的原因又挂了,由于邮件告警问题,没有及时通知到,并且归档已经被删除,备份也追溯不回丢失的归档日志。
在我们的技术讨论群『云和恩墨大讲堂』中,还有日常的微信互动中,经常有朋友会提出一些有趣的小问题,在空闲的时候,我希望能够记录下来,和大家做一点小分享,以点滴的知识,增进一点点对于Oracle的理解,就名之为『微信课堂』吧。
数据库重新启动的时候,收到了ORA-19815的错误。从错误的提示来看,是由于闪回区的空间被填满导致无法成功启动。这种情形我们通常考虑的是清除归档日志,那就直接在OS层面rm了,真的是这样吗?客官,如果你有相同的情形,接下往下看......
场景:某oracle库生成的过期归档备份很多,通过rman没有清理掉,需删除一天以前的归档备份,假设归档备份的格式为log。
这是一个单实例数据库,oracle11.2.0.4 ,跑在Wondows上,当时主库压力太大,用户有容灾和读写分离的需求,这样在主库跑了一段时间后搭建了一个备库,这个备库一直跑到很好,最多主库由于存储压力,删除过几个归档日志,这个删除也是确认了备库应用之后操作的,对主备都已经没有影响。所以,当这家南方公司的负责人(我就称为王工)找到我时,我还是觉得意外。
链接:http://www.eygle.com/archives/2010/11/recover_archivelog_corruption.html
编辑手记: LogMiner是用于Oracle日志挖掘的利器,使用该工具可以轻松获得Oracle 重做日志文件(归档日志文件)中的具体内容,LogMiner分析工具实际上是由一组PL/SQL包和一些动态视图组成,它作为Oracle数据库的一部分来发布,是oracle公司提供的一个完全免费的工具。本文主要演示LogMiner的使用,直观展示LogMiner的作用。 环境:Oracle 11.2.0.4 RAC 1.查询当前日志组 2.业务用户插入操作 3.归档日志切换 4.业务用户插入操作 5.归档日志切换
环境:RAC+单机 Dataguard 问题:启动备库到ADG模式时,发现后台归档日志并不同步
Oracle随着版本的升级,逐渐将步骤缩减,进行封装,18C之后可谓是达到了所谓的一键刷新,恢复DG同步。
在 Oracle 12.2 之前,当我们需要恢复数据库到某个时间点的时候,需要确定 SCN,或者日志序列号,或者一个时间点,以便尽可能多的应用归档日志,进而尽可能多的恢复数据。 从12.2开始,RMAN 新增参数: RECOVER DATABASE UNTIL AVALIABLE REDO RMAN 将会根据控制文件信息和归档日志/在线日志/归档日志备份集的物理可用性,将数据库恢复到最后一个可用的归档日志。所以在进行恢复的时候,可以不需要指定 SCN,或者时间,或者日志序列号。需要注意的是,数据文件仍然需要
Oracle 开启归档模式后,会一直不停的产生归档日志,如果不定时删除,迟早会撑爆磁盘空间,所以就需要布置定时删除归档日志的脚本!
最近在因归档日志暴增,使用delete archivelog all貌似无法清除所有的归档日志,到底是什么原因呢?
对于DEV以及UAT环境,有些时候,数据库需要处于归档模式,但并不需要备份数据库。因此,archive归档日志不停的增长导致磁盘空间被大量耗用。对于这种情形,可以使用一个shell脚本来定时自动清除这些归档日志。本文给出了清除归档日志的脚本。
从这期开始讲Oracle Data Guard方面的内容,先将基本的概念,然后介绍如何搭建Data Guard
执行备份或还原的数据库称为目标。在一些环境下,有许多数据库,因此有许多RMAN目标。应一次连接每个数据库。目标的每个备份都有一些属性:
在使用RMAN命令(DELETE NOPROMPT ARCHIVELOG ALL;)删除归档信息后,VARCHIVED_LOG视图中的NAME列为空,但是依然可以查询到这些删除了的归档信息,出现这样的现象是因为使用RMAN命令在删除归档日志的时候不会清除控制文件中的内容,导致VARCHIVED_LOG留下的过期的不完整的失效信息。
在恢复控制文件时“recover database”命令可能需要使用归档日志。所谓缺失归档日志,是指控制文件从备份还原之后,在执行“recover database”命令恢复时报告找不到相应的日志导致恢复终止的情况。
Oracle通过Redo Archived实现数据的归档 什么是Redo日志 Redo日志记录了数据的变更,用于在数据库出现故障后,进行数据恢复。 功能主要由三个组件实现:Redo Log Buffer、LGWR后台进程、Redo Log File。 Redo Log Buffer是Oracle共享内存中的一段空间,记录了数据库的变更历史,包括:insert,update,delete,create,alter,drop等。 过程: 用户内存中的记录 --复制--> SGA中的Redo Log Buf
DB2日志是以文件的形式存放在文件系统中,分为两种模式:循环日志和归档日志。当创建新数据库时,日志的缺省模式是循环日志。在这种模式下,只能实现数据库的脱机备份和恢复。如果要实现联机备份和恢复,必须设为归档日志模式。
在使用RMAN命令(DELETE NOPROMPT ARCHIVELOG ALL;)删除归档信息后,V$ARCHIVED_LOG视图中的NAME列为空,但是依然可以查询到这些删除了的归档信息,出现这样的现象是因为使用RMAN命令在删除归档日志的时候不会清除控制文件中的内容,导致V$ARCHIVED_LOG留下的过期的不完整的失效信息。
在Oracle数据库中,数据库可以设置为归档模式和非归档模式。归档模式保存所有的事务日志,包括在线Redo日志和归档日志,而非归档模式没有归档日志,只有在线Redo日志。归档模式是指可以备份所有的数据库事务并恢复到任意一个时间点。非归档模式则相反,不能恢复到任意一个时间点,但是非归档模式可以带来数据库性能上的少许提高,因为非归档模式没有归档日志。DBA必须做出的一个重要决策是将数据库配置为在ARCHIVELOG模式下运行还是将其配置为在NOARCHIVELOG模式下运行。。
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/53905885
项目名称:赛克蓝德日志分析软件 seci-log 项目简介: 赛克蓝德日志分析软件,主要对日志进行收集,格式化,然后进行分析,日志可以是系统日志,也可以是业务日志,业务日志需要二次开发。目前支持
遇到的失败或错误分为两大类:物理和逻辑。物理错误一般是硬件错误或使用数据库的应用程序中的软件错误,而逻辑错误一般在终端用户级别(数据库用户和管理员)。
我们坑你遇到的失败或错误分为两大类:物理和逻辑。物理错误一般是硬件错误或使用数据库的应用程序中的软件错误,而逻辑错误一般在终端用户级别(数据库用户和管理员)。
当主库的某些日志没有成功传送到备库,那么这时候就发生了归档裂缝(Archive Gap)。目前Oracle提供了两种日志GAP的检测和处理机制,分别是自动GAP处理(Automatic Gap Resolution)和FAL进程GAP处理(FAL Gap Resolution)。自动GAP处理即主库上的ARCn进程会每分钟检查备库上的日志GAP情况并做相应处理。FAL(Fetch Archive Log)是通过配置FAL_SERVER和FAL_CLIENT实现GAP检测的一种机制,它是备库主动发起的“取”日志的过程。备库就是FAL_CLIENT,它从FAL_SERVER中取这些GAP。Oracle会首先尝试使用FAL进程处理GAP,当发现FAL机制并没有配置生效的时候,进而尝试使用自动GAP处理。
目前一共包含以下4个脚本,其中DB_healthcheck_lhr_v6.0.1_ALL_RW.sql 是读写版本,在脚本执行过程中会对数据库做DDL(创建一些用到的临时表)和DML操作(对自己创建的临时表DML操作),但是,在脚本执行后会清理掉创建的临时表,基本上不会留下任何痕迹。而脚本DB_healthcheck_lhr_v1.0.0_10g_RO.sql、DB_healthcheck_lhr_v1.0.0_11g_RO.sql和DB_healthcheck_lhr_v1.0.0_2c_RO.sql分别对应10g、11g和12c及其以上版本,这3个脚本都是只读版本,这3个脚本只会对数据库做查询操作,不会做DML和DDL操作,这也是很多朋友所期待的功能。
RAC环境下的归档模式切换与单实例稍有不同,主要是共享存储所产生的差异。在这种情况下,我们可以将RAC数据库切换到非集群状态下,仅仅在一个实例上来实施归档模式切换即可完成RAC数据库的归档模式转换问题。本文主要描述了由非归档模式切换到归档模式,而由非归档切换的归档步骤相同,不再赘述。
本篇梳理DG的架构和一些概念知识,重新梳理的目的是加强理解,也方便复习,基于11gR2版本写的,不包含12c新特性。如果能帮助到新接触DG的朋友,那就再好不过。
在 Oracle 归档模式下直接 rm data.dbf 数据文件并重启数据库还有救吗?为何会有这样的问题,要追溯到上周一位朋友咨询的事情,他那里一个 Oracle 单机的环境因为表空间不足了,需要扩容表空间,则通过添加表空间数据文件的命令加入了一个数据文件,执行成功后呢便可以继续写入数据了。
领取专属 10元无门槛券
手把手带您无忧上云