Надо с кем-нить посоветоваться. =) Вкратце суть проблемы - бухи мечтают ускориться. ИП.
Две 1с-ы: 7.7(торговля) и 8.2(бухия), обе на скл. Данные из торговли перекачиваются в бухию вчерашним днем.. Пара баз бухии объемом ~80гб каждая (последние 3 года). Документо-оборот только по реализации около 1000 док-тов в день на каждую базу. Обычно раз в месяц бухи запускают перепроведение, которое длится около 2х суток. Медленовато формируются книга покупок, регистрация счф на аванс. Книгу доходов пришлось разделить "по разделам", т.к. клиенту не хватало окна в 4гб.
Все (скл+1с) живет на HP Proliant DL380R06 E5530+32гб+Серв2008стандарт 64+рейд 10 sas 15к 8шт долько под диск базы.
Есть у кого-то мысли по качественному/количественному апгрейду?

Отладчик уже подрочил?

(1) нет.
бухия сток (2.0.36.4) движек (8.2.17.143)

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

(0) В КА и УПП нет необходимости перепроведение запускать.

шо, опять?©
v7: Померяемся? SELECT Count(*) FROM _1SJOURN (2)

(4) тут обычная бухия, или ты предлогаешь перейти? =)

(5) спос покурю =)) там тока семерки?

(6) Вы хотели мыслей. В КА и УПП бухгалтерского функционала полно.

(8) Пардон, Вы. =) Благодарю.

(9) В вашей ситуации апгрейд железа мало чего даст.

Дописывать узкие места. Смотреть - когда возникают тормоза (к концу месяца, или через неделю после перезапуска серверов, после долгой работы любого пользователя (как в 77 было с *.cfg файлом с настройками пользователя). Строить регламенты - еженедельное, где возможно, закрытие участков.

Если всё это не решит - копить денег на softpoint.ru

А сто, 1000 доков в день - это уже много для снеговика?

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

(13) ну так смотри счетчики сиквела, и скрипт от vde69

(12) Для БП - очень много. Особенно если перепроведение делать - вообще труба.

(15) грустно. И на чем работать?

(16) ну на том, где есть РАУЗ, наверное...

(17) да чойто и рауз не радует...
так и сидеть, не дергаться? Но, боюсь, более 250 тыщ доков у меня не вытянет... а такая перспектива есть через пару лет...

Кстати, может кто знает: в КА и УПП есть возможность в бухучете вести учет по 41 счету по "сводной" номенклатуре?
Т.е. в документе 100 строк, а проводка по 41 счету - одна? (полный учет - по регистрам)

(18) Да пошустрее ПУ будет. Через пару лет будет 1С 9.0 и РАУЗ 2.0, так что проблема наверное решится ))

(19) если юзаешь характеристики, то так оно и есть.

(12) 1000 док в день это копейки, для снеговиеа проблеммы для 100 док в день, а вот 10000 это глрмально.
Проблемма в том, что сложно обьяснить почему отчет в 3 стооки формируется 5 сек, но всем понятно когда 20000 стоок формиокетсч 30 с

(20) у мню 7.7. Надо бы переходить, а как-то вариантов... только на самописку...

(22) Не поясните, за счет чего при увеличении документооборота скорость увеличивается? Чтой-то туплю

(24) Он хотел сказать, что 8ка и со 100 документами, и с 10000 работает одинаково медленно :)
У автора темы главная проблема - перепроведение. Ускорить можно только придумывая схему многопоточного проведения.

(25) Или отказаться от перепроведения в пользу более прогрессивных методик.

(26) тайная методика pit'а? :-)))

(27) Что это такое?

(2) Переходите на 3.0 и вы поймете как у вас сейчас всё просто летает....

p.S. А что такая древняя бухия то, тем более если типовая:

(28) вам молодым не понять

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

(27) Перепроводят обычно с целью восстановить состояние расчетов с контрагентами или для рассчета себестоимости. Вместо перепроведения достаточно обновить движения только по "нужным" регистрам.

(32) прости но в типовой один регистр - да и тот бухгалтерии, там не используется 1000 и один регистр накопления

поэтому чтобы обновить нужный регистр фактически можно перепровести базу

Другое дело, что можно проводить виртуально, сравнивать движения и если движения не изменились, то и не трогать запись

(34) поверь для типовой бухии непоможит

(36)С чего это? Скулю как то фиолетово типовая тим бухия или упп 11

(37) ну-ну

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

И да все эти рекомендации уже 100 лет как прописаны на скуле, типовой глубоко все равно на чём тормозить

(38)у меня с бухией примерно такие же траблы были.
Статистики полдня обновлялись. Потом все залетало.
Теперь на регламенте регулярно делатся

Что напрягает? Долгое "перепроведение документов за месяц"?

(41) стабильно каждую ночь делается, полетов не заметно

(43)ну тогда значит у тебя дело не в этом.

пока что в планах после перехода на 3.0 сделать уриб копию и резать каждый год

(45)У нас резать вообще без вопросов, регламентная операция ежегодно.
А на 8.3 тоже планируем.Но через годик. Сыровато оно еще.

(33)
1. В типовой БП больше 40 регистров накопления.
2. Т.е. рассчитать сумму зачтенного аванса при реализации и заменить ее в проводке то-же по времени, что перепровести документ?

(34) ой, а кто это у нас http://kb.1c.ru/articleView.jsp?id=13 смистил? айайай

(48)Я честно поставил копирайт:-)
Ценная инфа должна быть доступна не только для зарегеных франчей и их подданых, имхо.

(48) копилку пригодилось:-)

факардо!! только запостил и у провайдера лег главный концентратор.. по всему району, где контора находится. =)
(49) не успел посмотреть, чего там было =)
я сам восьмеркой не занимаюсь (разве что какие-то мелочи), суппортю семь-семь, но, чувствую, прийдется и ее ковырять. Т.к. ниразу не понятно, что можно делать, не загружая ни проц, ни дисковую подсистему. =\ С отладчиком полазию.. думал что проблема типовая и проявляется у многих, у кого большой док-оборот. Посему хотел обсудить, как кто решает. По той схеме, по которой сейчас работает организация, бухов напрягают две вещи - тормозное перепроведение и невозможность работы во время формирования указанных отчетов. Кста, а что никто не написал про превышения лимита 32 разрядного приложения?.. или не встречалось? =)

(3) я не настолько хорошо пока знаю как работает бухия =)
да и думаю врятли такое возможно.. на чем при таком раскладе возможно сэкономить?

регламенты - обновление статистики чекинг и реиндексация каждую ночь

(14) шо за скрипт от vde69 и где его взять?

(29) бухию обновляет местный франч. я бы и не трогал эту тему, бо своих забот хватает. но тут ГБ вздумалось розницу (еще 4 точки) слить в одну базу с оптом. и соответсно доков должно еще прибавится. а как-бэ уже не шибко быстро работает. =)

(51) переходи на БП 3.0. Будет дольше перепроводиться, зато можно лазить по программе (проведения в фоне идёт)

(47) и что? Большая половина из них для ИПников только, часть по комиссии и по мелочи. В 99% идут чистые проводки без регистров (это в 1.6 было в движении количество регистров накопления было больше чем количество проводок)

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

+(58) хороший пример ЗИК, ЗУП. Проводки в бухии думаю в 1000 раз по объему меньше данных в ЗИК, плюс совсем немного справочники еще и регистры

(52) При таких объмах глупо копировать всю информацию в бух, которая там не нужна.

(52)  подобное еще в 2000 году делали ))), тоже было очень много документов 1000 - 2000 доков в день и строк в них(100-200)

(0) Вот не сочтите за офтоп - но нафига тащить всю реализацию из торговли в бухию? в чем сакральный смысл дублирования огромного массива данных .к оторые потом еще и сверить надо а вдруг после выгрузки какая-то сволота взяла и поменяла?

(62) например в торговой учет ведется скопом без разбивки по организациям, или филиалы

Плюс у нас налоговая постоянно запрашивает накладные от поставщиков по котором пришел товар проданный конкретно этому покупателю

(63)  ну так дайте информацию с торговли

Просто смысл в дубляже информации? не проще тогда вести все в комплексной в одной базе?

поддерживаю идею об обобщенном (и даже обезличенном) учете в бух, вплоть до раз в месяц делать одной строчкой по каждому счету учета ТМЦ делать един свод приход/расход

(64) там нет этой информации

(63) Если у вас учет не по ФИФО, и нет специфики обязывающей вести партионный учет - налоговую с такими запросами можно послать далеко и надолго. Что например мы с великим удовольствием и делаем.

(67) Самая распространённая схема (и ИМХО самая вменяемая) - это выгрузка из ОУ в БУ.
То есть в ОУ есть по товару всё, в БУ только то что нужно для фискального учета.

(68) нет ни по фифо, и нет специфики, просто запрос из налоговой о предоставлении информации о закупки товара проданного этому клиенту (проверяют всю цепочку от клиента до поставщика).  Послать ... был у нас инспектор один, так он по базам ГИБДД пробивал по госномерам машины, из ТТН и придерался если модель в ТТН не соответствовала базе ГИБДД, или типа а напишите объяснительную как вам поставщик привез 2 коробки товара (там мелочёвка кг на 10 максимум) на машине ВАЗ-2110

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

Вообщем много всего весёлого, но сабж не об этом, а о типовой БП и ускорение её работы на больших объемах

P.S. мне кстати так и никто и не смог объяснить внятно почему 1С в типовой БП несмогла с разделителем данных, т.е. почему объем проводок по организации А влияет на скорость удаления данных в организации Б

(70) ТТН хранится только если перевозка осуществляется сторонней организацией. С ТТН так-же можно послать инспектора далеко и надолго. Если они хотят доказать схему, то это им нужно доказывать схему, а не вам что схемы не было. И никакие документы сверх необходимых вы им предоставлять не должны.
(71) У нас не ларек, мы состоим в налоговой по работе с крупнейшими налогоплательщиками :)

(72) У нас документооборот намного больше чем в сабже, и с типовыми работать слишком некомфортно. Но за день можно порезать конфигурацию так, что всё будет летать.

(71) Абсолютно нормальная история когда налоговая проводит следственные действия. Ничего страшного в этом нет, если вы конечно не замешаны в схемах.

(75) да как бы в криминальных нет, вот переодически и требуют, то карточку 41 (которая минимум на 500 листов и даже в екселе не сохраняется, отсылал в html формате), то документы по закупки, то еще чего

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

Угу вот он и копал, искал к чему придраться

У меня объемы 40 см

полазил по табличкам.. самые жирные
AccRg468_____4.5 6.8 Гб 22,937,944 строк
AccRgED504__13.2 8.1 Гб 92,022,826 строк
AccumRg7575__4.8 4.2 Гб 19,414,769 строк

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

налоговая в основном как раз приходы проверяет

(81) в документах много строк?
Если много строк в документе, то для начало можно доки перебрасывать с одной итоговой по документу строкой.

(83) в среднем около 100 редко больше

(84) конечно это не совсем правильно, проще перебрасывать обощенные проводки, тк с себестоимостью проблемы будут.

(84) Если это очень надо  и если  хорошо подумать то все решаемо.

а сами размеры табличек - это вообще много или мало? =)

(87) Приличный размер. Мы бы померли на типовой БП учет вести. У себя сделали учет товаров - в отдельном РН (у нас и серии, и партии), а учет на 41 счете - только по субконто "Склады", по 1 проводке на документ.
Данные РН всегда совпадают с 41 счетом.
Но это - серьезная переписка типовой.
В "хозрасчетном" регистре (8.1 на базе БП 1.6) имеем:
Основная _AccntReg10321 11 гб 25 млн. записей
ЗначенияСубконто _AccntRegED10346 18 гб 81 млн. записей

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