Customers: Partners: GP 2013 Customers: Partners: Isolation of the database files Log Data Files (LDF) It is recommended to always isolate the Microsoft Dynamics GP database log files on a dedicated RAID 1 or RAID 10 volume. This is to ensure that SQL Server can always write to the log file as fast as possible with no contention from the MDF Input/Output (I/O) activity. This will have a positive impact on the performance of SQL statements (inserts, updates, deletes) in the database because SQL Server can continue to the next statement as soon as the log is written. Master Data (MDF) It is recommended to always isolate the Microsoft Dynamics GP database data on a dedicated RAID 5 or RAID 10 volume. Ensure you have adequate disks to handle your I/O load, otherwise latency will increase once the disks are saturated. TEMPDB (MDF and LDF) It is recommended to always isolate the TEMPDB database (MDF and LDF) on a dedicated RAID 1 or RAID 10 volume. Performance may also benefit by creating 1 data file per CPU for TEMPDB as recommended in the article below. Refer to the article below for the SQL Server Storage Top 10 Best Practices Latency Latency from the disk subsystem is one of the most common causes for performance issues. Proper placement of the database files across correctly sized RAID volumes will ensure a solid base to troubleshoot against. The following disk counters provide the best evidence latency of how well the disk subsystem is handling the requests from SQL Server. Performance Monitor Counter Description Average Disk Sec/Read Measure of disk latency. Lower values are better however & this can vary and is dependent on the size and nature of Average Disk Sec/Write the I/Os being issued. Numbers also vary across different storage configurations (cache size/utilization can impact this greatly). “On well-tuned I/O subsystems, ideal values would be:
Customers: Partners: GP 2013 Customers: Partners: Isolation of the database files Log Data Files (LDF) It is recommended to always isolate the Microsoft Dynamics GP database log files on a dedicated RAID 1 or RAID 10 volume. This is to ensure that SQL Server can always write to the log file as fast as possible with no contention from the MDF Input/Output (I/O) activity. This will have a positive impact on the performance of SQL statements (inserts, updates, deletes) in the database because SQL Server can continue to the next statement as soon as the log is written. Master Data (MDF) It is recommended to always isolate the Microsoft Dynamics GP database data on a dedicated RAID 5 or RAID 10 volume. Ensure you have adequate disks to handle your I/O load, otherwise latency will increase once the disks are saturated. TEMPDB (MDF and LDF) It is recommended to always isolate the TEMPDB database (MDF and LDF) on a dedicated RAID 1 or RAID 10 volume. Performance may also benefit by creating 1 data file per CPU for TEMPDB as recommended in the article below. Refer to the article below for the SQL Server Storage Top 10 Best Practices Latency Latency from the disk subsystem is one of the most common causes for performance issues. Proper placement of the database files across correctly sized RAID volumes will ensure a solid base to troubleshoot against. The following disk latency counters provide the best evidence of how well the disk subsystem is handling the requests from SQL Server. Performance Monitor Counter Description Average Disk Sec/Read & Average Disk Sec/Write Measure of disk latency. Lower values are better however this can vary and is dependent on the size and nature of the I/Os being issued. Numbers also vary across different storage configurations (cache size/utilization can impact this greatly). “On well-tuned I/O subsystems, ideal values would be: