Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Please, try again later.
This article was produced in coordination with the Veeam R&D team to provide Service Providers with a comprehensive list of the most common performance improvements and maintenance actions relating to the underlying Microsoft SQL Server instance that hosts the Veeam Service Provider Console configuration database.
The information, advice, and scripts provided in this article are provided as a courtesy. Assistance with implementing the configuration advice provided in this document is outside the scope of Veeam Support.
If you have feedback regarding the content of this article, please use the Article Feedback form.
Memory utilization for the SQL Server Database Engine is bounded by a pair of configuration settings, min server memory (MB) and max server memory (MB). Over time and under normal circumstances, SQL Server will attempt to claim memory up to the limit set by max server memory (MB).
Use max server memory (MB) to guarantee the OS and other applications don't experience detrimental memory pressure from SQL Server. Before you set the max server memory (MB) configuration, monitor the overall memory consumption of the server hosting the SQL Server instance during regular operation to determine memory availability and requirements.
Use SQL Server Management Studio to set server memory options:
When utilizing SQL Server Standard Edition or Express Edition, be mindful of the compute capacity limitations when configuring the CPU socket and core configuration of the Virtual Machine (VM) hosting Microsoft SQL Server.
Microsoft SQL Server - Compute capacity limits by edition
Example:
If you intend to assign a total of 24 vCPUs to a VM and configure it as 24 sockets with 1 core each, SQL Server Standard edition would be able to utilize at most 4 cores. If the configuration were 4 sockets with 6 cores each, then SQL Server Standard Edition would be able to access all 24 cores.
To manage data and log files, ensure the following:
ALTER DATABASE VSPC SET AUTO_SHRINK OFF;
Performance Monitor is a built-in Windows Tool for monitoring all aspects of Windows and hosted applications such as SQL Server. A Data Collector Set is used to organize and schedule performance counter data as a single collection to be analyzed later.
To create a Data Collector Set for your physical disks:
There are several areas where SQL Server logs information about processes that are occurring as well as errors that occur. The most used is probably the SQL Server Error Log. This error log provides startup information, integrity check information, backup information, and other information, as well as any SQL Server errors that occur.
To get to the MS SQL Server Logs, follow these steps:
Almost all of the data collected by VSPC goes through Staging tables. It is important that these tables maintain as near to zero records as possible. If the number of records continues to increase, it could indicate that there is a performance issue.
To check how many records Staging tables have:
To view the current amount of free (unallocated) space in the database, see Display Data and Log Space Information for a Database.
Consider the following information when you plan to shrink a database:
Shrink operations in progress can block other queries on the database and can be blocked by queries already in progress.
Data that is moved to shrink a file can be scattered to any available location in the file. This causes index fragmentation and can slow the performance of queries that search a range of the index. To eliminate the fragmentation, consider rebuilding the indexes on the file after shrinking.
Index and data pages can experience internal fragmentation. Index and table structures can experience logical scan and extent scan fragmentation. Periodically check index fragmentation of the VSPC database. The most sensitive tables for index fragmentation are:
Check Index Fragmentation using SQL Server Management Studio:
You’ll see table names, indexes, and operation recommendations in that report. Follow the recommendations and rebuild\reorganize indexes.
Please note that rebuilding indexes is a heavy task that can take a lot of time. Additionally, online indexing can only be done with the Enterprise Edition of Microsoft SQL Server. In other editions of the SQL Server, only offline indexing is available, meaning tables having their indexes rebuilt will be locked during the rebuild operation. Reorganizing the index, on the other hand, is less heavy an operation and can be done online with all editions. Generally speaking, reorganizing indexes is preferable to rebuilding when possible.
For information about rebuilding Indexes (Online) with SQL Server Enterprise Edition, please review Microsoft documentation:
SQL Server - Perform index operations online - Use SQL Server Management Studio
You can check how irrelative the statistics are in your VSPC DB using the following query:
set transaction isolation level read uncommitted;
select quotename( sh.[name] ) + N'.' + quotename( t.[name] ) as [object_name]
, s.stats_id
, quotename( s.[name] ) as stat_name
, s.auto_created
, s.user_created
, s.no_recompute
, replace( sc.stat_columns, N'] [', N'], [' ) as stat_columns
, cast( sp.last_updated as datetime2( 3 ) ) as last_updated
, sp.[rows]
, sp.rows_sampled
, sp.steps
, sp.modification_counter
, ltrim( format( cast( sp.modification_counter as decimal( 20, 2 ) ) / cast( sp.[rows] as decimal( 20, 2 ) ), N'# ##0.00 %' ) ) as irrelevance
, s.filter_definition
from sys.schemas sh
inner join
sys.tables t on t.[schema_id] = sh.[schema_id]
inner join
sys.stats s on s.[object_id] = t.[object_id]
outer apply
( select quotename( c.[name] ) as [data()]
from sys.stats_columns sc
inner join
sys.columns c on c.[object_id] = sc.[object_id] and c.column_id = sc.column_id
where sc.[object_id] = s.[object_id]
and sc.stats_id = s.stats_id
order by sc.stats_column_id
for xml path( '' ) ) sc( stat_columns )
outer apply
sys.dm_db_stats_properties( s.[object_id], s.stats_id ) as sp
order by [object_name], s.stats_id;
go
-- Use the name of your VSPC database instead of the VSPC_DB_NAME
USE VSPC_DB_NAME;
GO
-- The following example updates the statistics for the INDX_ObjectEntityPropertyValue_IsDeleted_DateTime index of the VeeamBP.ObjectEntityPropertyValue table.
UPDATE STATISTICS VeeamBP.ObjectEntityPropertyValue
INDX_ObjectEntityPropertyValue_IsDeleted_DateTime;
GO
-- Use the name of your VSPC database instead of the VSPC_DB_NAME
USE VSPC_DB_NAME;
GO
-- The following example updates the statistics for all indexes on the VeeamBP.ObjectEntityPropertyValue table.
UPDATE STATISTICS VeeamBP.ObjectEntityPropertyValue;
GO
-- Use the name of your VSPC database instead of the VSPC_DB_NAME
USE VSPC_DB_NAME;
GO
-- The following example updates the statistics for all tables in the database.
EXEC sp_updatestats;
Your feedback has been received and will be reviewed.
Please, try again later.
Please try select less.
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Your feedback has been received and will be reviewed.
Please, try again later.