ITPub博客

DBA 最不想接到的一类告警是 ORA-01578: ORACLE data block corrupted。它意味着某个数据块物理损坏，访问到这个块的查询和 DML 全部失败，而同一个表里其他块上的数据看起来完好无损。

大批量 UPDATE、DELETE 的执行时间通常与行数成正比，串行跑到几个小时是常有的事。提高这类语句的速度，并行hint（`/*+ PARALLEL */``）对查询成熟，但对 DML，数据库默认只并行读、不并行写，真正要并行执行 DML 还得开启会话级并行 DML，粒度、资源都不可控。

定时作业的并发重叠是运维中的常见隐患：上一轮作业还没跑完，调度器又启动了下一轮，两个进程同时处理同一批数据，轻则重复劳动，重则相互等待甚至死锁。应用侧的常规做法是往状态表里插一条"运行中"记录作为标志，但这个方案有两个天然缺陷：先插记录再判断之间存在窗口期；进程异常退出后记录残留，需要人工清理。

一个常见的空间问题：历史数据按期清理，DELETE 执行了几十万行，几个月后看 DBA_SEGMENTS，段的大小纹丝不动；依赖这张表的全表扫描，耗时也没有任何改善。原因在于段的高水位标记（HWM）只升不降——数据删除后块空了，但仍然属于这个段，全表扫描照样要走过它们。DBA_SEGMENTS 只能看到段占了多少空间，看不到这些块的"实心程度"。要看清 HWM 之下到底有多少满

排查 I/O 相关的性能问题时，等待事件给出的信息是物理地址：db file sequential read 的 P1 是文件号、P2 是块号，buffer busy waits 等待同样以文件号加块号标识热点块。DBA 拿到这组数字后，下一步往往就断了线，这是哪个表的哪个段落？如果要继续追，能不能定位到具体行？这一步的关键是ROWID，以及配套的 DBMS_ROWID 包。ROWID 本身就是行

排查数据库问题时，DBA 打开 V$SESSION，经常看到的是几百个长得一模一样的会话：PROGRAM 是 plus.exe 或 JDBC Thin Client，MODULE 一列基本都是默认值，分不清哪个会话属于哪个应用、哪个作业。批量作业更是一个黑盒：会话状态一直是 ACTIVE，但执行到了哪一步、还要多久，应用之外无人知晓。这个问题 Oracle 其实早有标准解法：DBMS_APPLIC

想象一下下面的场景：一个跑了四、五个小时的批量 INSERT，眼看到了最后一步，屏幕上突然蹦出：ORA-01653: unable to extend table TEST.T_RESUMABLE by 128 in tablespace SMALL_TBS空间不够，语句报错，前面几个小时的劳动全部

在 Oracle 数据库的日常运维中，除了 RMAN、expdp 等常见备份手段外，DBMS_FILE_TRANSFER 包也是一个不容忽视的工具。它提供了 COPY_FILE、GET_FILE、PUT_FILE 三个过程，可以在数据库之间、或者同一数据库的不同目录之间传输数据文件（datafile）。利用这一特性，我们可以把源库的数据文件直接"推送"或"拉取"到远端服务器，实现一份远程备份。

前几天给 ASM 磁盘组加盘，本来觉得是 routine 操作：盘怼上去，rebalance power 给上，盯着进度跑完就收工。结果这次栽了个不大不小的跟头，记录一下。事情的经过加完盘，rebalance 正常开跑，前半程都顺。眼看着快完工了，进度不动了——查操作进度，剩余时间已经显示 0。按理说时间归零就差临门一脚，可左等右等，这脚就是踢不进去，状态一直挂着，加盘始终不算成功。rebalan

 RAC 运维的人多少都见过节点被驱逐：告警响起来，上去一看，一个节点自己重启了，日志里一片 eviction 的信息。要搞明白节点为什么被踢出去，就得先搞明白集群的心跳机制。这篇文章把 Oracle 集群的三种心跳捋一遍，给以后排查这类问题打个底。从集群一致性说起先说一个概念：集群一致性。听起来挺玄，其实就是两件事：集群里的每个成员都得知道其他成员的状态；每个成员手里的“节点成员列表”

背景：某高校客户检测出 5000 端口有中危漏洞告警。

SQL Monitor 是 Oracle 数据库（从 11g 开始引入并持续增强）内置的一项 实时性能诊断和监控 功能。它是 Real-Time SQL Monitoring 功能的核心组成部分。它的主要目的是提供正在执行的长时运行或资源密集型 SQL 语句的 实时、详细执行计划和运行时统计信。

先说为什么这事值得单独拎出来讲。 干 DBA 的都遇到过这么个场景：某张表数据量变了，或者刚做完大批量数据导入，CBO 的统计信息该重新收集了。dbms_stats.gather_table_stats 一敲下去，心里就开始打鼓——这次收集完，执行计划会不会变？变了是变好还是变坏？ 最怕的是那种"收集完反而变慢"的情况。统计信息一旦更新，原来的计划就成了过眼

起因前几天接到客户反馈，说绩效核算的查询 SQL 变慢了。原来 10 分钟就能出结果，这次跑了 13 分钟还在转。按惯例先问环境，客户那边给的背景信息挺有意思：每个月 6 号 12 点开始，HIS 库会做一次 exp 全库导出。这个月因为赶上国庆，前几天没跑，今天这一轮到现在还没结束。听到这，第一反应是——是不是 exp 导出占着资源把业务查询挤了？这个怀疑先放着，但没急着下结论，毕竟"

查询 lob 字段对应的表：select e.owner, l.table_name, l.segment_name  from dba_extents e, dba_lobs l where e.owner = l.owner and e.segment_name = l.segment_name   and e.segmen

在Oracle数据库中，自主事务（Autonomous Transaction）是指一个独立于当前事务执行的事务。它可以在不依赖于外部事务的情况下独立提交或回滚，而外部事务的状态不会受到影响。自主事务通常用于日志记录、触发器中的独立操作或需要在当前事务上下文之外执行的任务。

“叮！/oracle 目录使用率 100%！”作为一个数据库管理员，这行报警短信绝对比女朋友的“我们谈谈”还要让人心跳骤停。昨天我就经历了这么一遭。正准备摸鱼喝口咖啡，监控系统突然发难。上服务器一看，好家伙，/oracle 目录红得刺眼，直接顶满。这就好比你刚买的 512G 手机，一夜之间被塞满，还不知道是谁干的。01 案发现场：谁吃了我的空间？通常来说，Oracle 目录满了，嫌疑人无非就是那几

作为 DBA，我们最怕听到客户抱怨：“数据库怎么又慢了？”、“归档日志怎么又满了？”。最近我们就遇到了这样一个案例：客户生产系统的归档日志量突然暴增，Undo 表空间的使用率也居高不下，报警短信响个不停。经过紧急排查，我们发现罪魁祸首竟然是一个不起眼的“中间表”。今天，我们就来聊聊这个案例，以及如何利用 Oracle 的全局临时表特性，优雅地解决这类问题。案发经过：一张小表引发的“血案”接到报警后

在 Oracle 数据库的世界里，锁（Lock）是我们最熟悉的陌生人。我们都知道 UPDATE 会加锁，SELECT FOR UPDATE 也会加锁，但你是否想过，当成千上万个会话同时争抢同一个资源时，Oracle 是如何在底层管理这些锁请求的？答案就是：排队（Enqueue）。今天，我们就潜入 Oracle 内核深处，去看看这个名为 Enqueue 的神秘结构是如何指挥交通的。什么是 Enque

在数据库运维中，修改数据库名称（DB_NAME）和实例名（INSTANCE_NAME）是一个相对底层且有风险的操作。这通常发生在数据库迁移、克隆或标准化命名等场景。