База SQL больше 1,7Гб, в том числе журнал расчетов Зарплата больше 500 000 строк, Kladr+SocrBase+Street почти 1,2 миллиона строк. Еще и CJ4891 (не нашла в словаре, что за ЖР) размером за 400 000 строк.
На сегодня получила 2 совета - терминал и DBF (но это было до уточнения размеров базы), либо RAM-диск.
Есть ли еще идеи или выбирать одну из этих?

обрезать и перевести на ДБФ

а чо, таблицы КЛАДРа как-то влияют на быстродействие ЗиК?...

(2) Упомянуты для оценки размера базы.

(1) Существует ли более или менее стандартная обработка обрезки ЗиК? Для меня это задача непростая.

А вот не надо было все регионы грузить

- 1С++ загрузить при старте (ускоряет создание многочисленных СЗ и ТЗ и тп)
- разогнать процессор допобольше гигагерц
- само собой работать в терминале, не по сети в дбф

или монопольно

"Kladr+SocrBase+Street" вычистить нафиг, загрузить только нужный (нужные)регион.
"журнал расчетов Зарплата" - есть такая штука Метла ЖР - вычистить лишние (ненужные) записи.
пустые (ненужные) записи в ЖР возникают, когда в документ "Начисление зарплаты" заполняют всем без разбора (в том числе и давно уволенными). Аналогично в журнале по страховым взносам.

1.7 Гб всего на SQL (включая полный Кладр) - это ни о чем.
если выгрузить в dbf - сколько будет весить самый большой dbf-ник ?

какой мутак пустил тупую сукульницу зикерить?

"журнал расчетов Зарплата больше 500 000 строк"
детский размер.
счас открыл CJ447.dbf - 237000 записей,   весит всего 31 Мб.

(9) +100 скуль и ЗиК - вещи несовместимые.
а тем более, у автора такие детские размеры.

о, нашел другую базу в архиве.
CJ447.dbf - 475376 записей - размер 61 846 160 байт.

твои "500 000 строк" в dbf будут весить меньше 70 Мб.
Не смеши тапочки своими "большими" размерами.

(8) Завтра выложу размеры. ЗиКу в SQL выложили давно, я пришла позже. Но знаю ЗиК слабо, поэтому буду благодарна за любой совет).

(13) потрахаться не забудь
ЗЫ про за любой совет :))

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

(15) ладно, не пишите больше

(не нашла в словаре, что за ЖР)
ЗЫ что четал челевек?

что то миста обыдливается, сезонное надеюсь

(17) Смотрела в DD, не нашла там сперва журнал Страховые взносы СтраховыеВзносы, сейчас нашла. Без иронии никак? Буквы "и " и "о" на клавиатуре западают?

Еще погуглила - создается впечатление, что в 7.7 простых средств для ускорения нет? Стандартная обработка с ИТС чистит ЖР, но практически не ускоряет расчет зарплаты, судя по отзывам. Сложную обработку написать я не смогу, предметная область знакома слабо.
(6) 1С++ загрузить при старте - единственный полезный совет, имхо... Но не знаю, насколько 1С++ стабильно работает...
Ну, и посмотрю, потянет ли DBF-я база по размеру после чистки Kladr и чистки ЖР...
Спасибо всем, кто дал советы!) Успехов вам и хорошего настроения!!!)

Сколько у вас сотрудников, что сильно тормозит?

Всех уволить. ЗИКа летать начнет.

(21) Около 3000 человек.

(22) Пятница через 25 минут, раздел другой).

Все, до завтра и еще раз спасибо ответившим!)

(23) сколько по времени длится расчет?
щитаю что 2-2,5 часа на такое количество терпимо. хотя могу что-то позабыть. 4 года за зик не брался.

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

(0) Если не ошибаюсь на софтпойте была статья по этому поводу. Поищите.
И опять таки если не изменяет память, самое узкое место в методе ВыбратьПоЗначению() в процедуре расчета.

(28) самое узкое место в ЗиК - это сами расчеты...

Самое узкое место в ЗиК это работа с большими таблицами значений (функция глПроводкиЗаПериод) ну и само собой выборки по ЖР. Выборки по ЖР переписываются на прямые запросы без проблем а по глПроводки тоже от Vaicartana есть решение - правда под новые релизы надо под себя точить.
Основными показателями нагрузки на базу являются:
- количество сотрудников;
- количество постоянных видов расчетов и их вид (фиксированной суммой, процентом от базы)
- количество переменных видов расчетов (в месяц сколько разовых начислений)
- правка данных об НДФЛ в карточках (страдают же этим некоторые)
- методика отражения в БУ (для анализа производительности формирования свода проводок)
После предоставления этих сведений (0) можно будет далее предметно разговаривать.
Также желательно предоставить характеристику сервера SQL
- аппаратные характеристики (частота процессора, шины, размер оперативной памяти, конфигурация дисковой подсистемы - кол-во дисков; контроллер; уровень массива; включен ли кэш обратной записи)
- программные характеристики - ОС (разрядность), версия SQL (select @@version), настройки AWE и PAE если SQL x32, производится ли обслуживание базы (обновление статистики, переиндексация).

Ускорить всегда можно, остается все переписать на прямые запросы :)

забить.
С 1 января ЗиКа начнет считать ощутимо быстрее. :)))
К концу года опять будет тормозить.
Это циклическое :)))
В январе ЗиК "пробегает" при расчете по человеку 1 раз (1 месяц), в декабре - 12 раз (12 месяцев)...

(30) Данные уточню в понедельник. Сразу: разовых начислений много, активно начисляются премии фиксированной суммой.
Вопрос: переход на 8.2 решит проблему или тормоза будут большие по-прежнему? Сейчас расчет идет так, что расчетчики перед зарплатой сидят ночами.

(30) Дополняю: "методика отражения в БУ" - шаблоны проводок не заполнены, выгрузки в Бухгалтерию на сегодня нет, если Вы об этом.

занимался как-то ускорением ЗИК под СКЛ. мутота. КЛАДР там вообще ни при делах.

Странно.. 2500 человек ЗиКа десять лет назад на пеньке с 1Гб памяти считала часа полтора... притом там совсем замутные расчеты были у бригад.. что-то не то в консерватории.. и слезайте со скуля..

dbf,ssd,терминал,ram диск
все уже ясно, что еще?

(34)Не работает ЗиК на SQL. Ужасно тормозит.
Решение одно, резать + Переводить на DBF.
Если людей больше 400, то завести несколько зиков.
Ибо ЗиК, это решение для малого бизнеса :)
...
Если не устраивает много баз и все же хочется SQL, то вам нужен ЗуП, на 8-ке :)

(37)Все в топку, не поможет.

+(34)Если начнешь переписывать на прямые запросы, то будь готова это делать при каждом обновлении :)
Ибо ЗиК обновляется с такой же скоростью, с которой у нас в стране пишутся Законы. Т.е. всегда... :)

(36)Нечего странного, все дело в SQL, зик криво отрабатывает запросы. Походу, когда 1С переходила на SQL, то поленилась по человечески написать запросы :)

Обратимся к классикам
"Часто на форуме задается вопрос «а сколько сотрудников реально рассчитывать в программе ЗиК»? Отвечаю: вполне реально рассчитывать 6-7 тыс человек, практически без переделок, с переделками еще больше.
Только нужно грамотно разделять ввод и отчетную информацию - при такой численности все отчеты следует получать на «вчерашней» копии, общий расчет зарплаты ставить на ночь, а всю первичку вынести в отдельную базу и настроить односторонний обмен.
2-3 тысячи человек программа отработает вообще безо всяких вопросов. "(С)

http://hghltd.yandex.net/yandbtm?text=Уважаемые%20балбесы%2C%20если%20вам%20влом%20найти%20постановление%20МинТруда%20за%20номером%2056&url=http%3A%2F%2Fvaicartana.narod.ru%2Fzic.cgi&fmode=inject&mime=html&l10n=ru&sign=14eabae308f0d042d4b1e4f087bf4e6b&keyno=0

как всех уволить! а расстрелять?

видел зику на две тыры человек, дык и то в распреленных базах

(42)Сказочник... ну вы продолжайте :)

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

Можно убыстрить ЗиК. Из своего опыта: 12000 сотрудников - проведение документа "Начисление зарплаты" и следом расчет зарплаты длился меньше часа.

1. ДБФ и Терминал (естественно хорошее железо: проц и память)
2. 1CPP.dll
3. SSD диск
4. Избавится от ПолучитьСтрокуПоНомеру()
5. Ежедневные копии

http://www.softpoint.ru/info_id94.htm

А из практических советов - распараллеливайте. Зик по другому эффективно не ускоряется.

(20) расчет зп в ЗиК 1с 7.7 только в монопольном режиме!!! Скорость выполнения на порядок выше! Не спрашивай почему.

(48)Неправильное утверждение, не спрашивайте почему:) А если серьезно это только справедливо для DBF да и то не на порядок а в разы. Происходит из за системы файлового кеширования в монопольном режиме.

(47) а какие затраты на это там не написано?
Сколько времени и денег потрачено. Хотя в (46) приведет к такой же скорости работы.