Create Index recommendations
Create Index recommendations appear when the SQL Database service detects a missing index that if created, can benefit your databases workload (non-clustered indexes only).
Drop Index recommendations
Drop Index recommendations appear when the SQL Database service detects duplicate indexes (currently in preview and applies to duplicate indexes only).
As it’s currently only non-clustered and duplicate indexes, the potential issues when a change is made should be limited. It is indicated that the recommendation will be reverted if performance was negatively impacted by the change. What is not currently clear, is what period of time or amount of monitoring will need to pass before a negative performance change will be reverted.
Looking at the current features being added to SQL Server 2017 there doesn’t appear to be anything to get overly excited about.
There’s nothing that makes you think ‘wow we need to upgrade NOW!’
From my perspective the following should be easy no brainers to get DBAs motivated to upgrade:
1. The ability to undo transactions from the transaction log / log backups. Geez, this has been around for years by 3rd parties. Surely it’s time to include it, just like native compressed backups (best thing since sliced bread).
2. Writable snapshots. We’ve got read-only snapshots so we are half way there. Just think of the space savings and ability to quickly use cloning for test/dev environments.
3. The ability to easily fail-over/fail-back log shipped databases. Man, how long has the good old reliable log shipping been around for and that dreaded pain of a fail-over test.
4. The ability to attach a database to an older version. Surely there could be a simple flag that says, hey I may need to go back to version x so don’t give me funky xyz features. Exporting/importing data is just painful.
5. Wow, wouldn’t it be great if we had a fail-over solution that didn’t drop the client connection.
Re-reading the above, possibly Microsoft just needs to focus on making existing features great, before pursuing new features and leaving DBAs again feeling that they could have been better i.e. JSON.
Interestingly, “In CTP 2.1, we moved Reporting Services installation from the SQL Server installer to a separate installer. This is a packaging change, not a product change; access to SQL Server Reporting Services is still included with your SQL Server license. The new installation process keeps our packages lean and enables customers to deploy and update Reporting Services with zero impact on your SQL Server deployments and databases.”
As mentioned previously, installs look to be getting a lot more complicated. I can see why Microsoft would do this for easier internal development, but for an end-user experience, this is likely not ideal.
Before you apply a SQL Server patch, it is usually advised to perform the below:
1. Ensure that there are no user/application connections to the SQL Server instance.
2. Ensure there are no SQL agents jobs, that may kick off just before you start the patching.
3. If this is a Virtual Machine (VM), take a snapshot otherwise, ensure you at least have a backup of the system databases.
4. Restart the server. (This one step surprisingly usually resolves 99% of patch application issues and it’s not mentioned by Microsoft). Just stopping/starting the services or reviewing/resolving the locked files warning is typically less effective than a server restart.
Of course if you are using Database Mirroring, AlwaysOn, Clustering … there are other considerations, and typically these involve patching the Passive instance to minimize the outage window. Once again, restarting the passive server prior to patching usually ensures the smoothest patching experience.
Once patching is completed, it is also recommended to again restart the server. This final restart can give you the confidence that future restart issues are likely not related to this patch.
On none HA instances, these server restarts will likely increase the outage window, but it could prove to be the difference between a successful or failed patching attempt.
You don’t often hear about references to Facets in SSMS, however this is a great feature which allows you to review and even change the SQL Server configuration.
I often use it to quickly access the good old SQL Server 2005 Surface Area Configuration settings.
Take a look at the various Facets available and you may be pleasantly surprised.
Below shows an upgrade from CTP 1.4 to CTP 2.0 on Ubuntu.
1. Run: sudo apt-get update
2. Run: sudo apt-get install mssql-server
and that’s it.
As the Linux offering progresses we’ll hopefully better understand any caveats regarding upgrades.
Further info on Linux installs, upgrades and uninstalls can be found here.