Would love to have a new Server-Wide as well as the Database Scoped Configuration configuration that would be called "Optimise for Analytics" and that would server the purpose of tuning the Storage Engine & Query Processor specifically for the Analytical Workloads (Business Intelligence, Data Warehousing, Data Preparation for ML, etc).

The actual functionalities to be controlled by this option would be such as: -E configuration, Query Optimiser huge preference for the Hash Joins, Bigger preference for the Batch Execution Mode for the Rowstore tables, Bigger preferences for the Scans and Prefetching for the Storage Engine, Bigger Columnstore Object Pool allocation for the server, Actual Cached Plans improvements, etc

When RAID controllers are idle, they automatically check the storage to make sure it's still okay. Why not SQL Server too?

Some of the pieces are there – for example, SQL Server already has the ability to watch for idle CPU times and run Agent jobs when it’s bored. For starters, that’d probably be good enough to save a lot of small businesses from heartache. For the databases over, say, 100GB, it’d be really awesome to have resumable physical_only corruption checking – tracking which pages have been checked (just like how the differential bitmap tracks page changes), with page activity reset when the page is changed (again, just like the differential bitmap.) This wouldn’t count the same as a real CHECKDB, which needs to do things like compare index contents – but it'd be a big improvement over what we have now in environments where folks just aren't aware that the onus for data integrity is on them, not SQL Server.

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!

SQL Server has been ported to Linux for over a year now and it is time the complete SMO library (or what can be) is ported over to cross-platform as well.

Only 9 or so core files have been ported over to .NET Core and this allowed the sqlserver module to port over a small set of cmdlets to PS Core. This does not work for other modules like dbatools that use a wider berth of the library.

There are plenty of other modules in PowerShell (and applications too) that would like to provide cross-platform support for managing SQL Server enterprises. This cannot be done until SMO is completely ported over.

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

DBCC CHECKDB reports no errors, I rebuilt the indexes just to be sure. It happens when running this query:

WITH t1 AS
(
SELECT [Endpoints].[Name] AS [f1],[MatchLocations].[Location] AS [f2],ISNULL(SUM([Matches].[LastCount]), 0) AS [f3],ROW_NUMBER() OVER (ORDER BY [Endpoints].[Name] ASC) AS [f4]
FROM MatchLocations
INNER JOIN [Matches] ON ([MatchLocations].[Id] = [Matches].[MatchLocationId])
INNER JOIN [Endpoints] ON ([Endpoints].[Id] = [MatchLocations].[EndpointId])
GROUP BY [Endpoints].[Name],[MatchLocations].[Location]
)
SELECT [t1].[f1] AS [t1_f1],[t1].[f2] AS [t1_f2],[t1].[f3] AS [t1_f3]
FROM t1
WHERE ([t1].[f4] BETWEEN 1 AND 100)
ORDER BY [t1].[f4] ASC

When the SUM and GROUP BY are removed, it runs just fine. It happens from time to time on some databases, on other databases (with the same schema) the query runs without errors.

Microsoft SQL Server 2017 (RTM-CU10) (KB4342123) - 14.0.3037.1 (X64) Jul 27 2018 09:40:27 Copyright (C) 2017 Microsoft Corporation Developer Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 17134: )

Having to select statements by clicking and holding the mouse is just bad ergonomics. Request to have a keyboard shortcut which runs the current sql statement. The current sql statement is defined based on where the cursor is placed. For example, proposed shortcut runs only runs a single sql statement to the next semicolon. This shortcut would be an equivalent to Oracle's SQL developer's ctrl + enter shortcut. Note that this is probably the most used shortcut in SQL Developer and not having an equivalent on SQL Server Management Studio is disappointing. I know that not everyone ends their statements with semicolons but they can carry on manually selecting what they want to run and then pressing F5. But having a shortcut for running the current sql statement would make of a lot of SSMS users extremely happy.

SQLCMD docs state that Command Line Utilities 15 requires ODBC 17 (https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-2017). However, the actual Command Line Utilities 15 installer does not recognize a previously installed ODBC 17.

Installing ODBC 13 will allow the Command Line Utilities 15 installer to complete successfully, but we end up with errors later presumably due to the Command Line Utilities 15 actually requiring OBDC 17 functionality. Installing both versions 13 and 17 seems to get around this, but obviously requires installation of both packages.

Our server for testing this is a 64 bit Windows 2008 R2 Enterprise with SP1.

Repro steps:
- Install ODBC 17 from the downloads available here: https://www.microsoft.com/download/details.aspx?id=56567
- Install Command Line Utilities 15 from the links available here: https://docs.microsoft.com/en-us/sql/tools/sqlcmd-utility?view=sql-server-2017
- Observe error message during Command Line Utilities installation: Setup is missing an installation prerequisite: -Microsoft ODBC Driver 17 for SQL Server. To continue, install Microsoft ODBC Driver 17 for SQL Server and then run the setup operation again

- Exit the utils installation.
- Install ODBC 13.1 from the downloads available here: https://www.microsoft.com/en-us/download/details.aspx?id=53339
- Run the Command Line Utilities 15 installer again.
- Observe success.

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