Дня доброго. Собственно, есть собратья?

(0) не тяни - собратья по (не)счастью ?)

я не ходил

(1) Да не. Я думал - с мистянами скооперироваться.

Почти сдал, 2 плюса, 1 полуплюс. Надеюсь, практикой добью.

(3) за что полуплюс сняли? спросил, когда 8.3.6 выйдет ?)

(4) В чем главное отличие read_commited от read_commited_snapshot с т.з. 1С.

Сегодня к проруби надо ходить

(5) детский вопрос

(7) угу, из серии "угадай, о чем я сейчас думаю"  )

(5) я только сегодня пытался это понять, нихрена не понял.

(0) Долго готовился?

(7) ага, детский вопрос...
Все у вас сразу детское.

ВР, а вы эксперт?

(5) потому что 8.2 и 8.3?

Ёжик ну что??? не томи

(9) При snapshot-e не накладывается совместная блокировка при операциях чтения, что повышает параллельность.

(14) что такое "совместная блокировка"?

(10) Плотно - последние 5 дней, до этого - эпизодически, когда сталкивался по работе.

(15) s - блокировка  на уровне СУБД. Позволяет другой транзакции установить такую же s юлокировку на тот же самый ресурс (строку таблицы, строку индекса, и.т.д.).

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

(18) Да, ты прав.

Надо предложить 1с внести годную терминологию. Совместная/исключительная - сервер 1С.
s,x,u, range - сервер субд.

(5) Отсутствие грязного чтения?

(20) нет.

(18) Тебя сегодня не было?

Я пытался вкурить что такое БлокироватьДляИзменения

Пока туго :)

Вообще тоже очень хочу сдать этот экзамен. Не знаю зачем, но хочу, гыгы

(22) Не, я только влажнофантазирую пока. Ну и почитываю.

(19) В сервере 1С нет совместной. Она разделяемая

Хочу взять купить курс по оптимизации на курсы-по-1с.рф

Кто-нибудь приобретал данный курс?

(21) Принимающие охренели. "Пропадание" грязного чтения - это изменение контракта платформы.
Отсутствие избыточных блокировок при чтении - приятный момент, но не настолько глобальный.

(23) Блокировать для изменения - заставляет сервер 1с ставить исключительную блокировку по периоду+измерениям, без разделителя итогов. Это помогает избежать взаимоблокировки при чтении остатков, после записи набора (ситуация - "Повышение уровня блокировки ресурса в рамках одной транзакции"). Все классически, я тоже долго не мог вкурить, зачем это:

Управляемые блокировки - боль. страдание. унижение.

(25) Да, пардон, не правильно назвал :-)

(27) шта?

(29) да вот, боль, страдание, унижение.

(31) Все понятно и логично, могу объяснить.

(5) я у них на собеседовании был несколько лет назад, там несколько вопросов  были примерно такие-же. То-же завалил их (по тому как по любому на память не помню) хотя тест прошел по общему числу баллов.

(32) отсутствуют источники информации, где это подробно написано, вот в чем проблема %)

Каша в голове - основная проблема этого экзамена

(33) короче готовится нужно, ибо все знать и помнить нельзя а там часть вопросов чисто на знания....

(30) Отсутствие грязного чтения - изменение поведения платформы. Знаю ряд людей, которые "завязались" на его наличие в очередных костылях по распараллеливанию через фоновые задания - и после переход на 8.3 пришлось переписывать код.

Отсутствие блокировки прочитанных данных сервером СУБД - такого вызвать не может.

Поэтому если говорить о том, что "в чем главное отличие read_commited от read_commited_snapshot с т.з. 1С" - изменение поведения главнее оптимизации (которая вполне может нивелирвоана повышением нагрузки на tempdb).

(37) Грязное чтение как отсутствовало, так и отсутствует. При чем здесь оно?

(37) Единственный момент - запросы with Nolock, которые выполняются для списков, а также запросов вне транзакций.

(38) Что значит отсутствовало? Возьмите 8.2 и проверьте - любой запрос, выполненный вне транзакции вернет вам изменения незафиксированных транзакций. В т.ч. запросы от всех отчетов и списков на формах.
Возьмите 8.3 и проверьте - не будет такого.

(40) см (39).

Да, вы правы, в режиме snapshot-а режим nolock (read uncommited) не ставится, только что проверил.

Тоесть, притензии к 1С в том, что убрали грязное чтение?

(42) Так незачем больше :)

(43) Претензии к тому, что это не "главное" изменение от включения read_commited_snapshot)

(44) Да я понял, s блокировки то нет. Чтение при этом вернет какое значение? Если транзакций на изменение - много. То, что было на момент начала первой транзакции?

(45) Сколько людей - столько и мнений.

read_commited_snapshot

- на момент транзакции производится "снимок" данных, данные в транзакции меняются, а другим транзакциям - на чтение - возвращаются данные "снимка"?

(46) Все, понял, глупый вопрос. u блокировка не позволит нескольким транзакциям менять данные.

(11) По моим книгам учились эксперты.

(5) я бы сформулировал главное отличие так: пишущие транзакции не блокируют читающих (этим и повышаем параллельность)

(50) думаю по Экспертам все-таки ведущим был Константин Рупасов

(37) если не ошибаюсь на итс писали что нельзя так делать ибо на версионниках не взлетит

+ 53 имеется ввиду ещё для 8.2

(47) ну тогда и нефиг в таком виде вопросы формулировать)
(51) вроде наоборот, читающие больше не блокируют пишущих. Если бы пишущие не блокировали читающих - а зачем тогда вообще блокировка?
(53) угумс. Правда те, про кого я писал - в гробу видели версионники - до перехода на 8.3 без совместимости)

Если бы пишущие не блокировали читающих - чтобы блокировать других пишущих.

(56) так енто и получается read_uncommitted - который был возможен в 8.2 на блокировочниках

(57) в read_uncommited есть грязное чтение, чтобы от него избавиться - ставим x-блокировку до конца транзакции

этим запрещаем читать грязные данные

чтобы дать читать, НО НЕ_грязные данные - вводим снапшоты

(58) может хватить s блокировки

(59) но тогда этой транзакции (а может и нескольким транзакциям) придется подождать, чтобы установить s-блокировку. а если пишущая транзакция длительная?

а так - сразу читаем из снапшота (хоть 100, хоть 1000 транзакций), и даже s-блокировки не нужны

(60) Да, так и есть.

(26) Я прослушал данный курс от курсы-по-1с.рф. Мне очень понравилось. Прочистило мозги существенно.

(62) Почему может тормозить консолидированная отчетность по разделенной базе (при использовании разделителя независимо и совместно)?

А чо, ндо было идти 19 числа ?

(64) А когда?

(63) Теоретически отбор будет не по индексу, так как первый элемент индекса - значение разделителя. А данные нужны по всем его вариантам.

(66) Все верно. Отбор по разделителю не установлен, индекс использован не будет. А почему?

интересно мнение kihor-a, прошедшего курс.

(63)(68) Если это вопрос ко мне, то я не отвечу. Если бы попытался , то это было бы "гадание на кофейной гуще". Надо провести анализ проблемы, например, при помощи SQL Profiler (или ЦУП или сервисов Гилева). Посмотреть на планы запросов и сделать выводы. Хотя не буду позиционировать себя как эксперта только на том основании, что прослушал классные курсы :)

Вопрос уровня (67) был задан мне сегодня. Причем в контексте, "иногда все же будет индексный поиск". Толи это была ловушка, толи мы друг друга не поняли, но я объяснил, почему поиска не будет, хотел даже физику процесса описать, но ответ зачелся.

(40) Я что-то запутался:
ЗУП использует конструкции:
- начало транзакции;
- процедение документа;
- считывание движений регистра расчета;
- отмена процедения;
- отмена транзакции;

В данном случае платформы 8.2 и 8.3 поведут себя по-разному?

+(71) или в данном случае запрос, выполненный внутри транзакции возвращает одно и тоже независимо от платформы? %(

Как в вас там 2й день прошел?

Херово

(72) Запрос вернет одно и тоже. А вот отчеты, которые формируются во время выполнения данной транзакции на 8.2 будут отображать изменения этой (еще не зафиксированной) транзакции.

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

(76) Да. Но почему?

(77) Почему условия в запросе не сочетаются с полями в индексе?

(77) Или что почему?)

(74) так, чую, экзамен еще сложнее...

Рассказывай?

(60) Это все конечно очень интересно... Только вот управлямые блокировки то никто не отменял. При записи объекта будет установлена исключительная управляемая блокировка. Другие транзакции смогут до ее завершения прочитать данные?

(78) Забей.
(80) Лениво.

(82) не порти карму, у тебя еще 2 дня

(83) карма фих с ней, главное чтобы статистику не испортил - с первого раза сдает не больше 2-х человек с группы :)

(84) соник вроде второй раз уже сдает

(84) а группа сколько человек?