Вопрос программистам

[AlexACE]

У меня 1с предприятие 7,7 для SQL сетевая, сегодня сделал свёртку базы за 7ми летний период и сразу заметил что после свёртки база стала "весить" в 2 раза больше. 989мб вместо 415мб до свёртки, вопрос почему так? Истории стало на 7 лет меньше, логично было бы предположить что и веса станет меньше. Решил по сравнивать конкретно размеры файлов и обнаружил 2 файла RG99 CDX и DBF, которые имели вес 44мб и 102мб соответственно до свёртки и 257мб и 427мб после. За что конкретно отвечают эти файлы? Можно ли взять и заменить их старыми? Ещё вопрос напоследок куда пишутся логи "Журнала регистрации", который в меню сервис есть и показывает всю активность за весь период существования базы? Мне теперь логи досвёрточного периода не нужны и хотел бы их зачистить и вообще по возможности отключить его, ибо не нужен он мне и я думаю он тоже место жрёт на диске, в конфигураторе не нашёл ничего по нему вообще. Ещё заметил что база стала изрядно тупить при подборе товара в чек например, но не каждый раз, а как ей захочется.
P.S. Попробовал заменить файлы RG99 оба и не заметил никаких изменений вроде, может будут какие то скрытые последствия потом?

[Herby]

Я что не понял, у вас база DBF или SQL?

2 файла RG99 CDX и DBF

такие файлы могут быть только в файловой версии в ДБФ.

И каким образом вы свертку делаете?

За что конкретно отвечают эти файлы?

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

Ещё вопрос напоследок куда пишутся логи "Журнала регистрации"

папка SYSLOG

[AlexACE]

Я что не понял, у вас база DBF или SQL?

2 файла RG99 CDX и DBF

такие файлы могут быть только в файловой версии в ДБФ.

И каким образом вы свертку делаете?

За что конкретно отвечают эти файлы?

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

Ещё вопрос напоследок куда пишутся логи "Журнала регистрации"

папка SYSLOG

если бы я знал отличия DBF от SQL я бы написал, вот что выдаёт по кнопке "О программе"

Добавлено: 08 янв 2015, 06:46

И каким образом вы свертку делаете?

внешней обработкой, у нас база на основе типовой 4,3 предприятия доработанной программистами из "Ориента" 7 лет назад, конкретно процедура свёртки насколько я помню нужна была бухгалтеру нашему. Я то рассчитывал снизить вес базы свёрткой, а уж никак не поднять в 2 раза

[дфтын]

да понятно отчего так.
1. у вас оно не удалилось физически. оно только пометилось на удаление. т.е. записи остались
2. на начало года свернулись регистры - вот и увеличение размера.
Зайдите в конфигуратор, тестирование и исправление, и там - упаковка таблиц базы данных.

[AlexACE]

да понятно отчего так.
1. у вас оно не удалилось физически. оно только пометилось на удаление. т.е. записи остались
2. на начало года свернулись регистры - вот и увеличение размера.
Зайдите в конфигуратор, тестирование и исправление, и там - упаковка таблиц базы данных.

1. удалилось физически, более того я ещё дополнительно удалил все документы "ввод остатков кредитов" ибо не представляют информационной ценности

Добавлено: 08 янв 2015, 12:24

папка SYSLOG

там достаточно будет просто удалить mlg файл и он создаст новый лог с чистого листа?а то я заглянул, а он там аж свыше 100мб весит

Добавлено: 08 янв 2015, 12:29

Зайдите в конфигуратор, тестирование и исправление, и там - упаковка таблиц базы данных.

Запустил процесс, надеюсь это не займёт слишком много времени и действительно поможет.
Свёртка например у меня заняла 6,5 часов

[дфтын]

Это вам так кажется, что они физически удалились.на самом деле оно в таблице пометилось ,что удаленное, но из таблицы не куда не делось. вот процесс упаковки их уберет физически:)

[AlexACE]

Это вам так кажется, что они физически удалились.на самом деле оно в таблице пометилось ,что удаленное, но из таблицы не куда не делось. вот процесс упаковки их уберет физически:)

Значит выходит что каждый раз, когда я удаляю любые документы или позиции из справочников, они физически не удаляются тоже? И эту процедуру есть смысл запускать периодически? Кстати она выполнилась за полчаса и суммарный вес базы упал на 200мб примерно, что составляет лишь чуть меньше половины прироста.

Добавлено: 08 янв 2015, 14:54

Ещё немного поэкспериментировал с RG99 файлами и выяснил следующее:
1. При установке ТА в новой базе на момент свёртки, то есть как раз сразу на последний документ ввода, так чтобы остатки количественно совпадали с остатками в старой базе, замена РГ фалов не даёт результата, остатки остаются неизменными;
2. При оставлении ТА текущей, змена РГ выдаёт остатки на 01.01.15, на момент свёртки;
3. При любом варианте замен, если провести любой новый документ, либо просто сменить ТА, остатки вырастают в 2 раза;
4. Если снять проводки со всех текущих документов, заменя РГ всё равно выдаёт остатки на момент свёртки
Выходит что "свёртка базы" возможна и быстрым методом без всяких внешних спец. обработок, тупо групповой обработкой удалил всю исторю и перекинул РГ файлы? Из этих экспериментов я понял что РГ99 файлы несут в себе лишь инфо о текущих остатках, на момент ТА той базы с которой взяты. Тогда какого хрена после свёртки они выросли в 2 раза? Попробую ещё в чистой базе со старыми РГ сделать мат.ведомость, покажет ли хоть какую то историю позиций, а то у меня кроме того что они ещё и историю хранят больше нет мыслей по поводу их раздува.

Добавлено: 08 янв 2015, 15:42

В общем есть ещё какие то файлы отвечающие за остаток кроме RG99 ибо опытным путём я понял что 99е влияют только на отображаемый в справочнике "Номенклатура" остаток. Однако при попытке списать какой либо товар, из тех что отображаются с положительным остатком, выходит сообщение что на остатке 0. Истории они тоже в себе никакой не хранят, мат. ведомость выходит с пустой историей. Блин что в итоге делать то? У меня задача стоит избавить от лишнего веса базу данных.

[дфтын]

ну регистр состоит из двух таблицу, в одном движения в другом итоги. почитайте в инете устройства базы данных 7.7. Все что вы описываете - все верно.
Далее. нужно смотреть устройство регистров. очень может быть, что не корректно измерение какое то сделано и оно нормально не закрывается.
Ну и потом. У вас конфигурация Штрих М, я так подозреваю это регистр чеков, или чтото такое. Нужно изучать, что в вашем понимании было свертка, и что оно сделало.

[Herby]

989мб вместо 415мб

а зачем вы о размере базе так печетесь? Если за 7 лет ваша база стала 400мб, можно вообще не думать о свертке, тем более полезно иметь движения прошлых периодов.

[AlexACE]

ну регистр состоит из двух таблицу, в одном движения в другом итоги. почитайте в инете устройства базы данных 7.7. Все что вы описываете - все верно.
Далее. нужно смотреть устройство регистров. очень может быть, что не корректно измерение какое то сделано и оно нормально не закрывается.
Ну и потом. У вас конфигурация Штрих М, я так подозреваю это регистр чеков, или чтото такое. Нужно изучать, что в вашем понимании было свертка, и что оно сделало.

База была приспособлена для работы с ФР Штрих, сканерами и принтером штриховых этикеток BZB

Добавлено: 09 янв 2015, 07:46

989мб вместо 415мб

а зачем вы о размере базе так печетесь? Если за 7 лет ваша база стала 400мб, можно вообще не думать о свертке, тем более полезно иметь движения прошлых периодов.

Дело в железе на котором база стоит, места на винте маловато, решил "кастрировать" базу ибо помню что когда то она весила менее 100мб вообще. Ну раз не выходит ничего будем работать как есть, тем более что после свёртки база стала притормаживать ещё до кучи в подборе товара в чек и при навигации по номенклатуре, раз через раз.