Oracle 荒岛DBA

嗨，伙计们，

我刚刚重新阅读了oracle insights (橡树桌的故事)，并希望在书中有所了解。
我相信它是在关于强迫性调整障碍 (CTD) 的部分，作者说DBA被带到一个荒岛，删除了所有GUI工具，有一个telnet会话，并且在最多3个查询中必须诊断数据库性能问题来保持他们的工作。提出的修辞问题是 “您是DBA幸存者的材料吗？”

阅读了AWR，ASH，了解了等待界面，了解了如何进行解释计划，了解了Tom Kyte的runstats等，我发现自己对处理性能问题的方法不知所措。从实例性能问题到单个SQL语句的最佳方法是什么？Anjo Kolk的YAPP如何适应经过深思熟虑的方法？

我经常接触到以前从未见过的数据库，并被告知存在性能问题，那么我应该采用什么方法？可估算的Kolk先生是否可能是小型袖珍版本，可立即咨询？

我怀疑我不是荒岛DBA幸存者-你们呢？

让我在这上面画一个不同的旋转。

所有用于调优的方法、技术、理念等都只是DBA工具箱中的工具。对于某些情况，每个工具可能是该工作的 “最佳” 工具，其他工具也可能有用。

如果我遇到系统问题，我可能会从AWR/ASH开始，以全面了解谁在做什么。实际上，甚至在此之前，我可能只是在v $ session上进行查询，以获取数据库的鸟瞰 (多少个连接，多少个活动)。如果我发现某人看起来像罪魁祸首/问题/原因等，我可能会10046跟踪该会话。但是，如果该会话在CPU上旋转-那么10046不会对我有太大帮助，因为没有等待... 所以我可能会使用strace/truss/etc或oradebug转储。

当然是 “我”-我是命令行恐龙。如果我问我的朋友Jeff Smith (SQL Dev的产品经理)，我想他的方法可能是通过SQL Dev中的GUI监视屏幕附加监视。

我们俩都不是 “错的”-我们只是在使用我们最擅长使用的工具来解决当前的问题。

因此，不必担心了解 “最佳” 工具，而应专注于对广泛的工具拥有良好的知识，并在各种情况下轻松应用它们。

其他人欢迎加入他们的想法 ..