Обрезать базу ЗУП, нужен совет
 

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

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

15 тыс сотров в одной базе!? да ещё небось одним доком зп начисляете, все сорок расчетчиков
ЗЫ это вам к доктору надо, ну или хотя бы к аналитеку, адынеснеги то тут при чем?

а по свертке ключевое слово - числящиеся сотрудники, работающие в периоде не канает
ЗЫ но я бы распределил базы, хотя бы по 1-ой на два расчетчика - учет труда и расчет зп вообще-то разные вещи

1-vah1 > Да, все в одной базе. Но начисления делаются не одним документом. Как я уже писал, в документе порядка 2 тысяч строк.
"адынеснеги то тут при чем" - дак не причем. Я и есть 1С-ник, сейчас надо что-то решать.

2-vah1 > "по свертке ключевое слово - числящиеся сотрудники, работающие в периоде не канает"
Не понял этого выражения

Про УРБД думаю дело советуете, возможно придем к этому, но сначала бы обрезание сделать да посмотреть что получится. С УРБД слишком глобально.

"учет труда и расчет зп вообще-то разные вещи" - это понятно, к чему это сказали?

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

(3) Ты на ваху не смотри, его речь как покойного Черномырдина надо в рамочку вставлять и объяснять что "так писАть не следует".

5-Секвестр > на меня-то фикли смотреть, дайте пиво в пятницу попить
ЗЫ да. и пристрелите потом, плиз что б не мучался

(3) Ну вот видишь? Нужны какие либо объяснения ещё? (см. (6) )

А вообще, на просторах инета есть "обрезаловка". Но те кто пользовался ею, пишут что "надо работать потом напильником".

Ну, можно потерпеть ещё полгодика, а потом перейти на 3.0. При переносе все уволенные и обрежутся, начисления останутся за 2 года.
Если попробовать делать начисления на 20-30 сотрудников в документе скорость обработки увеличивается?

9-GSokolov > "Если попробовать делать начисления на 20-30 сотрудников в документе скорость обработки увеличивается?"
Я уже предлагал разбить на более мелкие подразделения, чтобы в документе было хотя бы 500 сотрудников. Чтобы попробовать, будет ли быстрее. Но им удобно делать именно по большим подразделениям.

9-GSokolov > "Ну, можно потерпеть ещё полгодика, а потом перейти на 3.0."

Дак вроде уже можно. Правда не изучал тему, мне кажется ещё глюков много.

[quote=Antikvar;36995165]мне кажется ещё глюков много. [/quote]Потому и предложил подождать, хотя, основное уже есть. И тормоза в тройке не слабые, в начислении зарплаты при заполнении сразу и расчет производится, в т.ч. и страховых взносов.

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

охохонюшки...
ну а вы же исследовали, что на самом деле происходит, когда зависает, тормозит и т.п.? какие операции выполняются, где узкое место?

т.е. ни чтения, ни записи, ни работы с оперативной памятью, ни работы процессора во время тормозов не наблюдается?...
а компьютер вообще включен?
какие конкретно занчения каких показателей приводят сисадмины? чисто ради интереса.

И никто не спросил, а скуль-то какой? Поди мелкомягкий? Переползай на Оракл, там все будет быстрее и намного.

да дайте наконец уже человеку кряк на 1С:Сервер 64-х. Пусть памяти воткнет по максимуму и попробует.
:)

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

Тебе что мешает [b]всё [/b]перевести на 64 бит (всё - это значит всё, начиная с оси) и попробовать? Только необходимость докупить пару планок? Не, я ни в коем случае не предлагаю [em]работать [/em]на пиратских версиях, но [em]попробовать [/em]то можно и на пиратке/триале? Понравится - купишь, не понравится - будешь искать другие способы.

При таких объёмах клиент и сервер 64бита обязательны.

14-Пудель > Я удаленно работаю и подключение у меня к базе вечером, когда никто уже не работает :) Но со слов пользователей исследовал. Когда очень много пользователй в базе (а их одновременно около 50 штук сидит), то периоды массово

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

15-Зелёный тролль > Вот что мне сообщил сисадмин (это я его попросил посмотреть в тот момент, когда все юзеры висели):
"Посмотрел нагрузку на железный sqlserver, и на нем же сервер 1с. Он не нагружен. Очередь диска иногда подскакивает 0.01 в целом 0.00. Оперативки полно, 25% всего лишь занято. Процессор 2-8% нагружен. Думаю тут вопрос не в скорости железа сервера. Вообще ms sql может всю базу себе в оперативку при желании положить. Оперативки 128 гигабайт, а база всего 44 гб."

Вот такой ответ был.

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

[quote=Блондинка в шок;37106969]Тебе что мешает всё перевести на 64 бит[/quote]
Мне мешает то, что у меня доступ только к серверу 1С, я работаю удаленно, чисто как программист. Для таких дел там есть сисадмины.
Но проблему с ключом 64-бит всё-таки пропихнули :) Как раз вчера был первый день работы с новым 64-битным ключом. Наконец-то его купили и админ поставил. Ось на сервере тоже 64-разрядная.
Памяти как писал выше 128 Гб, куда уж больше в самом то деле.
Пока пользователи ничего не поняли, сильных тормозов не было, но и массовой работы не наблюдалось. Посмотрим дальше.

23-Antikvar > странно, что при ОЗУ в 128 Гб и базе в 44 Гб потребление памяти, по твоим словам - [em]25% всего лишь занято[/em]. т.е. всего лишь 32 Гб.
Немножко странно, я, конечно, с такими большими базами не работала (так.. максимум 6-8 Гб), у меня обычно SQL со временем стремился отожрать как можно больше, больше, чем вся база весит.
Может, админы [em]max server memory[/em] ограничили?

А приложение 1С какой разрядности?

[quote=Блондинка в шок;37108365]Может, админы max server memory ограничили?[/quote]
Не знаю, спасибо за предположение, уточню у админов. Но они говорят, что памяти всегда очень много свободной. Может в самом деле, вот бы хорошо :)

[quote=Секвестр;37108653]А приложение 1С какой разрядности?[/quote]
Не совсе понял?
Сервер 1С поставили тоже 64-разрядный. А сама платформа 8.2 последней версии, она одна на сайте, но платформа может вообще у пользователя стоять.

26-Antikvar > ага. спроси.
и еще. А сколько у тебя процессов rphost было (когда был 32-х 1С:Сервер)? на 50 то юзеров?
они то тоже должны были память отжирать.. каждый..
а то больно много у тебя памяти свободной.. :)

зы: на 1С:64-х, как говорят, достаточно всего два rphost, один из них - резервный.

[quote=Antikvar;37109055] сама платформа 8.2 последней версии,[/quote]
Открой прайс лист 1С [url]http://www.1c.ru/rus/partners/pricelst.jsp[/url]
И посмотри позиции
4601546081315
4601546081322
Как ты думаешь, это одно и тоже?

29-Секвестр >[em]Как ты думаешь, это одно и тоже?[/em]
хм.. для юзера (клиента), который подключается к серверу 1С и у которого рядовая рабочая станция WIN ХР с двумя ГБ на борту, абсолютно одно и тоже.

В свете (27) [em]но платформа может вообще у пользователя стоять[/em] - я так понимаю, работают не в терминале?

Разница, я так понимаю, будет заметна если либо всех в терминал загнать, либо (если не терминал, а просто клиент-сервер) каждому юзеру-клиенту на рабочей станции поставить WIN 64-х и ОЗУ больше 4-х ГБ?

[quote=Блондинка в шок;37109209]А сколько у тебя процессов rphost было (когда был 32-х 1С:Сервер)? на 50 то юзеров?[/quote]
Было распараллелено на 6 процессов. Сейчас на 64-битном админ сделал 4 процесса

29-Секвестр > "Блондинка в шок" правильно описала в (30). Я честно говоря даже не знаю как пользователи подключаются. Я то удаленно из другого города, поэтому через удаленный доступ захожу на сервер, там мне доступен только мой каталог, на этом сервере запускаю 1С, но это обычный запуск, не в терминале.
Есть и удаленные пользователи, однозначно. Но расчетчики точно все местные и у них наверное своя 1С установлена у каждого, но не уточнял.

Вот и я думаю, какой сервер 1С развёрнут в клиент-серверном варианте? Сама ОС может быть и 64х разрядной, а вот какой сервак 1С развёрнут?

Хмммм...
Дано: 15000 активных записей на 50 операторов. Т.е., по 300 записей в одну морду. На 22 рабочих дня, заметим. По 8 часов в каждом. Для ввода изменений в кадровой информации, внутренних перемещений, и прочей инфы, нужной для финишного (в конце месяца) расчета.
Т.о., на обработку каждого сотрудника (в среднем) приходится ((22-2)*8*60)/300=32 минуты (2 дня выкинуты на финишный расчет).
Полчаса.
А потом финишный расчет (итого начислено, итого удержано, итого выплачено, НДФЛ, пФР...) - всего 6 документов, в каждом из которых помещается 2000 рыл.
Информация по каждому тщательнейшим образом отшлифована в течении получаса.

Вы правда полагаете, что проблема в "железе"?

VZ, да я знаю что "разруха в головах", но ведь это Россия...

[quote=Секвестр;37110802]Сама ОС может быть и 64х разрядной, а вот какой сервак 1С развёрнут?[/quote]
Дак я написал в (27), что сервер 1С 64-разрядный

[quote=Секвестр;37111143]Вы правда полагаете, что проблема в "железе"?[/quote]
Лично я полагаю, что не в нем. Просто здесь меня спрашивают конкретику, я отвечаю.

имхо, тут был самый хороший совет - подождите немного, потом переходите на 3.0

Антиквар - это несерьёзный подход к исследованию проблемы. На основании устного опроса, даже без анализа журнала регистрации, Вы собираетесь принимать решение!
Вы даже не знаете, какая проблема является основной - транзакционные блокировки или медленное выполнение запросов.
Фу таким быть :)

38-Пудель > Ну устный опрос в реальном времени дал понять, что выскакивают именно сообщения о транзакциях и ничего не проводится из-за этого и не расчитывается. Т.е. не медленно выполняется запрос, а вообще не выполняется. Практически сразу вылетает сообщение о транзакции.
А чем поможет журнал регистрации? Там хрен чего найдешь, одну минуту можно минутами листать :)