Можно ли удалять InventDim и InventSum без проводок?

[Zabr]

Можно ли смело удалять InventDim и InventSum без Inventtrans (в Ax 4.0) ? У меня из 10 млн. записей примерно 39% оказалось именно таких. Предполагаю, что это последствия массового создания и удаления заказов на покупку, по которым не обрабатывается затем никаких накладных. В InventDim используются только Склад и Размер.
Сам-то думаю, что можно. Но на всякий случай перестраховываюсь этим вопросом.

[Alexius]

Смело нельзя
InventDim необходимо проверить на связи еще по куче табличек
По InventSum не вижу препятствий

[Poleax]

Как удалить неиспользуемые InventDim

Чистим InventSum, потом Пересчет inventSum

[Zabr]

Цитата:

Сообщение от Poleax

Как удалить неиспользуемые InventDim

Первый InventDim проверяет уже 4 минуты. При нашем объеме - это примерно 80 лет чистого времени на проверку всей таблицы. Я не доживу.

[someOne]

Цитата:

Сообщение от Poleax

Как удалить неиспользуемые InventDim

Пробовал. Это никуда не годится. Только для малых объемов работоспособно.

Класс InventUnusedDimCleanUp - похоже, то что надо. По уму сделано.
Только у меня меню называется "Очистка складских аналитик", а не "Очистить не используемые складские аналитики"

Попробовал скрипт на демо базе.

Удалено 700 тыс записей из, почти, 4 млн. Все отработало минут за 15. Супер.
Вся нагрузка на сервере БД происходила...

[Zabr]

Цитата:

Сообщение от someOne

Класс InventUnusedDimCleanUp - похоже, то что надо.

Спасибо. Напрягает в нём только одно - сначала заполняется отдельная таблица всеми существующими InventDimid, причем она совсем не временная, как можно было бы предполагать. А у меня в InventDim >10 млн.записей. И еще это в одной транзакции.

updated: Работало около 1 часа, удалило 18% записей. Ожидал большего, но тоже неплохо.

[Geo]

Цитата:

Сообщение от Zabr

Спасибо. Напрягает в нём только одно - сначала заполняется отдельная таблица всеми существующими InventDimid, причем она совсем не временная, как можно было бы предполагать. А у меня в InventDim >10 млн.записей.

В книжке прочитал, что временные таблицы размещаются на клиенте. Если это так, то все >10 млн. записей ползали бы по сети, получается.

[glibs]

Цитата:

Сообщение от Geo

...временные таблицы размещаются на клиенте...

Неправда. Можно и на сервере создать.

[sukhanchik]

Цитата:

Сообщение от Geo

В книжке прочитал, что временные таблицы размещаются на клиенте. Если это так, то все >10 млн. записей ползали бы по сети, получается.

Временные таблицы размещаются там, где была вставлена в них 1-я запись. Т.е. необязательно на клиенте.

Но надо понимать - что временная таблица - суть есть файл на диске, причем на AOS-ном диске (в случае сервера; не говорю уже о клиенте), т.е. который в отличие от СУБД-шного диска (дисков) может быть гораздо менее шустрый. Плюс этот файл существует безо всяких там оптимизаций и обслуживания, которые есть у СУБД. Собственно - поэтому с т.з. производительности лучше создать временную таблицу в СУБД для большого объема данных.

[mazzy]

Цитата:

Сообщение от Zabr

updated: Работало около 1 часа, удалило 18% записей. Ожидал большего, но тоже неплохо.

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

только в этом случае не забудьте почистить inventSum от записей, которые ссылаются на удаленные InventDim.
вопрос изначально был поставлен совершенно корректно

[Zabr]

Цитата:

Сообщение от mazzy

исключите InventSum из проверки.

О, точно! Спасибо, так и сделал. Удалилось еще около 750 тыс.записей Inventdim, запускал в пакетном режиме, заняло 25 минут.
Нужно в метод isCandidateInventDimIdTable добавить строчку с InventSum:

protected boolean isCandidateInventDimIdTable(SysDictTable _sysDictTable)
{
    configurationKeyId  configurationKeyId = _sysDictTable.configurationKeyId();
    tableId             tableId = _sysDictTable.id();
    ;

    // The table should only be evaluated if it has not been marked for deletion, it is
    // not a temporary table and is not InventDim nor InventDimCleanUp
    if (configurationKeyId      == configurationkeynum(SysDeletedObjects40) ||
        configurationKeyId      == configurationkeynum(SysDeletedObjects41) ||
        _sysDictTable.isTmp()    == true                                     ||
        tableId                 == tablenum(InventDim)                       ||
        tableId                 == tablenum(InventSum)                      ||
        tableId                 == tablenum(InventDimCleanUp))
        return false;
    else
        return true;
}

[Zabr]

Цитата:

Сообщение от Zabr

Напрягает в нём только одно - сначала заполняется отдельная таблица всеми существующими InventDimid, причем она совсем не временная, как можно было бы предполагать.

Я имел в виду, что постоянная таблица увеличивает объем базы. Например, у меня она пустая занимает 125 Мб. Хотя в принципе это немного.

[mazzy]

Цитата:

Сообщение от Zabr

Первый InventDim проверяет уже 4 минуты. При нашем объеме - это примерно 80 лет чистого времени на проверку всей таблицы. Я не доживу.

э-э-э... рискну спросить.
вы джобик на клиенте запускали или на сервере?
чтобы запустить джобик на сервере, нужно создать menuItem, в нем указать ссылку на джобик и свойство RunOn = Server.

Цитата:

Сообщение от someOne

Пробовал. Это никуда не годится. Только для малых объемов работоспособно.

Вы ошибаетесь

Цитата:

Сообщение от someOne

Класс InventUnusedDimCleanUp - похоже, то что надо. По уму сделано.
Только у меня меню называется "Очистка складских аналитик", а не "Очистить не используемые складские аналитики"

Да, спасибо. Пополнил FAQ.

принципиальное отличие класса InventUnusedDimCleanUp от джобика:
= для каждого тестируемого поля в каждой тестируемой таблице класс делает один запрос по всем записям InventDim;
= для каждого тестируемого поля в каждой тестируемой таблице джобик делает запросы по каждому InventDim.

другие отличия скорее технологического характера:
= в классе отдельный connection - круто
= в классе используется более быстрый exist join, а в джобике count

есть и спорные "усовершенствования":
= в классе очень агрессивно делаются четыре skip'а (метод deleteUnusedInventDimIds). Я побоялся вставлять такие skip'ы в публичный ФАК - мало ли что у людей случится. Я думал, что знающие люди догадаются их вставить по месту и в зависимости от того, как у них накастомизировано. А незнающим - отсутствие skip'ов не навредит (а всего лишь замедлит работу).
= класс сейчас невозможно запустить "частями" и параллельно с работой остальных пользователей. Сейчас, в эпоху отсутствия блокировок на чтение это кажется полной фигней. Тогда, когда создавался джобик было важно не блокировать на чтение на слишком долго. Поэтому типичная доработка джобика выглядела так: цикл по InventDim прекращался, если было удалено 10, 20, 50, 100 inventDim'ов. а сам джобик вешался в пакетное задание и выполнял постоянный мониторинг и чистку (обычно вместе с чисткой InventSum(!)). при этом джобик не сильно нагружал систему.

Цитата:

Сообщение от someOne

Вся нагрузка на сервере БД происходила...

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

думал, что очевидная вещь. оказывается, ошибался.
Спасибо, дополнил ФАК.

[ice321i]

Можно попробовать Периодической операцией УЗ\Периодические операции\Очистка\Очистить не используемые складские аналитики, не знаю есть ли она в 4-ке, в 5-ке есть.

[Poleax]

Грех не добавить в тему ликну на статью База данных Аксапты быстро растет. Что делать?
Не совсем про InventDim и InventSum, но "как бы" по теме

[ice]

такой класс лучше запускать в пакете, прекрасно отработает на сервере. почистил где то 25% записей

[mazzy]

если хорошо подумать,
то ВНЕЗАПНО обнаружится, что InventSum зависит не только от inventTrans, но и от:
= заказов на продажу
= заказов на покупку
= заказов на перемещение
= заказов на производство
= складских журналов
= прогнозов
= сводного планирования
= проектов
= CRM
= ОС (как asset, так и rAsset)
= и т.п.

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

[S.Kuskov]

Цитата:

Сообщение от mazzy

InventSum зависит не только от inventTrans

То есть как? Нет зависит конечно, но ведь не напрямую, а как раз таки через InventTrans. Или я чего-то не понял?

[mazzy]

Цитата:

Сообщение от S.Kuskov

То есть как? Нет зависит конечно, но ведь не напрямую, а как раз таки через InventTrans. Или я чего-то не понял?

напрямую.
Ожидается приход, Ожидается расход, Зарезервировано в ожидаемом расходе.

не, я тормоз.
да, из проводок.

да, inventSum можно удалить, посмотрев только в InventTrans.
спасибо.

[petr]

Кто-нибудь пробовал использовать класс InventUnusedDimCleanUp в четверке? Я имею ввиду экспортировать из 2009, импортировать в четверку и запустить?

Работает?
Были ли замечены какие-либо подводные камни?