服务器信息可以分成几个方面来看，比如操作系统情况，内核版本，硬盘，内存，空间使用情况，累计运行时间，数据库实例运行时间，系统中的swap争用情况等等，尽可能根据实际的情况进行一些维度的划分和细粒度的归纳。
比如说在生产中，考虑容灾，会有一主一备，甚至一主多备，这个时候，我们也需要考虑主备环境中的硬件资源的情况，资源使用情况。
举几个例子。
比如我们手头有两台服务器，是作为异地容灾的，我们通过简单的解析得到了两台服务器的初步信息。
服务器一：RHEL 6,空间使用近70G,120G内存，24CPU,服务器已启动590多天，数据库实例启动自2013年，
服务器二：RHEL 4,空间分配达3.1T,使用率达2.5T,40G内存24CPU,服务器已启动280多天,数据库实例启动自2014年,swap争用较高
我们来看看这两台服务器信息在特定的场景中会有哪些考虑，当然有些细节还没有罗列出来。
第一个部分就是IP信息，dataguard的场景作为异地容灾尤为重要，如果主备在同一个机房，势必会给灾备带来一些隐患，比如机房断电，这种情况下影响就会凸显出来
然后我们来看主备的系统版本，一个是redhat 6,一个是redhat 4，其实也可以搭成主备环境，但是多多少少会有一些影响，比如有些基于操作系统级的参数在不同的系统版本中可能有不同的表现。
我们再来看一看空间分配，第一台是作为主库来使用的，可以看到使用了近70G的空间，但是备库却又3T左右的空间，使用率却要高得多，这个时候就需要评估是否空间资源使用是否合理，是否有一些额外的空间消耗没有释放。
再来看看内存资源，一台服务器是120G，一台是40G，在这种情况下，势必会对sga的配置会有一定影响，对于系统中的hugepage等的设置也会有所不同，配大了可能备库不能接受，配小了又有些浪费。
还有一些信息，比如主备库的系统运行时间，可以看到主库服务器已经运行了近600天，而备库有差不多300天的样子，在这个时间范围内，可能发生了一些资源的分配最后导致了系统资源，硬件资源出现了一些差别。
最后一个要点就是在备库中存在着较高的swap现象，这个从数据库的角度来看，还是没有能够合理的利用large page或者hugepage。而在主库中就没有明显的swap争用。这个时候如果发生了灾难切换，切换到备库之后，可能在备库中就会存在一些潜在的性能问题。
再比如我们有如下的两台数据库服务器，一部分资源作为dataguard使用，另外一部分资源作为其它的辅助资源来提供，怎么理解呢，可以简单来说，一台服务器类似主库，另外一台服务器做为备库，同时根据情况还需要跑其它的业务数据库。
比如我们得到了两台服务器的资源情况如下：
RHEL 5,空间分配350G,使用近170G,8G内存，服务器已启动780多天，数据库实例启动自2013年,同时有xxxxx和xxxx两个数据库实例在跑,swap争用较高
RHEL 5,空间分配234G,使用近170G,8G内存，服务器已启动近500天,数据库实例启动自2014年，同时又xxxx和xxxx,xxxx三个数据库实例在跑，swap争用较高
在这种情况我们怎么来分析呢，第一个部分就是IP信息，dataguard的场景作为异地容灾尤为重要，如果主备在同一个机房，势必会给灾备带来一些隐患，比如机房断电，这种情况下影响就会凸显出来
然后我们来看主备的系统版本，一个是redhat 6,一个是redhat 4，其实也可以搭成主备环境，但是多多少少会有一些影响，比如有些基于操作系统级的参数在不同的系统版本中可能有不同的表现。
我们再来看一看空间分配，第一台是作为主库来使用的，可以看到使用了近70G的空间，但是备库却又3T左右的空间，使用率却要高得多，这个时候就需要评估是否空间资源使用是否合理，是否有一些额外的空间消耗没有释放。
再来看看内存资源，一台服务器是120G，一台是40G，在这种情况下，势必会对sga的配置会有一定影响，对于系统中的hugepage等的设置也会有所不同，配大了可能备库不能接受，配小了又有些浪费。
还有一些信息，比如主备库的系统运行时间，可以看到主库服务器已经运行了近600天，而备库有差不多300天的样子，在这个时间范围内，可能发生了一些资源的分配最后导致了系统资源，硬件资源出现了一些差别。
最后一个要点就是在备库中存在着较高的swap现象，这个从数据库的角度来看，还是没有能够合理的利用large page或者hugepage。而在主库中就没有明显的swap争用。这个时候如果发生了灾难切换，切换到备库之后，可能在备库中就会存在一些潜在的性能问题。
再比如我们有如下的两台数据库服务器，一部分资源作为dataguard使用，另外一部分资源作为其它的辅助资源来提供，怎么理解呢，可以简单来说，一台服务器类似主库，另外一台服务器做为备库，同时根据情况还需要跑其它的业务数据库。
比如我们得到了两台服务器的资源情况如下：
RHEL 5,空间分配350G,使用近170G,8G内存，服务器已启动780多天，数据库实例启动自2013年,同时有xxxxx和xxxx两个数据库实例在跑,swap争用较高
RHEL 5,空间分配234G,使用近170G,8G内存，服务器已启动近500天,数据库实例启动自2014年，同时又xxxx和xxxx,xxxx三个数据库实例在跑，swap争用较高
这个时候我们可以看到系统版本，空间资源使用情况都差不多，系统的内存相对有些紧张，跑了好几个数据库勉强才有8G的内存空间，主库服务器上有两个数据库实例在跑，而备库中有两个备库实例在跑，另外还有一台其他业务的数据库实例，这种情况下，就可能会有一些灾难场景，我们可以了解到主库服务器已经运行了近800天，已经两年多了，而备库也有差不多1年半了。在这种情况，系统的资源使用情况比较紧俏，很可能就会出现问题。一旦出现问题，就会有问题的放大效应，比如备库出现了介质损坏，那么额外的那个数据库实例就没有办法恢复了，因为本地的空间情况剩余也只有50G左右，如果规划系统的rman备份，也没有多少空间可用，而且同时主库已经跑了2年多了，压力还是相似甚至开始加大的状态下，主库长期在这种资源紧俏的时候更容易出现问题，这个时候主库出现问题，备库的隐患还是没有解除，因为这个时候系统的压力全部都到了备库上了。如果备库压力突增，更可能出现问题。
所以这个时候与时俱进做一个前瞻的准备还是不错的，比如我们的主库资源配置较低，但是我们配备了一个高配的备库，这样就相对可以轻松很多，如果出现问题，问题处理的余地还很大，甚至我们还是希望主库能够切换到备库上来，这样出现问题之后切换系统的稳定性反而更强了。
所以说如果手头拥有大量的服务器资源，不妨还是适当规划一些，看看是否能够做一些合理的改变，在问题发生的时候更加从容一些，毕竟自动化运维是一个很大的方向，我们不能保证系统的资源都是完全一样的，可能很多时候因为各种因素，会有很大的差别，这些系统资源的权衡是自动化运维所不能完全考虑到的，所以我还是希望这是属于半自动化运维中的范畴。