假期前的数据库检查脚本之主备关系(r11笔记第46天)

时间:2022-05-05
本文章向大家介绍假期前的数据库检查脚本之主备关系(r11笔记第46天),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

快过年了,很多系统都要进入最后的检查和复验阶段,一方面在节假日前,提前发现问题总比过节的时候发现要好。另一方面如果出现故障的时候能及时进行处理,这个时候我们就需要有一个尽可能全面的元数据收集。而且还有一点比较重要的就是工作交接,如果你临时有事,需要让同事来代劳,你得提供清晰易懂的信息给他们。

可能有的同学会觉得我们已经有了数据库监控,基本的性能分析,这个工作是不是就可以忽略了。监控只是标记状态,出现问题时候它没法帮你处理,还是需要人工介入,而人工介入尽可能全面的信息就是这些元数据了,如果你们已经有了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)如果是多备库的情况,如果得到更具体的备库信息,比如同机房备库,异机房备库,这些就需要解析资产信息了。