Voice of the DBA

Author: way0utwest

  • Virtual Failback

    I saw a very interesting tweet from Scott Stauffer asking this: “… looking for quick’n’easy way to make workload virtual w/ fail-fast method to physical if performance doesn’t meet expectation.” This was part of a conversation Scott was having in looking to move to a virtual environment from his current physical one. That’s something I think more and more people are being asked to do, whether they do in inside of their own data center, or they move to some type of hosted or cloud environment. There is increasing pressure from management to consider using cloud-type environments to reduce the capital expenditures for new systems and move to an operating cost model.

    I don’t have a fundamental problem with cloud environments, though I think it is important to carefully consider the pros and cons, but I can certainly appreciate Scott’s concern. No matter how well we architect things or prepare for the movement of a physical environment to a virtual one, there could be problems. Having a fall back plan becomes important, and even more important if we discover problems when some time has passed.

    While there are utilities that can move a physical machine to a virtual environment, there aren’t any (or any I know of) to reverse the process. Honestly, though, I think virtualization has so many advantages, that if I really had performance issues and needed to return to a physical host, I’d continue to virtualize my instance, but I’d have only one VM on my physical host, with access to almost all the resources on the hardware. Today’s hypervisors have so little overhead, I wouldn’t hesitate to run one virtual machine on a host.

    Ultimately, moving to a virtual environment is very much like moving to new hardware. There are definitely different configuration options you may need to set, but you can contract for some help with configuring your system. In the worst case, just use a single VM on a host, get hardware abstraction, and manage the machine like any other. Just don’t forget to have the hypervisor and your guest start up automatically after a reboot.

    Steve Jones

    The Voice of the DBA Podcast

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

  • DLM Dashboard moves to 50 Databases – For FREE

    I love DLM Dashboard. It’s the product that I’ve written myself, in various ways since SQL Server 6.5. My versions weren’t as pretty, often scripts that ran queries, returning loads of data in text format, from queries, trace, or Extended Events.

    However there’s been a limitation that affected even me. When DLM Dashboard was released, it allowed you to monitor 5 databases. That increased to 10 if you registered, but that still wasn’t enough. I have 4-5 databases, many in a few environments, that I’m trying to monitor.

    I had a meeting with the DLM Dashboard team a few weeks ago, and we discussed a number of items, including the limitations. We debated the topic, and I got word recently that the limitation has been raised.

    DLM Dashboard now allows you to monitor 50 databases, which covers quite a few of your environments, and quite a few complete pipelines. I’d urge you to give it a try and download the product today.

    We understand some of you might need more, or that there are other features you’ll want. The team wants to hear from you on UserVoice, which you can also get to by clicking the "Give Feedback" link in the app.

    2015-10-23 09_22_34-Photos

    This is one of the best free products I’ve seen in a long time, and I’m excited that Redgate built it.

    Now I don’t have to at any other job in the future.

  • Using Automated Tests to Raise Code Quality

    Abstract

    Agile development practices can speed the development of applications and increase the rate at which you can deploy features for your customers. But unless you include a high level of test coverage in your code, these practices can also increase the number of bugs that are released. Databases can be particularly challenging for developers. This session examines database refactorings that introduce bugs, which are detected by automated tests. This approach allows developers to rapidly fix their code before a customer is affected.

    Level: 200

    Demos

    These are the demos shown in this talk.

    • Adding test data inline
    • Added test data in a procedure
    • Adding test data from a separate set of tables.
    • Exclusions to SQL Cop or other tests with Extended Properties.
    • Using FakeFunction
    • Using SpyProcedure
    • The boundary issues with multiple requirements for a function.
    • 0-1-Some testing
    • Catching dependencies.

    Downloads

    Here are the downloads for the talk.

  • Secret Software Security

    This might not be the best title, but I like the alliteration for a the problems we have when governments seek to prevent security researchers from releasing information about software vulnerabilities. This is nothing new, as vendors have tried to prevent this for years, arguing that criminals will exploit the information and target users before a patch can be built. The other side of the argument is that many software companies don’t bother building patches if the issues are kept secret.

    What might be different in this case is that we aren’t talking about database software, devices, or banking websites. Certainly those systems may need secure software, but here we have the US Department of Transportation arguing that security details about automobile software shouldn’t be released. There is some leeway in that potentially limiting details might satisfy the government, but apart from that, how do you feel?

    Many of us use vehicles every day. We might use private cars, but we might use public buses, trains, and airplanes, all of which are making more and more use of software over time. I don’t know, but I suspect, that much of this software is being developed with an eye towards ensuring it works as intended much more than with a view towards how malicious users might take advantage of vulnerabilities. Far too often it seems that we have new systems where control data is allowed to transit the same networks and computing structures as less secure data, with minimal security across the entire system.

    I certainly think that some researchers might not appreciate the dangers of random people experimenting with the issues they disclose, but I also truly believe that the pressures of getting software released overwhelm the concerns and dangers that exist overall. There are no shortage of people with time to spare, abundant computing resources, and substantial intelligence devoted to finding flaws in software. They work at “hacking” the system to change behaviors. While it’s a game to many, there are very real consequences to the world if strong security isn’t built into vehicle software.

    I don’t know that I expect much to change, but I suspect that we will see more and more issues over time, more lawsuits and more highly technical and forensic analysis performed when we a system is attacked. I can only hope that we actually disclose poor security practices so that vendors do learn that their embedded systems need better, and more secure, software engineering practices implemented.

    Steve Jones

    The Voice of the DBA Podcast

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