Azure Data Studio provides a lot of Extensibility options and its Extension Model is actually my favorite feature of this tool. There is no need of huge software installs and in the process getting tools/functionalities which you don’t require. The base install of Azure Data Studio is very small & lightweight. With Azure Data Studio you can customize your environment with the tooling you need. Extensions provide an easy way to add more functionality to the installation.
As a developer, have you ever written your own customized string splitting function in your code? Do you still have comma separated values stored inside your database columns? If the answer to any of these questions in YES, then you will be happy to know that with SQL Server 2016, we have finally got a built-in function which takes care of this overhead.
Diagnosing performance issues with long running queries is challenging. Generally for troubleshooting a query performance, we look at the execution plan generated by the T-SQL query and then identify the expensive operators. However for a long running query, where we have to stop the T-SQL execution prior to its completion, there is no execution plan generated. Live Query Statistics in SQL Server 2016 comes to our rescue in such scenarios.
There might be scenarios where you might need to alter the masked column after the initial implementation. Wondering if it is possible? Yes it is. You can alter/drop an existing masked column as per your requirement by just writing a simple T-SQL query.
With the release of SSMS v17.3, Microsoft has introduced the all new XEvent Profiler in the Object Explorer right inside SQL Server Management Studio which displays a live viewer of Extended Events. XEvent Profiler is built on top of the Extended Events technology and is an honest attempt by Microsoft to move the developers still using SQL Profiler to adopt the new XEvent Profiler.
Once you have implemented Dynamic Data Masking across multiple tables in your database to protect your sensitive data, how do you track all the masked columns in one place?
When a column is wrapped around in a function call in the WHERE clause, the query processing speed can be extremely low because of the potential resultant scan operation. We should avoid using functions on columns in predicate. Especially on large tables, it can create a noticeable performance overhead by preventing the Query Optimizer to use available indexes.
We bumped into a Performance issue last week for one of our web application in Production. After doing some research and looking at Logic Monitor reports for web servers and database servers, we figured out that the Deadlocks and Lock Timeouts in the Database have increased considerably.
Your application is bound to grow over a period of time. Sometimes it is critical to test your changes with a bigger workload than your current table size to identify any performance bottlenecks, well ahead of time. Leveraging automated tools to generate a workload for you to test your application makes your lives much easier.