Parameter sniffing или защо понякога заявките в SSMS са бързи, а в приложението не

SQL Server има оптимизация, която се нарича parameter sniffing, която запазва и кешира query планове при извикване и компилиране на stored procedure за конкретни параметри.

По подразбиране .NET приложенията използват малко по-различни параметри отколкото SSMS например:

За приложения:

за SSMS:

Съответно в някои случаи заявките се оптимизират грешно за .NET приложения (с arithabort off), но в SSMS работят наред, тъй като няма натрупана статистика, за да се оптимизират.

Бързо решение на проблема (временно!) е да се изпълни

Това изчиства кеша на сторнатите процедури и започва наново да се съхраняват. Тези статистики се пазят в паметта, поради което рестарт на сървъра също върши работа.

Има и други опции, като да се добавят различни опции към заявката като use recompile, option recompile, optimize for unknown и т.н.

По-глобално решение би било използването на Trace flag 4136 или

По-долу има подробна информация за този (и други случаи) и различни решения на проблема:

http://www.sommarskog.se/query-plan-mysteries.html

Сериозен недостатък при .NET приложения и EF е генерирането на  dynamic SQL, който използва sp_executesql и лесно може да възникне такъв проблем.

Конфигуриране на TDE за SQL Server

SQL скрипт за създаване на TDE (Transparent Data Encryption) и осигуряване на “Encrypt the data at rest”.

Информацията в базата данни е криптирана и ако някой намери backup на базата няма да може да я използва.

Друга положителна страна е, че приложението,което достъпва данните няма нужда се променя и продължава да работи както и досега.

Криптирането на базата е онлайн, прозрачно и може да се проследи до къде е стигнало чрез изпълнение на query към dmv таблица.

Важно е да се запазят ключовете и сертификата, за да може базата данни да се прочете, ако се премести на друг сървър!