Rookie Mistakes: Installing Everything
Prior to my coming to my current company, somebody had a great love of installing all SQL services on every server where SQL was installed.
This is such a pet peeve of mine, and frankly, it’s a rookie mistake. In my environment, almost all of our applications are off-the-shelf apps with minimal customization. Today I was looking at a web-based app that is an intranet type of collaboration application. The server had Reporting Services, Integration Services, Analysis Services, and Notification Services installed. This particular application barely makes use of the database services and is database agnostic. We could run this thing on Oracle or MySQL. It’s not going to need Reporting Services, and it certainly won’t need Analysis Services.
Extra services mean extra CPU and memory utilization. While it’s not much, these little things add up. And in case of the rare bit of malware that hits SQL server, only software that’s installed can be exploited.
In a perfect world, we would have an understanding of what our servers will be doing before installing the database server. Then we would install only what’s needed. Better yet, in my environment, the vendor’s installation instructions would specify what services to install. If SSRS, SSAS, SSIS, or SSNS aren’t mentioned, there probably is no need for them.
My boss might say “We might need them some day.” He’s right. We might need them some day. And when that day comes, we can install them. Until then, we don’t.
Congrats to the Winner
As Brent Ozar mentioned in his blog post, the winner of the all-expense paid trip to PASS is Jen McCown, aka @MidnightDBA. I’m really happy for her. Don’t get me wrong, I’m jealous as hell. Jen wanted this as much as I did, perhaps more. She produced a ton of amazing content, and the community is better off for the work she did.
I have a lot of good stuff coming up professionally. We’re planning on consolidating our database servers, and this should give me a ton of good stuff to write about. I’m really enjoying my time with SQLServerpedia.com and look forward to having the opportunity to contribute.
Mike’s Rule: Know Thy Data
At my former employer, I was hired to do database application support. I spent my first two weeks working with Debbie, our trainer and business analyst. I learned all about our project management system and met the key players. In retrospect, that was one one of the best things I’ve done in my career. It gave me an appreciation for the business.
Technology people have a tendency to focus on the technology that runs business and ignoring the business. That’s a huge mistake. As I said in a previous post, if you don’t understand the business behind the data, the data is meaningless. In that position, it was especially true. Construction financials are incredibly complex. It’s not just debits and credits. It’s left-side and right-side accounting. I was there four years and the concepts are still a bit blurry to me. Imagine writing a trigger, stored procedure or report against the COR table when you don’t even know what a COR is. (For those unfamiliar with construction, it’s a change order request.)
I’ve seen situations where an IT department will get a request from the business user and just farm out that request to a business partner to develop the situation. The business user knew they needed certain data elements but didn’t know where the data lived in the database. And the business user shouldn’t know, but the IT contact should. This led to countless back-and-forth questions. The time and budget overruns were embarrassing. The next request was mine, and I literally laid out every field, formula, constraint, and specification. The vendor was able to turn that around incredibly quickly with minimal review because they knew exactly what was expected. That was the result of rock-solid specifications by someone who knew the system and how it was being used.
Call me crazy, but I think that as a DBA, we should at least have a slight understanding of the data in our databases.
The Where’s Waldo of Red Flags
Not that I’m actively looking for a new job, but I like to look at my options once in a while.
I came across this posting on Craig’s List, and it’s looks incredibly fishy.
As a DBA, we’re part of a team. I just can’t imagine a DBA/sysadmin being remote 100% of the time. Even if the data center is hosted/remote, this just feels wrong to me.
What red flags do you see? It smells like a bunch of developers got together and built a monster, and now they need a DBA to keep it running. My red flag is that they have a major app with millions of rows in tables running SQL 2000.
Thanks to Tom LaRock for the title.
Non-DBA skills for DBAs
I’ve read a lot of good blog posts about things people look for in a DBA. A lot of those are skill-related. I think a monkey could do my job if properly trained. Here are a few non-skill related items I’d be looking for if I were hiring a DBA.
- analytical skills
- attention to detail
- aptitude for mathematics
- ability to document processes
- writing skills
- creativity
- problem solving skills
- ability to work with all levels of business users
- ability to translate technical concepts for business users
And if anybody in the Boston area is looking for a DBA with these skills, just let me know.
A Deep Breath
I started writing The Cranky DBA for a lot of reasons. One of them was to boost my professional exposure. One never knows when one will be looking for a new job.
In addition, I’d like to win the all-expense paid trip to PASS this year. The contest closes today. I’m not syndicating this post, so it won’t qualify for the contest.
My queue has been cleared. I will continue to post here, just at a more sane pace. Thanks for all of the feedback. I’ve found that I’ve learned a lot, just by writing about what I know.
Update on Combine
Where Does the Business Logic Go?
A few years ago, when I was at the utility company, we were implementing the new customer management system. This was the first time I had ever seen a system that implemented all of the business logic in the database. Most of my experience was with the logic being on the client application.
Which one is better? I really don’t know.
In the case of the utility company, the system was new, and this was one of the first large implementations of the application. We were rolling out changes almost nightly. If we would have to have upgraded the client nightly, it would have been a pain. Instead, we applied it to a single database server, and the business logic was taken care of.
At my last company, all of the business logic was in the client application, and rolling out a service pack or hot fix to the application was a pain. Not only would our hundreds of Boston users have to be upgraded, but we’d have to upgrade our Citrix servers as well. As well as we’d plan it, it was never as easy as one might hope.
In my current company, we don’t have serious desktop management, and our ERP system has business logic in both places. We could upgrade the desktops in a few hours if necessary. Most of heavy lifting is fortunately done in the database. This thing has nested stored procedures several layers deep.
Our document management system, on the other hand would be a nightmare. All of the business logic is done by the desktop application. And it’s installed all over the company. I cringe at the thought of customizing that application. Fortunately, we haven’t had to.
I go back to the question of where the business logic should live? I like having it in the database because then I can control it. It typically makes patching easier. At the same time, it’s a performance hit. There are more stored procedures and triggers. And yet, my database servers are typically more powerful than user laptops.
I have a feeling this is almost a religious debate, and we’ll never have a “right” answer. Your comments should be interesting, and I look forward to reading them.
Consolidation Planning
Last week, my boss handed me a gift. He asked our network admin and myself what our infrastructure should look like in the next six to eighteen months.
Right now, we have about 35 primary production servers. Many of them have a web/app server and a database server on them. I would love to do some serious consolidation. Our servers almost all fit into one of four generations, all IBM hardware, the 306, 346, 3350/3550, or the 3650.
In my perfect world, our universe would look something like this:
This is what I’m hoping to do:
- Consolidate all of the MS SQL database servers into three clusters. I need to segregate these by network segment.
- Consolidate all of the application servers into three corresponding VMWare server farms.
If we do this right, we can pull it off without buying many servers. Our existing 3350/3550 and 3650 servers are perfectly capable servers. They may need additional processors or memory. I’d rather spend the money on the right SAN and less money on servers. Imagine, consolidating your infrastructure down to half of what it is today!
My question to other DBAs out there is whether or not clustering is the right option here. I’m looking at clusters for high availability. The plan was to leave the servers as physical servers for now and then to virtualize them later. Or would I be better off to have them as virtual servers and leave the clustering to VMWare.
Thoughts on Being a DBA
I’ve been working as a DBA for about five years now, and here are a few observations I’ve made. These are pretty random.
- Most performance tuning issues are caused by bad design
- Vendors should have a DBA on staff to work with their developers
- I spend more time fighting with vendor database issues than things developed in-house
- Arguing with developers keeps your skills sharp
- Triggers are not my friend
- Implementing new systems is much more fun than babysitting existing systems
- I spend more time babysiting existing systems
- It helps to understand the application before diving into the data
- If you don’t understand the business, the data is meaningless
- Having a friend who is a business analyst can be helpful. They can explain what the application is trying to do.
- Vendors rarely comment their stored procedure and trigger code
- It helps to have a plan for when things go bump in the night.
- Things eventually DO go bump in the night
- Developers always want to use the latest and greatest technology. There is something to be said for that.
- There is also something to be said for using proven, stable technologies.