Еще раз о переименовании номенклатуры (ItemID).

[kostass]

Доброго времени суток!

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

Я снял трассировку переименования ItemID с помощью профайлера сиквела. Длительность процесса переименования колебалась в пределах 1 час 20 минут - 2 часа. Снял трассировку переименования вновь созданной номенклатуры, те же временные показатели. Все трассировки снимал в монопольном режиме на тестовой системе, т.е. в базе работал только один пользователь. В итоге: обрабатывается 164 запроса по 141 таблице.
Проблема в том, что номенклатурный справочник привязан к виртуальной компании, а в ней объединено 7 компаний, поэтому апдейты по большинству таблиц обрабатываются по 7 раз (в каждой компании). Итого 914 запросов, конечно, из них есть 49 самописных таблиц . При запуске в рабочей системе процесс переименования блокирует пользователей.

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

[ice]

если компания не работает в режиме 24х7, то запустите когда пользователей нет или их количество минимально

[kostass]

Цитата:

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

если компания не работает в режиме 24х7

Именно так и работаем, еще и ругаются на перезагрузки АОСа.
Им нужна Аксапта 25 часов в сутки

[ice]

а 1,5 - 2 часа на 1 номенклатуру?

[kostass]

Цитата:

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

а 1,5 - 2 часа на 1 номенклатуру?

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

[Alexius]

Если такой напряженный график, то лучше всего делать переименование с помощью прямых SQL запросов:
1. Создаете таблицу переименования (старый код, новый код)
2. На всякий случай желательно покопаться в функционале, может какие-нибудь таблички не попали в штатное изменение первичного ключа (например может не попасть прайс, правда я не проверял)
3. Создаете запросы на основании лога профайлера по нужным компаниям и п.2
4. Выгоняем пользователей
5. Прогоняем сформированные запросы (время выполнения ориентировочно меньше 2 часов)
6. Разглядываем последствия
7. Продолжаем работу в АХ

Если время простоя 2 часа (или какое покажет тест) неприемлемо, то можно вместо п. 4:
4.1 Создать (скопировать) новую номенклатуру с правильными кодами
4.2 Заблокировать вновь созданную и предназначенную к переименованию
Далее прогоняем последовательно запросы, каждый в своей транзакции. Это может быть дольше, т.к. их могут заблокировать пользователи и нужно будет постоянно отслеживать процесс и "отстреливать" пользователей мешающих переименованию.

[kostass]

to pitersky
Да вариант, спасибо.

Цитата:

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

4.2 Заблокировать вновь созданную и предназначенную к переименованию

Подскажите как поставить эту блокировку.

Цитата:

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

Это может быть дольше

Мое время не важно, главное сократить время простоя пользователей.

[Alexius]

Цитата:

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

Подскажите как поставить эту блокировку.

УЗ / Номенклатурные единицы / Количество - три поля Блокировано

[ice]

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

[kostass]

Цитата:

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

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

Согласен. НО сам процесс создания индексов, тоже подвешивает пользователей. ВИЛКА Можно, конечно, разок помучить пользователей и оставить индексы навсегда, но тогда все инсерты будут подтормаживать.

[Alexius]

Цитата:

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

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

Торможение инсертов будет копеечным, т.к. АХ подавляющее кол-во операций вставки/удаления делает по одной записи. Зато можно выиграть а дальнейшем на операциях выборки, а можно и не выиграть Основной минус дополнительных индексов в АХ - рост БД.

[ice]

Цитата:

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

Торможение инсертов будет копеечным, т.к. АХ подавляющее кол-во операций вставки/удаления делает по одной записи. Зато можно выиграть а дальнейшем на операциях выборки, а можно и не выиграть Основной минус дополнительных индексов в АХ - рост БД.

в случае существенного торможения, индексы легко выключаются в АОТ

[kostass]

Цитата:

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

Зато можно выиграть а дальнейшем на операциях выборки, а можно и не выиграть

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

Цитата:

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

Основной минус дополнительных индексов в АХ - рост БД.

197 Гиг, но это решаемо другими способами.

[pitersky]

Я бы пошёл с таким раскладом по времени к постановщику задачи и задал ему вопрос - стоит ли переименование первичного ключа таких затрат.
Вообще - если переименование нужно только для упрощения процесса поиска, то я бы поступил по другому - занёс бы правильные коды в NameAlias джобом и добавил это поле в группу AutoLookup. Тогда пользователь сможет быстро найти номенклатуру и по старому, и по новому коду. А уж само переименование (если действительно без него никак) делать не торопясь и в пономенклатурной транзакции.

[kostass]

Цитата:

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

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

Обязательно!

Цитата:

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

А уж само переименование (если действительно без него никак) делать не торопясь и в пономенклатурной транзакции.

Все так. Я и планировал по 1 номенклатуре в день. Или все скопом в праздничный день. Но пока, требования в реальном времени.