Извечная тема для семерок - превышение 2Гектаров
Обратился на днях клиент
RA 1.32Гб, RG 1.85 Гб
Ну диагноз понятен - пухнет, не закрыт
RG в течении месяца не растет(период месяц)
каждый месяц на метров 5 вырастает
Клиент измерения убирать не хочет, ресурсы урезать тоже, сворачивать не хочет, Скуль ставить не хочет
Попросил хотя бы остановить рост.
1)
Ну для начала ТиС сделал, все пункты прошли на ура , последним включил пересчет итогов, - через 2-е суток  -программа аварийно закрылась.
RG файы не удалял.
2)
Сели с бухгалтером посмотрели что много хвостов по отчету партий по 1 копейке или вообще сумма бек кво.
Сделал служебный документ и в нем все хвосты убрал просто сторно правильно по измерениям
3) Но проблема в том что специфика фирмы в том что у них много остатков партий реально на складе лежат с 2003 года, тоесть не должны закрывааться, я думаю что по этому и такое распухание RG

4) Попробовал закрыть не закрытое
Вот тут нужен совет
Выгрузил остатки по не закрытым регистрам
допустим весит такая строка:
Фирма  - пусто
склад  - пусто
статус - пусто
контрагент -Вася
Док - РН№1
сумма  - 10
Кво - 0
Делаю точно такую же запись в регистре движения (спец документом)
ну типа остатков уже нет партии - всё красиво но потом на  следующий месяц RG всё равно подростает.
Универсальным отчетом по регистру смотрю -  вроде всё нормально
Может я не то смотрю
Как Вы ищете в  универсальном регистре не закрытые партии ? точнее не правильно закрытые ?

Вот такая картина маслом !
#===============================================================================
#==TABLE no 261    : Регистр ПартииТоваров
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RG277   |Регистр ПартииТоваров         |A          |RG277      |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=PERIOD    |Period Registr      |D   |8     |0        
F=SP278     |(P)Фирма            |C   |9     |0        
F=SP279     |(P)Товар            |C   |9     |0        
F=SP280     |(P)Статус           |C   |1     |0        
F=SP281     |(P)Контрагент       |C   |9     |0        
F=SP282     |(P)Поставщик        |C   |9     |0        
F=SP283     |(P)Поставка         |C   |13    |0        
F=SP284     |(P)ПрихДокумент     |C   |13    |0        
F=SP2783    |(P)Склад            |C   |9     |0        
F=SP285     |(P)ОстатокТовара    |N   |16    |5        
F=SP286     |(P)Стоимость        |N   |20    |2        
F=SP287     |(P)ПродСтоимость    |N   |20    |2        
F=SP288     |(P)НДС              |N   |20    |2        
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=PROP     |PERIOD+PROP   |0     |PERIOD,SP278,SP279,SP280,SP281,SP282,SP283,SP284,SP2783     |PROP      
#
#===============================================================================
#==TABLE no 262    : Регистр (Дв.) ПартииТоваров
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RA277   |Регистр (Дв.) ПартииТоваров   |A          |RA277      |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=IDDOC     |ID Document's       |C   |9     |0        
F=LINENO    |LineNo              |N   |4     |0        
F=ACTNO     |Action No           |N   |6     |0        
F=DEBKRED   |Flag Debet/Kredit   |N   |1     |0        
F=SP278     |(P)Фирма            |C   |9     |0        
F=SP279     |(P)Товар            |C   |9     |0        
F=SP280     |(P)Статус           |C   |1     |0        
F=SP281     |(P)Контрагент       |C   |9     |0        
F=SP282     |(P)Поставщик        |C   |9     |0        
F=SP283     |(P)Поставка         |C   |13    |0        
F=SP284     |(P)ПрихДокумент     |C   |13    |0        
F=SP2783    |(P)Склад            |C   |9     |0        
F=SP285     |(P)ОстатокТовара    |N   |16    |5        
F=SP286     |(P)Стоимость        |N   |20    |2        
F=SP287     |(P)ПродСтоимость    |N   |20    |2        
F=SP288     |(P)НДС              |N   |20    |2        
F=SP290     |(P)Оборот           |N   |20    |5        
F=SP292     |(P)НДСрасхода       |N   |20    |5        
F=SP294     |(P)КодОперации      |C   |1     |0        
F=SP2309    |(P)Прибыль          |N   |20    |5        
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=IDLINE   |of IDDOC+LineN|0     |IDDOC,LINENO,ACTNO                                          |IDLINE    
#

(1) нет такого патча

(1)
4 Гб это наверное патч для того что б выгрузить в SQL типа Solution 7?
Как может DBF быть больше 2Гб
Кстати о Solution.
Посмотрел  на базу а у них реально много остатков на партиях -  физически много - тоесть на складе валяеться куча всего старого и не продаётся.
Выгрузил в скуль  - база стала 100 Гб (в дбф база 18 Гб)
Не получется что в скуле она будет еще быстрее расти
(2) Спасибо
Можно ли по подробнее 1 - й пункт. -  как Вы это делаете ?
По  пункту 3 - Перавая попытка пересчёта -  краш.  Сейчас в копии удалил RG и снова пересчитываю -  пару дней будет

(4) Ёпрст - спасибо что подтянулся !!!
Конфу писал какой то там ABBBY  в 2003 году торговля

поставщик и поставка  -  это вообще БЕЙС
Там  действительно поставщик и поставка, РН там иногда свои движения прописывают - когда в минус проводят
А в Акте оприходования они пустые

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

(8) полная (___о___)

(7) выкинуть из измерений Поставщик/Поставка/Контрагент, для начала

Клиенту говоришь: в условиях бардака в учете и отсутствия ресурсов для регулярного "закрытия" этого бардака в ноль - единственный вариант - перейти на скуль и продолжать дальше пложить бардак.
А самому срочно бежать оттуда - если что - сигай через окно...

Ну так им работу сделали -  мне сейчас надо им тоже самое оставить.
(9) каком к верху я уже сделал -  подозрительное, меньше 0,001 и тд...
убрал 30 Мб

(6) Сделайте пересчет на скуле. Готовая обработка была на инфостарте

(11) выкинуть можно много. может у них после этого вся работа встанет ибо на эти измерения куча отчетов "ну очень нужных" накалякана

(13) убирай по п.2 как я выше сказал. получится больше сэкономить.

При желании, можно оставить поставщика, если туда то что надо пишется как при приходе, так и при расходе

Для теста можешь пункт 4 сделать на базе без пп1-3. посмотришь насколько уменьшится. если уменьшится очень мало - значит совсем бяка...

(16) Работаю в этом направлению
поставщик контрагент и поставка у них куча где прописаны

(14) потом со скуля выгрузить на ДБФ - пересчет итогов пойдет заново. не выход.

Если в базе нет многофирменного учета, выкинуть еще и фирму оттуда

(19) и чего пишут в Контрагента при поступлении  и реализации ?!

если чистая купи-продай - выкинуть "Статус" возможно или посмотреть нафейхоа он там

(22) как обычно. каком кверху ;-)

(22) Ты правильно подметил - поле контрагент просто дублирует поставщика но в некоторых отчета используется и контр и пост отдельно.
Статус  -  это вообще раритет. им реально пользуется бух с 2003 года. статус мало занимает

Да там еще Общ учёт, тоесть 2 движения с фирмой и без.

короче - вешайся ;-)

(25) всё это приводится в порядок за пару часов.
Пересчет итогов на такой базе будет минут 5. Скуль там не нужен.

(20) Все сделать на скуле, выгрузить уже красивую.

Нужно просто вдумчиво посмотреть на движения прихода и расхода регистра, выкинуть лишнее, поправить код  и таблички регистров.

1)Сейчас пересчитываю регистр после удаления RG,
2)Потом попробую убрать нулевые - хотя я их не вижу в regprint
3)Потом выгружу в скуль там сделаю пересчеты чистки и тд и попробую обратно всосать в дбф

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

(29) + За то пересчет напрямую в скуле будет минут 10 на не пару суток как у (0)

(29) как есть, это г..о не затолкать на скуль
а)оно тупо не выгрузится
б)оно не загрузится

(28) Не понял про 5минут ?

в скульуже выгрузил - сейчас там крутятся обработки

Ну хорошо -  удалю поставщика допустим -  как оно мне даст  выигрыш  в пересчёте -  он у меня двое суток идёт

(34) чего непонятного ? база в 20ГБ на дбф, пересчет итогов занимает 10 минут.
Твоя от силы 5..

там  в базе 30 регистров

переиндексация идёт 20 минут

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

(38) И че ?
там и половина регистров не используется

(36) Делай пересчет пока средствами скуля, прямыми запросами. В инетах была готовая обработка.

(42) Да делаю уже
И еще параллельно пересчет с удалёнными файлами

(41)  Все регистры юзаются на полную
Дебеторки разные , потом еще что то типа регистров сведений у них там есть (наверное восьмерочник руки запускал ))))))

Кароч все регистры в работе. Там так - Документ. -  под него регистр, и отчёт - ))) Во Как  -  видимо много рабоду бодалось с ней. Кстати это и спасло регистр партий - не пхали в него лишнего а делали извне

(31) а в регпринте ты их и не увидишь

И вот это еще ПродСтоимость    зачем в ресурс запихали ?!

(41)  Не ну я всё равно не могу поверить. Ты наверное говоришь про фирмы у которы нет висячих остатков на физическом складе.
У этих -  склад с футбольное поле забит говном с девяностых и на всё это еще и партия есть.
Я когда выгрузил остатки  что б их в пустую базу завернуть - оболдел -  там реально всё нужное!

(37) это как ты так ловко пересчитываешь? чем?

(39) на таком обьеме переиндексация не долшье 3-4 минут должна идти (это у меня на серваке 10летней давности)

(47) Анализировал. - Это конкретно для розницы

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

Короче,
1. выкинуть из измерений Контрагент, Поставка, Статус
2. Ресурс ПродСтоимость перенести в реквизит ПродСтоимость
3. найти все записи в RA, где пустой документ в ПрихДокумент
и исправить это
4. найти все записи в RA, где пустой склад и заполнить его
5. найти все записи, где пустой Поставщик и заполнить его из ПрихДокумента
6. далее, пересчитать итоги по этому регистру.

(1) Поподробнее можно, что за патч?

(51) у ва с розница ?

(54) нет такого патча. Размер дбф не может быть физически >2 ГБ

и опт и розница и еще маленькое производство

(52) При удалении нулевых - никаких. По крайней мере я юзаю, на траблы пока не натыкался.

(49) Скорее всего вот этим
http://catalog.mista.ru/public/14216/

(54) это патч использования ОП

(59),(2)  За деньги. Остаётся (53). Стрёмное конечно
. Какими средствами вы правите RA ?

(61) insert/update/delete через vfpoledb

при желании, можно этим
http://catalog.mista.ru/public/79515/

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

Плохо, что для дбф пересчета не сделали как для скуля в (59)

(65) Можно взять исходники http://www.codebase.com и сделать. Наверное.

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

(67) ))))
(64) Спасибо !

(63) Шикарно ! Её можно подпарвить и на автоматическое действие  -  допустим пройтись по всем движам и простаить склад...

А прод стимость в рознице я бы не трогал пущай в ресурсах висит

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

(67) просто представил сколько там возни..

В sql Залилось -  и сделался пересчет, сейчас выгружу обратно в файл  -  и в 1С, посмотрю на рез.

Впринципи можно RA править SQL Запросами

Заказчик хоть в курсе, что это лишь отсрочка ненадолго?

Выгрузил из скуля базу гружу в dbf - файл всего 3,6 Гб, при том что в  скуле он  под сто, а в ДБФ база была  22,4 Гб
О чём это может говорить - много пустой информации ? - Все процедуры вплоть до упаковки делались -  только минуса в регистрах не убирались , - пока !

(75) Главное что у меня на готове уже скуль -  пыхтит и ждёт ))) А если заказчик хочет экстрима  -  пусть получает

час ночи .. Обычный пересчет итогов увеличил таблицу остатков до 1,99 - в топку. Выгрузка из скуля - 1,91  - в топку
сейчас рабочий размер регистра 1,84
Остается последние два варианта - Удалить нули (Спасибо Злопчинскому) и удалять реквизиты (спасибо ЁПРСТУ)

Я думаю что чистка нулей в твоём случае даст очень маленький эффект, практически нулевой.

(78) Кручу, верчу, обмануть хочу...

Чего тут гадать? Либо на SQL переходить. Либо на восьмерку.

+80 По аналогии:

Приходи мужик к врачу и говорит:
- Доктор, у меня нога болит и плохо пахнет. Помогите!

Доктор осмотрел ногу и отвечает:
- Плохи ваши дела, нужно удалять по колено.

- Но я не хочу удалять! Она мне дорога, как память! Я с ней столько лет вместе!

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

*приходит

(0) Конфигурация, наверно, на основе ТиС версии 8.7? Которую 1С ещё до исторического материализма (2000 г.) заменила на версию 9.2?

(80) Только не забыть перенести на восьмерку все косяки этого "шедевра" и успеть вовремя смыться :)

(0) Поскольку ситуация близка к экстренной, сейчас базу только обрезать. Для любителей воспоминаний о боевой молодости оставить архив на просмотр.

(84) Старые косяки лучше оставить в старой базе.  В новой базе нужно делать новые! :)

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

https://drive.google.com/file/d/1lRyGighjSwIn4S_JlZhZlVwINQTvrayr/view?usp=sharing

После заливки и всяких тестов и пересчётов она заняла : 4 г база 23 Г
Не работал раньше с большими поэтому прошу  совета
Нормально будет ?
Меня интересует модель восстановления полная и ограничения на рост файлов
Местяк на диске впринципи есть пару териков пока будет всё на одном терминале, потом может разделить дадут на разные серваки

(83) База ТИС 7,70,003. одна из первых - 2001 или 2000 год
18 лет и всего один рег поджимает -  а так всё в шоколаде, так бы еще 20 лет её не трогал ))) в ней уже и производство там допилено и розница и даже  какой-то там фин учет даже есть и штрихкоды ))) даже мобильную весьмёрку им прикрутил ))))

(87) если не нужны архивы, то модель простая, убрать понижение совместимости, рост выставляют в мг, а не процентах.

В скуль зашло нормально ! Благодаря ромиксу солюшенам и одбц  заменялкам и еще пару запросов по уникальным записям, ну в общем малой кровью
(89) А как без архивов можно ? Ну если там чего грохнулось -  поднять хоть прошлый день ?
Убрать понижение до 2000 ?
Рост базы стоит 1Мб а лог в процентах -  поставить Мб ? сколько лучше ?

хотя бы по 512м для файла и журнала, рост не ограничен

+ паралелизм убрать

Про совместимость -  если я правильно понял залить в базу в режиме совместимости  2000, а потом переключить  в 2008? А потом не будет косяков? На что это может впринципи повлиять ? (91) Спасибо!

Могут возникнуть косяки с хранимыми процедурами 2000 и 2008 ?

Есть еще способ порезать регистр - обратить внимение на числовые величины измерений. К примеру на сумму НП. Она не нужна, просто поставить в 2

(92) паралелизм никогда вообще не трогал
По дефолту такая картина с процессорами
Ты наверное имеешь ввиду выставить
max degree of parallelism в 1 ?
Тыкни где этот параметр можно поменять, Пожалуйста.
https://drive.google.com/file/d/1QiRrVIkmICOFjMeQH5wPFRrnILPzYLFa/view?usp=sharing
(95)  А что за сумма НП, не вижу такой ?

(92) Может ты имеешь ввиду sp_configure ?

sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE;
GO

(98) забыл  -  это доп параметр -  тогда вот так
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure max degree of parallelism', 1;
GO
RECONFIGURE;
GO
(92) Это ты имел ввиду ?

Ребята ! - поделитесь опытом восстановления  SQL из симпла и из фула? Интересует не пошаговаяинструкция и подводные камни того или иного метола-  плюсы и минусы. У меня из опыта только серваков пять  моих но админят их админы по бумажке которую я написал и толком опыта не имеют. Везде стоят фулы. В двух сервакав лог за неделю выростает до 90 Гб и админ  переводит в симпл, удаляет лог и потом опять в фул. Но у них база 11 Гб в год растёт и обрезается.
А в моём теперешнем случае база уже 20 Гб и лог после закачки уже 4Г -  а еще ничего не делали, вот и имею мысль делать в симпл, но Никогда не имел с этим симплом дело, поэтому и прошу совета. Заранее благодарен всем откликнувшимся !

(100) Ставь симпл, но с ним сможешь восстановиться только на момент бекапа, если что.
Если не критично такое точное восстановление, хватит симпл.

(101) Спасибо. Именно такое интересует только на момент бекапа. Мне смущает момент, как сам сервак при сбое поднимается при симпле. Был у кого то опыт ?
Ну допустим трабл с УПС и сервак выключили. Включается. Хватит ему данных в журнале, что б нормально подняться ?

(102) Всегда поднимался без вопросов. Могут пропасть только незавершенные транзакции.

Да это фиг с ними, разве что УРБД в этот момент могут качаться сливаться ))))