AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.01.2011, 09:55   #1  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Еще раз о переименовании номенклатуры (ItemID).
Доброго времени суток!

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

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

Может имеет смысл написать идентичный запрос, тупо скопировав все запросы из профайлера, и запустив его на сиквеле?
Фокус в том, что все запросы сверху объединены общей транзакцией для отката, и даже если в данный момент процесс переименования не апдейтит таблицу в которую вносят данные пользователи, но она в общем списке таблиц на переименование, пользователи блокируются и ждут.
Как бы блокировать пользователей только в пределах одной – трех таблиц?
__________________
Axapta 3.0 SP6
Старый 28.01.2011, 10:05   #2  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
если компания не работает в режиме 24х7, то запустите когда пользователей нет или их количество минимально
Старый 28.01.2011, 10:10   #3  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Цитата:
Сообщение от ice Посмотреть сообщение
если компания не работает в режиме 24х7
Именно так и работаем, еще и ругаются на перезагрузки АОСа.
Им нужна Аксапта 25 часов в сутки
__________________
Axapta 3.0 SP6
Старый 28.01.2011, 10:12   #4  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
а 1,5 - 2 часа на 1 номенклатуру?
Старый 28.01.2011, 10:16   #5  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Цитата:
Сообщение от ice Посмотреть сообщение
а 1,5 - 2 часа на 1 номенклатуру?
Да. Причем по вновь созданной приближается к 2 часам
__________________
Axapta 3.0 SP6
Старый 28.01.2011, 10:21   #6  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
а если создать индексы по ItemId(и другим обновляемым полям) временно для обновления, может получится быстрее?
Старый 28.01.2011, 10:28   #7  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Цитата:
Сообщение от ice Посмотреть сообщение
а если создать индексы по ItemId(и другим обновляемым полям) временно для обновления, может получится быстрее?
Согласен. НО сам процесс создания индексов, тоже подвешивает пользователей. ВИЛКА Можно, конечно, разок помучить пользователей и оставить индексы навсегда, но тогда все инсерты будут подтормаживать.
__________________
Axapta 3.0 SP6
Старый 28.01.2011, 10:34   #8  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Я бы пошёл с таким раскладом по времени к постановщику задачи и задал ему вопрос - стоит ли переименование первичного ключа таких затрат.
Вообще - если переименование нужно только для упрощения процесса поиска, то я бы поступил по другому - занёс бы правильные коды в NameAlias джобом и добавил это поле в группу AutoLookup. Тогда пользователь сможет быстро найти номенклатуру и по старому, и по новому коду. А уж само переименование (если действительно без него никак) делать не торопясь и в пономенклатурной транзакции.
__________________
С уважением,
Вячеслав
Старый 28.01.2011, 10:40   #9  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Если такой напряженный график, то лучше всего делать переименование с помощью прямых SQL запросов:
1. Создаете таблицу переименования (старый код, новый код)
2. На всякий случай желательно покопаться в функционале, может какие-нибудь таблички не попали в штатное изменение первичного ключа (например может не попасть прайс, правда я не проверял)
3. Создаете запросы на основании лога профайлера по нужным компаниям и п.2
4. Выгоняем пользователей
5. Прогоняем сформированные запросы (время выполнения ориентировочно меньше 2 часов)
6. Разглядываем последствия
7. Продолжаем работу в АХ

Если время простоя 2 часа (или какое покажет тест) неприемлемо, то можно вместо п. 4:
4.1 Создать (скопировать) новую номенклатуру с правильными кодами
4.2 Заблокировать вновь созданную и предназначенную к переименованию
Далее прогоняем последовательно запросы, каждый в своей транзакции. Это может быть дольше, т.к. их могут заблокировать пользователи и нужно будет постоянно отслеживать процесс и "отстреливать" пользователей мешающих переименованию.
Старый 28.01.2011, 10:44   #10  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от kostass Посмотреть сообщение
Можно, конечно, разок помучить пользователей и оставить индексы навсегда, но тогда все инсерты будут подтормаживать.
Торможение инсертов будет копеечным, т.к. АХ подавляющее кол-во операций вставки/удаления делает по одной записи. Зато можно выиграть а дальнейшем на операциях выборки, а можно и не выиграть Основной минус дополнительных индексов в АХ - рост БД.
Старый 28.01.2011, 10:47   #11  
ice is offline
ice
Участник
Аватар для ice
Лучший по профессии 2014
 
1,689 / 405 (17) +++++++
Регистрация: 23.03.2006
Цитата:
Сообщение от Alexius Посмотреть сообщение
Торможение инсертов будет копеечным, т.к. АХ подавляющее кол-во операций вставки/удаления делает по одной записи. Зато можно выиграть а дальнейшем на операциях выборки, а можно и не выиграть Основной минус дополнительных индексов в АХ - рост БД.
в случае существенного торможения, индексы легко выключаются в АОТ
Старый 28.01.2011, 11:02   #12  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
to pitersky
Да вариант, спасибо.

Цитата:
Сообщение от Alexius Посмотреть сообщение
4.2 Заблокировать вновь созданную и предназначенную к переименованию
Подскажите как поставить эту блокировку.

Цитата:
Сообщение от Alexius Посмотреть сообщение
Это может быть дольше
Мое время не важно, главное сократить время простоя пользователей.
__________________
Axapta 3.0 SP6
Старый 28.01.2011, 11:08   #13  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Цитата:
Сообщение от Alexius Посмотреть сообщение
Зато можно выиграть а дальнейшем на операциях выборки, а можно и не выиграть
Мы сейчас взяли курс на оптимизацию текущей работы (инсертов), а с отчетами пусть ждут.

Цитата:
Сообщение от Alexius Посмотреть сообщение
Основной минус дополнительных индексов в АХ - рост БД.
197 Гиг, но это решаемо другими способами.
__________________
Axapta 3.0 SP6
Старый 28.01.2011, 11:21   #14  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от kostass Посмотреть сообщение
Подскажите как поставить эту блокировку.
УЗ / Номенклатурные единицы / Количество - три поля Блокировано
Старый 28.01.2011, 11:24   #15  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Цитата:
Сообщение от pitersky Посмотреть сообщение
Я бы пошёл с таким раскладом по времени к постановщику задачи и задал ему вопрос - стоит ли переименование первичного ключа таких затрат.
Обязательно!

Цитата:
Сообщение от pitersky Посмотреть сообщение
А уж само переименование (если действительно без него никак) делать не торопясь и в пономенклатурной транзакции.
Все так. Я и планировал по 1 номенклатуре в день. Или все скопом в праздничный день. Но пока, требования в реальном времени.
__________________
Axapta 3.0 SP6
Старый 28.01.2011, 11:25   #16  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Цитата:
Сообщение от Alexius Посмотреть сообщение
УЗ / Номенклатурные единицы / Количество - три поля Блокировано
Ага, нашел, спасибо.
__________________
Axapta 3.0 SP6
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Себестоимость номенклатуры Silphidae DAX: Программирование 4 30.08.2010 15:38
lookup для ItemId iz InventTable + InventDim + InventSum stalker25 DAX: Программирование 6 20.07.2009 15:50
Планирование номенклатуры с типом Основное средство AlexeyBP DAX: Функционал 19 29.01.2009 07:42
Импорт списка номенклатуры Роман Кошелев DAX: База знаний и проекты 2 15.06.2006 16:52
Остатки номенклатуры Def DAX: Программирование 16 16.11.2005 16:12
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:56.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.