Category: Editorial

  • The Importance of My Cloud Data

    I recently rebuilt my laptop, and when I installed Office, there was an offer to sync my Office data up to the cloud. I declined since I already use Live Mesh to sync data across multiple machines, a Windows Home Server for local backups, and Dropbox for remote ones. It’s not that I don’t like the cloud, but that I’m not sure I, Steve Jones, can trust the cloud.

    There was an outage at Hotmail recently that involved SQL Server. That’s bound to happen as the larger you are, the more likely it is that you will have some sort of failure.  It’s inevitable, and hopefully you have done enough planning to recover quickly. I don’t know where the Hotmail team failed, but they certainly failed somewhere.

    The cloud works because it provides some great economies of scale, a much more efficient use of computing resources. For many people, that means it can also be a much cheaper way to get the services they need. Even companies could do find advantages in using cloud-based services.

    However this outage shows one of my major concerns. It’s not that I find Hotmail unreliable, or that I worry about security. It’s that when something breaks, and it will, I’m not sure Hotmail will care a lot about my data. If Steve Jones, Inc., a company paying Microsoft $1000 a year for mail, Office, etc.,  winds up losing 3 days of service and 1 week’s worth of data, will Microsoft care? What if the same failures affect a large company, one that pays Microsoft $1,000,000 a year? Whose data will they work harder to restore?

    Ultimately economics and realities set in. Microsoft, and every single other cloud provider out there, will worry about the larger customers first, and perhaps not even bother to finish restoring data for the smallest ones if there is not enough cost benefits. They might even refund the payments of someone to compensate them.

    If it’s my data, however, I’m not sure that’s good enough. I’m also not sure it’s a risk I want to take.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72146/)

    Podcasts

  • NoSQL Basics

    Last year there was quite a bit of press devoted to the NOSQL movement, emphasizing the scalability and power of this class of databases. They have not been well known, but have been used to power some of the very well known Internet companies out there. Companies like Google, Facebook, and others are using NoSQL databases in places, achieving the scalability that many RDBMS’s have struggled to achieve without enormous costs.

    I ran across an article that talks about some of the basics of what is classified as a NOSQL database. It’s written more for managers, and it does a good job of warning them that NOSQL is not the “answer” to all your performance problems. It’s a piece of technology that fits in some places and in some situations.

    Should you care about NOSQL? I think you should, if for no other reason than some manager will ask you about it at some point. Or a developer will want to build an application using a NOSQL database. A flat “no” from the data group is counter-productive,  and is not appropriate. If you are going to rationally argue against a new technology, you should have some basic understanding of how it works, what problems it solves, and engage in a logical debate.

    There are lots of good NOSQL articles out there, and perhaps the first thing you should learn is that there are different types of technologies for solving different problems. Cassandra is not interchangeable with MongoDB, and Voldemort is different from the other two. None of them is a direct replacement for SQL Server (or another RDBMS), but they do work in different areas. If you’ve never seen the CAP triangle, take a look at it now.

    Many of you are data professionals, and SQL Server specialists, and that’s fine. That doesn’t mean you shouldn’t learn a little something about other technologies, and how they might compare and contrast with SQL Server. Here’s a nice basic article from SQL Server Master to get you started.

    Steve Jones

    (originally published at http://www.sqlservercentral.com/articles/Editorial/72127/)

    Podcasts:

  • Data Loss or Downtime

    I was watching Kimberly Tripp of SQL Skills talk recently about VLDB disasters and how to recover from them. One of the first things she said in the session was getting a damaged database back online, even without all of the data, was important. Often her clients need to keep working, and it is important that they get the system back online, even without all the data. This allows business applications and business people to get back to work.

    That is interesting. I had always thought of my production OLTP databases as needing to be online, but also needing all the critical data. After Mrs. Tripp’s talk, I had to rethink that a bit and consider that a little data loss might be acceptable.

    To me this is a topic that is worth understanding. At the very least, it will help you make decisions in the event of some disaster for how you will proceed. So for this Friday’s poll:

    So what is more important to you: downtime or data loss?

    My feeling is that most of the people would really rather have the database online, even without all the data so they can continue to work. I realized that most of the time, getting the site back up, having lookup and other types of ancillary data (like products, prices, etc), was the most important thing. Recovering other data such as older orders, was secondary.

    Once the database is up, you can then work on getting other data back and merging it into the production system.

    Let us know what you think this Friday and what’s more important to your business (and why).

    Steve Jones

    Originally Published at http://www.sqlservercentral.com/articles/Editorial/72117/

  • In Case of Breach


    What would you do if you received a phone call in the middle of the night saying that one of your databases had been hacked and data released? Do you know what to do as a first responder? There’s a report from Dark Reading that talks about some of the things you might want to consider.

    Crisis situations, and this is definitely one, require some planning and thought ahead of time. You ought to have some sort of “run book” similar to the one you have for disaster recovery, that helps you decide how to handle the situation. Unlike many troubleshooting situations, rebooting a server might be the worst thing you can do.

    I used to think that database people were more insulated from responding to these types of crisis situations. It seemed early in my career that we would be backups for the system administrators, and not necessarily need to respond to a midnight call. However the last 5 years have shown that this type of call is more and more likely for all data professionals.

    As we store more and more data, of great importance to the organization, we should be more prepared to respond to these types of incidents. Financial, identity, medical, and other types of data are becoming mixed in with all sorts of business data. As we build warehouses and transfer data among more systems, the likelihood we have data needing strong protections increases.

    At the very least, we must educate ourselves on our legal responsibilities as the data profession moves forward. More and more laws are being passed and regulations applied to data, and a good data professional in the future needs to be aware of their responsibilities in this area.

    Steve Jones