快过年了，很多系统都要进入最后的检查和复验阶段，一方面在节假日前，提前发现问题总比过节的时候发现要好。另一方面如果出现故障的时候能及时进行处理，这个时候我们就需要有一个尽可能全面的元数据收集。而且还有一点比较重要的就是工作交接，如果你临时有事，需要让同事来代劳，你得提供清晰易懂的信息给他们。
可能有的同学会觉得我们已经有了数据库监控，基本的性能分析，这个工作是不是就可以忽略了。监控只是标记状态，出现问题时候它没法帮你处理，还是需要人工介入，而人工介入尽可能全面的信息就是这些元数据了，如果你们已经有了CMDB,那可能会简化很多工作，如果没有，也可以生成一个精简版的，在这个基础上能够故障自愈那就太好了。别着急，一口气吃个大胖子也不现实。
之前也写了不少的脚本，自己也用了一些脚本完成了一些基本的检查任务，但是想得到一个简练的报告，这个工作现在还没有做好。比如对于节假日的问题处理分析，出现服务不可用，宕机类问题可能才是呼唤我们的时候。所以对于灾备的信息就尤其需要注意。
先来看看目前的简单效果：
name : ACCMOB0
db_unique_name : s2accmob0
database_role : PRIMARY
open_mode : READ WRITE
version : 11.2.0.3.0
Character set : AL32UTF8
NCHAR Character set : AL16UTF16
10.11.2.145 s3accmob0.test.com s3accmob0 1525
10.11.128.169 saccmob03.test.com saccmob03 1525
上面的输出就能够达到一个基本的效果，通过这些信息，我们就可以得到数据库的字符集，状态，对应的备库信息和IP,连对应的端口也抓到了，这个信息其实就比较简练了。
实现这个脚本复杂不复杂呢，其实也没多少。
sqlplus -s / as sysdba <<EOF
set pages 0
set feedback off
select rpad('name', 20, ' ') || ': ' || name || chr(10)||
rpad('db_unique_name', 20, ' ') || ': ' || db_unique_name || chr(10)||
rpad('database_role', 20, ' ') || ': ' || database_role || chr(10)||
rpad('open_mode', 20, ' ') || ': ' || open_mode
from v\$database;
select rpad('version', 20, ' ') || ': ' || version
from v\$instance;
select rpad(description, 20, ' ') || ': ' || property_value
from database_properties
where property_name in ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');
EOF
for tmp_ins in `dgmgrl -silent / " show configuration" |grep -i "Physical standby database"|sed 's/Physical standby database//g'|sed 's/-//g'`
do
tmp_tns=`dgmgrl -silent / " show database verbose ${tmp_ins}" |grep StaticConnectIdentifier|awk '{print $3}'`
echo $tmp_tns
tmp_host=`echo ${tmp_tns}|grep ADDRESS|sed 's/Attempting to contact //'|sed 's/(/\n/g'|sed 's/)/\n/g'|grep -i 'HOST\|PORT\|SERVICE_NAME\|SID_NAME' |grep -i HOST| awk -F= '{print $2}'`
#tmp_host=`tnsping ${tmp_ins}|grep ADDRESS|sed 's/Attempting to contact //'|sed 's/(/\n/g'|sed 's/)/\n/g'|grep -i 'HOST\|PORT\|SERVICE_NAME\|SID_NAME' |grep -i HOST| awk -F= '{print $2}'`
#echo ${tmp_host}
tmp_port=`echo ${tmp_tns}|grep ADDRESS|sed 's/Attempting to contact //'|sed 's/(/\n/g'|sed 's/)/\n/g'|grep -i 'HOST\|PORT\|SERVICE_NAME\|SID_NAME' |grep -i PORT| awk -F= '{print $2}'`
#echo ${tmp_port}
tmp_con_chk=`nc -w 1 -v ${tmp_host} ${tmp_port}`
#echo ${tmp_con_chk}
if [[ ${tmp_con_chk} =~ "succ" ]]; then
echo `grep -w ${tmp_host} /etc/hosts|awk '{print $1}'`" " ${tmp_host} " " ${tmp_ins} " " ${tmp_port}
else
echo 'NEED TO CHECK HOST '${tmp_host}
fi
done
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆
这里有几点需要指出：
1）得到备库的信息，目前是基于DG Broker来抓取的，但是有的服务器可能配置了主机名，有的配置了IP，就需要根据情况来解析。
2）得到对应的服务器IP和端口，目前有三种实现方式，一种就是通过dgmgrl，使用show database verbose来得到连接串的信息，另外一种就是通过tnsping来得到，第3种是通过解析tnsnames.ora来得到。
上面的例子给出了前两种。
3）解析IP和端口后的网络情况是通过nc来实现的，nc这个命令比较好，可以设置超时时间，这个例子里面设置了1秒。
当然你说这个脚本看起来蛮有意思，你说有没有缺点呢，实在太多了，所以只是一个初版，会持续更新。
缺点有以下几个：
1）判断数据库的主备角色，这样就可以避免重复解析DG Broker中主备关系信息。
2）使用tnsping或者DG Broker中的show database verbose方式，如果多备库间的网络不通，会有超时的情况。不过这种概率较小，如果出现问题也需要我们及时修复
3）如果是多备库的情况，如果得到更具体的备库信息，比如同机房备库，异机房备库，这些就需要解析资产信息了。
