Oracle如何实现批量 DML 的手动并行
大批量 UPDATE、DELETE 的执行时间通常与行数成正比,串行跑到几个小时是常有的事。提高这类语句的速度,并行hint(`/*+ PARALLEL */``)对查询成熟,但对 DML,数据库默认只并行读、不并行写,真正要并行执行 DML 还得开启会话级并行 DML,粒度、资源都不可控。
定时作业并发重叠的避免方法
定时作业的并发重叠是运维中的常见隐患:上一轮作业还没跑完,调度器又启动了下一轮,两个进程同时处理同一批数据,轻则重复劳动,重则相互等待甚至死锁。应用侧的常规做法是往状态表里插一条"运行中"记录作为标志,但这个方案有两个天然缺陷:先插记录再判断之间存在窗口期;进程异常退出后记录残留,需要人工清理。
如何从等待事件定位到具体数据块和具体行
排查 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
Resumable Statement的用法
想象一下下面的场景:一个跑了四、五个小时的批量 INSERT,眼看到了最后一步,屏幕上突然蹦出:ORA-01653: unable to extend table TEST.T_RESUMABLE by 128 in tablespace SMALL_TBS空间不够,语句报错,前面几个小时的劳动全部
利用 DBMS_FILE_TRANSFER 实现数据文件的远程备份
在 Oracle 数据库的日常运维中,除了 RMAN、expdp 等常见备份手段外,DBMS_FILE_TRANSFER 包也是一个不容忽视的工具。它提供了 COPY_FILE、GET_FILE、PUT_FILE 三个过程,可以在数据库之间、或者同一数据库的不同目录之间传输数据文件(datafile)。利用这一特性,我们可以把源库的数据文件直接"推送"或"拉取"到远端服务器,实现一份远程备份。
搞懂 Oracle RAC 的三种心跳:网络心跳、磁盘心跳、本地心跳
RAC 运维的人多少都见过节点被驱逐:告警响起来,上去一看,一个节点自己重启了,日志里一片 eviction 的信息。要搞明白节点为什么被踢出去,就得先搞明白集群的心跳机制。这篇文章把 Oracle 集群的三种心跳捋一遍,给以后排查这类问题打个底。从集群一致性说起先说一个概念:集群一致性。听起来挺玄,其实就是两件事:集群里的每个成员都得知道其他成员的状态;每个成员手里的“节点成员列表”
统计信息备份和还原
先说为什么这事值得单独拎出来讲。 干 DBA 的都遇到过这么个场景:某张表数据量变了,或者刚做完大批量数据导入,CBO 的统计信息该重新收集了。dbms_stats.gather_table_stats 一敲下去,心里就开始打鼓——这次收集完,执行计划会不会变?变了是变好还是变坏? 最怕的是那种"收集完反而变慢"的情况。统计信息一旦更新,原来的计划就成了过眼
ORACLE LOB大字段介绍和管理
查询 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 性能优化:日志暴增、Undo 告急?全局临时表来救火!
作为 DBA,我们最怕听到客户抱怨:“数据库怎么又慢了?”、“归档日志怎么又满了?”。最近我们就遇到了这样一个案例:客户生产系统的归档日志量突然暴增,Undo 表空间的使用率也居高不下,报警短信响个不停。经过紧急排查,我们发现罪魁祸首竟然是一个不起眼的“中间表”。今天,我们就来聊聊这个案例,以及如何利用 Oracle 的全局临时表特性,优雅地解决这类问题。案发经过:一张小表引发的“血案”接到报警后
Oracle 小众需求:如何安全、彻底地修改 DB_NAME和INSTANCE_NAME?
在数据库运维中,修改数据库名称(DB_NAME)和实例名(INSTANCE_NAME)是一个相对底层且有风险的操作。这通常发生在数据库迁移、克隆或标准化命名等场景。
闪回功能介绍与使用
Oracle闪回技术是现代Oracle数据库不可或缺的灾难恢复和数据分析工具包。它通过利用数据库内部的撤销机制和专用日志,提供了远超传统恢复方法的速度、精度和易用性。理解不同闪回技术的原理、适用场景、依赖和限制,对于DBA高效地进行数据恢复、审计、排错和保障业务连续性至关重要。根据具体需求(恢复整个库、单个表、查询历史、恢复删除的表)选择正确的闪回技术是关键。选择哪种闪回技术?场景推荐技术主要依赖
如何主库进行闪回,而备库不需要重新搭建?
主库需要跑批或者其他场景怕失败,准备闪回,怕失败准备闪回,但是闪回完需要resetlogs打开,避免备库要重新搭建的方法流程。
Dg broker如何配置
DG Broker(Data Guard Broker)是Oracle数据库提供的一个集中式管理框架,用于简化Data Guard配置的创建、监控和维护。它将主库(Primary)和所有备库(Standby)视为一个整体系统,通过命令行工具dgmgrl或Oracle Enterprise Manager
如何查杀正在运行的job
1.首先确定要停止的JOB号select * from dba_jobs_running;--得到sid和job号 2.Broken确认的JOB可以在PL/SQL Developer中,直接选项broken;或者使用语句:EXEC DBMS_JOB.BROKEN(job#,TRUE);--加入job号,注意commit 3.Kill 对应
如何对ocr进行备份与管理
OCR存储了集群的全局配置信息(如节点映射、资源定义、监听器配置、VIP/SCAN IP地址等)。若OCR因硬件故障、存储损坏或人为误操作丢失,备份文件可快速恢复集群配置,避免整个RAC环境瘫痪。1.1 检查 OCR 的状态123456789101112131415161718192021[root@rac1 bin]# ./ocrcheckSta