Information Systems software coding for a proprietry Learning Management System (LMS) with complete integration and stringent Active Directory hybrid CISCO Systems/IEEE port map stack to route The University of Western Australia and Harvard University from a hardware SQL Server with RAID-configured Virtual SQL Servers in the cloud-hybrid Multipoint-protocol virtualisation of a composite Internet of Things (IoT) to relay packet signals in real-time with Hbb Broadcasting frequency signals routed through ezy-proxies and our respective Universities for Institution-wide, minimal labour hour information systems administration to maximise positive outcomes of student, faculty, library and student administration for protocol pedagogy and intranet-directed Strategic Management of student and faculty support and services as an alternative to reduce discrete-object administrative and learning material delivery inefficiencies as has been found with third-party LMS such as WebCT and Blackboard through our Universities electronic auto-compiling object errors as is a current area of research in software API universal framework alignment, and primary objective labour hours for increased Research and Institution-wide revenue raising of objective reduction in student intake population numbers to benefit both student study and reading and also commercial intellectual property of private-sponsored research at The University of Western Australia and Harvard University. I am also interested in

SQL Server 2016 introduced Query Store, and SQL Server 2017 CU3 brought us aggregated wait stats at the query level. This is great information for data driven DBAs who need to be able to track plan changes over time, etc.

With that in mind, an additional data collector for wait stats per database would be a great product feature, independent from Query Store data collection.

We all know the limitations of the wait stats DMVs now:

- They're cumulative over time
- They're instance-wide
- There's a lot of potential noise from wait types that aren't registered

If you wanna figure out what's going on with them, you have to log them to a table yourself, or spend a bunch of money on a monitoring tool.

SQL Server should have a database-level option to store wait stats at a user-defined interval, for a user-defined period of time, the same way that Query Store works now. There could be additional options to only log significant waits based on occurrences and duration, etc. To make it extra useful, data could be centralized in msdb (or via another system view, like `sys.all_wait_stats` or something).

This would be an invaluable feedback mechanism for SQL Server users at all levels, especially now that Availability Groups and cloud migrations are more and more common. Admins with SQL Server responsibility need historical data like this to gauge workload efficacy on different hardware.

Thanks for reading!

Reorganizing a columnstore index can, in some cases, cause the modification_counter on the table's statistics to increase. This is unexpected because while the underlying structure of the table is being changed, the data itself isn't being modified. This can lead to issues where SQL is automatically updating statistics the next time a query is executed against the table in cases where the modification_counter increases a significant amount because of the REORGANIZE. This has been particularly problematic for our large fact table with 150+ billion rows and full scan statistics across 40+ columns.

Attached is a reproduction script with three examples:

• A columnstore index REORGANIZE that has no impact on row groups does not impact modification_counter
• A columnstore index REORGANIZE that compresses an open row groups does not impact modification_counter
• A columnstore index REORGANIZE that combines two compressed row groups does impact modification_counter

I have observed this behavior in 2016 and vNext but not tested it against other versions. The impact to the modification_counter is different across these two versions, though in both cases the modification_counter is increased as a result of the REORGANIZE.

Feature request: expose information about what indexes the optimizer considered while compiling an execution plan. Specifically, the index names and WHY the index was rejected for that particular query. This could potentially be included in per-operator execution plan properties (see attached mockup), an extended event target, or some other avenue.

Reason: many developers and DBAs wonder why certain indexes on their tables aren't being chosen for specific queries. This gives them better tools to figure that out and make better use of the SQL Server product.

I've blogged about this feature request in more detail here: http://joshthecoder.com/2018/06/21/feature-request-index-rejection-reasons.html

This request was inspired by a feature of the RavenDB document database: https://ayende.com/blog/183425-C/ravendb-4-1-features-explain-that-choice

Working with an SSAS multidimensional cube that was developed using SSDT 17.3, the Data Source View for the cube is showing multiple phantom tables as the data source view is changed/refreshed. This is happening when looking at the Data Source View for both cubes as well as dimensions.

The Data Source View object itself does not show any issues, cube functionality does not appear to be affected when it is deployed and processed.

When trying to use the "Copy Diagram from" function, Visual Studio crashes on me.

The issue has persisted as I've upgraded to 17.4, as well as testing with SSDT 15.x. This is a continuation of the issue described at https://social.msdn.microsoft.com/Forums/en-US/b4be5ff0-5b9f-4538-9ec0-5def3bab4fff/phantom-tables-in-ssas-cube-data-source-view?forum=ssdt

Currently there is no way to link together or to see execution of a view (or nested views) as part of a query execution plan if that query based on simple or on nested views. That makes very hard to explain how a simple query like SELECT * FROM dbo.view can be very slow. A query execution plan (in QUERY Store as well) has only details of a query itself. However, view (or nested views even worst) contributes to the slow execution tremendously. As a view is executed at the time of a parent's query execution - it shouldn't be a problem but will help a lot in troubleshooting.
(That is a copy of the same idea from Visual Studio user voice)