Voice of the DBA

Category: Editorial

  • The Employment Contract

    I ran across this piece on how we should pay people from Business Week. It’s a look at the issues of specifying the exact work that someone will do once you hire them. I suspect this is a problem in many industries, but it can be especially tricky in technology, where the job requirements can change as the technology rapidly changes.

    Most of the time I’ve taken a job in the US, it’s been an “at will” employment, with a verbal contract between me and the hiring manager or HR representative. Nothing was signed, and I essentially did whatever my manager wanted, regardless of my job title. That was fine with me. Currently I have a written contract, but the requirements for my position are a little vague and my duties aren’t explicitly spelled out.

    However I wonder how most of you feel. Does it make sense to more explicitly list the requirements for your job? As a DBA, developer or other professional, would you want any limits on what you were required to do?  This Friday, answer this poll question:

    Would you like to have your duties spelled out explicitly in a contract?

    I know we don’t typically sign contracts, but would you like that? What if the duties were modified every quarter, with an agreement by both you and the management of the company? What if you could just list the things you were not required to do?

    Let me know this week what you think.

    Steve Jones

    The Voice of the DBA Podcasts

  • Not So Unbreakable

    Nothing is unbreakable

    There’s a report on Dark Reading that says some researchers think Oracle is not working on security as hard as they should. The proportion of security fixes has diminished, which some people think implies that they are not taking security as seriously as they should. The window of time between the disclosure and the patch has grown wider, which is troubling, especially when newer software displays vulnerabilities.

    I’ve been proud to work on SQL Server over the last 6 years from a security perspective as there have been very few security patches issued, and correspondingly, few vulnerabilities disclosed. It’s possible Microsoft has muzzled some researchers, but I doubt it. I would guess that if any serious security issues existed in SLQ Server 2005, 2008, or R2, we’d have heard about them. I think the security engineering process that is used for SQL Server has truly resulted in more secure software.

    It’s possible that Oracle faces a resource issue with all their acquisitions, but for a billion dollar company that employs over 100,000 people, they shouldn’t be having resource issues with their development process. It’s a question of accepting greater development costs in order to ensure their software is secure.

    This is one area where we ought to have independent security researchers that can discuss, debate, and disclose vulnerabilities, after a limited amount of time. That would help us at least understand the security risks we face, and perhaps pressure companies to build better software.

    Steve Jones

    The Voice of the DBA Podcasts

  • Sharing Your Database Server

    Is it time for a little more sharing in the database world?

    Some of the details for SQL Server 2012 are out now, and as expected, we have feature limitations in various editions. I was hoping for a change, and maybe it will come at some point in the future. I did expect there to be scale limitations and there are. As noted here, the Standard edition is limited to 64GB of RAM. It wasn’t too long ago that I would have considered that high a RAM limit to mean I’d never need Enterprise Edition, but these days I am finding more and more database servers with 32GB, 64GB, and more RAM inside them.

    The post notes that the buffer pool will not grow beyond 64GB, though it doesn’t mention limits in any of the other memory spaces that SQL Server uses. However assuming that the memory outside of the buffer pools scales, it might be time to think about installing extra instances of SQL Server on a single host if you are licensing by the core. With a commodity server costing under $10k with 6 cores and 96GB of RAM (no HDDs), one could easily consider placing 2-3 SQL Server instances on this hardware with each getting 24+GB of RAM.

    I think that virtualization is the best way to share physical resources, but the changing licenses for SQL Server 2012 might have a few of us rethinking that, especially as we consolidate legacy systems that might happily co-exist on a larger physical server, with smaller data sets, lower hardware requirements, and a cheaper edition of SQL Server.

    Steve Jones

    The Voice of the DBA Podcasts

  • Layers of Security

    Every little bit of security helps

    I haven’t configured many firewalls in my time, but if I were doing that job, I’m sure I’d be included in this report that says half of all firewalls are improperly configured. Firewalls are confusing, complicated, and it’s incredibly easy to make a mistake when you are dealing with the complex rules of Windows networking and various application requirements. These days I call a friend, who’s a firewall expert, to do any changes for me, and let him implement the rules. It’s a slow, annoying process to watch, but I also understand that it is complex task, and he does a much better job than I’d do. Probably because he’s more patient.

    For the database administrator, however, this should be a wake-up call that lets you know you can’t rely on the firewall to protect you. If you have a small 3 machine, one subnet network, maybe, but in most enterprises there are many subnets and complex rules to implement. That means that your company might not be a soft chewy center protected by a hard shell. It might be a soft center protected by Swiss cheese that does little to limit the influx of unauthorized requests.

    Good security involves lots of strict policies, strong passwords, and many layers. Depending on someone else to provide security for your database instance is not only a bad idea, it could be a reason to remove you from your position. Good administrators, and developers, will ensure that they enable security on their servers, limit access to authorized users, and grant appropriate rights.

    It’s a good habit to get into, and it’s good practice for developing an application that will remain secured once it’s deployed.

    Steve Jones

    The Voice of the DBA Podcasts