Voice of the DBA

Category: Editorial

  • Productivity and Accountability

    I think Yahoo's blanket policy was a mistake, but I can't say it was wrong.
    I think Yahoo’s blanket policy was a mistake, but I can’t say it was wrong.

    Recently Yahoo decided that remote work was no longer an option, requiring all workers to either begin coming into an office, or terminating their employment. As expected, it seems many tech workers were outraged, though more than a few noted while working at home is great, it isn’t the best thing ever. There is no shortage of articles that support the decision, and ultimately I think, as with most things in the database world, what you think about this “depends” on your situation.

    I’ve worked at home for over a decade; my wife for over two decades. In that time we’ve learned a few things. One of them is that telecommuting isn’t for everyone. It’s hard. We alternately struggle trying to stay motivated with understanding we need to stop working. We realize that the ability of telecommuting to work is job dependent. The more your job involves just you, the more likely it is that you can do it remotely. The more it involves collaboration, the more you’ll struggle to get things done. We have also learned that periodic face-time is important in almost all situations.

    There are numerous challenges that others have elicited with telecommuting, but the success or failure of remote work is measured no differently than it is in an office. If you are accountable for your productivity and complete all your work, you’re a success. If you don’t, you’re not. It’s that simple. It doesn’t matter if you work in an office or never leave your house. It’s about getting work done.

    The people that do well as telecommuters typically do well in an office. They’re just happier at home where they can juggle tasks. The people that slack off in offices, won’t do well at home. We might blame slacking off on being away from supervision, but my experience is that people that don’t want to work hard, don’t.

    I don’t think the Yahoo decision was a good one for everyone, but it probably was for some. I think telecommuting is a great way to build a small team, and get work done in an efficient fashion when jobs are discrete and easily defined, but ultimately employee success comes down to each person being held accountable for their work.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Two Plugs Away

    The office at Valve. Notice the wheeled desks.
    The office at Valve. Notice the wheeled desks.

    I’ve always enjoyed smaller environments, where people are more free to work in the way they want to, when they want to, as long as they are productive. I applaud the efforts of small companies to design offices or spaces where employees feel comfortable working and enjoy spending time. Some large companies do this as well and maybe this is necessary to offset the grind of long hours, but I believe the owners and founders of smaller companies often cultivate a friendly, close atmosphere and they hope their people to want to come to work. After all there are plenty of places one can work that will exact and demand long hours, often without any recognition of the hardships or without any additional benefits for your efforts..

    I ran across this piece on the culture and hiring at Valve, a gaming company that makes Steam and Half Life. They have a very free flowing culture, depending on the individuals to make good decisions for the company and their own teams. I’m not sure how scalable this is, or even how easily this can be replicated to other companies. As I’ve watched Red Gate grow over the years, it’s been an amazing place to work, but it’s not without some pain points. We’ve done well, though I don’t know that the ideas from Valve would work there.

    At the bottom of the article, however, I was struck buy this quote:  Everyone’s desk is on wheels. “There are only two plugs that need to be unplugged in order to shift from one team to another.” That’s an interesting way to design an office setup. Your desk is your desk, and you can customize it for you, but since it’s on wheels, you can move it if the need to change arises. That doesn’t happen too often in larger companies, but I do think the idea of virtual teams that come together for projects and then disband would work well in this environment.

    Even in the operational world, the option of periodically moving my desk and changing neighbors without the hassles of packing up lots of stuff, would be interesting. It would also make weekend practical jokes much more interesting. Imagine coming in Monday morning and having no idea where you desk, with all your stuff, might have moved.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Data We Don’t Want

    Filldisk.com might do this to your hard drive.
    Filldisk.com might do this to your hard drive.

    Don’t visit the FillDisk.com site, which I ran across a link to froman Arts Technica article that talks about a flaw in web browsers. It’s possible a security flaw, possibly an availability flaw as well. Apparently the new HTML specification allows for sites to use the Web Storage Standard to keep data on your hard disk. There is a limit in most browsers for how much data you can store per domain, but the FillDisk site uses sub domains to put random junk on your drive. The author of the site built this as a proof of concept and was able to add 1GB of data to an SSD on a laptop every 16 seconds.

    That’s a denial of service type attack that I hadn’t expected, but it is an interesting attack vector. I wouldn’t expect this to impact servers, but if servers are consuming web services, and using controls based on browsers, there is the possibility this type of attack might affect them. I’d hope this were limited to web servers and not impact database servers, but it’s certainly a concern if you have processes running on your database server that might retrieve data from a remote source.

    This makes me want to re-architect the way we build data driven application in the future, to prevent this type of vandalism. Maybe building an application level firewall that proxies all access to a database server. The idea of application servers was very popular a decade ago, but it seems few systems actually implemented this type of architecture. Perhaps this is because the web server/database server pairing is such an easy paradigm to build for most developers.

    Frameworks that allowed separation of the application through a middle layer could allow for caching of data in addition to more security. That could increase performance and scalability as the database wouldn’t be the single bottleneck for all requests.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Data Loss

    This piece was originally published in Database Weekly.

    Are SSDs less reliable?
    Are SSDs less reliable?

    Two words that no database administrator ever wants to put together are “data” and loss”. We go to great efforts to ensure that our SQL Server data is protected, backed up, available on alternate systems, even replicated to remote machines. Our goal is always to have zero data loss in all situations, even in those situations where we cannot prevent downtime from occurring.

    This past week an article at InfoWorld caught me eye with the phrase “solid-state drives suffer data loss” in the subtitle. The article is written about a study from HP Labs and Ohio State University that studied the effects of power loss on various SSDs. Using a number of “enterprise quality” SSDs from various manufacturers, the authors of the study cut power to the drives while they were in use, a scenario that I’d expect would happen periodically to systems. We reboot all kinds of systems at times without shutting them down at times, for a variety of reasons. I’d expect that file systems and low level software would properly handle these situations in a manner similar to SQL Server, with some sort of recovery running when power was reapplied.

    In the study, there were six potential failure types, and of the fifteen manufacturers whose drives were used, five of these failures occurred. The susceptibility of various kinds of corruption to power faults led the authors to conclude that systems with critical data should not use SSDs, test them thoroughly since they were not aware of ways to design a storage system to account for these potential issues. They did not say that SSDs were more unreliable than hard drives, but in this specific type of disaster, unexpected power loss, there could be problems.

    We can design around these issues somewhat with redundant UPSes, battery backing of SSD cards and more, but disasters in the form of an accident can occur. I’ve seen two occasions where large data centers lost power because of maintenance work on power distribution units resulted in improper fail overs. The more complex our system design becomes, and the more we use SSDs in databases, the more likely for some failure or corruption to occur.

    I wouldn’t panic and remove SSDs from systems, but I would ensure that any disaster recovery processes and procedures I had were up to date and working. You never know when you will need to recover from hardware issues on a primary system and have to restore on completely separate hardware. Advance preparations and practice are the only way to ensure you can successfully recover when the need arises.

    Steve Jones