SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Where are all the MVBs?


Where are all the MVBs?

Author
Message
Tony Davis
Tony Davis
SSC Eights!
SSC Eights! (899 reputation)SSC Eights! (899 reputation)SSC Eights! (899 reputation)SSC Eights! (899 reputation)SSC Eights! (899 reputation)SSC Eights! (899 reputation)SSC Eights! (899 reputation)SSC Eights! (899 reputation)

Group: Administrators
Points: 899 Visits: 1159
Comments posted to this topic are about the item Where are all the MVBs?
swjohnson
swjohnson
SSChasing Mays
SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)SSChasing Mays (654 reputation)

Group: General Forum Members
Points: 654 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
GilaMonster
GilaMonster
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86270 Visits: 45232
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, MVP, M.Sc (Comp Sci)
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


SQLNightOwl
SQLNightOwl
Old Hand
Old Hand (366 reputation)Old Hand (366 reputation)Old Hand (366 reputation)Old Hand (366 reputation)Old Hand (366 reputation)Old Hand (366 reputation)Old Hand (366 reputation)Old Hand (366 reputation)

Group: General Forum Members
Points: 366 Visits: 510
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
John Kauffman
John Kauffman
Forum Newbie
Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)Forum Newbie (4 reputation)

Group: General Forum Members
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.
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)

Group: General Forum Members
Points: 84687 Visits: 41069
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
GilaMonster
GilaMonster
SSC Guru
SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)SSC Guru (86K reputation)

Group: General Forum Members
Points: 86270 Visits: 45232
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, MVP, M.Sc (Comp Sci)
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


Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)SSC Guru (84K reputation)

Group: General Forum Members
Points: 84687 Visits: 41069
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
MonkeyMan
MonkeyMan
SSC-Enthusiastic
SSC-Enthusiastic (131 reputation)SSC-Enthusiastic (131 reputation)SSC-Enthusiastic (131 reputation)SSC-Enthusiastic (131 reputation)SSC-Enthusiastic (131 reputation)SSC-Enthusiastic (131 reputation)SSC-Enthusiastic (131 reputation)SSC-Enthusiastic (131 reputation)

Group: General Forum Members
Points: 131 Visits: 329
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.
Saravanan-429478
Saravanan-429478
Forum Newbie
Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)Forum Newbie (3 reputation)

Group: General Forum Members
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 shoutingSmile

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

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search