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 instead. It would be even better if you renamed the entire directory and left it in place renamed for a day or two.

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.

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.

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. If it is an active datafile, the timestamp would be current.

Add the ORACLE_SID and user into the SQL prompt. This will prevent many a disaster by visually checking the prompt before running a script in what you think is a non-production database. Instructions on how to do this come later in the book.

Use the extended Unix prompt that puts in the hostname, user, and ORACLE_SID. This will add more visual clues to ensure that you know exactly what you are modifying.

Copying and pasting directly into a 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. This double checks exactly what is in the copy/paste buffer.

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.

It is best to run recovery scenarios on a different server from any running production. Also, test operating system restores. Disaster recovery sites should also be located on a different server for true failover capabilities.

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.

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.

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.

Log rotating scripts can play havoc with naming the online redo logs with a file extension of log. Using the letters rdo would be safer.

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.

Using the number 8 in any type of scripting, ORACLE_SID name, or the like can play havoc with scripting or command-line executions because the all-inclusive wild card character * is above the eight—it's too easy to type it accidentally.

Double check by tracking the operating system's performance on a server, especially running out of file space.

Beware the reuse clause when adding or altering a database file. This command can overwrite an existing datafile, which destroys any existing data.

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.

You are responsible for backups. It is not wise to delegate this in any way.

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.

Make sure the system administrators know not to modify, move, or delete anything that belongs to the Oracle accounts.

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.

This is the most important blunder-avoiding tip—it is wisest not to do anything that you can't undo, reverse, or fix.