Имя: Пароль:
1C
1С v8
Плюсы и минусы использования nolock в MS SQL 2008
,
0 szhukov
 
17.11.11
12:17
Собственно интересует сабж - опыт использования.
Плюсы вообщем-то понятны, не блокирующее чтение со всеми вытекающими.
Понятно что в результате таких действий читаются грязные данные
и можно пролететь в случае каких-то важных изменений в момент чтения данных.
Я выполняю запросы (чтение и запись) из 1С к внешней базе MS SQL через ADO.
Во внешнем источнике перегружены сильно две основные таблицы (такая структура бд - изменить нельзя),
в них ведется постоянная запись и чтение (в том числе и из 1С) из-за чего периодически
возникают блокировки (блокировки каждый день 1 раз как минимум)
Решили все выборки переделать с nolock (в запросах из 1С и во внешней базе).
Собственно вопрос: не выльется это в какую-то проблему с еще большими тормозами, есть тут подводные камни?
1 rs_trade
 
17.11.11
12:18
(0) а разве не очевидно? будешь получать не закоммиченные записи в 1С.
2 rs_trade
 
17.11.11
12:20
(0) первым делом попробовать навести красоту в индексах во внешней базе. там все красиво?
3 Господин ПЖ
 
17.11.11
12:21
>Во внешнем источнике перегружены сильно две основные таблицы (такая структура бд - изменить нельзя),
в них ведется постоянная запись и чтение (в том числе и из 1С) из-за чего периодически

точить некогда, пилить надо
4 szhukov
 
17.11.11
12:21
(1) Это пока не пугает. Почти все, что я получаю - я же и пишу, в пределах одного сеанса. Но каждый сеанс пишет свои данные (грубо говоря каждый работает со своим документом)
5 szhukov
 
17.11.11
12:22
(2) Ну если верить DBA базы - то да.
6 szhukov
 
17.11.11
12:24
(3) Над БД MS SQL существует своя логика (клиент), который имеет определенные ограничения и требования к структуре БД.
7 szhukov
 
17.11.11
12:26
Я спросил к тому, что поиск по интернету выдал неоднозначный ответ, кто-то получил прирост, а кто-то еще большие тормоза по непонятным причинам. Может не все так просто...
8 Рыжий Лис
 
17.11.11
12:31
(7) Однозначный ответ даст анализ планов выполнения типичных запросов
9 rs_trade
 
17.11.11
12:34
(7) нет здесь однозначного ответа. кто знает чего там у вас понаделано. лучше сначала посмотреть насколько эффективно используются индексы, нет ли избыточных индексов. провести ревизию запросов. поискать тормозные места и попробовать оптимизировать.
10 rs_trade
 
17.11.11
12:36
может быть как то можно разнести время работы программ с таблицей. что бы не пересекались.
11 apokrit
 
17.11.11
12:41
(0) Можно вместо ожидания получить:
"Could not continue scan with NOLOCK due to data movement"
Если при чтении сервер наступит на записи которые прямо сейчас модифицируются

(7) Про тормоза не понятно, на первый взгляд выглядит как полный бред.
12 szhukov
 
17.11.11
13:00
(10) работаю над этим, но это немного разгрузит базу со стороны 1С только.
(11) Это хуже. Я думал при использовании nolock по боку, что там и куда пишется...
13 Кириллка
 
17.11.11
13:23
(12)такое сообщение можно получить, при поврежденных данных - лечится DBCC CHECKDB. Либо если скуль старый, это сообщение было признано ошибко и был выпущен фикс еше на 2000-м скуле.

Тормоза при отсутствии NOLOCK это объективная реальность.

Можно внешнюю базу перевести в режим RCSI и тогда не нужно будет никаких NOLOCK и тормозов не будет.
14 szhukov
 
17.11.11
14:40
(13) RCSI - не подходит, при этом режиме будет каша в базе.
NOLOCK позволяет более тонкий подход (т.е. только там где надо)
Интереснее еще в этом плане выглядит режим версионности, но боюсь наши сервера тупо по ресурсам не потянут :)
15 Кириллка
 
17.11.11
14:56
(14) "при этом режиме будет каша в базе" - а почему?
16 szhukov
 
17.11.11
16:38
(15) Не везде нужен NOLOCK по умолчанию. Гарантированные данные тоже востребованы.
17 rs_trade
 
17.11.11
17:07
(16) а что у вас там за блокировки такие? вообще блокировки это нормальное явление. и возникают они гораздо чаще чем один раз в день ))