July 31, 2012 at 9:51 pm
Comments posted to this topic are about the item Out of the Frying Pan Into the Fire
August 1, 2012 at 2:59 am
So true. I'm a "solutions provider" / "developer" / "current vogue name" writing SQL-based intranet (dot net) solutions.
Whilst I have a rough idea of what is going on behind the scenes on our SQL boxes there is no one actively managing them. Once in blue moon I check the logs but they could be filling up even as I write this with some esoteric error message that I wouldn't understand nor be able to fix.
Because they have run this way for the best part of two years everyone (me included, I suppose) assume that things are OK. And for internal, intranet based solutions we can probably get away with this. Imagine the same attitude being adopted for an external, client-facing server though!
I rely so much on the articles on SQLServerCentral just to get by, but there are only so many hours in the day (and only so many grey cells in my head) to absorb the information - and SQL Admin is not my core job, just a platform I use to get solutions implemented.
Actively managing a SQL server (and understanding what it is you should be managing and pre-empting) is IMHO a necessity. I used to be a Lotus Domino DB Admin and that took 100% of my time (bigger solutions, many servers admittedly, but things did need managing to avoid a meltdown).
How do you get that message across to management who just see the SQL server running quite happily and a DBA as an additional expense with no perceived benefit - before total meltdown?
August 1, 2012 at 8:08 am
I enjoy perodically getting dumped into a 'sink or swim' situation, as long as the expectations are realistic. That's how I started in SQL years ago (my database experience before that was primarily Access).
My new challenge is a complete revamp of our network based fax system (it has a SQL backend) and I am rapidly learning about telecom hardware and protocols (the vendors involved are lending considerable expertise to the project). It's a bit scary, but exhilarating as well.
...
-- FORTRAN manual for Xerox Computers --
August 1, 2012 at 9:02 am
No one I know of "enjoys" walking into a firestorm. That said though, I have learned an enormous amount by doing so. Both, in further developing my overall skill set by my learning how to quickly think and react on my feet in these situations under pressure, and also by learning what situations/environments to avoid in the future by accurate assessing it (ie: spotting the red flags) during the interview, long before I actually walk into it. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
August 1, 2012 at 9:06 am
ralph.bacon (8/1/2012)
How do you get that message across to management who just see the SQL server running quite happily and a DBA as an additional expense with no perceived benefit - before total meltdown?
Not sure you can, until there is some issue. When you can't fix something or it takes you a long time, or performance impacts users, you can document these things and use them as a case for getting some help or training, but other than that, not sure.
The flip side is how do you know when things will break? If it's not for 5 years, does it matter? Ten years? Is it worth paying someone for 5 years while everything works?
It's a tricky situation.
August 1, 2012 at 9:15 am
Steve Jones - SSC Editor (8/1/2012)
ralph.bacon (8/1/2012)
How do you get that message across to management who just see the SQL server running quite happily and a DBA as an additional expense with no perceived benefit - before total meltdown?Not sure you can, until there is some issue. When you can't fix something or it takes you a long time, or performance impacts users, you can document these things and use them as a case for getting some help or training, but other than that, not sure.
The flip side is how do you know when things will break? If it's not for 5 years, does it matter? Ten years? Is it worth paying someone for 5 years while everything works?
It's a tricky situation.
You probably don't want to pay a DBA in those cases, but, you should have a consulting firm on contract. They will have the people to call in to handle the emergency situations. They could also be contracted to come in monthly (or some other frequency) to review the servers and issue a report. This is how I've seen it done in small shops where the expertise is not in-house.
August 1, 2012 at 9:55 am
Steve,
For a year or so I took the time to do some knowledge transfer to unknown new developers in C# on a large message board to help educate those who are starting and learning. I tried to not answer all the questions directly but to point people to answers or places where answers could be found so they also learned the necessary skill of debugging and digging for answers.
I have also started to assist others in using of one of the more popular Content Management Open Source products as to help others again but also to better my understand and advance my skills.
Really we should openly help others for two reasons, first to give back, but second and almost more importantly by assisting others with their problems we expand our understanding of software, situations, logic and logic traps we set for ourselves. When you help others you also help yourself. So Share what you know and you will know more, or hide what you know and become less knowing.
Have a great day, and thanks for bringing us along on this educational ride. It is appreciated.
M.
Not all gray hairs are Dinosaurs!
August 1, 2012 at 12:24 pm
Steve: And I thought you were going to wrap up with some horrible joke about how your career progressed from waiting on tables (in restaurants) to waiting on tables (in SQL Server). Thankfully you didn't. 😀
August 1, 2012 at 2:28 pm
I am so glad to see this as the topic of your editorial today.
I am scheduled to do a presentation at SQL Saturday #161 that I titled "Yesterday I couldn't even spell 'DBA'..." 😀 I even have a post somewhere on here under SQL Server 2008 > SQL Server Newbies > titled "Enlisted or Drafted" where I hoped to get people to weigh in on the subject and maybe tell their own tales.
I definetely was drafted. Although I have been designing and coding databases ever since 1980, the days of the 6502 CPU, making the transition from developer to DBA is a bit jarring.:w00t: I had only started developing in SQL 7 when the development company where I worked decided to also do some SQL Server hosting. I was drafted and glad I did if for nothing else than to stop them from their normal backup plan. Their plan was to not use SQL Server backups but to let everything get backed up to tape without even stopping the services.
I quickly learned as much as I could and my boss was supportive, even allowing me to study and finish my MCSE then take the last two tests to get my MCDBA.
One problem I run into with developers is that they can't seem to wrap their minds around the concept of result sets (RBAR) or the concept of a database server. Some just thought that SQL Server was the same as having Visual FoxPro or Access available on a network share.
Please tell me more of what your experiences and what you found helpful and what you wish you had known when you made the transition!
-----------------
Larry
(What color is your database?)
August 1, 2012 at 4:42 pm
ganotedp (8/1/2012)
Steve: And I thought you were going to wrap up with some horrible joke about how your career progressed from waiting on tables (in restaurants) to waiting on tables (in SQL Server). Thankfully you didn't. 😀
LOL, that would be a bad joke, wouldn't it?
August 2, 2012 at 10:09 am
ralph.bacon (8/1/2012)
So true. I'm a "solutions provider" / "developer" / "current vogue name" writing SQL-based intranet (dot net) solutions.Whilst I have a rough idea of what is going on behind the scenes on our SQL boxes there is no one actively managing them. Once in blue moon I check the logs but they could be filling up even as I write this with some esoteric error message that I wouldn't understand nor be able to fix.
Because they have run this way for the best part of two years everyone (me included, I suppose) assume that things are OK. And for internal, intranet based solutions we can probably get away with this. Imagine the same attitude being adopted for an external, client-facing server though!
I rely so much on the articles on SQLServerCentral just to get by, but there are only so many hours in the day (and only so many grey cells in my head) to absorb the information - and SQL Admin is not my core job, just a platform I use to get solutions implemented.
Actively managing a SQL server (and understanding what it is you should be managing and pre-empting) is IMHO a necessity. I used to be a Lotus Domino DB Admin and that took 100% of my time (bigger solutions, many servers admittedly, but things did need managing to avoid a meltdown).
How do you get that message across to management who just see the SQL server running quite happily and a DBA as an additional expense with no perceived benefit - before total meltdown?
I agree with you, Ralph, as I am an accidental DBA as well. I look over and read, when time permits, the articles I see in my daily SSC newsletter. If it weren't for that and the SSC forums, we could have extremely serious problems. But honestly this is so hard. SQL Server is a fantastic product. We're using SQL 2005, and may remain on it for another year or two (I'm going to start lobbying for an upgrade, but I know it isn't in our budget for the current fiscal year). We're a small shop, just 1 production DB server and 1 test DB server, so there's not a lot of problems we face. Because of our small size, and because SQL Server is so good, we don't have major problems. I believe my management, not seeing anything wrong, concludes that nothing can go wrong. Therefore, training is out of the question. And, since my primary job is a developer, if I get any training that's what it will be for. But I worry about what could go wrong. I remember the last time we did anything major, when we upgraded from SQL 2000 to SQL 2005, I totally forgot how to associate logins with users in SQL. Man, we were in a total panic because all of our software relies upon logins being associated with a handful of users in our databases. Of course, it's easy with with the ALTER USER command or the older SP_CHANGE_USERS_LOGIN stored proc, but when you're under the gun it's easy to forget the basics. I never want to go through that again.
I kind of think that there should be a separate forum on SSC, or some other place entirely, for accidental DBA's like ourselves. Sort of joking referring to the 1988 film "The Accidental Tourist" (which I confess I've never seen) where we could ask those basic questions that accidental DBAs have. I suppose it isn't necessary, but it sort of would be nice to know that others in that area are more like myself.
Kindest Regards, Rod Connect with me on LinkedIn.
August 2, 2012 at 10:31 am
We're a small shop, just 1 production DB server and 1 test DB server, so there's not a lot of problems we face. Because of our small size, and because SQL Server is so good, we don't have major problems. I believe my management, not seeing anything wrong, concludes that nothing can go wrong. Therefore, training is out of the question. And, since my primary job is a developer, if I get any training that's what it will be for. But I worry about what could go wrong. I remember the last time we did anything major, when we upgraded from SQL 2000 to SQL 2005, I totally forgot how to associate logins with users in SQL. Man, we were in a total panic because all of our software relies upon logins being associated with a handful of users in our databases. Of course, it's easy with with the ALTER USER command or the older SP_CHANGE_USERS_LOGIN stored proc, but when you're under the gun it's easy to forget the basics. I never want to go through that again.
I kind of think that there should be a separate forum on SSC, or some other place entirely, for accidental DBA's like ourselves. Sort of joking referring to the 1988 film "The Accidental Tourist" (which I confess I've never seen) where we could ask those basic questions that accidental DBAs have. I suppose it isn't necessary, but it sort of would be nice to know that others in that area are more like myself.
I really like your idea of a forum just for Accidental DBAs.
I hope that your company considers Disaster Recovery an important issue. Things can go very wrong and people can quickly face an untested backup strategy. A great cautionary tale is told by Paul Randal about a financial institution that had a backup plan but not a recovery plan, and while the database could be restored, the restoration caused the institution to be down for days which led to the company going belly up.
Where I work we are large enough so we do have multiple datacenters across our state and when we think of DR we apply the "smoking hole in the ground" approach as in what would we do if something wiped out the an entire data center? Just as a good question to ask about a developer, "What would happen if xxxxx were to be run over by an ice cream truck? (I don't know why, but the past several companies that I worked for specifically stated an "ice cream truck".);-)
I guess that that is the main danger of being complacent about managing SQL Server. But a company really needs to know the value of their data and how long they can go if a system/database becomes unavailable for a few hours or a few days.
One suggestion I have is for you to go to the PASS site and see if there is a local chapter near you. They are a great source of information and it is always great to meet other people face to face who deal with SQL Server. Also see if there are any SQL Saturdays or other SQL events near you. Usually the events are either free or have a slight charge to defray the cost of the meals, and you can attend some great sessions led by a variety of people on a variety of SQL Server related issues.
PS: find a copy of Accidental Tourist. It is one of my favorite movies and I swear that I am married to someone from the family in the film - they have no sense of direction and can get lost by making two left turns. 😀
Larry
-----------------
Larry
(What color is your database?)
August 2, 2012 at 11:34 am
IowaTechBear (8/2/2012)
I really like your idea of a forum just for Accidental DBAs.
We have "Newbies" forums in all areas, or most of them. This was also the idea behind the "Stairway" series to help you get started in a few areas. Some of our books are also geared towards getting you up to speed in areas.
August 2, 2012 at 11:50 am
Steve Jones - SSC Editor (8/2/2012)
IowaTechBear (8/2/2012)
I really like your idea of a forum just for Accidental DBAs.
We have "Newbies" forums in all areas, or most of them. This was also the idea behind the "Stairway" series to help you get started in a few areas. Some of our books are also geared towards getting you up to speed in areas.
<HomerSimpson>
d'OH! :blush:
</HomerSimpson>
I must have had a brain fart. I should have remembered since I read them and have actually posted in one myself!
-----------------
Larry
(What color is your database?)
August 2, 2012 at 12:07 pm
IowaTechBear (8/2/2012)[hr Just as a good question to ask about a developer, "What would happen if xxxxx were to be run over by an ice cream truck? (I don't know why, but the past several companies that I worked for specifically stated an "ice cream truck".);-)
Larry
I have usually heard it as being run over by a Mack truck. 🙂
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply