ITPub博客

在生产库中，我们经常发现索引字段不多，但是竟然比表段还要大很多，索引段白白占据了大量的数据空间，其实对于索引，没有update的概念，更新索引列时，旧的索引标记为delete,重新插入索引，因此在update和insert大量记录后索引段会碎片化，进而需要更多的数据块用于索引段。本文通过测试演示索引段空间的变化。

数据库告警日志报错TNS-00515: Connect failed because target host or object does not exist以及ORA-00600: [qcsprfro_tree:jrs present], [0x7FFFF213B1A0]，提示MV user1.mv_tab_LOCATION was not refreshed successfully.

因为遇到一个故障，网络的haip冲突，网卡上意外绑定了Oracle的haip网段的地址，虽然最后判断是IBM的IMM机制导致设备分配了169.254/16网段地址，但是由于缺乏ifconfig监控信息还是缺少足够的证据。这里重新部署了OSWatcher工具，给了相应连接和原厂高老师写的博客，分析得很不错，案例说明充分，也考虑到用户的担心，做个记录下把。

问题看起来像是bug，后分析应该是lmon异常（网络异常）关闭了实例，最后一步步检查分析发现IBM的IMM 默认使用 IANA (Internet Assigned Numbers Authority) 网络地址范围造成169.254/16网段的地址的地址冲突，从而造成集群的节点驱逐。

用户有一个需求，之前删除了表中大量数据，只保留最近20天的数据，因为表中有lob段，所以这些lob段占用的空间一直没有释放 二目前释放这些空间需要move表的lob段，这个时间很慢，业务无法接受，后续我们通过讨论采用另一种方案解决。

这个系统安装了很久，中间七七八八出过好几个问题，因为不是自己负责，只是再群里看了下讨论，感觉第三方的工程师以及技术支持技术还是到位的， 后来在安装2021年4月份的RU后，一个节点集群出现驱逐，第三方通过重启网卡临时解决了，但是还是担心后续系统是不是稳定，需要确定问题出在哪里。

理论上Expdp导出一张表应该很快，如果发现导出操作卡顿，我们需要确定等待事件，以及等待事件操作的对象，从而分析应对策略。

这是一个典型的案例，library cache pin,cursor: pin S wait on X造成死锁等待，进而造成队列锁，拉高Dbtime，而罪魁祸首还是用户的造作和这个对象的高并发访问，这个案例我们一起学习library cache pin,cursor: pin S wait on X，library cache pin等待事件以及相关原理，同事从业务层面分析DDL操作的潜在危险！

最近一个同事问为啥这个SQL怎么优化都是走全表扫描，让我帮着看看，从微信发来得txt执行计划看，第一眼我就预料是这个问题，隐式类型转换，函数屏蔽了索引，经过分析验证，最终确认是这个问题，下面我把问题仔细分析下，也再重温下hash-join和nested-loop得原理。

600错误 往往是引擎内部的问题，但是这个问题也往往是由于用户的SQL引起的，无论是bug还是其他原因，我们最好了解这个错误的含义，这里分析ORA-00600: \[KGL-heap-size-exceeded]告警分析处理过程。

套这是一套三节点集群，使用ASM共享存储，发现２，３结点数据库实例无法启动，1节点实例又频繁重启。记录下处理和分析过程。

6600错误往往和引擎层面的问题，涉及内部进程，内部对象等，这里是一个内存同义词失效的处理过程

TimesTen除了作为单独的数据库之外，其缓存功能是基本功能之一，也是其最重要功能之一，我们测试从Oracle数据库到timesten的同步过程，在timesten端实现数据缓存减少Oracle数据库的读压力。

由于运维需求，我们需要接手TimesTen的维护工作，出于习惯，我们测试了TimesTen的安装、缓存功能以及复制功能。 采用TimesTen的版本为18.1.4.11.0,Oracle数据库版本为19.3, 操作系统为OL7.8

在我们的业务系统中，存在部分数据库由于dbtime过高导致的告警，经分析等待事件皆关于dblink.SQL*Net more data from dblink ,SQL*Net message from dblink 分析dblink导致的性能问题一般从几个方面考虑1 remote操作慢，分析远端执行计划 2 remote数据源与本地数据集Jion顺序异常，也就是执行计划不合理 3 网络不稳定

某个系统dbtime过高，经分析发现大量的ITL等待，确认这条SQL为insert操作，并发用户大概100多个，最终通过修改ITL相关参数解决， 下面时处理过程

最近有一个业务需求，修改Oracle 默认的网络端口号，将1521修改为1881，修改熟知的Oracle监听端口也是安全考虑，这个操作不需要停应用，但是对于网络连接还是会有点影响，应用也需要修改连接的数据库服务端口。下面是在基于RAC架构的数据库层面如何修改监听端口的测试过程。

该系统刚刚上线，需要监控运行情况，发现每天晚上DBTime都会超过阀值，经过分析发现大量的cursor: pin s wait on x，和dblink等待，发生cursor: pin s wait on x等待的SQL无法捕获，我们从分析应该是执行的SQL有DBlink，而问题时段告警日志大量的Dblink故障告警，我们模拟该问题，从而验证我们的分析。

由于ＣＰＵ问题，更换主板，系统拉起后，发现集群不正常，关闭集群重启，发现数据库实例无法正常启动，同时实例不断重启，下面是分析过程。

测试环境突然一个节点的数据库无法启动，报错很清楚，找不到控制文件，而控制文件在ASM上，第一个节点正常，下面是处理流程。