墨墨导读:某客户单位数据库出现异常,大致现象是:数据库状态是open的,但是其中一个数据文件无法访问,本文分享排查原因与解决问题的整个过程。
跟踪文件(Trace File)一般位于“user_dump_dest”参数所指定的目录中,具体路径可以通过以下几种方式查询获得。
在Oracle RAC环境中,对集群中的日志进行定期检查是必不可少的。通过查看集群日志,可以早期定位集群环境中出现的问题,以便将问题消灭在萌芽状态。下面简单介绍一下有关Oracle集群环境中日志的结构,有助于方便快速地查找所需的日志文件。
Oracle Net trace 用于跟踪或调试oracle连接故障,连接异常断开或者连接超时等情形,通过产生详细的跟踪信息来进行分析和诊断Oracle Net相关故障。关于这个网络调试主要是通过为相关的网络配置文件添加相关的参数来实现。MetaLink上ID 219968.1有详尽的描述。
杨廷琨(yangtingkun) 云和恩墨 CTO 高级咨询顾问,Oracle ACE总监,ITPUB Oracle数据库管理版版主 这是一则生产环境的真实维护过程,由于RAC的测试环境空间不足,因此规划给ASM扩展空间,然而在给ASM添加新的磁盘空间时又出现了故障,这类问题在很多用户的生产环境中可能也会遇到。 空间扩展的操作步骤如下: 在RAC环境的节点1上启动了DBCA工具来管理ASM设备; 由于新增的裸设备在ASM图形界面下看不到; 通过root用户将裸设备的访问权限授予了操作系统上的Oracl
本文发表于itpub技术丛书《Oracle数据库DBA专题技术精粹》,未经许可,严禁转载本文.
戴明明(Dave) Oracle ACE-A,ACOUG核心成员,宝存科技数据库方案架构师 Dave也是CSDN 认证专家,超过7年的DBA经验,擅长Oracle数据库诊断、性能调优,热衷于Oracl
Oracle 18C 引入了只读 Oracle 主目录的概念,其中所有配置和日志文件都可以与 Oracle 二进制文件分开保存。
链接:http://www.eygle.com/archives/2010/06/asm_format_dictionary.html
昨天到公司之后,收到两份封报警邮件,可以看到在早晨6:30左右主库的v$dataguard_status检查时发现了一个错误。然后再2分钟后就自动恢复了。 一般这种问题很自然想到可能是网络出现了一些问题。因为自动恢复了,所以也不同太着急处理,于是细细看了下。 报警邮件如下: ZABBIX-监控系统: ------------------------------------ 报警内容: DG_issue ------------------------------------ 报警级别: PROBLEM --
仅仅需要标识该会话并为该会话启用跟踪(专用模式为一对一模式,即一个用户进程对应一个服务器进程)
当我们想了解一条SQL或者是PL/SQL包的运行情况时,特别是当他们的性能非常差时,比如有的时候看起来就好好像卡在什么地方一样,该如何入手呢?
环境:Solaris 10 + Oracle 11.2.0.1 现象:alert告警日志定期出现ORA-600 [13011]错误
墨墨导读:一套Oracle RAC环境运行在HW超融合环境中,由于硬件问题导致数据库crash,期间出现了不少数据坏块,本文详述整个恢复过程,希望对大家有帮助。
崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 编辑手记:感谢崔华授权我们独家转载其精品文章,也欢迎大家向“Oracle”社区投稿。 我们都知道在 Oracle 数据库里是“读不阻塞写,写不阻塞读”,那么是否可以认为在正常情况下,select 操作是怎样都能执行,始终不会被 hang 住的呢?注意这里提到的是正常情况下,不包括那些由于 latch 被 hold 住、或者 bug 等相关异常导致的 select 操作 hang 住的情况。 答案是:不可以这样认为
原作者:Bane Radulovic 译者: 魏兴华 审核: 魏兴华 DBGeeK社区联合出品 原文链接:http://asmsupportguy.blogspot.sg/2015/12/asm-data-scrubbing.html 根据维基百科, 数据清理(data scrubbing)的定义是“一种数据纠错技术,利用后台任务周期性的扫描内存或存储的错误,在检测到错误后利用数据的多余副本来对数据进行纠正,数据清理可以减少数据错误不断累计的可能性,进而降低由数据错误带来的风险”。 数据清理(
1. 设置ADR 2. 使用Support Workbench 3. 恢复块介质 Reference
张乐奕 云和恩墨副总经理 Oracle ACE 总监 ITPUB Oracle数据库管理版版主、Oracle高可用版版主、ACOUG联合创始人 今天收到一个发过来请求帮助的 case,Oracle 数据库无法启动,请求帮助恢复。仔细阅读了发过来的告警日志,这是一个典型的“事情越弄越糟”的案例。 作为一个专业的DBA,在遇到问题时,一定要思考:如何保护现场,不让事情变得更糟。这是基本要求,保护现场以使得其他人接手工作时,可以从原有状态开始。 以下就来根据告警日志,一条一条地回顾这位 DBA 是如何将数据
http://www.eygle.com/faq/How.To.Get.Tracefile.Name.htm
当数据库检测出内部错误时,会在告警日志内输出相关的错误代码,并输出相关的跟踪日志文件和事件日志文件。
SQL> select status from v$instance; STATUS ------------ MOUNTED SQL> ALTER DATABASE OPEN; ALTER DATABASE OPEN * ERROR at line 1: ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
最近碰到了一个oracle bug,但是我感觉还是有些运气的成分,虽然错误日志和bug描述吻合,版本也完全对应,现在有几个问题在我脑海中翻腾,就是这个问题是不是一个特例,是不是一些额外的原因导致的,于是我翻出了日志重新来看。 这是一个一主两备的环境,一个本地灾备,一个异地灾备,数据库版本是10.2.0.4.0,单实例 数据库日志如下: Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[8]: Assigned to
续上篇:http://blog.csdn.net/bisal/article/details/39225373
最近的alert日志中碰到了ORA-27090的错误信息,其错误提示为Unable to reserve kernel resources for asynchronous disk I/O。根据这个提示来看是跟异步I/O相关的内核参数问题。下面是这个问题的描述与解决。
作者 | 张维照,Oracle ACEA,2006年起从事数据库管理工作,2009年转 Oracle,从事过多套 TB 级省级工商、医疗、交通、人社、电信运营等数据库维护优化工作,擅长Oracle 数据库性能问题的分析与解决,Oracle数据库故障分析,Oracle数据库升级迁移。
在一套2节点的19c RAC 环境下,节点2 alert告警 ORA 7445,且频度固定为每分钟报一次;期间有重启实例,但故障依旧:
这是一个单实例数据库,oracle11.2.0.4 ,跑在Wondows上,当时主库压力太大,用户有容灾和读写分离的需求,这样在主库跑了一段时间后搭建了一个备库,这个备库一直跑到很好,最多主库由于存储压力,删除过几个归档日志,这个删除也是确认了备库应用之后操作的,对主备都已经没有影响。所以,当这家南方公司的负责人(我就称为王工)找到我时,我还是觉得意外。
Errors in file /u01/app/oracle/diag/rdbms/orcldg3/orcl/trace/orcl_m000_9167.trc:
昨天写了一篇停库没有响应的问题分析,其实对于我来说,还是有些不太踏实,里面有几点需要改进。 因为是测试环境,所以操作的时候就随意了一些,如果是生产环境,直接kill进程是很不规范的。对于启库停库的时间把握,只是感觉有延迟,但是延迟究竟有多大还是不够严谨;问题的原因最后没有给出很清晰的答案,主要是因为后面自己没有经过大量的测试,所以这个地方还是不够严谨。 我们来继续分析一下。 目前的问题可以简化为两个:停库慢,启库慢。 我们来逐个击破。 首先是停库慢,shutdown immediate之后,就没有任何反应了
任何软件都不是完美的,oracle也是如此,隔一段时间就会收到oracle的邮件说建议打哪些安全补丁什么的。新发布的产品都是release 1,比如10gR1,稳定版本都在10gR2 不要小看着两个大版本的变化,印象比较深的就是10g 10.2.0.1的安装包有大概600多M,但是在10.2.0.2.0的补丁包就比安装包还多,可见在产品线内做了很多的修改,才使得数据库越来越稳定。 昨天下午在检查一个问题的时候,发现数据库日志报出了ora-600的错误,这种症状不清的错误只能求助于metalink了。
另外需要实现建好本地外层路径,更改路径后在Linux下也可执行。也可以使用pyinstaller打包成exe执行。
环境:Linux + Oracle 11.2.0.1 ADG 现象:发现备库没有应用日志
李磊 云和恩墨技术专家 每一个接触过 Oracle 数据库的人想必听到 Ora-04031 都会有一种捶胸顿足的感觉,至少在两年前的我是这样子的。都说 Ora-04031 和 Ora-01555 等是 Oracle 的经典错误,之所以成为经典,可能就是因为它们会经常出现,却又不是那么好解决的缘故吧。今天我就跟大家分享一个我工作当中的4031案例,解读一下4031的前世今生,希望通过今天晚上的交流,当我们再次遇见4031错误时不再像之前那么恐惧。 本次跟大家分享的这个案例是去年我在某电力公司驻场的时候,某天
2019-01-12T10:10:11.499130+08:00 Errors in file /u01/app/Oracle/diag/rdbms/rac1/rac112/trace/rac112_j000_119621.trc: ORA-12012: error on auto execute of job "SYS"."ORA$AT_OS_OPT_SY_7458" ORA-20001: Statistics Advisor: Invalid task name for the current user ORA-06512: at "SYS.DBMS_STATS", line 47207 ORA-06512: at "SYS.DBMS_STATS_ADVISOR", line 882 ORA-06512: at "SYS.DBMS_STATS_INTERNAL", line 20059 ORA-06512: at "SYS.DBMS_STATS_INTERNAL", line 22201 ORA-06512: at "SYS.DBMS_STATS", line 47197 查看trc文件
Oracle 11g之前,当数据库出现问题时,往往第一时间需要看alert日志,看看里面记录了哪些错误,可以给我们提示。alert文件名则
李磊 云和恩墨技术专家 每一个接触过 Oracle 数据库的人想必听到 Ora-04031 都会有一种捶胸顿足的感觉,至少在两年前的我是这样子的。都说 Ora-04031 和 Ora-01555 等是 Oracle 的经典错误,之所以成为经典,可能就是因为它们会经常出现,却又不是那么好解决的缘故吧。今天我就跟大家分享一个我工作当中的4031案例,解读一下4031的前世今生,希望通过今天晚上的交流,当我们再次遇见4031错误时不再像之前那么恐惧。 本次跟大家分享的这个案例是去年我在某电力公司驻场的时候,某
某项目扩展表空间后增加了一个数据文件,出现数据库无法连接的情况,项目人员联系主机硬件厂家,对方发了几个图片说空间不足了,项目人员于是说按照对方说法在主机删除了对应数据文件,这次更无法启动数据库了,,,,,真是无知者无畏,对方敢让删数据文件,项目人员也赶删,实在是无语至极!
下周要为新员工介绍Oracle数据库,为了让课程更接地气,准备了虚拟机环境,用于实验和练习,在此过程中出现了两个ORA-600的错误,偶然中又有必然,记录于此。
Level 1 - contains the basic level of trace information. For example, this trace level will display the bind variables in PL/SQL and SQL statements.
上一篇文章还停留在腊月二十六,现在正月十五也已经过去了,这个年算是过去了,这二十多天里看到很多大佬都在不停的更新文章,卷的铺天盖地,我就只能假装看不见,算是躺平了,什么也没有干,静静地等待这个年过完。本文是今年年初一位朋友遇到的数据库的小问题,事后指导其记录形成的文档,算是小白记录问题处理过程,也是本公众号的第一篇投稿(还有投稿的读者朋友可以找我私聊),适合初学者通过搜索引擎、MOS 来解决 Oracle 数据库遇到的小问题并按照一定的格式来记录问题处理过程,具有一定的参考性,废话不多说,进入正文。
近日有一套实时同步的 ASM 管理的单机 11204 ADG 备库,由于业务需要,想要脱离主库的约束,想激活拉成读写库直接升级成 ASM 管理的 19C,闪回快照模式无法满足要求,只能 ALTER DATABASE ACTIVATE STANDBY DATABASE 强制切成可读写的主库。说干就干,先将其切成主库,升级过程等下次在一起讨论。
工作中碰到问题当然是见怪不怪了,而处理这些问题也是我们的价值所在。 今天处理了几个看起来比较有意思的小问题,当然究其原因,要不是不规范,要不就是基本功不够扎实。 问题1:奇怪的ORA-00600报错,常规的原因 对于ORA-00600的错误,其实自己也碰到过很多次了,绝大多数的情况下,这个错误还是能够反映出来一些不规范的现象。 比如今天得到了一个DDL语句,执行的时候有卡顿,然后直接抛出了ORA-00600的错误。 SQL> CREATE USER "KA_SYS" IDENTIFIED BY VAL
undo表空间是Oracle体系结构的重要组成部分,为什么我们可以回滚,就是因为有它。数据库任意数据的修改都会在undo表空间里生成前镜像,一是可以回滚,二是可以实现并发,以及一致性查询。因此undo也是Oracle数据库在创建和配置参数时必要的组成部分。本文描述的是错误的配置undo表空间之后故障的解决。
当由于空闲超时而手动或由PMON终止会话后手动执行alter system kill session时,将在警报日志中记录相关信息
Oracle 10046是一个Oracle内部事件。最常用的是在Session级别设置sql_trace(alter session set sql_trace=true)即是开启了级别为1的10046调试事件。当设置了10046事件之后,Oracle 将产生一个dump文件。通过得到的dump文件进行进一步分析,可以得到Oracle 内部执行系统解析、调用、等待、绑定变量等详细的trace信息,对于分析系统的性能有着举足轻重的作用。
有客户遇到ORA-2289的报错,同事协助去现场排查,我帮着远程共同check下。 客户只是应用端报出的错误,为了进一步定位,服务端需要开errorstack协助定位具体问题。 下面就以这个ORA-2289为例,示范下errorstack的使用方法。
《一个执行计划异常变更的案例 - 外传之rolling invalidation》
领取专属 10元无门槛券
手把手带您无忧上云