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

[Didukh84]

Цитата:

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

Только вот.. Didukh84, Вы УВЕРЕНЫ, что Вам надо запускать эту процедуру? У Вас RecId перескочил за maxint() или Вы таким образом пытаетесь какие-то другие проблемы?

У меня значение RecId - "-1804886437". Т.е. рано или поздно придется процедуру делать . Не охота, чтобы она застала врасплох .
Да, запустил еще раз проверку кодов то через 4-о суток оно сделалось!!! Значение RecId стало "140568244" :-) (правда я запускал перед этим еще реиндексацию зачем-то :-( )

[Didukh84]

Цитата:

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

Какие таблицы самые большие?
Можете привести данные отчета "Disk usage by top tables" или аналогичного?
.

привожу

[coolibin]

У меня вопрос знатокам по поводу поля LedgerTrans.BondBatchTrans_RU. У поля тип RefRecId, но как я понял ни на какой живой RecId он не ссылается. Вопрос, что будет с содержимым этого поля при выполнении дефрагментации RecId? Ведь новые номера в таблице AXOLDTONEWRECIDS сгенерятся не для всех его значений, а апдейт будет все равно запускаться.

[glibs]

С ними будет то же самое, что будет в полях, которые таки ссылаются на другие записи по RecId. Т.е. если у вас запись ссылается на другую запись по RecId, но записи с таким RecId не существует, то ссылка по RecId не обновляется. После реиндексации она может начать ссылаться на какую-то другую (уже существующую) запись. Тут будет точно так же. Но в данном конкретном случае, по-моему, это не страшно.

[coolibin]

Цитата:

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

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

На это очень хотелось бы надеяться, но у меня есть сомнения.
Смотрим код. Там в частности для оракла генерится оператор вида:

UPDATE table set field = NEWRECID FROM AXOLDTONEWRECIDS WHERE OLDRECID=table.field

Допустим, в AXOLDTONEWRECIDS не всегда есть подходящая запись, UPDATE вообще не отработает или запишет пусто?
Версия 3.

[AndyD]

Для table.field, которым нет соответствия в AXOLDTONEWRECIDS, ничего не изменится

[Gustav]

Изучаю метод \Classes\SysRecIdRepair\mainLoop.

И что-то возникло смутное беспокойство - а транзакция-то где? Самая главная, в которой выполняются все эти executeUpdate? Или она неявно обеспечивается существованием объекта Connection, который в new инициализируется?

Развеивателям беспокойства - заранее спасибо!

[sukhanchik]

Нэту... У объекта Connection есть методы ttsbegin(), ttscommit() - вот они и должны стоять (именно у этого экземпляра)... Все остальные tts-ы не имеют к этому коду никакого отношения.

[glibs]

Там нет транзакции. Более того, пересчет нужно запускать только в "монопольном" режиме. А то все развалится.

Насколько я понимаю, транзакция подсадит производительность. Я перед пересчетом предпочитаю сделать бэкап базы, перевести ее в "simple recovery mode", а потом вернуть обратно. Если что не получится — гораздо быстрее и безопаснее откатиться в начало из бэкапа. А запись лога отнимет ресурсы и потребует прилично места на диске.

[Gustav]

Цитата:

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

Нэту...

Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации, ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!.. И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?

Цитата:

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

Я перед пересчетом предпочитаю сделать бэкап базы, перевести ее в "simple recovery mode", а потом вернуть обратно. Если что не получится — гораздо быстрее и безопаснее откатиться в начало из бэкапа.

Логично! И лучше, чем я предположил.

[fed]

Цитата:

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

Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации, ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!.. И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?

Да - именно так. Причем после дефрагментации имеет смысл бегло просмотреть сохранность функциональности (Типа пару-тройку часов побегать по интерфейсу и потыкать в наиболее популярные ДОРАБОТКИ). Просто если кто-то в таблицах создал ссылку по recId, а расширенный тип для этой ссылки забыл отнаследовать от recId или refRecId, то при дефрагментации связь потеряется. То есть - конечно в стандартном функционале таких граблей нету, но я лично лет 7 назад забыл повесить правильный extended type на поле со ссылкой. И узнали мы об этом только тогда после дефрагментации recId, когда у нас пропала связь шапок авансовых отчетов с какой-то полезной дополнительной таблицей.

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

[Vadik]

Цитата:

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

Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации

А какая разница, когда тетя Клава дергает провод - во время регламентных мероприятий или в середине рабочего дня?

Цитата:

ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!..

Мы имеем (должны иметь) бэкап (протестированный, лучше - несколько на разных носителях)

Цитата:

И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?

Отключение пользователей, бэкап рабочей БД, тестирование бэкапа, дефрагментация
P.S. Попробуйте (на тестовом инстансе!) завернуть дефрагментацию в транзакцию и посмотрите, что происходит в это время с transaction log ( undo / redo ). Теперь попробуйте прервать эту транзакцию на середине. Теперь представьте, что у Вас каждую минуту звонит телефон "ну когда уже можно будет зайти". Вариант с полным бэкапом покажется не таким уж и страшным

[egorych]

Провожу сейчас исследование на тему дефрагментации, поскольку RecID уже за -1.6 млрд перевалил. Что обнаружил, применимо к Oracle -
строка 103, mainLoop -

this.executeUpdate('CREATE TABLE AXOLDTONEWRECIDS (OLDRECID NUMERIC(12), NEWRECID NUMERIC(12), CONSTRAINT PK_AXOLDTONEWRECIDS PRIMARY KEY (OLDRECID)) ORGANIZATION INDEX');

убрав слова "ORGANIZATION INDEX" - получил уменьшение времени расчета с 2 СУТОК до 2 ЧАСОВ!
Собственно CONSTRAINT PK_AXOLDTONEWRECIDS ИМХО можно безболезненно убрать!

[Vadik]

Недавно вместе с одним из пожелавших остаться неизвестным участников "отдефрагментировали" RecId :

Вводная:
- Несколько (порядка 10) компаний, три крупных
- Одна виртуальная компания
- Максимальный RecId 1843756363
- Размер БД около 280Гб (SQL Server 2008)

Проблемы:
- основная, разумеется, размер БД и ограниченное временное окно на выполнение процедуры
- стандартный механизм обладает некоторыми "особенностями":
- при запуске по всем компаниям компаний эффект "сжатия RecId" может снижаться или полностью отсутствовать
- при запуске по одной компании неправильно делается обновление ссылок по RecId на таблицы в виртуальных компаниях и "общие" (SaveDataPerCompany=No) таблицы
- хотелось хранить историю маппинга "старых" и "новых" значений RecId для разбора непредвиденных проблем

Как обходили:
- модифицирован класс SysRecRepair, добавлен небольшой фреймворк для регистрации "проблемных" ссылок (описание "проблемных" ссылок см. выше, определение ссылок делается вручную)
- исключили (средствами фреймворка) из обработки некоторые большие "непостоянные" таблицы (SysDatabaseLog, SysUserLog, xRef)
- переконфигурировали некоторые параметры БД на время обработки (отключение RCS, auto update statistics и пр.)
- настроили partitioning по DataAreaId
- временно удалили некластерные индексы с RecId на таблицах, где их более одного
- сохраняем временную таблицу маппинга "старых" значений RecId на "новые"

Результат:
- Количество обработанных записей по всем компаниям - 2850036022
- Максимальный RecId - 180862996 (сжатие приблизительно в 10 раз, благо были достаточно большие "дырки" в выделенных RecId)
- Вся процедура заняла около 12 часов, из них работа класса SysRecIdRepair около 7 часов.

Ограничения:
- Анализ имеющихся проблемных ссылок по RecId в виртуальные компании не автоматизирован (выполняется вручную)
- Версии для Oracle нет (пока)
- Обработка нескольких виртуальных компаний есть, но не протестирована

Код не выкладывается (по крайней мере пока), воспринимайте данный пост как некий whitepaper плюс "тестовый забег"

P.S. - в "простых" случаях (одна компания) стандартный механизм работает корректно

[Vadik]

Также см. альтернативный подход от Gustav

[DPO]

Коллеги, привет. На форуме не нашел, поэтому пишу здесь.

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

Поэтому был предложен альтернативный вариант спасения аксапты.
Если кратко, то он заключается в том, чтобы сделать RecId уникальными потаблично, а не во всей системе. Делается это конечно же не автоматически, а ручками с помощью дефрагментации и укладывания таблиц ровными слоями начиная с некоторого значения (например с 1). То есть например раз в квартал можно запускать дефрагментацию, в результате которой (а таблицы будут лежать параллельно!) масимальное значение RecId будет равно количеству записей в наибольшей таблице и затем уменьшать счетчик RecId. Вот такое временное решение.

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

[gl00mie]

Если вы все равно переходите на SAP, то, может, рассмотреть вариант с усечением базы? Вы же явно не будете тащить в SAP все исторические данные - только справочники и сальдовки...

[glibs]

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

Подходы к чистке данных могут быть различными. Как вариант можно подумать над архивированием, но это нетривиально.

[DPO]

Да, извиняюсь, что сразу не рассказал.

У нас будет старт с чистого листа в эту замечательную новогоднюю ночь, видимо то, что вы имеете ввиду под архивированием. То есть текущая база станет архивной, а в новую боевую перенесутся справочники, всяческие остатки и работа начнется в чистой базе.
Проблема в том, что RecId могут переполниться даже за год! В прошлый раз подобная процедура архивирования выполнялась 2 года назад. До этого нового года дотянули со скрипом и дефрагментацией. По прогнозам на следующий год планируется увеличение отгрузок в системе. При таком росте до следующего нового года мы дотягиваем, а вот до 2013 уже нет (хотя там может и не важно, в 2012 году-то ).
Делать процедуру рхивирования чаще раза в год не вариант из-за проблем с годовой отчетностью и общей ее геморойностью. Поэтому рассматриваем такой экстремальный способ спасения.

Что думаете на этот счет? В сравнении например с переходом на новую версию?

[Vadik]

Цитата:

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

Что думаете на этот счет?

Бизнес, генерящий столько транзакций, чтобы переполнить диапазон RecId (4 миллиарда записей) за год, причем на 3.0 - как-то слабо верится. Логистика к примеру в трешке такого не вытянет, разве что самописный модуль какой-то
Либо чего-то Вы не договариваете, либо что-то не то считаете, либо как-то не так дефрагментируете (imho)
Каков текущий размер БД (в терабайтах, я полагаю) ?