Voice of the DBA

Tag: sql server

  • When To Hire a DBA

    How busy should someone be before you hire a DBA?

    One of the things that I often see on SQLServerCentral’s forumsis a developer struggling with an administration issue or a complex query. It’s natural and even expected since many developers are not as familiar with SQL Server as they are with their development platform. It’s great to see them trying to get help and work through issues and there are many generous volunteers that give their time and knowledge to help.

    Recently I found a post where a developer was struggling with a variety of problems: design, backups, and more. It was obvious this person was overwhelmed and when someone suggested hiring a consultant, this person noted their boss didn’t want a DBA consultant, and wasn’t willing to hire a DBA. Management didn’t feel like there was enough work to justify a full-time employee.

    That’s an issue that I think many companies face. When do they hire a DBA and when is it beneficial for them? I’ve had this conversation before with employers, and while I’ve seen small companies benefit from having me as a DBA, I also know that I’ve contributed in ways other than just with helping with the database platform. I have helped administer systems, develop applications and more.

    I think part of this is the fault of the database professional, who has a stereotype of being difficult, stubborn, and resistant to change. It’s also hard for many database professionals to quantify exactly what they do and show explicit value for their services. They don’t build new features into applications, often don’t interact with customers, and regularly answer question with “it depends.”

    The ROI for a DBA is something that can be hard to explain to management, but it’s something that I think needs attention from all SQL Server professionals. If we can better explain our jobs, develop standard tasks and benefits that DBAs show, we can help ensure that more companies see the benefits and value from employing a DBA. If you have any ideas, please add them to the discussion for this editorial.

    There’s also a nice opportunity here for hybrid DBAs, the kind that come to conferences like SQL Server Connections. Doing a little developer alongside your DBA work might get you some jobs in smaller, more flexible, and more fun companies.

    Steve Jones

    The Voice of the DBA Podcasts

  • Showing Its Age

    Are these computer too old to be in production?

    I went to register a new car recently at the DMV and couldn’t do it. Apparently the state DMV system in Colorado was down that week, and had been down for two weeks because of a DR situation. The primary system had failed, and after being down, the state agency moved to their older, backup system. However when that failed, many of the remote offices were down and were issuing extensions to car owners for registrations.

    I am guessing that the Colorado state DMV system runs on some sort of mainframe or mini, and not on a 15 year old PC architecture. However I do know lots of companies that are working on older software, often on older versions of Operating Systems that might struggle to work on newer hardware. It makes me wonder if we will start seeing these types of problems for database applications over time as companies look to extend the lifetime of their IT infrastructure.

    There was a time when it seemed many companies were refreshing servers every 2-3 years, and they would upgrade to a new version of their OS or database platform whenever the vendor released it. However the last 5-6 years have seen many people holding on to older systems. I know lots of companies that are on 4 or 5 year hardware refresh cycles, and there are still lots of SQL Server 2000 instances still running out there.

    For awhile it felt like keeping a database application alive for 10 years was a stretch, but as I look at the evolution of SQL Server, and the power that we have with modern hardware, it doesn’t seem like a stretch. The advances in virtualization can prevent newer hardware architectures from being a problem, and perhaps even extend the lifetime of old software significantly.

    I do think that the latest releases of SQL Server are much, much more efficient and powerful than previous versions. Today’s hardware can even be more cost effective given the price of power and cooling. However if all you need are core database engine features, I’m not sure it’s worth upgrading. Just be sure that you have a better backup plan than the CO DMV.

    Steve Jones

    The Voice of the DBA Podcasts

  • PAAS

    Will we get a real platform in the clouds or just virtual machines?

    When I hear people talk about the “cloud” I often find that I have a different view of what “cloud” means.  What is a cloud? How is it structured? There are all sorts of definitions, but in my mind I have thought of the cloud as a service I can use, just as I use the web. My browser works with any kind of hardware, and software, as long as it handles the http spec.

    In my mind, that’s what I expect with a cloud database service. It conforms to what I expect in a SQL Server database, allowing me to deploy my data and objects, and expecting that I don’t need to worry about a database name, or configuring Windows logins, or even worrying about scaling up from 4 to 8 CPUs. I’d expect that the cloud would handle this fairly invisibly.

    There’s an acronym called PAAS, which is Platform as a Service, and it’s analogous to SAAS (Software as a service) and IAAS (infrastructure as a service). The idea is that an application platform exists in the cloud and you essentially upload your code, allowing the provisioning, scaling, and other details to be handled by the platform is interesting. This article talks about PASS solving lots of developers’ problems, but I think it’ s a little premature to think that this is the best solution for many types of businesses.

    I do hope that we find a way to smooth the deployment and access for our applications and services for both companies and consumers. It does feel that we spend a lot of time covering up for the inefficiencies in our entire application development and deployment life cycle. The cloud has some promise here, but it has to be more than a Windows host that runs on someone else’s hardware. It has to truly handle much of the complexity and abstract  us away from those details, in a secure, safe way.

    Steve Jones

    The Voice of the DBA Podcasts

  • Why Use the Principle of Least Privilege?

    This SQL Injection could be a problem in data entry

    SQL Injection is not the fault of the SQL Server. Brian Kelley pointed that out, and reminded me that SQL Injection isn’t an case of malformed SQL. It’s legitimate code, including SQL commands that we might use from any query connection, especially an administrative one. We regularly issue update and delete commands from our applications, and SQL Injection takes advantage of this to issue an update the we might not be expecting.

    Would you expect this input handwritten injection from an application? Or this table guessing attempt? You wouldn’t, but they can come through data entry in your application if the input isn’t well sanitized. Someone setting all your prices to $0.01 or all of your customers to “W3 0wnz U!” isn’t what you want to happen. You can’t necessarily prevent all of these patterns  or check for every permutation, but you can prevent things like ‘shutdown’ or ‘drop table’ from being run by your application. Even adding a new user to the database system isn’t something I would want to allow.

    Education is the key here. As Andy Leonard (blog | @AndyLeonard) would say, design patterns are important. When developers have an understanding of the issue, many of these things will be avoided. Having standard ways to begin building an application, checking for bad input, and setting up database users and permissions easily, should make this easy for anyone that wants to code against a database. We still have work to do here to build better frameworks, and ORM tools that require elevated permissions to the database are not the answer. They might become the answer, but they aren’t a better solution right now.

    Grant Fritchey wrote a nice piece about developers and DBAS, noting the need that we both have the same goals, but need to learn to communicate better.  This is one area where we ought to make an effort to communicate better, pass along education about security issues, and work to make life easier for developers to work with a database.

    That also means teaching them to work with the minimum privileges needed in order to make an application work, just in case someone plans on submitting some input you didn’t expect.

    Steve Jones

    The Voice of the DBA Podcasts