There are many things that could cause the database to crash or become unavailable to end-users:

• Hardware failure
• Corruption
• Operating system issues
• Cluster specific problems
• Human error

How do you keep yourself safe from common problems?

1. Assuming that all of the datafiles in a certain directory only pertain to one database is a recipe for disaster, those files can be created anywhere on the filesystem as long as Oracle has write access.
2. Don’t use rm -rf *.* for any reason at anytime, do rm *.log or *.lis or *.trc: It is safer to back up a directory and use rmdir It would be even better if you renamed the entire directory and left it in place renamed for a day or two.
3. Modifying access for a production instance at the SQL*Plus level is unusual and generally not granted to programming staff unless there is a single point of accountability, such as a lead programmer.
4. It is best to use the UNIX utility called fuser against a database file before using an rm or mv command because it checks if the file is actively being used. Another way would be to force a database checkpoint and check the timestamp before removing it. If it is an active datafile, the timestamp would be current.
5. Copying and pasting directly into an SQL*Plus or other command-line utility window can lead to the wrong code being executed. Copy and paste into a text file and run it instead. These double checks exactly what is in the copy/paste buffer.
6. Type the word production into the command-line window after you finish using it. This will prevent disasters if you accidentally switch windows and run something you shouldn’t have. It will only produce an error because there is no command called production.
7. It is best to run recovery scenarios on a different server from any running production. Also, the test operating system restores. Disaster recovery sites should also be located on a different server for true failover capabilities.
8. Make sure you know how to use the command line for all of the Oracle utilities and Unix vi editor just in case you have nothing else at your disposal.
9. It is suggested to make your production windows, application, or command-line utility like PuTTY a completely different color for production versus non-production, and the scrolling history as large as possible. Unix has a history capture utility called script.
10. Tell someone else you are modifying something… just in case. Saying it aloud may give someone else time to stop you or at least give you a mental check on what you are doing.
11. Unknown outside consultants won’t necessarily give the best advice. Be wary until you are sure of their expertise and ability. If at all possible, ask to do the work under their guidance so that you know what is actually occurring.
12. Double-check by tracking the operating system’s performance on a server, especially running out of file space.
13. Beware the reuse clause when adding or altering a database file. This command can overwrite an existing datafile, which destroys any existing data.
14. Be wary of scripts generated by third-party tools, they can be too powerful. A script to recreate an object usually drops it in the first line. This can be disastrous if the data has not been saved.
15. You are responsible for backups. It is not wise to delegate this in any way.
16. Be sure to investigate the addition of resource limits for any users that have ad hoc SQL access in production. Those types of users can easily hog CPU or I/O, which is needed more by the OLTP application.
17. Make sure the system administrators know not to modify, move, or delete anything that belongs to the Oracle accounts.
18. The Unix root account is not intended for everyday use and especially not suited for Oracle tasks. Investigate the use of sudo for tracking root-authorized activities.
19. This is the most important blunder-avoiding tip—it is wisest not to do anything that you can’t undo, reverse, or fix.