Production Database Releases - Worst Practice
-
I thought I should share with the community a recent event that has come across my desk. A fairly new DBA (and I use the DBA definition loosely), is responsible for a fairly important database that is used Nationally. He was recently involved in a production release. This is how it was done.
1. Developer notified DBA to announce production release.
2. DBA detached the Production database and emailed the database to the developer.
3. Developer updated with scripts etc and emailed database back to DBA.
4. DBA reattached the database.
While I consider myself to be an intermediate DBA with 3-5 years experience, I would have picked this up when I first started as being very, very bad practice.
Any thoughts or are you all having to pick yourselves up off the floor first!!!
-
You got to write an article about this. I'm sure you can win an award or something!!!
No need to point out that this is a bad idea. Not even a worst practice. A worst practice is something that works to do some task. But it usually does NOT involve stopping the application altogether.
-
Um... no, that's pretty terrible.
-
Put him through the ITIL Foundation course quick!!
-
Im not sure what to call that other than bad.
Biggest reason I've seen companies do stuff even close to that is that the developers dont do a good job of tracking changes, so no good way for them to do change scripts. Using a diff tool solves the whole problem simply in my view, on the dev side I dont want to keep track of my changes either, its just busy work when a tool can figure it out.
-
Why don't you send it to worsethanfailure.com?
-
Lots of problems here. Breaks SOX, so if you're public, this gets you an audit failure.
Time between detach and attach? Downtime for sure.
Testing? Developers can't test, or at the least, don't want do and don't do a good job.
Not a worse practice (having developers deploy directly to production themselves probably is here), but definitely down the list as far as options I'd choose.
-
I just couldn't believe it when I found out, and have since informed our CIO who has immediately put a stop to the practice.
Still can't quite get my head around how someone could ever think this was an OK solution!!
-
Then again, this is the same DBA who has not removed AdventureWorks from the production environment and is backing it up daily.
Also, there are no system database backups and all backups reside on the same Raid as the databases!
I rest my case!!
-
This sounds like a job for "SQL Compare" and "SQL Data Compare".
Have a good day,Norene Malaney
-
Sounds like the job for a new DBA.
Or at least some training.
-
Can you imagine what would have happened if that email had been intercepted by a malicious user / hacker?
YIKES!!!
-
What if a cumstomer needs to create a report? What if two customers want to create a report at the same time? And then theirs the Auditors.
-
For me, what would be interesting is people responding with their best practice to solve this situation.
Here's what I think,
The DBA receives from Development the scripts to update the database.
The DBA determines when the update is to occur, for example a standard maintenance window, or an emergency basis; then notifies the users that there is going to be a change on a certain date and time.
At that time the DBA determines if there is any users logged on and uses a standard method to get them off. (What suggestions to people have to do this?)
The DBA backs up the database (original backup).
The DBA uses the scripts to update the database.
The DBA backs up the database and releases it to production telling the user community that change has been successful.
If the database is not successfully updated then the original backup is used to get things back to where they were and the problem is reported to development and the user community notified that the application is available again.
Steve
-
Steve,
Unfortunately, even that practice wouldn't fly at my work place. Everything must go through a rigorous SDLC. We put things into Test, have the BAs test it. We put it through Test again, have the Business Unit test it, we put it in QC, have everyone test it to make sure all the bugs were fixed the last two times it was in Test (if not, it goes back to Development then) and finally, after everyone has signed off on it, it goes into production via the procedure you listed above.
Excepting of course, that we tell the users to be off a good 15 minutes before the release. If they aren't, their Citrix sessions are terminated by the server team and any remaining direct SQL Logins are killed. We Snapshot the database (I LOVE this new snapshot tool) and then implement the changes, falling back to the snapshot and starting over again if we make a mistake.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply