当数据库检测出内部错误时,会在告警日志内输出相关的错误代码,并输出相关的跟踪日志文件和事件日志文件。
英文解析:resource busy and acquire with NOWAIT specified
RFS(Remote File Server)进程主要用来接受从主库传送过来的日志信息。对于物理备库而言,RFS进程可以直接将日志写进Standby Redo logs,也可以直接将日志信息写到归档日志中。一般可以在主备库的告警日志中看到如下的信息:
Last Updated: Monday, 2004-11-15 10:32 Eygle
在ORACLE中移动数据库文件 --ORACLE数据库由数据文件,控制文件和联机日志文件三种文件组成。 --由于磁盘空间的变化,或者基于数据库磁盘I/O性能的调整等, --我們可能会考虑移动数据库文件。 --下面以LUNIX平台为例,分别讨论三种数据库文件的移动方法。 一.移动数据文件: -- 可以用ALTER DATABASE,ALTER TABLESPACE两种方法移动数据文件。 1. ALTER DATABASE方法; -- 用此方法,可以移动任何表空间的数据文件。 STEP 1. 下数据
RAC环境下的归档模式切换与单实例稍有不同,主要是共享存储所产生的差异。在这种情况下,我们可以将RAC数据库切换到非集群状态下,仅仅在一个实例上来实施归档模式切换即可完成RAC数据库的归档模式转换问题。本文主要描述了由非归档模式切换到归档模式,而由非归档切换的归档步骤相同,不再赘述。
我的实验环境: 源生产库(主库): IP地址:192.168.1.30 Oracle 10.2.0.5 单实例
众所周知我们的Data Guard数据同步是基于日志流的。所以在主库执行nologging操作是不被允许的。这也就是为什么我们需要在配置Data Guard阶段需要使用Force Logging。但是这也会带来很多问题(SQL执行效率),例如:当我们使用数据泵进行迁移时我们希望最少停机时间完成,这时候我们就可能会考虑到以最小日志导入的方式以加快导入速度,然后重新同步备库。
近日有一套实时同步的 ASM 管理的单机 11204 ADG 备库,由于业务需要,想要脱离主库的约束,想激活拉成读写库直接升级成 ASM 管理的 19C,闪回快照模式无法满足要求,只能 ALTER DATABASE ACTIVATE STANDBY DATABASE 强制切成可读写的主库。说干就干,先将其切成主库,升级过程等下次在一起讨论。
在Oracle中,如何修复由于主库NOLOGGING引起的备库ORA-01578和ORA-26040错误?
当主库的某些日志没有成功传送到备库,那么这时候就发生了归档裂缝(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处理。FAL进程只在物理备库存在。FAL进程提供了一个CLIENT/SERVER的机制,用来解决检测在主库产生的连续的归档日志,而在备库接受的归档日志不连续的问题。该进程只有在需要的时候才会启动,而当工作完成后就关闭了,因此在正常情况下,该进程是无法看见的。
--==========================================
AIX 操作系统因 MTU 不一致导致主机和 RAC 数据库不断重启,事件就是发生在上周日。操作系统工程师因监控发现有一台主机不断重启,排查硬件后无问题,便将事件转至数据库工程师排查了。当时我接到的这个主机是一套不太重要的 SVC 存储复制的灾备环境,基本上没有业务使用,所以也就比较从容,慢慢排查问题。RAC 数据库是 11.2.0.4 版本的,操作系统是 AIX 7.1 版本,如下图:
听说过还原(restore)数据库,表空间及数据库文件,使用归档日志恢复(recover)数据库,表空间,数据库文件。咦,还有还原归档日志这一说法呢?没错,可能我们忽略了还原归档日志这一个过程,原因是还原归档日志通常情况下是oracle在recover时自动完成的。大多数情况下我们是先还原数据库,恢复数据库,打开数据库。实际上在恢复数据库之前有一个动作,那就是还原归档日志,也就是将日志文件还原到缺省的归档位置,如果我们在备份归档日志时使用了delete [all] input子句的话。本文对此给出了单独还原归档日志以及恢复归档日志的示例以及restore archivelog的一些用法,仅仅是为了更好来的理解还原与恢复的过程,因为大多数情形下,数据文件被还原到缺省路径。如果是还原到非缺省路径,那就需要手动restore archivelog。
在前两篇文章中描述了中小型数据库使用RMAN catalog设计备份与恢复方案,并给出了所有相关的脚本来从某种车程度上模拟Oracle Data Guard以减少硬件故障带来Prod服务器上数据库损失。在这边文章中主要描述Prod数据库的变迁在Bak server端如何进行恢复。
很多刚入行的DBA往往一看有ORA-600这类错误就不知所措,直接就想寻求中高级DBA支持,甚至在网上还看到有人说,判断一个Oracle DBA是否达到中级以上,就是看其是否可以独立思考处理ORA-600这类问题,而实际上ORA-600这个错误集合中的确有很多跟bug相关,有些甚至是MOS也搜不到的,但同样也有很多是很简单的,并不需要你去深入分析trc,比对call stack匹配bug什么的。就比如今天遇到的一则案例,客户发现DG备库应用出现了问题,进一步查看告警日志发现有报错ORA-600[2619],并因此导致mrp进程异常终止。
有的时候由于备库空间不足,在主库添加了数据文件后,导致备库数据文件的缺失,可能很久之后才发现,但是由于归档的缺失等其它原因而导致备库不能正常应用Redo日志。还有其它情况可能导致备库的数据文件不能正常ONLINE,在这种情况下,可以在主库上利用CONVERT命令备份一个数据文件然后拷贝到备库即可。若是备库归档文件比较全,则可以直接在备库创建数据文件后应用Redo日志即可,而不需要从主库拷贝数据文件。
一 系统环境: 1、操作系统:oracle Linux 5.6 2、数据库: Oracle 11g 二 Oracle 重做日志的作用: [模拟介质恢复] 1. 关闭数据库归档模式: [oracle@test ~]$ sqlplus /nolog SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 6 23:49:30 2017 Copyright (c) 1982, 2009, Oracle. All rights reserved. SQL>
主库(Primary Database)在运行过程中,会源源不断地产生Redo日志,这些日志需要发送到备库(Standy Database)端。这个发送动作可以由主库的LGWR或者ARCn进程完成,不同的归档目的地可以使用不同的方法,但是对于一个目的地,只能选用一种方法。选择不同的进程在数据保护能力和系统可用性方面有很大区别。如果使用LGWR进程来传递日志,但是由于某些原因,LGWR进程变得无法归档到目的地了,那么重做传输将会使用ARCn进程来完成归档操作。
在Oracle中,Redo日志文件包含所有的数据库变化历史记录,例如所有的DML变化(INSERT、UPDATE、DELETE和SELECT FOR UPDATE)和所有DDL语句造成的数据字典对象的更改及递归语句的更改等,所以redo文件可以最大限度地保证数据的一致性与安全性。万一数据库出现故障可以启用数据恢复。但是redo日志被误删了怎么办呢?本文通过一个案例来了解一下redo日志被误删,强制开库遭遇ORA-16433,供大家参考。
昨天写了一篇停库没有响应的问题分析,其实对于我来说,还是有些不太踏实,里面有几点需要改进。 因为是测试环境,所以操作的时候就随意了一些,如果是生产环境,直接kill进程是很不规范的。对于启库停库的时间把握,只是感觉有延迟,但是延迟究竟有多大还是不够严谨;问题的原因最后没有给出很清晰的答案,主要是因为后面自己没有经过大量的测试,所以这个地方还是不够严谨。 我们来继续分析一下。 目前的问题可以简化为两个:停库慢,启库慢。 我们来逐个击破。 首先是停库慢,shutdown immediate之后,就没有任何反应了
差异增量备份(Differential Incremental Backup)模式(默认): LV0:全备。 LV1:最近一次LV0或LV1至今的变化。 LV2:最近一次LV0或LV1或LV2至今的变化。 优缺点:速度较快、因为仅存储少量变化的块、但需要更长的时间来恢复
分析Oracle数据库日志文件(1) 一、如何分析即LogMiner解释 从目前来看,分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner来进行, Oracle数据库的所有更改都记录在日志中,但是原始的日志信息我们根本无法看懂,而LogMiner就是让我们看懂日志信息的工具。从这一点上看,它和tkprof差不多,一个是用来分析日志信息,一个则是格式化跟踪文件。通过对日志的分析我们可以实现下面的目的: 1、查明数据库的逻辑更改; 2、侦察并更正用户的误操作; 3、执行事后审计;
原文链接:http://www.eygle.com/blog/special/oracle_recovery.html
相信大家在Dataguard环境中遇到过主库丢失归档日志,而备库也没有及时接收,导致备库出现了GAP的现象。因为日志的中断,备库无法再去应用之后的日志,就无法起到容灾的效果。
Oracle故障诊断有助于预防,检测,诊断和解决问题。特别针对的问题是诸如由代码错误,元数据损坏和客户数据损坏引起的重大错误。
oracle在启动时和启动过程中经常会出现这样那样的错误,简单记录下碰到过的问题,方便备用。
AIX 操作系统因 MTU 不一致导致主机和 RAC 数据库不断重启,事件就是发生在上周日。操作系统工程师因监控发现有一台主机不断重启,排查硬件后无问题,便将事件转至数据库工程师排查了。当时主机是一套 SVC 存储复制的灾备环境。 RAC 数据库是 11.2.0.4 版本的,操作系统是 AIX 7.1 版本,如下图:
修复由于主库NOLOGGING操作引起的备库ORA-01578和ORA-26040错误
故障概述 某天晚上,我方收到行方请求协助分析某数据库两节点RAC数据库问题,问题描述如下: 该 数据库版本为11.2.0.3,该版本中ASM内存管理机制有所变化,导致ASM实例对共享内存的需求加大,由于该数据库ASM实例共享内存设置过小,导致ASM实例间歇性出现ORA-4031共享池无法分配连续内存空间。为解决该问题,行方决定调整ASM实例内存参数,而在首先修改节点2 ASM内存参数并重启节点2 grid集群过程中,发现节点1 grid集群状态异常,并且在重启节点2集群后,查看节点1 grid集群状态依然报
–sql>alter database mount (读取控制文件),没有实例恢复。
在Oracle DataGuard部署过程中,如果操作不规范,可能遇到很多想不到的问题。有些问题是配置参数不到位,有些是操作不规范遗漏导致。
最近测试了使用datapump来迁移百G数据的场景,因为实际需要,需要把Unix下10gR2的库迁移到Linux下11gR2,所以这个过程相对来说牵制也较多。考虑了多种方案,最后权衡后决定使用datapump来迁移。 其实整个迁移的过程还算顺利,完整模拟了整个生产环境的迁移情况,datapump的全库导入还是比较方便省心,只要导出得当,导入基本不需要太多的检查 选项,导入的过程中的可操作选项也非常有限。如果数据库里存在大量的结构信息,而且关系错综复杂,使用datapump还是比较通用快捷。 datapump
SYSTEM表空间是Oracle数据库最重要的一个表空间,存放了一些DDL语言产生的信息以及PL/SQL包、视图、函数、过程等,称之为数据字典,
在虚机上执行lsnrctl start,问题解决。 1、当连接异常时,可以通过分析监听日志来查找线索 〜[test]$ find $ORACLE_HOME -name listener.log /opt/64bit/oracle/11.2.0/log/diag/tnslsnr/sinrndvud062/listener/trace/listener .log
背景:这里提到的常规恢复指的是数据库有完备可用的RMAN物理备份。 实验环境:RHEL6.4 + Oracle 11.2.0.4 单实例.
Oracle数据库实例的启动,严格来说应该是实例的启动,数据库仅仅是在实例启动后进行装载。Oracle数据启动的过程被划分为
Oracle DataGuard 升级 [11.2.0.1 -> 11.2.0.4] Primary: 11.2.0.1 单机,Site A。 Standby: 11.2.0.1 单机,Site B、Site C。 当前DG环境示意图:
看到这报错,很简单对吧,找不到归档日志,便报错了,基本上没什么可说的,但对于初学者而言,还是记录以下,以便后来者参考。先说说这个错误怎么来的吧,事情的经过是这样的(回忆片段走起),上周四晚上回家途中,马上要下地铁了,手机微信里出现了一大片关于数据库的告警,数一数有 7 套数据库同时告警,感觉出大事了,后来说是存储那边出问题了,经过一天的修复,只剩下一台机器有问题了,操作系统无法启动,也修复不了,幸好修复不了的机器只是我们数据库的一个节点,可这就造成了我们其中的一台数据库由RAC 变成单点了。
今天碰到一个有些奇怪的问题,但是奇怪的现象背后都是有本质的因果。 下午在做一个环境的检查时,发现备库是在mount阶段,这可是一个11gR2的库,没有ADG实在是太浪费了,对于这种情况感觉太不应该了。 所以尝试启动至open阶段,发现状态一直是read only,在ADG中应该是READ ONLY WITH APPLY才对啊。 使用dg broker设置为READ-ONLY,备库的数据库日志如下: Standby Database: stestdb3, Enabled Phys
近期我们对DBASK小程序进行了升级,UI交互做了重大优化调整,对注册用户开放知识库全文检索功能,引入数据和云公众号文章,提问时自动关联知识库已知问题,专栏可生成图片分享给好友,欢迎大家通过微信搜索DBASK体验。
Windows环境下的Oracle 11g在一次关机后,无法正常启动,且无法启动到mount状态,一直提示:
今天在火车上接到一个电话说,数据库有个报警,让我看看是怎么回事。 看着报警信息一直重复出现,看来是有些问题了。 这是一个统计库,出现了DG相关的报警(自定义配置的),看起来是备库端接收归档的时候出现了问题。 Error 270 creating remote archivelog file 'sgstatdb3' 我们知道备库端其实是有一个80%的阈值控制闪回区的,当时限于在火车上,网络,信号不顺畅,所以让同事帮忙看了下,大体是说闪回区满了,但是系统层面设置了crontab定期去删除归档,每
通常在当前控制文件丢失,或者当前的控制文件与需要恢复的控制文件不一致的情况下,我们需要重新创建一个控制文件或者使用 unsing backup controlfile方式来恢复控制文件。说简单点,只要是备份的控制文件与当前的控制文件不一致进行恢复数据库,就需要使用到 unsing backup controlfile方式,而一旦使用了该方式,则需使用resetlgos选项来打开数据库。
Oracle 数据库可以实现数据库不完全恢复与完全恢复。完全恢复是将数据库恢复到最新时刻,也就是无损恢复,保证数据库无丢失的恢复。而不完全恢复则是根据需要特意将数据库恢复到某个过去的特定时间点或特定的SCN以及特定的Sequence。我们可以通过基于用户管理的不完全恢复实现,也可以通过基于RMAN方式来实现。本文主要描述是基于RMAN的不完全恢复的几种情形并给出示例。有关数据库备份恢复,RMAN备份恢复的概念与实战可以参考文章尾部给出的链接。
环境:Linux + Oracle 11.2.0.1 ADG 现象:发现备库没有应用日志
题记:一些用户在使用 Oracle Database 12.1 版本时(包含12.1.0.1 和 12.1.0.2 初始版本),再次遭遇到一个『专门为 AIX 定制的BUG』,这个BUG的影响非常大,再次提醒大家关注。 前一段,我们发布过一篇文章,题目是:一个专为AIX上11.2.0.4版本定制的Bug正在高发 ,很多朋友回复遇到过这个BUG,并且开始做出修正。最近,随着 12c 用户的逐渐增多,这个版本中的问题也在逐渐的呈现出来。 一些用户在使用 Oracle Database 12.1 版本时(包含12
同事说dg不能同步,让我帮忙看看,我用自己写的2个视图查看了下,首先发现主库没有常见的LNSn进程,下意识的认为主库这个进程没有启动,需要切换日志唤醒LNSn进程,事实上也这样做了,(alter system set log_archive_dest_state_2='defer'; alter system switch logfile; alter system set log_archive_dest_state_2='enable'; alter system switch logfile;),切换后发现日志可以正常传输了,但是主库还是看不到LNSn这个进程,于是找找资料,深入的研究了一下这个问题。
五一放假期间,某客户的数据库出现故障,据说对方找了一些工程师折腾了一天,都无法将数据库open,其中参考了网络上的很多文章,也使用了一系列隐含参数,均无法将数据库打开。这里我简单的与大家分享一下这个c
本文作者系肖遥(花名),现任甲骨文技术支持工程师 ,目前专注于Oracle RAC领域。个人主页:
领取专属 10元无门槛券
手把手带您无忧上云