Voice of the DBA

Author: way0utwest

  • Rebuilding the W510 – DVD Driver Issues with x64

    I backed up my machine, copied a bunch of data to both a thumb drive as well as the second hard drive on my W510, and get ready to install Windows 7 x64.

    First I had to add memory. I had put 8GB in the bottom slot, but to replace the 4GB with 8GB in the top slots, I had to remove the keyboard. It’s actually easy, unscrew two screws (all the way out), pop out the keyboard, and then replace memory. The underneath slot is hard to reach, but it only took me about 5 minutes to upgrade to 16GB.

    Now time for Windows. Nervously I put the x64 image in the DVD drive (replacing it in the 2nd bay) and booting. Windows setup loaded and started and….

    Stopped. No DVD driver found. Slightly amusing to me since I had booted from the DVD drive. I tried again, and then went downstairs to search the ‘net. I found a few references but no drivers. The drivers on the Lenovo site were an install, which won’t work during setup. I downloaded Intel drivers, but those didn’t work. To top it off, my laptop was now not booting into the old Windows, saying I needed to run repair. I suspect setup has some boot files there, but now I was really nervous.

    I read on a Lenovo forum that someone had a similar issue and fixed it with a new .iso download. So I burned a new Windows x64 DVD from MSDN and tried that. Success!!

    Now the install is running and my fingers are crossed. We’ll see how well this works.

  • In Case of Breach


    What would you do if you received a phone call in the middle of the night saying that one of your databases had been hacked and data released? Do you know what to do as a first responder? There’s a report from Dark Reading that talks about some of the things you might want to consider.

    Crisis situations, and this is definitely one, require some planning and thought ahead of time. You ought to have some sort of “run book” similar to the one you have for disaster recovery, that helps you decide how to handle the situation. Unlike many troubleshooting situations, rebooting a server might be the worst thing you can do.

    I used to think that database people were more insulated from responding to these types of crisis situations. It seemed early in my career that we would be backups for the system administrators, and not necessarily need to respond to a midnight call. However the last 5 years have shown that this type of call is more and more likely for all data professionals.

    As we store more and more data, of great importance to the organization, we should be more prepared to respond to these types of incidents. Financial, identity, medical, and other types of data are becoming mixed in with all sorts of business data. As we build warehouses and transfer data among more systems, the likelihood we have data needing strong protections increases.

    At the very least, we must educate ourselves on our legal responsibilities as the data profession moves forward. More and more laws are being passed and regulations applied to data, and a good data professional in the future needs to be aware of their responsibilities in this area.

    Steve Jones

  • MCM Prep – Sliding the test

    If you can’t cram enough for the test, what’s the thing to do? Slide the test. I realized last night that I was scheduled for this Friday, but I’m nowhere near prepared. Not that I’ll be totally prepared, but I’d like to be well prepared in my mind and I haven’t gotten through all modules.

    I did XML last night, and realized I’m a little lost. The CLR I did today made sense, but I decided to give myself more time. So I moved it to late February, after vacation, where I think I’ll do some prep as well with all the flights and laying around the pool time. It will be good to keep the mind moving while I’m in the Bahamas.

  • MCM Prep – Only ONE Transaction Log File

    Unlike for data files, SQL Server does not use multiple files for the transaction log in any way that improves performance. The writes are not striped across files. Instead SQL Server will write to one file, then the next, then the next, wrapping to the first file when all the VLFs are full, just as it would with one file. In other words, it moves sequentially through the files for new transactions.

    I haven’t found a BOL reference for this, and don’t really feel like continuing the search, but Kim Tripp blogs about it here and it’s mentioned in the log file internals MCM video.