服务器搬迁后不是简单能连接上服务器就可以了，还有许多的事情需要考虑，否则服务器不可用还是白搭。
我大体碰到了如下的一些问题，也能够反应出来对于系统的各种潜在隐患。
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完全不可用，先不要着急，你可以看看是不是分区没有挂载。
