Hello,

I'm following my own practices to document my job on databases, but
also I'm wondering if they are correct or how other DBAs manage their
own documentation for a day-to-day job.

We have about 5 instances or databases to check. Each instance has a
number of schemas or users, tablespaces and datafiles, blobs, indexes
etc.

On my Windows XP, I distribute my documentation in folders and Excel
files.

I keep my scripts or queries as small text files. If I have 10 text
files, each text file has one script or a documented command. These
text files are storaged in folders. For example, one root folder is
named "Scripts and Commands" that contains general scripts and useful
commands for an Oracle DBA . This folder is divided by sub-folders.
For example sub-folder "Tablespace_Management" contains scripts and
commands for managing tablespaces.

Other root folder is named "Instance_1", which is the name of our
instance 1. It contains scripts for recreating schemas, users,
tablespaces, etc of that instance. It also contains specific queries
for end-user information.
This folder contains sub-folder "Backup_Management" which has docs
about the backup process.

Also, I keep an important Excel file with many sheets. One sheet lists
server's IP, instances, schemas, passwords and some comments. Another
sheet lists instances, schemas and tablespaces. Another sheet lists
database servers and performance features like model, memory,
processors, hard disks, etc.

I update manually this Excel file every three days by querying my
databases or after any big change that I made to a database.

Of course I also use EM db console and Toad.

Is there any advice or suggestion that you could provide?

Thanks a lot !

On Jun 6, 2:41*pm, Big George <jbet... (AT) gmail (DOT) com> wrote:
How you organize your scripts and reference documentation should be
done in a manner that makes sense to you and your teammates.

Mine are organized in my UNIX home directory under a directory named
ora then in subdirectories by functional grouping. I have a
subdirectory for scritps related to tables, indexes on the table,
columns in an index, FK to a table, and so one. I have another
directory for information related to database data files, tablespaces,
redo logs, and undo segments.

I back my scritps up by copying my scritps from my development server
to my production server so I have access to my scripts on each server
I need to work on. If you are placing your information folders on the
same server as your database you should give some though to their
availability in the event of a media problem on the server.

HTH -- Mark D Powell --





If you are storing the scripts on the database server

Mark D Powell <Mark.Powell2 (AT) hp (DOT) com> writes:

Essentialy, I have a defined directory hierarchy and the whole tree is
managed inside version control. I was using SVN, but I'm now using GIT.

Apart from tracking changes to scripts and documentation, this also has
the nice advantage that all my stuff is maintained on our revision
control system, which is backed up nightly. It also has the advantage
that if I'm setting u a new system, or owrking on a different server, I
can just do a checkout and all my files are there with the latest
version. I also have control over who can access the repository, so I
can grant/revoke access to others on the team. So, I get

1. automatic backup of everything
2. Easy access from any server
3. Ability to share the data
4. An audit trail for changes

The last two are very useful. If I'm away or off sick, important
info/scripts are not locked away on my deskto where others can't get to
them. Also, when I return, provided team members have checked in
changes (and they are required to), I can see what has been changed and
check nothing bad has occured. Using the revision control system also
makes it possible to have a level of peer review, which think is
important as it helps catch mistakes earlier and ensures we have less in
the way of separate silos of key knowledge only known by one person etc.

Highly recommend using a revision control system. Doesn't really matter
which one. I like GIT, but some find it conceptually challenging.
Mercurial (Hg) is very similar, but apparently a bit more user friendly.
Bazaar (bzr) is also pretty good. Even subversion is better than
nothing!

Tim
--
tcross (at) rapttech dot com dot au

On Jun 17, 3:34*pm, Tim X <t... (AT) nospam (DOT) dev.null> wrote:


Since I can't get sign-off on any of this from my boss, and indeed,
can't convince anyone a DBA is necessary, and am working under a RAD
system where vendor people can get authorization to do all sorts of
strange stuff without telling me about it, I keep everything on
subfolders on the server where I can simply search for stuff when I
need it, and be sure it is backed up, and be sure the rc scripts bring
everything up right with no attention. If others are too clueless to
read a script, not my problem (until I have to fix it when I come back
from vacation). I habitually modify dangerous scripts to start with
an exit.

I have recently been able to document a couple of problems created
more than 10 years ago by doing it this way, should you be laughing or
shaking your head at this.

jg
--
@home.com is bogus.
"A quality DBA are the ones where the bosses ask 'What does that guy
do anyway? We never have any problems with the database.'" - Chris
Taylor

joel garry <joel-garry (AT) home (DOT) com> writes:

Both! Been there and had this fight. Never understood why anyone would
resist using version control. It has next to no additional overheads and
gives you so much for so little. When I first started trying to get it
adopted where I currently work, I had two problems. One group who were
resistant (fear of the unknown I suspect) and another group that wanted
to ove engineer its use and came up with an amazingly complicated
procedure involving multiple branches, tags and all sorts of process
overhead. As a consequence, my first attempt failed.

I left things for a while and then tried again. This time, I insisted on
a very light weight, minimal process. This time was successful. After a
while, once everyone got use to it and understood it better, we defined
slightly more complex procedures surrounding how it is used.

We now have everyone using it. The great thing is, in addition to basic
version control, we use it for peer review, have a semi automated
'gatekeeper' process that ensures code doesn't get into the
mainline/trunk branch until it has been properly signed-off, have a much
more reliable promote process and better bug management. It is even
integrated with our issue tracker. Management now wouldn't be without it
as they have a much better way to gauge how things are going and our
processes are more reliable. Developers now actually like it because it
has actually made their life much easier.

My recommendation would be to just start using it. If you use something
like git/bazaar/mecurial, there is no sys admin or centralized
management required. You can just use it on your own system. At least
you can benefit from it. You don't even have to modify your current
process that much. All your files, scripts etc will still be laid out as
they are now. The difference will be you have a history of changes, logs
indicating why, what and when things changed and you can 'push' the
whole thing to another system as an easy backup. Many of the latest
generation distributed version control systems run on multiple
platforms, such as Linux, Windows and Mac.

If your using any Linux systems, there is a nice package called
etckeeper, which uses git/bzr/mecurial/darcs to version control all your
files under /etc. This utility is hooked intot he package management
system, so you don't even notice it there - until you need it. There has
been a number of occasions when I've forgotten that a config file was
modified for local requirements, have updated its package and allowed
the config files to be overwritten by new defaults provided by the
package. Rather than having to reconfigure by hand, I can either revert
back to the previous version or merge the new and old.

Tim


--
tcross (at) rapttech dot com dot au