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»»»

Where are all the MVBs? Expand / Collapse
Author
Message
Posted Saturday, September 24, 2011 4:50 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: Administrators
Last Login: Thursday, August 28, 2014 5:25 AM
Points: 569, Visits: 1,018
Comments posted to this topic are about the item Where are all the MVBs?
Post #1180501
Posted Saturday, September 24, 2011 7:33 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Sunday, October 6, 2013 9:36 AM
Points: 568, Visits: 309
Tony,

It is definitely a community effort. I have been through most of those in the past 7 years as a DBA and it was a community effort just within my organization. Everyone from Hosting Operations, DBA's, Software Developers, Information Security, Individual Business Line Managers to Sr Management was involved. Not easy and not perfect but well worth the effort as things are much easier now and fairly standardized and documented.

The best piece of advice I could give is to just start somewhere. Like you said, start with backups (or better yet restore) policy as I would bet no DBA has been fired for having a good backup policy/system. Then branch out based on need and importance. Finally, would be glad to help out the community.

Thanks

SJ



Accepting all invites
Post #1180505
Posted Saturday, September 24, 2011 8:37 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:41 AM
Points: 42,827, Visits: 35,957
I suspect that they all were driven insane by bureaucracy and red tape and retired to desert islands.


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1180510
Posted Saturday, September 24, 2011 9:51 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 1, 2014 9:55 AM
Points: 201, Visits: 404
I like this idea! Having a body of knowledge that can be applied to these situations will be a great resource.

IMHO: Steer away from the term "best practice". There are multiple "good" practices that may be a better choice given the business situation. Some companies will blindly apply the "best practice" and ignore other practices that may be a better fit for their situation. Having multiple well thought out papracticesnd the reasons you would want to choose one approach over another would be a huge benefit.


--Paul Hunter
Post #1180523
Posted Saturday, September 24, 2011 10:07 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, April 14, 2014 3:09 PM
Points: 4, Visits: 43
i came into database work from a pretty indirect path - i'm a former psychologist who had to do some data analysis. Querying data led to tuning queries which led to database optimization. i'm much more knowledgeable about the development end of db work - much of the admin work was in place when i started, so i've never had to design or implement much in that space. Though i've learned enough to do a reasonable job, i'd never claim that i know what i need to document to do a meaningful job of it, or that i know useful, effective means to organize and present that information. I would be happy to participate in a team effort to build out templates.
Post #1180526
Posted Saturday, September 24, 2011 1:49 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 9:58 AM
Points: 36,995, Visits: 31,517
Whereas there are plenty of experts prepared to help with the technology, few seem to come forward when the struggle is against the bureaucracy rather than a recalcitrant server.


I have to agree with Gail on this one.

To put my own slant on what she said, I believe that a lot of excellent DBA's have simply tired of the fight with stupid people (as in people who don't know better but won't listen, either). A DBA has to respect everyone's budgets for both money and time no matter how ridiculous such budgets may seem. I believe that most DBA's worth their salt all have fought and, maybe, still fight for doing things the "right way" such as using stored procedures instead of T-SQL embedded in supposely "managed code".

But constant fighting with people who simply will not listen is a bit like water torture... even the best can only take so much. So they either find a job where people will listen (totally negating the need for tools, such as a book, to fight the bureaucracy) or they simply stop fighting because it doesn't get them anywhere even when such tools are available. They resign themselves to people doing stupid things, clean up the mess (they're usually smart enough to expect "the mess" and have prepared for it) when something goes wrong, and maybe even have the pleasure of occasionally telling someone "I told you so."

As honorable a task it may seem to be, we don't need yet another book for DBA's. The good ones already know what needs to be done and how to do it. What we really need is a book to teach managers that "If you want it real bad, you'll normally get it that way." We need a book of real stories where poor planning, shortcuts, and omissions taken to meet some bloody schedule or budget contrived during a conversation on the golf course or in an elevator have caused major catastrophes or serious "Black Eyes" in the eyes of customers. We need them to understand the differences between front-end code and what databases are really all about. We need to scare the hell out of them with the truth that they apparently can't see now.

To me... a lot of DBA's have become like old folks (a serious compliment, actually). They really know how to get things done but everyone thinks they're hard of hearing and possibly mute. They're really not... they're just tired of listening to stupid things and speaking to deaf ears.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1180550
Posted Saturday, September 24, 2011 3:25 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:41 AM
Points: 42,827, Visits: 35,957
Jeff Moden (9/24/2011)
To put my own slant on what she said, I believe that a lot of excellent DBA's have simply tired of the fight with stupid people (as in people who don't know better but won't listen, either). A DBA has to respect everyone's budgets for both money and time no matter how ridiculous such budgets may seem. I believe that most DBA's worth their salt all have fought and, maybe, still fight for doing things the "right way" such as using stored procedures instead of T-SQL embedded in supposely "managed code".


That's one nice thing about been a consultant. When the budgets are stupidly low or the client is doing exactly the opposite of what's advised I can walk away and tell them to call me when they get realistic (and I've done that once)

We need a book of real stories where poor planning, shortcuts, and omissions taken to meet some bloody schedule or budget contrived during a conversation on the golf course or in an elevator have caused major catastrophes or serious "Black Eyes" in the eyes of customers. We need them to understand the differences between front-end code and what databases are really all about. We need to scare the hell out of them with the truth that they apparently can't see now.


I promised Tony an article on just that (based on my time with the "Client from Hell"). Just have to find the time to write it.

I doubt it'll change anything though. The people that most need to read it won't or won't believe that it applies to them.

One thing I noticed at the Client from Hell was that the IT manager stuck to her snap-decisions and poor processes even when references and books and industry authorities had been quoted and provided that explained (with reasons) that her chosen path was a poor one.

I got so sick of her 'time estimations' at one point that I loaned her my copy of "Software Estimation: Demystifying the Black Art" (which, come to think of it, I never got back). I saw her reading it a couple of times. She didn't change.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1180557
Posted Saturday, September 24, 2011 4:25 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 9:58 AM
Points: 36,995, Visits: 31,517
GilaMonster (9/24/2011)
That's one nice thing about been a consultant.


Heh... and, oh, how I miss that. And, yes... I agree... the wrong people would read the book. After all, the particular "Managers" who really need to read such a thing won't because they already "know" it all.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1180560
Posted Sunday, September 25, 2011 5:33 AM


SSC-Enthusiastic

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

Group: General Forum Members
Last Login: Monday, June 30, 2014 7:23 AM
Points: 121, Visits: 296
I don't know if SSC could add a Wiki to the many useful categories already present but I've used Zoho Wiki for my own personal good practice notes for years. It takes effort but I use it regularly. Perhaps SSC can add some Wiki functionality.

I agree about good not best practice. Having worked for big and small organisations as well as not-for-profits and corporates I've had to adjust to reflect the needs and budgets of the organisation.
Post #1180621
Posted Sunday, September 25, 2011 9:58 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, June 20, 2013 10:39 AM
Points: 3, Visits: 137
Well put Jeff You had mentioned most of the items that I have been through last 10 years. After few "told you so"; I am now being called in few applications in the design phase. Good improvement.

I would say, DBA's has to be involved right from the design phase or the project kick off phase. Most of the instances, I had been called when there were system slowness or not working, but in my company things are changing a bit after few years of shouting:)

DBA's need Wiki's so we can point out to others of standard best practices as well as recheck them when needed.

Addition to best practice list
Out of gate monitoring on the entire system and SQL Server, immaterial of the critcality or availability needs
Retirement plan for server


Post #1180718
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse