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

[ziva]

Цитата:

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

а может кто посоветует как провести процедуру дефрагментации несколькими этапами?

Я ж сказал - надо смотреть на месте.
Нашли ли вы достаточные промежутки для того чтобы у вас работала база хотя бы день? Какие операции постоянно "пожирают" RecId? На каких именно таблицах? Какие лицензии и конфиг. ключи включены - какие таблицы задействованы (на предмет связи по RecId)?
Вопросов много. Задавать их нужно по месту - смотря в приложение и бд, анализируя процессы, находящие отражение в системе, оптимизируя их...
Конечно можно проводить операцию дефрагментации и несколькими этапами. Но удаленно (тем более с помощью форума) такое не решить.
У каждого специалиста в данной сфере накоплены свои знания, которые на форуме по понятным причинам не раскрываются.

[velk]

я смотрел класс которые занимается дефрагментацией recid
он создает две таблички одна из них содержит соответствие старых и новых Recid
а потом цикл по всем объектам базы со связью с той таблицей соответствия!!!!
этож какой огромный запрос получается как сервер то мучается..... а нельзя было в эту таблицу добавить еще и название таблицы чтоб выбрать меньше записей!!!
конечно он будет делать такую работу неделю!!!
Может кто объяснит???

[glibs]

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

Да и не факт, что это существенно повысит производительность запроса.

Начните лучше с того, про что пишет участник Gelios вот в этой ветке

Регенерация RecID

[velk]

А почему вы думаете что не поможет ?
цель вот какая
я добавил новое поле в таблицу AXOLDTONEWRECIDS Tabnum ineteger
теперь алгоритм перебирает все объекты базы и навчинает обновлять recid причем не узнавая есть ли там или нет тех значений которые он обновляет
а вот зная Tabnum мы уже сразу ограничиваем этот список...
Поможет это мне или я ошибаюсь?

[velk]

Просто у меня записей в этой таблице AXOLDTONEWRECIDS 50млн слишним :-(

[velk]

Разобрался все там нормально просто все так долго делается
не надо никаких Tabnum
просто у нас в базе есть дублирующиеся значения Recid но все они находятся в разных не связанных таблицах и это думаю не помешает

[velk]

Обнаружил очень не приятную ОШИБКУ!!!
При формировании промежуточной таблицы из каждой таблицы берется одно поле RecId
а при обновлении значений идет перебор всех полей таблицы порожденых от RecId
И получается не все значения попадают в промежуточную таблицу!!!!!
Как быть?
Это что правильно ???

[glibs]

Цитата:

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

...берется одно поле RecId...

Вы имеете в виду то, что при построении AXOLDTONEWRECIDS отбираются неповторяющиеся значения RecId?

Это правильно. Это не ошибка.

[kashperuk]

Подниму тему.
Axapta 3.0 SP3

У кого какие мнения сегодня?
Безопасно ли запускать SysRecIdRepair?
Делает ли это кто-то сейчас?

configKey smmCRM отключен.

[glibs]

IMHO.

На стандартной условно безопасно.

Если есть доработки — обязательно проверить корректность своего кода.

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

Один мой знакомый оптимизировал код процедуры, и теперь регулярно запускает. Ему даже нравится. Проблем у него не было, насколько я слышал.

[kashperuk]

База "почти" новая, но из-за некорректного переноса данных из нескольких компаний (включили в виртуальную не сразу) в виртуальную, сейчас подходим к значениям RecId, которые уже есть.
Вот думаем запустить.
Код наш - вроде без глюков такого рода. Меня больше беспокоит русский код, о котором так много лестных слов сказано в этой ветке

Оптимизация заключалась в чем? Индекс поменял? или что-то более глубокое?

[glibs]

Цитата:

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

...
База "почти" новая
...

А в гигабайтах это сколько?

Цитата:

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

...
Оптимизация заключалась в чем? Индекс поменял? или что-то более глубокое?
...

Ну, я уже писал где-то. С тех пор мало что изменилось.

Могу кусок кода выслать, если лень искать (если пришлете мне ваш адрес в личку).

[glibs]

Только я SQL часть делал. С Ораклом я пока не подружился, хотя есть шанс попробовать сделать по аналогии.

[KiselevSA]

Проводил на базе размером под 30 Гб. Все прошло хорошо. Но на тот момент бухгалтерская (финансовая) состовляющая не интересовала совсем, т.к. работала как довесок.

[glibs]

Нашел таблицу, в которой RecId хранится как текстовое поле.

SysSearchPath.URL

Но это не проблемная таблица, т.к. это индекс поисковой системы корпоративного портала, и его можно перестроить.

Просто нужно иметь в виду.

Если индекс большой, то перед запуском процедуры имеет смысл почистить таблички SysSearch*. М.б. даже в SysRecIdRepair кусочек кода на эту тему вставить имеет смысл.

[KiselevSA]

Цитата:

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

Нашел таблицу, в которой RecId хранится как текстовое поле.

SysSearchPath.URL

Но это не проблемная таблица, т.к. это индекс поисковой системы корпоративного портала, и его можно перестроить.

Просто нужно иметь в виду.

Если индекс большой, то перед запуском процедуры имеет смысл почистить таблички SysSearch*. М.б. даже в SysRecIdRepair кусочек кода на эту тему вставить имеет смысл.

И желательно запустить процедуру удаления отмененных сопоставлений и группировки используемых

[glibs]

Ну, это я бы уже отнес скорее к области здравого подхода к обслуживанию базы, нежели к дафрагментации RecId.

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

[TasmanianDevil]

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

[Vadik]

Цитата:

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

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

А можно пример? Тяжело с утра понять, о чем идет речь

[kashperuk]

Цитата:

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

А можно пример? Тяжело с утра понять, о чем идет речь

Насколько я понял, имеется ввиду, что в таблице соответствия старым RecId новых может случиться ситуация вида:

RecId (OLD) RecId (new)
124 1
45676 2
2 3

То есть произойдет замена уже замененного RecId.
Если неправильно понял, ТазманианДевил поправит.

Но такой ситуации не может быть, потому как RecId в таблице отсортированны по возрастанию. То есть таблица будет выглядеть так, на самом деле:

RecId (OLD) RecId (new)
2 1
124 2
45676 3