I’m still settling in to my new position. One of the biggest changes for me is that I am no longer the sole DBA, which is nice. The other change is that we have a formalized change process in place and nothing can be done to production databases unless it has gone through this process. This is also very nice. However, with every plus, there is a minus. The minus that both of these pluses have is that they slow things down. When I was the sole DBA, I was used to coming up with a plan of action and doing it. Now, I have to run it by the other DBA then submit a change control approval form, which gets reviewed at a weekly meeting of department heads. For instance, as I wrote about last time, I discovered I needed to run DBCC CHECKDB WITH DATA_PURITY and DBCC UPDATEUSAGE on many of the databases here. Running it on the development and QA servers was not an issue and I could do that pretty much whenever. But before I could touch the production databases, I needed to go through the change control approval process.

It’s nice to be in a company that has an actual process defined and in use. The process requires me to describe the changes I need to make, how I tested them, create an implementation plan, a backout plan, and a checkout plan – how I will check to make sure whatever I did was done successfully. Now, for something like running DBCC, there is no backout plan and the checkout plan is simply to look to see if the command completed successfully. Thankfully, the weekly meetings are short. The one I attended today lasted 9 minutes.

If this was just paperwork for the sake of paperwork, I wouldn’t be able to stand it. But the real purpose of the change control process is communication. It’s a method to alert all departments of the company that something will be going on at a certain time relating to a certain product / program / server. When you are part of a large company with many different systems, this is important. As part of the process, I need to schedule a date and time for my work and at the meeting, all the changes are shown on a timeline, so you can see if anything might be going on at the same time that might impact you.

Right now, I’m still frustrated by the delays these processes inject into my work. If I was at my old job I’d have all this DBCC stuff done in two days. Here, it’s going on two weeks and will probably stretch to four. I’m working for a financial company and that industry is pretty much the definition of conservative. Even with all the above processes, I can’t do my work on all the production databases at once. I need to try it on some, see how it goes, then make a new change control request for the next batch of databases to be done at a later date. But I can’t complain too much. I have some of my own money invested with this company and, as a customer, this is exactly the sort of cautious, careful approach I would want them to take. I hope by the time I am done with this project, I’ll have recalibrated how I estimate the time it takes to perform tasks and will be less frustrated with delays.