Tag: databases

  • Data Gravity

    gravity
    Does data have gravity? And will it affect DBAs’ jobs?

    Many of us have worked with distributed applications at this point in our careers, with different parts of the application located on different physical servers. Some of us might have worked with applications that actually have different servers in different locations, potentially even different countries. That can be challenging, dealing with different time zones, different collations and regional settings on servers and more.

    While many of us are not looking to implement cloud computing now, we may do so in the future, but not for simple cost reasons. There’s a piece about data gravity in the cloud, and how the law can drive the location of data in some cases. Just as many companies that wanted to offer gambling services moved to countries with fewer laws about that business, I would expect that we see some companies moving pieces and parts of their data to other countries to take advantage of more lax or lenient privacy or other laws in the future.

    Most companies won’t bother trying to avoid laws like this right now, but at some point in the future, the cost of moving an application to another country might be tiny. We constantly build better tools for distributed development, deployment, and management, and whether it’s a cloud infrastructure, or just a rented VM, we may find that it becomes worthwhile in some cases to move data, not just for cost reasons, but potentially to reduce the costs of compliance with local laws.

    It’s hard to know whether compliance with the law will ever significantly affect the work a DBA does, but I certainly expect that we will have distributed applications with their various components more widely distributed to challenge us in the future.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Data Resolutions

    Happy New Year

    Making a new year’s resolution is an annual tradition for many people on January 1. Breaking those resolutions seems to be another annual tradition that often takes place during the month of January as we struggle to live up to the changes that many of us often want to make in our lives.

    It’s the last Friday of the year, and rather than ask you about the resolutions you are making overall, I wanted to ask this question:

    What would you like to do differently in your career in 2012?

    It’s easy, and I hope it makes you think a little about where you want to go ni the future. Are you looking to move to a new job, a new kind of work with SQL Server? Do you want to learn more about some aspect of SQL Server? Do you want to get out of technology?

    As you think about what you might do differently in 2012, it’s not always about growth. Perhaps 2012 is a year where you slow down a bit and maintain some skills, or even reduce your hours as you spend time on something outside of work.

    For me 2012 will be a slower year. After attending over a dozen events in 2011, I am planning on many fewer in 2012. My wife’s career will take a little more precedence over mine, and I’ll concentrate on writing more, and bringing you more news, knowledge, and training as SQL Server 2012 is released.

    Happy New Year, be safe and responsible over the weekend and I will see you in 2012.

    Steve Jones


    The Voice of the DBA Podcasts

  • The Year in Review – 2011

    Big Data and The Cloud were a large part of 2011

    It’s the end of the year, and I’m taking a look back at 2011 from the data perspective. As we close out the year, it’s apparent that “big data” has been catching on with many companies. It seems that every week we have some headline that talks about “big data” in some way. Even Microsoft has joined in with  their work with Hadoop and SQL Server.

    The other big push in 2011 seems to have been “the cloud”. It’s everywhere, from consumer Windows 7 commercials to the updates to the SQL Server tools to support the SQL Azure platform. I haven’t found many people that are excited about moving their databases to the cloud, but more and more people are testing the platform, and I suspect we’ll start to see some apps that don’t require high security or extremely high performance appearing in the cloud in 2012. I have embraced the cloud in many ways over the last couple years (EvernoteDropboxLive Mesh) and I find it to be an advantage in managing a busy life.

    We had our share of high profile data breaches as well, with some very high profile ones, including RSA, the security vendor. We could add in the Carrier IQ fiasco, which showed a little abuse of consumer trust with the debugging code they developed.

    A few other notable items in the data world for me. The first was the death of Steve Jobs. While most of us working with SQL Server don’t use Apple products, the changes that Steve Jobs brought to the world, most recently the iPhone and iPad, have altered the way we consume data in many facets of our lives. The second item, was the split of Netflix into two businesses, and the failed idea that splitting our online and physical DVD data into separate sites wouldn’t be an issue. The reversal of that decision showed me just how valuable centralization is for many consumers.

    There were many stories that touched data in our lives in 2011, and it seemed to be a busier year than ever before for me. However one large milestone for me was the 100th SQL Saturday event in Brazil. It’s hard to believe there have been 100 events, with 45 events in 2011. Seeing the SQL Server community come together to embrace, help, and inspire each other, both online and off, has been amazing. If you haven’t tried to interact with others through LinkedIn, Twitter, Google Plus, or some other social media, I urge you to try in 2012.

    I hope that you have had a great 2011, and I look forward to an even better 2012.

    Steve Jones


    The Voice of the DBA Podcasts

  • The Layman’s View of a DBA

    I wrote this piece as a guest on Bradmcgehee.com for the DBA in Space competition. Republishing here.

    A DBA (Database Administrator) is someone who takes care of your data. When you place an order on Amazon.com, it’s the DBA who ensures the order is permanently recorded in the database. If one of the computers at Amazon fails, and they regularly do, the DBA can recover the data. The DBA should be the person that prevents part of your order from getting lost because it’s incorrectly recorded, and it’s the person that makes sure that if you update your address, the change is recorded so your purchases reach the right destination.

    A DBA makes sure that the transfers between your bank account and other accounts are completed in full, without allowing the deduction from your account to occur without the credit arriving in the destination account. DBAs try to ensure the data that appears on your bill is correct, and that if you change the name on your account, the change is reflected in your statement.

    DBAs are like the local librarians, keeping track of all the various words and numbers in their library and knowing where everything is. They are the custodians of information in databases, trying to keep it all organized, intact, and available for access. DBAs are not perfect and they can make mistakes which result in the mistakes we occasionally find on bills or statements.

    However, DBAs don’t act alone, and in many cases their job is directly affected by other people. The websites you use, or the applications on your computer or mobile phone, are written by developers that decide how you enter or read the information, and how the data moves into or out of the database. These developers sometimes do not have the proper training on how to store data to prevent mistakes, or how to clean data to fix incorrect entries, resulting in bad data outside of the control of the DBA.

    In addition, the connections to databases are often managed by system administrators or network professionals who also deal with failures. When you cannot access your account on a website, it’s entirely possible the database is running and working fine; the problem is in the connection between the website computer and the database computer.

    The DBA’s role is often taken for granted. If everything works as expected, it appears the DBA is not doing any work, or adding any value to their company. This may be why so many companies forgo hiring a DBA and expect their developers and system administrators to manage the databases. That’s not usually the case as the work a DBA does is designed to prevent problems, and be available to fix the inevitable issues that will arise.

    The DBA is a preventative mechanic, working on your car every day and night when you aren’t using it, ensuring that it is working when you do need it. They’re the behind the scenes staffers that coordinate and organize the concert or play you enjoy, unaware of just how much work goes into providing you with an enjoyable experience. The DBA is the glue that binds so much of our technological world together, helping to ensure that all parts of the system know what should be built, sent to who, and when it should arrive.

    Read more: http://www.bradmcgehee.com/#ixzz1fnp9rH1k
    Under Creative Commons License: Attribution