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

[mazzy]

Цитата:

Изначально опубликовано Maxim Gorbunov
Я вовсе не против рекламы в этом топике. Просто мне кажется достаточно странным его наличие в форуме Проекты.

Максим, я понял твою аргументацию по поводу перемещения.
Готов согласиться с тем, что поступил мало подумав.

Сейчас предлагаю ничего не менять, оставить этот топик в проектах.
Впредь буду осторожнее.

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
1. Условно согласен. В "перекрестном" случае это не всегда ОЛЦД. Как вариант, _можем_ выделить, например, для компаний разные диапазоны recId, например DAT-первый миллиард, холдинг--второй миллиард, и по одному на две аффилированные структуры

При этом в общей таблице при ее просмотре из холдинга будут битые ссылки, которые на самом деле ссылки на строки таблиц из компании DAT.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
2. ????? Ни разу не видел ! Обновления производятся командой UPDATE (строка 139, AX3SP1), поэтому такой случай SQL просто пропустит, т.к. он при обновлении исключится фразой WHERE в коррелированном запросе. По моему, не может такого быть. Или я что-то проглядел ?

Да, тут я ошибся. Действительно пропустит.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
3. Да. А поиск производился по каким модулям ? Я имел ввиду все модули, какая часть из них находится в наиболее часто используемых--не смотрел

Поиск проводился автоматически по всем таблицам.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Боюсь, что нет. В таблице LedgerTrans есть поле RTSLSessionTransId, которое ссылается на Recid таблицы RTSLSessionTrans--сессии трансляции--номер сессии, которая породлила проводку. В форме на этой табличке есть кнопка "Отменить"--откатывает трансляцию с удалением проводок.
После Exp-Imp или "Проверке..." в сессиях recid поменяется, а в проводках нет, поэтому сессию удалить можно будет только руками. Явный баг. Регистрирую в MBS.

На чем основано Ваше утверждение? Анализ приложения (стандартного Axapta 3.0 SP1 CIS) позволяет утверждать, что поле LedgerTrans.RTSLSessionTrans ссылается на поле RTSLSessionTrans.SessionTransId, а не на RTSLSessionTrans.RecId.

[glibs]

На прошлых выходных развлекался попытками разогнать (в смысле, ускорить) стандартную процедуру на MS SQL (путем изнасилования кода процедуры). Заодно прочитал сначала данную ветку. Очень интересно.

Цитата:

Сообщение от Yaroslav Batozskiy

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

А стандартная процедура пересчета RecId не далека от этого состояния.

Цитата:

Сообщение от Yaroslav Batozskiy

...
поэтому работает быстро (2 ГБ базы пересчитывается меньше, чем за полчаса на четырехпроцессорном XEON).
...

В моем случае на базе в 5 Gb с хвостиком (правда данных всего 2.5 Gb и столько же под индексами) удалось выйти на результат около 1:40. На однопроцессорном лаптопе (правда, база и лог были на внешнем диске: один, обычный IDEшный, подключенный по USB-интерфейсу). Память под MS SQL Server была ограничена до 300 Mb. Т.о. цифра далеко не предельная. В ходе опыта явно видно, что для дальнейшего ускорения процедуры нужно наращивать дисковую подсистему и/или память SQL Server.

Так что в плане скорости вышеупомянутый скрипт, IMHO, не является панацеей.

Цитата:

Сообщение от Yaroslav Batozskiy

...
Ув. glibs. Я просто дал совет. Хотите-разберитесь, хотите-проигнорируйте.
...

Поглядев на код и поэкспериментировав неприязнь к штатному алгоритму не разделяю. Скорее наоборот я бы отдал предпочтение стандартному алгоритму, нежели алгоритму, который не использует данные из АОТа и работает исключительно на базе эвристического анализа с элементами теории вероятности.

Хотя использовать его для обнаружения незадокументированных должным образом в АОТе связей по RecId можно попробовать. А много вышеупомянутый скрипт нашел таких связей (если вдруг Yaroslav Batozskiy не ответит на данный вопрос, может кто-то имел возможность скриптом попользоваться на законных основаниях и может прокомментировать)?

[glibs]

Цитата:

Сообщение от Maxim Gorbunov

Кстати, был в какой-то ветке вопрос (в какой, уже не помню), какие таблицы не переживут дефрагментацию RecId.

Исчерпывающего ответа не дам, но внесу первый вклад:
smmTransLog

Похоже, он же и последний. Если не считать tutorial_AuctionBids.

Проверял путем анализа названий полей (а иногда, например, TaxTrans.TaxRefId, и кода с данными), базовый тип которых Integer. Анализировал глазками.

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

Т.о. дефрагментация recId очень даже рабочая. Но при попытках ее использовать на инсталляциях с кастомизированным приложением, имеет смысл проверить корректность собственоручно созданных табличек.

[velk]

Здравстуйте
помогите решить проблему
на данный момент поле nextVal в таблице SystemSequences равно -13
соответсвенно в базе работать невозможно ругается на дубрирование записи и не создает....
как решить проблему?

[Recoilme]

Цитата:

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

Здравстуйте
помогите решить проблему
на данный момент поле nextVal в таблице SystemSequences равно -13
соответсвенно в базе работать невозможно ругается на дубрирование записи и не создает....
как решить проблему?

Обычной перезагрузкой )) АОС перезапустить

[velk]

Цитата:

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

Обычной перезагрузкой )) АОС перезапустить

Всмысле не понял как это????
А я думал что RecID кончились :-(((

[Recoilme]

Рано радуетесь)) Вот как 400000 строк заказов в день научитесь разносить так и приходите за 64 битным рекид
Скорей всего у Вас просто псевдо сцылочностная целкостность нарушилась.

[velk]

Мдааа сложно
может подскажете как ее решить...:-(
а то база стоит работать не возможно
и как найти свободный диапазон RECID чтоб сместить его?

[Recoilme]

Цитата:

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

Мдааа сложно
может подскажете как ее решить...:-(
а то база стоит работать не возможно
и как найти свободный диапазон RECID чтоб сместить его?

Старт/стоп AOS а не помог???

[velk]

Цитата:

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

Старт/стоп AOS а не помог???

Нет конечно :-(

[ziva]

Цитата:

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

Мдааа сложно
может подскажете как ее решить...:-(
а то база стоит работать не возможно
и как найти свободный диапазон RECID чтоб сместить его?

Вот, процитирую себя:
http://axforum.info/forums/showthrea...992#post110992

По результатам телефонного митинга с John McBride (менеджер команды разработки) и Mathieu Kemenovic (глобальная служба поддержки) мне подтвердили что они ничего менять в 3.0 не будут (и даже не будут делать private hot-fix) и предоставлили набор SQL-скриптов, которые ищут большие "дырки" последовательности идентификаторов записей и используют их. Данные скрипты неавтоматические и необходимо выполнять ряд шаманских танцев с бубнами...
.

[Recoilme]

Цитата:

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

Здравстуйте
помогите решить проблему
на данный момент поле nextVal в таблице SystemSequences равно -13
соответсвенно в базе работать невозможно ругается на дубрирование записи и не создает....
как решить проблему?

-114 поставьте

[Recoilme]

Потом выгрузите в текстовый файд список всех таблиц
(Встаньте на список таблиц а энтерпрайзменеджере и экспорт лист)

на любом языге нопишите select min(recid) from "тут_ваша_таблица"

если с язаком сложно - откройте список таблиц в экселе , добавьте колонку про селект , СЦЕПИТЬ(а,б)

и выполните этот скрипт из кверианалайзера например ,

Выгрузите результаты запроса в ексель, например и посмотрите минимум, это и буде Ваш nextVal

СОРРИ: сумбурно очень, но примерно так я бы делал ибо не знаю как список всех таблиц например запросом получить и т.п.

[velk]

Цитата:

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

-114 поставьте

у нас увеличивается за раз на 250

[velk]

PHP код:

systemSequence systemSequence = new systemSequence();
;
Info(Strfmt("?? - %1", systemSequence.getCacheSize())); 


Возвращает 250
сейчас установили 10

[velk]

и сместили значение nextVal в обратную сторону
промежуток RecId взяли из LedgerTrans
вроде бы пошло
но проблема в том что в таблице LedgerTrans есть этот промежуток RecId
значит эти RecId где то были использованы...
и если будем делать дефрагментанцию то корректно либудет произведена она?

[ziva]

Цитата:

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

... если будем делать дефрагментанцию то корректно либудет произведена она?

Для начала попытайтесь воспользоваться стандартным средством -
Администрирование\Периодические операции\SQL Администрирование\Проверка кодов записей. (Classes\SysRecIdRepair)
Он сам выстраивает в рамках компании все записи последовательно и перенумеровывает их.
Насколько результат работы данного средства будет положительным зависит от размера базы, мощности серверов и прочего.

Предостережение:
Не стоит впадать в крайности и сразу запускать данную обработку в production environment - необходимо сделать копию "боевой" версии.
Кроме того, если Вы используете виртуальные компании - следует особо внимательно проверить результаты работы данного механизма - если у Вас таблицы, со связями по RecId сделаны "общими".

[velk]

Виртуальных компаний нет....слава богу...
база архивируется каждый день
размер её 40Гб
сервер 2-х процессорный XEON

[ziva]

Цитата:

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

Виртуальных компаний нет....слава богу...
база архивируется каждый день
размер её 40Гб
сервер 2-х процессорный XEON

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

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

В любом случае Вам нужен профессионал который через это "проходил" и данную проблему решал неоднократно.