Как выполнять дефрагментирование RecID

[Maxim Gorbunov]

По-моему в Axapta вообще нет unsigned типов. Можно ограничить значения через EDT, но EDT - это не новый тип, это подмножество существующего типа.

А Axapta можно настроить так, что в SystemSequences будет заведена последовательность для каждой таблицы. То есть RecId будут уникальны не в рамках компании, а в рамках связки компания+таблица. По-моему, на крупных внедрениях это должно решать проблему нехватки RecId.

[George Nordic]

Спасибо, Максим! Отличная идея! А где можно поподробнее про это? В Администрировании что-й то не нашел...

[Maxim Gorbunov]

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

[Yaroslav Batozskiy]

Цитата:

Я, например, зарекся рыть в эту сторону после того как покопался в 2.5.
Именно из-за того, что есть поля, которые содержат ссылку на RecID, но не унаследованы от RecIdRef.

Скрипт находит такие поля, которые могут являться ссылами по recid. Делает это он довольно достоверно. В нашем скрипте можно еще и явно указать такие поля и, если известно, на что они должны ссылаться.

Цитата:

И надо ли делать эту дефрагментацию?

Надо, если реально исчерпали четырехмиллиардный диапазон уникальных записей и внутри диапазона нет досточно большой дырки, чтоб туда переставить счетчик (т.е. использованные recid более-менее равномерно размазаны по всему диапазону)

Цитата:

а теперь экспортируй компанию и импортируй обратно с удалением предыдущих значений

При экспорте-импорте как раз и потеряешь ссылки в полях, которые не наследуются от recid. Кроме того, как это делать с базой в 100ГБ ? Или даже в 10 ?

Цитата:

Я один раз запускал штатную процедуру на небольшой тестовой базе. Вроде работает.

Серьезные проблемы со ссылками. Со всеми вытекающими... (AX3SP1) Глубоко не копал, т.к. скорость её выполнения меня все равно не устраивает

Цитата:

Только лог транзакций на MS SQL у меня раздулся очень сильно.

Если хотите все обновления провести в одной транзакции--конечно раздуется. Можно каждое обновление проводить в своей транзакции--но при этом надо наготове иметь ленту, чтоб восстановить backup

Цитата:

а что происходит при достжении этого предела и какие последствия ?

Даже если cycle стоит 0, пойдет по кругу со второго запуска. Со всеми вытекающими...--"Запись уже существует" в случайные моменты с небольшой вероятностью

Цитата:

а потом вроде как будут заполняться дырки.

не будут.

Цитата:

Да - при достижении максимального значения RecId, он сбрасывается в минимально-возможное значение в табличке последовательностей

На самом деле, если посмотреть на битовую карту значений 2^31-1 и -2^31 можно увидеть, что он не сбрасывается, а система внутри оперирует числом как беззнаковым и просто прибавляет к нему единицу, в результате чего устанавливается старший бит, который для знаковых целых означает отрицательный полудиапазон--число становится минус два миллиарда и растет к нулю (абсолютное значение уменьшается до нуля)

[Yaroslav Batozskiy]

Наш скрипт написан целиком на T-SQL, поэтому работает быстро (2 ГБ базы пересчитывается меньше, чем за полчаса на четырехпроцессорном XEON).
Скрипт большой, состоит из шести фаз: четыре основных и нулевая--очистка ненужных таблиц и пятая--удаление следов (индексы etc)
Скрипт исправляет все ошибки целостности ссылок, которые я мог придумать
Создает логи, можно посмотреть все ошибки и додумать причины
Скрипт содержит "интеллектуальные" вещи, т.е. он может _подбирать_ и советовать в таблице правил, какое правило лучшее

Небольшое описание здесь http://www.crm.columbus.ru/ep/yarb/CITP_RecIdDefrag.doc

[Yaroslav Batozskiy]

В дополнение:
мне, например, удобнее, когда в ссылочных полях находятся значения одно порядка--тогда ошибочные значения всегда сразу видно (например все записи имеют ссылки до миллиона, и несколько -2 000 000 000)
Проблемы с системой при проблемах с RecId будут такие: визуально--ошибка "Запись уже существует" в случайные моменты времени с небольшой вероятностью. Но когда вы добавляете по одной строке-вероятность 5% приемлема, хоть и неприятна, но работать можно. Когда вы журнале создаете 20 строк и журнал разносите целиком--вероятность появления ошибки становится равной 100%.
Вообще плохо, когда в системе есть таблицы с recid большим, чем счетчик. Даже если вы диапазон не исчерпали (это видно по systemsequences) вы будете получать ош. "запись уже существует". Редко, но как правило, метко.
Причем записи такие, вероятно, могут появиться из-за действий пользователя. Система сама, если не делать ничего в таблицах руками, скорее всего таких строк не создаст. По крайней мере мне не удалось обнаружить таких случаев, я, правда, не очень глубоко и копал, т.к. инструмент для их исправления и обнаружения у меня есть.
В общем, если есть строки с recid больше, чем счетчик--это плохо. Когда я сделал дефрагментацию в нашей бухгалтерии (первый раз), у них все как-то глючить перестало, особенно сопоставления.
А вот ситуацию с зацикливанием допускать нельзя.

[Yaroslav Batozskiy]

Цитата:

А Axapta можно настроить так, что в SystemSequences будет заведена последовательность для каждой таблицы. То есть RecId будут уникальны не в рамках компании, а в рамках связки компания+таблица. По-моему, на крупных внедрениях это должно решать проблему нехватки RecId.

Я об этом слышу первый раз, но могу предположить, что работать это будет вряд-ли, т.к. есть такая табличка, как CustVendTransPostingLog_Ru, в которой есть ссылочные поля, и ссылаться они могут как на проводки поставщика, так и на проводки клиента. Если в обоих таблицах будут одинаковые значения, то как это вообще может работать ?
Кроме того, если настроить систему так , то это все равно что при снижении быстродействия HDD каждый раз покупать новый винт, вместо запуска дефрагментации

[Vadik]

Цитата:

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

похоже, работать таки не будет, особенно вот такое

PHP код:

display ModuleCustVend moduleCustVend()
{
    if ((select firstonly RecId from VendTrans
            index RecId
            where VendTrans.RecId == this.TransRecId).RecID)
        return ModuleCustVend::Vend;
    return ModuleCustVend::Cust;
} 


"Слава, слава Айболиту! Слава добрым докторам!" (с)

Цитата:

Кроме того, если настроить систему так , то это все равно что при снижении быстродействия HDD каждый раз покупать новый винт, вместо запуска дефрагментации

так их же выпускают все шустрее и шустрее - то оборотов прибавят, то кэш увеличат, то NCQ какой-нибудь введут

на самом деле - спасибо, есть над чем подумать

а можно маленькое уточнение?

Цитата:

Наш скрипт написан целиком на T-SQL

он совсем не смотрит в AOD или просто бегает по построенным перекрестным ссылкам?

если конечно это не военная тайна..

[glibs]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
...
Серьезные проблемы со ссылками. Со всеми вытекающими... (AX3SP1)
...

А не затруднило бы вас привести пример связи между табличками, которые рушатся (?) при выполнении операции проверки кодов записей, пожалуйста?

[Maxim Gorbunov]

CustVendTransPostingLog_RU - замечательный пример того, что локализаторам все эти их буржуйские стандарты программирования не указ. Она, конечно, работать не будет. Однако, в международной функциональности ссылку только по RecId не делают, добавляют еще и RefTableId. А еще пишут Relation на таблице.

[George Nordic]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
...Наш скрипт написан целиком на T-SQL, поэтому работает быстро...Скрипт исправляет все ошибки целостности ссылок, которые я мог придумать...
...Создает логи....Скрипт содержит "интеллектуальные" вещи,он может_подбирать_ и советовать в таблице правил, какое правило лучшее..

Извиние, Ярослав, но это - чистая реклама, т.к. продукт платный. Вообще-то люди простили совета... все мы знаем, что за деньги можно все. Можно даже руками RecId перебить

Цитата:

Изначально опубликовано Yaroslav Batozskiy Когда я сделал дефрагментацию в нашей бухгалтерии (первый раз), у них все как-то глючить перестало, особенно сопоставления.

??? Не понял? Поподробнее, плиз? Что же, Вы хотите сказать, что Axapta не может найти запись, если в RecId есть "незаполненный диапазон"?? Или не может найти отрицательный RecId?? В помойку тогда такую систему! И никакой скрипт ей уже не поможет...

Кстати, идея - запущу поиск по всему репозитарию с параметром ".RecId > 0". Но не думаю, что таких строчек там много... "Особенно в сопоставлении" 8)

С Уважением,
Георгий.

[Yaroslav Batozskiy]

Классный вопрос !

Цитата:

Вообще-то люди простили совета...

Мы решили эту проблему таким образом. Вы можете придумать свое решение. Изначально я разрабатывал дефрагментацию для решения своей конкретной проблемы со своей системой, но скрипт у меня получился универсальным, поэтому я увидел, что могу помочь многим.
Тот факт, что участвую в этом форуме говорит о том, что я хочу помочь. Но сделать я это могу только таким образом... George, просто не следует забывать, что разработка эта принадлежит компании. Компания потратила на это определенные ресурсы.
Поэтому то, что я не могу ответить на вопросы по алгоритму--это продиктовано простыми законами бизнеса и корпоративной этикой
Уверен, что моем месте Вы поступили бы так же.
За счет его универсальности мы можем снизить цену в разы, и это станет дешевле, чем собственная разработка.
Однако меня ни что не ограничивает в том, чтоб я мог поделиться своими знаниями в функционировании системы. Что я, по мере возможности, и делаю :-)

Цитата:

Что же, Вы хотите сказать, что Axapta не может найти запись, если в RecId есть "незаполненный диапазон"??

Боюсь, Вы меня не совсем правильно поняли Я имел ввиду, что сопоставление, IMHO, перестанет "иногда некорректно работать", если в этой таблице не будет строк с неправильными ссылками, т.е. например TransRecid ссылается на проводку, а вот OffsetRecid ссылается на несуществующую запись.
Изначально фаза исправления ошибок делалась просто для обеспечения логической целостности данных, однако это дало вот такие результы.

Цитата:

...Создает логи....Скрипт содержит "интеллектуальные" вещи,он может_подбирать_ и советовать

А вот Вас, George, как "Фому неверующего" , я могу пригласить к нам в офис и продемонстировать работу скрипта, в т.ч. логи, "интеллектуальность", подсказки. Я продемонстрирую процесс и результат работы.

[George Nordic]

Цитата:

Изначально опубликовано Yaroslav Batozskiy ...просто не следует забывать, что разработка эта принадлежит компании. Компания потратила на это определенные ресурсы.Уверен, что моем месте Вы поступили бы так же.

Да, Ярослав, согласен Эх, жаль, что Вы не написали этот срипт "для себя, на досуге"
Просто уж больно лакомый кусочек... "Битых" сслылок со временем действительно может много накопиться...

А за приглашение - спасибо! Считайте, что напросился - как-нибудь дойду

[Vadik]

Т.е. ответов на мой и glibs'а ответов тоже не будет? жаль

Что смутило меня:

- самое первое:

Цитата:

Скрипт находит такие поля, которые могут являться ссылами по recid. Делает это он довольно достоверно.

"довольно достоверно" - это заставляет задуматься. Скорость работы скрипта уже не так вдохновляет

Цитата:

Я имел ввиду, что сопоставление, IMHO, перестанет "иногда некорректно работать", если в этой таблице не будет строк с неправильными ссылками, т.е. например TransRecid ссылается на проводку, а вот OffsetRecid ссылается на несуществующую запись.

Мы же с Вами люди с высшим техническим (я так думаю) образованием. Нам ли оперировать такими терминами, как "иногда некорректно работать"? Ошибка или есть или ее нет. Если есть ссылка, а запись, на которую она ссылается, отсутствует, и таких ссылок несколько и есть несколько записей, на которые нет ссылок, как это будет автоматически разгребаться? Я в недоумении

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

P.S. В то, что Ваш скрипт действительно дефрагментирует RecId, верю с радостью В то, что при этом может лечиться проблема "запись уже существует" верю, потому что понимаю механизм

[George Nordic]

\Data Dictionary\Tables\CommissionSalesRep\Methods\validateField
\Data Dictionary\Tables\CommissionSalesRep\Methods\validateField
\Data Dictionary\Tables\LedgerJournalTrans\Methods\createNewPayment
\Data Dictionary\Tables\LedgerJournalTrans\Methods\createNewPayment
\Data Dictionary\Tables\HRMCourseAttendee\Methods\checkMaxAttendees
\Data Dictionary\Tables\TmpRTax25LedgerAccountList\Methods\findRecIds
\Data Dictionary\Tables\LanguageTable\Methods\multipleLanguageExist
\Data Dictionary\Tables\smmContactPersonDetails\Methods\syncIsNeeded
\Classes\UserInfoHelp\deleteUsersFromUserGroup
\Classes\SysApplCheck\checkTableFieldPnameMustBeUnique
\Classes\SysApplCheck\checkTableFieldPnameMustBeUnique
\Classes\ReleaseUpdateDB\dataImportStart
\Classes\ReleaseUpdateDB\dataImportStart
\Classes\ReleaseUpdateDB\deleteDuplicatesUsingNames
\Classes\xUtilIdElements\checkDuplicateNamesWithDifferentId
\Classes\CustVendCreatePaymJournal\aggregateLedgerJournalTrans
\Classes\CustVendCreatePaymJournal\aggregateLedgerJournalTrans
\Classes\CustVendCreatePaymJournalBoth_Cust\addLedgerJournalTrans
\Classes\CustVendCreatePaymJournalBoth_Cust\addLedgerJournalTrans
\Classes\CustVendCreatePaymJournalBoth_Vend\addLedgerJournalTrans
\Classes\CustVendCreatePaymJournalBoth_Vend\addLedgerJournalTrans
\Classes\smmUtility\checkExecuteConditions
\Classes\smmUtility\checkExecuteConditions
\Classes\CustVendSettle\relatedAssetTrans
\Classes\LedgerJournalTransUpdateVend\checkVoucher
\Classes\SysINetHTMLPublish\processCommand
\Classes\BMScopeDB\init
\Classes\CustVendCreatePaymJournal\transactionsMax
\Classes\CustVendCreatePaymJournal_Cust\transactionsMax
\Classes\CustVendCreatePaymJournal_Cust\transactionsMax
\Classes\CustVendCreatePaymJournal_Vend\transactionsMax
\Classes\CustVendCreatePaymJournal_Vend\transactionsMax
\Classes\SysSqlRestoreCompany\deleteDocuValue
\Classes\SysCodeProfilerSumServer\calcLineSumWithoutChildren
\Classes\SysCodeProfilerSumServer\calcMethodSumWithoutChildren
\Classes\SysCodeProfilerSumServer\calcObjectSumWithoutChildren
\Classes\ReleaseUpdateDB_V25toV30\FindValidZipCode
\Classes\ReleaseUpdateDB_V25toV30\FindValidZipCode
\Classes\ReleaseUpdateDB_V25toV30\updateInventJournalTrans
\Classes\ReleaseUpdateDB_V25toV30\updateInventJournalTrans_TagLineNum
\Classes\ReleaseUpdateDB_V25toV30\updatePaymentTransferFees
\Classes\ReleaseUpdateDB_V25toV30\updateProdJournalBOM
\Classes\ReleaseUpdateDB_V25toV30\updateProdJournalProd
\Classes\ReleaseUpdateDB_V25toV30\updateProdJournalRoute
\Classes\ReleaseUpdateDB_V25toV30\updateProjJournalTrans
\Classes\ReleaseUpdateDB_V25toV30\updateWMSJournalTransLineNum
\Classes\BMRunStatExtended\calcLedgerDisp
\Classes\ConvCompanyCurrency\convAmountsInLedgerTrans
\Classes\ConvCompanyCurrency\convAmountsInLedgerTrans
\Classes\ConvCompanyCurrency\convPerExtendedType
\Classes\ConvCompanyCurrency\convPerExtendedType
\Classes\SysBPCheck\checkGlobalTablePNameUnique
\Classes\SysBPCheckTable\checkFieldPnameUniqueness
\Classes\KMCollectionCheck\checkDerivedQuestionsSeqNumber
\Classes\HRMUpgradeTo30NetworkToCRM\FindValidZipCode
\Classes\HRMUpgradeTo30NetworkToCRM\FindValidZipCode
\Classes\RAssetProposal\dialog
\Classes\RPayBalanceSheetCol_Counter\sumUpTrans
\Classes\RPayBalanceSheetCol_CTypeAmount\sumUpTrans
\Classes\RPayBalanceSheetCol_CTypeQtyDay\sumUpTrans
\Classes\RPayBalanceSheetCol_CTypeQtyHour\sumUpTrans
\Classes\LedgerAccountRenameProcess_RU\checkDuplicateRecord
\Classes\LedgerAccountRenameProcess_RU\prompt
\Classes\RTax25RegTransEngine\filter
\Classes\RAssetOperationType_Depreciation\checkLastDepDate
\Classes\Markup_ReleaseUpdate_RU\initMarkupTrans_RU
\Classes\CustVendAutoSettlement_RU\run
\Forms\ConfigChooseFromRoute\Designs\Design\[Group:RightGroup]\[ButtonGroup:ButtonGroup]\CommandButton:OK\Methods\clicked
\Forms\ConfigChooseFromRoute\Designs\Design\[Group:RightGroup]\[ButtonGroup:ButtonGroup]\CommandButton:OK\Methods\clicked
\Forms\PBATreeBOM\Methods\moreThanOneRecId
\Forms\PBATreeBOM\Methods\moreThanOneRecId
\Forms\PBATreeRoute\Methods\moreThanOneRecIdRoute
\Forms\PBATreeRoute\Methods\moreThanOneRecIdRoute
\Forms\PBATreeTable\Methods\moreThanOneRecId
\Forms\RAssetBalance\Methods\init
\Reports\WebCmNewsArticle\Methods\init

[George Nordic]

Да, забыл добавить - Ax 3.0 SP3 HF2...
Простая вроде проверочка (Поиск строчки "RecId >" ) А сколько информации для размышления... Так что, господа, вы уверены, что Ax готова работать с отрицательным RecId?

С Уважением,
Георгий

[mazzy]

Цитата:

Изначально опубликовано George Nordic
Re: Кстати, вот в этих местах возможны проблемы с отрицательным RecId

Спасибо!
О-о-о-ох...

[Андре]

Цитата:

Простая вроде проверочка (Поиск строчки "RecId >" ) А сколько информации для размышления... Так что, господа, вы уверены, что Ax готова работать с отрицательным RecId?

Цитата:

Спасибо! О-о-о-ох...

Спокойно. Аксапта готова работать с отрицательным RecId. Более того, я знаю проект, где именно так она и работает.

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

[Yaroslav Batozskiy]

Открыл первую попавшуюся ссылку, вот что там увидел:
return contactPerson.RecId > 0 ? true : false;
А нельзя было написать
return contactPerson.RecId > 0;

[Maxim Gorbunov]

Георгий, не сейте панику.
В большинстве указанных Вами мест последовательность операторов приблизительно такая:

PHP код:

select count(RecId) from .... where ...;
if (...RecId >= 1) {
    ....
} 


Так что все будет в порядке.

P.S.: Не гарантирую, что так везде.

--- добавлено ---
P.P.S.: В том, которое указал Ярослав (\Data Dictionary\Tables\smmContactPersonDetails\syncIsNeeded) тоже сначала делают count(RecId)