Для 1С не подходят решения с помощью увеличения длины первичного ключа кластерного индекса. Есть какие либо другие решения?

Шта?

(0) а зачем понадобилось длину PK увеличивать?

(0) У вас 40 потоков пишут в одну таблицу? Приветствую, коллега по несчастью:) Битва за последнюю страницу идет страшная :)
Кластерный индекс там - модифицированный ГУИД, как вы собрались его увеличивать? Если, конечно, я правильно догадался, что запись выполняется в документ или справочник.

(3) основная конкуренция за партии товаров+продажи себестоимость ((( есть большой механизм расчета закупок который постоянно юзает эти регистры на чтение+ 4-5 чеков проводится в секунду+ну и основной документооборот (

(3) пишут причем где то 10-15... а вот читают еще от 40 до 100 в это время (

(3) не собираюсь... думаю что еще можно сделать... когда снижали avg stall темпдб с 4 дисков и 8 файлов вынесли на 1 файл и 1 диск. Думаю сегодня попробовать 2 диска/2 файла по идее это должно уменьшить ожидание буфера

(2) увеличение длины ключа приводить к увеличению количества страниц индекса и снижает конкуренцию за последние страницы

почему ты постоянно упоминаешь чтение?

сделай явное назначение УИДа через конструктор уида для первой ссылки индекса, чтобы увеличить разброс

(8) вообще то уровень изоляции SERIALIZABLE конкурирует со вставкой... если много читают, INSERT будет ждать своей очереди.

(10) ты только о чтениях в транзакции?

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

ну и изменения последние после которых началась проблема на эти мысли подвигли

(10) мне так кажется, здесь ты говоришь про блокировки типа lock, не latch

WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    PAGELATCH_EX    Buffer Latch    1102.5    0.3    59.9    5.4    74112    14.9
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    PAGELATCH_SH    Buffer Latch    883.1    0.2    55.2    6.3    65660    13.4
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    SOS_SCHEDULER_YIELD    CPU    195.6    0.1    195.2    99.8    345406    0.6
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    CXPACKET    Parallelism    32.9    0.0    4.5    13.7    5680    5.8
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_RS_U    Lock    32.1    0.0    0.0    0.0    15    2143.1
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    ASYNC_NETWORK_IO    Network IO    17.9    0.0    15.6    87.2    27351    0.7
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_IX    Lock    12.9    0.0    0.0    0.0    4    3215.5
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    PAGEIOLATCH_SH    Buffer IO    6.9    0.0    0.0    0.0    1073    6.4

тут и чтение и эксклюзивный доступ к странице. Я пытаюсь в голове укрупнить до уровня кода и запросов которые могут создать такую ситуацию

WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_RS_U    Lock    32.1    0.0    0.0    0.0    15    2143.1
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_IX    Lock    12.9    0.0    0.0    0.0    4    3215.5

конкуренция за страницы уменьшила ожидания блокировок lock, они должны быть выше

так ты не ответил - чтения ты говоришь о чтениях в транзакции?

с блокировками lock?

для начала надо понять какую прикладную проблему мы решаем

(18) основная проблема чтения вне транзакции

(20) есть километровые запросы которые с начала прошлой недели стали выполняться в 5 раз дольше. Сначала я залез в эти запросы и там оказалось что данные в некоторых подзапросах читались прямо с физических таблиц, отборы накладывая через WHERE. читаем 30М строк, возвращаем 400к, в вложенном запросе. Вынес во временные, через виртуальную таблицу. Началась эта свистопляска под большой нагрузкой

была проблема 1, после доработок возникла проблема 2
но мы же своими руками создали вторую проблему
может быть запросы оптимизировать более корректно?

Я один тут нихера не понимаю?

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

Ну и о каких блокировках речь при грязном чтении (чтении вне транзакции) ?

(10) А у вас автоматические блокировки 1С, если речь про SERIALIZABLE  ?

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

(25) да... в связи с некоторыми "решениями" в следствии которых когда то отказались от измения Склад в регистре Партии на складах, даже смысла не вижу на управляемые переходить... все равно эскалация будет на всю таблицу партий по номенклатуре

(26) У меня такая же херота была.
Нормально типовой запрос работал, по расчету взаиморасчетов в УТ11.2, потом в один прекрасный день встал просто колом.
План запроса показывал crossjoin таблицы движений по взаиморасчетам с таблицей остатков, хотя так быть не должно.
Переписал на 2 временные таблицы.

(27) Что за конфа то?

(26) недавно накинули несколько нахлебников. Интернет магазин и статистику собирают по продажам. Больше ничего крупного не было. +увеличилось количество категорийных менеджеров которые работают с этим БП

(28) ну вот я переписал.. план стал красивый. И тут здрасте... а мы буфер ждем теперь

(24) "Но кластер регистра - он случаен"
кластерный индекс основной таблицы регистра накопления: [ОРРХ | ОРНР1 +] Период + Регистратор + НомерСтроки

(31) Волшебный mdop равен 1 ?

(29) УТ10.2 для украины. Но от типовой там нифига. Ее превратили в подобие Комплексной, впилив туда план счетов с регистром бухгалтерии

(33) да

(32) Да, пардон, про таблицу движений чет забыл.

(33) ночью переключаем, когда параллельность минимальная для регламентов. Утром обратно

попробую увеличить количество темпдб до 2 и в понедельник под нагрузкой сделаю замеры

пока больше ничего в голову не приходит как это лечить (

Кстати. Вопрос. Когда индексируем временную таблицу, индекс с нуля создается или субд его с кластерного собирает?

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

(32) Нужно просто больше строк в документе!

(41) покажи на примере что будет больше последующего

(40) я не понял вопрос

(43) Это было предположение. Он не будет больше?

(45) ну, фраза не выглядит как предположение)
насколько я знаю такие уиды не последовательные

(44) когда индексируем временную таблицу в запросе, как субд создает непосредственный индекс?

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

(47) create index
А какие еще способы есть то?

(48) это тоже предположение? или есть пример?

(47) посмотри в профайлере

(48) "непоследовптельные- да. Но почти  наверняка увеличивающиеся"
сам себе противоречишь

(52) нет, посмотри на смысл групп символов в уид

(53) фраза противоречивая - неполедовательные, но увеличивающиеся

(54) числа 1 2 4 8 16 - непоследовательные. Увеличивающиеся.

(55) ладно, согласен

(53) покажи мне эти группы символов, созданные конструктором уид

(57) сам погугли, там есть сессионная часть

(57) https://www.vdgb.ru/kompaniya/tehpodderzhka-1s/faq/kak-po-guid-opredelit-vremya-i-datu-sozdaniya-ssylki/

(59) ну и где там конструктор?

(60) у тебя яндекс да?)

а нельзя к индексу добавить поле рэндом?
все равно уже ломаем по самоп небалуйся

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

(4) Есть причины, по которым эти все считается в онлайне?

(0) Ээээээ, версионник (даже ваш сиквел последних версий умеет прикидываться версионником) не спасёт отца русской демократии?

(64) думаю точную себестоимость ет никаких причин считать онлайн... думаю в период минимальной нагрузки реально устроить пересчёт за последние сутки... но если так пригорает - считать онлайн приближенную себестоимость

(62) нахрена рэндом искать - время разбазаривать если есть № коннекта/№ сеанса и т.п.

+ (65) таки да, версионник + разделение итогов

(68) судя по (22) у него проблема в чтении, не в записи

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

(70) получить рандом если оно не на уровне материнки - трата времени, если есть особые требования, например гарантированная уникальность 1Е9 значений за какой-то период времени - это может быть довольно затратно.

(71) все имеет свою цену, особенно если говорить про миллиарды
вопрос применимости к конкретному кейсу

Какой версионник? У автора - автомат, а это seriasable на регистрах и repeatable read на обьектных.
Ему хотя бы в управляемые вылезти.

(73) ну тогда перевод на управляемые - первый шаг.... и скорее всего этого и хватит. Версионник на авт - зло!

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

(75) перевод авт. на упр. нетривиальная задача?

(76) да

(76) Переведи на управляемые расчёт себестоимости в типовой УПП...

заблокировал все по организации и готово

(75) Нормальный совет. У ТС проблемы с транзакционным чтением. Версионник решит эту проблему на корню. Т.е. банальный переход на упр-блокировки.

(21) Чтение вне транзакции на авто-транзакциях в блокировочнике - грязное. Его ничего не может блокировать, кроме изменения схемы.

Тут просто некоторая путаница упр/авто и блокировочник/версионник. На современном сиквеле включение упр-блокировок автоматически заюзывает режим версионника в mssql.
Но что происходит в смешанном режиме, когда параллельно используются и автоматические и управляемые транзакции - для меня вопрос. Если кто в курсе - расскажите.

(78) ну свою нетленку перевёл... никаких особых проблем... так давно что уже забыл когда было. Зачем расчёт себестоимости переводить если есть ЕРП? Потом, разве нельзя сделать частичный перевод(режим управления блокировкой = Упр+авт и понемногу переводить)?

(82) Если для конфигурации выбрано значение «Автоматический» или «Управляемый», то режим, установленный для объектов, будет игнорироваться. Если у конфигурации выбран смешанный режим
«Автоматический и управляемый», то будет использоваться тот режим, который указан для объекта метаданных, открывшего транзакцию.

(80) там нетранзакционное чтение, он явно это написал