Здравствуйте!
1С 8.3 БП 3.0
платформа достаточна свежая (несколько месяцев назад обновлялась, но уже не самая последняя), конфигурация самая свежая.
В последние год-два база сильно разрослась (109Гб, раньше была 4-5Гб).
И вот, теперь когда бухи запускают перепроведение документов (не знаю точно как у них это называется, а у нас в УТ это называется - Проведение по партиям, цель - правильная себестоимость),
то проводить уже другие работы невозможно, идет взаимоблокировка транзакций, вылезает "Неопределенная ошибка".
Железо среднее, но не совсем плохое, нагрузка на сервер (40% процессора).
Я по своей УТ 10.3 знаю, что нельзя одновременно делать проведение по партиям и работать (например создавать и проводить другие документы).
Но бухи говорят что БП раньше им позволяла все делать параллельно - и перепроведение документв, и текущая работа.

Вопрос - либо помогите мне найти аргументы для бухов, что перепроводить можно только по ночам, но никак не в рабочее время.
Либо, пожалуйста, дайте совет как исправить ситуацию, чтобы снова можно было бухам работать одновременно с перепроведением документов.

Бухи готовы надавить на начальство и вложиться в железо, но по попыту УТ 10.3 я знаю что такого железа не существует на свете, чтобы перепроводилось по партиям и можно было нормально при этом работать.

P.S.: я сам больше по УТ, а бухгалтерию совсем не знаю

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

(0) >109Гб, раньше была 4-5Гб

За сколько лет данные в базе? И за сколько было "раньше"?

109 гб это реально много для БП. База надеюсь не файловая? А если sql - то размер это не включая размер лога транзакций, случайно? Если с логом - то это на быстродействие не влияет вообще никак. Да и если база забита например вложенными файлами, это тоже практически не влияет.

(4) конечно скульная (единственное, в отличие от УТ база и 1С-сервер расположены на одном железе, а в УТ я разнес по разным серверам). Диски ССД-шные. Для ТемпДБ отдельный диск. Размер лога мизерный, всего около 100Мб, даже одного Гига нет. Основной объем - сама база.

(3) просмотрел документы - с декабря 2012 года!

раньше не было маркировки и было ЕНВД, было все проще

(6) На вторую часть ответь тоже.

И показывай топ таблиц.

(8) как ответить на вопрос "за сколько было раньше?" ?
если два года назад, то на два года меньше, соответственно )))) База ведется с момента создания фирмы и с тех пор не обрезалась.
В базу добавилось за эти годы несколько организаций. Изначально в одной базе было одно ООО и один ИП, года 4-5 назад добавились два ИП, с начала прошлого года еще 8 ИП, и с начала этого года еще два ИП.

(8) топ таблиц - надо обработку найти

(9) За сколько времени база выросла с 5 до 100 Гб? За последний год, два, три? Проблемы начались тогда же, или позже?

Релиз платформы - озвучить
Релиз конфигурации - озвучить

Режим использования базы - сервер или файл. Вполне допускаю, что это "раньше" и работают до сих пор в файловом варианте, но при этом сидят на "сервере" по РДП, а потому и работают допустим 2 или 3 буха в своей файловой бухе.

Раньше все было нормально ... это когда примерно выполнялось обновление конфигурации? И после перехода с 2.0 на 3.0 который был когда?
А может при этом переходе ничего от мусора не почистили?

(10) Я имел в виду топ из SSMS. Но расшифровку тоже неплохо бы. Обработка есть в ИР.

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

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

(14) уж в скуле то я разбираюсь, умею посмотреть размер базы

(13)
_AccRg560    1    21375.273437    13793.132812    7582.140625
_AccRgED596    1    24867.320312    9085.367187    15781.953125
_AccumRgT10268    1    13277.625000    8795.421875    4482.203125
_AccRgAT2593    1    2927.218750    2876.617187    50.601562
_Document227_VT6328    1    3191.726562    2554.007812    637.718750
_AccumRg10248    1    2344.281250    1793.234375    551.046875
_AccRgAT3594    1    1055.140625    1035.781250    19.359375
_Document190_VT4894    1    1144.492187    984.070312    160.421875
_Document216_VT5794    1    918.898437    838.156250    80.742187
_InfoRg24446    1    812.476562    598.125000    214.351562
_AccumRgT10317    1    541.007812    531.757812    9.250000
_DocumentJournal7700    1    456.414062    312.687500    143.726562
_AccumRg10307    1    361.578125    304.062500    57.515625
_Document188_VT4740    1    282.578125    250.398437    32.179687
_InfoRg24192    1    1213.734375    236.132812    977.601562
_Document214_VT5711    1    230.257812    229.234375    1.023437
_Document227    1    308.398437    204.843750    103.554687
_Document189_VT4839    1    204.070312    203.140625    0.929687
_Document214    1    290.390625    201.460937    88.929687
_DocumentJournal23086    1    243.273437    195.273437    48.000000

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

На какие-то вопросы из (12) будут ответы?

Номер релиза конфы сейчас и когда было обновление релиза конфы, то с какого на какой релиз прыгали? Там было критичное в обслуживании обновление.

1С:Предприятие 8.3 (8.3.18.1363)
Бухгалтерия предприятия, редакция 3.0 (3.0.106.60)

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

Если обновлялись на 18-ом релизе платформы
То это и озанчает, что при этом обовлении не сделали или не доделалось в платформе до конца реструктуризация данных и пересчет итогов,

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

Причем, глючность проявляется именно на базах с бухгалтерской подсистемой. Допустим, на УТ 10.3 или там на ЗУП не будет заметно.

(12) конечно скульная (единственное, в отличие от УТ база и 1С-сервер расположены на одном железе, а в УТ я разнес по разным серверам). Диски ССД-шные. Для ТемпДБ отдельный диск. Размер лога мизерный, всего около 100Мб, даже одного Гига нет. Основной объем - сама база.

Что значит "от мусора не почистили?" По-моему это пустая фраза.
Переход с 2.0 на 3.0 проводил очень опытный и профессиональный специалист по 1С. когда это было - не помню. Думаю что он сдела все правильно.
Обычные обновления делает наш сисадмин, просто обновляет и все. Что-то чистить не в его компетенции, чтобы потом бухи верещали что мы полезную информацию удалили.

(18) // Но бухи говорят что БП раньше им позволяла все делать параллельно - и перепроведение документв, и текущая работа.

А вот этот прикол, кстати говоря, не имеет прямой связи с тем, что база распухла.

Я бы на всякий случай заглянул в свойства базы на сервере, т.е. в 1С кластере - вдруг кто-то нечаянно поставил блокировку регламентных в свойствах базы...

(21) А это то при чем? Во-первых галочка блокировки регламентных не стоит, это я отвечаю на 100%. Во-вторых бухи ДНЕМ сами запускают перепроведение. Для примера, у меня в УТ 10.3 это действительно делается регламентным заданием с полуночи до 6 утра. А бухи хотят делать это не только ночью, но и днем. Сперва своими действиями испортят валовку за год назад, потом перепроводят ее несколько дней (за ночь успевает около 4 месяцев перепровестись)

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

(16) Вроде ничего необычного.

(23) Сделай ТИИ на копии, потом выгрузку/загрузку. Сравни размер.

(20) да мне пофиг, если честно, кто там опытный, а кто неопытный. Откуда бы я это знал?!

Я спрашиваю только в целях диагностики и высказывания предположений.
Ты же задаешь вопросы "что могло произойти?" - вот я и спрашиваю "а что вообще происходило?" - не имею никаких мотивов кого-то обижать или усомниться в профессиональности.

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

После обновления платформы нужно обязательно вытащить CF поставщика и накатить его заново на базу - конфигуратор из-за этого прокрутит очень жестко таблицы.

Если нет возможности поднять на 20-ый... Ну может посмотреть/проверить, а что будет при выгрузке базы в ДТ - это только в целях диагностики. А вдруг она сожмется.
И если выгрузится, то загрузить в файловый режим "для посмотреть"

(22) иногда случается такое, что 100% никто ничего не устанавливал, но внезапно смотришь, а там какое-то чудо и галочка стоит.

УРИБ есть? Проверь планы обменов. у меня такое было давно когда сильно выросла таблица изменений (была почка с которой уже 100 лет обменов никто не делал), и при перепроведении тоже вылазили транзакции. Как только таблицу почистил так сразу все нормализовалась (ну до тех пор пока не распухла опять табличка из за пере проведения).

Самописгых документов нет? Давно были косяки с комиссией, когда перпроводка по комиссии также "вешала" блокировку на всю базу. Аналогично был косяк с ИП, когда была перепроводка по ИП блокировала другие организации

(28) он бы все это увидел сам, смотри он запостил в (16) - там не заметно ни таблы для РИБ, ни самописных каких-то

(26) спасибо

(28) самописных доков нет

(26) я это все попробую в выходные. у нас сегодня рабочий день - торговля все-таки

Если идет постоянное перепроведение, то таблицы будут раздуваться, т.к. запись движений это delete+insert, а не update. Возможно есть смысл чаще перестраивать индексы, чтобы они не раздувались сверх меры.

Насчет блокировок — посмотри, включено ли разделение итогов регистров.

(33) В смысле в объеме таблиц будет присутствовать приличный процент свободного места.

(26) Раньше мы делали выгрузку в ДТ и восстановление в файловую систему, когда к нам приходили аудиторы, и отдавали аудиторам файловую базу. При этом размер базы сжимался раз в 10 кажется.
А потом он превысил какой-то критический размер, после которого базу нельзя развернуть в файловом варианте, так что уже полгода мы ДТ-шников не делали. А для аудиторов делаем скульную копию.

(33) ок, попробую, спасибо

(33) а скульное перестроение индексов отличается от 1С-ного? На SQL-сервере каждую ночь проходит. А если в 1С зайти в конфигуратор, выбрать "тестированеи и исправление" и там поставить галочку "пересчитать индексы" - это тоже самое или другое? Если другое, то оно не делается

(35) это плохо. Получается, что примерно тогда, когда она перестала выгружаться в Дт, вот в то время и начались проблемы.

Лечить надо базу. База на типовой конфе БП 3 с таким относительно маленькими объемами данных не должна быть такой большой в скуле - это во-первых.
И должна позволять выгрузить себя в ДТ практически всегда.

Мое мнение, повторяюсь :-) - считаю, что причина в глюках платформы.

(37) Точно не знаю, но думаю отличается тем, что в скуле более эффективно и можно делать выборочно.

Если в скуле делаете, то OK. Каждую ночь имхо чересчур в обычном режиме работы.
Обновление статистики после этого в плане обслуживания есть? Именно после перестройки индексов.

(37) проверьте даты документов. Возможно кто-то ввел по ошибке даты 1го года. И тогда сформировались итоги за 2000 лет.

(40) По ошибке будет несколько строк, которые никак не дадут 100 Гб.