Databases Reference
In-Depth Information
likely to be able to identify and resolve performance problems without requiring specialist tools and deep
internals knowledge that would normally be accessed via Microsoft Product Support Services.
Monitoring Remote Servers
When monitoring any service on any server there's always a trade-off between running the monitoring
tool locally versus remotely. There's no right answer that works for every situation, since there are bene-
fits and disadvantages of every monitoring configuration. Importantly, performance data should always
be analyzed with awareness of the environment and configuration with which the data was gathered
(specifically network configuration/limitations when using remote monitoring). As discussed earlier,
running any kind of monitoring tool creates a performance overhead on the computer being monitored.
When troubleshooting a specific issue, the use of Performance Monitor is usually confined to a relatively
short timeframe before logging is stopped and often the output is copied to another computer for analy-
sis. On most such occasions it would be suitable to run System Monitor on the server being monitored.
However, if the purpose of monitoring is capacity planning or trend analysis, a remote server is pre-
ferred. This limits the impact of monitoring on the target server to creating some additional network
input/output (I/O).
When monitoring SQL Server remotely, it's worth mentioning that Performance Monitor relies on
NetBIOS. If there are any firewalls or port filters between the source and target for monitoring, it's
possible that monitoring will be problematic. Once the target server has been specified within Perfor-
mance Monitor, the performance objects and counters should automatically populate to reveal those
available on the target system. If they don't appear, review the Application Event log on the source
system (because any errors will appear on the source system, not the monitoring system), and ensure
that there are no other instances of Performance Monitor running.
If you're still experiencing problems registering counters from a remote server, it may be worth looking
at the Remote Registry service. Often restarting this service will reset any connections. Once this service
is restarted, attempt to add the performance counters again and you should find that this works.
Best Practices for System Monitor
There are a number of best practices that you should consider when running System Monitor that will
help you get the most from System Monitor and avoid some of the common pitfalls.
Taking a Baseline
It's probably the last thing on your mind. The phone has finally stopped ringing, and you finally have a
chance to make sure the backups ran last night and grab a coffee. However, you may be grateful at some
point soon that you did actually make time to take a baseline. All that's needed is to run System Monitor
for 24 hours with a 15-minute sample interval, covering the main system components. This alone could
be instrumental in prompt fault resolution. Try to invest a few minutes to set up a trace, and you'll see
the benefits if you ever have a performance problem.
Each time you make a significant change to a software or hardware configuration, re-run your System
Monitor baseline for 24 hours. Very quickly, you and the Change Managers should become comfortable
with the likely (low) performance impact and associated risk of running System Monitor. Don't forget,
each time you apply an operating system or application patch, upgrade the SAN fabric firmware, or
change the networking routing table, take a new baseline.
Search WWH ::
Custom Search