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

[velk]

а может кто посоветует как провести процедуру дефрагментации несколькими этапами?
у нас база уходит в down и уже дня три - четыре никакого эффекта

[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?

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

[Kasper]

Цитата:

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

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

Hi !

Ziva, а почему эту известную компанию называют "цветочной" ?

Давно уже не в теме, но попробую вспомнить, чего я тогда наваял.
1. Берем связи по recid из словаря--формируем таблицу связей.
2. Запускаем анализатор БД. Он полчаса шуршит, и выдает такую же таблицу, как в п.1., но с дополнительной колонкой "Вероятность". Там, где вероятности меньше процентов 75 -- отбрасываем сразу. Осталось 5...10 строк. Смотрим данные. На тех клиентах, где я это делал -- по 2...3 связи из этих 10 предполагаемых -- это реальные связи и кастом код разработчика, которые они не отразили в типах полей и которые надо врукопашную добавить в таблицу, полученную в п.1. Остальные--случайные совпадения
3. Запускаем дефрагментатор.
Все.

А в чем вопрос-то ?
П. 1 и 3 реализуются тривиально на T-SQL, причем для первого, по моему, достаточно одного select'а. В смысле, алгоритм тривиальный, а клаву топтать надо будет долго.
П.2 имеет смысл, если кастом-кода много, приложение старое, и источники знаний уже покинули компанию. Если разработчики здесь--то недокументированные связи извлекаем из голов.

[ziva]

Цитата:

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

Ziva, а почему эту известную компанию называют "цветочной" ?

Тык "клумба"-ж ...

[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.

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