Voice of the DBA

Author: way0utwest

  • You Don’t Need Log Backups

    You don’t need log backups. You don’t. They aren’t required for SQL Server to function.

    The place when you don’t need log backups is when you have a database operating in the Simple recovery model. In this model, your transaction log will clear out on a regular basis, every few minutes, and the space will be reused.

    I saw a post recently where someone said they had a database that only changed once a day. Data was loaded once a day and otherwise the database was read only. In that case, you:

    • Need log backups if you are in Full or Bulk-Logged recovery models
    • Do not need log backups if you are in simple mode.

    It doesn’t matter how many changes you have, if you don’t have log backups in full recovery, you’ll eventually have an out of control log growth situation.

  • When To Touch

    It seems that every product that has an underlying database has documentation that says not to modify the schema?  Do you always pay attention to that warning? The PSS blog at Microsoft says that for Reporting Services you ought to definitely keep your hands off, and gives some good reasons why you should.

    However what about those other products? Dynamics, SAP, JD Edwards, and other common types of software that many companies use. Can you modify them at all? Perhaps.

    We hear about the build vs. buy debate in software, but there’s also the modify vs. workaround argument. I was reminded of that from the PSS blog. There are times that you might be tempted to change things in a database built a software company, or add objects to that database. In many cases this can be seen as action that voids any support contract with the vendor, and more often than not they won’t want to give permission to make changes.

    I can understand that, as it can substantially increase the support costs for a software company. However I also think that a blanket policy prohibiting changes is a bad idea.

    I think there are plenty of things that you can do, especially with the latest versions of SQL Server, that could be useful “touches” that improve the use of a database. Adding indexes judiciously to improve performance of some queries is one very light touch that can add tremendous benefits. Adding reporting objects in another schema could help you extend functionality to get more value from the software.

    Touching a database that you didn’t build should be done carefully, lightly, and with a lot of testing, and it can be something that creates a much more valuable system.

    Steve Jones

  • Rating Bugs

    Is this a big deal? Michigan is the wrong shape, reported on Connect as a problem with the Report Builder 3.0. I guess is depends on whether or not you are showing Michigan in one of your reports. If you are, it’s probably a big deal, and no matter what data is on the report, plenty of people will never get beyond the incorrect shape.

    Is this a critical bug? Is it a must fix for SP1? Does it deserve a high level of priority?

    Triaging bugs like this and assigning a priority has to be extremely hard. On one hand this should be a simple fix, but after the maintenance plan fiasco in SQL Server 2005 SP2, I’ve heard a few SQL Server developers say there are no “simple fixes.” However this bug is not critical to most people; it won’t cause downtime or data loss. For those people that need it, however, it could be extremely critical. It also a little embarrassing for any report that has the wrong shape visible in a map control.

    Should this be fixed before bugs that cause downtime? What if this takes 2 days and those bugs take 2 weeks? Or two months? You could easily get into the situation where a low priority bug keeps getting pushed back because there are more important issues to deal with. I’m not specifically talking about this bug, but rather using it as an example of an annoying, but otherwise non-critical issue.

    As companies work on software, I’m sure there’s some developer on every team that finds items like this one to be very annoying bugs, and would probably just fix it if they had time. Or permission. To me, this is a great reason why you ought to give developers some free time to work on things that they find interesting. My guess is many little bugs like this that can be fixed quickly, would get worked into the schedule.

    Developers like fixing things, and they like easy wins. Give them a chance to work on them.

    Steve Jones

  • Security Panics

    I went to host the Red Gate SQL Source Control webinar recently and had a snag. I downloaded the GoToWebinar software (why must I download this every time?) and when I ran it, I got an error.

    First it was a FireFox, “This security certificate is invalid” and I had to click the “I understand the risks” button to move forward. But then I got a dialog that said

    “This security certificate has been revoked”

    Now, a smart guy would click “cancel” because perhaps there’s some phishing or malicious behavior going on. Being in a hurry, I clicked “OK, move forward anyway, I don’t need no stinking certificates.” Maybe not smart, but it failed, so no big deal.

    Fortunately I had been trying to connect 30 minutes early, so I had time. I called Citrix, and they attempted a remote desktop session, which failed for the same reasons. We chatted for a few minutes and the tech support guy said that the certificate didn’t expire for years, and could I try another machine.

    I went out and was about to do so when I noticed that my clock said “8/19/2039”. It hadn’t registered before, but that time it did. 2039 is likely past the end of the Citrix security certificate’s lifetime.

    I reset my clock, and things went well.

    I’m not sure what happened. I used my machine early in the morning, took kids to school, and then came back to a machine that wouldn’t come out of suspend. I rebooted, and when it responded (some Java error on the screen, figures), things seemed to work. Except that the webinar didn’t.

    I don’t know what causes a clock to slide, but this actually happened last year one time as well. This is a Win 7, x64 machine, and it surprised me that I got this much drift, if 29 years is “drift”, but it did.

    On the bright side, the Win 7 year-changing dialog is kind of cool. You might play with it.