Need DBA Best Practices/Guidelines

[pheffley]

You know how every so often you're asked to do something way beyond your realm of responsibility? Well, I've been asked to put together standards for the DBA's in our organization. The current standards are very general, out of date, and only cover the basics like naming conventions. I need resources or ideas on where to find this information.

We use several database platforms (DB2, Oracle, SQL Server, etc) and the suggestion is to create one enterprise standard for all platforms if possible. For example, we should limit all table/column names to 18 characters due to the limitations of DB2. I have no idea if this is possible and would appreciate some feedback from those who do have a clue.

Thanks,

Paul

 

[Dimandja]

Hi pheffley,

Your question is still being debated in every software organization. It is not easy to design standards that everyone will agree with. But, it is possible to get your shop organized. And that's the key: organization and consistency.

The answer to your question will easily covers several books. Here, I'll limit myself to one aspect of organizing your database.

Basically, you should have three databases for each application:

1. Production database: very secure.

2. Test/QA database: very secure with backup datasets. This database is used to test software changes and will regularly have to be refreshed with predictable data.

3. Unit test database: programmers "playground". This database is used at the discretion of programmers. They will regularly need to populate it with test data. For security, test data should not be obtained from the production database.

This is only a little something to start with.

Dimandja

 

[JeremyNYC]

On a more general level, if you're faced with something you think might be over your head, the best thing to do is often to break it down in _lots_ of little steps.

The outline tool in Word has always helped me a lot when working on things like this. Just think about what you have to write one bit at a time. Keep adding to your list of items to be covered, shifting them around until you get a logical heirarchy, and then bite off one piece at a time. There will be plenty of pieces that you're not prepared to write, but because you've segmented the work, you will be able to go to others with very specific questions, and get usable responses from them.

Jeremy

==
Jeremy Wallace
AlphaBet City Dataworks

http://www.ABCDataworks.com

Access Databases for Non-Profit Organizations

Please post in the appropriate forum with a descriptive subject; code and SQL, if referenced; and expected results. See thread181-473997 for more pointers.

 

[willir]

pheffley

ISO this, ISO that !!!

I volunteered for a non-profit health centre, and helped lead a team through their first certification. I also participated in a few other ISO certication / recertification processes. Here are a couple of general things to consider from my school of hard-knocks...


- The document will evolve. It is a living document subject to change as you learn to do things better, or new technology is intorduced. As you learn, you can go back an change existing policies. So don't consider this the be-all-to-end-all type of document. If specifications on security are too lax, or too severe, you can go back and change them.

- The document will need to be reviewed periodically. Your comment about the existing manual being out-of-date is very typical. When documenting your procedures, also plan on how you will review and keep them current. Including a section - to be reviewed every six months at the top of the document may seem okay, but what will you say six months from now!

- for the main policy documents, try to generalize in most areas, but when specifics are required, be specific. This goes back to the review step. Having to change an entire document and get the change authorizated on minor technicalities can be a real waste of time.

- Reference external documents. This is where you can include the detail.

As per management, hey you got the tools. Put together a database that references linked documents, includes the review date, ownership, comments, etc. And provide some categorization codes so the users can quickly find their documents. For example, "global" for use of global variables. "array" for best practices on sizing / resing an array. "api" or "libaries" for any shared libaraies, etc. "security" on security polices. Development, testing, deployment, naming conventions, connection rules, backups, etc. Using a database as a tool helps with the review process, and will help the users reference the procedures in a simpliefied manner -- much easier than flipping pages in a binder.

As Dimandja stated, there are books and books on this. And as Jeremy stated, work at it at a chunk at a time with the realization that the outcome will be a living document.

Richard