This discussion is archived
1 2 Previous Next 15 Replies Latest reply: May 20, 2013 9:33 AM by EdStevens RSS

How to auto start and stop the database on startup and shutdown of the OS

996129 Newbie
Currently Being Moderated
How do you automatically start and stop the database on startup and shutdown of the Operating system using Oracle 11gR2 11.2 on Oracle Linux 5.9 x86. I tried what oracle support suggested in How to Configure a Linux x86 Box for Oracle DB Auto Start / Shutdown [ID 281912.1] as follows, but it didn't work either. Can anyone please tell me what I'm doing wrong.

[root@dgsdba init.d]# cat dbora
#! /bin/bash
#
# description: Oracle auto start-stop script.
#
# chkconfig: 2345 99 10
#
# processname: oracle
# config: /etc/oratab
# pidfile: /var/run/oracle.pid

# Source function library.
. /etc/init.d/functions

RETVAL=0
ORA_OWNER="oracle"
ORA_HOME="/u01/app/oracle/product/11.2.0/dbhome_1"

# See how we were called.

prog="oracle"

start() {
echo -n $"Starting $prog: "
su - $ORA_OWNER -c "$ORA_HOME/bin/dbstart"
su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl start"
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/dbora

return $RETVAL
}

stop() {
echo -n $"Stopping $prog: "
su - $ORA_OWNER -c "$ORA_HOME/bin/dbshut"
su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl stop"
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -r /var/lock/subsys/dbora

return $RETVAL
}

restart() {
stop
start
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac

exit $?
[root@dgsdba init.d]#
  • 1. Re: How to auto start and stop the database on startup and shutdown of the OS
    sb92075 Guru
    Currently Being Moderated
    993126 wrote:
    How do you automatically start and stop the database on startup and shutdown of the Operating system using Oracle 11gR2 11.2 on Oracle Linux 5.9 x86.
    Nothing is required to be done when OS goes down.

    I NEVER configure Oracle to automatically start after OS boot since doing so could wipe out needed evidence why the system went down in the first place.
  • 2. Re: How to auto start and stop the database on startup and shutdown of the OS
    EdStevens Guru
    Currently Being Moderated
    If you read the cited note, you know there is a lot more to it than just that dbora script.

    Did you properly set /etc/oratab? Show us.

    Did you properly run chkconfig? Show us.

    Did you put the dbora script in the proper directory? Show us.

    But as SB said, do you really want your databases to start up automatically? If I have a server go down, I want to manage every step of bringing it back up. It went down for a reason, and I don't want my databases restarting until I'm ready.
  • 3. Re: How to auto start and stop the database on startup and shutdown of the OS
    996129 Newbie
    Currently Being Moderated
    EdStevens wrote:
    If you read the cited note, you know there is a lot more to it than just that dbora script.

    Did you properly set /etc/oratab? Show us.

    Did you properly run chkconfig? Show us.

    Did you put the dbora script in the proper directory? Show us.

    But as SB said, do you really want your databases to start up automatically? If I have a server go down, I want to manage every step of bringing it back up. It went down for a reason, and I don't want my databases restarting until I'm ready.
    Of course I did, but I'll show you anyway.

    The contents of the /etc/oratab is as follows:

    #



    # This file is used by ORACLE utilities. It is created by root.sh
    # and updated by the Database Configuration Assistant when creating
    # a database.

    # A colon, ':', is used as the field terminator. A new line terminates
    # the entry. Lines beginning with a pound sign, '#', are comments.
    #
    # Entries are of the form:
    # $ORACLE_SID:$ORACLE_HOME:<N|Y>:
    #
    # The first and second fields are the system identifier and home
    # directory of the database respectively. The third filed indicates
    # to the dbstart utility that the database should , "Y", or should not,
    # "N", be brought up at system boot time.
    #
    # Multiple entries with the same $ORACLE_SID are not allowed.
    #
    #
    OracleLinux:/u01/app/oracle/product/11.2.0/dbhome_1:Y
    [root@dgsdba init.d]#

    The output of the grep on the chkconfig on dbora is as follows:

    [root@dgsdba init.d]# chkconfig --list | grep -v grep | grep dbora
    dbora 0:off 1:off 2:off 3:on 4:off 5:on 6:off
    [root@dgsdba init.d]#

    The location of the dbora script is as follows:
    [root@dgsdba init.d]# ls -l /etc/init.d/dbora
    -rw-r--r-- 1 root dba 921 May 14 11:41 /etc/init.d/dbora
    [root@dgsdba init.d]#

    I want to know how to make it start automatically because if the system reboot for some unknown reason, which most likely it wouldn't. However if say if I was using this on a live server and the UPS power was to get low or the above were to occur I would want the database to start automatically on startup so users would hardly notice it was down. Either way I don't see anything wrong with wanting it to start automatically after all it would in Windows, so why not have it do the same using Linux.
  • 4. Re: How to auto start and stop the database on startup and shutdown of the OS
    sb92075 Guru
    Currently Being Moderated
    http://www.lmgtfy.com/?q=oracle+autostart+linux
  • 5. Re: How to auto start and stop the database on startup and shutdown of the OS
    EdStevens Guru
    Currently Being Moderated
    993126 wrote:
    EdStevens wrote:
    If you read the cited note, you know there is a lot more to it than just that dbora script.

    Did you properly set /etc/oratab? Show us.

    Did you properly run chkconfig? Show us.

    Did you put the dbora script in the proper directory? Show us.

    But as SB said, do you really want your databases to start up automatically? If I have a server go down, I want to manage every step of bringing it back up. It went down for a reason, and I don't want my databases restarting until I'm ready.
    Of course I did, but I'll show you anyway.

    The contents of the /etc/oratab is as follows:

    #



    # This file is used by ORACLE utilities. It is created by root.sh
    # and updated by the Database Configuration Assistant when creating
    # a database.

    # A colon, ':', is used as the field terminator. A new line terminates
    # the entry. Lines beginning with a pound sign, '#', are comments.
    #
    # Entries are of the form:
    # $ORACLE_SID:$ORACLE_HOME:<N|Y>:
    #
    # The first and second fields are the system identifier and home
    # directory of the database respectively. The third filed indicates
    # to the dbstart utility that the database should , "Y", or should not,
    # "N", be brought up at system boot time.
    #
    # Multiple entries with the same $ORACLE_SID are not allowed.
    #
    #
    OracleLinux:/u01/app/oracle/product/11.2.0/dbhome_1:Y
    [root@dgsdba init.d]#

    The output of the grep on the chkconfig on dbora is as follows:

    [root@dgsdba init.d]# chkconfig --list | grep -v grep | grep dbora
    dbora 0:off 1:off 2:off 3:on 4:off 5:on 6:off
    [root@dgsdba init.d]#

    The location of the dbora script is as follows:
    [root@dgsdba init.d]# ls -l /etc/init.d/dbora
    -rw-r--r-- 1 root dba 921 May 14 11:41 /etc/init.d/dbora
    [root@dgsdba init.d]#

    I want to know how to make it start automatically because if the system reboot for some unknown reason, which most likely it wouldn't. However if say if I was using this on a live server and the UPS power was to get low or the above were to occur I would want the database to start automatically on startup so users would hardly notice it was down. Either way I don't see anything wrong with wanting it to start automatically after all it would in Windows, so why not have it do the same using Linux.
    Off-hand I don't see anything wrong. Does your alert log perhaps indicate a failed startup? What clues exist in the alert log? I see the dbora script has some 'checkpoint' messages that get echo'd without any redirection. I'm not familiar enough with the init process to know where those messages go, but you might try to track them down for confirmation, or add a second one with redirection to a known location:
    start() {
    echo -n $"Starting $prog: "
    echo -n $"Starting $prog: " >> /tmp/dbora.lis 2>&1
    Do that for every function in the script.


    " after all it would in Windows, so why not have it do the same using Linux."
    It only does it by default on Windows. Probably because the guiding principle in Windows is that the user doesn't know what he wants. On my remaining Windows system, no the database doesn't start automatically. For the same reason I don't do it on Linux. I can understand certain applications require high-availability and this auto-start sounds attractive. But if that were a real business requirement, then you'd be using RAC. And even when "high availability" is a "requirement", think about the validity of the "requirement" Is it really business-driven, or is it management-driven? For example, a banking ATM system, or an on-line sales system would be a legitimate HA requirement. An internal system, say HR ... not really HA beyond the fact that management thinks it is. What is the cost to the company if the HR people don't have access for 20 minutes? I once had a financial reporting system and if a printed report was 5 minutes late arriving on the VP's desk, phones started ringing. Sure, he was a VP and we had to do what we could, but that requirement was driven by management expectations, not business need.

    I guess what I'm saying is that while it would be nice to figure out what's going on here, I wouldn't just assume that auto-start is necessarily "A Good Thing". Another option to keep in the back of your mind is that if you install Grid Infrastructure to run ASM .. even stand-alone (no cluster) .. you get Oracle Restart, which handles auto stop and start for you. But if you don't want to use ASM, that is probably overkill.
  • 6. Re: How to auto start and stop the database on startup and shutdown of the OS
    996129 Newbie
    Currently Being Moderated
    EdStevens wrote:
    993126 wrote:
    EdStevens wrote:
    If you read the cited note, you know there is a lot more to it than just that dbora script.

    Did you properly set /etc/oratab? Show us.

    Did you properly run chkconfig? Show us.

    Did you put the dbora script in the proper directory? Show us.

    But as SB said, do you really want your databases to start up automatically? If I have a server go down, I want to manage every step of bringing it back up. It went down for a reason, and I don't want my databases restarting until I'm ready.
    Of course I did, but I'll show you anyway.

    The contents of the /etc/oratab is as follows:

    #



    # This file is used by ORACLE utilities. It is created by root.sh
    # and updated by the Database Configuration Assistant when creating
    # a database.

    # A colon, ':', is used as the field terminator. A new line terminates
    # the entry. Lines beginning with a pound sign, '#', are comments.
    #
    # Entries are of the form:
    # $ORACLE_SID:$ORACLE_HOME:<N|Y>:
    #
    # The first and second fields are the system identifier and home
    # directory of the database respectively. The third filed indicates
    # to the dbstart utility that the database should , "Y", or should not,
    # "N", be brought up at system boot time.
    #
    # Multiple entries with the same $ORACLE_SID are not allowed.
    #
    #
    OracleLinux:/u01/app/oracle/product/11.2.0/dbhome_1:Y
    [root@dgsdba init.d]#

    The output of the grep on the chkconfig on dbora is as follows:

    [root@dgsdba init.d]# chkconfig --list | grep -v grep | grep dbora
    dbora 0:off 1:off 2:off 3:on 4:off 5:on 6:off
    [root@dgsdba init.d]#

    The location of the dbora script is as follows:
    [root@dgsdba init.d]# ls -l /etc/init.d/dbora
    -rw-r--r-- 1 root dba 921 May 14 11:41 /etc/init.d/dbora
    [root@dgsdba init.d]#

    I want to know how to make it start automatically because if the system reboot for some unknown reason, which most likely it wouldn't. However if say if I was using this on a live server and the UPS power was to get low or the above were to occur I would want the database to start automatically on startup so users would hardly notice it was down. Either way I don't see anything wrong with wanting it to start automatically after all it would in Windows, so why not have it do the same using Linux.
    Off-hand I don't see anything wrong. Does your alert log perhaps indicate a failed startup? What clues exist in the alert log? I see the dbora script has some 'checkpoint' messages that get echo'd without any redirection. I'm not familiar enough with the init process to know where those messages go, but you might try to track them down for confirmation, or add a second one with redirection to a known location:
    start() {
    echo -n $"Starting $prog: "
    echo -n $"Starting $prog: " >> /tmp/dbora.lis 2>&1
    Do that for every function in the script.


    " after all it would in Windows, so why not have it do the same using Linux."
    It only does it by default on Windows. Probably because the guiding principle in Windows is that the user doesn't know what he wants. On my remaining Windows system, no the database doesn't start automatically. For the same reason I don't do it on Linux. I can understand certain applications require high-availability and this auto-start sounds attractive. But if that were a real business requirement, then you'd be using RAC. And even when "high availability" is a "requirement", think about the validity of the "requirement" Is it really business-driven, or is it management-driven? For example, a banking ATM system, or an on-line sales system would be a legitimate HA requirement. An internal system, say HR ... not really HA beyond the fact that management thinks it is. What is the cost to the company if the HR people don't have access for 20 minutes? I once had a financial reporting system and if a printed report was 5 minutes late arriving on the VP's desk, phones started ringing. Sure, he was a VP and we had to do what we could, but that requirement was driven by management expectations, not business need.

    I guess what I'm saying is that while it would be nice to figure out what's going on here, I wouldn't just assume that auto-start is necessarily "A Good Thing". Another option to keep in the back of your mind is that if you install Grid Infrastructure to run ASM .. even stand-alone (no cluster) .. you get Oracle Restart, which handles auto stop and start for you. But if you don't want to use ASM, that is probably overkill.
    Good point, but this is a test enviroment on a virtual machine and I really just want to be able to make the database start automatically to see how it works and I'm not using ASM because we really didn't cover it by doing hands-on exercise for my class. Once I can make it work I would like to share how I did it.
  • 7. Re: How to auto start and stop the database on startup and shutdown of the OS
    996129 Newbie
    Currently Being Moderated
    EdStevens wrote:
    993126 wrote:
    EdStevens wrote:
    If you read the cited note, you know there is a lot more to it than just that dbora script.

    Did you properly set /etc/oratab? Show us.

    Did you properly run chkconfig? Show us.

    Did you put the dbora script in the proper directory? Show us.

    But as SB said, do you really want your databases to start up automatically? If I have a server go down, I want to manage every step of bringing it back up. It went down for a reason, and I don't want my databases restarting until I'm ready.
    Of course I did, but I'll show you anyway.

    The contents of the /etc/oratab is as follows:

    #



    # This file is used by ORACLE utilities. It is created by root.sh
    # and updated by the Database Configuration Assistant when creating
    # a database.

    # A colon, ':', is used as the field terminator. A new line terminates
    # the entry. Lines beginning with a pound sign, '#', are comments.
    #
    # Entries are of the form:
    # $ORACLE_SID:$ORACLE_HOME:<N|Y>:
    #
    # The first and second fields are the system identifier and home
    # directory of the database respectively. The third filed indicates
    # to the dbstart utility that the database should , "Y", or should not,
    # "N", be brought up at system boot time.
    #
    # Multiple entries with the same $ORACLE_SID are not allowed.
    #
    #
    OracleLinux:/u01/app/oracle/product/11.2.0/dbhome_1:Y
    [root@dgsdba init.d]#

    The output of the grep on the chkconfig on dbora is as follows:

    [root@dgsdba init.d]# chkconfig --list | grep -v grep | grep dbora
    dbora 0:off 1:off 2:off 3:on 4:off 5:on 6:off
    [root@dgsdba init.d]#

    The location of the dbora script is as follows:
    [root@dgsdba init.d]# ls -l /etc/init.d/dbora
    -rw-r--r-- 1 root dba 921 May 14 11:41 /etc/init.d/dbora
    [root@dgsdba init.d]#

    I want to know how to make it start automatically because if the system reboot for some unknown reason, which most likely it wouldn't. However if say if I was using this on a live server and the UPS power was to get low or the above were to occur I would want the database to start automatically on startup so users would hardly notice it was down. Either way I don't see anything wrong with wanting it to start automatically after all it would in Windows, so why not have it do the same using Linux.
    Off-hand I don't see anything wrong. Does your alert log perhaps indicate a failed startup? What clues exist in the alert log? I see the dbora script has some 'checkpoint' messages that get echo'd without any redirection. I'm not familiar enough with the init process to know where those messages go, but you might try to track them down for confirmation, or add a second one with redirection to a known location:
    start() {
    echo -n $"Starting $prog: "
    echo -n $"Starting $prog: " >> /tmp/dbora.lis 2>&1
    Do that for every function in the script.


    " after all it would in Windows, so why not have it do the same using Linux."
    It only does it by default on Windows. Probably because the guiding principle in Windows is that the user doesn't know what he wants. On my remaining Windows system, no the database doesn't start automatically. For the same reason I don't do it on Linux. I can understand certain applications require high-availability and this auto-start sounds attractive. But if that were a real business requirement, then you'd be using RAC. And even when "high availability" is a "requirement", think about the validity of the "requirement" Is it really business-driven, or is it management-driven? For example, a banking ATM system, or an on-line sales system would be a legitimate HA requirement. An internal system, say HR ... not really HA beyond the fact that management thinks it is. What is the cost to the company if the HR people don't have access for 20 minutes? I once had a financial reporting system and if a printed report was 5 minutes late arriving on the VP's desk, phones started ringing. Sure, he was a VP and we had to do what we could, but that requirement was driven by management expectations, not business need.

    I guess what I'm saying is that while it would be nice to figure out what's going on here, I wouldn't just assume that auto-start is necessarily "A Good Thing". Another option to keep in the back of your mind is that if you install Grid Infrastructure to run ASM .. even stand-alone (no cluster) .. you get Oracle Restart, which handles auto stop and start for you. But if you don't want to use ASM, that is probably overkill.
    You wanted to see my alert log, so I did as follows. I ran the command adrci as oracle and did a show alert on dbora. The following are the results:

    2013-04-29 22:37:42.634000 -04:00
    Create Relation ADR_CONTROL
    Create Relation ADR_INVALIDATION
    Create Relation INC_METER_IMPT_DEF
    Create Relation INC_METER_PK_IMPTS
    System parameter file is /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
    Log messages written to /u01/app/oracle/diag/tnslsnr/dgsdba/dbora/alert/log.xml
    Trace information written to /u01/app/oracle/diag/tnslsnr/dgsdba/dbora/trace/ora_5154_3045172928.trc
    Trace level is currently 0

    Started with pid=5154
    TNS-01151: Missing listener name, dbora, in LISTENER.ORA
  • 8. Re: How to auto start and stop the database on startup and shutdown of the OS
    sb92075 Guru
    Currently Being Moderated
    993126 wrote:
    TNS-01151: Missing listener name, dbora, in LISTENER.ORA
    1) listener is NOT required to start or use any local Oracle DB
    2) listener.ora file does not need to exist to start or use Oracle listener.

    do as below

    cd /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/
    mv listener.ora listener.ora.sav

    lsnrctl stop
    lsnrctl start
    lsnrctl status
    # wait 60+ seconds
    lsnrctl service

    COPY the results from above then PASTE all back here.
  • 9. Re: How to auto start and stop the database on startup and shutdown of the OS
    EdStevens Guru
    Currently Being Moderated
    993126 wrote:
    EdStevens wrote:
    993126 wrote:
    EdStevens wrote:
    If you read the cited note, you know there is a lot more to it than just that dbora script.

    Did you properly set /etc/oratab? Show us.

    Did you properly run chkconfig? Show us.

    Did you put the dbora script in the proper directory? Show us.

    But as SB said, do you really want your databases to start up automatically? If I have a server go down, I want to manage every step of bringing it back up. It went down for a reason, and I don't want my databases restarting until I'm ready.
    Of course I did, but I'll show you anyway.

    The contents of the /etc/oratab is as follows:

    #



    # This file is used by ORACLE utilities. It is created by root.sh
    # and updated by the Database Configuration Assistant when creating
    # a database.

    # A colon, ':', is used as the field terminator. A new line terminates
    # the entry. Lines beginning with a pound sign, '#', are comments.
    #
    # Entries are of the form:
    # $ORACLE_SID:$ORACLE_HOME:<N|Y>:
    #
    # The first and second fields are the system identifier and home
    # directory of the database respectively. The third filed indicates
    # to the dbstart utility that the database should , "Y", or should not,
    # "N", be brought up at system boot time.
    #
    # Multiple entries with the same $ORACLE_SID are not allowed.
    #
    #
    OracleLinux:/u01/app/oracle/product/11.2.0/dbhome_1:Y
    [root@dgsdba init.d]#

    The output of the grep on the chkconfig on dbora is as follows:

    [root@dgsdba init.d]# chkconfig --list | grep -v grep | grep dbora
    dbora 0:off 1:off 2:off 3:on 4:off 5:on 6:off
    [root@dgsdba init.d]#

    The location of the dbora script is as follows:
    [root@dgsdba init.d]# ls -l /etc/init.d/dbora
    -rw-r--r-- 1 root dba 921 May 14 11:41 /etc/init.d/dbora
    [root@dgsdba init.d]#

    I want to know how to make it start automatically because if the system reboot for some unknown reason, which most likely it wouldn't. However if say if I was using this on a live server and the UPS power was to get low or the above were to occur I would want the database to start automatically on startup so users would hardly notice it was down. Either way I don't see anything wrong with wanting it to start automatically after all it would in Windows, so why not have it do the same using Linux.
    Off-hand I don't see anything wrong. Does your alert log perhaps indicate a failed startup? What clues exist in the alert log? I see the dbora script has some 'checkpoint' messages that get echo'd without any redirection. I'm not familiar enough with the init process to know where those messages go, but you might try to track them down for confirmation, or add a second one with redirection to a known location:
    start() {
    echo -n $"Starting $prog: "
    echo -n $"Starting $prog: " >> /tmp/dbora.lis 2>&1
    Do that for every function in the script.


    " after all it would in Windows, so why not have it do the same using Linux."
    It only does it by default on Windows. Probably because the guiding principle in Windows is that the user doesn't know what he wants. On my remaining Windows system, no the database doesn't start automatically. For the same reason I don't do it on Linux. I can understand certain applications require high-availability and this auto-start sounds attractive. But if that were a real business requirement, then you'd be using RAC. And even when "high availability" is a "requirement", think about the validity of the "requirement" Is it really business-driven, or is it management-driven? For example, a banking ATM system, or an on-line sales system would be a legitimate HA requirement. An internal system, say HR ... not really HA beyond the fact that management thinks it is. What is the cost to the company if the HR people don't have access for 20 minutes? I once had a financial reporting system and if a printed report was 5 minutes late arriving on the VP's desk, phones started ringing. Sure, he was a VP and we had to do what we could, but that requirement was driven by management expectations, not business need.

    I guess what I'm saying is that while it would be nice to figure out what's going on here, I wouldn't just assume that auto-start is necessarily "A Good Thing". Another option to keep in the back of your mind is that if you install Grid Infrastructure to run ASM .. even stand-alone (no cluster) .. you get Oracle Restart, which handles auto stop and start for you. But if you don't want to use ASM, that is probably overkill.
    You wanted to see my alert log, so I did as follows. I ran the command adrci as oracle and did a show alert on dbora. The following are the results:

    2013-04-29 22:37:42.634000 -04:00
    Create Relation ADR_CONTROL
    Create Relation ADR_INVALIDATION
    Create Relation INC_METER_IMPT_DEF
    Create Relation INC_METER_PK_IMPTS
    System parameter file is /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
    Log messages written to /u01/app/oracle/diag/tnslsnr/dgsdba/dbora/alert/log.xml
    Trace information written to /u01/app/oracle/diag/tnslsnr/dgsdba/dbora/trace/ora_5154_3045172928.trc
    Trace level is currently 0

    Started with pid=5154
    TNS-01151: Missing listener name, dbora, in LISTENER.ORA
    That would be from the listener log, not the database alert log. So it appears that the listener is not starting, but perhaps - we don't know - that the database is starting. When I asked for the alert log, I was talking about the database alert log. Looking for evidence that the database was NOT being shut down cleanly. Evidence would be lack of 'shutdown' messages, and presence of 'crash recovery' messages on startup.


    So maybe we need to go back to square one and ask what evidence you have that the database is not starting?

    Show us
    env|egrep 'ORA|PATH'|sort
    ps -ef|grep pmon
    sqlplus / as sysdba
  • 10. Re: How to auto start and stop the database on startup and shutdown of the OS
    996129 Newbie
    Currently Being Moderated
    EdStevens wrote:
    993126 wrote:
    EdStevens wrote:
    993126 wrote:
    EdStevens wrote:
    If you read the cited note, you know there is a lot more to it than just that dbora script.

    Did you properly set /etc/oratab? Show us.

    Did you properly run chkconfig? Show us.

    Did you put the dbora script in the proper directory? Show us.

    But as SB said, do you really want your databases to start up automatically? If I have a server go down, I want to manage every step of bringing it back up. It went down for a reason, and I don't want my databases restarting until I'm ready.
    Of course I did, but I'll show you anyway.

    The contents of the /etc/oratab is as follows:

    #



    # This file is used by ORACLE utilities. It is created by root.sh
    # and updated by the Database Configuration Assistant when creating
    # a database.

    # A colon, ':', is used as the field terminator. A new line terminates
    # the entry. Lines beginning with a pound sign, '#', are comments.
    #
    # Entries are of the form:
    # $ORACLE_SID:$ORACLE_HOME:<N|Y>:
    #
    # The first and second fields are the system identifier and home
    # directory of the database respectively. The third filed indicates
    # to the dbstart utility that the database should , "Y", or should not,
    # "N", be brought up at system boot time.
    #
    # Multiple entries with the same $ORACLE_SID are not allowed.
    #
    #
    OracleLinux:/u01/app/oracle/product/11.2.0/dbhome_1:Y
    [root@dgsdba init.d]#

    The output of the grep on the chkconfig on dbora is as follows:

    [root@dgsdba init.d]# chkconfig --list | grep -v grep | grep dbora
    dbora 0:off 1:off 2:off 3:on 4:off 5:on 6:off
    [root@dgsdba init.d]#

    The location of the dbora script is as follows:
    [root@dgsdba init.d]# ls -l /etc/init.d/dbora
    -rw-r--r-- 1 root dba 921 May 14 11:41 /etc/init.d/dbora
    [root@dgsdba init.d]#

    I want to know how to make it start automatically because if the system reboot for some unknown reason, which most likely it wouldn't. However if say if I was using this on a live server and the UPS power was to get low or the above were to occur I would want the database to start automatically on startup so users would hardly notice it was down. Either way I don't see anything wrong with wanting it to start automatically after all it would in Windows, so why not have it do the same using Linux.
    Off-hand I don't see anything wrong. Does your alert log perhaps indicate a failed startup? What clues exist in the alert log? I see the dbora script has some 'checkpoint' messages that get echo'd without any redirection. I'm not familiar enough with the init process to know where those messages go, but you might try to track them down for confirmation, or add a second one with redirection to a known location:
    start() {
    echo -n $"Starting $prog: "
    echo -n $"Starting $prog: " >> /tmp/dbora.lis 2>&1
    Do that for every function in the script.


    " after all it would in Windows, so why not have it do the same using Linux."
    It only does it by default on Windows. Probably because the guiding principle in Windows is that the user doesn't know what he wants. On my remaining Windows system, no the database doesn't start automatically. For the same reason I don't do it on Linux. I can understand certain applications require high-availability and this auto-start sounds attractive. But if that were a real business requirement, then you'd be using RAC. And even when "high availability" is a "requirement", think about the validity of the "requirement" Is it really business-driven, or is it management-driven? For example, a banking ATM system, or an on-line sales system would be a legitimate HA requirement. An internal system, say HR ... not really HA beyond the fact that management thinks it is. What is the cost to the company if the HR people don't have access for 20 minutes? I once had a financial reporting system and if a printed report was 5 minutes late arriving on the VP's desk, phones started ringing. Sure, he was a VP and we had to do what we could, but that requirement was driven by management expectations, not business need.

    I guess what I'm saying is that while it would be nice to figure out what's going on here, I wouldn't just assume that auto-start is necessarily "A Good Thing". Another option to keep in the back of your mind is that if you install Grid Infrastructure to run ASM .. even stand-alone (no cluster) .. you get Oracle Restart, which handles auto stop and start for you. But if you don't want to use ASM, that is probably overkill.
    You wanted to see my alert log, so I did as follows. I ran the command adrci as oracle and did a show alert on dbora. The following are the results:

    2013-04-29 22:37:42.634000 -04:00
    Create Relation ADR_CONTROL
    Create Relation ADR_INVALIDATION
    Create Relation INC_METER_IMPT_DEF
    Create Relation INC_METER_PK_IMPTS
    System parameter file is /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
    Log messages written to /u01/app/oracle/diag/tnslsnr/dgsdba/dbora/alert/log.xml
    Trace information written to /u01/app/oracle/diag/tnslsnr/dgsdba/dbora/trace/ora_5154_3045172928.trc
    Trace level is currently 0

    Started with pid=5154
    TNS-01151: Missing listener name, dbora, in LISTENER.ORA
    That would be from the listener log, not the database alert log. So it appears that the listener is not starting, but perhaps - we don't know - that the database is starting. When I asked for the alert log, I was talking about the database alert log. Looking for evidence that the database was NOT being shut down cleanly. Evidence would be lack of 'shutdown' messages, and presence of 'crash recovery' messages on startup.


    So maybe we need to go back to square one and ask what evidence you have that the database is not starting?

    Show us
    env|egrep 'ORA|PATH'|sort
    ps -ef|grep pmon
    sqlplus / as sysdba
    I did as you suggested and here is the output:

    [oracle@dgsdba ~]$ env|egrep 'ORA|PATH'|sort
    ORACLE_BASE=/u01/app/oracle/
    ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
    ORACLE_SID=OracleLinux
    PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/oracle/bin:/u01/app/oracle/product/11.2.0/dbhome_1/bin
    [oracle@dgsdba ~]$ ps -ef | grep -v grep | grep pmon
    [oracle@dgsdba ~]$ sqlplus / as sysdba

    SQL*Plus: Release 11.2.0.1.0 Production on Sat May 18 13:31:37 2013

    Copyright (c) 1982, 2009, Oracle. All rights reserved.

    Connected to an idle instance.

    SQL>

    The following would be the evidence that the database is not automatically starting on startup of the operating system:

    [oracle@dgsdba ~]$ /u01/app/oracle/product/11.2.0/dbhome_1/bin/sqlplus

    SQL*Plus: Release 11.2.0.1.0 Production on Sat May 18 13:34:26 2013

    Copyright (c) 1982, 2009, Oracle. All rights reserved.

    Enter user-name: system
    Enter password:
    ERROR:
    ORA-01034: ORACLE not available
    ORA-27101: shared memory realm does not exist
    Linux Error: 2: No such file or directory
    Process ID: 0
    Session ID: 0 Serial number: 0


    Enter user-name:

    Also should I try the following:

    1) listener is NOT required to start or use any local Oracle DB
    2) listener.ora file does not need to exist to start or use Oracle listener.

    do as below

    cd /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/
    mv listener.ora listener.ora.sav

    lsnrctl stop
    lsnrctl start
    lsnrctl status
    # wait 60+ seconds
    lsnrctl service

    COPY the results from above then PASTE all back here.

    Edited by: 993126 on May 18, 2013 10:39 AM
  • 11. Re: How to auto start and stop the database on startup and shutdown of the OS
    sb92075 Guru
    Currently Being Moderated
    post results from following OS command

    ls -ltr /u01/app/oracle/product/11.2.0/dbhome_1/dbs/
  • 12. Re: How to auto start and stop the database on startup and shutdown of the OS
    EdStevens Guru
    Currently Being Moderated
    >
    <snip>
    So maybe we need to go back to square one and ask what evidence you have that the database is not starting?

    Show us
    env|egrep 'ORA|PATH'|sort
    ps -ef|grep pmon
    sqlplus / as sysdba
    I did as you suggested and here is the output:

    [oracle@dgsdba ~]$ env|egrep 'ORA|PATH'|sort
    ORACLE_BASE=/u01/app/oracle/
    ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
    ORACLE_SID=OracleLinux
    PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/oracle/bin:/u01/app/oracle/product/11.2.0/dbhome_1/bin
    [oracle@dgsdba ~]$ ps -ef | grep -v grep | grep pmon
    Ok, right there is the proof that the database is not started. If it were started, we would have seen its 'pmon' process.
    [oracle@dgsdba ~]$ sqlplus / as sysdba

    SQL*Plus: Release 11.2.0.1.0 Production on Sat May 18 13:31:37 2013

    Copyright (c) 1982, 2009, Oracle. All rights reserved.

    Connected to an idle instance.

    SQL>
    And corroborated by the fact that it indicates connected to an 'idle' (aka 'not started') instance.
    The following would be the evidence that the database is not automatically starting on startup of the operating system:

    [oracle@dgsdba ~]$ /u01/app/oracle/product/11.2.0/dbhome_1/bin/sqlplus

    SQL*Plus: Release 11.2.0.1.0 Production on Sat May 18 13:34:26 2013

    Copyright (c) 1982, 2009, Oracle. All rights reserved.

    Enter user-name: system
    Enter password:
    ERROR:
    ORA-01034: ORACLE not available
    ORA-27101: shared memory realm does not exist
    Linux Error: 2: No such file or directory
    Process ID: 0
    Session ID: 0 Serial number: 0


    Enter user-name:

    Also should I try the following:

    1) listener is NOT required to start or use any local Oracle DB
    2) listener.ora file does not need to exist to start or use Oracle listener.

    do as below

    cd /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/
    mv listener.ora listener.ora.sav

    lsnrctl stop
    lsnrctl start
    lsnrctl status
    # wait 60+ seconds
    lsnrctl service

    COPY the results from above then PASTE all back here.

    Edited by: 993126 on May 18, 2013 10:39 AM
    Why ask me if you you "should"? SB has asked for the evidence that would provide. What is the worst that could happen?

    But based on what you just showed, I can guess what will result. The listener will start with all default values (fine for 99.99% of the people 99.99% of the time) and will recognize the db instance as soon as it registers itself with the listener. But since we already know the instance is not started (lack of a pmon process for it) we know that there is nothing to registers. In fact, when we say the instance is 'not started" or is 'idle', what we are really saying is the instance does not exist. That's a nit-picky detail that applies in this case. The *database* is the collection of data, control, and redo log files. The *database* exists on disk. The *instance* is the memory space and background processes that operate on the database. If the instance isn't *started*, then in fact it doesn't even exist. But I digress from your immediate problem.

    Ok, then .. we know your database is not restarting at server startup, in spite of the fact it *looks* as if you have your dbora, dbstart, and dbshut scripts all in place. How do we go about tracing the activity of those scripts?
  • 13. Re: How to auto start and stop the database on startup and shutdown of the OS
    996129 Newbie
    Currently Being Moderated
    sb92075 wrote:
    post results from following OS command

    ls -ltr /u01/app/oracle/product/11.2.0/dbhome_1/dbs/
    I did what you requested and the following is the output?

    [oracle@dgsdba ~]$ ls -ltr /u01/app/oracle/product/11.2.0/dbhome_1/dbs/
    total 48
    -rw-r--r-- 1 oracle oinstall 2851 May 15 2009 init.ora
    drwx------ 2 oracle oinstall 4096 Apr 26 15:53 peshm_orcl_0
    -rw-r----- 1 oracle oinstall 24 Apr 26 15:54 lkORCL
    -rw-r----- 1 oracle oinstall 1536 Apr 26 16:03 orapwOracleLinux
    -rw-rw---- 1 oracle oinstall 1544 May 10 16:53 hc_OracleLinux.dat
    -rw-r----- 1 oracle oinstall 3584 May 10 16:53 spfileOracleLinux.ora
    [oracle@dgsdba ~]$
  • 14. Re: How to auto start and stop the database on startup and shutdown of the OS
    996129 Newbie
    Currently Being Moderated
    EdStevens wrote:
    >
    <snip>
    So maybe we need to go back to square one and ask what evidence you have that the database is not starting?

    Show us
    env|egrep 'ORA|PATH'|sort
    ps -ef|grep pmon
    sqlplus / as sysdba
    I did as you suggested and here is the output:

    [oracle@dgsdba ~]$ env|egrep 'ORA|PATH'|sort
    ORACLE_BASE=/u01/app/oracle/
    ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1
    ORACLE_SID=OracleLinux
    PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/oracle/bin:/u01/app/oracle/product/11.2.0/dbhome_1/bin
    [oracle@dgsdba ~]$ ps -ef | grep -v grep | grep pmon
    Ok, right there is the proof that the database is not started. If it were started, we would have seen its 'pmon' process.
    [oracle@dgsdba ~]$ sqlplus / as sysdba

    SQL*Plus: Release 11.2.0.1.0 Production on Sat May 18 13:31:37 2013

    Copyright (c) 1982, 2009, Oracle. All rights reserved.

    Connected to an idle instance.

    SQL>
    And corroborated by the fact that it indicates connected to an 'idle' (aka 'not started') instance.
    The following would be the evidence that the database is not automatically starting on startup of the operating system:

    [oracle@dgsdba ~]$ /u01/app/oracle/product/11.2.0/dbhome_1/bin/sqlplus

    SQL*Plus: Release 11.2.0.1.0 Production on Sat May 18 13:34:26 2013

    Copyright (c) 1982, 2009, Oracle. All rights reserved.

    Enter user-name: system
    Enter password:
    ERROR:
    ORA-01034: ORACLE not available
    ORA-27101: shared memory realm does not exist
    Linux Error: 2: No such file or directory
    Process ID: 0
    Session ID: 0 Serial number: 0


    Enter user-name:

    Also should I try the following:

    1) listener is NOT required to start or use any local Oracle DB
    2) listener.ora file does not need to exist to start or use Oracle listener.

    do as below

    cd /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/
    mv listener.ora listener.ora.sav

    lsnrctl stop
    lsnrctl start
    lsnrctl status
    # wait 60+ seconds
    lsnrctl service

    COPY the results from above then PASTE all back here.

    Edited by: 993126 on May 18, 2013 10:39 AM
    Why ask me if you you "should"? SB has asked for the evidence that would provide. What is the worst that could happen?

    But based on what you just showed, I can guess what will result. The listener will start with all default values (fine for 99.99% of the people 99.99% of the time) and will recognize the db instance as soon as it registers itself with the listener. But since we already know the instance is not started (lack of a pmon process for it) we know that there is nothing to registers. In fact, when we say the instance is 'not started" or is 'idle', what we are really saying is the instance does not exist. That's a nit-picky detail that applies in this case. The *database* is the collection of data, control, and redo log files. The *database* exists on disk. The *instance* is the memory space and background processes that operate on the database. If the instance isn't *started*, then in fact it doesn't even exist. But I digress from your immediate problem.

    Ok, then .. we know your database is not restarting at server startup, in spite of the fact it *looks* as if you have your dbora, dbstart, and dbshut scripts all in place. How do we go about tracing the activity of those scripts?
    Good point how do you go about tracing the activity of those scripts and will showing you the logs help you do this? Also I'm pursing help from Oracle support as well, so I will share any successful solutions they can offer as well.
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points