To create a high-performance SQL Server instance, you must first create a VM instance with SQL Server and two Persistent Disk volumes.
Persistent Disk considerationsTo select the type of Persistent Disk volumes for your VM, review the following considerations:
A Local SSD disk provides a high-performance location for tempdb
and the Windows pagefile.
There are some important considerations to note when using a Local SSD disk. When you shut down your instance from Windows or reset it by using the API, the Local SSD disk is removed. This action renders the instance unbootable. To get the machine running again, you would need to detach your persistent disks, create a new instance with them, and then define a new Local SSD disk. After startup you would also need to format the new disk and reboot. Therefore, you shouldn't permanently store critical data on a Local SSD disk, or power off the instance, unless you are prepared to rebuild it.
An SSD Persistent Disk provides high-performance storage for the database files.
Persistent Disk performance is based on a calculation that uses the number of CPUs and the size of the disk. With 32 vCPUs and a 1 TB disk, the performance peaks at 40,000 read operations per second (ops) and 30,000 write ops. The total sustained throughput for reads and writes is 800 MB per second and 400 MB per second respectively. These measurements represent a summation of all the Persistent Disk volumes attached to the virtual machine, including the C:\
drive. To ensure consistent performance, create a Local SSD disk and offload all the IOPS needed for the paging file, tempdb
, staging data, and backups.
To read more about disk performance, see Configure disks to meet performance requirements.
Creating Compute Engine VM with disksTo create a VM that has SQL Server 2022 Standard preinstalled on Windows Server 2022, follow these steps:
In the Google Cloud console, go to the Create an instance page.
For Name, enter ms-sql-server
.
In the Machine configuration section, select General Purpose, and then do the following:
In the Boot disk section, click Change, and then do the following:
Expand the Advanced options section, and do the following:
To create local disks, click Add Local SSD, and then do the following:
tempdb
files.To create additional disks, click Add New Disk.
To create the VM, click Create.
Now that you have a working instance running SQL Server, connect to your instance and configure the Windows operating system. After that, you learn to configure SQL Server in an upcoming section.
Connect to your instanceIn the Google Cloud console, go to the VM instances page.
Under the Name column, click the name of your instance, ms-sql-server
.
At the top of the instance's details page, click the Set Windows Password button.
Specify a username.
Click Set to generate a new password for this Windows instance.
Note the username and password so you can log into the instance.
Connect to your instance by using RDP.
Create and format the volumes:
Create partition for Local SSD disk(s):
To locate a Local SSD disk, right-click on a disk and select Properties. The Local SSD disk properties name will be Google EphemeralDisk
for a SCSI interface or nvme_card
for an NVMe interface. Both Local SSD disks and persistent SSDs are marked as having Unallocated
partitions.
If the VM contains only 1 Local SSD drive, follow these steps:
In the Format Volume step, change the Allocation unit size to 8192 and enter "pagefile" for the Volume label. Click Next to proceed.
Click Finish to complete the disk volume wizard.
If the VM contains multiple local SSD drives, follow these steps:
In the Select Disks step, add all the available disks with the size 383,982 MB to the Selected section. Click Next to proceed.
In the Assign Drive Letter or Path step, choose P: for the drive letter and click Next to proceed.
In the Format Volume step, change the Allocation unit size to 8192 and enter "pagefile" for the Volume label. Click Next to proceed.
Click Finish to complete the disk volume wizard.
Repeat the previous steps to create a New Simple Volume for the SSD disk, with the following three changes:
Choose D: for the drive letter.
Set the Allocation unit size to 64k
.
For details on selecting an allocation unit size, see Best practices for SQL Server instances.
Enter sqldata
for the Volume label.
Now that the new volumes are created and mounted, move the Windows paging file onto the Local SSD disk, which frees up Persistent Disk IOPS and improves the access time of your virtual memory.
C:\
drive, and you need to move it.Click OK three times to exit the advanced system properties.
Microsoft Support has published additional tips for virtual memory settings.
Set the power profile to High-Performance
instead of Balanced
.
Use SQL Server Management Studio to perform most administrative tasks. The preconfigured images for SQL Server come with Management Studio already installed. Launch Management Studio and then click Connect to connect to the default database.
Moving the data and log filesThe preconfigured image for SQL Server comes with everything installed on the C:\
drive, including the system databases. To optimize your setup, move those files to the new D:\
drive you created. Also remember to create all new databases on the D:\
drive. Because you are using an SSD, you don't need to store the data files and log files on separate disk partitions.
There are two ways to move the installation to the secondary disk: using the installer or moving the files manually.
Using the installerTo use the installer, run c:\setup.exe
and select a new installation path on your secondary disk.
Move the system databases and configure SQL Server to save the data and log files on the same volume:
D:\SQLData
.Enter the following command to grant full access to NT Service\MSSQLSERVER
:
icacls D:\SQLData /Grant "NT Service\MSSQLServer:(OI)(CI)F"
Use Management Studio and the following guides to move your system databases and change the default file locations for new databases.
If you plan on using Report Server features, move the ReportServer and ReportServerTempDB files as well.
tempdb
files yet because you must first change some permission settings and then move the DB to the Local SSD volume.
After you move the primary configuration database files and restart, you need to configure the system to point to the new location for the model and MSDB databases. Here is a helper script to run in Management Studio:
ALTER DATABASE model MODIFY FILE ( NAME = modeldev , FILENAME = 'D:\SQLData\model.mdf' ) ALTER DATABASE model MODIFY FILE ( NAME = modellog , FILENAME = 'D:\SQLData\modellog.ldf' ) ALTER DATABASE msdb MODIFY FILE ( NAME = MSDBData , FILENAME = 'D:\SQLData\MSDBData.mdf' ) ALTER DATABASE msdb MODIFY FILE ( NAME = MSDBlog , FILENAME = 'D:\SQLData\MSDBLog.ldf' )
After you execute these commands:
services.msc
snap-in to stop the SQL Server database service.C:\
drive where the master
database was located to the D:\SQLData
directory.After moving the system databases, modify some additional settings, starting with permissions for the Windows user account created to run your SQL Server process, which is named NT Service\MSSQLSERVER
.
Lock Pages in Memory
permission
The group policy Lock Pages in Memory
permission prevents Windows from moving pages in physical memory to virtual memory. To keep physical memory free and organized, Windows tries to swap old, rarely modified pages to the virtual-memory paging file on disk.
SQL Server stores important information in memory, such as table structures, execution plans, and cached queries. Some of this information rarely changes, so it becomes a target for the paging file. If this information gets moved to the paging file, SQL Server performance can degrade. Granting the group policy Lock Pages in Memory
permission for SQL Server's service account prevents this swapping.
Follow these steps:
Perform volume maintenance tasks
permission
By default, when an application requests a slice of disk space from Windows, the operating system locates an appropriately sized chunk of disk space, and then zeroes out the entire chunk of disk, before handing it back to the application. Because SQL Server is good at growing files and filling disk space, this behavior is not optimal.
There is a separate API for allocating disk space to an application, often referred to as instant file initialization. Unfortunately, this setting only works for data files, but you will learn in an upcoming section about log-file growth. Instant file initialization requires the service account running the SQL Server process to have another group policy permission, called Perform volume maintenance tasks
.
tempdb
It used to be a best practice to optimize the SQL Server CPU usage by creating one tempdb
file per CPU. However, because CPU counts have grown over time, following this guideline can cause performance to decrease. As a good starting point, use 4 tempdb
files. As you measure your system's performance, in rare cases you might need to incrementally increase the number of tempdb
files to a maximum of 8.
You can run a Transact-SQL (T-SQL) script inside SQL Server Management Studio to move the tempdb
files to a folder in the `p:` drive.
p:\tempdb
.Grant full security access to the "NT Service\MSSQLSERVER" user account:
icacls p:\tempdb /Grant "NT Service\MSSQLServer:(OI)(CI)F"
Run the following script inside SQL Server Management Studio, to move the tempdb
data file and log file:
USE master GO ALTER DATABASE [tempdb] MODIFY FILE (NAME = tempdev, FILENAME = 'p:\tempdb\tempdb.mdf') GO ALTER DATABASE [tempdb] MODIFY FILE (NAME = templog, FILENAME = 'p:\tempdb\templog.ldf') GO
Restart SQL Server.
Run the following script to modify the file sizes and create three additional data files for the new tempdb
.
ALTER DATABASE [tempdb] MODIFY FILE (NAME = tempdev, FILENAME = 'p:\tempdb\tempdb.mdf', SIZE=8GB) ALTER DATABASE [tempdb] MODIFY FILE (NAME = templog, FILENAME = 'p:\tempdb\templog.ldf' , SIZE = 2GB) ALTER DATABASE [tempdb] ADD FILE (NAME = 'tempdev1', FILENAME = 'p:\tempdb\tempdev1.ndf' , SIZE = 8GB, FILEGROWTH = 0); ALTER DATABASE [tempdb] ADD FILE (NAME = 'tempdev2', FILENAME = 'p:\tempdb\tempdev2.ndf' , SIZE = 8GB, FILEGROWTH = 0); ALTER DATABASE [tempdb] ADD FILE (NAME = 'tempdev3', FILENAME = 'p:\tempdb\tempdev3.ndf' , SIZE = 8GB, FILEGROWTH = 0); GO
If you use SQL Server 2016, there are 3 additional tempdb
files to remove after you do the previous steps:
ALTER DATABASE [tempdb] REMOVE FILE temp2; ALTER DATABASE [tempdb] REMOVE FILE temp3; ALTER DATABASE [tempdb] REMOVE FILE temp4;
Restart SQL Server again.
Delete the model
, MSDB
, master
, and tempdb
files from the original location on the C:\
drive.
You successfully moved your tempdb
files onto the Local SSD disk partition. This move carries some risks, mentioned earlier, but if they are lost for any reason,SQL Server rebuilds the tempdb
files. Moving tempdb
gives you the added performance of the Local SSD, and decreases the IOPS used on your Persistent Disk volumes.
max degree of parallelism
The recommended default setting for max degree of parallelism
is to match it to the number of CPUs on the server. However, there is a point where executing a query in 16 or 32 parallel chunks and merging the results is much slower than running it in a single process. If you are using a 16- or 32-core instance, you can set the max degree of parallelism
value to 8 using the following T-SQL:
USE master GO EXEC sp_configure 'show advanced options', 1 GO RECONFIGURE WITH OVERRIDE GO EXEC sp_configure 'max degree of parallelism', 8 GO RECONFIGURE WITH OVERRIDE GOSetting
max server memory
This setting defaults to a very high number, but you should set it to the number of megabytes of available physical RAM, minus a couple gigabytes for operating system and overhead. The following T-SQL example adjusts max server memory
to 100 GB. Modify it to adjust the value to match your instance. Review the Server memory server configuration options document for more information.
EXEC sp_configure 'show advanced options', 1 GO RECONFIGURE WITH OVERRIDE GO exec sp_configure 'max server memory', 100000 GO RECONFIGURE WITH OVERRIDE GOFinishing up
Restart the instance one more time to make sure all of the new settings take effect. Your SQL Server system is configured and you are ready to create your own databases and start testing your specific workloads. Review the SQL Server Best Practices guide for more information on operational activities, other performance considerations, and Enterprise Edition capabilities.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4