服务器搬迁后不是简单能连接上服务器就可以了，还有许多的事情需要考虑，否则服务器不可用还是白搭。

我大体碰到了如下的一些问题，也能够反应出来对于系统的各种潜在隐患。

1

批量检测服务器的可用状态

如果有大批量的服务器搬迁，有些能够连通，有些不可以，使用telnet本身就有硬伤，我们直接设置个超时时间，对于服务是否可用一目了然。这个时候还是推荐使用nc命令。比如测试服务器10.129.128.37的22端口是否可通，超时时间为2秒，则可以使用如下的命令。

nc -z -v -n -w 2 10.129.128.37 22

2

检查ILO的连接情况

如果ILO(iDRAC)都不可用，那么基本上可以保证你的这个服务器就不可用了。没有了终极控制权，即使可以连接，但是一旦服务器出现异常就完全不可控，这个时候尤其注意的是密码，要知道密码。

3

检查root密码的情况

检查root密码的重要性不言而喻，如果能够访问到服务器，但是你压根登录不了，没有任何预想准备的用户，那么这个也可以给服务器“判刑”了。修改root密码本身不是件容易的事情，通过各种设置，如果在关键步骤还需要密码呢。

4

防火墙信息丢失

这样的情况碰到了几次，服务器重启之后原本能连接的连不上了，这个时候的解决方法还是ILO的连接到服务器端，然后手工开启，或者给自己留点余地，给主库或者备库开启访问的权限，这样即使中控权限丢失，也还能保证能够连接。

5

使用硬IP绑定而非主机域名绑定

有些系统会设置自动启动监听，很可能服务器无法开启自启动，其中的一个主要原因就是使用了硬IP绑定，在listener.ora里面如果使用主机域名解析就会省事很多。

或者对于mysql而言，这个问题就会被放大，比如下面的一个slave服务器启动之后，无法连接到主库应用binlog,经过排查，主要的一个原因就是对于用户权限的配置使用了硬IP配置，如果使用域名绑定就会方便多了。

slave的错误信息如下：

2017-07-26

03:55:34 2490 [ERROR] Slave I/O: error connecting to master

'rep_live800@live800.test.com:3306' - retry-time: 5  retries: 5,

Error_code: 1130

2017-07-26 03:55:39 2490 [ERROR] Slave I/O: error

connecting to master 'rep_live800@live800.test.com:3306' - retry-time:

5  retries: 6, Error_code: 1130

update mysql.user set host='xxxx' where user='xxx';

这个时候刷新权限就能够正常连接了。

--flush privileges

查看slave的日志如下：

2017-07-26

03:55:44 2490 [Note] Slave I/O thread: connected to master

'rep_live800@live800.test.com:3306',replication started in log

'binlog.000019' at position 818554844

6

工具的配置问题

如果使用oracle的DG broker配置，如果本身存在一些配置的问题或者就是DG Broker在早期版本不够强大，很可能会出现一些问题。

比如下面的DG Broker配置总是失败，就是的问题，最后重新配置DG Broker就可以了。

Data Guard Broker terminating NSV3, timed out waiting for a response from database s3accdb0

07/26/2017 09:13:18

Data Guard Broker terminating NSV3, timed out waiting for a response from database s3accdb0

07/26/2017 09:13:37

7

数据库无法启动

数据库在启动时很可能失败，可能因为僵尸进程，可能因为内核参数配置的问题。比如下面的这个问题。

idle> startup mount

ORA-27102: out of memory

Linux-x86_64 Error: 28: No space left on device

而错误的原因就在于内存中的僵尸进程依旧存在，还没有释放。

$ ps -ef|grep smon

oracle    5374  4967  0 12:58 pts/0    00:00:00 grep smon

oracle   24710     1  0 Jul25 ?        00:00:00 ora_smon_statdb1

手工释放，重启就可以了。

8

数据库文件丢失

数据库如果你启动服务器之后，突然发现数据全都丢失了，sqlplus,mysql完全不可用，先不要着急，你可以看看是不是分区没有挂载。