CHM导致的磁盘空间爆满
“叮!/oracle 目录使用率 100%!”作为一个数据库管理员,这行报警短信绝对比女朋友的“我们谈谈”还要让人心跳骤停。昨天我就经历了这么一遭。正准备摸鱼喝口咖啡,监控系统突然发难。上服务器一看,好家伙,/oracle 目录红得刺眼,直接顶满。这就好比你刚买的 512G 手机,一夜之间被塞满,还不知道是谁干的。01 案发现场:谁吃了我的空间?通常来说,Oracle 目录满了,嫌疑人无非就是那几
Oracle 性能优化:日志暴增、Undo 告急?全局临时表来救火!
作为 DBA,我们最怕听到客户抱怨:“数据库怎么又慢了?”、“归档日志怎么又满了?”。最近我们就遇到了这样一个案例:客户生产系统的归档日志量突然暴增,Undo 表空间的使用率也居高不下,报警短信响个不停。经过紧急排查,我们发现罪魁祸首竟然是一个不起眼的“中间表”。今天,我们就来聊聊这个案例,以及如何利用 Oracle 的全局临时表特性,优雅地解决这类问题。案发经过:一张小表引发的“血案”接到报警后
一次物化视图中断的修复
[告警类型:ZABBIX][规则名称:45.59的物化视图失效的监控][告警状态:已恢复][告警级别:P1][触发时间:2026-04-30 19:52:56][告警详情:45.59的物化视图失效的监控 (value is 1)]查询物化视图状态的确是已经有一个小时没有更新了。物化视图是一种简单且实施成本极低的数据同步方案简单无需第三方工具,且一致性有保证。当初正因为这样,导致越用越多,从2个表的
【数据库数据恢复】Oracle数据库故障类型及恢复要点
Oracle数据库常见故障: 1、Oracle数据库无法启动、运行异常。 2、ASM存储损坏故障。 3、误操作导致数据文件丢失。 4、数据文件与Dump文件损坏。
[20260531]sqlplus set emb on使用问题.txt
[20260531]sqlplus set emb on使用问题.txt--//偶尔协助别人解决数据库问题,在服务端以sys用户登录后最大的问题,许多情况下环境都没有设置好,更加无法理解是没有安装--//rlwrap,无法使用上下键.每次都会花一些时间设置简单的sqlplus使用环境,也就是在这类设置中,set emb on|off的奇怪现象.--//通过例子演示展示该问题.1.环境:SCOTT@
[20260531]Oracle VM VirtualBox 7.0安装增强功能错误在centos 9 stream.txt
[20260531]Oracle VM VirtualBox 7.0安装增强功能错误在centos 9 stream.txt--//安装Oracle VM VirtualBox的增加功能报错,操作记录如下:--//光驱指向C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso文件.--//以新建立的test用户登录,这样安装VBoxGue
[20260530]DNF error Error in POSTTRANS script let rpm package kernel-core
[20260530]安装centos 9,出现DNF error Error in POSTTRANS script let rpm package kernel-core.txt在虚拟机器上安装CentOS Stream 9,安装iso文件为CentOS-Stream-9-latest-x86_64-dvd1.iso.安装遇到如下问题:DNF error: Error in POSTTRANS
[20260529]sqlplus set doc的使用.txt
[20260529]sqlplus set doc的使用.txt--//SET DOC[UMENT] {ON|OFF} 是 SQL*Plus 中的一个已废弃(obsolete)命令,用于控制 DOCUMENT 命令(同样已废弃)所创建的文档块是--//否输出到屏幕。--//SQL*Plus 中,DOCUMENT 命令允许在脚本中嵌入多行说明文本,并以 # 单独一行结束;SET DOCUMENT [
从“智能机”到“智能体”,思格新能源重写千亿储能赛道估值
从“智能机”到“智能体”,思格新能源重写千亿储能赛道估值
第64期 ORA-00600: internal error code, arguments: [qosdExpStatRead
ORA-00600: internal error code, arguments: [qosdExpStatRead: expcnt mismatch]报错解决办法。
[20260525]跟踪library cache lock library cache pin使用systemtap(21c)2.txt
[20260525]跟踪library cache lock library cache pin使用systemtap(21c)2.txt--//链接:[20260525]跟踪library cache lock library cache pin使用systemtap(21c)1.txt 列出几种方案。--//先尝试方案1,输出乱码,当时也没有仔细分析。方案2失败,再尝试方法3,先升级Syste
[20260525]跟踪library cache lock library cache pin使用systemtap(21c)1.txt
[20260525]跟踪library cache lock library cache pin使用systemtap(21c)1.txt--//去年6月份做的测试,当时测试失败,当时的记录如下。$ cat lkpn21c.stpglobal lk=0, pn=0#globak off_set=0#probe begin {# printf("Begi
[20260522]安装升级systemtap到4.0-13.txt
[20260522]安装升级systemtap到4.0-13.txt--//测试环境systemtap版本有点低,升级到4.0-13看看,顺便做一个记录。# rpm -qa | grep systemtapsystemtap-3.0-7.el7.x86_64systemtap-devel-3.0-7.el7.x86_64systemtap-runtime-3.0-7.el7.x86_64syste
看懂科技公司AI复利,谁在进入α重估区间?
看懂科技公司AI复利,谁在进入α重估区间?
如何快速处理Oracle控制文件损坏
控制文件是 Oracle 的目录文件(记录数据文件、日志文件、数据库信息),损坏只会导致数据库无法启动,用户数据文件、在线日志文件完好 = 数据绝对安全。重建控制文件优先用 NORESETLOGS(仅当在线日志丢失才用 RESETLOGS,你的场景全程用 NORESETLOGS)。场景 1:数据库能启动到 MOUNT 阶段(最简单)适用情况启动数据库报错,但执行 startup mount 不报错
如何处理Oracle数据库redolog日志损坏
一、核心背景在线日志写入极频繁,主机 / 存储异常断电最容易导致在线日志损坏。日志损坏 = 数据丢失,数据库会直接无法 OPEN,必须谨慎处理。关键状态说明INACTIVE:已归档,未被实例需要,损坏最容易修复ACTIVE:未归档,实例崩溃恢复需要,损坏有风险CURRENT:正在写入,最核心日志,损坏 = 必须强制打开 + 丢数据二、场景 1:损坏的是 INACTIVE 在线日志(最简单、安全)处
Oracle SYSTEM/UNDO 表空间损坏(无备份)处理完整指南
一、核心前提:必须优先备份!必须备份的文件清单空间不足 / 备份耗时的情况下,最小必备备份集:数据文件:SYSTEM、UNDO、SYSAUX 表空间对应的数据文件控制文件:所有路径的控制文件在线重做日志:所有在线日志文件重要原则:不可逆修复操作前,必须备份;非常规修复(隐含参数 /bbed)风险极高,无备份绝不轻易操作。二、适用场景数据库因 SYSTEM 表空间损坏 / UNDO 表空间坏块 异常
如何快速解决Oracle数据库的数据块坏块
如何快速解决Oracle数据库的数据块坏块修复步骤如下所示:步骤 1:安全校验坏块(推荐 DBV,无宕机风险)1.1 首选:DBV 工具(物理校验,100% 安全,不宕库)DBV 是 Oracle 自带的物理坏块校验工具,只读数据文件,不写入、不触发数据库内部操作,完全无风险。# 语法:dbv file=数据文件路径 blocksize=数据库块大小dbv
Oracle数据库坏块定义及产生原因
Oracle 正常数据块具备标准、固定的内部存储格式。若数据块内部结构紊乱、数据信息异常,导致数据库无法正常解析和读取,该数据块即被定义为坏块。坏块对数据库的影响程度不一、范围不定,轻微坏块仅影响局部业务数据访问,严重时会直接导致数据库无法正常启动。当数据库触发坏块故障时,通常会抛出 ORA-01578、ORA-10632、ORA-00600 等典型报错。数据库产生坏块的核心原因主要分为以下五类:
从全球量产定点到无人物流,知行科技讲通生态故事
从全球量产定点到无人物流,知行科技讲通生态故事