Voice of the DBA

Category: Blog

  • How Should We Pay People?

    It’s an interesting article on how to pay people from Dan Ariely at Business Week. It’s a look at some of the issues with paying for knowledge work, or work that isn’t well defined. The short version is that you don’t want to specify too tightly what you expect people to do, but then you have to motivate them to work in the best interests of the company.

    I think this is one of the fundamental problems in management today. We still have this mentality from the blue collar factory worker and piecemeal or easily measurable work items being applied by management to knowledge workers. It doesn’t work well, and somehow we think that the hours work in some way relate to the output.

    I blame lawyers. They tend to use this model, since they often bill by the hour. However the end result, the quality of that they produce, which is usually research, isn’t easily quantified in anything other than a win or loss. That often comes down to not only the soundness of the argument or the logic, but the charisma of the lawyer. That’s not even close to the way we do business in many other industries, especially technology.

  • Recovery Models

    In SQL Server we have three basic recovery models: full, bulk-logged, and simple. By default we find that most databases use the defaults, which mean that they are in the full recovery model.

    In that case, you need to be sure that you are performing log backups, otherwise the log will grow until it reaches it’s limits, or you run out of disk space on that drive. If the log cannot record SQL Server transactions, the database cannot accept any more transactions.

    The basics of recovery models are covered nicely in this article from Gail Shaw, which includes some common myths and misconceptions out there. However for the average person, the important thing is that you understand which recovery model to pick.

    You Need Point in Time Recovery

    Point in time recovery means recovery in between the full or differential backups. Quite a few DBAs will ask customers if they really need to recover to a point in time, and get the answer that they don’t, but that’s not often the right question to ask.

    Ask your clients if the database failed at 5:00pm today, and all the work done today was lost because you restored to last night’s backup at midnight, how would they feel?

    Sometimes they’re fine with the data loss, most times they aren’t. If you need to get back to a point in time between backups, make sure you use the full recovery model.

    You Can Reload the Database

    There are some databases, usually data warehouses, that can be rebuilt from other sources. If you take a backup of your database and then load data every day that rarely changes during the day, you might not need point in time recovery. In fact, many ETL processes are not designed for this anyway, and could not restart themselves in the middle of a load if you restored to the point in time when the database had an issue.

    In this case, use the Simple recovery model.

    You are space constrained with the log

    If you run index rebuilds, or large data loads and find yourself with a transaction log that grows very large, you might want to investigate the Bulk-logged recovery model. This model is more confusing, so I don’t want to give you a general rule here. If you think you might benefit from less logging, investigate the bulk-logged recovery model, practice restores with it and make sure you fully understand the implications of using it before you set a database in this mode.

  • Quick Recovery Techniques Webinar

    The slides for the SQLServerCentral webinar #13 are available here on the blog. Download them from the link below

    Quick Recovery Techniques PPT

    There aren’t notes in there, but if you have questions, let me know. The recording of the webinar will be up in the Training section of SQLServerCentral next week.

  • Decimal Data Types in SQL Server

    I learned something new about decimal data types in SQL Server recently. If you do something like this:

    DECLARE @d DECIMAL(10,10)
SET @d = 1.0

     

    You get this:

    Msg 8115, Level 16, State 8, Line 2

    Arithmetic overflow error converting numeric to data type numeric.

    That threw me for a minute since I’d never experienced it, but then I realized what was going on. The declaration of a decimal data type goes like this:

    DECLARE @d DECIMAL( @p, @s)

    Where we have

    • d – the name of the variable
    • p = precision, the number of digits in the number.
    • s = scale, the number of digits for the decimal

    You can think of this as the following,

    @d = nnnn.ssss

    Where the count of n’s and s’s must equal p.

    In the first example above, I’ve essentially declared:

    @d = 0.ssssssssss

    There’s no room for a digit, other than zero, to the left of the decimal. So you get an error. If I’d added one more digit to the p variable, like this:

     
DECLARE @d DECIMAL(11,10)
SET @d = 1.0

    I don’t receive an error. Likewise, I can add multiple digits to the other side like this:

    DECLARE @d DECIMAL(10,10)
SET @d = 0.999999999

    Works fine.

    I had never run into this because I don’t ever declare these the same. I almost always go larger than I need, and allow for more decimals. So for US money, I often declare things at decimal(10,3), giving me more space than needed. It pays to think ahead, and declare your variables properly, and understanding how they are structured is part of that.

    Note: this applies to numeric types as well.