September 19, 2009 at 11:57 am
Comments posted to this topic are about the item There's No Such Species as a DBA
Best wishes,
Phil Factor
September 19, 2009 at 1:58 pm
Outgrown the term DBA? Unfortunately, yes.
I am from the time when there weren't any DBAs, nor any other specialists. There were application programmers and systems programmers. And oh yes, some "senior" apps guys became analysts of one flavor or another. That was the beginning of the downfall.
Specialization is detrimental.
I am of the last generation of generalists. That is, I actually understand what computers do, and how they do it. I've worked with the "young pups" that know one thing, and THINK they know it well.
They don't. Most of the people in this industry now have no real understanding of computing, IT, or really, anything technical. It's simply too easy to get things done in an adequate fashion.
Back "in the beginning" when databases were "invented" in the '70s, it fell to the systems programmers to make them run, and we did. It was just another part of the job along with the core OS, telecom, storage management, applications support, and everything else we did. Strangely enough, even though those systems were MUCH harder to configure and maintain, most of us could handle most of the work - regardless of what it was.
For some reason, now that it's almost trivial to create a complex application in a matter of weeks instead of years, there is an attitude that a whole building full of specialists is necessary to git-r-done.
If even a handful of these specialists actually knew the SYSTEM, a lot of money would be saved. Of course, a lot of specialists would find themselves out of work because they are not useful.
I've worked alone, and I've worked as part of huge teams. I believe that overall productivity decreases as the team size increases.
This is a concept that goes back at least as far as the "skunk works" of aviation that gave us such miracles as the SR-71.
However, the smaller the team is, the more skills each individual must have. In other words, they actually have to have a couple of brain cells to rub together.
To make an analogy, our industry has people that can work with oak trees but not pine trees, grasses but not shrubs, etc. To be blunt, they are lost in the forest because they can only see a few of the trees.
Am I unique? Far from it. But for certain, there are damn few - WAY too few - of the younger generation (eg. under 40) that have the drive to git-r-done.
Here's a personal example. I just finished a contract writing a process control system. Never even saw one before. Never heard of PLCs (Programmable Logic Controllers). Yet, in 6 months, working alone, we're shipping bulletproof control systems.
Why? Because I understand computers.
I had some trouble with the PLCs at first. The normal programming language is "relay ladder logic". Then I found the checkbox that showed me the generated assembler code and instantly understood what was going on - I was working with a stack-oriented accumulator microprocessor - no big deal.
My first formal introduction to programming was to create algorithms. First example was how to change a tire. Believe it or not, that simple act emcompasses every basic function of computing. If you actually analyze the process, the lightbulbs might start coming on.
Now, if I could just find more clients like the last one. That is, people that can look beyond the alphabet soup and see that someone like me is what they need to get the job done. 😎
In closing, a bit of advice: Learn the basics and build from there.
P.S. To all those youngsters that think that Intel invented virtual storage with the 80386, you're wrong. They were 20 years after the fact (IBM/Cambridge, 1967).
And the mouse was invented years before that!
September 19, 2009 at 6:48 pm
Really good article about "The Many Types of DBAs"
September 19, 2009 at 6:59 pm
Well, as a Microsoft employee who wrote some of the manageability tools, I always find these articles humorous. We wrote (and write) a wide array of tools - graphical, command-line, and yes, PowerShell - all of which are designed to give you choices. You can use any, all or none of these tools in any way you wish, and we're just as pleased as we can be when you do. In fact, we have a lot of DBA's at Microsoft, and even while I was helping to write the tools, I volunteered (and still do) as a DBA, so I do the same job many of you do, in addition to my day job. I don't like it when I hear someone say "Microsoft is trying to MAKE us work in a certain way!". Bah. Not even remotely true. We even work hard (nobody's perfect, of course) at making sure you can do just about anything you need to do in T-SQL, SMO, SQL Server Management Studio, PowerShell, etc. That's dictating? Not hardly. We don't make you do anything in a certain way. I've seen people administer and monitor SQL Server with everything from Perl to Python, and from Redgate (who make great products, by the way) to Outlook. That's right - I helped a person the other day that had an entire job monitoring system he built into Outlook.
I take personal offense with the statement that Microsoft does not respect the diversity of our users. We even have an entire team that researches (at a great cost to us, I might add) how and what the amazing array of customers do every single week. They fly all over creation, watching and learning from lots of users, from the small shops to huge companies. These folks have advanced degrees in Human Computer Interraction, Computer Science, and even Psychology!
That research forms the basis of how the tools are put together. While it might not be exactly what you might want or expect in the tool, you might do well to take your own advise and respect the diversity of our users. What doesn't work for you might be perfect for someone else, who uses another language, is sight-impared, or has a different requirement than you do. I think we do a fairly good job given the millions of installations for SQL Server that exist.
It would be useful to remember that the "Microsoft people" are *people* first, many of whom have worked in the industry for years before we joined Microsoft. I was a DBA (yes, I actually still use that term, without shame), developer and data architect, as well as a person who worked with Business Intelligence systems, on Oracle, DB/2 and Microsoft SQL Server. Of course we all do other things - I've done management, documentation, and everything else, but at the end of the day we all work with data.
Instead of accusing Microsoft of being a large conglomerate that doesn't care, grab a blue-shirt at one of the conferences and sit down with them. I think you'll find they are pretty nice folks, and that our only goal is making the system better - for you. We do care - and we work very hard at making the product better, every day.
- Buck
Buck Woody
MCDBA, MCSE, Novell and Sun Certified
September 19, 2009 at 11:36 pm
The term DBA changes all the time and what it means from shop to shop varies. I have always considered myself a generalist as I can write C#/VB.Net ( and enjoy it ) and dont think that Windows is the latest virus released from China.
One position I had this was considered a positive. In the next position it was a negative as I would told at review time I was not specializing enough. In my next position it didnt matter as the DB Team was thought of by all others as slowing everyone down as we insisted that the developers test the code before putting it in production, that our management give us the infrastructure that we needed to be up 24/7 and support tens of thousands of users from around the world, that we be in on architecture decisions for the next version of our system, that we not get woken up every night with applications and network problems, that we only maybe work 5-6 days a week and be able to work less than 60 hours a week. We were seen as troublemakers due to these simple requests.
One shop wants you be an Oracle guru and Linux Systems Admin while the next wants you to know Oracle, SQL Server, DB2 and Ingres and be able to do production support on all in Sun, Windows and Linux environments and to be able to back up the System Admin and Storage Admin when they arent available.
The good old days of working on an IBM 4381 on MVS with COBOL and IMS seem so long ago but so much simpler than today. Guess that dates me huh ? 🙂
September 20, 2009 at 5:09 am
Apologies To Buck for generalizing a little too much. The struggle with an editorial is to make a point in as short a space as possible. Of course, I have a high regard for the amazing influence that Buck has made in SSMS, and the influence he has bought to bear on the development of SQL Server tools. I had no intentions at all of causing him personal offense by criticizing Microsoft. I also have a huge regard for Bill Ramos, and the SQL Server team. I was looking more broadly at the pervasive culture.
Among the points I was trying to make was this: A lot of Sysadmins are nervous about the way that Exchange 2010 assumes an expertise in Powershell, and that some of the functionality for routine admin tasks can only be reached through Powershell. By contrast Windows Server 2008 R2 at least duplicates all admin functions in GUI tools, but still, the Lingua Franca is Powershell. Some of this anxiety is percolating to Production DBAs.
Powershell v2 looks good, and I'm happy to use it, but I'm acutely aware that we must ensure that all functionality that it brings can be reached through the GUI. Also, I'd suggest that Microsoft would encourage the use of other available scripting mechanisms. How could I possibly think that they aren't currently doing that?
I suspect that http://www.microsoft.com/windowsserver2008/en/us/server-management.aspx is fairly close to the current Microsoft line...
Windows PowerShell is a command-line shell and scripting language that helps IT professionals achieve greater productivity and control system administration more easily. Windows PowerShell accelerates automation of system administration tasks and can help improve your organization’s ability to address the unique system-management problems of your server environment.
Windows PowerShell is easy to adopt, learn, and use because it does not require a background in programming, and it works with your existing IT infrastructure, existing scripts, and existing command-line tools. Unlike most shells which accept and return text, Windows PowerShell is built on top of the .NET common language runtime (CLR) and the .NET Framework, accepting and returning .NET objects. This fundamental change in the environment brings entirely new tools and methods to the management and configuration of Windows.
You could be forgiven for understanding from this statement that here was little in the way of alternatives here. Well, there are several .NET-based scripting languages that are ' built on top of the .NET common language runtime (CLR) and the .NET Framework, accepting and returning .NET objects'. IronPython and IronRuby come to mind immediately, but the the DLR will encourage more in time, such as poor JScript. We may even see VB.NET return to its roots as an interpreted language. I even raise my eyebrows slightly at the statement 'Windows PowerShell is easy to adopt, learn, and use because it does not require a background in programming'.
Microsoft has had, for a long time, a very sensible policy of repeating .NET code examples from MSDN in both C# and VB.NET. It could easily do the same thing with Powershell admin code by repeating examples that use Powershell with, for example, IronPython or IronRuby. (IronPython can invoke the PowerShell APIs directly. see http://ironpython.codeplex.com/Wiki/View.aspx?title=Samples). I'd love to see more copy-and-use scripting example in other languages than Powershell. For doing really complicated scripting, I still find VB.NET the best tool for the job.
There are always going to be possible improvements to the GUI management tools. I don't buy the idea that the SSMS that we see today is the culmination of all the man-years of experience by the 'folks(who) have advanced degrees in Human Computer Interaction, Computer Science, and even Psychology!'. SSMS isn't perfect. Surely, improvements are possible to reflect the range of roles and experiences of the users? Is it still even correct to believe that all the administrative requirements of all users can be achieved though one GUI?
Best wishes,
Phil Factor
September 20, 2009 at 5:45 am
I believe many work groups would say the very same thing about themselves and their own work titles and such. This is not something limited to DBAs but probably to most people. Because most people has to deal with problems and solve them and that can be problems that does not fall under their specific category of their work title. Lets not get ahead of ourselves.
What is the current reality of the different database-related jobs being demanded by IT departments? I believe that is as different as every job and work place is to any other job and work place. Where I am, I'm a dev. I fix bugs, I build new functions, I schedule sql jobs and I write them, I fine tune sql code as well as c# code, I build reports for sql report manager, I do simple and complex reports. I'm by definition not a dba however, we do not have someone titled dba where I'm at. I've been in this business for only three years and thus I have a lot to learn but in this business it is my belief that the day you stop to learn that you have aged out of it and need to move on.
If you strive to find a title to cling on to and do no more and no less I think your individual value will decline, it will rise when you work not only in the box you might have wanted to stay in.
September 21, 2009 at 3:56 am
its important that your current job title accurately reflects the nature of the work that you do and closely alligns with the titles used in the job market. Putting 'DBA' into a job search engine will return a lot of jobs, most of them not relevant to you. Putting 'SQL Server DBA' will, in my case, hit the spot and return what I'm after. No point calling yourself a 'SQL Data Tier Infrastructure Architect' when in fact you're a 'SQL Server DBA' - you'll limit your opportunities. My team has Oracle, SQL Server, Netezza, RDB, mySQL, DB2 and Sybase DBAs - we're all DBAs. I forget now the point I was trying to make ....!
thanks
SQL_EXPAT
September 21, 2009 at 7:49 am
I've been through the "what is a DBA?" question many times in my career. Personally I tend to think of a DBA as the production DBA, who's responsibility is the design, setup, and maintenance of the more physical part of a DBMS, that being the actual SQL Server program, filegroups and disk layouts, capacity planning, backups and maintenance plans, and system security.
I'd consider a data analyst someone who works in data modeling, systems integration, and more logical aspects of the DBMS.
Someone who's a programmer or developer would be a third role, focused on just the designing and implementing tables, views, trigers and stored procs. The problem is, a single person often to fill more than one of these roles, and those overlaps differ from company to company. Some split the data analyst role between the DBAs and developers. some give that role entirely to DBAs, some entirely to the developers. Occasionally I've seen a person need to be all 3 roles.
September 21, 2009 at 8:14 am
No problem at all Phil - the only reason I even responded is that I respect this site's writing so much, and I think others do as well.
I agree with the PowerShell comments, up to a point. I'm no fan-boy, but I do think it has made my job easier. I've posted my admin scripts on my blog, and the scripting guys ran a four-part article series on working with PowerShell and SQL Server that we kept as "batch-file" as possible.
My only issue was with any idea that Microsoft dictates a particular method of working to anyone. In fact, we're often criticised for the opposite - too many ways to do the same thing! Sometimes you can't win, right? In any case, I like the variety. If PowerShell is too "programmy" for someone (I'm not a dev either) then use SQLCMD, or IronRuby (I hate that thing) or whatever. It's all T-SQL in the end, right?
And as far as SSMS goes, of course things could be better. You have no idea how hard we fight to make it better, but sometimes you're the bug, sometimes you're the windshield. You can, however, rest assured that we take all the comments we get seriously, even if we can't act on them right away. It pained me every time I had to take a good suggestion and say "we can't do that right now" because of lots of other restrictions. I have friends that work at Oracle and Apple, and I can tell you they feel no such pressure. Users (especially at Apple) are told what they like, not the other way around.
So keep those cards and letters coming - especially you, Phil. We need you all to keep us on our toes. But do know that we are listening, and we do care.
Buck Woody
MCDBA, MCSE, Novell and Sun Certified
September 21, 2009 at 9:03 am
I think that it's hard to generalize in many areas. A system administrator, or MCSE, is often assumed to know Exchange as well as he does Windows. Or be an expert in Active Directory as well as IIS.
The difference with the DBA is that managers, users, etc. often know, or have an idea, of what is done in those areas. For databases, they're not sure how our job differs from a developer that has to built the application to access the data. The stuff a DBA does is often unclear, and apart from tuning a query to make it run faster, they don't get modeling.
Is a doctor a doctor? Not really. Their various sub-specialties are just more well-known.
September 21, 2009 at 9:24 am
"Swivel-eyed tinkerers"? The rest I followed, this one lost me. 😛
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
September 21, 2009 at 9:42 am
Recruitment agencies just see the initials DBA and all reason leaks out of their skulls.
Most? Maybe... but certainly not all of them. 😉
It seems increasingly difficult to recruit Database-savvy people without having to wade through the CVs of people whose training and skills are entirely inappropriate for the job description.
This is something I see with a lot of different roles, it tends to be more prevalent during times of high unemployment.
September 21, 2009 at 10:00 am
I've been primarily a developer, but took the time to ask and learn about databases from an Oracle DBA I was working with many years ago. In such an environment, the DBA owned the database and all things related. He even had override control over our code to be sure we were writing efficient queries and reads. Since then, I haven't worked with any "DBA" as budgets usually didn't allow for the extra person and the role usually fell to the IT person or developer that wasn't frightened to death of databases - usually me.
I understood from the beginning that if the foundation of an application was a database, then I can build the best application by building the most efficient database (and not writing code that sucks). I could say that 15 years ago, most developers would lack rudimentary database design and maintenance skills, but the landscape is vastly different today. While there are many companies whose operation is big enough to justify a full-time DBA, most do not and then the role is a shared one. I was hired as a developer and they said 'Oh, you know databases?' So, I am taking over all of the DBA duties while still having a great respect for the technology and what I don't know. My role as "DBA" may always need the quotes because I certainly don't fit the mold of twenty years ago but it begs the question of "What is a DBA?".
From a practical standpoint, if the responsibility of the database lies with you - i.e. whenever it breaks, they are calling you day or night - then you're the DBA no matter what proficiency level you are at. If you also happen to be a developer, IT manager, gopher, whatever, who cares. Having said that, the DBA has a personal responsibility to learn all he/she can to maintain an optimized environment. How many databases out there are just train wrecks waiting to happen because the designer didn't know what they were doing? How many will never be discovered because SQL Server is forgiving of most sins provided you're not handling hundreds of thousands of transactions per day?
I guess my point is that the term DBA - in what the job is - remains unchanged. It's just the individuals performing that job has changed quite a bit and is not nearly as clearcut as it was 15, 20 years ago. A person can wear many hats and be a competent DBA all at the same time. He/she must be proactive in going the extra mile to learn everything possible in being an effective DBA, using every tool at his/her disposal.
September 21, 2009 at 11:07 am
[SimpleSimon (9/19/2009 ". . . I actually understand what computers do, and how they do it. "
Well, for the bendfit of the rest of us, would you please consider writing an article for SSC explaining that?
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply