It is important for this type of analysis using the "logical read" unit that meaningful and representative test data is used. This means data that is comparable to productive data in terms of both the number of data rows and the distribution of values at the column levels discussed above. These test data sets can either be generated synthetically or be an anonymized version of the productive data. A tried and tested recommendation is that the productive data sets are automatically analyzed in terms of quantity, structure, use and distribution of values and that this metadata is then used to generate synthetic test data.
Another challenge in evaluating T-SQL statements is the selection of parameters to be used for the tests. As already described, the query execution plans generated depend, among other things, on how many rows of data the SQL Server estimates to be processed.
Therefore, it is armenia telegram screening crucial that developers consider which groups of parameters should be tested later during the development of T-SQL statements. These parameter groups, in turn, form one of the foundations for automated performance tests.
Automated tests
The aim of the performance tests is not to measure speed or time, but whether the quality or structure of the query execution plans generated remains stable after each iteration of the agile development process. The aim is to check whether extensions to the database schema - be it new columns in tables or queries, or new indexes - generate different execution plans than in the previous iterations. The good news is that Microsoft has been planning such an approach for some time and SQL Server can provide the required information.
A frequently expressed argument against this approach is that no development team could document or even compare query execution plans in detail. However, this is not necessary. Since version 2008, Microsoft SQL Server has generated a hash value for each T-SQL statement and each query execution plan, the so-called QueryHash and QueryPlanHash . This is usually shown in hexadecimal notation and can be easily accessed via corresponding data management views.