Testing posting with Live Writer and a proxy

I’m seeing if I can get through the firewall.

Using Live Writer

I’ve seen quite a few blogs about Windows Live Writer. Opinions seem to vary as to the usefulness of the tool. So I thought it was time I tried it out for myself.

This is the first post I’ve made with it. I’m just using basic word processing so it shouldn’t be too different than what I use now. That would be OneNote and Word, sometimes just entering right from blogger. But this looks to have most, if not all, the same capabilities. So we’ll see. 

Technorati Tags: Live Writer

Replaying traces with SQL Profiler

One of the projects I've become involved with at work has been the virtualization of our regional databases. However, when we hooked up a copy of one of the databases in a virtual environment we noticed a huge performance degradation, mainly in regard to CPU usage. The only part of the server that was virtualized was the drive containing the OS. User databases were mainly placed on a SAN so the IO looked to be acceptable, at least based on the small workload we generated. We know that the servers were not comparable; the current, physical server has 16 CPUs, where the virtual server is limited by VMWare to 4. Since performance was much worse than expected, we decided to try and replay a workload from one of our production servers on a virtual server and compare the results.
 
We thought of a few different ways to do this, but we eventually decided on using the replay ability of SQL Profiler. So we captured a trace from production, set up a copy of the databases on a second physical server configured identically to the production server, then used the different options inside profiler for the replay. What we saw was surprising.

The original trace was run for an hour. Using the multithreading option on the test box, the replay took twice as long, and the CPU usage was at least 10% higher for the length of the replay. When we set the number of threads to 64, the replay took 5 hours, and the CPU usage was maybe 25% of the original trace.

So the next step is to replay a trace on the same server to see what the results are. I'll post more on this in a few days, after a few more test cases. I'll also include some of the actual numbers.

How to change the display name of mail sent with DB Mail

Recently I had a manager complain that emails from some of our SQL 2005 servers were displaying different "From" aliases. These emails were being sent via DB Mail in jobs that were on all servers. I thought all the servers were configured the same; the same email account was being used on all, the same Exchange server, all the profiles had the server name as the display name.

 
 

However I missed one thing. Two servers were using Windows Authentication of the database engine and two were using Anonymous. The two using Windows Auth picked up the display name from Exchange, the 2 using Anonymous used the display name of the DB Mail profile.

 
 

A small thing, but useful in the future if I need to change the display name of email sent from a server.

Start with the basics when troubleshooting

Recently I began troubleshooting an issue on one of our servers. The issue is that the alerts I set up for jobs and on the server itself weren't sending emails to the operator I configured. This was happening for a while but I never had time to look at it in detail until now. And besides, I kept a close eye on the server so I would know if there were any problems. I had our other servers set up the same way, and none of them were having any issues. All the servers were using the same email account, and I set up all the database profiles to be identical. And I never had issues sending emails using send_dbmail.

So of course I checked and rechecked all the email account settings against a server that worked. I even went so far as deleting the email profile and creating a new one. Nothing I did had any effect. Finally I did what I should have done in the first place; check to see if the SQL Agent had email enabled for alerts. Sure enough if didn't.

The moral of my story is to start at the beginning when troubleshooting, no matter how basic it seems.

One of the first things you'll probably notice is the Surface Area Configuration Tool, introduced in SQL 2005, is not there. Actually it's still part of the server, only its moved. Now you access it by connecting to the server using the Management Studio, right clicking on the server name and choose "Facets" from the menu. When the View Facet screen opens, select "Surface Area Configuration" from the Facet combo box. Notice that by default all options are turned off; I specifically turned Database Mail on.

Moving a reporting database

Another task I just finished in regards to SSRS was moving the reporting database. We have an older server we were using for developing the report on. The system team gave us a virtual server (we're going to run virtual when we go live). I wanted to copy the existing catalogs to the new server so I wouldn't have to re-deploy them all. These are the steps I took. In my case the new report server was already installed and configured

1. Backup the encryption key on the source server using the Report Server Configuration Manager. This should be done regardless.
2. Backup the reporting database on the source server.
3. Restore the backup from the source to the destination server.
4. Apply the encryption key from the source onto the destination.

After I completed these steps all the reports and their data sources and credentials appeared on the new server's Report Manager. Hopefully I haven't missed anything.