{"id":4615,"date":"2016-08-15T16:53:51","date_gmt":"2016-08-15T15:53:51","guid":{"rendered":"http:\/\/www.onomi.co.uk\/?p=4615"},"modified":"2018-08-21T11:16:36","modified_gmt":"2018-08-21T10:16:36","slug":"lightning-bolt-performance-sql-server","status":"publish","type":"post","link":"http:\/\/content.n4stack.io\/2016\/08\/15\/lightning-bolt-performance-sql-server\/","title":{"rendered":"Lightning Bolt performance from your SQL Server"},"content":{"rendered":"

[et_pb_section bb_built=”1″ admin_label=”section” _builder_version=”3.0.47″ custom_padding=”0|0px|54px|0px|false|false”][et_pb_row admin_label=”row” _builder_version=”3.0.47″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” custom_padding=”0|0px|27px|0px|false|false”][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.11″ header_text_color=”#ffffff” background_size=”initial” background_position=”top_left” background_repeat=”repeat” use_border_color=”off”]<\/p>\n

SQL Server Performance<\/h1>\n

Suffering SQL Server Performance Issues?: A story of Olympic sprints and handy SQL Server hints!!!<\/strong> Usain Bolt, the world’s fastest runner, now boasts his third successive 100m Olympic title. That level of performance, the confidence in success when the pressure is at its greatest is an amazing achievement. However, the ability to start writing a blog on the performance level of Usain Bolt and then draw a very iffy link to SQL Server performance tuning surely has to surpass this. Some may say it\u2019s just a dirty, low down, good for nothing tactic \u2026. Well, yes, but, but, but… Read on, because when your business and colleagues are looking at you in anticipation, hoping, expecting, needing the database to perform during a critical trading period. Wouldn’t it be great to smile confidently and if the feeling takes you pull out an impromptu \u201cLighting Bolt\u201d swagger in the boardroom. Of course it would, so here are 5 handy hints to help you on the road to achieving stunning SQL Server performance: 1) Review your index usage:<\/strong> Make sure you review the missing\/redundant indexes as well as overlapping\/duplicate indexes which would cause unnecessary resource usage, thus preventing the best efficiency. 2) Make sure that your IO doesn\u2019t s*ck:<\/strong> Whilst PAGEIOLATCH is usually associated with disk IO throughput issues, it can also be caused by excessive TSQL query parallelism. This, however, is usually seen on systems with many logical cores where the max degree of parallelism is set to the default value of 0 (unlimited across all available cores). The disks (storage) can be overwhelmed by too much concurrency. Use Windows Perfmon to determine your read\/write latency. 3) Check tempdb is configured properly \u2013 default may not be the best option<\/strong>: The tempdb is not just used for the temporary tables you create but SQL Server engine uses it for sorting\/joining data, read committed snapshot isolation, availability groups, rebuild indexes in temp, etc. It’s important that the tempdb is configured properly. Prior to SQL Server 2016, by default you only start with 1 data file. But a good rule of thumb is:<\/p>\n