August 18, 2009 at 9:04 am
edill (8/18/2009)
First of all, I am more of a developer than a DBA and while I understand and can work with SQL Server fairly well, I would never claim to have the level of skills that a full DBA would have.What more would the DBA's here like their developers to do?
whoah, How long have you got, maybe If i can find a developer who can send me a script that actually parses, that would be great improvement, or even if they bother to test it before they give it to me, that would be fantastic.
re-runable scripts, that is the biggest bug bear that i have, regarding scripts from developers. I should be able to run a script multiple times, repeatly if i want to, without harming either the schema or data. so the script must have a use [database], object creation checks and be able to undo data changes. that isnt much to ask, and I do appreciate it 😀
Anything else and I think I am pushing my luck some what 😛
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
August 18, 2009 at 9:06 am
Nice post Matt!
I am an executive who does not tolerate any "keys to the kingdom" funny business. In my career I have twice fired employees (DBAs) who played this game. Job security is not gained by keeping other coworkers from what they need to do their jobs, and I personally will not tolerate this kind of thing, and find it one of the most distasteful habits any worker can develop. So I would advise you first and foremost to ascertain whether or not this DBA is merely protecting his "empire", or truly worried about something it is not his area to be worrying about.
If this is something he is truly worried about, and his motives (though skewed) are honest, then you need to talk to your manager. I once again find myself astonished to have to state the obvious but - businesses run by all workers working together in the most cohesive and supportive manner. If you are not getting this, then the business has a problem and a manager should address that because the business is what feeds all employees.
All this said, the term "Administrator" in DBA does not mean that person administrates people, coworkers, employees in general or the public. They administer data. This DBA should be working FOR you, supporting your efforts, and assisting you where ever needed. Simply put, DBA's Serve - THEY DO NOT RULE. That is what executives and managers do. The DBA role can lead a person to a presumed arrogance that is beyond the business ethos and that is unacceptable!
I would suggest that if you are not getting support, full support from this DBA, you need to inform a manager. You should NEVER work anywhere where the "team" is really nothing more than a collection of small kingdoms with people pretending to be important because they withhold, obfuscate, and 'control' data - something you must have to do your job.
If you worked for me and came to my office and informed me of what I am gleaning from your post, I would be meeting with the DBA today - and by the end of that meeting he would be supporting you and all coworkers, or looking for a new job.
August 18, 2009 at 9:07 am
Clearly, I'm missing something. Either that, or I'm horribly spoilt. Just for clarification, we're talking about playing around on a development computer. A computer, disk (or disk array), an entire RDBMS that's isolated from the primary production system, and preloaded with simulation data, right?
What protection? There shouldn't be any real data in there. I come from an environment where for the past 15 years, the computer names of some computers was classified as top secrete. Likewise, the data in them, was sometimes Eyes Only. Creating bogus data took some consideration and review, but it's mostly a one-shot thing.
What are you protecting? Doesn't the DBA/System Admin have a ghosted (or eqivalent) image? I mean, hey, crash it, wipe it out -- hell, beat it with a stick, they just wipe it clean and start over.
Clearly, I'm missing something. I'm shocked that this is even debatable! Put me down for the developer has free reign on a development box. Especially developers that know little to nothing about database management, development, etc.
August 18, 2009 at 9:07 am
First, let me state that I'm a developer, not a DBA, so obviously I'm biased 😛
In the company I work for, DBA responsibilities are really spread out all over the place. Developers actually build pretty much all new database objects (tables, procs, etc etc), but the systems are reviewed by the people that will be supporting the code as well as "real" DBAs (but not in all cases if I'm not mistaken). In my opinion, we wouldn't be able to do our jobs as developers if we didn't have this freedom. Now I'm not talking about the QA, Staging, Production environment, strictly the true TEST environments.
I frequently talk to some friends in a sister company that have what's considered the DBA's dream. ALL database servers are completely locked down. If a developer needs a new database object, they request it and might see it days later if they're lucky, not because any PERSON is slow, but there's a lot of red-tape (prioritization, etc). This is EXTREMELY frustrating for the developer who has to hurry up and wait. I should mention that developers are locked out of more than just dev database servers. ALL dev servers are off limits. Now I undestand they're finally allowing the devs to us VMs at least, but in my opinion, although that protects the precious dev servers, it simply makes what the non-devs would consider the dev servers simply an extra, non-dev layer of servers between the REAL dev (the VMs) and production, and therefore completely unnecessary (expensive and completely wasteful to maintain).
I suppose the devs in my company probably have a lot more database background than the 'average' or 'pure' developer. Shoot, I read and occassionally post to this site afterall. To sum up my feelings on this topic, I favor letting devs take a stab at creating DB objects and guiding them when they do something horrid (and we do all the time). Like others have said, we won't learn anything unless we try it ourselves. And I know every project is different, meaning there is no 'right' answer. But for that reason alone, I believe that the always-devs-locked-out-of-dev-environments approach is wrong at least some of the time (if not the majority of the time).
August 18, 2009 at 9:07 am
with regards to locked down environements and open vs closed environemtns, we're trialling the new Policy feature in SQL 2008 so that all dev machines and databases meet a minimum acceptable standard, and that they are configured in the same way that Live environments are.
This includes Collation, Ansi Settings, Compatibility mode etc etc
a weekly inspection of this data gives us a heads up on any potential dev issues from misconfiguration, while allowing the developers flexibility.
MVDBA
August 18, 2009 at 9:19 am
rboggess (8/18/2009)
Clearly, I'm missing something. Either that, or I'm horribly spoilt. Just for clarification, we're talking about playing around on a development computer. A computer, disk (or disk array), an entire RDBMS that's isolated from the primary production system, and preloaded with simulation data, right?What protection? There shouldn't be any real data in there. I come from an environment where for the past 15 years, the computer names of some computers was classified as top secrete. Likewise, the data in them, was sometimes Eyes Only. Creating bogus data took some consideration and review, but it's mostly a one-shot thing.
What are you protecting? Doesn't the DBA/System Admin have a ghosted (or eqivalent) image? I mean, hey, crash it, wipe it out -- hell, beat it with a stick, they just wipe it clean and start over.
Clearly, I'm missing something. I'm shocked that this is even debatable! Put me down for the developer has free reign on a development box. Especially developers that know little to nothing about database management, development, etc.
The problem with treating the dev environment as an "anything goes" playground is that it can mess up other devs.
If, for example, you have two devs who are working on solutions that will both access the same table, and one of them starts creating and dropping indexes, or even columns, it can easily mess up the other dev.
That's why I like each to have a separate playground where they can do whatever they want without messing each other up. If you only have one or two devs, then a single playground dev box might work, but it also might not. Separate copies of SQL Dev Edition, either on their workstations or on virtual machines they have access to, will definitely work.
Then, once they're happy with their individual solution, they roll it into dev, and collaberate on how to make all the solutions being worked on play nicely together. That's the pupose for the dev box, to take code that you know will work and put it where others can critique it or coordinate with you on it.
That's a great point to be able to have two teams look at each other's index needs and you can end up with things like, "if you add this one column to that index, it'll cover what we need as well as what you need", and similar coordination.
Once it works in dev, it's up to the (senior) DBA to move it to a test environment where it can be run and tested and reviewed and is still considered to be in a state of relative flux.
Once you're happy with it in that test environment, after it's probably gone back and forth a few times between devs and DBAs and has usually been significantly improved, and it's in a state where everyone agrees it's ready for production, then it goes to QA.
QA should be an exact replica of the production servers, as much as possible. In QA, it is run over a period of time and unexpected side-effects are looked for. Multiple solutions can be loaded onto QA over a period of time, to see how well they work with each other. At this point, it's expected that NO changes will be needed to the code, but it's a last chance to be sure it's okay before rolling it out fully.
Once QA has proven that the code works well in all known circumstances and is stable and reliable, and can deal with all the events that normally take place on the production servers, then it is finally rolled out to production.
That's the sequence I prefer. I don't often get to implement it fully, but it works and it works well.
- 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
August 18, 2009 at 9:22 am
blandry (8/18/2009)
Nice post Matt!I am an executive who does not tolerate any "keys to the kingdom" funny business. In my career I have twice fired employees (DBAs) who played this game. Job security is not gained by keeping other coworkers from what they need to do their jobs, and I personally will not tolerate this kind of thing, and find it one of the most distasteful habits any worker can develop. So I would advise you first and foremost to ascertain whether or not this DBA is merely protecting his "empire", or truly worried about something it is not his area to be worrying about.
If this is something he is truly worried about, and his motives (though skewed) are honest, then you need to talk to your manager. I once again find myself astonished to have to state the obvious but - businesses run by all workers working together in the most cohesive and supportive manner. If you are not getting this, then the business has a problem and a manager should address that because the business is what feeds all employees.
All this said, the term "Administrator" in DBA does not mean that person administrates people, coworkers, employees in general or the public. They administer data. This DBA should be working FOR you, supporting your efforts, and assisting you where ever needed. Simply put, DBA's Serve - THEY DO NOT RULE. That is what executives and managers do. The DBA role can lead a person to a presumed arrogance that is beyond the business ethos and that is unacceptable!
I would suggest that if you are not getting support, full support from this DBA, you need to inform a manager. You should NEVER work anywhere where the "team" is really nothing more than a collection of small kingdoms with people pretending to be important because they withhold, obfuscate, and 'control' data - something you must have to do your job.
If you worked for me and came to my office and informed me of what I am gleaning from your post, I would be meeting with the DBA today - and by the end of that meeting he would be supporting you and all coworkers, or looking for a new job.
Had to reply, cannot quite understand the attitude of management, as stated before I have been developer and dba for a long time. and there are valid justifications for some organisations and dba's to be protective about access, some companies and dba's are quite relaxed, but very few developers are fired for bad coding, and yet I know quite a few dba's who have been fired for screwing up.
Simply put, DBA's Serve - THEY DO NOT RULE. That is what executives and managers do. The DBA role can lead a person to a presumed arrogance that is beyond the business ethos and that is unacceptable!
I find that quote quite unacceptable personally, when an manager thinks he can tell me my job, I know it is time to move on. not a big fan of people who think their role makes them the knight in shining amour, who feel they have to protect employees from others.
Forgive me for my presumed arrogance, But being a DBA is one of the most technical roles you can be IMHO and that confers great responsibility and trust. It is our duty to help others and serve as the guiding light to other employees. I dont need an executive or management to point that out 😛
~Silverfox~
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
August 18, 2009 at 9:26 am
On the point of the DBA ruling the production database:
You cannot be held responsible for what you don't control. "Responsibility" without control is just blame. Conversely, control without responsibility is just ego.
If I'm going to be held responsible for a database or a server, I'm going to have control over it. If I'm going to be held completely responsible for it, I'm going to demand complete control over it. Anything less is just asking for trouble.
- 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
August 18, 2009 at 9:30 am
A Good DBA will want to know everything going on in his environment - especially since he will be the one called out at 2am in the morning when it all goes pear shaped...
a good DBA will also question every request (such as "why does the personell director need sysadmin access to my server?" ) which leads to the perception that DBA's are difficult or "own an empire"
security, protection and DR are paramount to a production DBA as they will be the one either facing the Axe if everything goes wrong and they cannot fix it, or they will be the one cleaning up the mess.
MVDBA
August 18, 2009 at 9:36 am
All comes down to having the best interests of the company to heart. how is that I hear you cry.
Every day you get into work, and you dont hear loud screaming and management running around like headless chickens. you can think to yourself... I knew I was right not to let those pesky developers anywhere near our production servers. 😀
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
August 18, 2009 at 9:37 am
DBA: Mentor vs Protector... Actually, mentor and protector can go hand in hand. A good mentor in essence is a protector by providing good communication. Helping with good coding practices limits runaway queries. Providing knowledge of data models and naming standards limits subverting corporate data structures and conventions. Giving an understanding of why the data has been encrypted or protected in some way can enlighten a fellow associate. Being there for assistance and understanding (mentoring) provides many fruits toward the common goals of the business. Working with Gestapo-type DBA's leads to limited and less productive communication with the goal of the developer becoming how to get around the DBA.
As an employee and a consultant, I've been on all sides of this issue. From Developer (yes, with MS Access too) to ETL Developer to Data Modeler to Application DBA to Platform DBA/Systems DBA in all environments - Sandbox(Systems and Development), Development environment, Test, User Acceptance, Production, etc. in many different worlds (Windows, Unix, Mainframe). This has led to a respect for all involved (including the Business Users) and has allowed the opportunity to mentor to all involved.
It's always nice to know that at the end of the day or at the end of an assignment, you've helped someone progress and the organization is better for it: mentored, and more secure.
Rich Graff
August 18, 2009 at 9:40 am
Silverfox (8/18/2009)
....I find that quote quite unacceptable personally, when an manager thinks he can tell me my job, I know it is time to move on....
With the greatest of respect, I couldn't disagree more. If my manager were to feel he should tell me my job, I believe I'd have lost my focus. Any employee's function, from cleaner to board level, is to do what the company believes is its best interest. Who, if not my manager, should tell me if I'm deviating from that? If a company....
feel they have to protect employees from others.
...who do they rely on to do this, if not the management?
...but being a DBA is one of the most technical roles you can be IMHO and that confers great responsibility and trust. It is our duty to help others and serve as the guiding light to other employees. I dont need an executive or management to point that out
You may not, but I've met plenty who do (and not just DBAs but people in all kinds of fields). Not everyone given responsibility will rise to the challenge.
In honesty, I don't believe Blandry was having a go at DBAs per se; merely anyone who wishes to indulge in empire building. If my assumption is correct, he has my support in trying to discourage that sort of divisive behaviour.
Semper in excretia, suus solum profundum variat
August 18, 2009 at 10:02 am
I think that we have met different kinds of management over the years with all due respect
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
August 18, 2009 at 10:24 am
I think a lot of the impedance mismatch described in these comments can be addressed by having Database Developers on the development team.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
August 18, 2009 at 10:26 am
IMHO the more freedom, the better for a developer to experiments his codes, his setup etc..
A developer needs to organize his/her work, keeps track of changes and structures documentation. Developers should experiment responsibly. I believe that DBA's role in developement environment is mentor/helper rather than administor/protector or babysitter
There are always plus and minus experience that you take from previous experience, be
a business person, a math instructor or an Access developer.
Hai
Viewing 15 posts - 16 through 30 (of 44 total)
You must be logged in to reply to this topic. Login to reply