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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.12.2010, 16:09   #161  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 901 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от DPO
...
Проблема в том, что RecId могут переполниться даже за год!
...
По прогнозам на следующий год RecId не хватит даже с учетом дефрагментации
...
За счет чего вам удается этого добиться? У вас все 4 с хвостиком миллиарда записей в БД хранятся? В каких таблицах?

Под архивированием я имел в виду удаление из БД данных за старые периоды, которые штатно можно удалять. А если они нужны для статистики, то смещать их в другую БД, по которой строить OLAP отчетность, а в рабочей БД данные чистить.

Но если у вас 4 миллиарда записей за год заполняются, причем не мусором, то такой вариант вам не подойдет.
__________________
С уважением,
glibs®
Старый 23.12.2010, 16:13   #162  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
367 / 410 (14) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Цитата:
Сообщение от DPO Посмотреть сообщение
Проблема в том, что RecId могут переполниться даже за год!
Как тут уже правильно заметили дело скорее всего в алгоритмах постоянно генерящих данные, которые живут недолго и снова и снова пересчитываются (какой нито самодельный модуль или сводное планирование). Если это реально так, то надо сделать ручное заполнение RecId из отдельного нумератора (сделать его на классе SystemSequence) для "полувременных" таблиц

SystemSequence позволяет создавать свои нумераторы на основе того же механизма что используется для RecId и TransId

Пример могу дать, но попозже

Последний раз редактировалось db; 23.12.2010 в 16:16.
Старый 23.12.2010, 16:33   #163  
DPO is offline
DPO
Участник
 
19 / 10 (1) +
Регистрация: 24.09.2007
И все таки он существует. Да, бизнес генерит много RecId.
На данный момент за месяц счетчик RecId увеличивается на 250 000 000 в месяц. Из них примерно 160 000 000 - существующие записи, остальное - пустоты в RecId. Для комфортного существования системы в течение 14 месяцев без экстренной дефрагментации на грани, скорость потребления RecId быть меньше чем 4 200 000 000 / 14 = 300 000 000 RecId в месяц, что в условиях растущего количества отгрузок может быть достигнуто достаточно быстро, уже в следующем году, а дальше - больше. Взял 14 месяцев потому что архивирование базы предполагает закрытие года в старой (архивной) базе, это с запасом.
То есть проблемы есть, не обманываю я вас.

Проблемы с производительностью тоже есть, но в следующем году их планируется решить переходом на новое оборудование и новый оракл. Понятно, что тройка с ее узким местом в inventSum`е помрет и на самом производительном железе. Продление жизни бизнеса на аксцапте 3.0 описанным выше способом рассматривается только как временная мера до перехода на САП.

Поэтому, коллеги, помогите чем можите. Хотелось бы услышать ваше мнение о реализации потабличного RecId с помощью дефрагментации.
Старый 23.12.2010, 16:52   #164  
DPO is offline
DPO
Участник
 
19 / 10 (1) +
Регистрация: 24.09.2007
Цитата:
Сообщение от glibs Посмотреть сообщение
За счет чего вам удается этого добиться? У вас все 4 с хвостиком миллиарда записей в БД хранятся? В каких таблицах?
На данный момент у нас не 4 миллиарда с хвостиком, а примерно 2.5. Хранятся в основном в транзакционных таблицах InventTrans, InvetnTransPosting, LedgerTrans и тд.
Цитата:
Сообщение от glibs Посмотреть сообщение
Но если у вас 4 миллиарда записей за год заполняются, причем не мусором, то такой вариант вам не подойдет.
Пока только 2.5 заполняются, но да, не мусором. Через год по прогнозам вполне вероятно и 4. От этого немусора за старые периоды избавляемся, но не чаще раза в год.
Старый 23.12.2010, 17:05   #165  
DPO is offline
DPO
Участник
 
19 / 10 (1) +
Регистрация: 24.09.2007
Цитата:
Сообщение от db Посмотреть сообщение
Как тут уже правильно заметили дело скорее всего в алгоритмах постоянно генерящих данные, которые живут недолго и снова и снова пересчитываются (какой нито самодельный модуль или сводное планирование).
Сводного планирования нет. Самописные модули есть, генерят в районе 15% RecId в системе.

Цитата:
Сообщение от db Посмотреть сообщение
Если это реально так, то надо сделать ручное заполнение RecId из отдельного нумератора (сделать его на классе SystemSequence) для "полувременных" таблиц
Очень интересно. Не понял, почему так можно делать только для "полувременных" таблиц. Почему тоже самое нельзя сделать с остальными?

Цитата:
Сообщение от db Посмотреть сообщение
Пример могу дать, но попозже
Хотелось бы примерчик. Буду очень-очень благодарен!
Старый 23.12.2010, 17:22   #166  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 901 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Скорость, с которой вы заполняете БД, впечатляет. С учетом того, что вы даже склад не закрываете (а то бы у вас InventSettlement был бы в числе больших таблиц). То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках. Но здесь развивать эту тему с учетом ваших планов не целесообразно.

Я помню идею заталкивать отдельные таблицы в виртуальные компании. Я над ней не думал из-за того, что это путь в тупик. Но если вы скоро спрыгнете на САП, то стоит и ее рассмотреть (ломать — так ломать). Но это если ваш функционал может адекватно работать с виртуальными компаниями.
__________________
С уважением,
glibs®
Старый 23.12.2010, 17:55   #167  
DPO is offline
DPO
Участник
 
19 / 10 (1) +
Регистрация: 24.09.2007
Цитата:
Сообщение от glibs Посмотреть сообщение
То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках.
Да, предлагаю на этом не зацикливаться. Но если не трудно, объясните или ткните в доку, интересно чем плохо такое соотношение записей в этих таблицах.

Цитата:
Сообщение от glibs Посмотреть сообщение
Я помню идею заталкивать отдельные таблицы в виртуальные компании. Я над ней не думал из-за того, что это путь в тупик. Но если вы скоро спрыгнете на САП, то стоит и ее рассмотреть (ломать — так ломать). Но это если ваш функционал может адекватно работать с виртуальными компаниями.
У нас отключены компании (-INTERNAL=NODATAAREAID). Так сложилось еще до меня, из-за производительности. Я тоже не рассматривал этот вариант потому как производительность у нас не на высоте. Но все равно спасибо, подумаю в эту сторону.
Старый 23.12.2010, 19:38   #168  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
367 / 410 (14) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Обещанный пример "самодельных" RecId для 3.0
В вложении проект с парой классов и джобом

джоб также повторю здесь
X++:
static void recIdExtraTest(Args _args)
{
    mSequence_RecIdExtra    seq = new mSequence_RecIdExtra();
    RecIdExtraTest          recIdExtraTest;
    int                     i;
    ;
    // эта строка запрещает для таблицы раздачу стандартных RecId
    // должна быть выполнена до начала пользования новым нумератором
    // например можно поместить в appl.startupPost()
    new SystemSequence().suspendRecIds(tablenum(RecIdExtraTest));
    
    
    for (i = 1; i <= 1000; i++)
    {
        // Раздача самодельных RecId
        recIdExtraTest.(fieldnum(Common, RecId)) = seq.value();
        recIdExtraTest.insert();
    }
}
Если перекрывать insert() и писать код по присвоению RecId в нем, то имеет смысл сделать singleton для mSequence_RecIdExtra поместив его в GlobalCache или непосредственно в Applicаtion

Присвоение RecId только вручную. Возможности глобально сказать что для таких то таблиц брать RecId из нового нумератора нельзя (даже перекрыв insert() могут остаться вызовы doInsert() и вставка через RecordInsertList). Родной режим потабличного RecId в трешке хоть и есть, но неработоспособен (поищите на форуме)

Если захочется еще нумераторов, то дублируете mSequence_RecIdExtra, называете как хочется и используете.

Предупреждение - все эти извращения на свой страх и риск. Прежде чем использовать на промышленных инсталляциях тестировать и еще раз тестировать. Все это работает и проверено годами, но осторожность не помешает

В вашем случает наверняка имеет смысл сделать это для SalesParm*/PurchParm* таблиц
Вложения
Тип файла: xpo RecIdExtra.xpo (5.7 Кб, 47 просмотров)
За это сообщение автора поблагодарили: DPO (1).
Старый 23.12.2010, 23:04   #169  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 901 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от DPO
...
чем плохо такое соотношение записей в этих таблицах.
...
Дело вкуса. Мне лично это не нравится из-за того, что увеличивает размер базы, что в свою очередь сказывается на снижении производительности и в увеличении продолжительности процедур по ее обслуживанию. В случае с 3.0 еще и ускоряет исчерпание RecId. На мой взгляд эти проблемы нужно понимать еще на этапе проектирования решения, чтобы не возникало таких ситуаций как у вас сейчас.
__________________
С уважением,
glibs®
Старый 24.12.2010, 08:47   #170  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,312 / 1347 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
DPO, простите, все же можете показать Ваши top 20 таблиц по количеству записей (из праздного любопытства пока спрашиваю)
Цитата:
Хотелось бы услышать ваше мнение о реализации потабличного RecId с помощью дефрагментации
Ну, теоретически может сработать, если делать аккуратно. Просто придется где-то в Вашем алгоритме жестко прописать все ссылки на дефрагментируемую таблицу (стандартному алгоритму этим заморачиваться не надо так как он тупо всех наследников от RecId во всех таблицах обрабатывает). Но предельно аккуратно - одну ссылку не зарегистрировали и привет целостность. Что-то похожее делали когда надо было отдельно обрабатывать ссылки между компаниями (из "реальной" в виртуальную)
__________________
-ТСЯ или -ТЬСЯ ?
Старый 27.12.2010, 10:44   #171  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,312 / 1347 (51) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Я на выходных еще немного подумал и вот что получается
- Вам придется реорганизовывать ("укладывать параллельно") все таблицы, потому что иначе нельзя (ну, небезопасно по крайней мере) сдвигать "назад" счетчик в SystemSequences, чтобы потом не нарваться на неуникальность сгенерированного RecId
- Это означает что придется где-то прописать все связи по RecId
- Алгоритм ацки усложнится по сравнению со стандартным, который заточен на то, что значения RecId в пределах компании все же уникальны
Т.е. в общем случае решение довольно сложное и не очень живучее получается. С другой стороны, если у Вас только небольшая часть функционала используется, то можно попробовать
__________________
-ТСЯ или -ТЬСЯ ?
Старый 05.10.2017, 10:29   #172  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Коллеги, нужны ваши советы
При анализе результатов запроса
Цитата:
Сообщение от Vadik Посмотреть сообщение
select dataareaid, name, nextval from systemsequences order by nextval desc
ориентируемся на самый большой nextval?

У нас самый большой прирост в компании dat, это нормальная картина в трешке?
dat SEQNO -780 699 868

У кого есть опыт достижения нуля по RecID, поделитесь.
Наша база 1, 292 ГБ и проводить операции по Проверке кодов записей затратно по времени, бизнес работает 24 на 7.

Есть ли вариант подцепить свежую БД с обнуленным RecID, ну естественно перезалив справочники, последние проводки?
Или это архи сложная задача "залить документы и проводки за месяц" из старой базы в новую?
__________________
Axapta 3.0 SP6
Старый 05.10.2017, 12:40   #173  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
2,925 / 1540 (57) ++++++++
Регистрация: 12.10.2004
Лучше договориться с пользователями и залить только справочники и исходные остатки и стартовать в новой базе.
За это сообщение автора поблагодарили: Kasper (1).
Старый 05.10.2017, 12:57   #174  
kostass is offline
kostass
Участник
 
37 / 13 (1) ++
Регистрация: 27.08.2009
Адрес: Владимир
Еще вопрос
По моему, после проведения операций Проверка кодов записей, запрос к systemsequence уже не покажет реальной картины?
__________________
Axapta 3.0 SP6
Старый 05.10.2017, 12:59   #175  
Kasper is offline
Kasper
Участник
 
31 / 19 (1) ++
Регистрация: 30.11.2005
7 лет...

Цитата:
Сообщение от kostass Посмотреть сообщение
У кого есть опыт достижения нуля по RecID, поделитесь
Я это делал. И на Ax 3 и на Concorde XAL. Результат -- успешно.
Я делал средствами БД (MS SQL и Oracle на Concorde)
Это именно дефрагментация. Поэтому если всего в БД записей под 2^32 это поможет ненадолго.

Рекомендую рассматривать мой вариант в последнюю очередь. Потому что за 10 лет коллеги могли выработать и иные, более простые решения этой проблемы.
Предыдущее сообщение Logger тому пример

На этом форуме я писал под ником Yaroslav Batozskiy,потом потерял пароль и завёл себя как Kasper

Последний раз редактировалось Kasper; 05.10.2017 в 13:05.
Теги
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, время: 13:13.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.