Есть конфа РИБ, порядка 50 узлов. Выгрузка идет долго и блокируется работа пользователей. Загрузка маленькая - от узлов мало данных.

Если поставить в SQL сервере: TRANSACTION ISOLATION LEVEL SNAPSHOT, это поможет в ситуации с РИБ, можно будет делать выгрузки параллельно?

http://msdn.microsoft.com/ru-ru/library/ms173763.aspx

казалось бы а причем тут скуль?

нет

1с не умеет вешать управляемые блокировки на таблицу изменений, блокируется вся таблица

(3) ну вот тут она и не будет блокироваться на уровне SNAPSHOT

кстати, как это сделать, подскажите (поменять уровень изоляции).
простите, что спрашиваю.

(5) это управляемые блокировки, т.е. (3).

И не факт что из-за этого вообще

ну сделай 1 база - 7 баз - 49 баз...

(5) не простим. Читай документацию.

1 - 8 - 64...

можно еще 1 где работают - 1 которая обменивается - 50 elfktyys[

просто не надо сразу во все точки выгружать, последовательно...

(10) что-что 50 делают??

(12) то самое

есть вариант сделать главную ПБ, которая обменивается с ЦБ, которая в свою очередь обменивания с остальными ПБ

тогда можно обмен ГлавнаяПБ и ЦБ делать как угодно

у нас успешно вариант снежинки работает

(16) ты смотрел возникающие блокировки при обмене в скуле? как то занимались этим вопросом, удалось выгружать в разные узлы паралельно, блокировки не было на самом деле на стороне скуля, была виновата плохая статистика

+ экспериментально удалось. в рабочем варианте не пытались

(17) каким образом вы это делали параллельно? таблица изменений разве не блокируется?

(17) я не смотрел, у меня все и так работает.

(19) в том то и дело что нет, на наших экспериментах

(19) так там же 1 апдейт 0 на номер сообщения же всего

Поглядите как нить блокировки при обменах, картина может не соответствовать догмам

(6) это не управляемые блокировки, это в СКЛ настраивается (11) расскажи как. Параллельно не получается.
(14) где взять еще один сервер для дополнительной базы (80 Гб, кстати объем)?
(23) еще бы научиться это делать. ;-)

я к тому, что раньше у нас стоял IBM DB2, как то с блокировками особых проблем не было (версионность), на скуле все сперва умерло, пока не перешли на версионность...

(0) Дорабатывайте и регламентируйте обмены. из предложенного в (0) точно ничего хорошего не выйдет.

(24) купить

Короче у нас было как - у сервера скуля есть настроечка, онлайн обновление статистики. Если статистика устарела - сначала он обновляет её, а только потом делает запрос. И именно это обновление статистики вызывало блокироку, а не мифическое, как я сейчас понимаю "1с не умеет".
Так же не забываем что тупо в коде самой 1с выгрузка заключена в НачатьТранзакцию() и ЗафиксироватьТранзакцию(), что не прибавляет ей паралельности

(27) давай без приколов.
(28) и как эту настроечку снести?

(27) тем более ничего не мешает развернуть на этом же серваке. ибо нагрузка в этой базе будет только на чтение и вставку в таблицы

(28) имхо фигню несешь

(30) лишняя база - лишние проблемы с целостностью...

(29) а если ты её снесёшь - то могут появится тормоза в других местах... или чаще надо обновлять статистику регламентно в скуле самом.

(31) Это не есть истина, посмтри сам. Глубоко не копали тоже

(32) а у тебя как я вижу есть еще куча вариантов?

(34) ну версионность - это как самое простое.
еще есть другие. да.

(33) Рупасов на курсе по технологическим вопросам прямо говорил, что таблица изменений узкое место именно в плане блокировки этой таблицы. тут нет речи о параллельности. и обновление статистики здесь не причем

я ставлю на то, что автор свои какие-то действия в обработке выгрузки делает.

поставь точку останова при обмене с узлом. и попробуй параллельно запустить еще один обмен

(38) я делаю несколько выгрузок параллельно (они идут минут 5), получается облом.

конкретно блокирует метод ЗаписатьИзменения

а ПриОтправкеДанныхПодчиненному ничего не происходит?

может быть ты с регистрации ставишь/снимаешь...

ЭлементовВТранзакции сколько указано?

(36) да, место узкое. но причины блокировок он озвучил? при определённых условиях я думаю возможна паралельность, поэкспериментирую как нить

(40) блокировать должен метод ВыбратьИзменения (там происходит апдейт, проставка номеров сообщений)

(44) выполни (38) и избавься от всех сомнений

(43) 200

(47) поставь 1

(45) возмжно, нюансво не помню.
(48) озверел? он у меня до утра пахать будет. хотя счас проверю.

(46) я сказал при определённых условиях, которые надо ещё создать сначала

при установке не 0 есть нюанс - движения документов лучше не полагать на автоматический механизм и вообще не регистрировать на обмен, а добавлять в файл выгрузки руками при выгрузке документа. а то может получиться, что док выгрузился, часть движений выгрузилась, а док распровели в этот момент - и часть отсутствующих движений будет в сообщении присутствовать.

при следующем обмене выровняется, но все равно...

(51) меня это не беспокоит, да, такое бывает, но я чищу движения. можно еще и сверять, но не сверяю

(50) с отключением статистики? или про какие условия ты еще говоришь?

ну и (41) еще важно

(41) нет. там нет мощных проверок и/или модификаций.
Поставил эксперимент - выгрузку на две точки.
поставил единички в порцию

(53) непосредственно Перед обменом - обновить статистику. И данные в таблицах должны быть определённые, т.е. не надо забывать о механизме эскалации блокировок, скуль может решить что легче заблокировать всю таблицу, чем отдельные записи.
Да хз, я повторюсь, не уверен. Общие слова про "узкое место" - надо проверять лучше, попробую воссоздать ситуацию на днях

я так думаю, что таки дело в том, что проверки и/или модификации таки есть

гм. проверю чуть позже, пока идут обмены. надо насухую экспереминтировать.

Поставил 1 в размер транзакции. Выгрузка идет параллельно.
Сделал 4 задания, в каждом по 15 узлов, полет нормальный.
Всем спасибо. ;-)
На загрузку тоже поставил 1, теперь все идет параллельно.
Крутота.

(59) спасибо не булькает

(60) могу закинуть СМ. ;-)

(61) а зачем они нужны? пока потратил пару сотен на промоблок для http://infostart.ru/public/173394/  больше пока применения не вижу

(62) ну я бы тебе пиво проставил, а с конторы не знаю, как стрясти бабла...