前几天的时候帮助一个网友看了他遇到的一个问题，在问题处理中也让我有不少的感悟。
最开始的时候这位网友的问题是一个10gR2的单实例数据库，监听无法正常关闭和启动，他在尝试了杀进程之后，重新启动还是会一直卡在那里。
看到这个地方，感觉是一个新环境，看来是网络哪里出现了问题，要么就是配置出现了问题。
在这种情况，配置情况很难一一去确认猜测，所以我就问他能否远程协助，很快就连了过去。
当他打开/etc/hosts文件的时候，感觉里面的配置信息似乎有些过于简单了，里面只有localhost和127.0.0.1的配置，我准备朝这个方向来分析，是否配置出现了问题，检查了网络配置，目前所看到的的配置都是取默认值，正在我分析的时候，他告诉我说，这个数据库以前好好的，今天出了点问题，不知道怎么的监听就无法重启了。而话外之意，为什么要重启还是有应用的同学反馈连接问题，这样听来也蛮有道理。
所以听到这里，我就停下来手中正在进行的配置信息检查。而准备换一个思路来考虑这个问题。
在重启的间隙里，我让他再打开一个窗口，使用top查看，发现CPU idle竟然是0，也就意味着现在的系统负载极高，CPU资源是已经被全部占完了，看到这里这位网友就有些不知所措了。我想了想，首先停止正在重启的监听工作，然后查看目前系统的CPU瓶颈究竟在哪里。从top结果来看，主要的CPU资源都是在数据库的会话进程上，而且从进程信息可以看出这些会话的持有时间已经超过20多个小时了，占用率都不低。这种情况下初步感觉就是相关的SQL语句出现了问题，当然要连接数据库检查还是要征得这位网友的同意，结果使用sqlplus登录竟然毫无反应，所以数据库层面的检查工作就很有限了。那我就从数据库日志中来尝试得到一些有用的信息，但是奇怪的是系统从昨天开始到现在竟然没有任何的日志输出，这个就极为奇怪了，总得切一次归档吧，竟然一丁点日志都没有。所以这个数据库不光是因为资源消耗高而完全阻塞了，从目前的情况来看是有僵死的感觉。
但是凡事不能太肯定，所以我们还是先做保守的工作，我看了下数据库目前有近80个用户进程，资源消耗都很高，所以我的建议就是先释放系统资源，即从操作系统层面来杀掉一些资源使用较高的会话，从实际来看，大量的会话持续20多个小时，肯定是有问题的。先保证业务可以恢复为先，所以在告诉网友要旨之后，让他来从本地操作一下。清理了近30多个进程之后，查看系统资源，CPU idle依然是0，从top来看资源使用依旧很高。所以逐步加大了杀掉进程的幅度，最后差不多了，查看top发现idle还是很低，所以这个问题就让人很纠结。
最后相关的会话都杀掉了，数据库的负载依旧是CPU 100%，这就让人无奈了，然后开启第二套方案，既然杀掉会话依然无济于事，我们开始尝试停止数据库，数据库实例有5个后台必备进程，但是我在尝试kill了smon,pmon之后，查看dbwr,lgwr,ckpt进程竟然依旧存在，而且资源占用依旧很高。最后一一杀掉会话，我想这下总会可以了吧，没想到这次确实有效果了，CPU资源一下子释放了，我建议这位网友尝试重启数据库，看看是否有大问题，但是我在远程运行sqlplus -v竟然没有任何反应，所以感觉问题又出现了。在这种情况下，sqlplus没有响应，后面的工作是压根没法做了。感觉问题越来越缥缈，这个时候我的一个基本建议就只剩下了重启系统，但是前提是先备份数据然后重启，因为按照这种情况重启如果失败，那数据就全丢了，这个库目前没有开启归档，所以丢数据的概率极高，在这一点上我还是很谨慎的。所以我是强烈建议先备份，然后重启数据库。
碰到这种情况着实让我有些担心，而且这台服务器存在一些硬伤，硬件配置太老旧了，内存是4G，而且上面竟然还跑了几个其他的业务，数据库的版本过低，很有可能触发一些bug之类的，对于这个问题还真是纠结，看来只能看看重启大发是否生效了，当然为了表明我的态度，不要出现二义性，我还专门打了一个电话给他，想他确认了一些信息。做完之后就等待他的进度反馈了，在我坐车回家之后，这位网友告诉我说，已经重启系统了，重启之后，数据库就自动启动了，监听使用也没有问题。而他也是带着赌一赌的感觉，没有做备份，当然这是大家都愿意看到的境地，问题解决了，但是我还是建议他以后需要及时保留备份，在问题真正出现的时候，能够少一些扯皮和推诿。
后面又帮他看了几个小问题，不过已经不重要了，因为主要的问题已经解决了。这个案例着实让我很纠结，不断调整着对于操作的最低要求，这个案例还是需要大家保持冷静，要不数据丢失就不是简单的技术问题了。
最开始的时候这位网友的问题是一个10gR2的单实例数据库，监听无法正常关闭和启动，他在尝试了杀进程之后，重新启动还是会一直卡在那里。
看到这个地方，感觉是一个新环境，看来是网络哪里出现了问题，要么就是配置出现了问题。
在这种情况，配置情况很难一一去确认猜测，所以我就问他能否远程协助，很快就连了过去。
当他打开/etc/hosts文件的时候，感觉里面的配置信息似乎有些过于简单了，里面只有localhost和127.0.0.1的配置，我准备朝这个方向来分析，是否配置出现了问题，检查了网络配置，目前所看到的的配置都是取默认值，正在我分析的时候，他告诉我说，这个数据库以前好好的，今天出了点问题，不知道怎么的监听就无法重启了。而话外之意，为什么要重启还是有应用的同学反馈连接问题，这样听来也蛮有道理。
所以听到这里，我就停下来手中正在进行的配置信息检查。而准备换一个思路来考虑这个问题。
在重启的间隙里，我让他再打开一个窗口，使用top查看，发现CPU idle竟然是0，也就意味着现在的系统负载极高，CPU资源是已经被全部占完了，看到这里这位网友就有些不知所措了。我想了想，首先停止正在重启的监听工作，然后查看目前系统的CPU瓶颈究竟在哪里。从top结果来看，主要的CPU资源都是在数据库的会话进程上，而且从进程信息可以看出这些会话的持有时间已经超过20多个小时了，占用率都不低。这种情况下初步感觉就是相关的SQL语句出现了问题，当然要连接数据库检查还是要征得这位网友的同意，结果使用sqlplus登录竟然毫无反应，所以数据库层面的检查工作就很有限了。那我就从数据库日志中来尝试得到一些有用的信息，但是奇怪的是系统从昨天开始到现在竟然没有任何的日志输出，这个就极为奇怪了，总得切一次归档吧，竟然一丁点日志都没有。所以这个数据库不光是因为资源消耗高而完全阻塞了，从目前的情况来看是有僵死的感觉。
但是凡事不能太肯定，所以我们还是先做保守的工作，我看了下数据库目前有近80个用户进程，资源消耗都很高，所以我的建议就是先释放系统资源，即从操作系统层面来杀掉一些资源使用较高的会话，从实际来看，大量的会话持续20多个小时，肯定是有问题的。先保证业务可以恢复为先，所以在告诉网友要旨之后，让他来从本地操作一下。清理了近30多个进程之后，查看系统资源，CPU idle依然是0，从top来看资源使用依旧很高。所以逐步加大了杀掉进程的幅度，最后差不多了，查看top发现idle还是很低，所以这个问题就让人很纠结。
最后相关的会话都杀掉了，数据库的负载依旧是CPU 100%，这就让人无奈了，然后开启第二套方案，既然杀掉会话依然无济于事，我们开始尝试停止数据库，数据库实例有5个后台必备进程，但是我在尝试kill了smon,pmon之后，查看dbwr,lgwr,ckpt进程竟然依旧存在，而且资源占用依旧很高。最后一一杀掉会话，我想这下总会可以了吧，没想到这次确实有效果了，CPU资源一下子释放了，我建议这位网友尝试重启数据库，看看是否有大问题，但是我在远程运行sqlplus -v竟然没有任何反应，所以感觉问题又出现了。在这种情况下，sqlplus没有响应，后面的工作是压根没法做了。感觉问题越来越缥缈，这个时候我的一个基本建议就只剩下了重启系统，但是前提是先备份数据然后重启，因为按照这种情况重启如果失败，那数据就全丢了，这个库目前没有开启归档，所以丢数据的概率极高，在这一点上我还是很谨慎的。所以我是强烈建议先备份，然后重启数据库。
碰到这种情况着实让我有些担心，而且这台服务器存在一些硬伤，硬件配置太老旧了，内存是4G，而且上面竟然还跑了几个其他的业务，数据库的版本过低，很有可能触发一些bug之类的，对于这个问题还真是纠结，看来只能看看重启大发是否生效了，当然为了表明我的态度，不要出现二义性，我还专门打了一个电话给他，想他确认了一些信息。做完之后就等待他的进度反馈了，在我坐车回家之后，这位网友告诉我说，已经重启系统了，重启之后，数据库就自动启动了，监听使用也没有问题。而他也是带着赌一赌的感觉，没有做备份，当然这是大家都愿意看到的境地，问题解决了，但是我还是建议他以后需要及时保留备份，在问题真正出现的时候，能够少一些扯皮和推诿。
后面又帮他看了几个小问题，不过已经不重要了，因为主要的问题已经解决了。这个案例着实让我很纠结，不断调整着对于操作的最低要求，这个案例还是需要大家保持冷静，要不数据丢失就不是简单的技术问题了。
