为啥要查询历史数据，一般保留趋势数据就可以，查询的话查询趋势数据就可以，历史数据可以定期直接清理，感觉保留的意义不大，另外建议修改监控项中历史数据的保留期限，不要太久，数据库软件优化的能力有限，有条件的话建议升级硬件性能，最好数据库可以存储在固态硬盘上...

清理无用监控项时可能会导致对应监控项的大量历史数据被保留，housekeeping的作用就是清理历史数据，如果一次删除大量无用的监控项，并且该监控项配置的保留历史比较久的话，这样数据量就会显著增大，导致出现慢sql等，建议分多次删除...

死锁其实不是数据库问题，而是业务一致性问题。这个问题还是需要从业务场景去解决。例如是否允许出现脏读幻读等。如果可以的话就降低隔离级别。另一个方法是把一个UOW拆成多个UOW提交，减少死锁现象。这个同样是业务问题。...

不难的，自己干

这个太大了……看操作系统的内存，CPU，硬盘使用率是否正常；看数据库缓冲池命中率，内存使用情况，具体看业务是否有反馈比较慢的功能，查对应的SQL等等

目前，我知道的工具只有 DbVisualizer 可以查看类Oracle、Mysql那种表格形式的执行计划，它也可以支持“树状图”执行计划。其实，我觉得还是树形图执行计划，清晰直观。用时间长了，你就知道它的好处了。...

1. 先做健康检查，找出系统瓶颈点。2. 如果瓶颈是整体硬件资源不够，比如cpu，内存，可以考虑扩容。或者换迁移到新服务器，用pureScale都集群技术。3. 如果是存储IO不够，可以考虑了数据库压缩。4. 另外也可以分析sql等，优化应用。...

鉴于你的情况，可以考虑开启AUTO_RUNSTATS,AUTO_REORG 避免频繁的手动操作,表中数据大量变更后，需要reorg，整理碎片叶后性能才会提升，只做runstat不行。

索引缓冲池命中率低是不是只是从缓冲池这个维度去查看的结果？如果是这样的话不太准确，因为我们最终想看的是哪个表的哪个索引命中率低，这样才知道是不是有问题。这个可以从表空间的缓冲池命中率和相关sql的缓冲池命中率去确定。如果最终确定了是表的索引命中率低，有两个方向...

之前Oracle官方有关于extended rac 的距离和延时要求，但是后来oracle 官方并不推崇这种做法。也就没有官方的数据了。但是从历史的文档和目前很多厂家宣称的指标是百公里内，5毫秒一个RTT。但是这个东西不是一个绝对值，不适合所有的业务。主要还是看自己的业务类型。但是个人...