Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: uviju
New Today: 33
New Yesterday: 31
Overall: 231537

People Online:
Visitors: 105
Members: 0
Total: 105



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Changes to Databases
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Changes to Databases

Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message

Joined: May 01, 2007
Posts: 1

PostPosted: Mon May 14, 2007 11:15 pm    Post subject: Changes to Databases Reply with quote

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!

Back to top
View user's profile
Senior Itiler

Joined: Apr 10, 2006
Posts: 86
Location: Boise Idaho

PostPosted: Tue May 15, 2007 1:14 am    Post subject: Reply with quote

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.
Practitioner - Release and Control
Blue Badge

"Not every change is an improvement, but every improvement requires a change"
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Senior Itiler

Joined: Sep 27, 2005
Posts: 207

PostPosted: Tue May 15, 2007 5:58 am    Post subject: Reply with quote

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 Wink
Fabien Papleux

Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger

Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Sat Jun 02, 2007 6:37 am    Post subject: Yes DBAs can be difficult - with good reason Reply with quote

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 $ Smile )

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.

Charles T. Betz
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.