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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.07.2008, 15:34   #141  
Didukh84 is offline
Didukh84
Участник
 
57 / 10 (1) +
Регистрация: 09.06.2006
Цитата:
Сообщение от Vadik Посмотреть сообщение
Только вот.. Didukh84, Вы УВЕРЕНЫ, что Вам надо запускать эту процедуру? У Вас RecId перескочил за maxint() или Вы таким образом пытаетесь какие-то другие проблемы?
У меня значение RecId - "-1804886437". Т.е. рано или поздно придется процедуру делать . Не охота, чтобы она застала врасплох .
Да, запустил еще раз проверку кодов то через 4-о суток оно сделалось!!! Значение RecId стало "140568244" :-) (правда я запускал перед этим еще реиндексацию зачем-то :-( )
__________________
Жить все веселей!.. AX3SP3CU1
Старый 23.07.2008, 16:10   #142  
Didukh84 is offline
Didukh84
Участник
 
57 / 10 (1) +
Регистрация: 09.06.2006
Цитата:
Сообщение от mazzy Посмотреть сообщение
Какие таблицы самые большие?
Можете привести данные отчета "Disk usage by top tables" или аналогичного?
.
привожу
Вложения
Тип файла: xls TableSpace.xls (113.0 Кб, 179 просмотров)
__________________
Жить все веселей!.. AX3SP3CU1
Старый 14.10.2008, 11:49   #143  
coolibin is offline
coolibin
Участник
 
264 / 68 (3) ++++
Регистрация: 07.04.2005
LedgerTrans.BondBatchTrans_RU
У меня вопрос знатокам по поводу поля LedgerTrans.BondBatchTrans_RU. У поля тип RefRecId, но как я понял ни на какой живой RecId он не ссылается. Вопрос, что будет с содержимым этого поля при выполнении дефрагментации RecId? Ведь новые номера в таблице AXOLDTONEWRECIDS сгенерятся не для всех его значений, а апдейт будет все равно запускаться.
Старый 14.10.2008, 13:35   #144  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
С ними будет то же самое, что будет в полях, которые таки ссылаются на другие записи по RecId. Т.е. если у вас запись ссылается на другую запись по RecId, но записи с таким RecId не существует, то ссылка по RecId не обновляется. После реиндексации она может начать ссылаться на какую-то другую (уже существующую) запись. Тут будет точно так же. Но в данном конкретном случае, по-моему, это не страшно.
__________________
С уважением,
glibs®
Старый 14.10.2008, 14:17   #145  
coolibin is offline
coolibin
Участник
 
264 / 68 (3) ++++
Регистрация: 07.04.2005
Цитата:
Сообщение от glibs Посмотреть сообщение
Т.е. если у вас запись ссылается на другую запись по RecId, но записи с таким RecId не существует, то ссылка по RecId не обновляется.
На это очень хотелось бы надеяться, но у меня есть сомнения.
Смотрим код. Там в частности для оракла генерится оператор вида:

UPDATE table set field = NEWRECID FROM AXOLDTONEWRECIDS WHERE OLDRECID=table.field

Допустим, в AXOLDTONEWRECIDS не всегда есть подходящая запись, UPDATE вообще не отработает или запишет пусто?
Версия 3.
Старый 14.10.2008, 14:32   #146  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Для table.field, которым нет соответствия в AXOLDTONEWRECIDS, ничего не изменится
__________________
Axapta v.3.0 sp5 kr2
За это сообщение автора поблагодарили: coolibin (1).
Старый 23.12.2009, 15:22   #147  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Изучаю метод \Classes\SysRecIdRepair\mainLoop.

И что-то возникло смутное беспокойство - а транзакция-то где? Самая главная, в которой выполняются все эти executeUpdate? Или она неявно обеспечивается существованием объекта Connection, который в new инициализируется?

Развеивателям беспокойства - заранее спасибо!
Старый 23.12.2009, 15:39   #148  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Нэту... У объекта Connection есть методы ttsbegin(), ttscommit() - вот они и должны стоять (именно у этого экземпляра)... Все остальные tts-ы не имеют к этому коду никакого отношения.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: Gustav (2).
Старый 23.12.2009, 16:28   #149  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Там нет транзакции. Более того, пересчет нужно запускать только в "монопольном" режиме. А то все развалится.

Насколько я понимаю, транзакция подсадит производительность. Я перед пересчетом предпочитаю сделать бэкап базы, перевести ее в "simple recovery mode", а потом вернуть обратно. Если что не получится — гораздо быстрее и безопаснее откатиться в начало из бэкапа. А запись лога отнимет ресурсы и потребует прилично места на диске.
__________________
С уважением,
glibs®
За это сообщение автора поблагодарили: Gustav (2).
Старый 23.12.2009, 16:31   #150  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Нэту...
Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации, ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!.. И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?
Цитата:
Сообщение от glibs Посмотреть сообщение
Я перед пересчетом предпочитаю сделать бэкап базы, перевести ее в "simple recovery mode", а потом вернуть обратно. Если что не получится — гораздо быстрее и безопаснее откатиться в начало из бэкапа.
Логично! И лучше, чем я предположил.

Последний раз редактировалось Gustav; 23.12.2009 в 16:37.
Старый 23.12.2009, 16:42   #151  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Gustav Посмотреть сообщение
Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации, ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!.. И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?
Да - именно так. Причем после дефрагментации имеет смысл бегло просмотреть сохранность функциональности (Типа пару-тройку часов побегать по интерфейсу и потыкать в наиболее популярные ДОРАБОТКИ). Просто если кто-то в таблицах создал ссылку по recId, а расширенный тип для этой ссылки забыл отнаследовать от recId или refRecId, то при дефрагментации связь потеряется. То есть - конечно в стандартном функционале таких граблей нету, но я лично лет 7 назад забыл повесить правильный extended type на поле со ссылкой. И узнали мы об этом только тогда после дефрагментации recId, когда у нас пропала связь шапок авансовых отчетов с какой-то полезной дополнительной таблицей.

Так что рекомендую дефрагментацию ставить в ночь с пятницы на субботу, в субботу приходить на работу и смотреть что получилось. Ну а если не получилось - откатываться до бэкапа на пятничный вечер.
За это сообщение автора поблагодарили: Gustav (2).
Старый 23.12.2009, 16:48   #152  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Gustav Посмотреть сообщение
Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации
А какая разница, когда тетя Клава дергает провод - во время регламентных мероприятий или в середине рабочего дня?
Цитата:
ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!..
Мы имеем (должны иметь) бэкап (протестированный, лучше - несколько на разных носителях)
Цитата:
И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?
Отключение пользователей, бэкап рабочей БД, тестирование бэкапа, дефрагментация
P.S. Попробуйте (на тестовом инстансе!) завернуть дефрагментацию в транзакцию и посмотрите, что происходит в это время с transaction log ( undo / redo ). Теперь попробуйте прервать эту транзакцию на середине. Теперь представьте, что у Вас каждую минуту звонит телефон "ну когда уже можно будет зайти". Вариант с полным бэкапом покажется не таким уж и страшным
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: Gustav (2).
Старый 29.03.2010, 16:04   #153  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Провожу сейчас исследование на тему дефрагментации, поскольку RecID уже за -1.6 млрд перевалил. Что обнаружил, применимо к Oracle -
строка 103, mainLoop -
X++:
this.executeUpdate('CREATE TABLE AXOLDTONEWRECIDS (OLDRECID NUMERIC(12), NEWRECID NUMERIC(12), CONSTRAINT PK_AXOLDTONEWRECIDS PRIMARY KEY (OLDRECID)) ORGANIZATION INDEX');
убрав слова "ORGANIZATION INDEX" - получил уменьшение времени расчета с 2 СУТОК до 2 ЧАСОВ!
Собственно CONSTRAINT PK_AXOLDTONEWRECIDS ИМХО можно безболезненно убрать!
За это сообщение автора поблагодарили: Logger (5), gl00mie (3).
Старый 20.08.2010, 13:46   #154  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Недавно вместе с одним из пожелавших остаться неизвестным участников "отдефрагментировали" RecId :

Вводная:
- Несколько (порядка 10) компаний, три крупных
- Одна виртуальная компания
- Максимальный RecId 1843756363
- Размер БД около 280Гб (SQL Server 2008)

Проблемы:
- основная, разумеется, размер БД и ограниченное временное окно на выполнение процедуры
- стандартный механизм обладает некоторыми "особенностями":
- при запуске по всем компаниям компаний эффект "сжатия RecId" может снижаться или полностью отсутствовать
- при запуске по одной компании неправильно делается обновление ссылок по RecId на таблицы в виртуальных компаниях и "общие" (SaveDataPerCompany=No) таблицы
- хотелось хранить историю маппинга "старых" и "новых" значений RecId для разбора непредвиденных проблем

Как обходили:
- модифицирован класс SysRecRepair, добавлен небольшой фреймворк для регистрации "проблемных" ссылок (описание "проблемных" ссылок см. выше, определение ссылок делается вручную)
- исключили (средствами фреймворка) из обработки некоторые большие "непостоянные" таблицы (SysDatabaseLog, SysUserLog, xRef)
- переконфигурировали некоторые параметры БД на время обработки (отключение RCS, auto update statistics и пр.)
- настроили partitioning по DataAreaId
- временно удалили некластерные индексы с RecId на таблицах, где их более одного
- сохраняем временную таблицу маппинга "старых" значений RecId на "новые"

Результат:
- Количество обработанных записей по всем компаниям - 2850036022
- Максимальный RecId - 180862996 (сжатие приблизительно в 10 раз, благо были достаточно большие "дырки" в выделенных RecId)
- Вся процедура заняла около 12 часов, из них работа класса SysRecIdRepair около 7 часов.

Ограничения:
- Анализ имеющихся проблемных ссылок по RecId в виртуальные компании не автоматизирован (выполняется вручную)
- Версии для Oracle нет (пока)
- Обработка нескольких виртуальных компаний есть, но не протестирована

Код не выкладывается (по крайней мере пока), воспринимайте данный пост как некий whitepaper плюс "тестовый забег"

P.S. - в "простых" случаях (одна компания) стандартный механизм работает корректно
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: gl00mie (3).
Старый 08.12.2010, 14:17   #155  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Также см. альтернативный подход от Gustav
__________________
-ТСЯ или -ТЬСЯ ?
Старый 22.12.2010, 16:50   #156  
DPO is offline
DPO
Участник
 
19 / 10 (1) +
Регистрация: 24.09.2007
Коллеги, привет. На форуме не нашел, поэтому пишу здесь.

Есть значит у нас большая база на тройке. Делали дефрагментацию, временно помогла. Но только временно. По прогнозам на следующий год RecId не хватит даже с учетом дефрагментации, что печально. Компания переходит на САП, поэтому переход на новую версию аксапты есть не самый лучший способ избавления от проблемы RecId. Проблема в том, что проект по внедрению САПа может затянуться, а рекайди все растут..

Поэтому был предложен альтернативный вариант спасения аксапты.
Если кратко, то он заключается в том, чтобы сделать RecId уникальными потаблично, а не во всей системе. Делается это конечно же не автоматически, а ручками с помощью дефрагментации и укладывания таблиц ровными слоями начиная с некоторого значения (например с 1). То есть например раз в квартал можно запускать дефрагментацию, в результате которой (а таблицы будут лежать параллельно!) масимальное значение RecId будет равно количеству записей в наибольшей таблице и затем уменьшать счетчик RecId. Вот такое временное решение.

Понятно, что это грозит нам возможными переписываниями кода с таблицей SpecTrans и проими, в которых хранятся ссылки на RecId нескольких таблиц. Так же возможны проблемы с уникальными индексами по подобым полям-ссылкам на RecId. Но все это на мой взгляд вполне побеждаемо. Подскажите пожалуйста, кто-нибудь так делал? Не видите ли вы неразрешимых проблем в этой схеме?
Старый 23.12.2010, 10:52   #157  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Если вы все равно переходите на SAP, то, может, рассмотреть вариант с усечением базы? Вы же явно не будете тащить в SAP все исторические данные - только справочники и сальдовки...
Старый 23.12.2010, 11:09   #158  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Поддерживаю. Я бы в данной ситуации почистил данные, которые не нужны, но которые очень жалко выбросить, а затем дефрагментировал бы RecId.

Подходы к чистке данных могут быть различными. Как вариант можно подумать над архивированием, но это нетривиально.
__________________
С уважением,
glibs®
Старый 23.12.2010, 12:58   #159  
DPO is offline
DPO
Участник
 
19 / 10 (1) +
Регистрация: 24.09.2007
Да, извиняюсь, что сразу не рассказал.

У нас будет старт с чистого листа в эту замечательную новогоднюю ночь, видимо то, что вы имеете ввиду под архивированием. То есть текущая база станет архивной, а в новую боевую перенесутся справочники, всяческие остатки и работа начнется в чистой базе.
Проблема в том, что RecId могут переполниться даже за год! В прошлый раз подобная процедура архивирования выполнялась 2 года назад. До этого нового года дотянули со скрипом и дефрагментацией. По прогнозам на следующий год планируется увеличение отгрузок в системе. При таком росте до следующего нового года мы дотягиваем, а вот до 2013 уже нет (хотя там может и не важно, в 2012 году-то ).
Делать процедуру рхивирования чаще раза в год не вариант из-за проблем с годовой отчетностью и общей ее геморойностью. Поэтому рассматриваем такой экстремальный способ спасения.

Что думаете на этот счет? В сравнении например с переходом на новую версию?
Старый 23.12.2010, 15:19   #160  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от DPO Посмотреть сообщение
Что думаете на этот счет?
Бизнес, генерящий столько транзакций, чтобы переполнить диапазон RecId (4 миллиарда записей) за год, причем на 3.0 - как-то слабо верится. Логистика к примеру в трешке такого не вытянет, разве что самописный модуль какой-то
Либо чего-то Вы не договариваете, либо что-то не то считаете, либо как-то не так дефрагментируете (imho)
Каков текущий размер БД (в терабайтах, я полагаю) ?
__________________
-ТСЯ или -ТЬСЯ ?
Теги
ax3.0, faq, recid, дефрагментирование recid

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
if (record) vs if (record.RecId) kashperuk DAX: Программирование 18 27.11.2008 18:53
поля, содержащие RecId somebody DAX: Программирование 15 16.05.2008 17:50
aEremenko: Дефрагментация RecID Blog bot DAX Blogs 2 06.03.2007 22:25
Два RecId у одной записи таблицы sparur DAX: Программирование 33 18.12.2006 15:56
Форма InventOnhandItem, Почему RecID у InventSum в этой форме всегда 0? Кирилл DAX: Программирование 2 25.05.2004 18:15
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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