Voice of the DBA

Category: Editorial

  • 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

  • Does Connect Work?

    Sometimes I wonder if the Connect bug reporting system is really working.
    Sometimes I wonder if the Connect bug reporting system is really working.

    I had a brief conversation on Twitter about the Microsoft Connect bug reporting system, and received the tweet pictured above. It notes: “I like how you used ‘Connect works’ in that sentence. Great work of fiction.” That made me laugh because it does sometimes seem that Connect doesn’t work all that well for those of us that use it.

    Connect was supposed to be a place where users could report bugs and make suggestions. Some people file a lot of bugs and suggestions, though more than a few seem slightly silly. Others file what appear to be support requests, and I’ve had a number of documentation notes. There are even Connect items filed on Connect itself, though I can’t understand why this particular one is “postponed”. There are some items that have been open for years, even with hundreds of votes.

    The Connect system is supposed to feed directly to product groups and there are more than a few times I’ve received feedback through the system from developers I know personally that provide comments. I know developers are seeing the items, but there appear to be a few times of year when the SQL Server group mass closes lots of Connect items, often without any feedback. The twitter conversation I had above included one of these items.

    I remember being excited when Connect was introduced, thinking this would be a good way to get feedback to the product groups, and hopefully influence the managers to prioritize some of the common requests. However that excitement was tempered with the idea that so many items would be submitted, and it would be hard to triage and rank them. Indeed, I rarely find something in the searches I make before submitting, even I’ll have submissions closed as duplicate.  The number of items submitted is so high, it’s hard to even comprehend how any group works with the submissions.

    With the state of Connect, the lack of feedback, and the mass closures, I’m not sure how well Connect is working these days. However it’s not all bad; I did submit one item that received enough votes to actually make a change in MS policy. Outside of that, I think @SirSQL’s statement might be closer to the truth than I would hope.

    Steve Jones

    The Voice of the DBA Podcasts

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