Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Part 1: The Database Administrator's Primary Responsibility Expand / Collapse
Author
Message
Posted Monday, September 14, 2009 12:30 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
Comments posted to this topic are about the item Part 1: The Database Administrator's Primary Responsibility


John Sansom (@sqlBrit) | www.johnsansom.com
Post #787192
Posted Monday, September 14, 2009 3:12 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Yesterday @ 4:56 AM
Points: 268, Visits: 877
Well said John. A simply stated and accurate introductory topic.

Can I hazard a guess that part two is on how to implement an effective and tested backup and recovery strategy?

Tim


.
Post #787257
Posted Monday, September 14, 2009 3:53 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
Hi Tim,

Thanks for the great feedback.

Your psychic powers may have eluded you on this occasion but I guess you will just have to wait and see

Cheers,



John Sansom (@sqlBrit) | www.johnsansom.com
Post #787281
Posted Monday, September 14, 2009 4:54 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, March 19, 2014 1:27 AM
Points: 2,366, Visits: 1,837
I will wait for the next part.

"Keep Trying"
Post #787320
Posted Monday, September 14, 2009 8:40 AM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, April 14, 2014 8:02 AM
Points: 68, Visits: 264
Unfortunately it is not always us “Acidental DBAs” that need convincing. That manager you talked about needs convincing that buying SQL is not a panacea in itself. As a result time needs committing to managing the system and/or tools need purchasing to assist in the management on numerous instances.
Post #787510
Posted Monday, September 14, 2009 10:29 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
PAH (9/14/2009)
Unfortunately it is not always us “Acidental DBAs” that need convincing. That manager you talked about needs convincing that buying SQL is not a panacea in itself. As a result time needs committing to managing the system and/or tools need purchasing to assist in the management on numerous instances.


An excellent point!

As Database Administrator’s, we have a responsibility to ensure that we communicate effectively to management regarding the implications of both our actions an inactions.




John Sansom (@sqlBrit) | www.johnsansom.com
Post #787599
Posted Monday, September 14, 2009 10:50 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, August 02, 2013 3:23 PM
Points: 23, Visits: 59
I'm a DBA in New Orleans, LA, and I work for the Health Sciences Center. I concur that data is extremely important and guarding it with valid backups is one of the most important duties of a DBA. Our data center was located in New Orleans during Hurricane Katrina, and we did not have access to it for over a month. We had to setup our infrastructure from scratch. Had we not been prepared with valid backups, hospitals and schools would not have been able to operate correctly and efficiently. We worked day and night to get things up and running, and we were able to successfully do so. Now we have a complete production system offsite, and we are even better prepared, if we ever have another disaster.


Post #787615
Posted Monday, September 14, 2009 11:28 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, January 30, 2014 1:12 PM
Points: 13, Visits: 1,007
This article is great.. I will follow it as I will need it.

In my case I've been a Data Analyst in my previous positions until now. My manager came to me last week and asked how I felt about taking over the SQL Server responsibilities for the organization, I work in Health care for an Organ procurement organization. Not really knowing what I was getting myself into I said sure, I've reading online books trying to get as much help as possible to cover all of my basis and this article i think will be good.
Post #787633
Posted Monday, September 14, 2009 11:35 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, April 10, 2014 6:15 AM
Points: 344, Visits: 1,530
smeye1 (9/14/2009)
I'm a DBA in New Orleans, LA, and I work for the Health Sciences Center. I concur that data is extremely important and guarding it with valid backups is one of the most important duties of a DBA. Our data center was located in New Orleans during Hurricane Katrina, and we did not have access to it for over a month. We had to setup our infrastructure from scratch. Had we not been prepared with valid backups, hospitals and schools would not have been able to operate correctly and efficiently. We worked day and night to get things up and running, and we were able to successfully do so. Now we have a complete production system offsite, and we are even better prepared, if we ever have another disaster.


Your experience demonstrates first hand not only how important data is but also how essential it is to have a Disaster Recovery strategy in place.

Thanks for sharing it with us.




John Sansom (@sqlBrit) | www.johnsansom.com
Post #787636
Posted Tuesday, September 15, 2009 1:58 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, February 28, 2014 1:54 AM
Points: 171, Visits: 229
I think something that is often missed is monitoring - people set up lots of lovely processes and systems, backup plans, etc.etc. - but then they (or management, or management don't allow them to...) fail to monitor if what they set up works, backs up ok, restores, monitor the data for quality and issues, etc. etc.

Case in point somewhere not so far from where I sit, where an entire years worth of work was lost for a couple of thousand people when a raid system failed. The official word was that they had `had a failure on all 3 levels of their backup systems`. The raid failed, its backup systems failed, and the daily backups being made failed.

The actual word was actually that the backups failed as no-one had made any backup's for over a year. No-one checked the backup's were being made, what was happening to them, if they worked, what the person responsible for making the backups was doing, etc.etc.etc.

I think management often like to fire and forget - i.e. buy in something, get it set up and installed and then assume that it will magically take care of itself. Resources can then be moved onto other things. (Even if those resources kick up a fuss about it :) ). Certainly in my experience anyway!

M.
Post #787964
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse