|
23.12.2009, 15:22 | #1 |
Moderator
|
Изучаю метод \Classes\SysRecIdRepair\mainLoop.
И что-то возникло смутное беспокойство - а транзакция-то где? Самая главная, в которой выполняются все эти executeUpdate? Или она неявно обеспечивается существованием объекта Connection, который в new инициализируется? Развеивателям беспокойства - заранее спасибо! |
|
23.12.2009, 15:39 | #2 |
Administrator
|
Нэту... У объекта Connection есть методы ttsbegin(), ttscommit() - вот они и должны стоять (именно у этого экземпляра)... Все остальные tts-ы не имеют к этому коду никакого отношения.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: Gustav (2). |
23.12.2009, 16:31 | #3 |
Moderator
|
Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации, ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!.. И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?
Логично! И лучше, чем я предположил. Последний раз редактировалось Gustav; 23.12.2009 в 16:37. |
|
23.12.2009, 16:42 | #4 |
Moderator
|
Цитата:
Сообщение от Gustav
Та-а-а-к... Т.е. если уборщица тётя Клава шваброй дёрнет какой-нибудь не тот провод во время дефрагментации, ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!.. И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?
Так что рекомендую дефрагментацию ставить в ночь с пятницы на субботу, в субботу приходить на работу и смотреть что получилось. Ну а если не получилось - откатываться до бэкапа на пятничный вечер. |
|
|
За это сообщение автора поблагодарили: Gustav (2). |
23.12.2009, 16:48 | #5 |
Модератор
|
Цитата:
Цитата:
ты мы имеем... Точнее, мы, наверное, уже ничего не имеем!..
Цитата:
И как же быть? Делать копию рабочей базы, дефрагментировать на копии и при успешном завершении "подставлять" копию под рабочее приложение?
P.S. Попробуйте (на тестовом инстансе!) завернуть дефрагментацию в транзакцию и посмотрите, что происходит в это время с transaction log ( undo / redo ). Теперь попробуйте прервать эту транзакцию на середине. Теперь представьте, что у Вас каждую минуту звонит телефон "ну когда уже можно будет зайти". Вариант с полным бэкапом покажется не таким уж и страшным
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: Gustav (2). |
23.12.2009, 16:28 | #6 |
Member
|
Там нет транзакции. Более того, пересчет нужно запускать только в "монопольном" режиме. А то все развалится.
Насколько я понимаю, транзакция подсадит производительность. Я перед пересчетом предпочитаю сделать бэкап базы, перевести ее в "simple recovery mode", а потом вернуть обратно. Если что не получится — гораздо быстрее и безопаснее откатиться в начало из бэкапа. А запись лога отнимет ресурсы и потребует прилично места на диске.
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: Gustav (2). |
29.03.2010, 16:04 | #7 |
Участник
|
Провожу сейчас исследование на тему дефрагментации, поскольку RecID уже за -1.6 млрд перевалил. Что обнаружил, применимо к Oracle -
строка 103, mainLoop - X++: this.executeUpdate('CREATE TABLE AXOLDTONEWRECIDS (OLDRECID NUMERIC(12), NEWRECID NUMERIC(12), CONSTRAINT PK_AXOLDTONEWRECIDS PRIMARY KEY (OLDRECID)) ORGANIZATION INDEX'); Собственно CONSTRAINT PK_AXOLDTONEWRECIDS ИМХО можно безболезненно убрать! |
|
|
За это сообщение автора поблагодарили: Logger (5), gl00mie (3). |
20.08.2010, 13:46 | #8 |
Модератор
|
Недавно вместе с одним из пожелавших остаться неизвестным участников "отдефрагментировали" 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. - в "простых" случаях (одна компания) стандартный механизм работает корректно
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: gl00mie (3). |
08.12.2010, 14:17 | #9 |
Модератор
|
Также см. альтернативный подход от Gustav
__________________
-ТСЯ или -ТЬСЯ ? |
|
22.12.2010, 16:50 | #10 |
Участник
|
Коллеги, привет. На форуме не нашел, поэтому пишу здесь.
Есть значит у нас большая база на тройке. Делали дефрагментацию, временно помогла. Но только временно. По прогнозам на следующий год RecId не хватит даже с учетом дефрагментации, что печально. Компания переходит на САП, поэтому переход на новую версию аксапты есть не самый лучший способ избавления от проблемы RecId. Проблема в том, что проект по внедрению САПа может затянуться, а рекайди все растут.. Поэтому был предложен альтернативный вариант спасения аксапты. Если кратко, то он заключается в том, чтобы сделать RecId уникальными потаблично, а не во всей системе. Делается это конечно же не автоматически, а ручками с помощью дефрагментации и укладывания таблиц ровными слоями начиная с некоторого значения (например с 1). То есть например раз в квартал можно запускать дефрагментацию, в результате которой (а таблицы будут лежать параллельно!) масимальное значение RecId будет равно количеству записей в наибольшей таблице и затем уменьшать счетчик RecId. Вот такое временное решение. Понятно, что это грозит нам возможными переписываниями кода с таблицей SpecTrans и проими, в которых хранятся ссылки на RecId нескольких таблиц. Так же возможны проблемы с уникальными индексами по подобым полям-ссылкам на RecId. Но все это на мой взгляд вполне побеждаемо. Подскажите пожалуйста, кто-нибудь так делал? Не видите ли вы неразрешимых проблем в этой схеме? |
|
23.12.2010, 10:52 | #11 |
Участник
|
Если вы все равно переходите на SAP, то, может, рассмотреть вариант с усечением базы? Вы же явно не будете тащить в SAP все исторические данные - только справочники и сальдовки...
|
|
23.12.2010, 11:09 | #12 |
Member
|
Поддерживаю. Я бы в данной ситуации почистил данные, которые не нужны, но которые очень жалко выбросить, а затем дефрагментировал бы RecId.
Подходы к чистке данных могут быть различными. Как вариант можно подумать над архивированием, но это нетривиально.
__________________
С уважением, glibs® |
|
23.12.2010, 12:58 | #13 |
Участник
|
Да, извиняюсь, что сразу не рассказал.
У нас будет старт с чистого листа в эту замечательную новогоднюю ночь, видимо то, что вы имеете ввиду под архивированием. То есть текущая база станет архивной, а в новую боевую перенесутся справочники, всяческие остатки и работа начнется в чистой базе. Проблема в том, что RecId могут переполниться даже за год! В прошлый раз подобная процедура архивирования выполнялась 2 года назад. До этого нового года дотянули со скрипом и дефрагментацией. По прогнозам на следующий год планируется увеличение отгрузок в системе. При таком росте до следующего нового года мы дотягиваем, а вот до 2013 уже нет (хотя там может и не важно, в 2012 году-то ). Делать процедуру рхивирования чаще раза в год не вариант из-за проблем с годовой отчетностью и общей ее геморойностью. Поэтому рассматриваем такой экстремальный способ спасения. Что думаете на этот счет? В сравнении например с переходом на новую версию? |
|
23.12.2010, 15:19 | #14 |
Модератор
|
Бизнес, генерящий столько транзакций, чтобы переполнить диапазон RecId (4 миллиарда записей) за год, причем на 3.0 - как-то слабо верится. Логистика к примеру в трешке такого не вытянет, разве что самописный модуль какой-то
Либо чего-то Вы не договариваете, либо что-то не то считаете, либо как-то не так дефрагментируете (imho) Каков текущий размер БД (в терабайтах, я полагаю) ?
__________________
-ТСЯ или -ТЬСЯ ? |
|
23.12.2010, 16:09 | #15 |
Member
|
Цитата:
Сообщение от DPO
...
Проблема в том, что RecId могут переполниться даже за год! ... По прогнозам на следующий год RecId не хватит даже с учетом дефрагментации ... Под архивированием я имел в виду удаление из БД данных за старые периоды, которые штатно можно удалять. А если они нужны для статистики, то смещать их в другую БД, по которой строить OLAP отчетность, а в рабочей БД данные чистить. Но если у вас 4 миллиарда записей за год заполняются, причем не мусором, то такой вариант вам не подойдет.
__________________
С уважением, glibs® |
|
23.12.2010, 16:52 | #16 |
Участник
|
Цитата:
Пока только 2.5 заполняются, но да, не мусором. Через год по прогнозам вполне вероятно и 4. От этого немусора за старые периоды избавляемся, но не чаще раза в год. |
|
23.12.2010, 16:13 | #17 |
Роман Долгополов (RDOL)
|
Как тут уже правильно заметили дело скорее всего в алгоритмах постоянно генерящих данные, которые живут недолго и снова и снова пересчитываются (какой нито самодельный модуль или сводное планирование). Если это реально так, то надо сделать ручное заполнение RecId из отдельного нумератора (сделать его на классе SystemSequence) для "полувременных" таблиц
SystemSequence позволяет создавать свои нумераторы на основе того же механизма что используется для RecId и TransId Пример могу дать, но попозже Последний раз редактировалось db; 23.12.2010 в 16:16. |
|
23.12.2010, 17:05 | #18 |
Участник
|
Цитата:
Цитата:
Хотелось бы примерчик. Буду очень-очень благодарен! |
|
23.12.2010, 16:33 | #19 |
Участник
|
И все таки он существует. Да, бизнес генерит много 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 с помощью дефрагментации. |
|
23.12.2010, 17:22 | #20 |
Member
|
Скорость, с которой вы заполняете БД, впечатляет. С учетом того, что вы даже склад не закрываете (а то бы у вас InventSettlement был бы в числе больших таблиц). То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках. Но здесь развивать эту тему с учетом ваших планов не целесообразно.
Я помню идею заталкивать отдельные таблицы в виртуальные компании. Я над ней не думал из-за того, что это путь в тупик. Но если вы скоро спрыгнете на САП, то стоит и ее рассмотреть (ломать — так ломать). Но это если ваш функционал может адекватно работать с виртуальными компаниями.
__________________
С уважением, glibs® |
|