Във вашия сценарий бих препоръчал изрично да зададете ниво на изолация на моментна снимка - това ще попречи на четенето да попречи на записите (вмъквания и актуализации) чрез предотвратяване на заключвания, но тези четения все още ще бъдат "добри" четения (т.е. не мръсни данни - не е същото като NOLOCK)
Обикновено откривам, че когато имам проблеми със заключването на моите заявки, контролирам ръчно приложеното заключване. напр. бих направил актуализации със заключвания на ниво ред, за да избегна заключването на ниво страница/таблица, и бих задал моите четения на readpast (приемам, че може да пропусна някои данни, в някои сценарии това може да е добре) връзка|редактиране|изтриване|флаг
РЕДАКТИРАНЕ-- Комбиниране на всички коментари в отговор
Като част от процеса на оптимизация sql сървърът избягва извършването на ангажирани четения на страница, за която знае, че не е променена, и автоматично се връща към по-слаба стратегия за заключване. Във вашия случай sql сървърът преминава от сериализиращо се четене към повтарящо се четене.
В:Благодаря за тази полезна информация относно отпадането на нивата на изолация. Можете ли да се сетите за някаква причина, поради която би използвал Serializable IsolationLevel на първо място, като се има предвид, че не използваме изрична транзакция за SELECT - нашето разбиране беше, че имплицитната транзакция ще използва ReadCommitted?
О:По подразбиране SQL Server ще използва Read Commmited, ако това е вашето ниво на изолация по подразбиране, НО ако не посочите допълнително стратегия за заключване във вашата заявка, вие всъщност казвате на sql сървъра „направете това, което смятате за най-добро, но моите предпочитания е Read Commited“. Тъй като SQL Server е свободен да избира, това го прави, за да оптимизира заявката. (Алгоритъмът за оптимизация в sql сървъра е много сложен и аз самият не го разбирам напълно). Неизричното изпълнение в рамките на транзакция не влияе, afaik, на нивото на изолация, което sql сървърът използва.
Въпрос:Едно последно нещо, изглежда ли разумно SQL Server да увеличи нивото на изолация (и вероятно броя на необходимите заключвания), за да оптимизира заявката? Също така се чудя дали повторното използване на обединена връзка би повлияло на това, ако тя наследи последното използвано ниво на изолация?
О:Sql сървърът ще направи това като част от процес, наречен „Ескалиране на заключване“. От http://support.microsoft.com/kb/323630 , цитирам:"Microsoft SQL Server динамично определя кога да извърши ескалация на заключване. Когато взема това решение, SQL Server взема предвид броя на заключванията, които се държат при конкретно сканиране, броя на заключванията, които се държат от цялата транзакция, и паметта, която се използва за заключвания в системата като цяло.Обикновено поведението по подразбиране на SQL Server води до ескалация на заключването, възникваща само в онези точки, където това би подобрило производителността или когато трябва да намалите прекомерната памет за заключване на системата до по-разумно ниво Въпреки това, някои дизайни на приложения или заявки могат да задействат ескалация на заключване в момент, когато това не е желателно, и ескалираното заключване на таблица може да блокира други потребители".
Въпреки че ескалацията на заключване не е точно същото като промяна на нивото на изолация, под което се изпълнява заявка, това ме изненадва, защото не бих очаквал sql сървърът да поеме повече заключвания от това, което позволява нивото на изолация по подразбиране.
