Changes to Databases

[Jugami]

I am looking for some input/experience regarding changes made to databases. We currently don't have databases as CI's in our CMDB. I have never been a DBA. I am looking for some idea on what actions performed on a database should require an RFC and within that, what kind of changes would be considered standard and which would be basic. Our definition of standard and basic is based on the ITIL defintions. We are getting a lot of push-back from our DBA's and I want to be sure that we are not creating any unnecessary work for them but at the same time not allowing them an unwarranted exception.

Any suggestions would be appreciated!

Thanks!
Nick

[ARoll]

DBA's.....oh the challenge =P Far as types of changes that will need to be recorded, and mind you i'm not a database person either, but schema's, adding columns, removing columns, column properties(seen this go down in flames). These types of things primarily would be minor and would go through the normal process. Probably the biggest push back from their view is in regards to direct data changes, simple sql statements. This, pending your organization i'd put under the standard change. In my former life, we had standard changes setup for direct data changes on specific databases. Each database had its own standard change and specific sets of sql statements that would be run just certain details would change pending on the specific correction that was being made. This way we had the record of who changed what, when and why. For our auditors this was very important, specially when it came to dealing with financial corrections. This is one approach but let me know if this at least makes a semblance of sense.
_________________
Adam
Practitioner - Release and Control
Blue Badge

"Not every change is an improvement, but every improvement requires a change"

[Fabien]

I take any sort of change as a significant change until such time that a shortcut can be defined, through a change model.

So, for instance, I have just finished a specific model to request metadata changes to databases in general. It is a simplified change with double approval process. We are programming it in a workflow solution and getting an SOP ready. We'll roll out in about 2 weeks.

Different changes to different databases supporting different applications and services may have different requirements. Design your significant change process with all the input you need/can. Then meet with application owners and DBAs to "help them simplify the process for their usage"... it sells
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek

[alphasong]

I have been a data architect, joined at the hip with operational DBAs. Yes, DBAs can be prickly, because people generally don't have a good understanding of what they do, which is arguably the most critical operational role in all of production IT. (That's why DBAs make the most $ )

Basic principles:

- Databases at the catalog level should be CIs
- It would be nice if CMDBs tracked lower level information about databases, but I have never seen a CMDB that handled schema, table, or column information. This is the domain of the metadata repository.
- Changes to database structure (new/changed schemas, tables, columns) and indices should be under change control. (Re-indexing a database can be catastrophic if mis-handled.)
- Changes to rows generally should *not* be under change control - this is core application functionality. Within SQL generally, you need to understand the distinction between DDL (Data Definition Lanaguage) and DML (Data Manipulation Language). DDL = always change control. DML = mostly not. Audit requirements are designed into the application and database hisotory structures themselves.
- Changes to runtime parameters (resource tuning, etc) *might* be under change control.
- Some tables contain application configuration data (e.g. 4GL systems like PeopleTools and Remedy ARS itself) that *must* be under full change control - the application's functionality is defined in terms of this data, down to the appearance and behavior of panels. But typically in 4GL-ish systems such tables are *very* clearly distinguished from the data tables.

In production fix situations, where DBAs are proposing applying direct, raw SQL fixes against live systems (even purely DML), such activities may be under change control. The criticality of the fix must be weighed against the change control pre-approval, testing, and definition of backout scripts. This is where databases get clobbered and companies go belly up.

For further information see the dm-discuss list on Yahoo. That's where the experts hang out.

Charlie
_________________
Charles T. Betz