April 9, 2015 at 8:08 pm
Comments posted to this topic are about the item After Six Months On The Job What Challenges Remain?
April 10, 2015 at 5:37 am
Five years in and I'm still fixing things - and having a whale of a fun time doing it.
The scale of my business unit means I work on both ends of the DBA/Developer spectrum and just about everything in between, so I don't get bored. Our unit did a lot of data collection but with little or no thought to leveraging it, so I've got a LOT of pain points to address, and an effectively mission-critical "database" that began as a bunch of separate Access databases dumped into one SQL Server instance. Ugly.
On the opposite end of the spectrum, I subscribed to Brent Ozar's weekly DBA Training emails and while not everything in them is applicable to our environment, I find the topics interesting in their own right and I learn something I can use out of almost every one.
I could see even a veteran DBA working through these and thinking, "Gee, that's something I haven't looked at in a while, maybe it's time to have a peek."
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
April 10, 2015 at 8:01 am
Things were so messed up the first 6 months were more like the first two years. And mixed in there's the aborted move to Cassandra, the consideration of SSAS, and now the possible move to Azure. In my experience things might slow up for a few months at a time but something, good or bad, comes along to keep things interesting.
April 10, 2015 at 9:19 am
We are not an industry that likes to be static...and business' like change too. Rarely have I seen a place which moves so glacially that there wasn't much to challenge someone who wanted it.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 10, 2015 at 9:55 am
My previous job, after I got domain admin access, I ran OSQL -L and started digging. I was quite surprised to find most of the databases being autoclose and autoshrink. Backups without DBCCs, sometimes no backups, in many cases recovery model was simple. Also a surprising number of orphan databases that no one had any idea what they did. The best part was finding out that I was THE[/i] dba, I had thought that they already had a DB staff in-house. Silly me, and another standard question is added to my list to be asked at interviews.
I think plenty of challenges remain after six months. Of course, lots depend on how large and mature the installation is.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
April 13, 2015 at 12:59 pm
I've been fixing things for 16 years and don't see an end anytime soon. So I[m not worrying about it.
April 13, 2015 at 11:54 pm
Considering that there were more than 30 different hacks trying to get something up and running quickly and then hacking at it more to add more functionality quickly over a period of 8 years, do you really think that one DBA can fix everything from those 240 FTE years in 6 months even with help from the more intelligent hacks in the group? 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
June 19, 2018 at 1:51 am
A lot of it depends on what you are allowed to change and how many people you have.
For example, if you come in as the DBA and have been assigned a fresh junior (maybe, say one of the young programmers who expressed an interest in databases), then once you have gotten the critical points sorted out (backups, security, any acute performance problems amongst others), you can start on training the junior DBA.
You can start looking at the other technologies available in SQL Server. If you have a productive server that is written too very heavily, then a project investigating the feasilbility of OLTP might be worthwhile. If the reports are in a sad state or if they take an age to generate, then cubes or tabular model reports might be something to look into. Maybe the consolidation of 20 disparate DB-servers onto one powerful host with 20 instances might save the company a fortune in licensing. There is always something to do. If you are allowed to do it.
Often you can only take it so far. The database might be running as well as can be expected but the application login insists on having sysadmin rights and you are not allowed to change that on the grounds that it would require a full release and the developers don't have the time or the will to change it. Or the Entity-Framework queries generated by the application might be so goddamn awful that you are not surprised that you are getting many deadlocks per hour. Or you might be shaking your head at the GUID primary keys implemented by some developer in the past and not at all surprised at the nightmare that is the clustered index and how poorly it performs. If you not let correct these crimes against databases, then there is little more that you can do other write up a report to the relevant managers, tell them where the problems lie and move on to somewhere where your skills will be appreciated.
June 19, 2018 at 2:30 am
Bored is boring, there's always something to do!
You just have to find the things to work on that are going to give you and your company the best ROI (in that order). If you're not helping set the agenda then you probably need to move on.
June 19, 2018 at 6:12 am
Sounds like this is only from a DBA point of view. As a database developer, we're continually developing new software, stored procs, SSIS packages, script, etc.
Always something to do, and never boring.
June 19, 2018 at 8:10 am
After six months on the job, I would guess the largest problem is getting permissions needed to fix problems. In my last position, after around ten years there, it was still nearly impossible to get approval for implementing changes needed to fix issues, everything from proven invalid data to performance problems. The existing 'project managers', essentially inexperienced wanna-be's, were so timid at managing that they would never approve the fixes. Thank God I don't have to tolerate that BS any more. It was so bad that often we had to make unauthorized changes at our own risk.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
June 19, 2018 at 8:32 am
Agree with skeleton567 : "largest problem is getting permissions needed to fix problems" I will only add this "hard resistance to accept any changes and learn anything new from management and some 'experienced' developers."
June 19, 2018 at 9:48 am
A writer writes, a teacher teaches, a chef cooks, and a developer develops. If circumstances outside your control have morphed you into a support position or low level manager, then you have to ask yourself whether or not it makes sense career wise. What is the trade off for doing something other than what you really love and are expert at?
Are you really earning more money as a low level manager than you would as a senior level DBA? No, probably about the same money and maybe less.
Are you staying in your current job because you feel it's more secure? Remember that when it comes time to scale back, companies start with the "dead wood", especially the gray haired and expensive dead wood. If your title is "DBA" but ever since the data center migration to Azure you've been more of a jack-of-all-trades, then job security means re-aligning your identity, skillset, and position. It's great if you can do that without changing jobs, but you need to do your research and decide what option is in your rational self interest.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 19, 2018 at 10:22 am
You are so correct in everything above. And that is pretty much what I did. Fairly early in my career I took a position as IT manager for a company with a small shop that averaged seven people. We did some very good things and moved the company decades head in their systems - literally. They were a large company that was still using pencil and paper for everything when we started. After eleven years its was obvious that I no longer wanted to be a 'manager'. So I went back to being a 'techie', and finished up with 42 year in IT. I loved database design, SQL development, and database administration, and that is what I did.
I would, for your younger folks, add one consideration to what a position is doing for your career. That is what a position is doing for your retirement. As I understand, companies that have good retirement benefits are harder and harder to find, so you have to do it for yourself. For a number of years, my wife and I were both contributing the max to our retirement savings, and it has paid off nicely. Over the years I was 'downsized' nearly as many times as I left a company otherwise.
Now we spend our late afternoons enjoying what we fondly call 'merlot time' on the deck. And after nearly 40 years, we still visit regularly with the folks I worked with at that company
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply