系统开关机时oracle自启动和关闭脚本（for aix和linux）
系统开关机时oracle自启动和关闭脚本（for aix和linux）
前言：
作为一名oracle DBA，有没有遇到过大半夜被电话吵醒，被告知服务器故障重启了，现在数据库服务不可用，麻烦回来启动下数据库？
作为一名oracle DBA，有没有遇到过系统组的同事跟你讲，今晚要停机维护，麻烦留下来停一下数据库？
作为一名oracle DBA，更有甚者，在这个虚拟化泛滥的时代，有没有遇到过物理主机硬件故障，导致几十台数据库server发生了重启，麻烦启动下数据库？
~~~~~~~~~~~~~~先心疼自己三秒钟 ~~~~~~~~~~~~~~~~~~
其实ORACLE从一开始就提供了数据库开机自启动的脚本，只是考虑到可控性和配置稍稍有点复杂，很多人不愿意去尝试。
正好有时间就把oracle自启动和关闭的脚本作了一些优化，以增加脚本的适用性，并把自启动和关闭的配置写到了初始化脚本auto_start_db.sh，这样只需要简单一步执行auto_start_db.sh脚本就可以完成所有配置工作。
以下：
1.AIX和Linux操作系统平台下，oracle自启动和关闭的开关在/etc/oratab文件，/etc/oratab实在创建数据库时由root.sh 脚本创建，在用DBCA 创建实例时也会更新这个文件。当ORACLE_SID:ORACLE_HOME:<N|Y>设置为Y时，允许实例自启动，当设置为N时，则不允许自启动。 这个文件里的配置仅仅起一个开关的作用，其并不会具体的执行启动和关闭，具体的操作由
2. oracle自启动和关闭的脚本直接调用oracle自带的dbstart和dbshut即可。如上所述，脚本需要做一下修改，以增强适用性。
譬如，dbstart和dbshut脚本都只能针对默认的listener，如果新建了listener或者更改过listener名，那么脚本就无法正确执行。
所以需要，
#完善listener启动和停止脚本，增加判断listener是否是默认的listenername，以及针对多个listener的情况，循环启动每个listener（包括默认的和重命名的listener）。
再比如，对于Dataguard环境，dbstart和dbshut脚本并没有做判断，以致于physical standby数据库时没法通过脚本启动到Recover managed standby模式。
所以需要，
#完善instance启动脚本，增加判断数据库为primarydb还是standby db，然后再相应地启动数据库。
3.创建dbora脚本，调用$ORACLE_HOME/bin/下的dbstart和dbshut实现自动启动和关闭。
For linux: vi/etc/init.d/dbora
For Aix: vi/etc/dbora
(NOTE：修改ORACLE_HOME和ORACLE_OWNER参数值）
#! /bin/sh
# description: Oracle auto start-stopscript.
#
# Set ORACLE_HOME to be equivalent to the $ORACLE_HOME
# from which you wish to execute dbstartand dbshut;
#
# Set ORA_OWNER to the user id of the ownerof the
# Oracle database in ORACLE_HOME.
ORA_HOME=<Type your ORACLE_HOME in fullpath here>
ORA_OWNER=<Type your Oracle account namehere>
case "$1" in
'start')
#Start the Oracle databases:
#The following command assumes that the oracle login
#will not prompt the user for any values
#Remove "&" if you don't want startup as a background process.
su - ORA_OWNER -c "
touch /var/lock/subsys/dbora
;;
'stop')
#Stop the Oracle databases:
#The following command assumes that the oracle login
#will not prompt the user for any values
su - ORA_OWNER -c "
rm -f /var/lock/subsys/dbora
;;
esac
4.在OS的适当的运行级脚本目录中创建dbora脚本的软链接（AIX平台和LINUX平台会有所差别，根据当前OS的运行级别来判断）。
For Linux：
# ln -s /etc/init.d/dbora/etc/rc.d/rc0.d/K01dbora
# ln -s /etc/init.d/dbora /etc/rc.d/rc6.d/K01dbora
# ln -s /etc/init.d/dbora/etc/rc.d/rc3.d/S99dbora
# ln -s /etc/init.d/dbora/etc/rc.d/rc5.d/S99dbora
For Aix:
# ln -s /etc/dbora /etc/rc.d/rc2.d/S99dbora
# ln -s /etc/dbora /etc/rc.d/rc0.d/K01dbora.
注意，这里有个坑，对于linux平台下的DG环境，dbora脚本在OS启动时可以放到init 3 或者init 5，但是reboot时一定不能放到init 5.放到init 5 会导致备库shutdown immediate时遭遇active call prevent shutdown operation。Active call就是备库的RFS进程，在OS层已经停止了部分服务(譬如IP配置、tcp连接)使RFS进程hung住，而pmon进程无法kill掉该进程似的shutdown无法继续。
为了避免一些手工配置的坑，我把自启动和关闭的配置写到了初始化脚本，这样只需要简单一步执行auto_start_db.sh脚本就可以帮助完成所有配置和脚本优化工作。
是不是很high？