HPE Reference Architecture for Microsoft SQL Server 2016 on HPE ProLiant DL380 Gen9 with HPE Persistent Memory SQL Server OLTP In-Memory with Persisted Log Buffer

Technical white paper

Technical white paper

Contents Executive summary ................................................................................................................................................................................................................................................................................................................................ 3 Introduction ................................................................................................................................................................................................................................................................................................................................................... 3 Solution overview ..................................................................................................................................................................................................................................................................................................................................... 3

HPE Persistent Memory .............................................................................................................................................................................................................................................................................................................. 4 Solution Architecture ............................................................................................................................................................................................................................................................................................................................ 5 Solution components ............................................................................................................................................................................................................................................................................................................................ 5

Hardware ................................................................................................................................................................................................................................................................................................................................................... 5 Software ..................................................................................................................................................................................................................................................................................................................................................... 6

Best practices and configuration guidance for the solution ............................................................................................................................................................................................................................. 6 HPE ProLiant DL380 Gen9 ..................................................................................................................................................................................................................................................................................................... 6 SQL Server Resource Governor ........................................................................................................................................................................................................................................................................................... 6

Capacity and sizing ................................................................................................................................................................................................................................................................................................................................ 8 Workload description ..................................................................................................................................................................................................................................................................................................................... 8 Test Methodology ............................................................................................................................................................................................................................................................................................................................ 9 Analysis and recommendations ....................................................................................................................................................................................................................................................................................... 10

Summary ...................................................................................................................................................................................................................................................................................................................................................... 13 Appendix A: Bill of materials ...................................................................................................................................................................................................................................................................................................... 14 Appendix B: Configuration adjustments ......................................................................................................................................................................................................................................................................... 15

HPE Persistent Memory .......................................................................................................................................................................................................................................................................................................... 15 Resources and additional links ................................................................................................................................................................................................................................................................................................ 17

Technical white paper Page 3

Executive summary The demand for high-performance SQL Server solutions is increasing at an extremely rapid pace. IT organizations are frequently presented with the challenge of architecting and tuning their SQL Server database systems to be capable of handling an increasing number of transactions concurrently, while maintaining low-latency SLA’s. To address this scenario, Microsoft® introduced In-Memory functionality into SQL Server. This functionality has evolved over several releases, and can provide significant query and server performance boosts for databases that leverage In-Memory table functionality.

The purpose of this Reference Architecture (RA) is to provide an example configuration, highlighting performance and best practices for SQL Server In-Memory OLTP DB workloads deployed on an HPE ProLiant DL380 Gen9 server. The RA provides configuration guidance for deploying up to 4 databases on an HPE ProLiant DL380 and highlights different processor and system configuration options that can impact overall workload performance. This white paper is not intended to represent a specific deployable configuration as workload behavior and performance will vary depending on the customer’s application/DB environment.

Target audience: This Hewlett Packard Enterprise Reference Architecture white paper is designed for IT professionals who use, program, manage, and administer large databases that require high availability and performance. Specifically, this information is intended for those who evaluate, recommend, and design new IT high-performance architectures.

Document purpose: The purpose of this document is to describe a Reference Architecture, highlighting recognizable benefits to technical audiences.

Introduction As the rate of business being conducted online increases, the requirement for systems capable of facilitating high-concurrency transactions does as well. This document consists of the result of testing and analysis of some of Microsoft's newest technological advances including databases that are strictly contained "In-Memory". Our test cases were also based upon questions such as:

1. What processor is best for my application architecture, and what options are available to me today?

2. Why would or should an IT professional choose a frequency optimized processor with fewer cores over a non-frequency optimized processor with more cores. What are the cost benefits?

3. Are there licensing savings with one processor over the other?

4. What are the performance gains or potential losses when comparing processors?

Solution overview The HPE ProLiant DL380 Gen9 server is one of the most ubiquitous systems found in the enterprise today. Its proven track record has made it Hewlett Packard Enterprise’s standard for two-socket (2s), x86, OLTP workloads, and is a perfect platform to deploy Microsoft SQL Server 2016.

Figure 1. HPE ProLiant DL380 Gen9 server, front view

Key features and benefits • Processors: Having the ability to scale with ease, the HPE ProLiant DL380 Gen9 server offers great flexibility by having two sockets that are

capable of housing processors with 4 to 22 cores.

• Memory: The HPE ProLiant DL380 Gen9 server is capable of hosting up to 3TB of memory. Building on its solid foundation, the HPE ProLiant DL380 Gen9 is one of Hewlett Packard Enterprise’s newest additions to the collection of servers that are now able to host Storage Class Memory.

Technical white paper Page 4

• I/O Expansion: With 3 PCIe 3.0 slots in its standard configuration, and an additional 3 PCIe slots available with an optional riser card, the HPEProLiant DL380 Gen9 has a bevy of expansion available to it including SMART Array, HBA, or networking adapters.

• Storage: Standard storage capabilities include 24 +2 x SFF or 12 + 3 x LFF drive enclosures for either HDD/SDD, or M.2. As well as furtherstorage expansion via the 6 PCIe slots for NVMe.

• Small form factor (SFF) means less rack space needed and lower power and cooling requirements.

• Easy administration from HPE Integrated Lights Out Management.

HPE Persistent Memory HPE Persistent Memory is storage that is as fast as RAM, and brings you closer, and faster to your data. These memory modules are compatible with the existing memory slots on the motherboard of the HPE ProLiant DL380 Gen9. The HPE ProLiant DL380 Gen9 is also capable of supporting up to 16 x 8GB NVDIMM modules (128GB). Unlike other types of memory, persistent memory modules have a battery backup on the motherboard, and can maintain data for a short period of time in the event of a power loss to the server, in order to fully commit the data to disk.

One of the prime advantages of using persistent memory is that it has two methods in which it can be used. It can be formatted as NTFS storage just as most other forms of media can, or it can be formatted as a Direct Access (DAX) device, which bypasses the need to pass through a driver layer, increasing the speed at which data is written to the device. For the purposes of this Reference Architecture, these memory modules will serve in the capacity of a Persisted Log Buffer, or pre-caching mechanism, for the database transaction logs.

Figure 2. Persistent Memory, front view

Technical white paper Page 5

Solution Architecture The diagram shown below is an example of one of the architectures configured for this project. As you can see, we have two 75GB databases that have been contained within SQL Server Resource Governor Resource Pools. These databases and resource pools have also been affinitized to individual NUMA nodes or processors within the HPE ProLiant DL380. The monitoring of how the server performed under load was captured with Windows® Performance Monitor, and the workloads were generated on two Windows Server® virtual machines; one workload server to a database.

Figure 3. Environment diagram

Solution components Hardware HPE ProLiant DL380 Gen9 Server configuration The server configuration implemented in this reference architecture was primarily focused on OLTP applications requiring the ability to process transactions in a highly concurrent environment. The server was configured with the following components:

• Processor configurations

– Configuration 1: Intel® Xeon® E5-2667v4 8-Core 3.2GHz Processors

– Configuration 2: Intel Xeon E5-2698v4 20-Core 2.2GHz Processors

• 704GB Memory (22 x 32GB HPE DDR4 Smart Memory)

• 16GB NVDIMM (2 x 8GB HPE NVDIMM Persistent Memory)

• 12 x 400GB 12G SAS Write Intensive SSD’s

• 2 x 146GB 6G 15K rpm SAS HDD

• HPE P840 Smart Array Controller

Technical white paper Page 6

Software • Microsoft Windows Server 2016 Datacenter Edition RTM

• Microsoft SQL Server 2016 Service Pack 1, Cumulative Updates 1, Enterprise Edition

Best practices and configuration guidance for the solution HPE ProLiant DL380 Gen9 The HPE ProLiant DL380 Gen9 server was configured with the following BIOS settings:

• Hyper-Threading: Enabled

• Intel Turbo Boost: Enabled

• HPE Power Profile: Maximum Performance

• NUMA Group Size Optimization: Clustered (default)1

• QPI Snoop configuration: Home Snoop

SQL Server Resource Governor When considering the deployment of the SQL Server In-Memory databases, SQL Server Resource Governor Resource Pools are not only a Microsoft recommended best practice, they’re almost a requirement. There is an additional overhead required to maintain databases In-Memory. This is to facilitate one of the prime features of SQL Server In-Memory being the row level versioning that removes the need for locking found when deploying non-memory resident databases, or database objects. This in turn increases the speed that transactions can be executed dramatically. Three components of Resource Governor were used:

• A workload classifier function

• Resource Pools

• Workload Groups

The resource pools encapsulated the database(s) and kept memory from being needlessly squandered as well as affinitized the database(s) to a specific NUMA node (or processor socket). The workload groups bind specific users to the resource pools as they are a child object to Resource Pools. The workload classifier not only activates the use of the Resource Pools, it also makes sure that the incoming traffic from a specific user is routed to the correct resource pool via the workload group(s).

Below is an example of the Transact-SQL (T-SQL) that was executed to create the workload classifier:

USE [master] GO

/****** Object: UserDefinedFunction [dbo].[WorkloadClassifier] Script Date: 2/11/2017 7:13:39 PM ******/ SET ANSI_NULLS ON GO

SET QUOTED_IDENTIFIER ON GO

CREATE FUNCTION [dbo].[WorkloadClassifier]() RETURNS sysname WITH SCHEMABINDING

1 For a more detailed explanation of NUMA, and how to configure it for HPE ProLiant Gen9 Rack servers, please refer to page 24, Appendix C: Understanding hardware and software NUMA in SQL Server 2016 and how to set affinity on Broadwell, in the HPE Reference Architecture for ProLiant DL580 Gen9 and Microsoft SQL Server OLTP database consolidation white paper found at http://h20195.www2.hpe.com/V2/GetDocument.aspx?docname=4aa6-8301enw.

Technical white paper Page 7

AS BEGIN DECLARE @WorkloadGroup AS SYSNAME IF(SUSER_NAME() = 'User1')

SET @WorkloadGroup = 'WG1' ELSE IF (SUSER_NAME() = 'User2')

SET @WorkloadGroup = 'WG2' RETURN @WorkloadGroup END

GO

This is an example of the code that was used to create the resource pools. Notice the max_memory_percent parameter that sets the limit that the database contained within the resource pool can use memory wise. This code also affinitizes the resource pool to a specific NUMA node, and the creation of the work groups as they are a child of the resource pool parent.

CREATE RESOURCE POOL [RP1] WITH(min_cpu_percent=0, max_memory_percent=49, AFFINITY NUMANODE = (0))

GO

CREATE WORKLOAD GROUP [WG1] WITH(group_max_requests=0, importance=High, max_dop=1) USING [RP1], EXTERNAL [default]

GO

The second to last step required in this process is to bind a database to a resource pool.

sp_xtp_bind_db_resource_pool ‘InMemDB’, ‘RP1’

When executed, the code above will return the following instruction:

A binding has been created. Take database 'InMemDB' offline and then bring it back online to begin using resource pool 'RP1'.

Therefore, the last step in this process is to take the database offline, and bring it online again to completely bind the database to the resource pool with the following T-SQL:

USE master GO

ALTER DATABASE InMemDB SET OFFLINE GO ALTER DATABASE InMemDB SET ONLINE GO

Technical white paper Page 8

Capacity and sizing Workload description For this Reference Architecture, multiple configurations were implemented on the HPE ProLiant DL380 Gen9 server. This was done in order to facilitate the different processor and database combinations required to accommodate the cases in our test plan. The workload virtual machines used in the testing simulate an online store using a 1:1 VM to DB ratio. A single instance of the workload VM and associated application was configured to execute against a single database target on the HPE ProLiant DL380 Gen9 server.

The testing consisted of the following:

1. A baseline test of a single 75GB db (2 total) affinitized to each of the 8-Core 3.2GHz processors with 335GB of memory allocated to the SQL Server.

2. Two of the 75GB db’s affinitized to a single NUMA node (processor socket) affinitized to a single 20-Core 2.2GHz processor with 335GB of memory allocated to the SQL Server, with SQL Server Persisted Log Buffer enabled.

3. A single 75GB db (2 total) affinitized to each of the 20-Core 2.2GHz processors, but only half of the available cores enabled in the BIOS with 335GB of memory allocated to the SQL Server, with SQL Server PLB enabled.

4. Two 75GB db’s (4 total) affinitized to each of the NUMA nodes (processor sockets) using the 20-Core 2.2GHz processors, and 670GB of the available memory allocated to the SQL Server, with SQL Server PLB enabled.

5. A single 75GB db (2 total) affinitized to each of the 8-Core 3.2GHz processors with 335GB of memory allocated to the SQL Server, and Persisted Log Buffer enabled. This is the same as the baseline test, but with PLB.

6. Read-In memory test. This was a single 75GB db (2 total) affinitized to each of the 8-Core 3.2GHz processors with 335GB of memory allocated to the SQL Server, with PLB enabled. The purpose of this test was to determine how long it would take the stopped SQL Server to fully recover the databases, and if there was any appreciable performance degradation to the SSD while the databases were being read into memory.

7. Write-out disk test. A single 75GB db (2 total) affinitized to each of the 8-Core 3.2GHz processors with 335GB of memory allocated to the SQL Server, with PLB enabled. The purpose of this test is the opposite of test case number 6 above; to see how long it would take the SQL Server to fully write any changes made to the database to disk upon a shutdown command being executed to the SQL Server.

For all of the test cases the following configuration settings were utilized:

• “Lock Pages in Memory” group policy modification enabled in the OS.

• SQL Server Trace flags: -T834 and -T9921, were also applied.

– Trace flag 834 permits the allocation of large pages in the SQL Server Buffer Pool, and trace flag 9921 enables SQL Server 2016 to see the 8GB NVDIMM modules for use as persisted log buffer storage devices.

There was 704GB of system memory available. Therefore, in order not to constrain the underlying operating system of memory resources, the maximum amount of memory that would be allocated to the SQL Server software was set to a limit of 670GB. The following key points also apply to all of the test cases that were executed

• A single 75GB database was contained within a single Resource Governor Resource Pool.

– With the exception of the 4-database test which had two databases in a single resource pool.

• The single processor tests had two resource pools and databases affinitized to a single NUMA node or Processor.

– With the exception of the two processor tests which had a single resource pool and database affinitized to a single NUMA node or Processor.

• The only test that was executed that did not have the SQL Server Persisted Log Buffer enabled was the initial baseline test.

Note Except for the power-up/recovery, and shut-down tests, all test cases were executed for 15 minutes.

Technical white paper Page 9

Test Methodology A wide gamut of tests was executed in various combinations of processors, memory, and database to NUMA node affinities. This was done with the goal of deriving what the best practices would be for obtaining maximum performance. Two different sets of processors were deployed including 8-Core 3.2GHz processors along with 20-Core 2.2GHz processors.

One of the goals of the examinations was to prove that similar performance can be achieved between the two different sets of processors from both a CPU utilization standpoint, and the quantity of batch requests per second. Although the second set of processors core count is more than twice that of the first, processor cores can be disabled in the servers BIOS creating potential savings in software licensing.

Table 1. Test case matrix

Test case

Processor set Active NUMA node(s)

Memory allocated to SQL Server

Memory allocated to each Resource Pool

DB size # of databases

Databases in each RP

Persisted Log

Buffer Enabled

Additional configuration

1 8-Core 3.2GHz 1 335GB 49% 75GB 2 1 No

2 20-Core 2.2GHz 1 335GB 49% 75GB 2 1 Yes

3 20-Core 2.2GHz 2 335GB 49% 75GB 2 1 Yes Only 10 of the cores were

enabled for each processor

4 20-Core 2.2GHz 2 670GB 49% 75GB 4 2 Yes

5 8-Core 3.2GHz 2 335GB 49% 75GB 2 2 Yes

6 8-Core 3.2GHz 2 335GB 49% 75GB 2 1 Yes Power-up/Recovery test

7 8-Core 3.2GHz 2 335GB 49% 75GB 2 1 Yes Shut-down test

Technical white paper Page 10

Analysis and recommendations The first, or baseline, test consisted of using the two 8-Core 3.2GHz processors with the intent of determining the quantity of batch requests per second and CPU utilization for the In-Memory workload. This test serves as the foundation for analysis for the subsequent test cases.

Figure 4. Baseline batch requests per second comparison. Test case 1 compared to test case 5

In Figure 4 above you will see that there was a difference of 1,732 batch requests per second or 6% increase between the Persisted Log Buffer being enabled and not, but as you will see in Figure 5 below, there was a 31.45% increase in processor utilization when the Persisted Log Buffer was not enabled.

Figure 5. Baseline CPU comparison. Test case 1 compared to test case 5

0

5000

10000

15000

20000

25000

30000

35000

Batc

h R

eque

sts

Per S

econ

d

Intel® Xeon® E5-2667v4 8-Core 3.2GHz Processor

Without PLB With PLB

0

5

10

15

20

25

CPU

%

8-Core 3.2GHz Processor

Without PLB

With PLB

1,732 more batch requests per second or a 6% increase without

PLB

31.45% increase in CPU utilization without Persisted

Log Buffer

Technical white paper Page 11

In Figure 6 below, the performance comparison is made between 2 x 8-Core 3.2GHz processors and 2 x 20-Core 2.2GHz processors with half of their cores disabled. The test was executed using 2 x 75GB databases contained within individual SQL Server Resource Governor Resource Pools with 49% of the available memory (335GB) allocated to each. Each Resource Pool was affinitized to a single processor socket as well.

Figure 6. Distinct processor set comparison. Test case 5 compared to test case 3

The difference in performance of how many batch requests per second were committed was less than 1,000 or 2.3%. This is a potential cost savings of over 23% in physical hardware, and software licensing costs2, should your application scope not exceed the requirement of more than 16 processing cores.

As illustrated in Figure 7 below, we also observed lower CPU utilization with the 2 x 20-Core processors having half of their available cores disabled. Although the difference between the two sets of processors measured in CPU utilization was 26.5%, the overall CPU utilization was extremely low as all of the work was concentrated within system memory. In this test, the CPU utilization never climbed above 10% as the 8-Core 3.2GHz CPU utilization was at 9.6%, and the 20-Core 2.2GHz processors with 10 of their cores enabled was only 7.8%.

Figure 7. CPU% utilization comparison. Test case 5 compared to test case 3

2 Based on HPE processor kit and Microsoft software list pricing as of 4/5/2017.

0

5000

10000

15000

20000

25000

30000

35000

Batc

h R

eque

sts

per S

econ

d

2 x 8-Core 3.2GHz vs 2 x 20-Core 2.2GHz(10-cores per processor)

20-Core 2.2GHz (10-Coresper processor enabled)

8-Core 3.2GHz Processors

0

2

4

6

8

10

12

CPU

%

2 x 8-Core 3.2GHz vs 2 x 20-Core 2.2GHz(10-cores per processor)

20-Core 2.2GHz (10-Coresper processor enabled)

8-Core 3.2GHz Processors

Less than 1,000 batch requests per second

or 2.3% difference

26.5% difference in processor utilization

Technical white paper Page 12

Similar to the test results shown above, we executed another test where we compared the results of the same two 8-Core 3.2GHz processors to a single 20-Core 2.2GHz processor with all of its cores enabled. As was done with the test above, the same two 75GB databases were contained within their own individual SQL Server Resource Governor Resource Pools with 49% of the available memory (335GB) allocated to each. The primary difference here, in Figure 8, is that when the test was executed using the 20-Core 2.2GHz processor, both Resource pools were affinitized to the same socket, where the 2 x 8-Core 3.2GHz processors had a Resource Pool affinitized to each socket.

Figure 8. Distinct processor set comparison between 2 x 8-Core processors and a single 20-Core processor. Test case 5 compared to test case 2

Again, the difference in performance was a meager 362.186 batch requests per second over the 15-minute time span that the tests were run. Although the price point comparison between the 2 x 8-Core 3.2GHz processors and a single 20-Core 2.2GHz is very low, if there is an expectation that greater processing needs may be required in the future, or the possibility that your architecture may require greater database consolidation, the other processor socket can be populated at a later date, or a different workload can also be affinitized to the remaining NUMA node. These test results represented a potential savings of 22% in physical hardware, and software licensing costs3

3 Based on HPE processor kit and Microsoft software list pricing as of 4/5/2017.

0

5000

10000

15000

20000

25000

30000

35000

Batc

h R

eque

sts

per S

econ

d

2 x 8-Core 3.2GHz vs 1 x 20-Core 2.2GHz

2 x 8-core 3.2GHzprocessors

1 x 20-core 2.2GHzprocessor

362.186 BRPS difference

Technical white paper Page 13

In test case 4, we doubled the workload using the 20-Core 2.2GHz processors to see whether or not the performance would meet our initial expectations. This time 4 x 75GB databases were contained within two SQL Server Resource Governor Resource Pools. Each Resource Pool had two databases in them, and 49% of the 670GB of total available memory in the SQL Server allocated to them.

Figure 9. Double the amount of workload along with twice the resources yields twice the performance. Test case 2 compared to test case 4.

As anticipated the HPE ProLiant DL380 Gen9 was able to produce double the amount of batch requests per second when allocated twice the workload with twice the amount of resources; 59,806 batch requests per second.

Further monitoring and analysis of CPU utilization occurred during these tests. We observed that CPU utilization was almost non-existent, as the majority of the “heavy lifting” was being accomplished via memory. Tests were also executed to discern the rate that 2 x 75GB databases could be loaded into memory and fully recovered upon start-up of the SQL Server, as well as written to disk upon the SQL Server’s shut down.

• The full recovery of both databases occurred as quickly as 1:34s upon start-up.

• The stopping of the SQL Server was completed in as fast as three seconds.

• These tests were executed using the two 8-Core 3.2GHz processors with each database encapsulated in a SQL Server Resource ManagerResource Pool, and each Resource Pool affinitized to a single processor socket.

Summary The HPE ProLiant DL380 Gen9 server is a workhorse system, providing scalability and high performance to run a myriad of different workloads. This white paper covered the configuration and scalability of running Microsoft SQL Server 2016 In-Memory tables on the HPE ProLiant DL380 Gen9 server, including highlighting different processor options and the use of HPE NVDIMM to highlight potential performance and cost savings. As presented in the test results described in this document, SQL Server 2016 In-Memory databases are memory intensive, and can potentially require twice the prospective space to accommodate the row level versioning mechanism that does away with locking. Further investigation and testing with customer specific data is recommended, to understand the actual overall memory overhead associated with In-Memory tables, prior to specific recommendations being made. Additionally, SQL Server 2016 In-Memory databases or database objects remove a substantial amount of load on CPU freeing up the resource for other processing needs. The CPU utilization never surpassed a threshold of 21% in any of the testing that was performed.

This Reference Architecture describes solution testing performed in March, 2017.

0

10000

20000

30000

40000

50000

60000

70000

2 x 75GB db's 1 x 20-Core 2.2GHz Processor 335GB of memory / 4 x 75GB db's 2 x 20-Core

2.2GHz Processors 670 GB of memory

2 dbs

4 dbs

59,806 batch requests per second or roughly twice the BRPS in the previous tests

Technical white paper Page 14

Appendix A: Bill of materials

Note Part numbers are at time of testing and subject to change. The bill of materials does not include complete support options or other rack and power requirements. If you have questions regarding ordering, please consult with your HPE Reseller or HPE Sales Representative for more details at, hpe.com/us/en/services/consulting.html.

Table 2. Bill of materials

Qty Part Number Description

HPE ProLiant DL380 Gen9 Server

1 767032-B21 HPE DL380 Gen9 Server 24SFF CTO Server Chassis

1 817947-B21 HPE DL380 Gen9 Intel Xeon E5-2667v4 (3.2GHz/8-Core/25MB/135W) Processor Kit

1 817947-L21 HPE DL380 Gen9 Intel Xeon E5-2667v4 (3.2GHz/8-core/25MB/135W) FIO Processor Kit

1 817965-B21 HPE DL380 Gen9 Intel Xeon E5-2698v4 (2.2GHz/20-Core/50MB/135W) Processor Kit

1 817965-L21 HPE DL380 Gen9 Intel Xeon E5-2698v4 (2.2GHz/20-core/50MB/135W) FIO Processor Kit

22 805351-B21 HPE 32GB(1x32) Dual Rank x4 DDR4-2400 CAS-17-17-17 Registered Memory Kit

2 782692-B21 HPE 8GB NVDIMM Single Rank x4 DDR4-2133 Module

1 727258-B21 HPE 96W Smart Storage Battery

1 726897-B21 HPE Smart Array P840 Controller Board

12 802582-B21 HPE 400GB SAS 12G Write Intensive SFF (2.5in) SC 3yr Wty SSD

2 652605-B21 HPE 146GB 6G SAS 15K rpm SFF(2.5in) Dual Port Enterprise 3yr Wty HDD

2 720478-B21 HPE 500W Flex Slot Platinum Hot Plug Power Supply Kit

1 BD505A HPE iLO Adv Incl 3yr TSU 1-Svr Lic

Technical white paper Page 15

Appendix B: Configuration adjustments HPE Persistent Memory Worthy of note is the sanitization of NVDIMM memory modules. Any time a system has new processors and/or NVDIMM memory modules installed, the NVDIMM memory modules require a sanitization and then configuration within Windows. To accomplish this procedure, the actual sanitization occurs in the HPE System Utilities.

1. Boot the server into the HPE System Utilities by pressing F9 when prompted.

2. Once in the System Utilities, you would need to navigate through the following submenus: System Configuration > BIOS/PlatformConfiguration (RBSU) > System Options > Memory Operations > NVDIMM Memory Operations.

3. Once within NVDIMM Memory Operations, the two options that need to be changed are “NVDIMM-N Sanitize/Erase on Next Boot Policy”,and “Sanitize/Erase all NVDIMM-N in the System”, as shown below.

4. Upon accessing the “NVDIMM-N Sanitize/Erase on Next Boot Policy” first (which is needed to access the second option), you will beprompted with the following warning:

Figure 10. RBSU Memory options screenshot

Technical white paper Page 16

5. The “NVDIMM-N Sanitize/Erase on Next Boot Policy” configuration option should be changed to “Sanitize/Erase and Boot to OperatingSystem.”

6. Once you’ve changed that, then you can access the “Sanitize/Erase all NVDIMM-N in the System” configuration option, which should bechanged to “Enabled” as depicted here:

Figure 11. Memory options sanitization screenshot

7. Once these configuration options have been modified, press F10 to save, and ESC to back out of the System Utilities saving as you exitcompletely and reboot the system.

8. Once you’ve completed this task, there are two critical steps to Initializing and formatting the NVDIMM’s in Windows, if the intent is to usethem for SQL Server “Tail of the Log” persisted log buffering:

a. Initialize the NVDIMM “disks” as GPT (GUID Partition Table)

b. Format them with the following command. (It’s the “/DAX” switch that tells SQL Server that these are Direct Access devices.)

Format driveletter: /y /q /DAX

Technical white paper Page 17

Sign up for updates

© Copyright 2017 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice.

The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein.

Microsoft, Windows, and Windows Server are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Intel, Xeon, and Intel Xeon, are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries.

a00006919enw, April 2017

Resources and additional links HPE ProLiant DL380 Gen9 product page, https://www.hpe.com/us/en/product-catalog/servers/proliant-servers/pip.hpe-proliant-dl380-gen9-server.7271241.html

SQL Server 2016 In-Memory OLTP Internals White Paper, https://docs.microsoft.com/en-us/sql/whitepapers/sql-server-in-memory-oltp-internals-for-sql-server-2016

HPE Reference Architectures, hpe.com/info/ra

HPE Servers, hpe.com/servers

HPE Storage, hpe.com/storage

HPE Networking, hpe.com/networking

HPE Technology Consulting Services, hpe.com/us/en/services/consulting.html

To help us improve our documents, please provide feedback at hpe.com/contact/feedback.