Voice of the DBA

Category: Editorial

  • The Test of Time

    I'd like to build a "smarter business" that will last for 100 years.

    IBM turns 100, and in this article, they brag about bench pressing more other companies half its age. That’s a great headline, and I still remember when IBM was not only the premier hardware vendor of the computer world, but also the largest software maker as well. The “Smarter Planet” ads that IBM puts out there are great, and they are a diverse company, covering so many different industries and locations that it’s hard to comprehend everything they are working on.

    The culture and mission of IBM has changed in 100 years, but it’s still amazing that the company has survived. I think back to the tech companies of my youth, and many of them are gone. Who remembers 3COM? Anyone set up a Wellfleet router? DEC becoming Compaq, and now HP. Apple is still around, but Sun Microsystems is disappearing into Oracle. Microsoft is only 30 years old.

    I once worked for a hundred year old company, one that embraced and remembered it’s history, even as it evolved in the modern world. The President of the company had worked there for his whole career, taking over for his father that had worked there almost his whole life and still came into the office a few days a week at age 80. There was a sense of history, tradition, and pride that kept people working there, with the vast majority of the company having worked there over a decade when I was hired.

    The modern world is fast paced, rapidly changing, and evolving quickly, but there is something to be said for adapting to fit in, while maintaining your mission and ideals. I hope that more companies would look beyond their next quarter or year and make the attempt to build a business that they are proud of, and can survive a hundred years into the future.

    Steve Jones

    The Voice of the DBA Podcasts

  • Cost of the Cloud

    Will we get real time costing of our cloud computing?

    One of the benefits of moving to a cloud infrastructure for IT services should be a reduced cost. The economies of scale for having specialized staff, licensing, etc. are more evident when you have more of everything. The larger you are, the more efficient you ought to be. For some companies, this can be achieved internally because they have such a large number of computers, but for many companies, I think they seriously struggle with the cost of staff and infrastructure for technology.

    A company that looks to build a technology infrastructure has to make an investment and across a short period of time, they are locked into the hardware that has been purchased. Often we find individual departments are unsure they are receiving a fair share of the IT services, which has resulted in large chargeback systems being implemented that usually have a lot of overhead.

    Microsoft appears to be trying to deal with this in an interesting way. It has collected, and published, very detailed data on how the services in its data centers are being used. These are essentially a private cloud for many business units at Microsoft, and the ability to see how costs are being spent in applications, services, even help desk tickets, which can drive behavior.

    Developers now have an incentive to build better applications, since the cost of a poorly performing application is more easily determined. I would even assume that accounting for metrics in development environments should help people test different solutions, and perhaps even start to determine when one should spend more time optimizing code and when someone should allocate more hardware.

    I don’t know if other cloud computing vendors will start to offer detailed use analysis and charges for the use of their services, but I expect that if they did, it would be something that many CFOs, and CTOs might want to see in analyzing the value they get from their public, or private cloud infrastructures. I know that I’ve found value in all the detailed metrics that we get in costing SQL Server queries through DMVs, wait states, and other metrics, which can certainly help one write code much more efficiently.

    Steve Jones

    The Voice of the DBA Podcasts

  • Regular Audit Analysis

    Do you regularly review audit data?

    I was reading over a digital supplement that I received from Dark Reading recently, which details some of the issues in the Epsilon, Gawker Media, and a few other data breaches. It was light on details, but there were some nuggets of knowledge in there about how these attack occurred. Some were sophisticated, and some were insider attacks, but the advice given to help protect your data was all similar: limit access, watch for injection, audit, and monitor.

    I know that over the last decade as I’ve run SQLServerCentral, the topic of security and auditing has grown in importance. More and more people are implementing auditing functions in their applications and slowly tightening security where they can. There is a lot of work to do, and a lot more education that needs to be spread to a wider audience, but the trend is positive.

    However one thing in the article caught me eye, and it had me wondering how many people are going beyond the basics. For those of you that have auditing built into your application or database, I have a question this week:

    Do you regularly analyze the audit data to look for abnormal trends or access?

    All the data in the world doesn’t have any value if it’s not used. In a security context audit data isn’t all that useful if it’s only examined when an incident is discovered. The real value in auditing data is the ability to uncover problems before they occur. Looking for inappropriate access, unusual access for a particular individual or application, or even repeated attempts to gain access can help prevent a data breach.

    After all, catching the criminal later doesn’t necessarily mean you’ve “recovered” the data. Unlike physical objects, data can easily be copied and spread in way that prevents it’s complete recovery.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Age of Software

    Do you use old software?

    Does the age of software matter? It’s an interesting question and one which recently came to my attention after a blog post by Dan Jones. Dan works on the SQL Server team and posted a note that the SQL 11 (Denali) tools would only be supported on certain operating systems, of which Windows XP was not one. In the comments on his post it seemed that there was a split in how this decision was viewed by readers, with a number of people saying that a ten year old OS didn’t need to be supported and should be upgraded.

    However, in my mind, the age of the OS isn’t an issue. If the OS still works for you, there’s no problem running it. My wife’s company has the majority of their users on XP, and she just received a new laptop with Windows 7 just a few weeks ago. There wasn’t any fundamental reason for the change, as all their business applications work fine with Windows XP, but as new hardware is purchased, there often are not XP drivers, so employees are slowly moving. That seems to be the case with many companies, who find XP to be a very solid OS for most users.

    However for SQL Server, I agree with the decision. The test matrix for SQL Server tools is likely huge, and they are supporting two desktop operating systems (Vista and Windows 7) as well Windows Server 2008 and Server 2008 R2. I would rather that the resources working on adding features, and fixing bugs in SQL Server, not be diverted to working on XP or Windows Server 2003 as those are too old. Not old in age, but old in versioning, being more than a version behind the current operating systems.

    I know there are a lot of people that are not happy with this, and I can understand their reasoning, but I just don’t think that the number of companies that want to go to SQL 11, and are unwilling to allow developers and DBAs to upgrade to Windows 7 is large. Personally I’d rather have more resources devoted to more exhaustive testing on the current set of operating systems and fixing any bugs that are found.

    Steve Jones

    The Voice of the DBA Podcasts