-
编辑 删除
lob字段的direct path read等待导致的性能问题分析过程
在一次性能调优中，发现用户大量的direct path read等待，正常理解这应该是一个大表的全表扫，我们捕获了该SQL发现两层嵌套走索引，索引需要回表。 所以显然这里不是全表扫描，我们检查了表结构，以及select后的查询字段发现都有lob字段，其次通过ASH的physical read统计，都是lob字段，所以我们怀疑是大量的 Lob 读导致了direct path read
-
编辑 删除
由于外键约束问题导致ORA-00060错误，报Single resource deadlock [T
这个问题持续很久，当时看到global_enqueue_deadlock，没有多看，直接认为是全局死锁，需要业务自己协调，从trace文件中拿来一个delete的SQL 但是后来偶然机会让辅助监控的工程师负责再看看该问题，确发现是另一回事。
-
编辑 删除
测试“奇怪的select” 造成的行锁等待测试----诡异的行为的解答离不开对原理的理解和坚持
这是一个生产库，出现大量的行锁等待，而一直无法捕获造成阻塞的SQL，一旦捕获竟然会是会话的select语句，这显然与我们的理解数据库一致性读原理，写不会阻塞读有冲突，下面我们经过测试，还原问题的真相，虽然生产问题更复杂，但是核心问题就在这个地方，我们通过测试来一步步模拟这个处理过程。
-
编辑 删除
update 主键造成行锁等待测试
行锁是Oracle实现事务的一种机制，在数据库操作中无法避免，但是长时间的等待就需要分析，问题原因，是阻塞会话执行时间长，还是外键约束问题或者是其他问题，这个需要具体问题具体分析，但是这个机制原理是不变的，同时只能有一个用户做DML操作，这里我们测试update主键的SQL如何被阻塞，这样的操作对于高并发操作往往带来严重的性能问题。下面是整个测试过程。
-
编辑 删除
从运维角度测试全局死锁以及带来的问题
s死锁是两个进程各自需要锁资源，而相互又不释放资源导致，Oracle会自动探测并释放这些资源，但是会生成大量得dump文件，如果从业务逻辑无法修改，就需要定时删除这些文件，防止撑爆Oracle软件目录操作实例挂掉!
-
编辑 删除
通过ACFS创建共享的文件系统
在现实生产系统中，往往需要创建一个共享的文件系统，使得集群中多个节点可以共享访问某个文件，比如数据双向同步软件的中间数据，此时可以采用比如veritas之类第三方存储产品，但是如果仅仅依靠Oracle就可以更好的节约成本，也方便管理，这里我们测试使用ACFS文件系统实现共享文件系统（备注并不是所有操作系统平台都支持ACFS）
-
编辑 删除
expdp操作审计测试
出于管理的需要，特别是在管理比较粗放，部门交叉复杂的系统，往往数据导出操作比较随意，开发或者相关业务管理人员都有权限，这样对于数据库的安全管理十分不利 为了监控expdp行为，我们可以通过两种方式来监控和审计该行为，以确认是否是合法用户的合法操作。
-
编辑 删除
bug导致的root.sh脚本失败分析
这个是个新的应用系统，由于时间紧，不知道为啥系统组直接给安装了Linux7.9这样的高版本，一般对于这样的安装很可能出现未知的问题，比如高版本上的各种bug.这次我们就遇到了，下面是遇到各种问题，简单做个记录吧，以后用得着可以来查查。
-
编辑 删除
12C-Dg 切换新花样
虽然做12C的数据库维护有几年了，DG也搭建，故障处理也做不少，12C的切换有了新东西还是第一次测试下这个过程。说明：测试环境是与生产库完全一致。
-
编辑 删除
全局死锁导致的trace目录超限处理过程
最近自动巡检平台频繁报目录大小超限告警，其/Oracle目录使用率搞达90%，处境危险啊，需要及时处理并清理过多或过大的文件，以免影响数据库正常运行。
-
编辑 删除
Oracle12C TDE wallet加密方法
在Oracle 12C中 TDE wallet加密使用了完全不同的管理wallet和master keys的接口，本文测试在RAC环境下如何设置TED加密以及数据库重启后如何自动开启Wallet
-
编辑 删除
DG环境备库数据不同步-同样的问题又发生了（处理过程与之前略有差异，值得记录下来）
这个问题算是重复出现了，由于主备存储空间配置不同，导致主库的数据文件在备库重放失败，无法创建改文件，从而导致MRP进程终止，这里的处理略有不同的是，需要先在主库修改该文件的存储目录（原因是一时无法实现扩容，先在主库将该文件迁移到空闲空间），再在备库重新创建失败的文件到与主库对应的空间中。
-
编辑 删除
Oracle12C集群打补丁失败转而使用手工打补丁报CRS-6706处理过程
集群有三个节点，其他两个节点都正常，使用opatchauto 打补丁成功，但是第三个节点报错，后尝试使用手工打补丁成功，但是又遇到CRS-6706，这里是整个问题的处理过程。
-
编辑 删除
相关自动任务ORA-12012 2000106512报错处理
之前巡检中发现有一套集群总是报错12012错误，之前对于job类错误我们都不再处理所以一直没有关注，但是最近发现改错误再三个节点频繁发生，监控日志刷了好几屏，感觉还是要分析下具体问题。这里是简单的分析流程，做个记录。
-
编辑 删除
9i迁移到12C实施流程
这是一个很古老的数据库，还是9i的版本，业务需求迁移新中心的12C数据库上，当时给了2个小时的迁移时间，中间会停业务 同时业务方提出需要分担读的压力，这里记录了这次实施流程。
-
编辑 删除
index scan join的使用场景测试
hash join的原理就是根据某个比配字段做hash计算，在做hash匹配，在table操作中我们已经十分熟悉这个操作，而index scan join则是相对陌生，我们通过测试分析改数据访问方式的原理以及使用场景。
-
编辑 删除
监控业务SQL消耗TEMP空间的几种常见方法-来自一线监控需求
最近经常遇到temp空间不足的问题，因为是重要系统，所以也监控了改表空间的使用率。但是最近零点之后告警频繁，就需要分析哪些用户的哪些SQL造成了temp空间被耗尽，对于这个问题的思路本文提供了三个方式。并经过测试，读者可以根据需要自行选择和调整相关参数设置。
-
编辑 删除
由于密码文件不一致导致得主备数据不一致
这个库的安装是我实施的，大家可以参考之前的文章，之前也发生过数据不同步的情况，上次是备库空间不够导致的MRP进程关闭，而这次处理开始没有看日志，直接看看是不是已知的问题，比如网络，日志缺失，MRP进程异常等，但是都发现正常，后续看了下日志，让人非常意外，竟然是密码不一致。
-
编辑 删除
数据库迁移后缺失直方图导致index full scan导致的性能问题1
数据从11.2.0.3迁移到12.2.0.1,使用数据泵迁移，迁移后发现数据库DBTime很高，并且部分SQL执行时间过长，这个是一个核心系统需要尽快定位问题，我们直接从ASH找出最大的等待SQL以及等待事件。发现都是涉及一条SQL，这条SQL并发，一个小时执行了近700次。而在之前库则没有这个问题。
-
编辑 删除
enq: TC - contention等待事件的分析过程
用户反映系统等待严重，在TOPsession里，有个两个等待一个是业务用户得CPU + Wait for CPU，一个是sys用户得db file async I/O submit 而这个等待对应的program 是DBWR进程，四个DBWR进程都发生改等待事件。下面是详细分析过程
