Documentation:  
·         Tools. All tools used on the project should be documented just as the application modules are documented. These tools become a part of the required expertise for the project if it is re-activated. An example of this would be the CASE tools used to design and implement the DDL for the application. If the knowledge requirements for the tools aren't captured when the project is reactivated vital time may be lost searching for the right person with the proper tool knowledge. 
·         Reasons for project mothballing. This may be the most difficult documentation to produce. This is not a face saving document. It should be as accurate and complete as is possible. Try to stick to the facts and not let opinions be included. Of all the documents, this may be one of the most important since it will point out to the new project leaders what went wrong so that they may be able to avoid the pitfalls that shelved the project in this first attempt.
·         Contact list. Even though it may get out of date rather quickly in these transient times, you should include a contact list of all members of the team. The contact list should include contact phone numbers, addresses and skill set matrices for all team members. If the project is reactivated this list may provide vital contact points to get back the original team, or, personnel recommended by the original team members.
·         Setup instructions. Each type of database has different file layouts and disk arrangements. An example would be Oracle's Optimal Flexible Architecture (OFA) methodology. If the application has any special considerations in this area, these have to be documented.

SEE CODE DEPOT FOR FULL SCRIPTS

http://www.rampant-books.com/book_1002_oracle_tuning_definitive_reference_2nd_ed.htm