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

[Gustav]

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

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

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

[sukhanchik]

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

[Gustav]

Цитата:

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

Нэту...

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

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

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

[Vadik]

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

[glibs]

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

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

[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)
Каков текущий размер БД (в терабайтах, я полагаю) ?

[glibs]

Цитата:

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

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

За счет чего вам удается этого добиться? У вас все 4 с хвостиком миллиарда записей в БД хранятся? В каких таблицах?

Под архивированием я имел в виду удаление из БД данных за старые периоды, которые штатно можно удалять. А если они нужны для статистики, то смещать их в другую БД, по которой строить OLAP отчетность, а в рабочей БД данные чистить.

Но если у вас 4 миллиарда записей за год заполняются, причем не мусором, то такой вариант вам не подойдет.

[DPO]

Цитата:

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

За счет чего вам удается этого добиться? У вас все 4 с хвостиком миллиарда записей в БД хранятся? В каких таблицах?

На данный момент у нас не 4 миллиарда с хвостиком, а примерно 2.5. Хранятся в основном в транзакционных таблицах InventTrans, InvetnTransPosting, LedgerTrans и тд.

Цитата:

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

Но если у вас 4 миллиарда записей за год заполняются, причем не мусором, то такой вариант вам не подойдет.

Пока только 2.5 заполняются, но да, не мусором. Через год по прогнозам вполне вероятно и 4. От этого немусора за старые периоды избавляемся, но не чаще раза в год.

[db]

Цитата:

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

Проблема в том, что RecId могут переполниться даже за год!

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

SystemSequence позволяет создавать свои нумераторы на основе того же механизма что используется для RecId и TransId

Пример могу дать, но попозже

[DPO]

Цитата:

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

Как тут уже правильно заметили дело скорее всего в алгоритмах постоянно генерящих данные, которые живут недолго и снова и снова пересчитываются (какой нито самодельный модуль или сводное планирование).

Сводного планирования нет. Самописные модули есть, генерят в районе 15% RecId в системе.

Цитата:

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

Если это реально так, то надо сделать ручное заполнение RecId из отдельного нумератора (сделать его на классе SystemSequence) для "полувременных" таблиц

Очень интересно. Не понял, почему так можно делать только для "полувременных" таблиц. Почему тоже самое нельзя сделать с остальными?

Цитата:

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

Пример могу дать, но попозже

Хотелось бы примерчик. Буду очень-очень благодарен!

[DPO]

И все таки он существует. Да, бизнес генерит много RecId.
На данный момент за месяц счетчик RecId увеличивается на 250 000 000 в месяц. Из них примерно 160 000 000 - существующие записи, остальное - пустоты в RecId. Для комфортного существования системы в течение 14 месяцев без экстренной дефрагментации на грани, скорость потребления RecId быть меньше чем 4 200 000 000 / 14 = 300 000 000 RecId в месяц, что в условиях растущего количества отгрузок может быть достигнуто достаточно быстро, уже в следующем году, а дальше - больше. Взял 14 месяцев потому что архивирование базы предполагает закрытие года в старой (архивной) базе, это с запасом.
То есть проблемы есть, не обманываю я вас.

Проблемы с производительностью тоже есть, но в следующем году их планируется решить переходом на новое оборудование и новый оракл. Понятно, что тройка с ее узким местом в inventSum`е помрет и на самом производительном железе. Продление жизни бизнеса на аксцапте 3.0 описанным выше способом рассматривается только как временная мера до перехода на САП.

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

[glibs]

Скорость, с которой вы заполняете БД, впечатляет. С учетом того, что вы даже склад не закрываете (а то бы у вас InventSettlement был бы в числе больших таблиц). То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках. Но здесь развивать эту тему с учетом ваших планов не целесообразно.

Я помню идею заталкивать отдельные таблицы в виртуальные компании. Я над ней не думал из-за того, что это путь в тупик. Но если вы скоро спрыгнете на САП, то стоит и ее рассмотреть (ломать — так ломать). Но это если ваш функционал может адекватно работать с виртуальными компаниями.