Тут соображения два: 1. Практика переноса темпдб в рам диск распространена, данные от этого ещё никто не терял. Админы в кровавом Энтерпрайзе переносят на ссд тоже без особых опасений 2. Скорее всего вы лечите проблему методом научного тыка, поможет или не поможет перенос ещё большой вопрос.

Как устроена на очень верхнем уровне запись и чтение в буферный кеш новых строк рассказывает Богачев на курсе Эксперта

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

Хм. Да, ты прав, жт пухнет

По любым вопросам скуля нужно смотреть видосы от сертифицированных русскоязычных спецов ms. Все около 1с ные специалисты - это какой-то детский сад. Поверхностная что кривая информация.

может быть лучше англ сразу смотреть?) мне лично даже сложно порой найти ту или иную настройку в переведенном на русский ms )

А сейчас о каком из двух снепшотов идет речь?

RAM диск и ССД как по мне - это две разные вещи. И я ничего не лечу, я мимо проходил и увидел что на заборе слово написано :)

вещи разные, но вероятность выключения света одинаковая )

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

О любом по идее.
В контексте 1с давайте забывать об не rc снепшоте вообще. Ms кажется сама давно считает устаревшим видом изоляции.

такое себе высказывание ) как разница потеряете вы 10 строк или 100 или 10000? задача же не потерять, а не потерять минимум, верно?

вроде нет. если потеря от некорректно настроенной инфраструктуры неизбежна, то лучше потерять минимум, а не все.

А почему увеличивается лог в случая большого количества отмененных транзакций? По идее же в ЖТ пишутся все транзакции - какая разница отменилась она в конце или нет.

Потому что откат часто происходит в в режиме "истерика".
Пачиму у меня не проводится? И сто раз повторяем действие. Вдруг поможет... А только потом, когда возвращается сознание, видим сообщение с проблемой )

Хз если честно... Но всегда там где много ролбэков - много ЦП на скуле, времени отката и много гб на диске.
Если попробовать что-то изменять в студии в транзакции минут 5, а потом нажать отмену, то откат будет раза в два дольше чем сама модификация.

Место в ЖТ - это может быть просто его расширение из-за необходимости сначала что-то записать/восстановить, а только потом пометить старые данные как ненужные. Так, предположение

ясно. спасибо.

Всем привет. Помогите пожалуйста решить задачу. Надо во всей самописной конфигурации найти все обращения через 2 и более точек. Пример документ.товар.код или документ.товар.категория.код. Если такие обращения есть в запросе то их следует исключить. С помощью каких инструментов это можно сделать? Кроме выгрузки конфигурации в файлы и поиском по всем файлам ничего в голову не приходит.

Ну в файлы выгрузить в любом случае придется. А далее уже парсить.
Альтернативный вариант - настроить ТЖ на все запросы где есть поле Version, но туда попадут и "законные" объектные чтения (при открытии всех форм например), ну и с одинарной точкой тоже.

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

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