Steps to Shut Down / Start Up the Exadata


Shut Down

  • Log in to the first database server as root.
  • Change to the OneCommand directory:

# cd /opt/oracle.SupportTools/onecommand

 

  • Note whether the Grid Infrastructure is currently enabled for autostart, so that this state can be restored later:
# dcli -g dbs_group -l root /u01/app/12.1.0.2/grid/bin/crsctl config crs

 

  • [Optional] If the preceding step indicated that the Grid Infrastructure is currently enabled for autostart, disable it for autostart on the database servers:
# dcli -g dbs_group -l root /u01/app/12.1.0.2/grid/bin/crsctl disable crs

 

Note: This step is optional. It may be required during maintenance operations like “firmware patches,” which require rebooting the compute node several times.

  • Stop the Grid Infrastructure stack on the database servers (compute nodes):
# dcli -g dbs_group -l root "/u01/app/12.1.0.2/grid/bin/crsctl stop crs"

 

  • Verify that the Grid Infrastructure stack has shut down successfully on the database servers. The following command should show no output if the Grid Infrastructure stack has shut down:
# dcli -g dbs_group -l root "ps -ef | grep diskmo[n]"

 

  • [Optional] Disable email/SNMP alerts if applicable. If alerts will be enabled, first note the notification method in use so that it can be restored later. The following command will show the current notification method:
dcli -g cell_group -l root "su - celladmin -c \"cellcli -e list cell attributes name,notificationMethod\""

 

  • Now set the notification method to null to disable alerts:
# dcli -g cell_group -l root "su - celladmin -c \"cellcli -e alter cell notificationMethod=null\""

 

  • Shut down all cells:
# dcli -g cell_group -l root "su - celladmin -c \"cellcli -e alter cell shutdown services all \""

 

  • Power off all cells:
# dcli -g cell_group -l root poweroff

 

  • Copy the /opt/oracle.SupportTools/onecommand/dbs_group to /opt/oracle.SupportTools/onecommand/dbs_group2:
# cp /opt/oracle.SupportTools/onecommand/dbs_group /opt/oracle.SupportTools/onecommand/dbs_group2

 

  • Remove the “first compute node name” from the /opt/oracle.SupportTools/onecommand/dbs_group2 file (using any editor, e.g., vi).
  • Power off all the compute nodes (except compute node # 1):
# dcli -g dbs_group2 -l root poweroff

 

  • Power off compute node #1:
# poweroff

 

Now, both cell servers and compute nodes are down for maintenance.

 

Start Up

  • Power on “compute node #1” by using the power button on the front panel of the Exadata Storage Servers.
  • Change to the OneCommand directory:
# cd /opt/oracle.SupportTools/onecommand

 

  • Power on the cells either by using the power button on the front panel of the Exadata Storage Servers or by executing the following script from the first database server (from compute node #1):
for host in `cat cell_group`; do
echo ${host}: `ipmitool -H ${host}-ilom -U root -P welcome1 chassis power on`
done

 

  • Wait until all the cell servers are up. Then, power on the compute nodes either by using the power button on the front panel of the Exadata Storage Servers or by executing the following script from the first database server:
for host in `cat dbs_group2`; do
echo ${host}: `ipmitool -H ${host}-ilom -U root -P welcome1 chassis power on`
done

 

  • Verify that all Exadata Storage Servers have booted successfully:
# dcli -g cell_group -l root hostname

 

  • Verify that all the cells are up (MS, RS, and CELLSRV services must be running):
# dcli -g cell_group -l root "su - celladmin -c \"cellcli -e list cell detail \""

 

  • Re-enable email/SNMP alerts if they were disabled during the pre-maintenance steps. The following example illustrates the command to use if both email and SMTP alerting were used. Adjust the command as necessary to restore the notification method noted during the pre-maintenance steps.
# dcli -g cell_group -l root "su - celladmin -c \"cellcli -e alter cell notificationMethod=\'mail,snmp\'\""

 

  • Start the Grid Infrastructure stack on the first database server:
# /u01/app/12.1.0.2/grid/bin/crsctl start crs

 

  • Wait until the Grid Infrastructure stack has started successfully on the first database server. To check the status of the Grid Infrastructure stack, run the following command and verify that the “ora.asm” instance is started. Note that the following command will continue to report that it is unable to communicate with the Grid Infrastructure software for several minutes after issuing the “crsctl start crs” command above:
# /u01/app/12.1.0.2/grid/bin/crsctl status resource -t

 

  • Start the Grid Infrastructure stack on all remaining database servers with a one-minute delay between servers. Note that the following command will issue the start command for all database servers, including the first database server where it is already started. The output for the first server will therefore indicate that the software is already started, but this message can be safely ignored:
for h in `cat dbs_group2`; do
echo "Starting CRS on host $h"
ssh $h /u01/app/12.1.0.2/grid/bin/crsctl start crs
echo "Waiting 60 seconds…"
sleep 60
done

 

  • Monitor the startup progress (this could take several minutes):
# /u01/app/12.1.0.2/grid/bin/crsctl status resource -t

 

  • Re-enable the Grid Infrastructure for autostart if it was found to be enabled for autostart at the beginning of the pre-maintenance steps.
# dcli -g dbs_group -l root /u01/app/12.1.0.2/grid/bin/crsctl enable crs

 

Note: If dcli/ssh is not enabled due to security reasons, then you will need to connect and execute the preceding steps on each node at the time.

To speak with an Axxana representative, contact us here.