因为Oracle archivelog会不断生产,一般会设置定期清理archivelog的排程,类似下面。
本文介绍一下,在DG环境中,主库使用rman做不完全恢复后,备库如何通过flashback操作,继续和主库保持同步,而不用重新搭建DG。
在使用RMAN命令(DELETE NOPROMPT ARCHIVELOG ALL;)删除归档信息后,V$ARCHIVED_LOG视图中的NAME列为空,但是依然可以查询到这些删除了的归档信息,出现这样的现象是因为使用RMAN命令在删除归档日志的时候不会清除控制文件中的内容,导致V$ARCHIVED_LOG留下的过期的不完整的失效信息。
Oracle 11g中对于归档日志的删除,除了遵循RMAN保留策略外,也可以通过RMAN来配置归档日志的删除策略,也就是归档日志何时可以被删除。归档日志删除策略适用于所有归档位置(使用快速闪回区FRA/不使用FRA)。本文主要描述归档日志删除策略并给出了具体的演示。
--**************************************************
最近开发部换了 2012, 相比 05 真是有很多提升, 特别是多出了一些高效率的关键字
最近在因归档日志暴增,使用delete archivelog all貌似无法清除所有的归档日志,到底是什么原因呢?
1、在Oracle用户下,创建归档日志删除文件del_OCPLHR1_arch.sh
首先要明确resetlogs操作非常危险的,也只有在进行不完全恢复开库时会使用到。
Oracle 数据库可以实现数据库不完全恢复与完全恢复。完全恢复是将数据库恢复到最新时刻,也就是无损恢复,保证数据库无丢失的恢复。而不完全恢复则是根据需要特意将数据库恢复到某个过去的特定时间点或特定的SCN以及特定的Sequence。我们可以通过基于用户管理的不完全恢复实现,也可以通过基于RMAN方式来实现。本文主要描述是基于RMAN的不完全恢复的几种情形并给出示例。有关数据库备份恢复,RMAN备份恢复的概念与实战可以参考文章尾部给出的链接。
ApacheTomcat 是 JakartaEE (正式的 JavaEE)技术的一个子集的开放源码软件实现。ApacheTomcat 的不同版本可用于规范的不同版本。规范和相应的 Apache Tomcat 版本之间的映射如下:
听说过还原(restore)数据库,表空间及数据库文件,使用归档日志恢复(recover)数据库,表空间,数据库文件。咦,还有还原归档日志这一说法呢?没错,可能我们忽略了还原归档日志这一个过程,原因是还原归档日志通常情况下是oracle在recover时自动完成的。大多数情况下我们是先还原数据库,恢复数据库,打开数据库。实际上在恢复数据库之前有一个动作,那就是还原归档日志,也就是将日志文件还原到缺省的归档位置,如果我们在备份归档日志时使用了delete [all] input子句的话。本文对此给出了单独还原归档日志以及恢复归档日志的示例以及restore archivelog的一些用法,仅仅是为了更好来的理解还原与恢复的过程,因为大多数情形下,数据文件被还原到缺省路径。如果是还原到非缺省路径,那就需要手动restore archivelog。
在使用RMAN命令(DELETE NOPROMPT ARCHIVELOG ALL;)删除归档信息后,VARCHIVED_LOG视图中的NAME列为空,但是依然可以查询到这些删除了的归档信息,出现这样的现象是因为使用RMAN命令在删除归档日志的时候不会清除控制文件中的内容,导致VARCHIVED_LOG留下的过期的不完整的失效信息。
最近在无疑中查看一个数据库的日志的时候,发现里面有这么一段内容。 Sat Feb 06 10:07:25 2016 Deleted Oracle managed file +ARCH/testdb2/archivelog/2016_01_13/thread_1_seq_4566.261.901038877 Archived Log entry 9262 added for thread 1 sequence 4678 ID 0x26b3e123 dest 1: Sat Feb 06 14:04:52 2
最近为了不影响开发库的使用,打算复制创建一个备库,定时更新,防止开发库不能使用的情况下,可以临时使用备库,不影响进度。
首先这对于Oracle DBA来说是个初级问题,即使不熟悉的初级DBA也可以快速在网上搜索到现成的SQL语句。 网上搜到的查询SQL基本类似这样的逻辑:
https://www.cwiki.us/display/CONF6ZH/Archive+a+Space
5.11.6. Best Practices for Declarative Partitioning
前些天给同事准备一套模拟环境用于测试一个OGG问题: 环境架构:Oracle 11.2.0.4 RAC + 单实例11.2.0.4 ADG(同时作为OGG源端,OGG版本19.1.0.0.4) + 单实例19.3多租户(其中1个PDB作为OGG目标端,OGG版本19.1.0.0.4) 现象概述:发现OGG进程abended,原因是主库归档满,但是实际已配置归档自动清理脚本(归档空间使用大于90%时清理),进一步查看发现根源是归档清理失效,报错RMAN-08137,导致的影响有很多,首先主库无法进行测试数据写入,其次ADG备库产生延迟,然后OGG源端抽取进程因超时报错OGG-02149导致abended..
备节点查看select pg_last_xlog_receive_location();值没有变化,已经不从主节点同步。
环境:RAC+单机 Dataguard 问题:启动DG备库到mount阶段,启动MRP进程后,发现后台日志不打印归档传输信息,另外备库日志打开ARC1: Becoming the 'no FAL' ARC
Recovery Manager: Release 11.2.0.3.0 - Production on Tue Jan 9 07:33:58 2018
在开发环境及UAT环境经常碰到需要清除归档日志的情形,对于这个问题方法有很多。可以直接使用rm方式清除归档日志,也可以使用find命令来查找符合条件的记录来清除归档日志,或者直接写个shell脚本来搞定。这样在DEV或者UAT还可以,但是在Prod环境还是建议使用RMAN提供的命令来搞定比较妥当。因为rm,find方式删除了实际的归档日志也释放了空间,但对应的存储在控制文件中的归档信息并没有彻底清除。依旧占用着一些空间未能及时清除而需要控制文件通过age out方式来释放空间。本文描述了使用RMAN方式来清除归档日志,同时也可以将其部署到shell脚本中使用。
ADG是可以正常同步的,但是备库执行 archive log list 时显示都为 0,因此比较好奇,于是查询mos发现:
自从 1990 启动的家喻户晓的人类基因组计划开始,全世界的科学家竭尽全力破译了第一个完整的人类基因组,从那时开始人类拿到了一本只有 ATCG 四个碱基书写的天书。后续人们逐步完善了基因组序列信息,并写在 Fasta 格式的文本文件“天书”中,这本天书就叫做参考基因组。
首先通过备库sql查出相应的 node[thread#] 和归档位置 name:
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
对于DEV以及UAT环境,有些时候,数据库需要处于归档模式,但并不需要备份数据库。因此,archive归档日志不停的增长导致磁盘空间被大量耗用。对于这种情形,可以使用一个shell脚本来定时自动清除这些归档日志。本文给出了清除归档日志的脚本。
环境:RAC+单机 Dataguard 问题:启动备库到ADG模式时,发现后台归档日志并不同步
最近的RAC环境中遭遇ORA-00254,ORA-15173,即无法进行归档。通常情况下归档失败我们考虑更多的是归档路径的不可达,或归档所在的磁盘空间不足造成的。在使用 ASM 存放归档日志的情形下,对于已经配置好且成功归档的数据库也提示路径不可达?看看到底是怎么一回事。
今天在梳理服务器的信息的时候,发现有一台服务器没有设置crontab作业,一般的服务器中可能会需要一些定时的任务来触发一些备份,清理等等工作。 因为这是一台备库机器,上面有11gR2的备库,所以首要工作就是查看是否在正常应用日志。 从日志来看,归档已经正常应用。不过似乎有一些相对陌生的操作在日志里面。 Archived Log entry 68735 added for thread 1 sequence 95373 ID 0x70141a28 dest 1: Tue Aug 04 16:00:29 201
本文主要介绍了iOS推送过程中可能遇到的坑,包括推送证书配置错误、推送权限未关闭或未正确关闭、设备token获取失败或发送给XG服务器的姿势不正确等问题。同时,也提供了推送诊断工具以帮助开发者排查推送问题。
今天在一套环境中做系统检查的时候,发现alert日志中有一段ODM的错误。 日志内容大体如下,可以看到是在半夜4点多报的错误。 Clearing Resource Manager plan via parameter Fri Aug 22 02:00:52 2014 ALTER SYSTEM ARCHIVE LOG Fri Aug 22 02:00:52 2014 Thread 1 advanced to log sequence 6934 (LGWR switch) Current log# 3 se
1、Oracle日志原理 史记讲解法 日志记录方式 2、实际日志产生过程 3、归档模式
随着业务数据量增长原来设置的 300M 大小 redo 日志组已经出现各种小问题,“log file switch (checkpoint incomplete)” 等待事件,alert 日志中经常出现“Checkpoint not complete”检查点未完成等信息说明需要重建 redo 日志组,下面来一起看下 RAC 与 ADG 如何重建 redo 日志组。
本文作者系大连健哥、 POSTGRESQL、ORACLE 数据库资深从业人员、IT 技术的深度爱好者。相信科学改变人类、技术创造未来。个人主页:https://www.cnblogs.com/gaojian/,经其本人授权发布。
本文是针对在DG灾备环境进行failover操作以及后续恢复的报告。 我这里的测试环境是: 数据库版本:Oracle 11.2.0.4 Site A:主库 db_unique_name=jyzhao Site B:备库(实时应用)db_unique_name=mynas Site C:备库(延迟1小时应用)db_unique_name=jyzhao_s
在归档空间中的页面不会显示在查找结果中(除非你选择 在归档空间中查找(Search archived spaces))。
人工智能的热潮已经在逐渐冷却,炒新闻的越来越少,AI 已经逐渐侵入到实际的生活中,可能我的神经弧反射的比较长,到现在才后知后觉,所以以一个后知后觉的人的角度来说说我感知DBA 与 AI 之间的关系。
Testlink是一款免费开源的测试管理软件,基于WEB的测试用例管理系统,主要功能是:测试项目管理、产品需求管理、测试用例管理、测试计划管理、测试用例的创建、管理和执行,并且还提供了统计功能。为了方便快速部署TestLink,并且保持环境的一致性,我们可以使用Docker进行搭建。本文将介绍如何使用Docker搭建TestLink的过程,让你可以轻松地在自己的开发环境中使用TestLink进行测试管理。
1.官方文档描述 2.故障报错信息 3.分析解决问题 1.官方文档描述 关于Clearing a Redo Log File的官方文档描述: A redo log file might become corrupted while the database is open, and ultimately stop database activity because archiving cannot continue. In this situation the ALTER DATABASE CLEAR L
新型冠状病毒(2019-nCoV)突然降临武汉,随着春运大潮,逐渐扩散到全国各省份。这让原本应该是热热闹闹的春节,一下子气氛冷到冰点,感觉空气中都带着恐怖的气息。
前面介绍了Oracle的基本参数,从这节开始讲其他的参数,参数从v$parameter中提取
实验环境:RHEL 6.5 + Oracle 11.2.0.4 GI、DB + Primary RAC(2 nodes)+ Standby RAC(2 nodes)
近日有一套实时同步的 ASM 管理的单机 11204 ADG 备库,由于业务需要,想要脱离主库的约束,想激活拉成读写库直接升级成 ASM 管理的 19C,闪回快照模式无法满足要求,只能 ALTER DATABASE ACTIVATE STANDBY DATABASE 强制切成可读写的主库。说干就干,先将其切成主库,升级过程等下次在一起讨论。
在上周五的时候,本来一个例行巡检,想扩充一些表空间,结果弄巧成拙,因为一个drop datafile的操作直接导致了一主两备的两个备库MRP直接抛出了ORA-600错误。 在尝试了一些方法和查看了MOS之后,除了重建备库,暂时还没有找到其它相对更快捷的方法。 因为是10.2.0.4.0的环境,为了先修复问题,自己先使用rman在主库做了备份,然后在备库直接做duplicate操作还原恢复。先搭好了一个备库,另外一个备库则先留下来,观察一下,看看有没有其它的方法,如果还是没有找到,就继续重新搭建备库。 结果在
查看当前归档日志路径,空间的使用率已经到了100%,于是在rman中,删除30天之前的归档日志文件,
领取专属 10元无门槛券
手把手带您无忧上云