MMS2017 SCCM SQL Optimal Performance v05
MMS2017 SCCM SQL Optimal Performance v05
MMS2017 SCCM SQL Optimal Performance v05
OPTIMAL PERFORMANCE
Benjamin Reynolds Steve Thompson
blogs.technet.microsoft.com/ www.stevethompsonmvp.wordpress.com
benjamin/
Senior Consultant
Microsoft
Softchoice
Benjamin Reynolds Steve Thompson
? @Steve_TSQL
CPU
Disk
Best Practices
WINDOWS SERVER - PROVISION SERVER
Use Windows Server 2016
Memory
CPU
Disk
64KB NTFS format
IOPS
Drive layout
Considerations for Azure VMs
See HA session
Best Practices – capacity planning
https://docs.microsoft.com/en-us/sccm/core/plan-design/configs/recommended-hardware
CONFIGURE SQL SERVER
CONFIGURE SQL SERVER
Installation location
Disk Layout
Memory
CPU
Databases
SCCM
TempDB
SUSDB
DB Sizing, Autogrowth & VLF’s
Patching – SP & CU updates
Cautionary notes…
Best Practices / Lessons from the field!
SQL INSTALLATION LOCATION
Collocate with SCCM?
When possible, install SQL Server on same server as SCCM
Remote install of SQL Server
Exceptions: HA scenarios
Install location
Never C:
Disk Layout
Plan to separate Data from Logs, TempDB on dedicated drive
DISK LAYOUT
Plan to separate Data from Logs,
Place TempDB on dedicated drive
Include TempDB data and logs on same drive – SSD if possible
If SQL co‐located with SCCM sample drive layout:
Logical Drive Minimum Size Purpose
(GB)
C: 100 OS + *Page file
E: 100 Applications + Database
F: 50 Log Files
G: 500 SCCM Content OS images, app packages, etc.
*P: 50 Page File
*T: 50 Temp DB
*U: 50 Backups
DISK LAYOUT - WHAT MSIT DOES
SQL MEMORY CONFIGURATION
SQL Server loves memory. Maybe too much.
Always, always set a minimum and maximum memory
Recommended Settings:
Minimum SQL memory = 8GB
Maximum SQL memory
SCCM and SQL on same server: example 96GB total – 16GB = 80 GB for SQL
SQL on Remote server: memory setting should be about 80% of server memory
Always calculate memory to whole GB
Example: 8GB * 1024 = 8192MB
SQL MEMORY CONFIGURATION
Default (Screen shot) & modified
Remember - Monitor memory usage and adjust as needed. Page file usage = BAD
CPU
MAXDOP - MAX Degree Of Parallelism (MAXDOP)
By default, MAXDOP is set to 0. This means that all available processors are available to be
deployed to process statements. That is good, right? Not necessarily. It depends.
To suppress parallel plan generation, set max degree of parallelism to 1
Large sites may benefit
Very large site: SCCM Admin feedback: “With a CAS, MAXDOP with a higher value makes
collection queries faster, lower setting makes inbox processing faster, not a lot of room for
compromise. We use 2.”
Advice: Experiment and monitor
DATABASES
Estimate size(s)
SCCM
SUSDB
TempDB
Use SCCM DB Sizing estimator!
Multiple data files may be appropriate
Can migrate using Filegroups
Be cautious in a multi-site hierarchy!
Single LOG file
Autogrowth = BAD
TEMPDB
Custom solution
Used as the core of the CM sprocs
Issues creating an Agent job due to DAC requirements
Write the info to a table!
THE “DBA” SOLUTION
THE “DBA” SOLUTION
A separate database named “DBA”
Logging and statistics gathering
Custom objects (stored procedures, functions, views, etc) stored here
Iterations in source control
A look at the DBA Solution
REFERENCES
Ola and SCCM
https://stevethompsonmvp.wordpress.com/2016/11/29/optimizing-sccm-databases-revisited/
VLFs
https://stevethompsonmvp.wordpress.com/2013/05/14/virtual-log-files-and-impact-on-
configmgr-performance/
SECTION HEADER
This is the next section
TITLE
Line1
Bullet Level 1
Bullet Level 2
Bullet Level 3
TITLE
Code
Text Only with Border
Level 1
Level 2
Level 3
Text Only (Red)
Level 1
Level 2
Level 3
TITLE
Text 1 Text 2
Level 1 Level 1
Level 2 Level 2
Level 3 Level 3
TITLE
Section 1 Section 2
Text Text
Level 1 Level 1
Level 2 Level 2
Level 3 Level 3
Demo Title