ITPub博客

9 月 30 号这一天，接到反馈，业务反应查询有点慢。数据库显示acknowledge over PGA limit是最严重的等待事件。这套库是 Oracle 19c 的 CDB，挂着 12 个 PDB，宿主机 24 核、94.4G 内存，SGA 已经占掉 58G。一、上午：AWR中最扎眼的是等待事件AWR显示：指标值DB Time4,210.78 分钟（快照区间 60 分钟）会话数393 → 5

你以为和上次一样？不是，同是一台物理机上的几个虚拟机重启，但是每个环境不一样，这次主库归档没了上次写了 rhino 库的那篇，缺 1 个 sequence，主库归档还在，修通 TNS 链路后 FAL 自动补，半小时搞定。这次是另一套环境，缺了 200 多个 sequence，主库归档也清理了，FAL 补不了。但最后还是没重做备库，RMAN 增量前滚 15 秒解决。一、环境信息主库：prod-isl

背景物理机故障重启，上面的虚拟机跟着重启，虚拟机里的 Oracle ADG 备库也跟着重启了。这本来是个很常规的操作，相关人报给我说无法启动。当时看到出错信息是 ORA-10458 的时候，心里咯噔了一下——备库打不开了。第一反应是完了，是不是得重做备库。冷静下来一步步排查，发现根本不用重做，问题比想象的简单，但隐蔽得很。一、问题背景这是一套 Oracle 11.2.0.4 的 Active Da

现在我做有些工作，越来越多地让 AI 来替我干活。以前遇到 OGG 链路挂了，我得自己 ssh 上机器、一条条敲 GGSCI、写脚本逐台核对，费时费力还容易手抖。这次 OGG 集成抽取链路重建，我几乎把这些都交给了 AI——它写脚本、跑命令、批量比对，我基本只动嘴。省事是真的省事。但过程也说明了一件事：AI 没经验、有误区，关键判断还得靠人。 它连续跑偏三次，都是我把方向拉回来的。写下来

– 写在前面：前几天朋友抛来一句"表空间快满了，加文件还是扩磁盘？"我心想这不简单，先看看使用率再说。顺手丢出一条用了 N 年的查询语句，结果屏幕上跳出来一行：USED_MB 空、FREE_MB 空、USED_PERCENT 空——一排醒目的 NULL。我心里咯噔一下：不会是数据文件坏了吧？– 这是我工作多年第一次在生产库上看到这种现场。后来在 1

先说背景，实在没想通这个默认打开的参数为什么关闭了。从来没去考虑过会关闭。而且大部分都是打开的。实在不巧遇到这个数据库是关闭的一、问题背景前几天在客户现场排查一个性能问题，发现 Oracle 19c 数据库中 ACS（Adaptive Cursor Sharing，自适应游标共享）居然没有开启。按照 Oracle 的官方文档，ACS 从 11gR2 开始默认是开启的，但客户的 19c 环

[告警类型：ZABBIX][规则名称：45.59的物化视图失效的监控][告警状态：已恢复][告警级别：P1][触发时间：2026-04-30 19:52:56][告警详情：45.59的物化视图失效的监控 (value is 1)]查询物化视图状态的确是已经有一个小时没有更新了。物化视图是一种简单且实施成本极低的数据同步方案简单无需第三方工具，且一致性有保证。当初正因为这样，导致越用越多，从2个表的

关于碎片的形成一般来说，关系型为主的多模数据库或者纯关系型数据库，对于执行delete的操作都不会释放数据空间。从而产生碎片。最好的方式就是，有一定的规划，比如分区之类。通过分区的转移来移除数据。这样不产生碎片。一旦产生碎片。怎么办？最 低级的操作就是把表进行逻辑导出，然后再进行逻辑导入。如果表大的话，这种几乎不可行。还有就是新建一个表，然后两个表换名字，慢慢搬迁需要的数据。还有一个方案就是做碎片

从11G开始把字段加在数据字典上是一个经典的设计MySQL8也有了这个不过也不是所有加字段的都可以像上述一样，秒过。创建一个表，写入1000万数据增加一个自增列并且给这个列增加主键。就从这个执行时间来说，就不是增加在数据字典上（想想也不可能。毕竟每一行不去改是不行的，他要一次产生不同的数据到每一行，而且加主键的过程还要校验是不是有null和重复）其他效果这个SQL在ogg的环境中是可以顺利传到下游

Nvarchar数据类型比较特殊有开发人员反馈，两个字段关联，一个是varchar、另外一个是Nvarchar，会有性能问题吗？这个问题其实不能说一定有。通过实验来说明吧。具体实验-表结构A表的VAR列、NVAR列和B表的NVAR列和M列有索引B表的VAR列索引不可见（或者说没有索引）类型转换VAR列有索引，但是是字符型，给了一个数值。函数转换了，全表扫描在执行计划中也看到了TO_NUMBER(“

先说感叹，成熟的产品就是出问题都让人放心上个月有一次有人反馈低代码平台不能用。一看是低代码的应用停了。这个怎么停了？是只有他停了吗？再去看看应用连接的数据库也停了。那么就启动数据库吧。启动以后看看日志，之前发生什么问题了。结果从日志上看到从7月23的13点后就没有日志了。然后就是7月28下午15点的启动。按说不应该啊，一般遇到问题导致异常关闭，应该有错误信号和日志。但是这里明显没有。仔细想来想去，

In-memory这个功能都有十多年了大家都知道alter table t INMEMORY，这一个命令就让Oracle数据库实现了行列混存。没什么特别的点。但是最近我遇到了一个问题，就是需要部分列加载有些问题深耕一下会发现不一样的为什么要深耕一下？是因为我要加载部分列。为什么不全部加载？那是因为内存有限。一个表中仅仅有2-3个字段需要聚合。全部加载浪费内存。全部加载会很大吗？会的，当你见过一个表

背景很特殊非我所负责的范围。别人求助我有一套Oracle数据库的ADG中断了。这个背景是十几年前这个Oracle数据库的高可用采用了阵列复制的存储层解决方案。这个方案虽然也能做容灾，但是不是Oracle官方的解决方案。这个技术完全依赖底层存储复制技术，其原理是主数据的磁盘变化，同步到灾备磁盘上进行文件块的改写来实现。这种技术其实可以用到很多数据库上。因为这根本不是数据库技术。（这点涉及到现在的问题

上周写了国产数据库的今天谈谈Oracle感谢Oracle从一毕业让我安装Oracle，我连Oracle是什么都不知道。到如今吃数据库这碗饭，真心的感谢Oracle带我进来。而从Oracle上学到的技术，用在其他数据库上基本都能用。有差异的只要学习差异就行。复用性还是非常高的。安全大约5年前，2020年4月10日Oracle通过公安部“信息安全技术 网络安全等级保护基本要求”(以下简称“等保2.0”

本身这两个其实没有关联性事情的起因是由于一个误操作，本来update where id=xxxx，结果where没带变成了全表更新，且提交了。但凡出现这种情况，操作人员一旦意识到了，不慌是不可能的。得知数据库是Oracle，那么还有机会。create table bak as select * from of timestamp to_timestamp (‘2015040216’,‘yyyymm

数据库自己会关闭吗？从现象来说Oracle MySQL Redis等都会出现进程意外停止的情况。而这些停止都是非人为正常关闭或者暴力关闭（abort或者kill 进程）一次测试环境的非关闭一般遇到这种情况先看一下错误日志吧。2025-06-01T06:26:06.352576+08:00PMON (ospid: ): terminating the instance due to ORA erro

最近生病，每天都去医院输液。所以有好几天没有更新了。前天晚上，呼叫我上线分析问题。当我问及出什么问题时候，给我的是一个报错指向不明确一般来说数据库（不管什么数据库）报错都会有自己的特点。比如Oracle的有Ora开头的，MySQL的有MY开头的。等等所有有时候说连接不上数据库，有数据库报错的，那么是数据库的连接数达到上限了。如果没有通常就是JVM那里的连接池的达到上限了。而今天这个说了几乎和没说一

注意这里说的是有时候按说故障有因有果，但是有时候吧。处理问题在外人看来像是玄学。事情起因上周有人求助，我远程连上去，瞬间看到/目录就剩下20K的空间了。然后打了几个命令以后变成了0K。这时候的现象是linux的命令补齐都用不了了。这时候就别想着细致的查问题。只能粗浅的查问题了。这个得知主要是是Oracle的数据库软件，那么最大可能是trace目录下。日志增加的可能性。tail命令查看alert的日

这个概念提出不是一天两天了具体怎么查，官方给出是一个课表之类的用例。但是这个其实让普遍的人认识不深刻。为此我看尹总监写过一篇以订单为用例的建模查询。我是看懂了。不过我不满足于此，我想看看怎么改。全文实践的只有查询，那么写呢？我开始的理解（我其实理解错了），就是对着表更新一行，他就把这行的一个字段更新了，如果这个字段在其他表上也有，那么一并更新了。这是我个人的理解。实验数据如下（我和官方的不一样）建

一次问题     数据库的归档日志很多，多到那个机器的硬件不足以处理了。查看了一下为什么产生这么多日志。发现其实都是一些不当的使用方式。比如开发人员建立了一个xxxx_temp从这么名字上就应该能猜出来这是要做什么？美其名曰是临时表。      就是导入一批数据，给这些数据做一系列加工（运算），然后再把这些数据删除。用SQL来描述，就是i