1. Hardware Recommendations to make installations hum
Eric Wauters
iFacto Business Solutions NV
Development Manager
September 18, 2018

2. Agenda
Basics
Native DB Server
SQL Server
Terminal Services
Clients & NAS
Network

3. Agenda Basics Why pay attention to hardware? Native vs. SQL Server
Core Components
Native DB Server
SQL Server
Terminal Services
Clients & NAS (Navision Appl Server)
Network

4. Basics - Why paying attention to hardware?
Performance Tuning Areas:
Application: 80-90%
Infrastructure: 10-20%
You need a solid base
Quick fix
May be show a code example?

5. Basics - Differences Native – SQL Server
Microsoft Native DB
Microsoft SQL Server
Single logical db - multiple files (up to 16)
Multiple logical databases - each db multiple filegroups - each filegroup multiple files
DB Size limit 128 Gb
(256 or 512 with special agreement)
No real DB size limit
Single processor
Multiprocessor
32 bit only
32 bit and 64 bit
1GB RAM only
Large RAM support
Not cluster aware
Cluster aware
Backup: Client based or HOTCOPY
Various backups strategies
Interfacing through Client, NAS, C/ODBC,C/FRONT
Various interfaces (API, ODBC, etc...)
Feature rich:
Reporting Services, Analysis services, Integration Services, Alerts, Jobs, Security, ...

6. Basics - Differences Native – SQL Server
Different server options need different hardware

7. Basics - Similarities Native – SQL Server
Index is an index, Lock is a lock, Block is a block, Deadlock is a deadlock
Get data fast, Write data fast!

8. Basics - Core Components

9. Basics - Core Components
Memory (RAM)
Processors (CPU)
Disk Subsystem (RAID)
Network
Server settings

10. Basics - Core Components - Storage Types
RAID 0
RAID 1
RAID 10
RAID 5

11. Storage Types - RAID0 RAID0 Physical Layout Logical Layout 1 1 2 3 2 41 1 2 3 2 4 5 3 6 7 4 8 9 5 6 7 8 9

12. Storage Types - RAID1 Logical Layout RAID1 Physical Layout 0’ 1 1 1’ 20’ 1 1 1’ 2 2 2’ 3 3 3’ 4 4 4’ 5 5 5’ 6 6 6’ 7 7 7’ 8 8 8’ 9 9 9’

13. Storage Types - RAID1 Logical Layout RAID10 Physical Layout 5 1 1 6 25 1 1 6 2 2 7 3 3 8 4 4 9 5 0’ 5’ 6 1’ 6’ 7 2’ 7’ 8 3’ 8’ 9 4’ 9’

14. Storage Types - RAID5 Logical Layout RAID5 Physical Layout 1 0-1parity1
0-1parity 1 2
2-3 parity 3 2
4-5 parity 4 5 3 6 7
6-7 parity 4 8
8-9 parity 9 5 6 7 8 9

15. Hardware recommendations Server Settings
Agenda
Basics
Native DB Server
Hardware recommendations
Server Settings
SQL Server
Terminal Services
Clients & NAS (Navision Appl Server)
Network

16. Native – Hardware Recommendations
Limited possibilities due to limited support.
1Gb RAM
1CPU core
Single database per server

17. Native - Hardware Recommendations
Dedicated Server
CPU
1 CPU for NAV
(If necessary: second CPU for +40 users)
RAM
1,5 Gb (1 for NAV; 0,5 for OS)
DISKS
OS – dedicated RAID 1
fdb file – dedicated RAID 1
.fdb > 5Gb
 Split over multiple RAID 1
 RAID 10
15K RPM
Show how to create a database with multiple files

18. Native - Server Settings
A few tips:
All database files: same file size
Dedicated fysical disks per file
Use commitcache
Make sure you use a UPS
If creating extra database file:
Backup/delete db/create db/restore!
DB Cache
Show how to create a database with multiple files
DB Cache: 1/3 – 2/3 – with minimum 200Mb for OS

19. Hardware recommendations Server Settings
Agenda
Basics
Native DB Server
SQL Server
Hardware recommendations
Server Settings
Terminal Services
Clients & NAS (Navision Appl Server)
Network

20. SQL Server – Recommendations - Core Components
Memory (RAM)
Processors (CPU)
Disk Subsystem
Server Settings

21. SQL Server – Recommendations - Memory
Importance
memory < > disks = ns compared to ms!
CACHE!

22. SQL Server – Recommendations - Memory
32 bit vs 64 bit
32 bit directly addresses up to 4Gb of memory
(232 = bytes = 4Gb)
64 bit can address an “indefinite” amount of RAM
(264 = bytes
= ,7 Gb)
Let's start with the basics.
First, 32-bit OSs can directly address up to 4GB of memory. That is, 32 bits can represent 232 or 4,294,967,296 different addresses or locations in memory where data can be stored. But 1 GB of memory equals 1,073,741,824 bytes, so 4,294,967,296 bytes represents 4GB of addressable memory. However, 32-bit SQL Server can access more than 4GB of memory on a server by using Physical Address Extensions (PAE) that create windows into a larger memory space. For example, if your server has 32GB of memory, you have eight logical windows of 4GB each that are mapped by the OS in and out of the 4GB set of addresses that can be directly addressed by a 32-bit OS. You can enable this ability to access more memory by placing the /PAE switch in the boot.ini file. You also have to make some configuration changes in SQL Server to enable Address Windowing Extensions (AWE) memory. The Microsoft article discusses both steps

23. SQL Server – Recommendations - Memory
32 bit – how to use more RAM?
Boot.ini:
/3GB:
Default windows install:
2 Gb reserved for kernel (OS)
2 Gb for usermode
With /3Gb:
1 Gb reserved for kernel (OS)
3 Gb for usermode
/PAE
“Physical Address Extensions”
memory address extension that enables support of greater than 4 GB of physical memory
Let's start with the basics.
First, 32-bit OSs can directly address up to 4GB of memory. That is, 32 bits can represent 232 or 4,294,967,296 different addresses or locations in memory where data can be stored. But 1 GB of memory equals 1,073,741,824 bytes, so 4,294,967,296 bytes represents 4GB of addressable memory. However, 32-bit SQL Server can access more than 4GB of memory on a server by using Physical Address Extensions (PAE) that create windows into a larger memory space. For example, if your server has 32GB of memory, you have eight logical windows of 4GB each that are mapped by the OS in and out of the 4GB set of addresses that can be directly addressed by a 32-bit OS. You can enable this ability to access more memory by placing the /PAE switch in the boot.ini file. You also have to make some configuration changes in SQL Server to enable Address Windowing Extensions (AWE) memory. The Microsoft article discusses both steps
1. AWE is used to access memory over 4GB 2. To enabled AWE you must specify the /PAE switch in the boot.ini 3. on a 32 bit OS 4GB of memory can be directly accessed 4. a default windows install on a machine with 4GB will allocated 2GB to Usermode memory and 2GB to kernel mode memory 5. you can change the kernel mode \user mode allocation by using the 3GB switch in the boot.ini, this will change it to 3GB Usermode 1GB Kernel mode

24. SQL Server – Recommendations - Memory
32 bit – how to use more RAM?
SQL Server:
AWE: to acces memory over 4Gb
“Address Windowing Extensions”
Address Memory over 4Gb as nonpaged memory
dynamically map views of the nonpaged memory to the 32-bit address space
You must specify /PAE in boot.ini
Let's start with the basics.
First, 32-bit OSs can directly address up to 4GB of memory. That is, 32 bits can represent 232 or 4,294,967,296 different addresses or locations in memory where data can be stored. But 1 GB of memory equals 1,073,741,824 bytes, so 4,294,967,296 bytes represents 4GB of addressable memory. However, 32-bit SQL Server can access more than 4GB of memory on a server by using Physical Address Extensions (PAE) that create windows into a larger memory space. For example, if your server has 32GB of memory, you have eight logical windows of 4GB each that are mapped by the OS in and out of the 4GB set of addresses that can be directly addressed by a 32-bit OS. You can enable this ability to access more memory by placing the /PAE switch in the boot.ini file. You also have to make some configuration changes in SQL Server to enable Address Windowing Extensions (AWE) memory. The Microsoft article discusses both steps
AWE is used to access memory over 4GB 2. To enabled AWE you must specify the /PAE switch in the boot.ini 3. on a 32 bit OS 4GB of memory can be directly accessed 4. a default windows install on a machine with 4GB will allocated 2GB to Usermode memory and 2GB to kernel mode memory 5. you can change the kernel mode \user mode allocation by using the 3GB switch in the boot.ini, this will change it to 3GB Usermode 1GB Kernel mode
SQL
An x86 server system can manage a maximum of 4 GB of memory. This limits the addressable memory space for Windows server 2003 systems to 4 GB. (This is true for all 32-bit operating systems). With 2 GB reserved for the operating system by default on 32-bit Windows, only 2 GB of memory remains for SQL 2000 or SQL Server 2005 x86. You can increase this amount to 3 GB by setting a /3GB switch in a Windows BOOT.INI. In order to use more than 4 GB of memory AWE must be enabled. AWE is a set of memory management extensions to the Microsoft Win32 API that allows SQL Server x86 to address memory b eyond 4 GB. Using AWE, applications can acquire physical memory as nonpaged memory, and then dynamically map views of the nonpaged memory to the 32-bit address space.
These issues are eliminated on the x64 platform when directly addressing memory as AWE is no longer necessary. In x64 environments you are no longer limited to 2 GB for memory for plan caching, sort space, and lock memory. For any Dynamics - NAV implementation that will use more than 4 GB of memo ry for SQL Server we recommend x64.
The expanded lock memory available when utilizing SQL Server 2005 x64 would be very beneficial if you plan on using the “Always Rowlock” database option in Dynamics - NAV as you could exceed the 2 GB of lock memory limit that exists on x86
Server edities

25. SQL Server – Recommendations - Memory
32 bit – Server settings
Min/Max SQL Server Memory
Set the same for ‘constant’ behaviour
Memory
Check the Windows Server and SQL Server editions limitations
/3Gb
/PAE
AWE
< 2Gb No
2 - 4Gb
Yes
4 – 16Gb
> 16Gb

26. SQL Server – Recommendations - Memory
32 bit - Warning when using AWE:
Imposes overhead
Adds initialization time
Memory above 4Gb is only for data caching, not for:
Plan caching
Sort space
Lock memory
AWE enables SQL Server 2000 and 2005 x86 to address larger amounts of data. Although AWE makes execution of memory-intensive appli cations possible when otherwise impossible, AWE imposes overhead, adds initialization time, and can face performance challenges under various processing conditions. The use of AWE in a x86 environment is only for data caching so plan caching, sort space, and lock memory are still limited to 2 GB o f memory in x86

27. SQL Server – Recommendations - Memory
What about x64?
Support for large RAM - no boot.ini changes
Not only data caching, also:
Plan caching
Sort space
Lock memory
=> “Always Rowlock”
SQL
An x86 server system can manage a maximum of 4 GB of memory. This limits the addressable memory space for Windows server 2003 systems to 4 GB. (This is true for all 32-bit operating systems). With 2 GB reserved for the operating system by default on 32-bit Windows, only 2 GB of memory remains for SQL 2000 or SQL Server 2005 x86. You can increase this amount to 3 GB by setting a /3GB switch in a Windows BOOT.INI. In order to use more than 4 GB of memory AWE must be enabled. AWE is a set of memory management extensions to the Microsoft Win32 API that allows SQL Server x86 to address memory b eyond 4 GB. Using AWE, applications can acquire physical memory as nonpaged memory, and then dynamically map views of the nonpaged memory to the 32-bit address space. AWE enables SQL Server 2000 and 2005 x86 to address larger amounts of data. Although AWE makes execution of memory-intensive appli cations possible when otherwise impossible, AWE imposes overhead, adds initialization time, and can face performance challenges under various processing conditions. The use of AWE in a x86 environment is only for data caching so plan caching, sort space, and lock memory are still limited to 2 GB o f memory in x86
These issues are eliminated on the x64 platform when directly addressing memory as AWE is no longer necessary. In x64 environments you are no longer limited to 2 GB for memory for plan caching, sort space, and lock memory. For any Dynamics - NAV implementation that will use more than 4 GB of memo ry for SQL Server we recommend x64.
The expanded lock memory available when utilizing SQL Server 2005 x64 would be very beneficial if you plan on using the “Always Rowlock” database option in Dynamics - NAV as you could exceed the 2 GB of lock memory limit that exists on x86
Server edities

28. SQL Server – Recommendations - Memory
Windows - Maximum Memory
Windows 2003 (32bit)
Windows 2003 Standard = 4GB
Windows 2003 Enterprise = 64GB
Windows 2003 Datacenter = 128GB
Windows 2003 (64bit)
Windows 2003 Standard = 64GB
Windows 2003 Enterprise = 1TB
Windows 2008 (32bit)
Web Edition: 4GB
Standard Edition: 4GB
Enterprise Edition: 64GB
Datacenter: 64GB
Windows 2008 (64bit)
Web Edition: 32GB
Standard Edition: 32GB
Enterprise Edition: 2TB
Datacenter: 2TB

29. SQL Server – Recommendations -Memory
SQL Server Maximum Memory
SQL 2000
Desktop Engine = 2GB
Standard Edition = 2GB
Enterprise Edition = 64GB
SQL2005
Express Edition = 1GB
Workgroup Edition = 3GB
Standard Edition = Operating System maximum
Enterprise Edition = Operating System maximum

30. SQL Server – Recommendations - Memory
IMPORTANT
On x64 SQL Server platforms you must give the SQL Service account the “Lock Pages in Memory” privilege in order for SQL to use the available RAM
KB Article
Kort tonen waar dat te vinden is.

31. SQL Server – Recommendations - Memory
CONCLUSION
Memory Recommendations
As big as you can afford
Rough guidelines
CCU
<6
6-50
51-150
RAM
2 Gb
4 Gb
8 Gb
16 Gb

32. SQL Server – Recommendations - CPU
CPU recommendations
Typically NOT a bottleneck
Cores vs Sockets
Disable Hyper Threading
Redundant
CCU
<6
6-50
51-150
CPU Cores 2 4 8
CPU is very low. No sp's and such.
There is not much done on the SQL Server. Most of the processing is done on the client.
Cores and sockets: there is a difference. But NAV close enough.
Intel and AMD: the best that you can afford.
Hyper-threading: CPU used to be expensive: so create a virtual processor was a good idea. But inthe world of dual, quad cores, it can create issues. SQL doesn't differentiate between a core / cpu / hyperthreaded ... So sql could be sending a huge job to a virtual (hyperthreaded) CPU Now, no need anymore for hyperthreading. So disable hyperthreading on these multiple cores.
In the NAV world, cores is close enough. Cores is nog really the same, but in NAV world close enough.
If you need 4 cores, think about 2 dual cores instead of one quad core, because of recundancy!!.

33. SQL Server – Recommendations - CPU
Windows - Maximum CPU Sockets
Windows 2003 (32bit)
Windows 2003 Standard = 4CPU
Windows 2003 Enterprise = 8CPU
Windows 2003 Datacenter = 64CPU
Windows 2003 (64bit)
Windows 2008 (32bit)
Web Edition = 4CPU
Standard Edition = 4CPU
Enterprise Edition = 8CPU
Datacenter = 32CPU
Windows 2008 (64bit)

34. SQL Server – Recommendations - CPU
SQL Server Maximum CPU Sockets
SQL 2000
Desktop Engine = 2CPU
Standard Edition = 4CPU
Enterprise Edition = 32CPU
SQL2005
Express Edition = 1CPU
Workgroup Edition = 2CPU
Enterprise Edition = Operating System maximum

35. SQL Server - RAID Recommendations
Three Spindles is a must!
WinOS,Page File,SQL Program files,etc.
Pagefile.sys
Transaction LOG
100% write
Writes all the time (“write ahead”)
Database File(s)
Read: 80-90%, Write 10-20%
Writes at checkpoints

36. SQL Server - RAID Recommendations
What about TempDB:
Used for large operations (e.g. Reindex), mainly out of hours.
In SQL2005: often 5-10% of IOs on TempDB files.

37. SQL Server - RAID Recommendations
OS, SQL Program files, etc = RAID1
LOG File = RAID1
DB Files = RAID10
(TempDB = RAID1)
Small disks, not for capacity but for IOPS !
Do NOT use RAID5.
RAID
These are most common, there are more, but these are far most commonly used:
RAID 1 and 10
RAID 5: striped set with parity.
For writing data: RAID 5 has twice as many IO's then the other: for every physical tast: 4 IO's. That can cause performance issues. You don't have that extra IO to spare. You should make transactions as fast as possible. It reads just af fine als RAID 10, so if you have a test database, or for some reason a read database, you can use raid 5.
So, alsways use a combination of RAID 1 and 10. Also seperate TL and Data. TL for the read/write head keeping the right position. 1 for TL, 10 for data. The log file is always pending at the end of the file, so you want to keep the read/write head at the right position to write the log. So, dedicated logical/digital disk.

38. SQL Server - Disks Summary
Biggest bottleneck
Think “Spindles” not “Capacity”
As fast as possible
15kRPM
RAID 1/RAID10
Think "spindles not capacity". For disk system: fysical spindels is more important, not capacity. With 300Gb one disk, you also have one head to server those 300Gb. The amount of spindels will dictate the speed.
Don't think about the space you waste, you have too look at the number of spindels, the number of read/write heads that are reading and handling your data.

39. SQL Server – Server Settings
MDOP
Auto Create Stats
Auto Update Stats
Auto Shrink – Auto Grow
MDOP
NAV only uses small sql statements. NO joins, nothing fancy.
CURSOR based.
A job to SQL server: how many CPU's does SQL use. Default: 0: so use what you want. What can happen. With these small statements: start parallel execution of the queries, can decrease the performance. The statements are small enough, so only 1, then you force him to use one.
Has helped dynamics NAV in performance
Auto Create stats
Same as below.
Auto update statistics
The drawback after this is turned off, is that there are no up-to-date statistics. NAV needs sometimes the last records, but SQL doesn't know what it is anymore if you turn it off.. .
If you do turn it off ... Have a mechanism in place (maintenance plan) that rebuilds the statistics daily.
As a general rule: turn it on.
If you turn it off: MAKE SURE you have a job that do it daily. After a week your performance will be off by 50-60%
There is overhead with updating stats, but there is also overhead with out-of-date statistics.
Recovery model
Sometimes problem: log file too big.
If you're not doing TL backup: recovery model should be "simple". If they do, set it to "full".
NAV defaults to "full"
Auto-shrink database
Never turn this on. Never shrink a database!
Actually, you don't want to autogrow either. Just make it as large as you have diskpace for, so you never have the performance hit when SQL is expanding (it just stops the transaction, grows the file

40. Agenda Terminal Services Basics Native DB Server SQL Server
Clients & NAS (Navision Appl Server)
Network

41. Terminal Services Memory CPU Disk Network
64 MB per Dynamics NAV user + 1 GB for OS
Example: (100 x 64) = 7.4 GB or 8 GB
CPU
users per CPU core
Based on client activity; Manufacturing and so on
Disk
1Gb per user
Based on activity
Network
1 Gigabit Ethernet

42. Client & Navision Application Server (NAS)
Agenda
Basics
Native DB Server
SQL Server
Terminal Services
Client & Navision Application Server (NAS)
Network

43. RAM CPU Disk Network Clients and NAS 256 MB or greater
2.0 GHz or greater
Disk
IDE (1 GB of drive space)
Network
100 Megabit (No hubs)

44. Agenda Network Basics Native DB Server SQL Server Terminal Services
Client & Navision Application Server (NAS)
Network

45. 1 Gigabit Backbone 100 Megabit No hubs only switches Network SQL
Terminal Services
BizTalk
IIS
Application Servers
100 Megabit
Clients
No hubs only switches

46. Agenda
Basics
Native DB Server
SQL Server
Terminal Services
Client & Navision Application Server (NAS)
Network

47. What about NAV 2009?
New architecture
 Middle Tier
Only SQL Server

48. Resources Microsoft Storagesearch.com SQLPerform Ltd. Partnersource
Windows & SQL Server editions:
Storagesearch.com
SQLPerform Ltd.

49. Q&A
Thank you for your attention
Eric Wauters