【IT168技术分析评论】

　　作为数据库管理员 ：你是否会根据表象采取行动? 你是否首先尝试? 为什么要按照你那样做?

　　我在我的DBA博客中写Action系列这一专栏，已经有很长一段时间了。一开始我并没有打算要写该系列，但我每天面对我们都会面对的事情时，都会问我自己为什么要按照那种方式做;并且有时，我也想知道读者为什么要按照他们的方式做。我真的很享受读者的提问;大家偶尔需要帮助，包括我。 然而，我有时想知道我们是否足够相信自己能独自找到解决办法。

　　以我所见，解决问题的能力，应该是每个数据库管理员都应该具备的能力。数据库管理员不一定需要会解决一切，但是他们应该有能力确定问题，研究解答和最终采取行动。 我经常与许多接受的方法混淆。 反而，他们将：

　　1. 假设某事不运作

　　2.在网络上做一次懒惰解答搜索并且询问朋友和家人

　　3. 实施解决方案

　　我很这种解决办法有明显的漏洞让我感到震惊：

　　1. 我们怎么确认某事是错误或不工作

　　2.考虑下来源。并非一切在网上都是正确的，很多从来没有经过测试，很多是向你推销卖，很多并不适合解你的问题，以及不胜枚举

　　3.一个简单的搜索结果，无任何验证测试或质量评价，并将毫无疑问的实施，为大灾难开辟了完整的

　　所以，当许多人在我面前这样做，我会试图解释解决问题的周期，与一些管理员。作为一个例子，我最近将回答一个读者关于我写的文章的问题。

　　Our Example：为了让使用案例实行，我最近写有关如何配置Oracle，让其在Linux系统上自动启动和停止。我提供的分步说明连同启动/停止脚本被成为dbora ，一个普通的做法。在我的文章中，我也叫dbstart脚本，每个管理员至少应该听说过。那么，让事情在这里，读者质疑我没有在dbora脚本设置一个启动Oracle监听器的设置。由于没有以前的读者，我可以补充。

　　1.知道问题的内外。这是谚语“三思而行” 。弄清你理解的问题的原因。所以常常，我看到工程师们开始解决问题仅仅是因为有人说存在一个问题。没有任何的问题验证程序。我们往往是由事件驱动的，就是说当有些事件发生了，然后我们才有反应，最后才发现这是第一次发生。

　　In our Example: 我的读者明显质疑我是否应该在dbora脚本设置一个启动Oracle监听器的设置。他们甚至指出外部网站，我没有提到的，以证明自己的观点，我应该包括这个LSNRCTL设置 。现在真正的问题是读者如何好好的实际地研究和探讨问题之察觉?我从来没有去阅读他们指的文章，等一会儿，让我现在看看。好吧，我回来了。你再也猜测这一次，也许你会，但上方的脚本，本文提到一个Oracle 9.2.0数据库，并在上方的文章谈到Oracle 10.2 。现在，我没有看到整个文章，并根据他们所要做的，这10.2 .VS.9.2可能是完全符合。但是，我知道我的文章是一个Oracle 11.1.0.6这样的事情可能会有所不同。这本身就应该有至少引发读者的关注。也许没有，我只是指出问题的版本。此外，还有其他一些问题，应该让你质疑你在网络上找到的。基本上，没有Web内容符合我的具体情况?相信我，事情变化太快，没有100 %符合。

　　2. 了解你。这一切都是为了知道你是否真的有问题。这可以追溯到问自己你如何确定的确实存在问题。你的系统一直以特定方式运行的时候，有时，或者只是你从一些用户得知?如果你没有什么地方告诉你什么时候出错，你怎么知道什么东西是错误的?时钟时间，用户的意见，和hot C-level breath并不一定意味着有错误。

　　In our Example：我假设，因为读者对我的auto- start and stop文章做出反应，他们实际上有一个自己组织的系统。在这种情况下，我要祝贺读者找到我的文章，并提出问题。他们显然是在做研究，并试图凑在一起。现在，如果读者只是试图找我文章的毛病，它常常发生，那么所有我能说的是直接跳到如下的3号。

　　3 . 了解你的工作。知道你的系统，相信你的研究并且衔接这两个。这或许是解决问题最困难的一部分。你必须混合你知道，你系统正在做的，和你的研究发现。错误可能是灾难性的。这就是为什么在这一步你必须把这些项目和你假设的实际测试结合在一起。彻底的试验和错误，特别是当第一次开始的，是唯一的途径，你可以验证你有什么和你想要去哪儿。

　　In our Example：这是部分，老实说，我也有点困惑。不管在第2步的情况，所有研究人员应验证其假设。这是你的通过试验和错误获得智慧的方法。通过调查和了解他们的工作，这些读者应该很快发现 dbstart脚本与Oracle 11有启动监听器的设置，所以没有必要放在我的脚本里。让我这一点，这是不是我的文章对别人的。它是确保你的问题，可以被我的解决办法弥补。考虑到这一点又向前迈进了一步，当我回答这些读者，我没有只需键入响应重新说明了我的解决方案/立场。我重装了我的机器和重新测试我所写的。然后才是我回答这个提给我的问题。是的，这花了大约1小时的时间。不管怎样，我们这些谁写的解决方案必须非常小心，不要导致有人误入歧途。

　　4 . 计划的实施。这应该是半明显，但根据是否你是在测试阶段或预先部署到生产阶段，你应该规划你会怎么做。我建议接近菜谱的办法，把你的步骤写在纸面上，然后采取后续行动你在的进程中你执行这些步骤。

　　In our Example：我已经说过，我重新测试脚本之前，我给我的读者回复了答案。我的读者应该也做了相同的。此外，当我重新测试，我按照我一步一步的办法，使命令和后续的输出和解释。你计划的攻击，不管你有多少信任你理解的解决办法，都应随时准备捕捉可能出现的漏洞，因为一些未知数。

　　5 . 执行与验证：好吧，只是这样做。但是，为后代的缘故，记录你的调查结果，确保它们符合你的测试结果，然后安心入睡。

　　在解决任何问题，研究是不可避免的。信任和验证这项研究是另一回事。这是很难验证我们遇到的一切。系统只是太复杂，而不能坐在角落里等待被使用。然而，在解决问题，将被部署到生产环境中，作为数据库管理员我们有责任，在我们接受解决方案成为事实之前测试他们。

　　原文：http://www.databasejournal.com/features/oracle/article.php/3770081