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!

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

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.

We have FOR XML and FOR JSON. But it is not uncommon that people want to produce CSV files. This can be done with BCP, but it is not straightforward not the least if you want to add headers. And if you only want fields to be quoted when needed, BCP is not really what you are looking for. SSIS is also an alternative, but SSIS does not always fit in.
Thus, it would be handy if there was a an option like FOR CSV, with a syntax like:
FOR CSV [, HEADERS] [,DELIMITER(',')] [, QUOTE('"')]

HEADERS would mean that the column headers would be added on the first line in the CSV output. DELIMITER would specify the delimiter, with comma as the default, and QUOTE would specify which character used to quote the data. (Whehter QUOTE is actually needed, I don't know.)

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.

In SQL Server 2017, when using Availability Groups with Per-Database DTC Support enabled, you are unable to configure replication.

The error received is:
Msg 3933, Level 16, State 1
Cannot promote the transaction to a distributed transaction because there is an active save point in this transaction.

By design, per db DTC support does not allow save points. However, Replication system stored procedures make extensive use of save points. As a result, this creates a conflict where you cannot have a database in an AG with both Replication and per DB DTC support.

As a workaround, you must disable per DB DTC support in order to configure (or change configuration) of Replication.