September 19, 2016 at 2:53 pm
I'm currently a permanent DBA but thinking about easing into contracting, so I'm just wondering what the general opinion is on the type of work you all think the term 'DBA' entails. I've been in multiple SQL jobs over the years and the goalposts change with each position.
I'm strong on the TSQL side, DB structures, performance tuning, basically anything I can use SSMS on, plus obviously installations, configurations, etc., but when I look at job adverts, and back over my own career, a lot of companies seem to put SSIS, SSAS, SSRS, etc. all under the one umbrella term. In my mind, a DBA is different to a developer, who is different to a BI analyst, and so on and so on.
So basically, what does being a DBA mean to you? Should it encapsulate everything SQL, or is it something a lot more specific than that?
September 19, 2016 at 3:39 pm
Essentially, DBA stands for "database administrator". If the organization has solutions deployed on SSIS, SSAS, or SSRS, then at the very least you'll be expected to manage those products on the operational side. For example, do you know the basic architectural components of SSIS; how to install and configure the framework, secure the SSISDB catalog, deploy packages, schedule packages, and troubleshoot executions?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 19, 2016 at 4:09 pm
Remember that a lot of people don't know what "DBA" is compared to "DBA". 😛 In many cases, I've found that when people ask for a "DBA" as a contractor, they want someone that has a deep understanding of T-SQL, the database engine, performance tuning at both the engine and code levels, and the ability to find and fix the worst problems in code.
I don't know much at all about any of the 4 letter words (SSIS, SSRS, SSAS, etc) of SQL Server and yet I've had to turn away contractor work. The big thing, it seems, is performance work revolving around T-SQL and the configurations of the database engine. Heh... sometimes it's even to replace SSIS packages with T-SQL. 😀
As for the advertisements that include all the 4 letter words, a lot of folks write "and the kitchen sink" job descriptions with those as "requirements". If you don't know those things, apply anyway because most of the time they want someone that can find, fix, repair, design, and implement high performance solutions and the other stuff is secondary, sometimes way down the list even though they haven't listed it that way.
Go for it.
p.s. You do know what a "Tally" or "Numbers" table in T-SQL is, right? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 19, 2016 at 4:47 pm
Thanks!
Jeff, I was hoping someone would say pretty much exactly what you did, and that I've not missed the boat completely with where my skills lay lol. Thanks for the reassurance. As for tally tables, I've used them occasionally, but I'll be honest, I had a quick look over them just now to refresh my memory, it's one of those things I've very rarely had a need for, but yeah, I know what they are and have used them on occasion. Funnily enough, I scanned through your Tally OH![/url] article again just last week!
Eric, yeah I can find my way around the things you discussed, I wouldn't be confident to design and build a well formed SSIS package, but I'd be fairly comfortable configuring the general setup, or poking around and debugging a pre-built package.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply