很多情况下，随着工作的进行，可能会接管更多的服务器资源。这个时候，我们手里的服务器可不止一两台了。可能有数十个、数百个甚至数千个。这时候服务器信息的维护就显得尤为重要。不管业务线的规划如何，对于DBA来说，只有掌握了服务器信息，知道了基础，才能解决问题。出现问题要合理处理。服务器信息可以分为几个方面，如操作系统、内核版本、硬盘、内存、空间使用、累计运行时间、数据库实例运行时间、系统中的swap争用等，尽量按照实际情况根据情况进行一些维度划分和细粒度归纳。比如在生产中，考虑到容灾，会有一主一备，甚至一主多备。这时候我们还需要考虑主备环境下的硬件资源和资源使用情况。举几个例子。例如，我们手头有两台服务器用于异地容灾，通过简单的分析，我们已经得到了两台服务器的初步信息。服务器1：RHEL6，空间使用近70G，120G内存，24CPU，服务器启动590多天，数据库实例从2013年开始启动。服务器2：RHEL4，空间分配高达3.1T，使用率高达2.5T，40G内存，24CPU，服务器已启动280多天，数据库实例2014年启动，swap争用高。下面我们来看看这两个服务器信息在具体场景下的注意事项，当然有些细节还没有列出来。第一部分是IP信息。dataguard场景对于异地容灾尤为重要。如果主备在同一个机房??，势必会给容灾带来一些隐患，比如机房停电。在这种情况下，影响就会凸显出来。然后再看主备系统版本，一个是redhat6，一个是redhat4。其实也可以设置成主备环境，只是会有一些影响，比如一些参数基于操作系统级别在不同的系统中是不同的。版本的行为可能不同。我们再来看看空间分配。第一站作为主库。可以看到使用了将近70G的空间，但是备份库有3T左右的空间，使用率要高很多。这时候就需要评估空间资源的使用是否合理，是否有一些额外的空间消耗没有被释放。我们再看看内存资源。一台服务器是120G，一台是40G。这样的话，势必会对sga的配置造成一定的影响。对于备份库来说可能是不能接受的，分配少的话有点浪费。还有一些信息，比如主备库的系统运行时间。可以看到，主库服务器已经运行了将近600天，而备库已经运行了将近300天。在这个时间范围内，可能会发生一些资源分配***导致系统资源和硬件资源出现一些差异。***很重要的一点就是备库存在highswap现象。从数据库的角度来说，还是不能合理的利用大页面或者hugepages。在主库中，没有明显的swap争用。如果此时发生灾难切换，切换到备库后，备库可能存在一些潜在的性能问题。再比如我们有如下两台数据库服务器，一部分资源作为dataguard使用，另一部分作为其他辅助资源提供。怎么理解呢？简单来说，一台服务器类似于主数据库，另一台服务器用作备份数据库，同时需要根据情况运行其他业务数据库。比如我们获取两台服务器的资源如下：RHEL5，空间分配350G，使用了将近170G，8G内存，服务器已经启动780多天，数据库实例从2013年开始启动，有是xxxxx和xxxx两个数据库实例同时运行，swap争用高。RHEL5，空间分配234G，使用近170G，8G内存，服务器启动近500天，数据库实例从2014年开始启动，同时运行xxxx、xxxx、xxxx三个数据库实例时间，并且交换争用很高。我们如何分析这种情况？这个时候我们可以看到系统版本，空间资源的使用情况都差不多，系统的内存比较紧张。跑了几个数据库，内存空间才勉强8G。主数据库服务器上运行着两个数据库实例，备库中运行着两个备库实例，另外还有一个数据库实例用于其他业务。在这种情况下，可能会出现一些灾难场景。我们可以了解到，主库服务器运行了将近800天，也就是两年多了，备库也运行了将近一年半。在这种情况下，系统的资源使用比较紧张，容易出现问题。一旦出现问题，就会出现问题的放大效应。比如备份数据库损坏，追加的数据库实例无法恢复，因为本地剩余空间只有50G左右。如果规划系统的rman备份可用空间不多，同时主库已经运行了2年多，压力还是差不多甚至越来越大。资源长期紧缺时，主库更容易出现问题。这个时候主库有问题，备库的隐患还是没有解决，因为这个时候系统的压力都在备库上了。如果备库压力突然增大，就更容易出现问题。所以这个时候，与时俱进，做好前瞻性的准备是好的。比如我们的主库资源配置低，但是我们配备了一个高配置的备库，这样就相对容易了。如果有问题，就会处理问题。空间还是很大的，我们甚至希望主库可以切换到备库，这样出现问题后切换系统的稳定性会更强。所以如果你手头的服务器资源比较多，不妨适当规划一下，看看能不能做出一些合理的改动，在出现问题的时候更加冷静。毕竟自动化运维是一个很大的方向，我们不能保证系统的资源完全一样，很多时候可能会因为各种因素而有很大的差异。这些系统资源的权衡是自动化运维无法完全考虑的，所以我还是希望这是一个品类中的半自动化运维。
