In this blog post, we give you a short summary from last week’s webinar on the topic of SQL Server Performance with SysKit and SQLDocKit. The webinar is hosted by Silvio Rahle, our business development manager, and Frane Borozan, SysKit and SQLDocKit product owner.
Table of contents
The webinar starts with a short SysKit and SQLDocKit overview in which Silvio explains how our two tools work and what they do.
After the overview, Silvio guides you through the demo and shows you how to use the combined powers of SysKit and SQLDocKit to monitor specific SQL Server performance counters and services, forecast performance-related events, and align your SQL Server settings with the latest best practices from Microsoft to maintain a healthy and optimized SQL environment.
Frane then leads the Q&A. Scroll down to find all the questions discussed in the webinar. If you have any questions after watching the webinar, feel free to contact us.
SysKit & SQLDocKit
For those of you who are new to SysKit and SQLDocKit, let’s discuss what these administration tools do.
SysKit is a server-monitoring and administration tool designed to help system admins in their daily tasks. You can use it to monitor server performance, user activity, application usage, and system inventory. Also, you can use SysKit to simplify remote server management with the help of the GUI we’ve created.
SQLDocKit is an SQL Server management tool developed for DBAs. With the help of SQLDocKit, you can auto-discover SQL Server instances, document the entire SQL Server environment, and manage SQL Servers.
How to monitor SQL Server Performance with SysKit and SQLDocKit?
Whenever something bad happens on your SQL Servers, it automatically affects the databases and end-user experience, leading to page-load problems on SharePoint sites, slow application responses, and so on. Because of problems like those, you should be monitoring your SQL Servers at all times.
As far as SQL Server monitoring goes, SysKit can help you:
- monitor all existing SQL performance counters and services.
- get real-time alerts when an issue is detected in the SQL environment
- compare performance values over different servers and time periods
- create and modify templates for various SQL server roles
For example, if you navigate to the SysKit Performance Dashboard, you will get an overview of your entire system. Right away, you’ll be able to see whether you have any critical servers and then double-click to drill down to the single-server overview dashboard and investigate further.
Then you can use SysKit Performance Counters to check SQL transaction values and compare them with another SQL Server in your environment. Go to the Monitoring Templates to find the SQL template with all SQL-Server-related performance counters and services.
Then you can use SQLDocKit to boost your administrative powers, with features that help you:
- estimate disk usage according to the current usage trends
- predict database growth and perform disk management accordingly
- forecast database log sizes based on previous usage
- compare different forecasts for multiple servers and databases from a single console
For example, SQLDocKit’s Disk Usage report takes into consideration all selected disks and the way they are being used, thus predicting disk usage over the next few months, depending on the filter value you set. This type of forecasting can be done up to one year ahead. The same goes for database sizes and log sizes, which are important for capacity planning, and of course, you want to know whether your databases are growing rapidly. The Log Size metric is something you should keep an eye on as well, in case it overgrows the database size.
Skip to the SysKit Demo section to see it in action.
SQL Server best practices with SQLDocKit
SQLDocKit makes it easy to optimize your SQL Server performance because it provides Best Practices reports, letting you align your servers according to Microsoft’s best practices.
Take the Max Degree of Parallelism, for example, which largely depends on whether this SQL Server is used for SharePoint on SQL only. In the case of SharePoint, it should be set to 0. Or check that the Network Packet Size is set to the default 4096kb, remembering that if an application does bulk-copy operations or sends or receives large amounts of text or image data, a larger packet size might improve efficiency because it results in fewer network read-and-write operations.
Skip to the SQLDocKit Demo section to see it in action.