生产环境DBLINK查询执行计划失控排查与优化
生产环境DBLINK查询执行计划失控排查与优化大家好,我是睿。前段时间,某客户的生产系统里出现了一条卡住的跨库报表查询。业务方第一反应是:是不是数据库缺索引?这句话在慢查询现场很常见。但这次如果只看索引,方向很容易跑偏。真正的问题不是本地索引,也不是远程索引数量,而是分布式执行计划把远程表的返回行数估算错了,随后选择了一个不该选择的连接方式。这次处理链路大致如下:远程表统计信息失真↓优化器低估远程
记一次硬件故障后的数据库启动异常
记一次硬件故障后的数据库启动异常大家好,我是睿。最近处理了一次比较棘手的 Oracle 数据库故障。数据库所在服务器发生硬件故障,主机宕机。硬件修复、服务器重新起来之后,数据库却无法正常启动。现场数据库版本是 Oracle 11.2.0.4,单机、归档模式,数据量大约 84GB,而且没有可用备份。这类故障最麻烦的地方,不是某一条命令怎么写,而是每一步都可能把后续恢复空间越压越小。这次的处理链路大致
Oracle RAC DB 层心跳误走 public 网络故障排查
Oracle RAC DB 层心跳误走 public 网络故障排查大家好,我是睿。最近处理了一个 RAC 环境里比较典型、也比较容易被误判的问题:数据库实例突然出现大量 Oracle 进程异常终止,alert 日志里连续报出 ORA-27504、ORA-27301: No buffer space available、ORA-00603 等错误。刚开始看,很多人第一反应可能是:是不是主机网络 bu
OGG Extract 异常停止排查:最后根因落在 RAC 私网分片重组失败
OGG Extract 异常停止排查:最后根因落在 RAC 私网分片重组失败Oracle GoldenGate 故障处理案例大家好,我是睿。今天处理了一个比较有意思的 Oracle GoldenGate 问题:某生产库的 OGG Extract 进程突然异常停止。刚开始看现象,很容易把方向放在 OGG 自身,比如参数、trail 文件、归档日志、抽取表 DDL、Redo 读取等。但这次一路排下来,
Oracle LOB 临时段占用 TEMP 排查实战:从 99% 使用率到应用释放临时 LOB
Oracle LOB 临时段占用 TEMP 排查实战:从 99% 使用率到应用释放临时 LOB大家好,我是睿。最近遇到一个很有代表性的 Oracle TEMP 临时表空间问题:客户反馈数据库 TEMP 使用率持续升高,一开始看上去还不算严重,第二天其中一个实例直接到了 99%。这类问题很容易被简单理解成“临时表空间满了,加文件就行”。但生产环境里,TEMP 涨高只是现象,真正要看的不是单纯加多大,
Oracle 索引组织表 ORA-00600 [6200] 处理实战:从十六进制对象号定位到 IOT 重建
Oracle 索引组织表 ORA-00600 [6200] 处理实战:从十六进制对象号定位到 IOT 重建大家好,我是睿。最近处理了一次比较典型、但又容易让人紧张的 Oracle 故障:数据库 open 后,后台进程不断在 alert 日志和 trace 中报 ORA-00600 [6200],同时伴随 ORA-07445 [kghstack_err()+117]。ORA-00600 这种错误,很
Oracle 在线重定义实战:不停业务,把普通表改造成分区表
Oracle 在线重定义实战:不停业务,把普通表改造成分区表大家好,我是睿。最近遇到一个比较典型的表结构改造需求:一张普通业务日志表,数据量已经接近 4000 万行,表段约 34GB,并且里面还有 CLOB 字段。随着数据持续增长,后续查询、归档和空间维护都会越来越麻烦,所以这次要把它改造成按时间字段分区的分区表。如果直接停业务、建新表、导数据、改名,思路很简单,但生产环境往往不允许这么干。表越大
闪回搞不定时怎么办?Oracle数据恢复的终极武器
Oracle数据恢复进阶实战:LogMiner日志挖掘与TRUNCATE恢复全攻略 大家好,我是睿。 上一期我们聊了Oracle闪回技术全家桶,从闪回查询到闪回数据库,把6种闪回方式全部实操了一遍。文章最后我留了个预告——当闪回技术搞不定的时候,该怎么办? 现实中,DBA经常遇到这些棘手场景:• DML误操作后,redo日志已经被归档,在线日志里找不到• 需要精确审计
Oracle闪回技术全景实战:Flashback全家桶,从误删数据到完美恢复的终极指南
Oracle闪回技术全景实战:Flashback全家桶,从误删数据到完美恢复的终极指南 大家好,我是睿。 做DBA的,最怕听到一句话:"完了,数据删错了。"不管是新手误操作DROP TABLE,还是开发同学一个没加WHERE的DELETE,这种场景在生产环境中真的不罕见。很多时候,业务方一个电话过来,心跳就加速了。好在Oracle给我们准备了一整套"
Oracle表碎片整理实战:SHRINK还是MOVE?完整实验对比
大家好,我是睿。表碎片是Oracle DBA日常维护中经常遇到的问题。很多表在经过大量数据插入和删除后,高水位线一直居高不下,即使实际数据已经很少,全表扫描时还是会读很多无效块,导致性能变差。最近我专门做了一个实验,用同一张表对比了 SHRINK 和 MOVE 两种缩表方式的实际效果,包括操作步骤、资源消耗、整理后的段大小和索引情况等。今天把整个过程完整分享出来,供大家参考。## 一、表碎片是怎么
Oracle 19c Active Data Guard DML 重定向:让只读备库也能“写”!
大家好,我是睿。 在传统的 Active Data Guard(ADG)中,备库只能做只读查询,这让很多“读多写少”的应用场景非常痛苦——报表系统偶尔要写点临时数据,就得切到主库,增加主库压力。 Oracle 19c 正式引入的 DML Redirection(DML 重定向)特性完美解决了这个问题:在备库执行 DML 时,Oracle 会自动把操作重定向到主库执行,执行完后再
一次紧急DMP导入:12c导出到11g生产库,踩过的版本与字符集大坑
大家好,我是睿。 作为乙方DBA,经常会接到客户的紧急需求。这不,今天刚处理完一个“看似简单、实则暗坑”的DMP导入任务,分享出来供大家参考,避免走弯路。 故障背景 上午客户电话打来:“有个DMP文件要紧急导入生产库,文件已经传到服务器上了,很急!” 我远程连上去一看:TMP.dmp,只有200MB。心想应该不难,结果问了客户导出信息后,客户表示这是“转了好
Oracle 10046事件深度解析:比SQL_TRACE更强的“X光机”,一招搞定生产疑难杂症!
在上一篇文章中,我们介绍了 SQL_TRACE + TKPROF 这对性能诊断黄金组合,很多读者反馈“干货满满,实战好用”。但当你遇到更棘手的问题时—— SQL执行慢,但看不出具体在等什么(等待事件) 绑定变量值不对,导致执行计划走歪 需要最完整的执行统计和真实耗时分布……这时,10046诊断事件 就该登场了!它是 Oracle 官方未公开的扩展诊断工具,被无数 DBA 称为“性能排查
Oracle SQL_TRACE + TKPROF 性能诊断神器:5分钟定位慢SQL,DBA必备“X光机”!
你有没有遇到过这种崩溃场景?1、SQL明明走了索引,却慢得像蜗牛;2、生产环境CPU/IO爆表,TOP SQL看不出问题;3、开发说“代码没改”,DBA却背锅……别慌!Oracle经典诊断利器——SQL_TRACE能把SQL执行的每一毫秒、每一次IO、每一次等待事件全部“扒光”,再搭配 **TKPROF** 一键生成美观报告,问题SQL瞬间现形。今天这篇干货,从零到实战,手把手教你玩转SQL_TR
Oracle存储过程被覆盖找回实战
LogMiner归档日志挖掘深度解析 一、问题背景与技术痛点某医疗客户的核心业务系统中,运维人员执行 `CREATE OR REPLACE PROCEDURE` 语句时,误将业务用户的关键存储过程覆盖,且操作时间点距发现时已超过10小时。客户急需找回原始存储过程逻辑,否则将影响后续业务流程。 为何常规方案行不通?1. DD
医疗HIS数据库双节点故障排查实战案例
一、故障初现:应用卡顿紧急排查某医疗客户核心 HIS 系统夜间突发应用卡顿,诊疗业务响应迟缓,严重影响医院正常诊疗流程。我方 DBA 接报后迅速登录数据库服务器,启动紧急排查工作。排查初期,DBA 优先聚焦数据库核心等待事件,通过反复执行如下 SQL 语句监控活跃会话状态:select username,&
RAC 容灾环境归档传输异常溯源
一、概述本次故障发生在客户容灾环境,具体环境信息如下:- 架构类型:双节点 Oracle RAC集群;- 数据库版本:Oracle 11.2.0.4,且已安装最新补丁;- 部署平台:超融合平台,依托超融合的资源整合特性实现容灾环境的灵活部署与管理;- 核心功能:通过 Oracle 容灾机制(如数据同步、归档日志传输)保障业务数据
Oracle DataGuard 搭建关键参数详解
一、文档概述本文档聚焦 Oracle DataGuard 搭建过程中的核心参数,从主库与备库基础配置参数、日志传输相关参数、备库恢复相关参数、监控与性能优化参数四大维度,详细解析每个参数的作用、取值范围、配置建议及注意事项,为DataGuard 环境的搭建、稳定运行与性能优化提供技术支撑。本次更新修正了部分参数的错误表述,并补充了日志传输参数的关键细节。二、主库与备库
一场由“消失的进程”引发的追踪:数据库备份异常背后的暗战
2025年X月2日,客户核心数据库出现备份异常,RMAN、expdp备份及文件拷贝进程均被异常终止。经排查,确认系恶意程序入侵所致,该程序通过暴力破解植入,旨在破坏数据备份机制。团队紧急处置后恢复正常,后续已完成深度清理及安全加固。
存储裂缝之“救赎” ——Oracle 数据坏块故障修复纪实
本文记录了一场由存储硬件故障引发的 Oracle 数据库抢救全过程。在 AIX 系统单机环境下,22GB 关键数据文件因存储损坏仅余 20.4GB 可读,导致数据库无法启动。通过冷备现场、屏蔽损坏 Undo 段、修复坏块及调整隐含参数,数据库成功重启后,核心表 XXX.SECRET_TABLE_OLD 因数据块损坏出现查询异常。团队创新采用 rowid 定位法,结合存储过程逐行筛查,从 "好坏掺杂" 的记录中提取 138823 条有效数据,仅缺失 105 条。