О чем молчит 1С (хранение оборотного регистра) #658727

Коллеги, добрый день! Крутую штуку обнаружил, на выяснение которой ушло несколько рабочих дней: Условие: 1С:Предприятие 8.2 (8.2.15.319) размер ее составляет 230 Гб после шринка. есть документ РеализацияТоваров, в нем три строки и он сделал три движения по регистру ПродажиКомпании. Выполняю код, чтобы очистить движекния по данному регистру: 1С показывает, что у этого документа нет движений по данному регистру. НО ЭТО ВРАНЬЕ!!! Движения есть! Правда 1С про них ничего нам не говорит. Видимо скрывает, чтобы сберечь наши нервы. Лезу на скуле в оборотную таблицу этого регистра _AccumRgTn6629 и вижу эти строки, но с нулевыми ресурсами. Эти движения абсолютно не влияют на обороты так как все ресурсы у них - нулевые. И все бы ничего, но они занимают место не хуже обычных движений. Индексы на эту таблицу тоже значительно больше, чем без них. К счастью сама 1С удаляет эти строки с случае рестуктуризации таблиц регистра. В моем случае это случилось после смены типа измерения с ДокументСсылка на ДокументСсылка.ЗаказПокупателя почти случайно. Не все изменения структуры регистра приведут к реструктуризации, но именно эти приводят точно. Можно еще использовать такую нереграментированную штуку : delete from _AccumRgTn6629 where  _Fld6620 = 0 and _Fld6621 = 0 and _Fld6622 = 0 and _Fld7477 = 0 но как ты понимаешь это является нарушением лицензионного соглашения 1С :) Ну и что с этого, спросишь ты меня. Да, ничего особенного, но эти действия позволили уменьшить размер нашей базы на 45 гигобайт! А также повысить скорость работы отчетов по продажам не десятки процентов. Все это сравнительно бесплатно и является безусловно "низко висящим фруктом". Одно действие приводит к огромной экономии дискового пространства, ускорению регламентного обслуживания базы и уменьшению времени выполнения отчетов. А у тебя есть оборотные регистры в конфигурации? :) Скажите, может я Америку открыл? Нигде не смог найти информацию о подобном поведении системы. Спасибо!

Коллеги, добрый день! Крутую штуку обнаружил, на выяснение которой ушло несколько рабочих дней: Условие: 1С:Предприятие 8.2 (8.2.15.319) размер ее составляет 230 Гб после шринка. есть документ РеализацияТоваров, в нем три строки и он сделал три движения по регистру ПродажиКомпании. Выполняю код, чтобы очистить движекния по данному регистру: 1С показывает, что у этого документа нет движений по данному регистру. НО ЭТО ВРАНЬЕ!!! Движения есть! Правда 1С про них ничего нам не говорит. Видимо скрывает, чтобы сберечь наши нервы. Лезу на скуле в оборотную таблицу этого регистра _AccumRgTn6629 и вижу эти строки, но с нулевыми ресурсами. Эти движения абсолютно не влияют на обороты так как все ресурсы у них - нулевые. И все бы ничего, но они занимают место не хуже обычных движений. Индексы на эту таблицу тоже значительно больше, чем без них. К счастью сама 1С удаляет эти строки с случае рестуктуризации таблиц регистра. В моем случае это случилось после смены типа измерения с ДокументСсылка на ДокументСсылка.ЗаказПокупателя почти случайно. Не все изменения структуры регистра приведут к реструктуризации, но именно эти приводят точно. Можно еще использовать такую нереграментированную штуку : delete from _AccumRgTn6629 where  _Fld6620 = 0 and _Fld6621 = 0 and _Fld6622 = 0 and _Fld7477 = 0 но как ты понимаешь это является нарушением лицензионного соглашения 1С :) Ну и что с этого, спросишь ты меня. Да, ничего особенного, но эти действия позволили уменьшить размер нашей базы на 45 гигобайт! А также повысить скорость работы отчетов по продажам не десятки процентов. Все это сравнительно бесплатно и является безусловно "низко висящим фруктом". Одно действие приводит к огромной экономии дискового пространства, ускорению регламентного обслуживания базы и уменьшению времени выполнения отчетов. А у тебя есть оборотные регистры в конфигурации? :) Скажите, может я Америку открыл? Нигде не смог найти информацию о подобном поведении системы. Спасибо!

Коллеги, добрый день! Крутую штуку обнаружил, на выяснение которой ушло несколько рабочих дней: Условие: 1С:Предприятие 8.2 (8.2.15.319) размер ее составляет 230 Гб после шринка. есть документ РеализацияТоваров, в нем три строки и он сделал три движения по регистру ПродажиКомпании. Выполняю код, чтобы очистить движекния по данному регистру: 1С показывает, что у этого документа нет движений по данному регистру. НО ЭТО ВРАНЬЕ!!! Движения есть! Правда 1С про них ничего нам не говорит. Видимо скрывает, чтобы сберечь наши нервы. Лезу на скуле в оборотную таблицу этого регистра _AccumRgTn6629 и вижу эти строки, но с нулевыми ресурсами. Эти движения абсолютно не влияют на обороты так как все ресурсы у них - нулевые. И все бы ничего, но они занимают место не хуже обычных движений. Индексы на эту таблицу тоже значительно больше, чем без них. К счастью сама 1С удаляет эти строки с случае рестуктуризации таблиц регистра. В моем случае это случилось после смены типа измерения с ДокументСсылка на ДокументСсылка.ЗаказПокупателя почти случайно. Не все изменения структуры регистра приведут к реструктуризации, но именно эти приводят точно. Можно еще использовать такую нереграментированную штуку : delete from _AccumRgTn6629 where  _Fld6620 = 0 and _Fld6621 = 0 and _Fld6622 = 0 and _Fld7477 = 0 но как ты понимаешь это является нарушением лицензионного соглашения 1С :) Ну и что с этого, спросишь ты меня. Да, ничего особенного, но эти действия позволили уменьшить размер нашей базы на 45 гигобайт! А также повысить скорость работы отчетов по продажам не десятки процентов. Все это сравнительно бесплатно и является безусловно "низко висящим фруктом". Одно действие приводит к огромной экономии дискового пространства, ускорению регламентного обслуживания базы и уменьшению времени выполнения отчетов. А у тебя есть оборотные регистры в конфигурации? :) Скажите, может я Америку открыл? Нигде не смог найти информацию о подобном поведении системы. Спасибо!

[НО ЭТО ВРАНЬЕ!!! Движения есть! Правда 1С про них ничего нам не говорит. Видимо скрывает, чтобы сберечь наши нервы]

С нервами у меня порядок. Я надеюсь получить комментарии по теме.

Баянист. Как тебя подпускают к боевым конфам? Гораздо прикольнее, что такие фантомные записи могут повлиять на RLS :) И да, они не только в регистре оборотов, но и в накопления прут.

Таблицу итогов регистра накоплений еще глянь.. Инфаркт обеспечен

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

_AccumRgTn6629 Это итоги оборотов, к таблице движений не имеет отношения

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

прикольно

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

Да, я так и понял, что дешевле не удалять. Но в моем случае это привело к тому, что база содержит информацию, которая не используется системой (около 17% от размера базы это не шутки) и вредит быстродействию

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

Это рваный баян же, В таблицах ИТОГОВ не удаляются физически записи, ставится 0, только после пересчета итогов они уходят. Неприятные последствия РЛС может вызвать на эти регистры, данных вроде нет, а нарушение прав доступа

поминится в 81 подобный глюк был для регистров остатков

Пересчет итогов никак не исправляет фантомные записи ОБОРОТНОГО регистра. Т.е. он растет безконтрольно в процессе работы конфигурации.

это происходит именно при программной очистке регистра? И что это за очистка аж на 45 гигов?

не верю... как итоги пересчитываешь? из пофигуратора?

Сжатие данных там же делал?

Это происходит и при программном удалении через обработку и в случае удаления проведенного документа у которого стоит Удалять движения автоматически при проведении. Я проверил и был немало удивлен.

Ну хз. вроде ж нормальное поведение любой БД при удалениях всередине таблиц. А шринк мссюл это тоже что вакуум для постгреса? Если да, то неверится что шринк часть таких записей не уберет :(

Нет не по конфигуратору, а через предприятие. А есть разница? Шринк делал конечно же, но средствами скуля. Опять же есть разница?

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

Для скуля строки в таблицах с 0 не есть лишние записи, он их не сожмёт. А вот для 1с разница есть

Открытие века.... Ты еще глянь как удаление файлов происходит... Ты себе представь как удалять строки из середины таблицы! Сколько это займет времени?

Не уберет, конечно! С точки зрения скуля это АБСОЛЮТНО нормальные записи. Скуль же не знает, что записи с пустым набором всех ресурсов абсолютно бесполезны с прикладной точки зрения.

Да я не против, я только за! :) Меня волнует другой вопрос: каким регламентным заданием на обслуживание 1С я могу периодически избавляться от таких записей? Два способа я отразил в посте. Может кто-то знает более красивый вариант, о котором я не знаю?

в конфигураторе в ТИИ есть сжатие таблиц

Спасибо, за совет, действительно есть разница между SHRINK  и Сжатие таблиц в конфигураторе 1С?

есть, SHRINK FILE вобще свободное место просто освобождает

Кстати, задача стоит уменьшение размера базы данных не типовой КИС на основании УТ. Начал ее решать запуском скрипта, чтобы узнать какие объекты отъедают больше всего места:    CREATE TABLE #t([имя таблицы] varchar, [строк] varchar, [зарезервировано] varchar, [всего данных] varchar, [размер индексов] varchar, [свободно] varchar);        exec sp_msforeachtable N'exec sp_spaceused ''?''';        SELECT * FROM #t where [имя таблицы] like N'%RgTn%' ORDER BY CONVERT(bigint, REPLACE([всего данных], ' KB', '')) DESC;        DROP TABLE #t; в топе оказалась как раз оборотная таблица _AccumRgTn6629

лицензионное соглашение это как девочка на фронте в автосервисе, красивая, ухоженная, чай наливает. в гараже все немного иначе.

До удаления фантомных записей она занимала 54 гигабайта (оборотная таблица и индекс) или 83 миллиона записей. После удаления эта таблица стала весить 20 гигабайт или 34 миллиона записей.

улыбнуло, коллега

А зачем там ".Прочитать; .Очистить;"?

гигобайт, круто!

Для надежности. Я знаю, что хватает и Записать.

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

ТОгда нужно было еще и запрос сделать или удалять по каждой отдельной записи.

В конфигураторе пересчитать итогов?

> Пересчет итогов никак не исправляет Вот это странно и сомнительно

Коллега, это не по теме :)

закладка

Может все-таки есть разница между пересчитать итоги в конфигураторе и в предприятии? Тогда да - мы никогда не рассчитывали итоги в конфигураторе.

"Зачем в 1С нужно периодически пересчитывать итоги по регистрам?"

набросал

отлично коллега, я на это намекал в посте

Верно, но в статье говорится только про остатки. Но оборотный регистр хоть и имеет ту же самую проблему фантомных записей - имеет и свою специфику. А именно пересчет итогов для него не устраняет фантомный записи!

да проверь уже! на тощей базе. в пофигураторе Пересчет, потом сжатие там же

Проблема точно решается реструктуризацией таблицы. Вызывать из конфигуратора - слишком роскошно для меня. База большая и потребуется большое время для выполнение этой операции для всех таблиц - несколько суток точно. Есть более дешевый по времени вариант - вызвать реструктуризацию только таблицы проблемного регистра. Один из способов я описал в посте.

ща проверю на тестовой и отпишусь

> пересчет итогов для него не устраняет фантомный записи! Сложно в это поверить.

только что проверил - пересчет итогов через 1С Предприятие управление итогами - проблему НЕ РЕШАЕТ для оборотных регистров. Оно и так было понятно, так как мы это делаем каждый месяц - все бы давно обрезалось. Для регистров ОСТАТКОВ шлак исчезает. Сейчас запустил пересчитать итоги через конфигуратор. Жду.

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

В конфигураторе есть выбор? Неожиданно.

в конфигураторе пересчитывает абсолютно ВСЁ, выбрать нельзя

Задумался конфигуратор, что-то он другое делает по сравнению с пересчетом итогов в предприятии. Видимо разница в этих режимах все же есть. Ждем окончания, что же будет с фантомными записями? :)

Да тьфу на вас, навели панику. У меня нулевых записей оказалось 0.0001 % от общего числа.

меня тоже заинтересовало. жду вместе с тобой

Что ж они тебя так зацепили :)? Эта фигня еще с 7.7 тянется, там же на ДБФ еще удаленные записи справочников физически не удалялись.

да понятно что другое, минимум - за весь период считает итоги, а не за указанный, ну и фантомчики удаляет может в обротных. Тут я не уверен, возможно это сделает сжатие таблиц БД

ТИИ пересчет итогов тоже спасет. Но можно и в предприятии.

как это ты так быстро определил?

Обработкой прошелся по всем таблицам SQL

пересчет итогов и сжатие давно делали?

Можно обработку в студию?

Не поверишь, никогда не делали. На базе в почти 300гб не возникает такого желания :)

Да я сейчас тоже занимаюсь в плотную чисткой 150-ти гиговой базы, от помеченых на удаление, чистки регистров кривых, и этой темой тоже надо будет занятся

во-во у меня тоже нет желания. Единственно что делаем пересчет итогов в предприятии раз в месяц и шринк средствами скуля.

итоги пересчитай

абсолютно ценный совет, каждый считает своим долгом это тут сказать?)

не говори, коллега :)

"Я вот не трогаю Гондурас, он и не беспокоит" (с). Если прочитать про механизмы работы SQL серверов, то становится понятно почему так поступает 1С. Удалять и перестраивать индексы и статистику, освобождать память и страницы в он-лайне выходит ох, как затратно. У вас что уже место кончилось? или тормоза повылазили? Кароче, я бы световал не чесать "Гондурас".

ну нужно же помочь человеку ))

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

спасибо за обработку, думаю многим пригодится

спасибо за обработку. 0,17% (44 056/25 279 560) не критично)

Вопрос. А при выгрузке/загрузке через dt эти нулевые записи сохраняются?

Думаю, да, т.к. при загрузке итоги не пересчитываются

почти всё ТИИ происходит при загрузке выгрузке, думаю что удалятся

2 нет, не сохраняются

незнаю насчет сохранения нулевых записей, а про пересчет итогов при загрузке из dt задавал вопрос на V8@1c.ru, ответили - не пересчитываются

* но сам не проверял

да обработка проверил. регистр продажи записей 2 400 000. хотя смотрю записей через count(*) там 5 лямов... хыхы

+ обработка показывает наличие нулевых записей в основной таблице, а не в итогах. так что переделайте ее быстрее :)

Посмотрел код обработки - подтверждаю

переделать несложно

спасибо. не знала.

я проверял сравнивая размеры файловой версии базы. При загрузке из дт размер практически такой же. При ТИИ (все галки) в моем случае размер снизился на 25% процентов.

хм, а то что в клиент-серверной в конфигураторе ТИИ нет "Сжатие таблиц БД" кто замечал? всегда думал что есть...)

делай в скуле, будь мужиком

а это чтоб шринк не забывали делать

я к тому что значит только Пересчет итогов уберёт , была мысль что это сжатие сделает. Шринк скуля их не убирает

Уважаемые мегагуру специалисты, подскажите нормально что этот запрос столько выполняется ?? Объект = Хозрасчетный ИтогиПоСчетамССубконто4 Команда = SELECT COUNT(*) FROM _AccRgAT410090 Начало выполнения: 29.03.2013 15:36:56 Окончание выполнения: 29.03.2013 15:38:03

"Шринк скуля их не убирает" Ну это логично.. с его точки зрения это обычные строки таблиц, которые он обязан хранить, пока приложение не захочет ух удалять. То, что они хранят бесполезную информацию, известно на прикладном уровне, но на уровне хранения данных они вполне не пустые.

Всем большое спасибо за указание на ошибку, исправил. Действительно, в итогах много нулевых.

Осталось select заменить на delete и радоваться :)

Да у тебя там в найти косяк был только по основной таблице долбило )))