# Oracle运维避坑案例整理
> 整理自用户提供的《新炬运维避坑指南合集》41 篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 **73 个案例**。期数按专辑标题编号；来源链接取自离线文章元数据。
[查看或下载 Markdown 原稿](新炬运维避坑案例整理.md)
## 案例目录
- [第 37 期｜Oracle 数据库undo段中的某些槽位wrap](#case-1)
- [第 36 期｜oracle迁移磐维pg_log报错](#case-2)
- [第 36 期｜ORACLE数据库句柄不释放](#case-3)
- [第 35 期｜Oracle数据库 log file sync 过高问题分析](#case-4)
- [第 34 期｜Oracle数据库连接异常问题分析](#case-5)
- [第 34 期｜oracle事务受到影响问题分析](#case-6)
- [第 32 期｜oracle实例发生重启](#case-7)
- [第 32 期｜oracle ADG库延迟](#case-8)
- [第 32 期｜oracle同步异常](#case-9)
- [第 32 期｜oracle switch datafile all失败](#case-10)
- [第 32 期｜oracle OGG同步报错](#case-11)
- [第 31 期｜oracle系统响应缓慢](#case-12)
- [第 31 期｜oracle会话数异常](#case-13)
- [第 31 期｜oracle LMD0进程报错](#case-14)
- [第 30 期｜oracle集群搭建过程中执行报错问题分析](#case-15)
- [第 30 期｜oracle编译报错问题分析](#case-16)
- [第 30 期｜oracle无法连接数据库问题分析](#case-17)
- [第 30 期｜oracle单个节点CPU使用率100%问题分析](#case-18)
- [第 28 期｜Oracle 备份一体机异常与策略配置问题](#case-19)
- [第 28 期｜Oracle ORA-32771问题分析](#case-20)
- [第 28 期｜Oracle 主机更换内存后，集群节点2未重启](#case-21)
- [第 26 期｜Oracle库表空间连续段不足问题分析](#case-22)
- [第 26 期｜Oracle数据库adg环境下（无OGG同步），主库归档无法删除问题分析](#case-23)
- [第 26 期｜Oracle数据库磁盘组满导致备库数据文件落到本地磁盘问题分析](#case-24)
- [第 26 期｜oracle数据库OGG问题分析](#case-25)
- [第 24 期｜ORACLE数据库备份存储厂商挂载的iscsi设备异常，导致数据库LGWR进程夯死，触发CRS集群将实例GACDB1踢出重启问题分析](#case-26)
- [第 24 期｜ORACLE数据库ORA-1653问题分析](#case-27)
- [第 24 期｜ORACLE ORA-01558故障分析与防范](#case-28)
- [第 20 期｜数据库ORA-01000错误](#case-29)
- [第 20 期｜redhat9.4安装oracle19c-rac集群](#case-30)
- [第 20 期｜Oracle数据库国产操作系统业务积压](#case-31)
- [第 20 期｜坏块导致备份失败](#case-32)
- [第 20 期｜ogg空间告警，数据trail文件无法自动删除](#case-33)
- [第 20 期｜OGG复制进程延迟很高](#case-34)
- [第 18 期｜oracle-IPV6改造问题](#case-35)
- [第 18 期｜oracle大量异常等待导致cpu耗尽分析](#case-36)
- [第 17 期｜国产操作系统欧拉安装Oracle19C问题](#case-37)
- [第 17 期｜ORACLE 告警日志频繁报ORA-6550](#case-38)
- [第 17 期｜ORACLE 已创建索引sql执行全表扫描](#case-39)
- [第 17 期｜ORACLE 回收站清理报ORA-01555错误](#case-40)
- [第 16 期｜导入csv文件报错问题分析](#case-41)
- [第 16 期｜table or view ‘’does not exist](#case-42)
- [第 15 期｜全量校验，报错ORA-08181](#case-43)
- [第 14 期｜oracle大量“cursor: pin S wait on X”等待事件导致数据库DBTIME较高](#case-44)
- [第 14 期｜oracle数据库出现ORA-04031报错，节点实例down，业务登录数据库失败](#case-45)
- [第 14 期｜oracle软件安装目录使用率异常增长](#case-46)
- [第 14 期｜oracle大量异常等待分析](#case-47)
- [第 12 期｜ORACLE IPV6改造报错处置](#case-48)
- [第 12 期｜ORACLE ADG同步延迟处置](#case-49)
- [第 11 期｜Oracle监听日志异常增长处置](#case-50)
- [第 11 期｜oracle ADG 主备库切换演练，备库直接关机致主库关闭](#case-51)
- [第 11 期｜同一sql，](#case-52)
- [第 9 期｜Oracle lib文件权限只读导致补丁升级失败](#case-53)
- [第 9 期｜Oracle IPV4+IPV6双栈改造实施后，单节点vip资源无法正常开启](#case-54)
- [第 9 期｜Oracle由于安全扫描程序命中bug导致数据库hang死](#case-55)
- [第 9 期｜OGG因NFS系统故障hang死](#case-56)
- [第 8 期｜Oracle数据库迁移至 ANTDB](#case-57)
- [第 8 期｜ORACLE DG故障处置](#case-58)
- [第 8 期｜ORACLE数据库资源使用高处理](#case-59)
- [第 7 期｜ORACLE执行SQL报错temp表空间不足](#case-60)
- [第 7 期｜ORACLE SQL语句响应缓慢应](#case-61)
- [第 5 期｜万里开源数据库集群同步异常处置](#case-62)
- [第 4 期｜ORACLE数据库hung处置](#case-63)
- [第 3 期｜SQLServer新增ogg表迁移传输失败](#case-64)
- [第 3 期｜ORACLE数据库主机hang死](#case-65)
- [第 3 期｜ORACLE数据库IO性能处置](#case-66)
- [第 3 期｜ORACLE UDEV绑定的别名消失](#case-67)
- [第 2 期｜ORACLE数据库执行计划变更致CPU资源耗尽](#case-68)
- [第 2 期｜ORACLE数据库突然宕机，并无法启动](#case-69)
- [第 2 期｜ORACLE 19C ASM扩容无法添加磁盘](#case-70)
- [第 1 期｜大页参数设置不规范导致故障](#case-71)
- [第 1 期｜Oracle备份进程未完成，导致白天影响业务](#case-72)
- [第 1 期｜Oracle表空间有剩余但依旧无法插入数据处置](#case-73)
## 第 37 期｜Oracle 数据库undo段中的某些槽位wrap
- 专辑文件：`05.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566533&idx=1&sn=11ecbd808f10f786c867e1e3ae953a0c&chksm=f8f446b9c87027cc675c1fe462ddc7e885a328c528ec75f48ef8589aead153daf70da9d74252#rd)
- **现象：** 某业务系统下应用主机状态接连夯，DBA通过检查日志发现有报错；ORA-01558: out of transaction ID's in rollback segment _SYSSMU354_1685888789$；的ORA报错，最终定位undo段中的某些槽位wrap
- **处置过程：** 上午收到告警，某业务系统应用主机接连夯住。；检查数据库主机资源使用情况，并向接口人汇报需对这些夯死主机进行硬重启，重启后通过智能运维工作台检查主机历史资源使用情况，发现故障期间内存占用过高，继续检查是进程占用过高内存情况，并未发现新增进程。
- **运维建议：** 版本风险意识；当前使用的 Oracle 12.2.0.1 版本存在已知 Bug，易在高并发场景下出现 Undo 段事务槽耗尽问题，需推动业务尽快上云。；监控与巡检前置
## 第 36 期｜oracle迁移磐维pg_log报错
- 专辑文件：`06.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** oracle迁移磐维，dtp迁移时，主节点coredump，pg_log报错 stack smashing detected。
- **处置过程：** 故障集群背景；PanWeiDB_V2.0-S3.0.0_B01三节点集群。；在将oracle数据迁移到三节点磐维集群后，发生主备切换。
- **运维建议：** 及时关注磐维数据库版本更新，以及更新后所解决问题。
## 第 36 期｜ORACLE数据库句柄不释放
- 专辑文件：`06.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** 文件系统目录使用率告警，审计日志的删除使用rm -rf *.aud，报错；bash: /usr/bin/rm: Argument；list too long
- **处置过程：** Linux 系统限制单次命令参数长度约 2MB，当文件数量超过数万时，rm 命令直接失败。；空间剩余足够：mv adump adump.bak &&；adump rm -rf adump.bak
- **运维建议：** 审计策略优化；ALTER SYSTEM SET audit_sys_operations= FALSE SCOPE = spfile；关闭sys审计
## 第 35 期｜Oracle数据库 log file sync 过高问题分析
- 专辑文件：`07.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** log file sync 过高，占 DB time 约 40%；同时 log file parallel write 也过高；REDO 所在磁盘利用率长时间保持在 80% 以上，整体事务性能不佳。
- **处置过程：** TSP 高达 9000 左右，但重做日志所在磁盘组物理和逻辑扇区均为 512，顺序读写能力受限，无法充分发挥 NVME SSD 磁盘性能，且REDO磁盘组只有一块磁盘，负载较高。；首选方案使用 4K 扇区磁盘替换，或加入一块磁盘分散负载。
- **运维建议：** 前期规划时应充分评估业务，进行针对性优化；部署前充分评估工作负载，部署时严格按最佳实践执行
## 第 34 期｜Oracle数据库连接异常问题分析
- 专辑文件：`08.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 业务侧反馈核心数据库连接异常，许多sql都在等io资源。；查看历史等待事件，发现SQL_ID “；”异常等待很高，查看sql执行计划并查看该表大小，判断该sql应该是一个子句，在1节点执行。
- **处置过程：** 先检查数据库的等待事件，确认是否有异常等待，经确认；Disk file operations I/O 非常高
- **运维建议：** SQL执行前检查SQL语句，禁止使用并发；对于大表的访问若一定要使用全表扫描，需在业务低峰时段执行
## 第 34 期｜oracle事务受到影响问题分析
- 专辑文件：`08.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565290&idx=1&sn=2eb4aab29ad488b7725e5c6e405ba395&chksm=f811046cbfbaa3f59adfb44e20f36ead80b5ea06f11d7b5c428d3ff5cc0b33e6df6446c0b3c8#rd)
- **现象：** 双节点RAC，其中一个节点主机硬件原因重启，存活节点的 LGWR和CKPT被阻塞，导致事务受到影响。
- **处置过程：** crs misscount 配置过高，导致集群层面 reconfig 时间过长，存活节点数据库实例的 LGWR 和 CKPT 被长时间阻塞。；私网网卡未配置巨型帧，reconfig 时 UDP 包大量溢出，导致全局资源被冻结时间过长。
- **运维建议：** 调高 misscount 不是为了从根本上解决集群心跳网络不佳的问题，而是掩盖问题，最终引发更严重的问题。应参照最佳实践进行部署。
## 第 32 期｜oracle实例发生重启
- 专辑文件：`10.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** 生产环境某节点实例发生重启。
- **处置过程：** 查看alter日志上有LGWR进程被kill的报错信息，然后实例重启，bomc平台上查看重启时间段的cpu情况，查看等待会话及等待事件都显示正常。；捞取osw报告分析实例1是被实例2和实例3在集群层面被"member kill"了，是因为实例2 Voting file /rasm/disk30002 超过90%的最大允许时间内没有IO,所以被驱逐，检查节点2 OSW VMSTAT数据发现"b"列数据明显异常增多，而且"IOWAIT"也异常增多，在iostat数据中显示，磁盘很多时候没有io,但是使用率接近100%，节点2和存储之前的连通性有异常。；初步分析是io异常，后续转主机侧进行协助分析处理。
- **运维建议：** 定期巡检数据库，检查数据库日志，osw报告，发现潜在风险提前进行处理解决。
## 第 32 期｜oracle ADG库延迟
- 专辑文件：`10.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** ADG库每到业务高峰期就开始延迟，日志应用缓慢。
- **处置过程：** 数据库层面分析；首先查看延迟和MRP进程应用情况，延迟7小时56分钟，MRP0进程也一直在应用归档，BLOCK；#一直在变化
- **运维建议：** 当问题分析和处理的一个方向没有进展时，需要从多角度去分析，并和客户充分沟通，获取更多的信息。；本例就是从数据库层面尝试解决无果后，发现主机层面存在问题，和客户充分沟通后发现问题出现前进行了底层环境迁移，最后通过重启操作系统解决。
## 第 32 期｜oracle同步异常
- 专辑文件：`10.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** 磁盘空间不足，备库数据文件创建失败，导致同步异常。；在日常DG扩容中，当standby_file_management=manual或者磁盘空间已满，就有可能出现在Standb DB创建文件失败的，如下；ORA 01111 name for data file 35 is unknown rename to correct file ORA 01110 data file 35
- **运维建议：** 及时关注库状态，在发生磁盘快满得情况，；切换归档或者数据文件得路径。
## 第 32 期｜oracle switch datafile all失败
- 专辑文件：`10.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** 搭建备库，应主库不同路径下有相同名数据文件导致switch datafile all失败。
- **处置过程：** 因主库两个文件系统中有数据文件的名字一致，但又因为备库这边的ASM盘目录只设置了一个，在脚本set newname时，带上了具体名字，导致在ASM目录中，数据文件名字重复，只过来了一个参数文件。在duplicate脚本日志的最后switch datafile all是失败的。；手动执行后还是报错，这也导致控制文件中的数据文件的路劲没有改变，而且也存在一个数据文件没有同步过来，mrp进程此时是拉不起来的。；经过确认后，决定对两个同名的数据文件进行单独备份，然后恢复到备库，最后在备库中重新修改数据文件的名字。
- **运维建议：** 运行duplicate脚本的时候提前确认好有无数据文件同名。
## 第 32 期｜oracle OGG同步报错
- 专辑文件：`10.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** 使用OGG同步的表在主库中未添加附加日志，导致同步进程时报错；OGG-01431、OGG-01003、OGG-01151、OGG-01296。
- **处置过程：** 检查主库中是否添加附加日志；from dba_log_groups where；table_name =
- **运维建议：** ogg进程abended的几种常见原因；1）undo表空间不足导致abended。；2）数据不一致，违反唯一约束导致abended。
## 第 31 期｜oracle系统响应缓慢
- 专辑文件：`11.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** 工单系统在进行提交操作、查询操作时，系统响应缓慢且无法提交。；登录检查数据库运行状态正常，期间数据库中其他应用系统未反馈有异常；数据库专家接入分析，workflow用户会话信息及数据库等待事件无异常，数据库表空间使用率和数据库实例均正常
- **运维建议：** 查看表统计信息变化时间；发现上午有两次变化，可以确定工单系统执行效率低是该用户中表的统计信息有变化。；表频繁发生DML操作，会导致oracle自动收集统计信息
## 第 31 期｜oracle会话数异常
- 专辑文件：`11.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** 运维监控A库；（4节点RAC）；长期出现会话数、活动会话数、异常等待、锁等待、以及大量的gc相关的等待。每个节点会话数经常超3000，每个节点活动会话数经常达到300+，数据库性能已经严重下降。
- **处置过程：** 数据库、主机、网络、业务进行综合优化；分析AWR等报告；根据近期AWR、ASH确认告警期间，主要锁等待来源于对告警表和告警历史表的insert，非常的频繁，经常造成索引分裂的等待，根据AWR中提示的最繁忙的4个索引，找业务确认这些索引的使用场景，业务确认这四条索引使用的很少，可删除。
- **运维建议：** 号节点的私网配置和其他主机不一致，网卡队列缓存为512，其他节点均为4096。3节点改成4096。；CPU软中断数；3号节点大部分CPU资源都消耗在两个逻辑CPU上，这两个CPU中断数经常被占满。而其他节点压力都是均摊到多个CPU上，单个CPU使用率、中断数都不高。联系主机工程师排查。
## 第 31 期｜oracle LMD0进程报错
- 专辑文件：`11.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** 某业务数据库多次出现LMD0进程报错之后实例发生重启的问题。
- **处置过程：** 某日16:19分；接到告警某oracle数据库2节点JDBC连接失败，检查2节点数据库日志发现使用私网通讯的LMS0进程由于通讯超时导致2节点实例被驱逐，重启集群后数据库恢复正常，查询MOS怀疑是私网网络问题导致数据库宕，收集了主机日志提交给主机工程师分析未发现硬件报错。；某日13:09分
- **运维建议：** ，默认值为4M和3M，默认值过小，需调整到16M和15M。将这两个参数按照ORACLE设置为16M和15M后，观察了未再出现数据库实例宕的情况。；数据库上线时需严格按照主机、数据库最佳实践进行部署，避免后续上线后由于参数设置不规范引发各种生产故障。
## 第 30 期｜oracle集群搭建过程中执行报错问题分析
- 专辑文件：`12.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** oracle-19c-rac集群搭建过程中执行root.sh脚本时报错，gipcd进程未启动。；clsrsc-119 start of；the exclusive
- **处置过程：** gipcd进程未启动，报错clsrsc-119；结合mos 2568395.1文档，19c下；cluster-name<15 length
- **运维建议：** 此问题是由于19c-bug导致，暂未修复。；在使用19c搭建oracle-rac集群期间，cluster-name的长度需要小于15。
## 第 30 期｜oracle编译报错问题分析
- 专辑文件：`12.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** oracle-12c json_value type包编译报错，pls-00103出现符号";"在需要下列之一时:(
- **处置过程：** json_value type包在oracle-11g时编译成功，但是在oracle-12c编译失败，期间该代码无任何改动。；看着是语法导致的问题，但是语法整体性完整，无语法问题。；json_value 是12c 内置函数 ，是个关键字，调整type中的函数名字后成功。
- **运维建议：** oracle-12c新增了很多关于json的函数，在oracle-11g时，开发了大量的json函数包，type包。；数据库升级后不能直接迁移到oracle12c上，需要调整函数名，避免和关键字冲突。
## 第 30 期｜oracle无法连接数据库问题分析
- 专辑文件：`12.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** windows环境中应用连不上数据库，重启监听报错，重建监听和重启数据库后都不行。
- **处置过程：** 适配器错误，连接关闭。；检查环境变量，重启监听；重新清理注册表后，依旧监听报错，适配器错误，连接关闭。查看监听错误日志
- **运维建议：** 调整sqlnet.ora文件后需要及时重启监听，避免后续出现问题后无从下手分析。
## 第 30 期｜oracle单个节点CPU使用率100%问题分析
- 专辑文件：`12.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** RAC集群中单个节点CPU使用率100%。；PAAS集群一个实例节点主机CPU使用率100%，所有PDB服务状态均为offline状态。
- **处置过程：** 检查CPU TOP进程；均为数据库后台进程占用，同时数据库alert日志报大量后台进程自动重启失败。；检查trace日志
- **运维建议：** 对于这种偶发性问题，除了需要监控主机剩余可用资源以外，还要考虑系统长时间运行产生的其他碎片问题。；比如物理内存碎片，数据库逻辑内存碎片；（SGA、PGA等）
## 第 28 期｜Oracle 备份一体机异常与策略配置问题
- 专辑文件：`14.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562405&idx=1&sn=5764e321cddf8d027678d4f3c4236f63&chksm=f8a25ac12867bf0f378586a0e275e57117dc193c1d28f6df10c196bf48cf0e5a4ac5a7ebede2#rd)
- **现象：** 备份一体机Oracle备份出现未知异常。
- **处置过程：** 备份客户端安装在了/tmp下；卸载备份客户端，重新安装至/opt目录下；；/opt/CDMClient/HWClientService/cfl.config；文件中在最后添加打开tracelog开关；赋予
- **运维建议：** 安装路径规范；在部署备份客户端时，应避免将其安装在临时目录；（如 /tmp）
## 第 28 期｜Oracle ORA-32771问题分析
- 专辑文件：`14.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562405&idx=1&sn=5764e321cddf8d027678d4f3c4236f63&chksm=f8a25ac12867bf0f378586a0e275e57117dc193c1d28f6df10c196bf48cf0e5a4ac5a7ebede2#rd)
- **现象：** ORA-32771 signalled during；alter tablespace SYSTEM add datafile；'+DATA'
- **处置过程：** 常规表空间扩容；alter tablespace SYSTEM add datafile；'+DATA'
- **运维建议：** 注意检查表空间是否为bigfile，如果是bigfile，则只能resize datafile；日常数据库运维操作一定要小心谨慎加检查，严格按照日常运维手册进行操作
## 第 28 期｜Oracle 主机更换内存后，集群节点2未重启
- 专辑文件：`14.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562405&idx=1&sn=5764e321cddf8d027678d4f3c4236f63&chksm=f8a25ac12867bf0f378586a0e275e57117dc193c1d28f6df10c196bf48cf0e5a4ac5a7ebede2#rd)
- **现象：** 因机房检查需要更换数据库内存，内存更换完成后重启服务器，发现集群节点2 crs没有起来，查看crs日志发现下面问题CRS-2419；The clock；host rac2 differs
- **处置过程：** 使用date命令，发现服务器节点2与其他节点时间不同步。；systemctl status ntpd查看服务器ntp状态为关闭，date -s手动调整时间，使其同步。；启动ntp服务systemctl start ntpd，让节点2时间慢慢拉平，再次启动CRS服务，启动成功。
- **运维建议：** 重启服务器后观察集群时间是否同步；因此，在重启服务器后，立即检查集群各节点的时间是否同步。这一步骤可以有效预防因时间不同步导致的服务启动失败问题。；通过本次故障处理，我们发现NTP服务的关闭是导致时间不同步的直接原因。
## 第 26 期｜Oracle库表空间连续段不足问题分析
- 专辑文件：`16.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** Oracle库表空间连续段不足。
- **处置过程：** 监控异常等待事件告警，检查数据日志：有很多ORA-1653告警。说明表空间已无空间使用，表空间紧急添加32G数据文件。；事后分析发现，加完32G数据文件，211G空闲空间剩余的联系段只有29G。；由于频繁的插入、更新和删除操作，导致表空间中的数据块变得不连续，形成大量的空闲空间碎片，小的空间碎片无法被利用，导致表写入失败。
- **运维建议：** 有效的监控机制；在本次事件中，一个显著的问题是我们没有为表空间连续段添加有效的监控机制。表空间连续段的不足是一个潜在的性能瓶颈，如果能够在问题发生前进行预警和干预，就可以避免类似故障的发生。；因此，我们应该加强对表空间连续段的监控，通过定期的空间分析和预警机制，及时发现并处理潜在的空间碎片问题。
## 第 26 期｜Oracle数据库adg环境下（无OGG同步），主库归档无法删除问题分析
- 专辑文件：`16.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** adg环境下；（无OGG同步）；，主库归档无法删除，报错
- **处置过程：** 通过查看 dba_capture表，发现发现捕捉名称为OGG$CAP_EX_OM的程序，状态为DISABLED。；在命令行执行；exec DBMS_CAPTURE_ADM.DROP_CAPTURE ('OGG$CAP_EX_OM')
- **运维建议：** 定期检查捕获进程
## 第 26 期｜Oracle数据库磁盘组满导致备库数据文件落到本地磁盘问题分析
- 专辑文件：`16.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** 主库表空间扩容，因原使用的磁盘组满，添加数据文件到其他磁盘组，导致备库数据文件落到本地磁盘，进而导致主备同步延迟，备份侧进行备份也失败。
- **处置过程：** 备库查看延迟；查看磁盘组使用情况，对应磁盘组DATADG空间耗尽；查看备库db_create_file_dest参数，指向DATADG，数据文件落到本地磁盘
- **运维建议：** 制定扩容方案要考虑全面；本次故障提醒我们，在进行表空间扩容时，必须全面评估所有相关磁盘组的空间使用情况。不仅要考虑主库的需求，还要充分预见备库在同步这些变更时可能遇到的问题。；这要求我们在制定扩容方案时，要综合考虑主备库的环境和资源限制。
## 第 26 期｜oracle数据库OGG问题分析
- 专辑文件：`16.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** 割接当晚增加字段后，业务开始增多，ogg核心复制进程出现延时。
- **处置过程：** 系统资源分析；各项系统资源正常。；目标数据库分析
- **运维建议：** 对于没有主键及唯一约束的同步表，最好需要添加唯一约束及主键；在本次故障中，我们发现缺少主键和唯一约束的表在同步过程中需要进行全字段比对，这大大增加了OGG的处理负担。因此，在设计和维护数据库时，为需要同步的表添加主键和唯一约束，以提高同步效率。；对KEYCOLS定义的键列创建唯一索引
## 第 24 期｜ORACLE数据库备份存储厂商挂载的iscsi设备异常，导致数据库LGWR进程夯死，触发CRS集群将实例GACDB1踢出重启问题分析
- 专辑文件：`18.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 一体机的数据库备份在节点1进行，通过iscsi协议将备份服务端的磁盘(sdb/sdc)通过备份网络挂载到一体机上作为本地磁盘，并挂载为本地文件系统以此来存放数据库备份文件，备份完成后卸载该iscsi磁盘。；严格把关监控体系的建设。对于关键数据库等待事件和异常，应建立及时有效的预警机制。通过实时监控数据库的性能指标和异常事件，可以及时发现潜在问题并采取相应措施。；2）备份策略的优化
- **处置过程：** 1）检查实例重启前后数据库alert日志；发现大量datafilecopy header validation failure报错，报错路径均为备份厂商iscsi设备sdb盘上的数据文件备份copy；；随后数据库LGWR进程夯死，日志显示lgwr从异常到等待持续了74s，同时数据库CKPT一直获取不到控制文件锁，报此等待事件： enq: CF – contention，然后check point stuck，然后数据库实例被pmon终止；
- **运维建议：** 1）严格把关监控体系的建设；此次故障提醒我们，必须
## 第 24 期｜ORACLE数据库ORA-1653问题分析
- 专辑文件：`18.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 一体机CRMPDB ORA-1653 错误分析。
- **处置过程：** 3/4节点CRMPDB在5.6日 13:39:12开始出现大量ORA-1653 报错， 增加datafile后，报错消失，数据库恢复正常。；数据库的SMON进程的一个作用是回收合并空闲空间(整理区碎片)；SMON负责把那些在表空间中空闲的并且互相是邻近的Extent接合成一个较大的空闲扩展区，并回收空闲空间，以减少数据库的碎片化，每5分钟检查执行一次。当有大量insert数据的对象在碎片较多，free space 较少的表空间时，扩展空间申请的量很大，并发很高，会出现ORA-1653,申请空间失败，导致session hang。
- **运维建议：** 1）生产业务高峰期，避免大批量的DML操作；尤其是占用大量空间的sql，操作前需提前检查空间使用情况。；）生产业务表空间，free space 保持在15%以上
## 第 24 期｜ORACLE ORA-01558故障分析与防范
- 专辑文件：`18.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 开启drm导致数据库后端有ora-01558故障。
- **处置过程：** 业务反馈出现ORA-01558故障，然后通过重建undo解决了。；分析原因发现是设置_gc_undo_affinity=FALSE，这样会更快的使用xid，导致undo xid耗尽引发故障。Oracle的开发认为这不是一个bug，所以不会有补丁。
- **运维建议：** ）_gc_undo_affinity=true，开启drm会带来其他性能问题，不。；2）针对undo xid使用情况进行监控，当xid使用了90%，重建undo。；1）合理配置 _gc_undo_affinity 参数
## 第 20 期｜数据库ORA-01000错误
- 专辑文件：`22.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559317&idx=1&sn=a31da36bf1dabcb830d3afa62047d913&chksm=f8aa5b88b2a20b367f6b9d382ebe934494bf294c6974e06553d0031ccc70008ce87d27e4b66c#rd)
- **现象：** 某业务数据库ORA-01000 错误，查得为open_cursors设定问题。
- **处置过程：** 查得数据库当前游标参数，目前查出来是300，确实有点小，尝试修改到1000，依然报错，业务研发提出要修改到2000，实则修改这么大是不合理的。；再次修改到2000，业务测试依然报错，查询v$open_cursor确认语句，反馈业务查找代码，业务最终查得原因为应用程序打开了游标，却没有在它完成工作后没有及时关闭。
- **运维建议：** 深入理解错误本质；ORA-01000错误的直接原因；此错误通常指示数据库中的open_cursors参数设置不足以满足当前会话的游标需求。然而，这仅仅是表象，背后可能隐藏着更深层次的问题。
## 第 20 期｜redhat9.4安装oracle19c-rac集群
- 专辑文件：`22.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559317&idx=1&sn=a31da36bf1dabcb830d3afa62047d913&chksm=f8aa5b88b2a20b367f6b9d382ebe934494bf294c6974e06553d0031ccc70008ce87d27e4b66c#rd)
- **现象：** 从官方下载的数据库安装包是19.3版本，不支持redhat9.4.故需要在安装集群前需要做升级操作。
- **处置过程：** grid镜像升级；解压grid19.3 安装包后，需要将19.23版本的grid的psu,dbru,ojvm做升级操作。；./gridSetup. sh
- **运维建议：** 预先规划与系统兼容性检查；确认软件版本兼容性；在安装之前，必须详细检查Oracle官方文档或MOS（Metalink Online Support，现更名为My Oracle Support）上的兼容性矩阵，确保Oracle 19c RAC支持Redhat9.4。在本案例中，虽然Oracle 19c本身不支持直接安装在Redhat9.4上，但通过升级补丁包可以实现兼容性。
## 第 20 期｜Oracle数据库国产操作系统业务积压
- 专辑文件：`22.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559317&idx=1&sn=a31da36bf1dabcb830d3afa62047d913&chksm=f8aa5b88b2a20b367f6b9d382ebe934494bf294c6974e06553d0031ccc70008ce87d27e4b66c#rd)
- **现象：** Oracle数据库国产操作系统替换影响到了客户内存库的数据传输，导致业务积压。
- **处置过程：** 7.2.1；oracle软件安装完毕，做dg同步，同一时间可能会有很多库进行，会占用大量网络带库，影响其他数据库的数据传输；本次案例就是影响到了客户内存库的数据传输，导致业务积压。
- **运维建议：** 网络带宽管理与数据同步优化；提前规划与协调；在进行大规模的数据库DG同步时，必须提前与网络团队协调，确保有足够的带宽资源。同时，制定详细的网络使用计划，避免高峰时段进行高带宽消耗的操作。
## 第 20 期｜坏块导致备份失败
- 专辑文件：`22.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559317&idx=1&sn=a31da36bf1dabcb830d3afa62047d913&chksm=f8aa5b88b2a20b367f6b9d382ebe934494bf294c6974e06553d0031ccc70008ce87d27e4b66c#rd)
- **现象：** oracle数据库有坏块导致备份失败。
- **处置过程：** 备份日志报错；rman 03009 ora 19566；exceeded limit of
- **运维建议：** 及时识别与定位问题；当备份日志中出现如；rman-03009 ora-19566
## 第 20 期｜ogg空间告警，数据trail文件无法自动删除
- 专辑文件：`22.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559317&idx=1&sn=a31da36bf1dabcb830d3afa62047d913&chksm=f8aa5b88b2a20b367f6b9d382ebe934494bf294c6974e06553d0031ccc70008ce87d27e4b66c#rd)
- **现象：** ogg空间告警，设置保留策略，数据trail文件也无法自动删除。
- **处置过程：** ogg安装在主机目录/back_data空间使用率高，发现其中/back_data/ogg/dirdat数据文件目录占用达1.8T，其中最早是到2024年1月份，查看数据文件ep对应的进程ext-p，序列号已经到ep028742，目录下最早的是ep026914，管理进程mgr配置的清理策略是保留3天。；从日志来看确实有清理动作，但是清理的日志文件序列号26913很小，无法满足空间要求，同时看到pum-p进程这是投递进程的日志切换序列号是26914，因为清理使用usecheckpoints参数，也就是确保所有进程对该文件没有访问，持续往后推进，这里不免怀疑管理进程把本地trail文件序列号与远程trail文件序列号当成一样对待，都要确保序列号不再使用，这里可能也是bug，没搜到相关补丁或修复说明。；使用修改目标端tr…
- **运维建议：** 源端与目标端Trail文件的明确区分；在GoldenGate；（OGG）
## 第 20 期｜OGG复制进程延迟很高
- 专辑文件：`22.html`，第 11 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559317&idx=1&sn=a31da36bf1dabcb830d3afa62047d913&chksm=f8aa5b88b2a20b367f6b9d382ebe934494bf294c6974e06553d0031ccc70008ce87d27e4b66c#rd)
- **现象：** 复制进程严重延时，超过10小时，Time Since Checkpoint 过高，通过info看到是在不断变化，trail文件存在丢失的情况。
- **处置过程：** 通过查看当前会话，发现存在慢SQL，根据SQL信息发现缺少统计信息，大表数据结构和数据是分开导入的，索引创建后，没有正常刷入统计信息。；调大的trail文件保留时间。；查询延迟时段的慢SQL，优化慢SQL，主要是调整统计信息。
- **运维建议：** 合理设置Trail文件保留时间；根据业务的实际数据量和复制进程的负载，设置合适的Trail文件保留时间可以有效防止数据丢失。Trail文件保留时间过短可能导致数据丢失或复制进程延迟，而设置过长则可能占用过多的存储资源。通过合理配置Trail文件保留时间，可以确保在出现延迟或丢失的情况下，有足够的历史数据用于恢复和处理。；优化慢SQL查询
## 第 18 期｜oracle-IPV6改造问题
- 专辑文件：`24.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557767&idx=1&sn=69ce887ff2044e523ab1ab089655c2b1&chksm=f89e7d05abda444a45ee125a3b68780fa677b20ebb033ecd5db39244b9b06ad31dee41c79c76#rd)
- **现象：** Oracle-IPV6改造问题；使用IPv6的subnet[子网号],将新的public网口添加到集群时报错。；启动scan_listener失败,提示scan ip的地址已经被使用。
- **处置过程：** 1.2.1 IPV6改造问题1；使用IPv6的subnet[子网号],将新的public网口添加到集群时报错；xnpmdb1:/home/oracle(xnpmdb11)$oifcfg setif -global bond0/2409:8050:5a00::fdfb:1:4c00:public
- **运维建议：** 在进行IPv6配置或任何网络参数的改变前，确保所有相关的网络设备；（如交换机、路由器）；（如DNS、DHCP）
## 第 18 期｜oracle大量异常等待导致cpu耗尽分析
- 专辑文件：`24.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557767&idx=1&sn=69ce887ff2044e523ab1ab089655c2b1&chksm=f89e7d05abda444a45ee125a3b68780fa677b20ebb033ecd5db39244b9b06ad31dee41c79c76#rd)
- **现象：** 19c ORACLE数据库出现大量cursor:mutex X等待事件，导致主机CPU耗尽，严重影响业务运行。
- **处置过程：** 某场地接到告警一套核心19.7版本 ORACLE数据库中出现了4000+ 个cursor:mutex X等待事件，同时CPU使用率达到99%，相关业务出现大量积压，影响到业务正常。立刻对产生cursor:mutex X等待事件的会话进行全量KILL，在KILL掉会话后数据库恢复正常。；之后将该问题提交SR分析，SR反馈命中了；BUG 28889389 High waits on cursor:mutex x after upgrade to 12.1.0.2 and higher release
- **运维建议：** 所以针对该问题原厂应用这3个one-off patch，但是经过测试这3个one-off patch之间互相存在冲突，所以最终决定将数据库版本由19.7版本升级至19.17版本。；当前19c数据库低版本存在较多的BUG，在安装19C数据库时将版本升级至19.17及以上的稳定版本；对应用侧上线的SQL进行规范，上线SQL绑定变量的长度尽量为固定值
## 第 17 期｜国产操作系统欧拉安装Oracle19C问题
- 专辑文件：`25.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** 国产操作系统欧拉安装Oracle19C碰到报错问题。
- **处置过程：** PRVG-0282；failed to retrieve the operating system distribution ID报错异常退出。；cat $ORACLE_HOME/cv/admin/cvu_config找到CV_ASSUME_DISTID取消注释。
- **运维建议：** 建立记录文档
## 第 17 期｜ORACLE 告警日志频繁报ORA-6550
- 专辑文件：`25.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** 数据库告警日志频繁报ORA-6550处理。
- **处置过程：** 查看alert日志，频繁报；****Encountered error ORA-6550.****；根据日志提示信息为某物化视图刷新失败，
- **运维建议：** 深入分析物化视图的刷新策略和频率，；以确定是否需要调整以避免未来的失败；使用DBMS_MVIEW.EXPLAIN_MVIEW来分析物化视图的能力和限制，这有助于确定物化视图是否配置正确。
## 第 17 期｜ORACLE 已创建索引sql执行全表扫描
- 专辑文件：`25.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** select xx from xx from id=? 全表扫描。
- **处置过程：** 原因是ID字段创建索引时，写成了xx；(‘id’)；,导致创建索引时创建的不是单字段索引，而是成了普通函数索引。
- **运维建议：** 使用 EXPLAIN PLAN 命令来验证查询是否真正使用了索引；如果没有，重新审视索引的创建语句。；正确重建索引
## 第 17 期｜ORACLE 回收站清理报ORA-01555错误
- 专辑文件：`25.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** 回收站清理报ORA-01555错误。
- **处置过程：** 一个一个地清理回收站中的表对象，而不是通过purge dba_recyclebin命令。；找到回收站为何急剧增长的原因。
- **运维建议：** 如果频繁出现ORA-01555错误，考虑增加撤销表空间的大小；可以通过调整撤销表空间来提供更多的撤销记录容量，从而支持更长时间的查询和更大的事务。；将大规模的删除操作分批进行
## 第 16 期｜导入csv文件报错问题分析
- 专辑文件：`26.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247556156&idx=1&sn=6b54be643f58f54bb692c56b304e7457&chksm=f85124e810a0278882f059e7df8f916171936d8d8ca0ac01e0331ba2b579d3c482ea95bc0589#rd)
- **现象：** 导入csv数据报错；Error ORA-01400；cannot insert Nul into 'ACTION ID
- **处置过程：** 业务中空值字段使有用字符串"null"表示，也有用空值表示，odc导入字符串是当成了空值，字段不允许空值，故报错。；修改导出内容null > \N即可，\N表示为空值，"null"即可正常按照字符串导入。
- **运维建议：** 标准化导出数据格式；在导出CSV文件之前，确保所有字段的数据格式标准化，对于空值的表示使用一致的方式；（如使用\N表示空值）
## 第 16 期｜table or view ‘’does not exist
- 专辑文件：`26.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247556156&idx=1&sn=6b54be643f58f54bb692c56b304e7457&chksm=f85124e810a0278882f059e7df8f916171936d8d8ca0ac01e0331ba2b579d3c482ea95bc0589#rd)
- **现象：** table or view ‘’does not exist
- **处置过程：** 在ob库及oracle库查询是否有该表信息。；排查业务日志中排查关于该表的操作记录，该表属于建表后再删除的逻辑。；发现该表在当日业务进行查询前有一条相对异常的删除记录，协调业务侧排查自身程序。
- **运维建议：** 增强数据库审计；确保数据库有完整的审计功能，记录所有DDL操作；（如CREATE, DROP, ALTER等）
## 第 15 期｜全量校验，报错ORA-08181
- 专辑文件：`27.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554936&idx=1&sn=fe456980a70d40759890b2c0fefd336d&chksm=f82ff81260bc3efeaa8c83a3efea3a534c3a2da4dd7053074af1f18f8bb2e239597b835936ab#rd)
- **现象：** OMS全量校验任务报错；ORA-08181；specified number is not a valid system change number
- **处置过程：** 核查因OMS根据操作系统的系统时间来生成Oracle源端校验查询的SCN号，但该环境由于存在机器间时间不同步，停了ADG实时应用后，该SCN号不匹配Oracle ADG自己生成的SCN号。；通过调整ORACLE主库时间，使其与ADG库、OMS机器之间的时间同步后，再次全量校验，问题解决。
- **运维建议：** 使用NTP服务；确保所有数据库服务器（包括主库和ADG库）以及OMS系统都同步到同一个可靠的时间源。使用网络时间协议（NTP）可以帮助保持系统时间的一致性。；监控时间偏差
## 第 14 期｜oracle大量“cursor: pin S wait on X”等待事件导致数据库DBTIME较高
- 专辑文件：`28.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** 巡检发现大量“cursor: pin S wait on X”等待事件且数据库该时间端DBTIME高。
- **处置过程：** 巡检发现大量“cursor: pin S wait on X”等待事件；awr报告发现此时段dbtime极高；查询此等待事件均由sys发起，会话状态均为active
- **运维建议：** 使用Oracle的自动工作负载仓库（AWR）和自动数据库诊断监视器（ADDM）等工具来定期分析数据库性能，并根据报告进行优化；定期评估数据库设计，特别是锁定策略和并发控制机制，确保符合当前的业务需求；管理和监控测试环境的运行状态，确保测试操作不会对生产环境产生负面影响
## 第 14 期｜oracle数据库出现ORA-04031报错，节点实例down，业务登录数据库失败
- 专辑文件：`28.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** 业务侧反馈数据库无法访问，数据库告警日志大量ORA-04031报错。
- **处置过程：** 收到业务反馈，数据库无法访问；用管理员无法登录到数据库4节点，3节点登录出现卡顿，无法正常执行操作命令；检查alert日志，发现大量ORA-04031，无法分配40字节share memory；同时，发现大量等待事件“library cache lock”
- **运维建议：** 使用 Oracle 的自动工作负载仓库（AWR）报告和统计视图来分析内存使用情况和等待事件；利用 Oracle 的 V$LIBRARYCACHE 和 V$SGASTAT 视图来监控共享池的使用情况，；特别是在高负载时期
## 第 14 期｜oracle软件安装目录使用率异常增长
- 专辑文件：`28.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** oracle软件安装目录突然告警文件系统使用率大于85%，使用率86%，该目录使用率增长很快，该目录大小500G。
- **处置过程：** 检查发现oracle日志目录diag大约占用370G空间，其中diag目录下子目录cdump占用空间330G；排查oracle的alert_$ORACLE_SID.log日志文件发现大量报错；（ORA-07445:[pevm_icd_call_common()+225] [SIGSEGV] [ADDR:0x0] [PC:0x1289FAA1] [SI_KERNEL(general_protection)] []）
- **运维建议：** 增加对Oracle诊断目录大小的监控，设置合理的阈值，以便在异常增长时及时发出警告；对于频繁出现的错误和core dump生成，设置特定的监控和报警逻辑，以便快速响应；实施日志轮转和自动清理策略，定期清理旧的trace文件和core dump文件，保持文件系统的健康状态
## 第 14 期｜oracle大量异常等待分析
- 专辑文件：`28.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** 数据库突现大量的latch:ges resource hash list、enq:tx-index-contention、buffer busy waits等待事件影响业务。
- **处置过程：** 数据库突现大量的latch:ges resource hash list、enq:tx-index-contention、buffer busy waits等待事件影响业务，产生等待事件的语句都是insert同一个表。；与业务侧确认，近期应用程序有调整，入库数据新增较多，业务优先调整入库数据量，等待事件消失，问题暂时恢复。；事后分析，产生大量latch:ges resource hash list、enq:tx-index-contention、buffer busy waits等待事件的session 在执行sql id 83yyz41uvtkt1，插入表FLOW_HIS_202403。显示在index IDX1_FLOW202403 上有高的buffer busy wait的竞争。
- **运维建议：** 本次故障因为业务高并发insert，进而触发bug，产生异常等待营销业务。原厂升级数据库到RU 19.17或以上修复bug。；人工介入分析；大量等待事件出现，没有短时间恢复造成入库数据积压影响业务。警示数据库运维人员遇到大量等待事件没有恢复，应及时人工介入分析处理。
## 第 12 期｜ORACLE IPV6改造报错处置
- 专辑文件：`30.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** 使用IPv6的subnet[子网号],将新的public网口添加到集群时,报错。；xnpmdb1:/home/oracle(xnpmdb11)$oifcfg setif -global bond0/2409:8050:5a00::fdfb:1:4c00:public；PRIF-33: Failed to
- **处置过程：** 检查mdnsd服务是online的；crsctl status；t -init
- **运维建议：** 一定要加强测试，再牛逼的O产品也会有BUG。
## 第 12 期｜ORACLE ADG同步延迟处置
- 专辑文件：`30.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** ORACLE ADG搭建过程中，数据通过RMAN做duplicate后，追积累归档，始终追不上。；2023 10 07 08；ERROR [pool
- **处置过程：** 怀疑主库归档切换过于频繁；主库的归档切换频繁，每小时约切换130个REDO日志；所以决定优化主库日志，降低减少主备之间的交互次数；调整后再次同步仍无法追平。；怀疑主备网络传输问题
- **运维建议：** 主机侧交付主机环境后对CPU，内存，储存等做检查；搭建完RAC后，可以在ASM中做数据文件复制来测试ASM中磁盘的IO效率
## 第 11 期｜Oracle监听日志异常增长处置
- 专辑文件：`31.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552221&idx=1&sn=a351b2e25f679c85214503d39ac9a2d1&chksm=f86c24ebbfa8ea998a17a9b0c070ec51f076dd2b0228a8bd622174bf69cc5755d5c2287922ed#rd)
- **现象：** 根据最近告警信息，发现CRM中心库监听端口1522的监听日志异常增长明显。；查看监听日志内容；通过cat listener.log ｜ grep Incoming | uniq 发现该数据库遭遇xxx.xxx.xxx.xxx 主机的暴力连接,一个节点的连接次数一天达到200万次以上。
- **处置过程：** 配置正确的白名单ip后解决。
- **运维建议：** 定期进行数据库非白名单IP访问数据库整理，防止暴力连接,以及异常攻击；在数据库巡检时，增加此巡检项，防止漏加误加；业务在申请加入白名单时，需提供具体的监听端口，防止信息差
## 第 11 期｜oracle ADG 主备库切换演练，备库直接关机致主库关闭
- 专辑文件：`31.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552221&idx=1&sn=a351b2e25f679c85214503d39ac9a2d1&chksm=f86c24ebbfa8ea998a17a9b0c070ec51f076dd2b0228a8bd622174bf69cc5755d5c2287922ed#rd)
- **现象：** 检查主库的alert 日志，有如下报错；Primary has heard from neither observer nor target standby within；FastStartFailoverThreshold
- **处置过程：** 手动禁用自动切换之后，open 主库恢复业务；FAST_START FAILOVER force;；通过查找资料发现dgbroker 的自动切换就是有这个问题
- **运维建议：** 对于一些新功能，新特性，在不熟悉的情况下，最好不要配置。如果确实需要配置，也请提前做好测试或资料查询。
## 第 11 期｜同一sql，
- 专辑文件：`31.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552221&idx=1&sn=a351b2e25f679c85214503d39ac9a2d1&chksm=f86c24ebbfa8ea998a17a9b0c070ec51f076dd2b0228a8bd622174bf69cc5755d5c2287922ed#rd)
- **现象：** 业务反馈相同的SQL语句查询结果集为0，在ORACLE中执行5-6S完成，在达梦数据库中执行花费时间大概5-6分钟才完成。
- **处置过程：** 分析SQL语句执行计划，发现SQL语句通过索引扫描 然后回表操作，把满足条件的记录找出来做条件过滤数据0条，如果索引能提前过滤出来数据为0，就不用大量数据回表查找再过滤，性能就能提升；查询DM官网和相关手册，发现索引过滤和参数ENABLE_INDEX_FILTER 有关，该功能默认是关闭的需手动开启；参数修改后让业务重启应用SQL执行 在6S左右完成
- **运维建议：** 开启DM索引过滤功能，修改动态参数，并形成相关参数最佳实践；找靠谱的运维团队，利用团队规模优势形成的知识库，避免重复踩坑；'ENABLE_INDEX_FILTER'
## 第 9 期｜Oracle lib文件权限只读导致补丁升级失败
- 专辑文件：`33.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** lib文件权限只读导致补丁升级失败。；4.2 处置方案；在应用19.20.0.1230718PSU时出现报错，lib文件libclntsh.so.19.1为只读，无法writeable，检查发现该文件是上次打PSU(19.12.0.0.210720)时候，文件权限被设置成了444，34套库68个节点都是同样的情况，修改文件权限为755后，补丁应用成功。
- **运维建议：** 打补丁前，检查是否有444的lib文件存在。；打完补丁后，检查是否有只读权限的lib文件。
## 第 9 期｜Oracle IPV4+IPV6双栈改造实施后，单节点vip资源无法正常开启
- 专辑文件：`33.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** 故障数据库环境Oracle 19.7 rac，在配置ipv4+ipv6双栈网络后。总存在一个节点vip资源无法开启，导致问题节点监听无法拉起，实例无法对外提供服务。；实施的双栈方案通过，在网络配置中添加ipv6网络资源，修改vip（先remove再重新添加v4和modify v6ip），将新的网络添加到集群。扫描scan ip,激活v4和 IPv6，集群验证状态后，再次重启集群完成配置。；停集群时显示日志
- **运维建议：** 在实施此方案时一定要注意数据库版本信息，对于数据库版本低的不适用。
## 第 9 期｜Oracle由于安全扫描程序命中bug导致数据库hang死
- 专辑文件：`33.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** 某核心库因安全扫描程序查询大量系统视图命中oracle 11g BUG，导致核心生产库直接hang死，严重影响系统业务。
- **处置过程：** 某核心生产数据库出现大量；enq：SQ-contention.latch：sharedpool和rowcachelock；，随着数据库活动会话的异常积压，导致核心库实例Hang，应用程序无法正常连接。
- **运维建议：** 要求第三方扫描程序在ADG或每天BCV上执行扫描作业。
## 第 9 期｜OGG因NFS系统故障hang死
- 专辑文件：`33.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** 某OGG同步kafka因NFS文件系统通信故障，导致OGG进程hang死，数据同步延迟。；次日下午15点左右，接业务侧反馈kafka未收到同步数据，当及核查目标端OGG同步情况，发现所有涉及到该库的复制进程延迟近16小时。排查源端OGG进程状态正常，核查目标端日志有timeout信息但无error，准备重启复制经常，发现进程无法正常停止，force stop也无法停止，进一步分析发现操作系统上涉及到B库的OGG复制进程状态全为Ds状态，疑似IO问题导致进程夯死，最后只能通过重启主机释放进程。；重启主机后，该库的复制进程状态仍为running转态，延迟持续增长，且操作系统上没有该库的复制进程。由于紧急恢复业务需要，只能重配所有复制进程，重新配置后从当日凌晨跳过的trail文件开始应用，数据逐渐追平，业务恢复。
- **处置过程：** 某日晚23点时收到源端OGG的投递进程异常告警，核查错误日志出现；TCP：73；错误，重启无法解决，将投递进程做了etrollover操作后进程恢复正常。
- **运维建议：** 禁止OGG软件目录部署在NFS文件系统上；；做好OGG进程源端和目标端监控；；OGG进程回退trail文件需规范操作，多人评审。
## 第 8 期｜Oracle数据库迁移至 ANTDB
- 专辑文件：`34.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550409&idx=1&sn=be35df1e75f261fcf47240c515120415&chksm=f8f2fd7089ce4eb53f071ef3f7b8cc3609442d032d6d9f00a3f27702d15e7cfe739d80c05899#rd)
- **运维建议：** ora2pg的迁移中每次只执行一种对象的迁移。提前梳理对象之间的依赖关系，可以避免缺少依赖引起的导入失败。；没有数据校验工具，新增校验模块待验证。；自带迁移工具不完善，不成熟，导致迁移效率低、问题多；整个数据迁移工作繁琐工作量大；整个迁移方案不够完整，考虑不够周全。导致在数据迁移时返工一次。影响效率。原厂进一步完善相关工具。
## 第 8 期｜ORACLE DG故障处置
- 专辑文件：`34.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550409&idx=1&sn=be35df1e75f261fcf47240c515120415&chksm=f8f2fd7089ce4eb53f071ef3f7b8cc3609442d032d6d9f00a3f27702d15e7cfe739d80c05899#rd)
- **现象：** 某业务数据库有一套DG环境，主库做读写操作，备库做只读操作，业务的一个web功能连接的是备库，各地势人员在从页面进行查询时页面的响应速度特别慢，业务开发厂商拿执行的语句到主库执行发现速度很快，认为DG备库出现问题，需DBA解决。；本次故障主要是由于存储底层迁移导致的，新旧存储的磁盘扇区大小不一致造成的，这就要求存储工程师在划分LUN的时候要严格检查旧盘的配置，而对于DBA来说，其实不好发现这种问题，因为迁移的过程中和迁移后，虽然磁盘扇区变化了，但是数据库并没有发生异常，也没有任何日志记录了这种变化，只有发生集群重启时才报错。但是当发生问题后，必须要通过找到方向。；传统的磁盘扇区是512字节，每个扇区之间不是直接相连的，存在一定的空间，这些空间用于分隔扇区、同步、地址标志和ECC区域（用于数据修复和还原），随着硬盘技…
- **处置过程：** 拿到业务给的SQL在主库执行，执行时间为0.8s。；在DG备库检查正在执行的SQL，执行时间1000多秒，还未执行完，并且有100个左右的同类会话正在执行。；检查主库和备库上的执行计划，发现执行计划有一处变化，使用的索引不一样，在主库上，其中一个表的索引使用“市”进行过滤，索引过滤6万行，在备库上这个表虽然也走索引，但是使用的是“省”这个条件，索引过滤63万行。这条SQL是用户在页面上进行条件筛选后执行，省和市都是其中的筛选条件，还有一些其他条件，并不固定，但省、市以及另外两个条件是常用的，省、市是必须的。在备库的执行计划中显示的city这个条件发生了隐式转换。此条件涉及的表有几千万行数据。
## 第 8 期｜ORACLE数据库资源使用高处理
- 专辑文件：`34.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550409&idx=1&sn=be35df1e75f261fcf47240c515120415&chksm=f8f2fd7089ce4eb53f071ef3f7b8cc3609442d032d6d9f00a3f27702d15e7cfe739d80c05899#rd)
- **现象：** 某业务系统两节点11204版本RAC数据库活动会话数达到800以上，业务卡顿，数据库主机负载较高，CPU使用率90%以上，前端应用基本无法使用。很多查询语句执行时间较长，存在阻塞，kill掉这些SQL后，业务恢复，但很快活动会话数又会升高。
- **处置过程：** 数据库主机只运行oracle数据库，无其他程序。；分析执行的SQL，发现基本上等待全是gc相关的，连接串使用的SCAN。；检查两个节点之间的私网使用情况，心跳网卡存在丢包、错包的情况。
- **运维建议：** 透明大页没有被关闭。透明大页是动态分配内存，可能影响性能，oracle是关闭的，使用预先分配的大页。；进一步处理；信号量参数以前改过，检查了当前信号量使用情况后，发现默认值完全能满足，修改回默认值。
## 第 7 期｜ORACLE执行SQL报错temp表空间不足
- 专辑文件：`35.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** 业务反映执行SQL报错temp表空间不足。
- **处置过程：** 检查执行报错的SQL语句，是个insert into ... select ... from ...left join... where ...；执行计划显示存在全表扫描，检查当前temp使用率很低，手工执行语句中的select部分语句，可以执行成功，同时观察temp表空间使用率，实际该SQL占用temp 表空间46%，约40g；；既然单独可以执行成功，temp表空间剩余还有一半多，那就说明存在其他SQL语句在这个时候占用大量temp表空间，导致insert语句不能分配到足够多的temp表空间导致执行失败；
- **运维建议：** SQL上线审核很重要；加强对temp表空间使用监控，运用自动化运维手段对temp占用超过一定阀值的SQL进行截断查杀；；运用自动化手段对temp进行清理，防止部分高耗temp的语句引发其他业务影响；
## 第 7 期｜ORACLE SQL语句响应缓慢应
- 专辑文件：`35.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** ORACLE数据库；SQL语句响应缓慢。；通过sqlhc报告确认到近期均采用的是谓词条件过滤性较差的执行计划，此结果也验证了研发人员反馈该语句近期响应缓慢的;
- **处置过程：** 根据SQL_ID查出该SQL语句存在2个子游标，实际执行过程中使用到的复合索引对应的谓词条件过滤性较差，而另一个子游标对应的复合索引存在某列不在where条件中，因此优化器并未将其评估为最优执行计划;；创建过滤性良好的复合索引(；索引列均存在于where条件
- **运维建议：** 加强对慢查询的监控，及时发现异常SQL并对其进行调优;；增加对SQL语句执行计划突变的监控。
## 第 5 期｜万里开源数据库集群同步异常处置
- 专辑文件：`37.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247546419&idx=1&sn=166891468c4eeb9c37a0b109baf3be3e&chksm=f872028936151d568f95bde0da5bc82853ed177f355e7060d2cfa6d370493bd8004d94f21fd5#rd)
- **现象：** 主集群执行clone备份约50分钟后报错，通过观察备份节点目录使用率发现上涨至3.5T就一直没有再变化，通过回显的报错信息，提示备份节点客户端被中断，并给出更改interactive_timeout和wai_timeout参数的提示，我侧评估后通过将主集群计算、存储节点和备份节点的该参数从原60分钟进行调至24h，重新发起备份后任然报错，并且在数据库日志中未发现相关的报错信息。
- **处置过程：** 通过查询`mysql`.`greatdb_flush_schedules`的数据结合存储过程的逻辑可以判断出现整个存储过程是卡在：FLUSH SCHEDULE START_FULL_BACKUP @greatdb_flush_id WITHOUT BINLOG;但是该操作能够找到的公开资料太少，并且FLUSH SCHEDULE START_FULL_BACKUP是greatdb的内部操作，不是开源版本所具有的，需要结合内部代码分析。；协调业务侧进行一次数据清理，将目录使用率从4.1T下降至2.7T，考虑到数据量有较大变化，尝试进行一次全量数据备份，此次备份正常。
- **运维建议：** 本次遇到最复杂的问题为主集群通过克隆方式初始化备集群失败，主要体现在：报错回显提示无效、日志无明显指向、GreatDB商业版与GreatSQL开源版差异较大透明性不够无法进一步分析源码（FLUSH SCHEDULE START_FULL_BACKUP为Greatdb的内部操作，不是开源版本所具有的，相关部分公开资料太少）。；只能通过相关经验对可能存在的怀疑点进行多次试错排除直至解决问题，在国产数据库替换的过程中，共同为生态建设添砖加瓦，众人拾柴火焰高。；根据原厂，对数据库版本进行升级。
## 第 4 期｜ORACLE数据库hung处置
- 专辑文件：`38.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545681&idx=1&sn=8aeb394823bc8a6be300364dc7faa8a6&chksm=f833e66cee5e5c651ecb8df3eab3acb1292e41d478c62576c0782b1789dd0cb51b78935f5a87#rd)
- **现象：** oracle 19.7 pdb row cache lock导致数据库hung。
- **处置过程：** 通过v$session_wait查找cache id。；通过v$rowcache结合cache id查找row cache原因。；DC_OBJECTS,DC_OBJECT_GRANT。
- **运维建议：** 配置自动巡检项，问题出现时急时告警。；出现问题时结合版本信息与bug编号进行补丁查询。；数据库打补丁patch 33121934。
## 第 3 期｜SQLServer新增ogg表迁移传输失败
- 专辑文件：`39.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** SqlServer新增ogg表到oracle数据传输失败。
- **处置过程：** 多次检查并重建中间进程依旧无法传输数据到目标端。；检查目标端中间进程日志发现有两端字段不一致的警告，判断因数据原因导致无法使用中间进程导入数据到目标端。；最终注销目标端中间进程参数“BULKLOAD”（批量导入参数），重启源端中间进程，数据成功导入至目标端。
- **运维建议：** OGG问题需从多点切入：配置、数据、表结构都需要检查。；sqlserver表迁移时不使用BULKLOAD参数。
## 第 3 期｜ORACLE数据库主机hang死
- 专辑文件：`39.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** 某库1节点JDBC连接失败，登录数据库主机检查数据库状态正常，但是操作系统输入命令响应时间较长，用TOP命令检查发现主机上存在10W+的僵尸进程，并且还在持续增长。
- **处置过程：** 接到告警某库1节点JDBC连接失败，登录数据库主机检查数据库状态正常，但是操作系统输入命令响应时间较长，用TOP命令检查发现主机上存在10W+的僵尸进程，并且还在持续增长，该部分僵尸进程都是某监控厂商的监控agent程序发起的。
- **运维建议：** 在尝试杀掉僵尸进程无效后，按主机工程师对数据库1节点主机进行重启，16:10分数据库主机重启后僵尸进程全部释放，主机和数据库恢复正常。；监控厂商工程师核查反馈可能是在操作系统出现问题时影响到监控进程，导致不停的产生僵尸进程，监控进程无论执行结果成功或失败每5分钟会执行一次，针对可能会带来产生大量僵尸进程的情况，已经发布oc-agent来替换subagent。；再监控本身也是应用程序，也有出现BUG的可能，要做好自身监控以及沙盒，出现问题异常要有自杀机制，避免因为监控影响业务，相关主机部署agent进程之前，需对agent进程进行压力测试，确保agent不会占用过多的主机资源从而影响到数据库软件的运行。
## 第 3 期｜ORACLE数据库IO性能处置
- 专辑文件：`39.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** 某场地应用侧反馈计费采集任务处理失败，怀疑可能是数据库出现异常。
- **处置过程：** 应用侧反馈计费采集任务处理失败，怀疑可能是数据库出现异常，DBA登录数据库检查：发现有大量gc类型的等待事件,最终通过阻塞链定位到都在等待LGWR写日志，；最终的阻塞源是LGWR进程。；随后查看log file parallel write 等待事件的平均响应时长发现在23:00由1ms变成了19ms左右，说明存储IO性能出现问题,进一步排查是rman增量备份任务在23:00挂起，
- **运维建议：** RMAN备份时候读取数据文件会消耗占用大量的IO资源，数据库在首次配置RMAN备份任务前，需提前对数据库的存储IO性能进行评估，明确RMAN备份时开启多少通道及是否需要做限速。；针对log file sync、db file parallel read响应时间进行监控。
## 第 3 期｜ORACLE UDEV绑定的别名消失
- 专辑文件：`39.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** udev绑定的别名消失，导致磁盘被踢后，DG要进行rebalance。；核查主机日志、存储、交换机都未见报错，通过部署脚本发现，掉盘时间点，只是udev绑定的别名磁盘在OS上消失了，multipath聚合绑定的dm-*和/dev.mapper/下的盘正常。目前还未找到具体原因，从看multipath聚合磁盘没有问题，udev生成的别名磁盘出现问题，；怀疑可能udev存在兼容性bug
- **处置过程：** DG是normal的，磁盘被踢出后，没用空间再进行rebalance，通过resize 数据文件腾挪空间保证rebalance完成，再将被踢出的磁盘加入到DG中，同时申请扩容存储，在问题未解决前保证即使磁盘被踢后也能正常rebalance完。
- **运维建议：** 之前很多系统都是通过udev绑定别名磁盘后给数据库使用，一直沿用的此模式。后续可根据环境调整，如对于multipath多路径软件通过wwid绑定的磁盘，可直接使用，不必再用udev生成别名磁盘；增加asm磁盘数量监控。
## 第 2 期｜ORACLE数据库执行计划变更致CPU资源耗尽
- 专辑文件：`40.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247543426&idx=1&sn=287cc6eaa6e98153ec19c45ea5989f33&chksm=f8170fa7cd7203246038852d2d0dab5a1d82b83c11b76b2ba4dd0275f67a6a1d255f198ce891#rd)
- **现象：** 业务运行缓慢，同时数据库主机资源紧张，数据库存在大量等待CPU的等待事件。
- **处置过程：** 查找引发CPU上升的原因，排查等待事件。；查找高耗CPU的SQL，分析执行计划。；对比历史执行计划和当前执行计划，由于自适应游标共享（Adaptive Cursor Sharing）特性引发执行计划发生变动，进而CPU资源上涨。
- **运维建议：** 部署SQL执行计划变化告警（；如果担心告警过多，可以增加过滤条件）；只对核心SQL进行监控，或者只对资源消耗排在TOP的SQL进行监控。
## 第 2 期｜ORACLE数据库突然宕机，并无法启动
- 专辑文件：`40.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247543426&idx=1&sn=287cc6eaa6e98153ec19c45ea5989f33&chksm=f8170fa7cd7203246038852d2d0dab5a1d82b83c11b76b2ba4dd0275f67a6a1d255f198ce891#rd)
- **现象：** 某场地oracle 12c 数据库集群1节点突然宕机，无法启动。
- **处置过程：** 尝试启动数据库报文件不存在。；检查报错文件状态，发现文件权限不对，再次检查上级目录权限，发现Oracle软件安装目录权限均错误。；通过相关脚本获取2节点目录权限，重新授予1节点目录权限。
- **运维建议：** 权限责任到人，严格限制root权限的使用。；回收业务人员过大的操作权限。；对数据库维护人员警示作用，生产操作再三确认，先思后行。
## 第 2 期｜ORACLE 19C ASM扩容无法添加磁盘
- 专辑文件：`40.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247543426&idx=1&sn=287cc6eaa6e98153ec19c45ea5989f33&chksm=f8170fa7cd7203246038852d2d0dab5a1d82b83c11b76b2ba4dd0275f67a6a1d255f198ce891#rd)
- **现象：** 在添加asm磁盘组添加磁盘提示无法添加，并提示；ORA-15137；The ASM cluster is in rolling报错。
- **处置过程：** 上线通过命令asmcmd showclusterstate查看数据库补丁状态信息，返回值为In Rolling Patch。；通过命令kfod op=patches查看补丁集信息状态。；在实际情况中kfod op=patches碰到过两种情况
- **运维建议：** 在宝贵的补丁停机时间中，我们在补丁更新后要主动检查补丁状态信息，不能在补丁更新中无报错就直接忽略，从而避免不必要的后续故障问题。
## 第 1 期｜大页参数设置不规范导致故障
- 专辑文件：`41.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247541586&idx=1&sn=6679d801fbeb3b8917f7298aeb573457&chksm=f8a211250a8a15312f5b12a9a56492512a3162a433ea92855b359aae4f82acfe75f1121e4b3b#rd)
- **现象：** 故障节点主机日志存在“Cannot allocate memory” 无法分配内存报错；数据库alert日志出现“；ORA-15025；could not
- **排查与原因：** HugePages 是 Linux 操作系统的一个内核特性，让操作系统可以支持现代硬件架构的大页面容量功能。；对于 Oracle 数据库，通过启用 HugePages 并使用大页面，可以用一个页表条目代表一个大页面，而不是使用许多条目代表较小的页面，从而可以管理更多内存，减少操作系统对页面状态的维护并提高 TLB 缓存命中率。
- **处置过程：** 检查主机参数配置，主机未配置hugepage参数，数据库未使用hugepage进行内存管理。；调整主机参数，禁用主机numa功能，设置主机内存hugepage参数，并重启所有节点主机和实例，经一段时间的观察，主机内存使用率正常。
- **运维建议：** 完善系统上线流程，将不同资产的上线纳入线上管理，并基于平台完善各类资产上线基线检查场景（像上线安全基线一样，形成各类组件的标准化集成基线检查）。如果暂无平台管理，也需要手动检查大页。
## 第 1 期｜Oracle备份进程未完成，导致白天影响业务
- 专辑文件：`41.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247541586&idx=1&sn=6679d801fbeb3b8917f7298aeb573457&chksm=f8a211250a8a15312f5b12a9a56492512a3162a433ea92855b359aae4f82acfe75f1121e4b3b#rd)
- **现象：** 业务运行缓慢，同时收到告警数据库主机内存使用率高。
- **排查与原因：** 因为RMAN本身会消耗大量的IO资源，一般全备RMAN放在非业务高峰期间进行。
- **处置过程：** 登录数据库检查发现在白天有rman进程存在，查询数据库rman备份记录显示昨晚rman备份未完成，检查rman日志发现rman进程僵死，杀掉rman进程后恢复正常。
- **运维建议：** 增加每日rman备份是否成功的告警，对前一天晚上没有完成的rman备份及时发现并考虑终止，防止影响白天业务。
## 第 1 期｜Oracle表空间有剩余但依旧无法插入数据处置
- 专辑文件：`41.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247541586&idx=1&sn=6679d801fbeb3b8917f7298aeb573457&chksm=f8a211250a8a15312f5b12a9a56492512a3162a433ea92855b359aae4f82acfe75f1121e4b3b#rd)
- **现象：** 数据库在表空间存在大量空闲空间的情况下，INSERT语句报无法扩展表空间错误；ORA-1683
- **排查与原因：** 通过分析数据库alert日志，从13:01开始出现ORA-1683表空间无法扩展的报错，索引分区XXXX.IDX_XXXX_202208_PKpartitionPART_210需要在表空间TBS_XXXX_IDX申请1024个连续块的extent，blocksize为8192，即需要申请一个8M的extent（extent由数据文件中一定数据量的连续块构成）；；表空间在8月9日14:51之后添加了3个数据库文件来缓解ORA-1683压力，分析表空间为系统管理区，即区的大小不是人为决定，是系统自动管理，根据表的大小自动设置，在系统管理区的模式下，extent的大小随表的增大而增大，如下面的测试，表的初始extent大小为65535bytes，即64K，随着表的变大，当表的大小超过了1M，即到了第16个extent时…
- **处置过程：** 快速添加数据库表空间文件，解决数据无法插入问题，快速恢复业务。
- **运维建议：** 通过数据治理，增加对数据库表空间碎片监控，定期对碎片率较高的表空间进行碎片整理，具体利用停机窗口对碎片率较大的表进行MOVE压缩等操作。