A few years ago having the database down on a regular basis was normal and considered necessary just for backups. But it is no longer needed in these days of 24x7 IT operations and expanded Service Level Agreements (SLAs).
The database most often will only have to be down for patches or upgrades, which can be either Oracle or application-specific. You should no longer need to have the database down to do backups. If cold backups are a norm at your workplace, then this is a sign of a dinosaur. Little to no downtime applies to production instances, but non-production should be mostly up during working hours with only intermittent outages.
Each organization has its own Outage Handling Procedures—depending on whether it is planned or unplanned downtime. Most DBAs are assigned a database to be the primary contact when there is an outage issue on call. Outage handling usually includes something similar to the following:
Initial troubleshooting to determine the type of outage: Evaluate any automatic failover procedures to check for success.
Forecasting the amount of time before resolution: This is the point for making the decision if a manual fail over is needed.
Bringing the application or database back online: Not all failures are due to the database being down, even when that is what first appears to be the case.
Root cause analysis: What was the real reason for the outage? This is not always evident at first glance.
Future preventive actions: Evaluating and rewriting the outage procedures, reassigning team members for outage coverage.
Outage handling is an important process and includes quite a few non-DBA team members who must coordinate efforts, and not just point fingers to get this issue resolved. These types of procedures should be well documented (in both print and online form for disasters) with a definite line of authority as to who can execute the procedures with administrative approval.
There are many things that could cause the database to crash or become unavailable to end users:
Hardware failure
Corruption
Operating system issues
ASM or RAC specific problems
Critical Oracle processes dying
Certain ORA-600 errors
Certain Oracle bugs
Listener not running
Human error
Speaking of the human side of things, the following list details how to avoid the really bad things that can happen to even experienced DBAs. Remember if you are a novice or new DBA, you shouldn't have access to certain servers or databases because your superior understands how easy it is to do the wrong thing at the wrong time. The following list may seem harsh, full of should and don't statements, but I felt it was important to state exactly what others have experienced or witnessed personally. Think of it as an experienced DBA giving someone under them some good advice about what to avoid.