Разработка динамических сайтов
SEO услуги
Управление контекстной рекламой

Вход на хостинг

Имя пользователя:*

Пароль пользователя:*

IT-новости

20.04.2016 iPhone 2017 года поместят в водонепроницаемый корпус из стекла

Линейка iPhone в новом году серьезно поменяется. В этом уверен аналитический исследователь Мин Чи Ку......

подробнее

30.07.2015 Ищем уникальный контент для сайта

Ищем уникальный контент для сайта Без уникального контента Ваш сайт обречен на то, что его страницы......

подробнее

11.05.2015 Распространённые ошибки разработчиков сайтов

Не секрет, что в сети Интернет насчитывается миллионы сайтов, и каждый день появляются тысячси новых......

подробнее

Повысить или понизить уровень гранулярности блокировок на каком-либо индексе или таблице можно с помощью процедуры sp_indexoption.

И всё-таки выработка стратегии блокировок – задача скорее разработчика, чем администратора. Для программиста огромным подспорьем будет уже картина блокировок, полученная вами на этапе поиска проблемы.

Снимаем дедлоки

Как уже говорилось, дедлоки, завязанные на несколько объектов, снимаются довольно легко. Ведь такой дедлок означает, что к одним и тем же объектам базы данных разные транзакции обращаются в разном порядке. Достаточно установить один какой-то порядок и проследить, чтобы он везде выполнялся. Если вы решили везде обращаться сначала к А, и только потом к Б, а необходимо сделать наоборот, то надо просто установить сначала блокировку на А, а потом можно работать с Б и снова с А в своё удовольствие. Например, это можно сделать так:

declare @l tinyint select @l = 1 from A with (tablockx) where 1 = 2

Менее понятно, что делать с дедлоками в рамках одной таблицы. Часто они решаются четким указанием режима уровня блокировок (pagelock, например). Тогда сервер не будет повышать эту блокировку до табличного уровня без крайней необходимости. Возможно, что придётся поработать с индексами и планами запросов, приводящих к взаимной блокировке. Ну и наконец, самый надёжный способ борьбы с дедлоками на уровне таблицы – это подсказка with (tablock) или изменение режима блокировок с помощью sp_indexoption. Конечно, производительность в этой ситуации может пострадать (а может и нет, зависит от конкретной БД). Но зато дедлоков не будет наверняка.

Проблемы на аппаратном уровне

Как уже говорилось, решать эту проблему должен не администратор базы данных. Тут на его долю остаётся только контроль и забота о файлах базы данных – наблюдение за фрагментацией таблиц с помощью dbcc showcontig, регулярная проверка физической целостности и перестройка индексов. Но даже эти простые процедуры могут дать очень большой прирост производительности, особенно если вы давно этим не занимались.

Заключение

Описанные сценарии не претендуют на полноту или оптимальность, но они работают, и я использую их ежедневно. Надеюсь, что набор приёмов и рекомендаций пригодится вам при решении проблем производительности MS SQL Server.


Предыдущая страницаОглавлениеСледующая страница
 
[001] [002] [003] [004] [005] [006] [007] [008] [009] [010] [011] [012] [013] [014] [015] [016] [017] [018] [019] [020]
[021] [022] [023] [024] [025] [026] [027] [028] [029] [030] [031] [032] [033] [034] [035] [036] [037] [038] [039] [040]
[041] [042] [043] [044] [045] [046] [047] [048] [049] [050] [051] [052] [053] [054] [055] [056] [057] [058] [059] [060]
[061] [062] [063] [064] [065] [066] [067] [068] [069] [070] [071] [072] [073] [074] [075] [076] [077] [078] [079] [080]
[081] [082] [083] [084] [085] [086] [087] [088] [089] [090] [091] [092] [093] [094] [095] [096] [097] [098] [099] [100]
[101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120]
[121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140]
[141] [142] [143] [144] [145] [146] [147] [148]

+7 (831) 413-63-27
ООО Дельта-Технология ©2007 - 2016 год
Нижний Новгород, ул. Дальняя, 17А.
Rambler's Top100