ITPub博客

 归档日志暴涨通常意味着数据库中有大量的数据变更（INSERT, UPDATE, DELETE）。需要明确一点：Oracle本身没有直接记录“某个表产生了多少归档日志”的机制。归档日志记录的是重做日志（Redo Log）的内容，而重做日志是为保证数据一致性和恢复而记录的所有数据块变更，包括数据字典的变化等。因此，我们需要通过一些间接但非常有效的方法来定位“元凶”。以下是监控和定位产生大量

最近处理了一个CASE，语句在执行一直无法出结果查看表分析结果如下: 一、错误原因分析统计信息被显式锁定使用 DBMS_STATS.LOCK_TABLE_STATS 或 DBMS_STATS.LOCK_SCHEMA_STATS 手动锁定了统计信息。数据导入（IMP/IMPDP）触发锁定使用 ROWS=N 参数导入表结构（不导入数

问题描述生产环境是 windowns Oracle11g 11203 版本的单机数据库。（建议oralce数据库千万不要装在widown上） 服务器在断电后重启服务器后，数据无法启动，日志介质损坏： SQL> startupORACLE instance started..........ORA-00333: redo log&nb

1. 背景概述问题描述：晚上ADG 发现有delay问题，同时伴随ORA-16055: FAL request rejected的错误信息发出2. 故障分析2.1.  故障现象当时报错如下Mon May 10 02:16:10 2021ORA-16055: FAL request rejectedMon May 10 02:16:10 2021Errors

1. 背景概述问题描述：数据库在adg备库上做差异增量备份，过一段时间就出现坏块，得完全恢复一次就好了，过一阵子就又出现了2. 故障分析2.1.  故障现象因不能远程连问题客户主机，只能看他的问题截图以下是异常截图                        &nbs

 1. 背景概述问题描述：晋商新核心ADG切换演练之后，TEMP表空间异常增长至满2. 故障分析2.1.  故障现象这时肯定有程序进程抓着temp不放，让我们细找分析一下SQL> set lines 200 pages 999SQL> select * from (select count(*), event,sql_id,program,inst_idfrom g

03月1日凌晨，在业务层的有一个应用报ora-600错误导此应用无法进行，查看警告日志报如下错误：alter 日志： s in file /oracle/app/oracle/admin/accdb/udump/accdb1_ora_2212.trc:ORA-00600: internal error code, arguments: [kcbnew_3], [4], [1], [1382873]

   一、故障现象 19:25业务层反应数据库无法连接。查看警告日志，无报错。查看数据库的等待事件，等待如下：有1462个会话，处于pin相关的子游，导致数据库无法连接。二、故障分析：查看此cursor: pin S wait on X事件发现都是如下语句引起，切登录时间在下午12点到6点， 这些业务，无法释放，导致数据库hang。三、解决方案：目前系统组是

一、日志报错11月21号下午4点20左右查看43.148的weblogic 日志报如下错误，16:20 weblogic报如下错误，16：20-17:05一直报，无其他报错。####<2023-11-21 下午04时20分27秒 CST> <Info> <Common> <bssapp5> <ctcrmServer> <[ACTIV

一：问题现象2024-01-30 10:00点左右发现数据库insert比较慢，数据库出现大量的HW 及大量的log file sync。二：原因分析1. 在10：-12点及下午的14:30-16:00，当时数据库的读写并不大，如下： 10-12  数据库1618396/1024/1024=1.5M/s 写读更小14:30-16:00数据库 2317351/1024/

一、问题发现2024年4月18日上午9点左右，经客户通知发现CPU异常。登录该服务器查询，发现CPU使用率确实比往常高出几倍之多，且看服务器整体的话，Oracle数据库的使用率是比较高的。如下图。二、问题处理1. 在9点10分收集了近一个小时的AWR报告分析，名为：awrrpt_1_28716_28717，查看是否有异常SQL，经发现，造成CPU飙高的有几条SQL语句，主要体现在前五个，查看这几个

  Oracle Clusterware（CRS或Grid Infrastructure）的网络套接字文件位于/tmp/.oracle、/usr/tmp/.oracle或/var/tmp/.oracle目录下，非常重要的是除非得到Oracle支持团队的指示，否则不要手动修改它们以保持集群软件的良好运行状态。其他Oracle组件也可能在相同目录中存储套接字文件，例如Oracle

1 【现象描述】20xx年8月1日16:02:00，数据库出现卡顿现象。20xx年8月2日09:10:00，数据库出现卡顿现象。2 【故障影响】已连接的业务出现卡顿，影响使用；新的连接无法正常建立；3 【故障处理】20xx年8月1日，分别kill掉两个节点的全部会话，让业务重新建立连接，观察一段时间，应用恢复正常；ps -ef|grep -v grep |grep LOCAL=NO|awk &#3

在 Oracle SQL 中，可以使用外部表（External Table）的概念来调用执行批处理文件（.bat 文件）。外部表允许在 Oracle 数据库中访问和处理外部数据，包括文本文件。要调用执行一个 .bat 文件，你需要遵循以下步骤：在数据库服务器上创建一个目录（Directory），用于存储的 .bat 文件。可以使用以下 SQL 语句创建目录：     

环境介绍：Oracle 版本：11.2.0.4.161018，操作系统：AIX 7100-04-02-1614，系统架构：单实例。 故障现象数据库报错无法正常fork进程，后台报错。  问题分析1、alert日志报错，无法fork进程，直接报错。根据ORA-27300: OS system dependent operation:fork failed with status:

环境介绍：Oracle 版本：11.2.0.4.191015，操作系统：Redhat linux server 7.5，系统架构：两节点RAC。故障现象业务层反馈数据库无法正常写入，无法切换归档日志。  问题分析1、Mon Oct 12 12:26:02开始多次报错，内存坏块，持续到13号 Mon Oct 12 12:26:02 2020Errors in file /opt/

最近在加主库添加数据文件时导致备库无法被应用，警告日志报如下错误：Media Recovery Waiting for thread 1 sequence 921276 (in transit)Recovery of Online Redo Log: Thread 1 Group 72 Seq 921276 Reading mem 0  Mem# 0: +DATA/ractd/onlin

最近在测试生产数据库时发现数据库在open过程很长慢，大概持续20分钟左右，有时持续1-2个小时。日志如下：Fri Nov 23 10:53:51 2018  SMON: enabling tx recovery  Database Characterset is AL32UTF8  Fri Nov 23 10:54:02 2018  Decreasing

ORA-27300: OS system dependent operation:fork failed with status: 12

本次测试目的模拟ORACLE 11G RAC 共享存储OCR磁盘损坏恢复测试。序号测试内容测试时间1模拟ORACLE 11G RAC 共享存储OCR磁盘损坏恢复测试。1小时 注意事项一定要确认2个节点的共享磁盘权限和属主正确。如下命令检查ls -la /dev/rhdiskchown grid:asmadmin /dev/rhdiskchmod 660 /dev/rhdisk