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

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

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

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

IT-новости

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

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

подробнее

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

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

подробнее

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

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

подробнее

Ускоряем Ms SQL Server


Юлия Шабунио

Что может быть хуже сервера, который неизвестно из-за чего стал работать слишком медленно? Только сервер, который работает слишком медленно по хорошо известной и неустраняемой причине! Чтобы реже сталкиваться с такой ситуацией, рассмотрим методы борьбы с причинами замедления работы Microsoft SQL Server.

В первой части статьи (см. «Почему MS SQL медленно работает? Ищем причины» – №5, 2005 г.) мы рассмотрели способы локализации проблемы, кроме одного – как обнаруживать дедлоки? Для начала изучим оставшийся вопрос и после этого перейдем непосредственно к сегодняшней теме.

Поиск дедлоков

Дедлоки (Deadlocks) являются довольно специфичной проблемой. С одной стороны, они не затрагивают весь сервер, а происходят на некоторых конкретных процессах. С другой стороны, если жертвы (снятые процессы) дедлока очевидны просто по журналу ошибок, то вот с каким процессом и на каких объектах случилось пересечение – непонятно. К счастью, в SQL Profiles входит великолепная возможность отследить всю цепочку блокировок с помощью LocksLock:Deadlock Chain. Чтобы эффективно ею воспользоваться, можно построить следующий шаблон:

1. События:

n  LocksLock:Deadlock Chain

n  LocksLock:Deadlock

n  Security AuditAudit Login

n  Security AuditAudit Logout

n  SessionExistingConnection

Первые два события нам нужны, чтобы отследить собственно блокировки. Остальные понадобятся для идентификации проблемного процесса. Дело в том, что событие «Deadlock Chain» ничего не пишет об участвующих процессах, кроме SPID. Поэтому нам потребуется регистрировать еще и входы и выходы из системы. По SPID и времени дедлока мы сможем точно найти записи о его подключении и отключении, а значит – найдём описание процесса. Событие «ExistingConnection» даст нам список тех процессов, на вход которых в систему мы уже опоздали.


Предыдущая страницаОглавлениеСледующая страница
 
[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