Voice of the DBA

Category: Editorial

  • Not Useless Features

    Some time ago I noticed Adam Machanic had written a post titled The SQL Hall of Shame. In it, Adam notes there are features that Microsoft will introduce in SQL Server and then let die. These are the useless features that aren’t widely used, or even useful for many projects. You can read his list, and agree or disagree.

    I think there certainly are some features that were silly experiments and I wish they had been introduced as experimental, or beta, features early, allowing users to give feedback on whether they’re useful and where they need refinement. I certainly think too many resources were initially wasted on items like MDW and Query Notifications, and far too little investment later. These days I think we’ll see more early releases of items in Azure where users can experiment and provide feedback to help Microsoft decide if more investment is needed. At least, that’s my hope.

    Today I’m wondering if you think there are features in SQL Server that do need more attention. Those features you use, but appear forgotten and you’d hope they are improved in the next version.

    For me, I certainly wish replication would get more attention, tooling, and resilience. I’m not sure if this needs an overhaul, like SQL Server 2005 was, or there just needs to be some reworking of the code, but in today’s distributed world, we need a more reliable way to hook up portions of databases and move data around. Not ETL, not Availabilty Groups, a better replication architecture and implementation.

    There might be other features you use or want, but let me know today. What’s a not useless feature that you want improved.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Certifying Schools

    We’ve debated the value of schools in technology careers plenty of times on this site. I have been torn on the value of schools, and I tend to go back and forth as to whether I’d recommend them for many people. Right now I tend to shy away from schools, mostly because I think the ROI is hard for a college. Working in technology can be a great job, one that pays well, but the cost of a degree seems high. Especially when there are plenty of ways that you can learn the same skills.

    I’m not saying that university makes you a better or worse developer or IT professional. I think that really depends on the individual. Plenty of smart people go through a university curriculum and go on to build great systems and applications. The same is true for self-taught individuals that learn on the job. Ultimately, you need to take responsibility for your own career, your knowledge, and your education, both in getting started and continuing as long as you work in this field.

    However, I do think that your responsibility also extends to researching and learning about the way in which you choose to learn. If that’s a school, be wary of their claims. I ran across this piece about a school that was fined for their marketing. They didn’t quite lie about the results from the curriculum, but they were deceiving. I think everyone should understand that finding a job can be hard in your area, especially when you are getting started. Whether you come out of a school of some sort, or you’ve been building your own projects. Ultimately, you need to convince someone you can do the work they need done in a competent manner at some reasonable price.

    Education has become a business, one where the profit and loss seem to be more important than the results experienced by their graduates. Some of the lack of success by schools is because students don’t make enough of an effort to become good at their craft. I see plenty of evidence of that, even in professional places, where workers aren’t learning to become better at their craft over time. That’s something we can all do, and it’s something I ask you to do on a regular basis throughout your career. However, some of the issues are inherent in modern curriculums.

    As we look for more secure coding practices, ask for more testing, and still see frameworks and platforms continue to advance, I don’t know if schools can keep up? I’d like to think that there are enough professional teachers that could update and alter curriculums on a regular basis, perhaps even every semester, to adapt to the changing workplace. I’d like to see more practical projects, still taught using basic, well known principles in computer science, but using modern platforms. That might change the nature of the professor in colleges, but perhaps groups of colleges should jointly develop curriculums and keep them current over time. There’s still a place for teachers to learn and bring their skills to teaching, but using information that is evolving too rapidly for one person to manage.

    I don’t know if we’ll get there, but regardless, each of you needs to look to improve your skills over time. Don’t expect that what you knew last year will be good enough for next year. Continue to learn, grow, evolve, and question the ways in which you build software and systems.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • We Need DevOps for Performance

    I read this nice piece on CosmosDB and setting performance levels. It covers how you set some level of performance for Request Units (RU) and CosmosDB handles the rest. Great, right? Set the level of performance you need and that gets handled. The question I have is how do you know what level of performance you need?

    This is one of the issues with the Cloud services that I see. It doesn’t matter if you use PaaS or IaaS, most of us really don’t know what level of performance works. We tend to guess, and far too many of us don’t use regular monitoring to decide if we are over or under powered. I find many DBAs and sysadmins would prefer to be over-provisioned and then let the server trundle along at a lower resource usage so that no one complains.

    When we move to a cloud type service, we tend to be more cost conscious, which makes sense when we’re paying by the minute. We want to minimum level of hardware we can get, but we don’t want to cause unnecessary complaints, either from customers because the system is slow, or from the CFO because costs are high. Using your old method of over-provisioning hardware (or DTUs) usually causes complaints from the CFO.

    The piece goes into some ways that you can start to evaluate your performance level for CosmosDB, and how to deal with throttling while you tune your RUs with a new application. This works great if you’re in a (more) greenfield area of development. Not so great if you’re lifting and shifting some application from another platform. Then we might need to ensure that we are responding quickly to issues, or better yet, have scripted responses that scale up or down.

    The same thing should be done for our relational systems. The Ops part of DevOps needs to be using monitoring and instrumentation to measure performance, adding capacity as appropriate, which should be before users realize there’s an issue. With today’s virtual systems, adding CPU and RAM usually is fairly easy, and it’s easy in the cloud as well.

    Of course, all this monitoring isn’t just to add capacity. Having a better sense of what’s going on can help you pinpoint poor code. Getting someone to fix that code becomes a lot easier if you can show that better code would cost less for our systems. It can be amazing how much more developers care about their code when the CFO gets involved.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Practice Until You Don’t Get It Wrong

    I wrote recently about a bad first day for an intern. He/she was fired, without cause in my opinion, when a production database was damaged while following a document for developer setup. The situation felt like a mistake, and one that wasn’t necessarily the fault of the individual. To me, this was extremely poor handling of the situation from a CTO.

    In the discussion for the piece, someone pointed out that it might not just be a new employee that makes a mistake that causes downtime. Certainly an unexperienced employee could have caused the issue, but I know there are people with lots of time in a position that make similar mistakes. It could be that someone that has been there a long time followed a poorly documented procedure, or applied the procedure to the wrong situation.

    In sports and the performance arts, I’ve heard a saying that says: amateurs practice until they get it right, but professionals practice until they don’t get it wrong. It’s the difference between just gaining a skill that you complete and continuing your learning to ensure that the execution of that skill is ingrained into your being. You internally build the muscle memory and skill to complete a task correctly over and over with practice.

    In the database world, this might be the difference between someone that has restored a database (the amateur) and someone that regularly practices restores of not only full database backups, but differentials and logs, tail log backups, filegroup restores, and more (the professional). The former has a skill, but the latter is confident and likely to complete the skill in a variety of situations without error.

    Practice won’t prevent mistakes, especially under pressure, but lots of practice does help us learn how to perform better. We learn what options are available, what issues might arise, and which choices we should be making. Just as professional athletes and musicians can make mistakes, we can as well. However, those mistakes should be rare. We should get most things right as the product of numerous hours of working deeply in, and understanding, our craft.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.9MB) podcast or subscribe to the feed at iTunes and Libsyn.