|
01.08.2006, 10:52 | #1 |
Иван Захаров
|
Цитата:
Сообщение от velk
а может кто посоветует как провести процедуру дефрагментации несколькими этапами?
Нашли ли вы достаточные промежутки для того чтобы у вас работала база хотя бы день? Какие операции постоянно "пожирают" RecId? На каких именно таблицах? Какие лицензии и конфиг. ключи включены - какие таблицы задействованы (на предмет связи по RecId)? Вопросов много. Задавать их нужно по месту - смотря в приложение и бд, анализируя процессы, находящие отражение в системе, оптимизируя их... Конечно можно проводить операцию дефрагментации и несколькими этапами. Но удаленно (тем более с помощью форума) такое не решить. У каждого специалиста в данной сфере накоплены свои знания, которые на форуме по понятным причинам не раскрываются. |
|
01.08.2006, 12:39 | #2 |
Участник
|
я смотрел класс которые занимается дефрагментацией recid
он создает две таблички одна из них содержит соответствие старых и новых Recid а потом цикл по всем объектам базы со связью с той таблицей соответствия!!!! этож какой огромный запрос получается как сервер то мучается..... а нельзя было в эту таблицу добавить еще и название таблицы чтоб выбрать меньше записей!!! конечно он будет делать такую работу неделю!!! Может кто объяснит??? |
|
01.08.2006, 12:50 | #3 |
Member
|
Название таблицы вам не поможет. В Аксапте в любой таблице может храниться ссылка на RecId любой другой таблицы. Причем явная ссылка на таблицу присутствует далеко не всегда.
Да и не факт, что это существенно повысит производительность запроса. Начните лучше с того, про что пишет участник Gelios вот в этой ветке Регенерация RecID
__________________
С уважением, glibs® |
|
01.08.2006, 13:24 | #4 |
Участник
|
А почему вы думаете что не поможет ?
цель вот какая я добавил новое поле в таблицу AXOLDTONEWRECIDS Tabnum ineteger теперь алгоритм перебирает все объекты базы и навчинает обновлять recid причем не узнавая есть ли там или нет тех значений которые он обновляет а вот зная Tabnum мы уже сразу ограничиваем этот список... Поможет это мне или я ошибаюсь? |
|
01.08.2006, 13:27 | #5 |
Участник
|
Просто у меня записей в этой таблице AXOLDTONEWRECIDS 50млн слишним :-(
|
|
01.08.2006, 14:35 | #6 |
Участник
|
Разобрался все там нормально просто все так долго делается
не надо никаких Tabnum просто у нас в базе есть дублирующиеся значения Recid но все они находятся в разных не связанных таблицах и это думаю не помешает |
|
03.08.2006, 12:32 | #7 |
Участник
|
Обнаружил очень не приятную ОШИБКУ!!!
При формировании промежуточной таблицы из каждой таблицы берется одно поле RecId а при обновлении значений идет перебор всех полей таблицы порожденых от RecId И получается не все значения попадают в промежуточную таблицу!!!!! Как быть? Это что правильно ??? |
|
03.08.2006, 13:25 | #8 |
Member
|
Цитата:
Сообщение от velk
...берется одно поле RecId...
Это правильно. Это не ошибка.
__________________
С уважением, glibs® |
|
27.02.2007, 14:50 | #9 |
Участник
|
Подниму тему.
Axapta 3.0 SP3 У кого какие мнения сегодня? Безопасно ли запускать SysRecIdRepair? Делает ли это кто-то сейчас? configKey smmCRM отключен. |
|
27.02.2007, 15:10 | #10 |
Member
|
IMHO.
На стандартной условно безопасно. Если есть доработки — обязательно проверить корректность своего кода. "условно безопасно" заключается в том, что стандартный код тормозит, и можно "завесить" базу (откат транзакции тоже долго ждать придется). Поэтому первый раз всегда нужно запускать на тестовой (ну или иметь бэкап как минимум). Один мой знакомый оптимизировал код процедуры, и теперь регулярно запускает. Ему даже нравится. Проблем у него не было, насколько я слышал.
__________________
С уважением, glibs® |
|
27.02.2007, 15:15 | #11 |
Участник
|
База "почти" новая, но из-за некорректного переноса данных из нескольких компаний (включили в виртуальную не сразу) в виртуальную, сейчас подходим к значениям RecId, которые уже есть.
Вот думаем запустить. Код наш - вроде без глюков такого рода. Меня больше беспокоит русский код, о котором так много лестных слов сказано в этой ветке Оптимизация заключалась в чем? Индекс поменял? или что-то более глубокое? |
|
27.02.2007, 15:30 | #12 |
Member
|
Цитата:
Сообщение от kashperuk
...
База "почти" новая ... Цитата:
Сообщение от kashperuk
...
Оптимизация заключалась в чем? Индекс поменял? или что-то более глубокое? ... Могу кусок кода выслать, если лень искать (если пришлете мне ваш адрес в личку).
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: kashperuk (2). |
27.02.2007, 15:32 | #13 |
Member
|
Только я SQL часть делал. С Ораклом я пока не подружился, хотя есть шанс попробовать сделать по аналогии.
__________________
С уважением, glibs® |
|
27.02.2007, 16:41 | #14 |
Злыдни
|
Проводил на базе размером под 30 Гб. Все прошло хорошо. Но на тот момент бухгалтерская (финансовая) состовляющая не интересовала совсем, т.к. работала как довесок.
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании. |
|
28.02.2007, 11:51 | #15 |
Member
|
Нашел таблицу, в которой RecId хранится как текстовое поле.
SysSearchPath.URL Но это не проблемная таблица, т.к. это индекс поисковой системы корпоративного портала, и его можно перестроить. Просто нужно иметь в виду. Если индекс большой, то перед запуском процедуры имеет смысл почистить таблички SysSearch*. М.б. даже в SysRecIdRepair кусочек кода на эту тему вставить имеет смысл.
__________________
С уважением, glibs® |
|
28.02.2007, 12:07 | #16 |
Злыдни
|
Цитата:
Сообщение от glibs
Нашел таблицу, в которой RecId хранится как текстовое поле.
SysSearchPath.URL Но это не проблемная таблица, т.к. это индекс поисковой системы корпоративного портала, и его можно перестроить. Просто нужно иметь в виду. Если индекс большой, то перед запуском процедуры имеет смысл почистить таблички SysSearch*. М.б. даже в SysRecIdRepair кусочек кода на эту тему вставить имеет смысл.
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании. |
|
28.02.2007, 13:38 | #17 |
Member
|
Ну, это я бы уже отнес скорее к области здравого подхода к обслуживанию базы, нежели к дафрагментации RecId.
Хотя, безусловно, время на дефрагментацию сократит, если логистический модуль активно используется, и склад закрывается.
__________________
С уважением, glibs® |
|
07.08.2007, 06:38 | #18 |
Мрачный тип
|
Пара слов о стандартном SysRecIdRepair, точнее о надежности его использования ...
Автоинкремент в чистом неконтролируемом виде, используемый в данном классе для генерации новых значений RecId - есть зло, ибо рискуем с ним получить нарушение ссылочной целостности ввиду теоретической возможности совпадения в рамках одной таблицы старого и нового RecId, не являющегося заменой старому. Чем это чревато - можете представить сами . Новый RecId должен быть построен на автоинкременте с проверкой каждого нового значения на пересечение с подмножеством старых значенй по этой таблице. Это, конечно же, замедлит общий процесс дефрагментации и породит некоторые небольшие дырки в множестве новых RecId, но зато с подобной проверкой на душе спокойнее. |
|
07.08.2007, 08:20 | #19 |
Модератор
|
Цитата:
Сообщение от TasmanianDevil
Автоинкремент в чистом неконтролируемом виде, используемый в данном классе для генерации новых значений RecId - есть зло, ибо рискуем с ним получить нарушение ссылочной целостности ввиду теоретической возможности совпадения в рамках одной таблицы старого и нового RecId, не являющегося заменой старому
__________________
-ТСЯ или -ТЬСЯ ? |
|
07.08.2007, 09:56 | #20 |
Участник
|
Насколько я понял, имеется ввиду, что в таблице соответствия старым RecId новых может случиться ситуация вида:
RecId (OLD) RecId (new) 124 1 45676 2 2 3 То есть произойдет замена уже замененного RecId. Если неправильно понял, ТазманианДевил поправит. Но такой ситуации не может быть, потому как RecId в таблице отсортированны по возрастанию. То есть таблица будет выглядеть так, на самом деле: RecId (OLD) RecId (new) 2 1 124 2 45676 3 |
|
|
За это сообщение автора поблагодарили: TasmanianDevil (2). |