Because this data is available in real time without needing to wait for the query to complete, these execution statistics are extremely useful for debugging query performance issues.

https://msdn.microsoft.com/en-us/library/dn831878(v=sql.130).aspx

SQL Server 2016 Community Technology Preview 2 Evaluations

새로운 버젼이 나왔네요...
2014 버젼도 쓰지 않은데, 2016버젼까지 나왔으니... 에휴에휴 

As the biggest leap forward in Microsoft’s data platform history, SQL Server 2016 delivers breakthrough mission critical performance, deeper insights across any data on many devices and enables the power of hyperscale cloud to unlock new hybrid scenarios.

• Operational Analytics: Insights on operational data, works with in-memory OLTP or on disk 

• In-memory OLTP enhancements: Greater T-SQL surface area, terabytes of memory supported and greater number of parallel CPUs

• Query Data Store: Monitor and optimize query plans with full history of query execution 

• Native JSON: Parsing & storing of JSON as relational data & exporting relational data to JSON 

• Temporal Database: Track historical changes 

https://www.microsoft.com/en-us/evalcenter/evaluate-sql-server-2016
https://www.microsoft.com/en-us/server-cloud/products/sql-server-2016/

http://www.sqlskills.com/blogs/paul/important-change-vlf-creation-algorithm-sql-server-2014/

For SQL Server 2014, the algorithm is now:

• Is the growth size less than 1/8 the size of the log?
• Yes: create 1 new VLF equal to the growth size
• No: use the formula above

So on SQL Server 2014, if you created your log at 1GB and it auto-grow in chunks of 512 MB to 200 GB, you’d have:

• 16 VLFs from the initial log creation
• All growths up to the log being 4.5 GB would use the formula, so growths at 1, 1.5, 2, 2.5, 3, 3.5, 4 GB would each add 8 VLFs * = 56 VLFs
• All growths over 4 GB will only create 1 VLF per growth = (200 – 4) x 2 = 392 VLFs
• Total = 392 + 56 + 16 = 464 VLFs

464 is a much more reasonable number of VLFs than 3200, and will be far less of a performance problem.