ITPub博客

8月4号晚8：12业务值班人员反应tjdm313 dbtime告警，百分比达到472%，持续时间1.5分钟。

业务反应集群第一节点，每天晚上批量插入数据最近变得极慢，影响了其他批量作业。需要协助解决

近我们遇到一个系统监控的协助申请，通过一个操作系统用户itsm执行脚本来监控数据库相关状态，发现无法查询v$视图，经分析是该用户缺乏对应权限，下面是分析过程。

业务反应某应用的节点，每天晚上批量插入数据近变得极慢，影响了其他批量作业。需要协助解决，我们通过分析确定了IO问题，并且该问题还有进一步优化空间。

这是一个12c的库，早上6点值班同事通过告警平台转发了该告警，看到4031第一眼想到共享池内存碎片，10g之前的库4031比较普遍，但是到了12C这个错误极少见到了，所以觉得奇怪，下面是通过gv$sgastat和lmd跟踪文件分析的结果。做个记录把。

习惯于在linux6下配置rule文件用udev绑定磁盘，但是这种配置在Linux7.下失效了，原文：In OL7, the /dev is a tmpfs and generated dynamically when the system comes up and hence the asm directory is not present under /dev after a reboot.

业务需求我们部门DBA紧急安装了4套集群，但是发现数据一直报错，虽然是warning还是想了解具体原因，担心后续上线影响数据库运行，分析一段时间后初步认为是系统问题，但是操作系统工程师说正常，后续问题反馈过来，希望给分析下，下面是分析过程，结论是与操作系统无关，应该是DBA安装有问题。

ORA-01625这个错误是提示temp空间不够了，为了业务正常运行，我们往往会临时扩下temp空间解决，但是有时不能根本解决问题或者根本解决不了问题。

直方图直观的统计表中相关字段的数据分布，从而给优化器提供准确的数据分布信息，Oracle依据这些信息可以计算正确的COST值，选择最优的执行计划。

最近有个业务需要将数据库从外网迁移到内网，需要做迁移方案，之前了解由于内外网关系以及带宽不足，我考虑用RAMN物理热备后追归档的方式实现迁移，尽量减小停机时间，下面是测试，从而发现可能潜在的问题，依次记录与大家共享。

在数据库恢复过程中，比如我们用了第三方的备份工具，在实施恢复操作时会导出需要的某个表空间这样可以大大减少恢复时间，是十分值得推荐的做法，这个过程中由于修改控制文件中数据文件的相关信息，需要执行alter datafile XX offline drop的操作。如果在生产库误操作这个指令，我们测试看看影响范围以及如何更快恢复。

最近打补丁遇到一个问题，后续发现patchauto无法关闭集群，后续只能暂时关闭该节点集群，保持其他两个打好RU的节点负责对外服务。

由于操作系统的Kernel bug，要求对没有上线的系统升级，选择了一套集群做测试，发现操作系统升级后RAC无法启动，下面记录下最后的是分析结果.

OJVM组件是OracleRDBMS自带的一个组件，也就是Oracle的JVM，支持对于Java代码的执行，一般用户使用很少，由于很多公司需要漏扫，会发现OJVM有漏洞，所以需要删除（或者打patch），这里记录下如何彻底删除OJVM组件

在版本操作系统安装12.2遇到很多bug ,建议在RedHat Linux7.7以上还是用19C吧，不过安装处理过程还是可以学习到很多东西，下面记录了遇到的bug或者遇到的问题，希望对大家学习有用。

如果数据库夯住,业务无法使用，或者更严重的sqlplus无法登录，此时我们就需要在不同环境下使用hanganalze工具做trc找出阻塞关系，最终定位问题。

本文通过10053跟踪，给出Oracle精确计算Cost成本的计算方法以及注意事项。后续会持续谓词带索引的查询语句如何计算Cost成本。

用户反映整个业务操作缓慢，影响业务运行，需要紧急排查，下面是分析步骤

如果一条SQL正在执行，发生性能问题，我们可以通过从内存抓取的方式获得这条SQL的所有执行情况，比如执行计划，执行次数，逻辑读，物理读，CPU使用等，从而采取合理措施优化SQL。而往往我们需要做事后分析，因为SQL性能问题时我们无法做现场分析，此时就需要从哪个Oracle历史记录中获取，这里我们通过记录在AWR中的SQL执行性能历史，来进一步分析SQL问题所在。

最近经常遇到用户TX行锁等待， 发现行锁等待的根源的会话，但是这个SQL执行结束了，后续会话同时执行了查询等其他操作，无法从会话层面获得这个事务的 SQL。下面我们通过测试，使用ｌｏｇｍｉｎｅｒ获得事务未结束的SQL。