Where are all the MVBs?
-
Comments posted to this topic are about the item Where are all the MVBs?
-
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
-
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 recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
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
-
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.
-
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.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
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 recoverabilityWe walk in the dark places no others will enter
We stand on the bridge and no one may pass -
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.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
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.
-
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
-
While I agree with the cynical bits about never getting agreement from the exact people who are the biggest block in getting the job done, I also think Tony's request for an outline of policy areas, for new and aspiring DBAs, is a good idea.
I also think a wiki would be the easiest way to get it done.
Could start with just "you'll need policies on backups, downtime, hardware requirements/configuration, security/auditing, DAL/DB APIs (procs vs inline code vs isolated DAL), coding standards, data access (possibly including PCI compliance), data retention (PCI again), patching, dev-to-prod path, on-call schedules, source control/change tracking, and beer popsicles", just to start out. Easy to expand from there, since I'm sure I missed a few of the top-level things. With those in place, it would be a matter of stubbing out some suggested policies based on shop-size, et al. If each policy is defined on the main page, and links to details, it would be easy to read and learn from.
Make it operate under a beerware license, so anyone can copy-and-paste into their own document for internal editing and use, and you're good to go.
I think anything other than a wiki is going to require too much editorial oversite to coordinate. It can be locked down to approved authors only, and probably should be, but there should be open comments (moderated, of course).
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
-
GSquared, I think you've laid it out nicely.
What about changes as time went on. As things change would the wiki be versioned? or just updated to keep in line with the most recent?
-
Brandon Leach (9/27/2011)
What about changes as time went on. As things change would the wiki be versioned? or just updated to keep in line with the most recent?That'd be up to the authors and admins/editors, I guess.
Most wiki software keeps version tracking.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
-
Hi Everyone,
I've read through this article and the varying posts from personal experience, work trends to wiki suggestions. It seems to me that this article has presented the same thing that it is written about, discussion with no solution. It would seem to me, as a productive stand point that if each individual would've posted one template on a specific topic i.e. backups, security, etc then the solutions for having good overall practice and policies would've been answered.
Just as a thought. I'm currently going through this very process and it is as we all know "chains and whips, whips and chains."
as I make my way through this process I'll begin to post my templates. Though they may not be spectacular maybe someone out there will find them useful.
Some do, but most don't and that is all there is too it. That is why I am I, and wish that I wasn't
-Eyore on Franz Kaufka- -
"This report, by its very length, defends itself against the risk of being read." (Winston Churchill)
The problem with policies and procedures is summed up by the Winston Churchill quote above.
I think an intranet/wiki is a good place to start but there are a few gotchas. It is quite a skill to be able to do the following:-
1. Write something that is both useful and easily digestible
2. Structure information so it is easy to navigate
3. Categorise information so others find it is easy to find
When I write wiki entries I take the following approach
1. Start with a basic page that summarises the key points
2. Always include a "last updated date" and "last updated author" at the head of the document below the title
3. Always include a table-of-contents (preferably hyperlinked to the subject headers) and "quick links" before the first subheading
4. Always give a concise description of what the document is for so the reader can determine if it is going to contain something useful
5. Hyperlink to documents giving more detailed information about the key subjects.
6. On a child page always have a link back to the parent in the "quick links" if you don't have a bread crumb trail.
Accepting all invitesViewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply