熊军（老熊） 云和恩墨西区总经理 Oracle ACED，ACOUG核心会员 在11g里面，随着ASM、RAC、Data Guard（包括Active Data Guard）的成熟，使用RAC+ASM+Data Guard越来越成为一种可靠的、维护简单、稳定的高可用性和容灾保护方案。这篇文章谈谈如何管理Oracle 11g Data Guard环境中的归档日志。 归档日志是重要的，备份恢复需要它，而Data Guard也需要它。在早期版本的Data Guard环境中，常常面临着归档日志管理问题,，但11g做
在开发环境及UAT环境经常碰到需要清除归档日志的情形，对于这个问题方法有很多。可以直接使用rm方式清除归档日志，也可以使用find命令来查找符合条件的记录来清除归档日志，或者直接写个shell脚本来搞定。这样在DEV或者UAT还可以，但是在Prod环境还是建议使用RMAN提供的命令来搞定比较妥当。因为rm，find方式删除了实际的归档日志也释放了空间，但对应的存储在控制文件中的归档信息并没有彻底清除。依旧占用着一些空间未能及时清除而需要控制文件通过age out方式来释放空间。本文描述了使用RMAN方式来清除归档日志，同时也可以将其部署到shell脚本中使用。
听说过还原(restore)数据库，表空间及数据库文件，使用归档日志恢复(recover)数据库，表空间，数据库文件。咦，还有还原归档日志这一说法呢？没错，可能我们忽略了还原归档日志这一个过程，原因是还原归档日志通常情况下是oracle在recover时自动完成的。大多数情况下我们是先还原数据库，恢复数据库，打开数据库。实际上在恢复数据库之前有一个动作，那就是还原归档日志，也就是将日志文件还原到缺省的归档位置，如果我们在备份归档日志时使用了delete [all] input子句的话。本文对此给出了单独还原归档日志以及恢复归档日志的示例以及restore archivelog的一些用法，仅仅是为了更好来的理解还原与恢复的过程，因为大多数情形下,数据文件被还原到缺省路径。如果是还原到非缺省路径，那就需要手动restore archivelog。
Oracle 11g中对于归档日志的删除，除了遵循RMAN保留策略外，也可以通过RMAN来配置归档日志的删除策略，也就是归档日志何时可以被删除。归档日志删除策略适用于所有归档位置(使用快速闪回区FRA/不使用FRA)。本文主要描述归档日志删除策略并给出了具体的演示。
最近检查测试机器（Linux6-Oracle112040 RAC）ASM目录发现归档日志有断档，目录里遗留了2019、2020年的一些不连续归档。断档的这一部分在控制文件中没有记录，故此归档文件一直没有被发现。这些不连续的归档日志都属于无效日志，需要清理。
在 Oracle 12.2 之前，当我们需要恢复数据库到某个时间点的时候，需要确定 SCN，或者日志序列号，或者一个时间点，以便尽可能多的应用归档日志，进而尽可能多的恢复数据。 从12.2开始，RMAN 新增参数： RECOVER DATABASE UNTIL AVALIABLE REDO RMAN 将会根据控制文件信息和归档日志/在线日志/归档日志备份集的物理可用性，将数据库恢复到最后一个可用的归档日志。所以在进行恢复的时候，可以不需要指定 SCN，或者时间,或者日志序列号。需要注意的是，数据文件仍然需要
查看当前归档日志路径，空间的使用率已经到了100%，于是在rman中，删除30天之前的归档日志文件，
由于业务增长，频繁的备份还原对于磁盘空间有了更大的空间需求，基本每周500G的磁盘，空间使用率都会达到85%以上，故编写Oracle清理脚本结合crond自动清理Oracle归档日志。
数据库重新启动的时候，收到了ORA-19815的错误。从错误的提示来看，是由于闪回区的空间被填满导致无法成功启动。这种情形我们通常考虑的是清除归档日志，那就直接在OS层面rm了，真的是这样吗？客官，如果你有相同的情形，接下往下看......
之前在《Win环境下Oracle小数据量数据库的物理备份》这篇文章中，介绍了在win平台下对于小数据量的数据库的物理备份设计。 文中重点提到，强烈建议备份文件有单独的存储,防止存储单点故障时备份文件亦不可用。 当我在实验环境实际去模拟这种使用单独存储的环境时，出现意料之外的问题：备份到映射的盘符无法成功，报错如下：
对于基于日志复制的主备数据库来说，由于配置不当或者备库空间问题造成主数据库的日志被自动清理，造成主备数据库同步中断，对于管理人员来说，也许就是一种失责甚至灾难(如果主发生故障),同样基于日志复制的同步软件来说，存在同样的问题，日志由于各种原因被删除,造成同步数据被中断，如果有定时备份日志，无非就是延迟的问题，如果无日志，可能重新初始化，尤其对于架构复杂以及多链路的复制，修复数据也是头疼事情。
最近在某银行进行OGG迁移时，遇到一个超过1T的数据库，由于开始没有注意到一些细节，导致在导入过程中出现了一些问题。现在将这些问题总结记录下来，防止之后再发生类似问题。
Oracle 开启归档模式后，会一直不停的产生归档日志，如果不定时删除，迟早会撑爆磁盘空间，所以就需要布置定时删除归档日志的脚本！
最近在因归档日志暴增，使用delete archivelog all貌似无法清除所有的归档日志，到底是什么原因呢？
DB2日志是以文件的形式存放在文件系统中，分为两种模式：循环日志和归档日志。当创建新数据库时，日志的缺省模式是循环日志。在这种模式下，只能实现数据库的脱机备份和恢复。如果要实现联机备份和恢复，必须设为归档日志模式。
对任何数据库系统而言，对显而易见的故障，应当避免发生本文列出了Oracle常见的故障并给出了解决方案，同时列出了一些日常规划。
编辑手记： LogMiner是用于Oracle日志挖掘的利器，使用该工具可以轻松获得Oracle 重做日志文件（归档日志文件）中的具体内容，LogMiner分析工具实际上是由一组PL/SQL包和一些动态视图组成，它作为Oracle数据库的一部分来发布，是oracle公司提供的一个完全免费的工具。本文主要演示LogMiner的使用，直观展示LogMiner的作用。 环境：Oracle 11.2.0.4 RAC 1.查询当前日志组 2.业务用户插入操作 3.归档日志切换 4.业务用户插入操作 5.归档日志切换
在 Oracle 归档模式下直接 rm data.dbf 数据文件并重启数据库还有救吗？为何会有这样的问题，要追溯到上周一位朋友咨询的事情，他那里一个 Oracle 单机的环境因为表空间不足了，需要扩容表空间，则通过添加表空间数据文件的命令加入了一个数据文件，执行成功后呢便可以继续写入数据了。
RMAN使用服务器会话来完成备份操作，从RMAN客户端连接到服务器将产生一个服务器会话
1、备份保留策略rman连接到 RMAN 管理工具, rman 默认配置[oracle@orcl:/home/oracle]$ rman target /Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jun 15 13:11:22 2022Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.connected to target datab
Oracle闪回区已经有了好几载的岁月了，在10g的时候就被推出一直延续到现在。Oracle闪回区是为RMAN准备的，尽管抛开它我们可以同样完成数据库备份恢复的相关工作，Oracle依旧强烈推荐使用且它让其成为RMAN的组件之一。这是因为该区域可集中简化管理所有和备份恢复工作，这也是其魅力所在。本文描述了Oracle闪回区的特性及其配置闪回区，监控闪回区等。
执行备份或还原的数据库称为目标。在一些环境下，有许多数据库，因此有许多RMAN目标。应一次连接每个数据库。目标的每个备份都有一些属性：
我们坑你遇到的失败或错误分为两大类：物理和逻辑。物理错误一般是硬件错误或使用数据库的应用程序中的软件错误，而逻辑错误一般在终端用户级别（数据库用户和管理员）。
遇到的失败或错误分为两大类：物理和逻辑。物理错误一般是硬件错误或使用数据库的应用程序中的软件错误，而逻辑错误一般在终端用户级别（数据库用户和管理员）。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/53905885
当数据库处于非一致状态的备份就是非一致性备份。 实例失败， shutdown abort，数据库打开的时候进行的备份是非一致性备份
Oracle随着版本的升级，逐渐将步骤缩减，进行封装，18C之后可谓是达到了所谓的一键刷新，恢复DG同步。
对于 Oracle 数据库的备份与恢复，尽管存在热备，冷备以及逻辑备份之外，使用最多的莫过于使用RMAN进行备份与恢复。而制定RMAN备份策
其实帮助很多的朋友解决过Oracle数据库数据不同步的问题，看似简单的问题分析出来的原因也是五花八门。比如： Oracle数据库问题的一点总结 在查看一些没有专业DBA维护的数据库的时候，会发现很多的潜在问题，有些可能无伤大雅，看起来是不规范不标准的问题，倒不会直接造成问题，而有些问题会让人后背发凉，正如同歌词里唱的，一旦错过就不再，这里说的就是数据，所以也希望大家能够在一些案例中得到启发和参考，避免在自己的系统中重演。 先啰嗦一句，尽管在Oracle命令行下敲过命令了，但是完整的命令和思路还算清晰，所以大
通常在当前控制文件丢失，或者当前的控制文件与需要恢复的控制文件不一致的情况下，我们需要重新创建一个控制文件或者使用 unsing backup controlfile方式来恢复控制文件。说简单点，只要是备份的控制文件与当前的控制文件不一致进行恢复数据库，就需要使用到 unsing backup controlfile方式，而一旦使用了该方式，则需使用resetlgos选项来打开数据库。
如何知道是否开启了实时应用呢？可以查询V$LOGSTDBY_STATE视图或查询是否有lsp进程。
在Oracle中，闪回恢复区（Fast Recovery Area，FRA）是什么？如何监控FRA？
最近的RAC环境中遭遇ORA-00254，ORA-15173，即无法进行归档。通常情况下归档失败我们考虑更多的是归档路径的不可达，或归档所在的磁盘空间不足造成的。在使用 ASM 存放归档日志的情形下，对于已经配置好且成功归档的数据库也提示路径不可达？看看到底是怎么一回事。
在Oracle数据库中，数据库可以设置为归档模式和非归档模式。归档模式保存所有的事务日志，包括在线Redo日志和归档日志，而非归档模式没有归档日志，只有在线Redo日志。归档模式是指可以备份所有的数据库事务并恢复到任意一个时间点。非归档模式则相反，不能恢复到任意一个时间点，但是非归档模式可以带来数据库性能上的少许提高，因为非归档模式没有归档日志。DBA必须做出的一个重要决策是将数据库配置为在ARCHIVELOG模式下运行还是将其配置为在NOARCHIVELOG模式下运行。。
这是一个单实例数据库，oracle11.2.0.4 ，跑在Wondows上，当时主库压力太大，用户有容灾和读写分离的需求，这样在主库跑了一段时间后搭建了一个备库，这个备库一直跑到很好，最多主库由于存储压力，删除过几个归档日志，这个删除也是确认了备库应用之后操作的，对主备都已经没有影响。所以，当这家南方公司的负责人（我就称为王工）找到我时，我还是觉得意外。
对于DEV以及UAT环境，有些时候，数据库需要处于归档模式，但并不需要备份数据库。因此，archive归档日志不停的增长导致磁盘空间被大量耗用。对于这种情形，可以使用一个shell脚本来定时自动清除这些归档日志。本文给出了清除归档日志的脚本。
Oracle可以将联机日志文件保存到多个不同的位置，将联机日志转换为归档日志的过程称之为归档。相应的日志被称为归档日志。
我们不管在生产环境还是开发环境，看日志是必不可少的，日志中往往包含很多有用的信息，有时候被DDOS、上传非法文件等等，我们都需要通过日志分析。但是日志是跟访问量成正比的，你的访问量越大，你的各种级别日志就越多，日志文件大小会增长极快，服务器会很快消耗磁盘空间，这成个很严重的问题。不仅是这个，如果你是一个日志文件的话，你阅读、打开都要花费很大力气，那么怎么才能处理好这种情况？
从这期开始讲Oracle Data Guard方面的内容，先将基本的概念，然后介绍如何搭建Data Guard
日志文件包含系统内部执行情况的有用信息。在排除故障或服务器性能分析时往往需要检查日志。对于繁忙的服务器，日志文件可能会在短时间内变得非常大。这将成为一个问题，因为服务器会很快耗尽存储空间。此外，操作一个非常大的日志文件往往会非常棘手。 logrotate 是可以自动转储、压缩和删除旧日志文件的一个非常有用的工具。例如，你可以设置logrotate将日志文件 /var/log/foo的每30天转储一次，并且删除超过6个月的记录。一旦配置完成，logrotate可以完全自动化操作不需要进行人工交互 在主要
当主库的某些日志没有成功传送到备库，那么这时候就发生了归档裂缝（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处理。
看到这报错，很简单对吧，找不到归档日志，便报错了，基本上没什么可说的，但对于初学者而言，还是记录以下，以便后来者参考。先说说这个错误怎么来的吧，事情的经过是这样的（回忆片段走起），上周四晚上回家途中，马上要下地铁了，手机微信里出现了一大片关于数据库的告警，数一数有 7 套数据库同时告警，感觉出大事了，后来说是存储那边出问题了，经过一天的修复，只剩下一台机器有问题了，操作系统无法启动，也修复不了，幸好修复不了的机器只是我们数据库的一个节点，可这就造成了我们其中的一台数据库由RAC 变成单点了。
近日，在给客户做了单机到集群的数据迁移后，发现集群的在线重做日志切换频繁，进而产生了大量的归档日志，对服务器造成了不小的压力。本文是对上述问题的分析处理过程。
本篇梳理DG的架构和一些概念知识，重新梳理的目的是加强理解，也方便复习，基于11gR2版本写的，不包含12c新特性。如果能帮助到新接触DG的朋友，那就再好不过。
这里当前日志（current）是： thread 1 sequence 30 thread 2 sequence 25
在前两篇文章中描述了中小型数据库使用RMAN catalog设计备份与恢复方案，并给出了所有相关的脚本来从某种车程度上模拟Oracle Data Guard以减少硬件故障带来Prod服务器上数据库损失。在这边文章中主要描述Prod数据库的变迁在Bak server端如何进行恢复。
ORA-03113: end-of-file on communication channel
领取专属 10元无门槛券
手把手带您无忧上云
