July 19, 2012 at 1:57 pm
Some people ask to be a SQL Server DBA, some are drafted or rather are a "DBA by default". I am looking for "horror stories" or even "rude awakenings" :w00t: when people first become a DBA.
For those who chose to become a DBA: what was the event that sort of splashed you with icy cold water and made you aware of the potential difficulties starting out as a DBA?
For those of you who were drafted: or became a DBA by default, can you give me a story of how it happened, or an immediate issue that needed to be addressed?
For anyone, what was the biggest obstacle that you encountered when you first started administering MS SQL Server
I am working on a presentation about starting as a default DBA and I would enjoy hearing from others.
(I unintentionally posted this in another forum. I apologize if that is against the rules.)
-----------------
Larry
(What color is your database?)
July 20, 2012 at 5:03 am
Probably should be moved to the "Anything that is not about SSC" forum, but that's Steve's call.
I was drafted/volunteered. I was working for a dot com startup as a developer. We had been without a DBA for a couple of months and things on the database were going downhill rapidly. One day, after hitting a number of issues, I kicked in the boss' door and when on a tear about how he needed to get a DBA ASAP. I listed out four or five issues. His response was "Which one will you work on first." Oops!
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 25, 2012 at 5:12 pm
I'm a volunteer. I got hooked in my first relational database class in college. The magic of pulling information out of a big pile of data turned me on and I've never looked back.
I view my primary function as protecting the data for my clients. Backups, restores, emergency preparedness, and disaster recovery are my top priorities each day. After I am satisfied that all is well in that world, I move on to performance tuning, helping others with queries, etc.
The "icy water" you mention was when I started my first job as a solo DBA after the previous DBA had quit. Everything looked wrong to me regarding datatypes, backup strategies, naming conventions, storing calculated values, and many other issues. For instance, the database backups were a mile wide but only an inch deep. Because I was new at the organization, I studied long and hard before I had the confidence to suggest and implement changes. It was a tough time, but in the end it was very satsifying to bring all the professionalism that I could to the job of DBA.
HTH
Elliott
August 1, 2012 at 2:40 pm
Thank you! I too believe that most of us were drafted one way or another. I had trouble grasping the nature of SQL Server when I started. It was similar to the story of the blind men and the elephant where each had a different perspective based on the part of the elephant that they touched.
I do admit that after all these years, certain BLOGs and books have helped me understand SQL Server. Books like SQL Server 2008 Internals, the writings of Kalen Delaney, Paul Randal & Kimberly Tripp, and Itzik Ben-Gan have helped me understand WHY SQL Server does what it does and why I should do what I need to do to administer all of our instances of SQL Server.
-----------------
Larry
(What color is your database?)
August 4, 2012 at 1:38 pm
Long time ago I was a Project Manager in the old sense of the term - at that point in time the "Project Manager" was a Sr Systems Analyst in charge of a project from end-to-end including Functional analysis, Storage specifications, Programming specifications and Implementation.
One day the company I was working for decided to test a new technology on a specific project, project got assigned to me. The "new technology" was Cincom Systems TOTAL DBMS, a network database management system. It was love at first sight.
Over time relational databases come into the picture like Supra and Adabas. I just followed the technological flow doing nowadays mostly Oracle and SQL Server.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.August 7, 2012 at 10:38 am
Hired as a QA Manager for a VB 4.0 system with 28 developers / testers.
Found out quickly that it was necessary to learn MS Access right away. It turns out that it was portables with a VB front-end, an Access back-end, with the first RAS Server (That be Dial-up for you youngsters) to a SQL Server (beta first release) and a custom ODBC interface to AS400 International JIT Network.
After this project, I was asked to become a Microsoft Access Trainer (for programming). To keep up on the training, I carried a "luggable" SQL Server that just verily fit under an airplane seat. The demand for Access Front-End connected to SQL Server kept me traveling over 30 weeks per year to a different location each week. Training often turned into troubleshooting at every level.
Part of the MCSD certification included Excel Object Model Programming. Excel can be set up as a server on a network. While many SQL Server professionals cringe at the thought of Excel being used anywhere in close proximity to the SQL Server, there are many cases where it does just that for real-time processing. Manufacturing real-time data processing such as Fractal analysis for cooling glass in Fiber Optics Manufacturing Control Systems at Dow Corning is one example. Industrial control monitoring systems or Wall Street decision support systems are other examples.
My fortune was to have a quality MS SQL Server Users Group available. While I sit in total awe for most of the meetings, the concepts allow me to ask really stupid questions on sites like this one. Or, search the Internet for hours to cobble a solution together. However, at most job assignments, I often have to install, setup, migrate and other wise lead staff to some solution or better process.
While Microsoft is moving sales to the large systems, don't forget that the small business or big business divisions with under 200 employees rarely employ C# or .NET programmers. A dozen applications with ten to thirty users each can add huge efficiencies to a small business. Isn't small business leading the Recovery as big business is downsizing? Allowing a small business or small division to be successful with tools such as Access and Excel -than migrating to a SQL Server back-end is popular.
B.T.W. My Access applications with SQL back end use Citrix to distribute with tiny bandwidth, works on PC, Apple Tablets and more. One person writes the front-end, middle ware, and administrates SQL Server.
August 7, 2012 at 11:17 am
Neither. More like I wasn't watching my feet, tripped, and landed face-first on a big pile of DBA.
My first rude awakening on it was how unclear basic terminology was in this field. My first question when I started workin with databases was, "why do they call them 'relational'?", and the top definition I found via Google at that time was "relational: of or having to do with relations in databases", "relation: what they have in relational databases", "relational database: databases that have relations".
Turns out, "relation" = "table". Had to get a computer science book from the 70s, when the concept was new, in order to get that definition in plain English. Otherwise, it was all circular definitions, and very unclear. (Don't believe me that "relation"="table"? Check definition 2 here: http://foldoc.org/relation.)
Still shocks me when I run into DBAs who think "relational database" = "database with foreign keys".
It was a rude awakening to realize that many of the people who are "experts" on IT, of any sort, DBAs, devs, sys admins, you-name-it, are often people who fell on the career and don't know basic terminology, much less basic theory or practice. Kind of like running into a doctor who doesn't know what "tissue" means, or a lawyer who's unclear on the definition of "lawsuit", or a politician who has never heard of "graft" or "lying". Key concepts of their chosen careers, right?
But we don't even have a single definition of "DBA". Still bothers me, to this day.
- 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 7, 2012 at 11:34 am
I'd have to say enlisted. At a previous employer we were looking at new technologies in an effort to replace a COBOL/ISAM based application (that application is still in use today, by the way, and is unchanged). We were looking at Borland InterBase (would run on SCO Unix) and MS SQL Server 6.5 (Windows of course) and using a VB6 front end.
MS SQL Server won out, not because it was better than InterBase but because it was easier to code against with VB6. Although we never developed a replacement for the COBOL application, SQL Server became a vital piece of the overall application framework. Over time we eventually downloaded all the data from the ISAM databases on a nightly basis and used SQL Server for reporting and integrating with other systems in the organization.
I took on the database part of the system, and for a while also helped with the hardware and OS, but that quickly went away under a couple of reorganizations.
I have never looked back having worked with SQL Server now for over 15 years.
August 9, 2012 at 3:32 pm
Turns out, "relation" = "table". Had to get a computer science book from the 70s, when the concept was new, in order to get that definition in plain English. Otherwise, it was all circular definitions, and very unclear. (Don't believe me that "relation"="table"? Check definition 2 here: http://foldoc.org/relation.)
I was actually dissed openly at work a time or two by people who saw themselves as my superior when I insisted that a relational database can have only one table.
Back on subject though, I identfied two possible career paths based on my favorite skills: I was either going to become a chef or go into IT. I chose the IT route because it would be easier to find a solid job with benefits. And within IT, I became a sql developer (not a dba) because it's fun! I have control, I am the man with the answers to the questions about what you have within your data!!!
And thanks to you folks who contribute to SSC, I'm getting better all the time 😀
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply