Stop and Start Rules for HANA on AWS
I work with a remote team in India and one of the things we have drilled into each others minds is – when you are done working on the HANA – Stop the instance on AWS to avoid unexpected compute charges. In fact, I even downloaded an iPhone app called OPS1 so that I can shut down the AWS instance.
The problem with this rule is- HANA doesn’t always want to start up correctly when we Start in instance back up in the EC2 console. Symptoms within SAP HANA Studio include:
- The AWS instance node shows something other than stop
- The Catalog doesn’t always expand out
- The Administration console shows only the tabs for Processes and Diagnosis Files
The ah ha step that we missed was – Stop the HANA database instance first and wait for the stop action to be completed. It’s as simple as running the Stop command from the database instance node in SAP HANA Studio using the Soft option. Once the node shows the database as stopped, then Stop the instance from the AWS EC2 console. Starting the VM back up from the EC2 console then starts the HANA database instance in a happy state!
All is not lost if anyone on the team forgets to stop the HANA database instance. In Juergen Schmerder’s master blog – http://scn.sap.com/docs/DOC-28294, he has documented the stop and start procedures that must be run from the Linux SSH client – you can’t use SAP HANA Studio to do this as you need to stop the instance and then start it and the Stop command is not enabled in HANA Studio. Here are the sequence of steps required to recover in the event you stopped the VM without stopping the database:
Launch your SSH client
# su -l hdbadm
# ./HDB stop
# ./HDB start
More information regarding stop and start operations can be found in the Administration Guide at http://www.saphana.com/docs/DOC-1073
Please follow me on Twitter at https://twitter.com/billramo
Bill Ramos, Database Architect at Advaiya Inc.
G'day Bill,
while this post is an old one, I came across it hunting down resolutions to issues relating to start/stopping HANA instances on AWS. We use the Cloud Appliance Library (CAL) control panel, which, against each of our instances, lists options to Activate/Suspend the HANA system (to avoid hosting charges). What I've noticed however, and some information from SAP on this would be wonderful, is that - like your observation above - it is not sufficient to simply suspend the operating instance and expect HANA to be cool with it. One must soft stop the DB before suspending the instance, using the methods you describe.
But this is counter intuitive to the CAL control panel: when one starts an instance, we're given the (convenient) option automatically suspending after x hours - a great way to keep on top of charges. It appears that this automated (or indeed, manual) suspend action does not soft stop the DB before suspending the instance. I know this because suspending the instance through the CAL results in an immediate suspension of the instance over in AWS. Our system takes at least 15 seconds to soft stop, and this is clearly not happening with the automated suspension from CAL.
What we've found, as a result of activating/suspending day after day, is that the troublesome table sys.m_dev_rollback_transaction_table continuously grows, understandably, but is never able to be cleared. Subsequently, when the thread stack size is exceeded (see discussion Large rollback transaction table | SCN, started by Dirk Kemper), the indexserver will not start until the thread worker stack size is increased. The default stack size is 1024 Kb. After these shenanigans, we've had to increase our thread stack size to over 5 Mb, just to get the indexserver up and running! As such, we are soft stopping before suspending the Linux instance each night to avoid this. No automated shutdowns, because they simply don't work.
For those interested, this is the post (HANA Index Server - Stack area size) that points to the SAP Note with a resolution. BUT! The note is no resolution. In fact, it's a poor work and temporary work around. If you run into the problem, you'll note that the rollback table in fact, never clears, so your only other option to get HANA up is to boost the stack size, as mentioned.
So, a warning to others - I'm providing a good amount of detail here so that some other unlucky soul might have a fighting chance of addressing this issue before it gets out of hand.
Sorry for hijacking your post Bill, but there's no need for others to bash their heads against the wall. If you haven't got an SMP account (which many devs using HANA Dev or Trial Cloud don't), you're up the creek, so to speak.
Cheers, and thanks for the great content.
Hagen
Hi Hagen,
I'll make sure SAP gets this feedback. By all means, you aren't hijacking the blog post as it's quite relevant with great advice for people using CAL.
Regards,
Bill
Dear Bill,
Can you run HANA Database setup again and tick on Restart system after try after machine reboot and check after restarting linux server.