Jon Seigel's questions

I started analyzing our SQL Server PerfMon logs in Excel, and discovered this.

Legend:
Red - SQL Server - Target Server Memory
Green - SQL Server - Total Server Memory
Blue - Available System Memory

Server 1:

Server 2:

Server 3:

Has anyone else seen this before, and should we be worried?

Configuration is identical across all servers, except for the maximum memory setting -- 14GB on Servers 1 and 2, and 10GB on Server 3. Minimum memory is zero on all servers. These are SQL Server 2008 R2 instances, each in it's own VM running Windows Server 2008 R2 (SP1 applied mid-month) under Hyper-V.

What I would expect is to see a graph like Server 1 (horizontal red line), but for Servers 2 and 3, how is the value being reported for Target Server Memory fluctuating over time? What can't be seen from the graphs I've shown is that the fluctuations match up somewhat to the Available Memory metric. Also, the server restarts (blue vertical lines) don't seem to affect the values either. Is this a bug in PerfMon?

PerfMon is set up such that all 3 servers are inside a single data collector set, with each server having its own performance counter with all the parameters we're tracking.

Any help or insight would be appreciated.

I'm not a sysadmin, so this may be trivial.

We have about 20 Windows Server 2008 R2 VMs we want to monitor centrally using Perfmon. The only issue is that the user account that's going to be doing the monitoring is not (and I assume will never be) in the Administrators group. The servers, and the user account (currently one, but could be more) are all on the same domain.

Right now we're running a pilot with 5 of the servers, touching each VM manually to set the permissions, which is already getting cumbersome to manage. If we decide to roll this out to all the servers, we need a scalable solution to control access.

What is the most flexible way to accomplish this? I'd like a solution that would work with 200 servers just as easily as the 20 servers we have now.

We have a custom MembershipProvider implementation using form-based authentication (FBA) under Sharepoint 2007.

I've searched high and low on Google, but only found:

• Active directory and FBA implementations to allow users to change their own password
• Active directory instructions (including video!) for administrators to change other users' passwords

Have we missed an option to enable the latter under FBA? Should this work by default and is the MembershipProvider misbehaving?

The procedure to do this as under active directory would be ideal, but the "Change Password" link does not appear in the Edit User screen. We verified that the logged-in user is a site collection administrator.

In our production environment (SQL Server 2008 Enterprise), we've been having issues with CPU usage and network utilization. Based on the specs of the (multiple) machines we have and the general functionality of our software product, load should not be an issue.

As a developer, I figured the problem must lie elsewhere, probably in the queries that are being run. I thought it would be a good idea to attach the SQL Profiler to a production instance to figure out which queries (or even code) are the hotspots, and work on optimizing those areas first. (None of our hardware/network guys have done this before.)

I attached the profiler to one of our development instances for a couple hours, and determined we have a few problem areas:

1. Queries being executed inside loops -- it was common to see the same few queries being executed tens of thousands of times.
2. Queries that don't get cached -- I saw a few SELECT * queries show up; there were also quite a few that are non-parameterized. This is a large subset of #1, where a query would only vary by a single WHERE parameter.
3. Long-running queries -- ones that are actually taxing the CPU; these may be inefficiently written, not utilizing indexes, etc. The hit count on these was much lower.

Based on the summary statistics I generated, the biggest problem queries are of type #1 and #2. However, I can't immediately take those results and start working because the development instance queries are essentially what the other devs are working on at the time, not what is going to be run most in production.

I've been reading that attaching the SQL Server Profiler to an instance is problematic because of overhead. For obvious reasons, attaching in a production environment should be as lightweight as possible.

What I need to know is this -- given the three different types of queries I need to spot, how do I set up the profiler to have a minimal impact on performance? Is there another tool that I could use to accomplish this?

Notes:

• Our production environment has definite on- and off-peak times, so it may be possible to get a decent sample by capturing only 30-60 minutes of data during a peak time.
• I'd like to log to a database -- after playing around with the profiler, that log format is the easiest to consume later on.

We have a domain controller currently running Windows Server 2000, and we're in the process of upgrading some of our workstations to Windows 7.

The problem is that users are getting access denied messages to things they should be able to do, even trivial things like deleting shortcuts from the desktop. The users run at less than administrative levels, which we want to maintain.

We think this is caused by Windows 7 having extra security permission settings that are getting defaulted to denied, because the new settings wouldn't actually exist in the Windows 2000 profiles.

The reason I'm asking about Windows 2003 Server is because we have an available license of that, and not to 2008 (which would likely solve the problem completely, but costs $). So what I'd like to find out is if the permission settings in 2003 will be sufficient for our needs to justify upgrading the domain controller to 2003.