перерасчет зарплатного журнала

[Corleone]

Цитата:

Сообщение от Greggy

Как мы не бились ничего путнего не смогли сделать ....

Значит не судьба.

[konrad_imported]

Тестовый сервер - обычная рабочая станция, 4 гига мозгов, двухядерный процессор 3000 Мгц, два идишных диска по 100Гб
У меня механизм такой.
Из внешних источников в журнал расчета ЗП закачиваются "внешние" проводки ряда начислений-удержаний. От 4 до 16 проводок (строк) по сотруднику. Далее эапускается расчет без очистки журнала. При расчете создается еще порядка 5-15 строк (расчетных элементов) на сотрудника, в ряде расчетных элементов которых используются закачанные ранее внешние проводки.
Далее при выверке могут правиться ( и правятся) суммы на каких-либо расчетных элементах (кроме закачанных из внешних источников). Далее в штатном режиме происходит перерасчет исправленного сотрудника без очистки. Но в данном тесте штатный "поштучный" перерасчет я не использовал. На паре десятков пиплов поменял суммы и запустил групповой перерасчет по всему журналу без очистки. (правда, и без пересортировки).

[Галина]

Возник вопрос правда не совсем тему.
Объем зарплатной базы с января этого года составлял 6 гб. Прочитав тему - убрала с Зарпл.ЖурналСтроки галки с MainSiftIndex. Решила убрать эти же галки и с Зарпл.КнигиОперации. Объем базы составил 1.4 гб.
Я в шоке. 4 гб - составляли ключи?
И теперь собственно вопрос. Чем мне это грозит? В принципе flow-field поля в Зарплате не используются-как в основном Навижине. Поэтому мне кажется ничем не грозит.

[konrad_imported]

Цитата:

Сообщение от Галина

Возник вопрос правда не совсем тему.
Объем зарплатной базы с января этого года составлял 6 гб. Прочитав тему - убрала с Зарпл.ЖурналСтроки галки с MainSiftIndex. Решила убрать эти же галки и с Зарпл.КнигиОперации. Объем базы составил 1.4 гб.
Я в шоке. 4 гб - составляли ключи?
И теперь собственно вопрос. Чем мне это грозит? В принципе flow-field поля в Зарплате не используются-как в основном Навижине. Поэтому мне кажется ничем не грозит.

Все нормально. Ключи столько и жрут - тем более не оптимизированые сифты. Поснимайте еще MaintainSQLIndex для ключей, которые в редко используемых отчетах применяются. Еще пол-гига, а то и более освободится.
А вот в таб 14821 со всех ключей MainSiftIndex поснимать - не совсем хорошо. Там есть несколько ключей (не помню, пара или около того), суммовые индексы которых используются в расчете ЗП. Расчет сильно замедлиться может.

[Галина]

Цитата:

Сообщение от konrad

Все нормально. Ключи столько и жрут - тем более не оптимизированые сифты. Поснимайте еще MaintainSQLIndex для ключей, которые в редко используемых отчетах применяются. Еще пол-гига, а то и более освободится.
А вот в таб 14821 со всех ключей MainSiftIndex поснимать - не совсем хорошо. Там есть несколько ключей (не помню, пара или около того), суммовые индексы которых используются в расчете ЗП. Расчет сильно замедлиться может.

Хм-а если снять только с 14820 MainSiftIndex и MainSqlIndex-то толку нету-объем освободился совсем на чуть-чуть.
Я сняла с 14821-и у меня сразу 4 гб освободилось.
Проверяла расчет по минутам-работает одинаково.