Maxx Dopp here. Lunch has just been served, but no live band today. As I mentioned earlier, activity is much quieter today at TechEd. At least today, I got to eat lunch. On Monday, I was a little late, and virtually all the food was gone when I got there.

[imageattachment]

As I was helping out attendees today, answering SQL Server questions, I was a little surprised how basic some of the questions were. In other words, they were questions from novice DBAs. There is nothing wrong with this, and if fact, it is DBAs like this, who ask questions, that learn more and eventually become great DBAs. For some reason, I expected to get really hard questions. In any event, here are some of the questions I got, with my responses.

One DBA asked if there was any easy way to verify the configuration options between different servers, such as a development and a test server. Unfortunately, SQL Server doesn’t offer this option, but it sounds like it would be a great tool for DBAs. What do you think? Do you ever have a need to compare one or more SQL Servers to one another and see how they differ? I know I have. Add your comments/suggestions to this post.

Another DBA asked if there was a reason that a distribution database (part of transactional replication) would become very large (18GB) and never shrink. Both the huge size of the database, and the fact that is was not shrinking, were both serious issues. While it was hard to diagnose such a problem without seeing the server, the most common reason you see similar problems is because the distributor is holding data to send to a subscriber, and for whatever reason, can’t send the data, and is retaining it until it can send the data to the subscriber. But what really interested me about this question was that the DBA did not notice the problem until it became a large problem. In other words, the DBA never monitored the size of the distribution database, and it was only when space was running out on the disk that the problem was discovered. This is an example where performing routine “health checks” of your server can help catch problems before they become big problems. Maybe there needs to be a third-party tool to do this also. What do you think?

One DBA asked me about the best way to replicate databases over geographic large distances. This is not an easy question to answer in a short time, as there are so many variables that can affect the architecture. I suggested that the DBA experiment with SQL Server 2005 database mirroring. While I don’t know if this is the best solution to his problem, but at least he can get experience with Database Mirroring at virtually no cost. Once he has this experience, then he will be in a better position to make a good decision for his particular circumstances.

Another DBA asked about a slow application he had inherited from a previous DBA. Actually, he was more of a VB developer than a DBA, and had never worked with T-SQL before. He had a sample of the code, and within seconds, I saw a major problem. The application was using T-SQL functions to SELECT, INSERT, and UPDATE data, all in the same function. And this was done over and over again. Apparently, the original writer of this code had no concept of set-based coding. While I couldn’t solve his problem directly, as this would require a complete code rewrite, at least I pointed out one major problem with the code, and I recommended that he get a good introductory book on T-SQL so he could learn how to rewrite the application correctly.

While today was slow, the TechEd parties begin tonight. I am not sure if this is good or bad. If the parties are too successful, then a lot of attendees will really be dragging tomorrow morning, and by Friday, who knows how much they will be able to absorb?

For me, I am skipping the parties. I want to stay awake so I can learn as much as I can. At least that’s my story, and I’m sticking to it.

More later,

Maxx

1:30 AM Orlando, FL

Tuesday, June 05, 2007