Re: How to document a DB

Rick Denoire wrote:

>Perhaps this is a silly question. I have got the task of documenting a
>DB. I keep this DB up and running (backup, reorganisations,
>configuration, etc.) but I am not familiar with the applications
>running based on it, neither am I familiar with the schema and
>relations (i.e., I don't understand the real sense of data contained
>there in - although I could).
>
>If I compile a document containing key information about tablespaces,
>backup procedure, security issues, stability... that would raise
>eyebrowses. What is expected is a description of the DB based on data
>dependency, workflows, basic data structures from the point of view of
>the users, when data is loaded and who uses them the most for what,
>and, most important, what is to be considered when making any changes
>in order not to break anything.
>
>Since I am not the first one in life with such a task, perhaps someone
>can point me to a standard procedure to setup this documentation. Or
>give me a hint about tools helping me in this question.
>
>We use Oracle 8.1.7 on a Sun E3500/Solaris 7 at the moment.
>
>Thanks a lot
>Rick Denoire
>
>
>

Not to in any way be disparaging ... it sounds like you are not the person to do the job and that what you are about to do is create a huge stack of documents that will never ... ever ... be read by anyone again.

The way to not break things is very well defined in our industry:

1. Don't ever make changes in a production environemnt that haven't been thoroughly tested on a production clone.
2. Have a series of scripts in that testing environment that look at the DBA_DEPENDENCIES, DBA_INDEXES, DBA_CONSTRAINTS, and other data dictionary views.

A far better investment in time would be to document a versioning and change management methodology to keep anything from ever being done in production before thorough testing and a management sign-off.

Of course reality is that likely your manager will still want you to waste your time. So ask for a copy of Designer and just reverse engineer the whole thing.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)