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

Current Membership

Latest: ABurchfie
New Today: 169
New Yesterday: 202
Overall: 130733

People Online:
Visitors: 157
Members: 3
Total: 160 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


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
Jugami
Newbie
Newbie


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!

Thanks!
Nick
Back to top
View user's profile
ARoll
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.
_________________
Adam
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
Fabien
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
_________________
BR,
Fabien Papleux

Accenture
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
alphasong
Itiler


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.

Charlie
_________________
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 http://www.nukecops.com

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.