Thanks for the question, Rafael.
Asked: January 09, 2020 - 2:24 pm UTC
Answered by: Connor McDonald - Last updated: January 13, 2020 - 4:24 am UTC
Category: Database Administration - Version: 126.96.36.199
Viewed 100+ times
Let's say we have a server maintenance and it needs to rebooted.
Should both teams (OS and database team) work together to, first, shutdown databases (grid daemons, listeners, etc) or should the database rely on server shutdown only? Are there any risks by choosing the second option?
and we said...
First thing I would be checking is that this is not already happening for you. Typically a server shutdown will either have explicitly scripts (in init.d for example) to shut the databases down, or there will be scripts to shutdown the clusterware which in turn will shutdown the databases automatically.
In any event, one of the great things about the Oracle database is that it is resilient to abnormal shutdown (power loss etc etc). That is why, when I need to do a quick bounce of database (eg parameter change) I'll do a "startup force" (which is a shutdown abort/startup). So even if a database shutdown was not performed, you should be fine. But being typically cautious person I am, in *general* I'd use a controlled shutdown because:
a) on that rare day when I needed a *clean* shutdown to do a database patch, I'm not going to get caught out if I was lazy
b) if a server shutdown causes some awkward blackspot where storage is "half" available, I don't want my database saving dirty writes etc. (I've never seen this happen...but you never know :-))
In 25+ years of databases, I've never seen a reboot corrupt an Oracle database unless it was already corrupted and the restart simply brought that fact to attention.