Всем привет!
Работаем в базе ЗУП много лет (1С 8.2, SQL).
Работников очень много, порядка 15 тысяч действующих. А в справочнике сотрудников их около 35 тысяч, в т.ч. давно уволенных.
При проведении расчетных документов в 2000 строк всё очень надолго зависает, никто ничего не может сделать. Справочник сотрудников тоже долго открывается. Если много пользователей работают с базой, то тоже тормоза то тут, то там. Вобщем пользователи жалуются, а начальство требует решения.
Сначала занимались этим сисадмины, сделали по железу всё что могли. Единственное говорят, что ключ сейчас 32-битный, надо мол ещё 64-битный сервер 1С попробовать. Но отчитались, что в остальном сделали всё что могли, мол железо тянет без проблем, сервер по процессору, очереди диска, оперативной памяти слабо загружен.
В итоге теперь требуют от программистов (от меня) максимально обрезать базу ЗУП, чтобы с нового года начать работу в новой базе. При этом должны быть перенесены все работающие сотрудники с их кадровой информацией, а также необходимые данные для расчета среднего.
В общем получается, что мне нужно как-бы начать работать в новой базе, но перенести туда все необходимые данные из прошлой, как например делался переход из ЗИК 7.7 на ЗУП.
Честно говоря, я не верю, что это поможет, ведь в документах как было по 2 тыщи строк, так и останется. Я не думаю, что прошлые данные в ЗУПе могут создавать сильные тормоза. Но теперь уже выхода нет, мне нужно обрезать базу, и либо доказать, что лучше не стало, либо в самом деле обрадоваться улучшению.

Прошу совета, может кто переходил на новую базу из 8.2 на 8.2 с целью избавится от прошлых периодов и ненужных сотрудников.
Кто чем пользовался, какой алгоритм.
Всех работников наверное нужно постараться перенести стандартной 1С-ной обработкой загрузки/выгрузки базы (со всеми сопутствующими справочниками). Ну а потом надо как-то все сальда подтянуть, и базу для среднего заработка.
Может есть уже механизмы, чтоб велосипед не изобретать?

свертка базы.

Можно обрезать базу. Почистить ненужных сотрудников.
Потом сделать распределенку, например по подразделениям. Некоторые расчетчики работают в своих базах, некоторые в сводной. Думаю, быстродействие увеличится.

хм я для приличия может все-таки сначала замеры не?частенько выдают поразительные результаты

(1) Для ЗУП вроде как не существует такого понятия
(2) "Можно обрезать базу. Почистить ненужных сотрудников" - вот у меня и вопрос, как лучше это сделать.
Насчет распределенки надо будет подумать, как вариант, если обрезка не поможет. Сразу не хотелось бы усложнять
(3) замеры чего? Что смогу, замеряю :)

(4)замеры производительности

Неоптимальные запросы поискать например..

(0) Может, пора переходить на 8.3? При переходе вроде бы свертка предусмотрена.

(0) "всё очень надолго зависает"
На сколько долго?

(7) Угу )) только самим конфу подправить чтобы все заработало более менее

(4) проверь работу жестких дисков, если нет то (5) и (6)

(7) На ЗУП 3.0 ? ага :)

(0) Я бы для начал посмотрел статистику - какие таблицы самые большие. И вообще - какой размер базы?

(11) И вообще, статистику на SQL.

http://infostart.ru/public/81235/
http://infostart.ru/public/94040/

1. Я бы админам сильно не верил бы? А вдруг база упирается в проце или в дисках? Реально видел счетчики производительности?
2. Хотелось бы услышать какое железо.
3. Ищи все что связано со сверткой ЗУПа.
4. Замер производительности сделай выше уже сказали.

В 1С всегда свертка дает прирост скорости. Особенно при большом периоде обрезки и при удалении большого количества данных. К примеру если удалите из 35 тысяц сотрудников хотя бы 30 % это уже прилично.

Насчет замеров производительности попробую.
А вот неоптимальные запросы наверное нет смысла искать, т.к. конфигурация ЗУП стандартная, потом обновлять намучаешься.

Дело ещё в том, что я удаленный программист, и доступ к базе у меня по вечерам, когда никто не работает. Живой картины не вижу. Но вот сейчас специально связался с пользователями, чтобы конкретнее узнать. Мне сейчас уже чуть по-другому сказали: оказывается вечером, когда никого нет в базе, расчетный документ с кол-вом строк (сотрудников) проводится минуты за три. А вот днем, когда в базе много пользователей, бывает даже дождаться не могут.

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

>> А вот неоптимальные запросы наверное нет смысла искать,

а чего тогда вообще связался с этим делом

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

блокировки

и зачем в один документ суют по 2 тысячи сотрудников?

>> В 1С всегда свертка дает прирост скорости.

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

(16) тут не свертка, а распределенка нужна

(20) Итоги это одно дело а таблица регистров расчета ведь имеет объемы. А объем влияет на запрос. Не думаю что со времен еще 1с 77 1С научился оптимально работать  данными по зарпалтным таблицам.

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

(14) "1. Я бы админам сильно не верил бы? А вдруг база упирается в проце или в дисках? Реально видел счетчики производительности?"

Это имеете ввиду виндовые счетчики? Нет, не видел, я чисто программист у них, причем удаленный, к системе нет доступа.

"2. Хотелось бы услышать какое железо."
По той же причине не знаю. Я даже не спрашивал, т.к. сисадмин там хороший, а я в железе всё-равно не силен.

(15) "В 1С всегда свертка дает прирост скорости"
Дак вот как лучше её сделать? Велосипед изобретать не хочется, может есть отработанные механизмы. Или каждый сам пишет кучу своих обработок?

(18) "а чего тогда вообще связался с этим делом"
Дак что ж мне теперь, увольняться. Начальство уверено, что обрезка базы поможет. Мне нужно это сделать и показать, помогло или нет.

(24)ищите кто возьмется.мож чему подучитесь

(24) Если база за большой срок времени более чем 5 лет я бы рекомендовал сделать свертку. Но оставить последние 2 года. Хотя бы год. Это чисто мой подход.
Но тем не менее нужно понять на сколько железо подводит. И еще понять объемы обрабатываемых данных за день, сколько расчетчиков работают? Как они взаимодействую?
Может действительно дело идет к РИБ?
По идее надо ехать вам туда и пару дней наблюдать и изучать что к чему. Или даже удаленно наблюдать на сервере что творится.

(18) "блокировки"
Видимо да. И обрезка тут похоже не спасет.

(19) "зачем в один документ суют по 2 тысячи сотрудников?"
Ну документ в стандарте 1С автоматически заполняется по подразделениям, так и делают, не вручную же вводить. Либо надо разбивать на более мелкие подразделения, тогда наверное шансов дождаться окончания блокировки будет больше.

(21) "тут не свертка, а распределенка нужна"
Кстати да, наверное только это и спасет при большом числе пользователей. А сложно реализовать?

(20),(22) Думаю вы оба правы. Обрезка сильно не поможет, но лучше стать должно :)

(23) А чё, после скульных обновлений быстрее заработало?

(25) Не подучусь. Тут всё удаленно. Если кто-то будет что-то делать, и я рядом не сижу, то не подучусь :)
Да и не возьмут никого, пока я им не докажу, что обрезка не помогает.

(27)угу.сейчас изучаю почему

"надолго зависает" - это все очень субъективно.
может они хотят чтобы документ на 2000 сотрудников рассчитывался за 3 минуты?

(26) "Если база за большой срок времени более чем 5 лет "
Да, больше 5 лет. Причем года 4 назад ещё было 4 разных базы, но не УРБД, поэтому мне приходилось программно склеивать отчетность. А в то время как раз форматы отчетности менялись постоянно (да и сейчас тоже), в итоге я запарился обработки делать и изучать новые форматы. И начальству тоже хотелось иметь одну базу. И я им сделал одну базу :)
Но через год появился один большой филиал, по размеру как все остальные базы, в итоге у нас постоянно растет число сотрудников, число пользователей, и имеем такие последствия...

"я бы рекомендовал сделать свертку"
Дак вот более детально не посоветуйте? Как её сделать?

Действительно, в клиент-серверном варианте свертка вряд ли поможет существенно увеличить быстродействие, но если пожелание свернуть базы связано не только с этим (но и к примеру с тем, что в справочнике тупо сложно найти нужного сотрудника), то можно рекомендовать свертку базы для ЗУП, ЗБУ http://o-systems.ru/software/soft/SvertkaHRM/

(27) Тебе намекают что ты слаб. И за такую работу рискованно браться. Можешь обломится. Пусть не заказчики найдут спеца а сам найди и подучись говорят.

(30) Я давно не занимался сверками ЗУПа. тем более я не россиянин. И наша типовая ЗУП отличается от вашей.

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

Я пользовался вот этой обработкой(не сочтите за рекламу). Правда она платная, но денег своих стоит:
http://infostart.ru/public/66073/
Отработала на отлично уже не на одной базе с большим количеством сотрудников.

(35) Да, я тоже использовал её использовал.

(35)(36) так если база тормозит то сразу свертка.рекламщики:))

(35), (36) http://o-systems.ru/software/soft/SvertkaHRM/ и http://infostart.ru/public/66073/ - это одна и та же обработка.

(38) судя по описанию одна и та же.
(37) почему сразу рекламщики? Обработка же не моя. Я просто ей пользовался и посоветовал ее для свертки базы. А тут уж захотят или нет

(38) не обратил внимания на ник. Спасибо за обработку.

(40) Спасибо за отзыв :)

(0) Я бы, наверное, завел новую базу и перетянул туда все, что нужно.
Занимался переносом данных из необновляющейся УПП в чистую ЗУП.
Перенес актуальные справочники.
Некоторые РН - такие как взаиморасчеты - перенес только остатки на дату начала ведения учета в новой базе.
Некоторые - такие как учет доходов для страховых взносов - все за 2 года.
Регистры расчета перенес все за 2 года и т.д.
Все это документом "Перенос данных".
Что нужно переносить и как(остатками или полностью) выяснял с помощью тестов. Типа "ага, средний не считается, значит про это забыл". Главное все затестить, ничего не забыть:)

(42) +1

(42) Вот, я именно так и хотел.
Ещё в первом посте написал: "мне нужно как-бы начать работать в новой базе, но перенести туда все необходимые данные из прошлой, как например делался переход из ЗИК 7.7 на ЗУП."

Значит попробую стандартной обработкой выгрузки/загрузки перенести сотрудников со всеми кадровыми даными, а потом остатки по регистрам уже видимо своими обработками, с помощью документа "Перенос данных"

(35) Обработка может и хорошая, но платная. Нет какой-нибудь демо-версии посмотреть, что она из себя представляет, чтобы понять, подойдет ли она.

(44) Добрый совет: не делай так.
Надо:
1) Выяснить размеры таблиц
2) Если выявятся очень здоровые, но которые можно почистить без вреда для базы - сделать это.
3) Убедиться, что на скорости работы это мало сказалось, почесать репу и начать искать узкие места.

Фантазии на тему "начать с чистого листа" к ЗУП не применимы.

(45) "1) Выяснить размеры таблиц"
Это в самом SQL смотреть, или как? И где-то есть описание соответствия таблиц SQL реальным объектам ЗУПа?

"Фантазии на тему "начать с чистого листа" к ЗУП не применимы."

Почему?
Ведь все когда-то начинают работать с ЗУП. Т.е. с нуля вводить в неё данные. Мне по идее нужно то же самое, только ввести автоматически все остатки начальные и перенести всех неуволенных сотрудников с кадровыми документами и физлицами.
Вот нашел:
http://курсы-по-1с.рф/salary-smart-courses/#perehodim-na-zup
Мне что-то такое и нужно, но опять же здесь описание, а как на самом деле окажется.

ПолучитьСтруктуруХраненияБазыДанных.
это лучше не трогай базу

(47) Спасибо, не знал такого метода.

(48) дальше полно готовых решений показывающих статистику по базе.мож звери порнух натаскали

Посмотрел размеры таблиц в SQL. С помощью скрипта вывел список таблиц с размером, и с помощью функции ПолучитьСтруктуруХраненияБазыДанных() получил соответствие объектам метаданных 1С, отсортировал по размеру:
1. Регистр расчета "РасчетСреднегоЗаработка"
   Данные - 1438 Мб, Индексы: 1247 Мб
2. Регистр расчета "ОсновныеНачисленияРаботниковОрганизаций"
   Данные - 617 Мб, Индексы: 533 Мб
3. Регистр накопления "СтраховыеВзносыИсчисленные"
   Данные - 563 Мб, Индексы: 83 Мб
4. Регистр сведений "Адресный классификатор"
   Данные - 530 Мб, Индексы: 2351 Мб

Ну и дальше всё так ровненько, размер помаленьку уменьшается. Т.е., как видим, из общей кучи сильно выделен только регистр среднего заработка
Но и его размер как-то меня не удивил. Не вижу ничего криминального.
Вся база 44 Гб.

Попросил пользователей отзвониться, когда будут жуткие тормоза. Это конечно вскоре случилось, ничего не проводилось и не расчитывалось. Я попросил админа сразу глянуть, что там на серваке.
Он пишет, что посмотрел нагрузку на железный sqlserver (на нем же сервер 1с). Он не нагружен. Очередь диска иногда подскакивает 0.01 в целом 0.00. Оперативки полно, 25% всего лишь занято. Прцессор 2-8% нагружен.
Оперативки 128 гигабайт, база 44 Гб, так что ms sql может всю базу себе в оперативку при желании положить.
Но в этот момент было много пользователей в программе.

(0)
Свертки базы на ЗУП нет уже давно ищу этот вариант.

1) Надо смотреть в сторону железа, оператив.память, диски, распределение баз и т.д.
2) Делать переход на ЗУП 3, при переходе много лишнего отвалится, но ЗУП 3 ещё сырая.

База пока на платформе 8.2
Переход на 1С 8.3 может улучшить ситуацию?

(53)в твоей ситуации получишь еще больше проблем с учетом

а обслуживание сделать не предлагали?

(51) На что именно жалуются пользователи? Какая кнопка сколько секунд отрабатывает? Обновление статистики на sql делали?

(55) Не понял, что значит обслуживание?
(56) В те периоды, когда всё висит, невозможно провести ни один документ. Ни начисление зарплаты, ни отпуск, ни командировку. Нажимают на кнопку "Ок" или "Провести", и сразу (или почти сразу) вылезает сообщение о транзакции. Такое бывает когда в базе много пользователей.
Я вот помню, раньше в параметрах базы была настройка, сколько секунд ждать транзакцию. Сейчас это наверное в параметрах базы SQL прописано, надо админа попросить посмотреть. Может есть смысл увеличить время ожидания?

"Обновление статистики на sql делали?" Вроде по умолчанию SQL-сервер сам это делает периодически, нет? Админ настройки не менял, но я уточню

(54) "получишь еще больше проблем с учетом"
Почему? Я ведь не на ЗУП 3.0 предложил перейти, а на другую платформу с прежней конфигурацией. Почему с учетом проблемы должны быть

Обнаружил сегодня, что строк в документах начисления зарплаты около 4 тысяч, а не 2 тысячи как расчетчики говорили. Это они имели ввиду 2 тысячи сотрудников, а строк то получается около 4 тысяч.
А документ начисления страховых взносов вообще один по организации делается, там 10 тысяч строк только во кладке взносов, 22 тысячи строк во вкладке основных начислений и т.д.
Это вообще нормально, документы с таким кол-вом строк держать? Как думаете? У 1С нет рекомендаций по максимальному кол-ву строк в документах, никто не в курсе?
Что-то мне кажется это вообще перебор, надо разбивать на несколько.

Можешь обратиться к Гилеву, там ребята реально ускоряют работу, переводят базу на управл. блокировки , настраивают скуль и только потом платишь деньги, если они выполнили твои требования.

(59)разбить же можно по подразделениям например.смысл пихать в один документ то?
для дока вводимого раз в месяц не вижу проблемы.
с рекомендациями у 1с туго
разделяй и властвуй)

(60)не только гилев сидит на этой теме

(58)просто смысла не вижу особого переводить на новую платформу.само по себе мало,что даст

(60) Управляемые блокировки - это насколько я знаю изменение конфигурации. А главный принцип работодателя - не уходить от стандартной конфигурации, чтобы не зависеть сильно от конкретного программиста и не поиметь проблем с обновлениями. (61) Вот и я про то. Я уж им говорил, но у них и так разбито по подразделениям :) Более глубокая разбивка им неудобна. Но я думал в документах максимум 2 тысячи строк, а вчера вот проверил и ужаснулся. Хотел узнать мнение, может ничего страшного и нет в таком кол-ве строк. Может я зря проблему раздуваю.

(64)страшное это не по части it.простите,а был ли мальчик?
по Зупу кстати меньше всего слышал о допилах в плане производительности

(65) В смысле "был ли мальчик" ?
ЗУП сильно зависит от стандартных обновлений, никто не хочет сам писать потом расчет среднего или отчетсноть в фонды или расчет НДФЛ... А глобальная оптимизация всё-таки подразумевает и корректировку кода, поэтому наверное редко и встречается в ЗУПе.

(66)есть ли проблема на самом деле?визги или действительно проблема присутствует

Не знаю как у вас в 8ке(с) но для 7.7 на диске ИТС была обработка по выгрузке в текстовый файл и(или) удаления записей журнала расчетов. Поскольку ЖР был один, а запросы и транзакции в основном грызли его, то делалось это каждый год. Удалялись записи ЖР старше двух лет.

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

(67) Проблема действительно есть, но может это не из-за большого кол-ва строк в документах, т.к. вечером документы начислений ЗП в 4 тысячи строк проводятся за 3 минуты. Причем при повторном перепровдении всего за 1 минуту, т.е. SQL оптимизирует выполнение повторных операций.
Ну как-бы всё связано, т.к. в любом случае, чем больше строк в документе, тем дольше он проводится. Соответственно при большом количестве пользователей больше вероятности попасть на блокировку.
Но думал, может само по себе большое кол-во строк как-то не рекомендуется 1С-ом, может там какие-то есть проблемы внутреннего характера, у платформы например, не знаю...

(69) >> Я вообще с трудом понимаю необходимость хранения в табличной части результатов расчета, если они и рассчитываются по модулю и хранятся в регистрах.

По-моему всё что расчитывается в документе, не расчитывается повторно при проведении.

обслуживание делал?

если типовая конфигурация, то остается только копать железо типа SSD ставить и SQL правильно настроить. (ну и не будет 4000 строк, считаться как 400 однозначно),  в с 8.3 в режиме совместимости не пробовал на тесте?

(26) <<
вот тут бы бухи тебя  убили. для расчета больничных необходимы сведения за два ПРЕДШЕСТВУЮЩИХ года. Т.е. на сейчас (октябрь) 2014 необходимы данные за 2013 и 2012.

(74) Я писал что 2 или 1 год. У нас в казахстане требуется 1 год для расчета средней ЗП для отпуском компенсаций и пр.

(70)полностью - это ограничение на размер номера строки документа, а объем данных который фиксируется в транзакции немного другое, ожидание захвата таблицы можно порыть, оно индивидуально для каждого пользователя было в 7.7.
В 8ке тоже что-то есть такое..

В SQL да и даже в файловой версии влиять объем старых данных на скорость транзакции не должно. Разве что отчеты и (конечно если есть, а в SQL нежелательно) запросы и расчеты при проведении.
При одновременной работе большого числа пользователей на большой базе и с большим объемом в документах и не попасть на блокировки:)
Распределить базу на работу индивидуально с синхронизацией ночью автоматически?

(75) текущий и два предшествующих. практически три года. из пяти.

ИМХО, ЗУП нужно (если вообще нужно) обрезать не по годам, а по сотрудникам.
Для работающих сотрудников - оставлять все данные по всем годам, а вот уволенных сотрудников - вообще убирать из текущей рабочей базы напрочь. (естественно, оставить архивную базу для "посмотреть").

вот у автора сейчас 15 тысяч действующих сотров, а всего 35 тыс. Получается, около 20 тысяч сотрудников и все их расчетные данные можно безболезненно выкинуть из текущей базы. Если говорить точнее, выкинуть  всех, кто уволился до текущего года. Уволенных в текущем году, разумеется, оставить в базе для отчетности..

(77)бред. есть понятие контрольные цифры. Итого называтеся. Если обрезать как вы предлагаете, то контрольные цифры поломаются и ни один бухгалтер не сможет отвечать за полноту данных в базе, поскольку из этих оставшихся 15тысяч каждого лично проверить невозможно после увольнения и удаления одного.

(77) а 1с это не вещь в себе а инструмент для полноты и достоверности..

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

зы: а для контроля прошлых лет, как я сказал выше - оставить архивную копию.

(72) Если речь об обслуживании SQL, то пока нет. Это только админ может. Я ему написал про обновление статистики, и ещё кое-чего. Он позже обещал посмотреть, а вчера поставил ключ на 64-бит, обновил SQL и версию платформы 8.2. Так же сервер 1С на 64-бит. Посмотрим что будет.

(73) "8.3 в режиме совместимости не пробовал на тесте?"
Админ пробовал, сразу после установки ключа 64 бит. Ему показалось тормознее, пока ограничился последней версией платформы 8.2

(76) Ну есть мысли организовать УРБД

(77) "Для работающих сотрудников - оставлять все данные по всем годам, а вот уволенных сотрудников - вообще убирать из текущей рабочей базы напрочь."
Вообще именно этого от меня и ждут. Я веду рабоыт в этом направлении, чтобы скорее всего убедить всех, что это не поможет. Ну а если вдруг поможет, то двигаться в этом направлении, чтоб в итоге всё перенести без косяков.

(78) да нет, не бред. С начала года будут свои отчеты, зачем сверять старые периоды. Они в старой базе будут. В этой базе учет как-бы с нового года начнется, только с сохранением среднего и кадровой информации по нужным сотрудникам.

(81)хм а что смотреть то?делать надо и на регулярной основе

(82) АДже если вы не разбираететсь в железе нам очень бы хотелось услышать о железе. И как реализована работа?
Сколько расчетщиц?

(0) Получается серверу ресурсов не хватает на такой размер базы? А как насчет 1С повелевает переходить на ЗУП 3.0?
Этот переход в ЗУП делается обновлением, но ЗУП3.0 потребует еще больше ресурсов! А вот в КА/УПП - только переносом остатков, документы не переносятся. Может также поступить? Понадобятся прошлые года - иди в архив...

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

А какие могут быть остатки по з/п части? Сделал "Выгрузка данных УПП 1.3 - УП 2.0", где их смотреть?