Включение потабличного RecID в 3-ке

[ZVV]

Всем привет!

Многим, наверное, известно, что в 3.0 есть "полунедокументированная" возможность включить генерацию потабличного RecId вместо "покомпанийного".
До вчерашнего дня я тоже знал, но сам не пробовал. Но т.к. проблема recId для клиента потенциально скоро встанет серьёзно, то решил попробовать прикрутить эту фичу. (Не как альтернативу 4-ке, а просто )

Делаю всё как описано в имеющемся описании - меняю 6-ой бит на 7-ой в системной переменной INDEX. Всё перезапускаю, и о чудо! Действительно Аксапта резко начинает клепать в таблицу SystemSequences потабличные записи для последовательностей RecId. Круто, думаю, это ж можно сразу решить все проблемы с рекИД. Одна проблема, что придётся вручную генерить записи для всех таблиц, чтоб проставить NEXTVAL в значение текущего для компании, чтоб избежать пересечений. А то аксапта создаёт новые с 1-цы.

Естественно, всё это время в голове жужжало одно - почему я нигде и никогда не слышал о том, что кто-то это реально использовал? Все только знают, что "типа можно". А реально единственная альтернатива - переход на 4-ку. И скоро стало понятно почему!
Потому что ядро нормально генерит только инсерты для этой таблицы!
А update остаётся старый!

UPDATE SYSTEMSEQUENCES SET NEXTVAL=:in1 WHERE ((SUBSTR(NLS_LOWER(DATAAREAID),1,3)=NLS_LOWER(:in2)) AND (ID=:in3))

Хотя в уникальном ключе ещё и номер таблицы тоже!
Соответсвенно, мы ничего не выигрываем, только записей больше.

Вообщем интересует вопрос, это специально так сделано? Или может кому-то удалось всё-таки завести эту систему?
У меня тут были мысли, что может на первых версиях 3-ки это и работало, но потом в ролапе, например, очередном эту возможность закрыли, чтоб все на 4-ку перебегали, а не этим способом пользовались. Реально то ведь всё работает кроме одного апдэйта - очень похоже на сознательное действие.
Надо будет как-нибудь в свободное время попробовать поставить аксапту без СП и КР и проверить....

Я проводил описаный тест на Ах3.0 сп3 кр3 + Оракл.

[belugin]

Осталось проверить все приложение, на то, что не используется факт уникальности recID в рамках системы. То есть что нет запросов типа

select from xxx where refRecID == zzz

без прочих условий, где refRecId может быть из разнях таблиц

[ZVV]

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

[db]

в трешке не работало никогда. регистрировали запрос в мс года 2-3 назад - что это баг признали, чинить отказались - типа ждите 4.0 там все работает

[ZVV]

Ясно. Ну то что чинить не станут - даже не сомневался если честно.
Спасибо!

[vc]

Цитата:

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

Но т.к. проблема recId для клиента потенциально скоро встанет серьёзно .....

Не в качестве решения, а как паллиативная мера, которая может быть применена при определенных условиях для отсрочки момента необходимости перехода:
Если у вас используется единственная компания.
Если при этом вы работаете не в компании по умолчанию (DAT).
Можно выделить таблицы, удовлетворяющие двум условиям

• потребляют большое количество RecId
• ссылки на RecId этих таблиц не используются в системе (сами они могут содержать ссылки на другие таблицы)

Это могут быть псевдовременные таблицы, содержимое которых постоянно перезаполняется, какие то таблицы логов - SysDatabaseLog, SysTraceTableSQL, SysTraceTableSQLTableRef например,у всех по разному.
Если у этих таблиц свойство SaveDataPerCompany установить в No, то RecId у них будет браться из SystemSequences для компании DAT.
А переполнение RecID в компании DAT вас беспокоить не будет.

[ZVV]

2 vc

ну да, где-то решение хорошее...
жалко вот только в случае этого конкретного клиента не выполняется второе условие

но зато уже знаю другого, кому это может пригодиться.

спасибо!

[Vladyslav]

Если грозит исчерпанием в будующем RecID можно воспользоваться следующим:
1) выделить наиболее прожорливые таблицы (обычно это какой-нибудь прожорливый протокол) в табличную коллекцию
2) колекцию в вируальную компанию
3) в виртуальную компанию включить вашу компанию (если компаний несколько, то создать для каждой по одной компании, или создавать для каждой таблицы... или выбирайте любую из допустимых комбинаций).

Для виртуальной компании генерится свой собственный RecId

Кстати, перекопав за долгие годы Аксапту вдоль и поперек, ни разу не встретил, чтобы RecId считалось где-то уникальным для всей системы (и сам такого никогда не писал, разумеется, и не давал так делать другим). Так что с этим проблем нет.
Механизм с виртуальными компаниями и коллекциями прекрасно работал в 3-ке. В 4-ке это оказалось уже не нужным - переимеовал значения в dataareaId обратно и удалил настройки компаний и коллекций (чтоб не вспомниать года через два зачем это нужно).

[ZVV]

Да, хорошее предложение - сам как-то не подумал про такой вариант...

[ZVV]

Владислав, а Вы не можете сказать, раз у Вас есть такой опят, как такое решение сказывается на производительности системы?
Если оно как-то сказывается?

PS Например если "выкинуть" таким образом InventTrans.

[Vladyslav]

Опыт есть, но не InventTrans
Как я уже упоминал: был заказ протоколировать всякую хрень, и объем этого протоколирования угрожал за впрочем довольно долгое время, но все же "съесть" весь ресурс идентификаторов записей.
Может если "выкинуть" подобное, то и для InventTrans хватит оставшихся двух миллиардов (это не считая отрицательных значений)?
Падения производительности не заметил (да и к чему бы). Будет ли падение при обращении к InventTrans? Вряд ли. Аксапта ведь в SQL запрос с объединением передает не как a.dataareaId = 'my1' and a.dataareaId = b.dataareaId, а как a.dataareaId = 'my1' and b.dataareaId = 'my1'
Нет, ну разумеется она там где-то внутри себя потратит время на "подстановку", но столь малой (надеюсь на это) величиной можно пренебречь

[ZVV]

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

Резюме: Пользуйтесь поиском, не изобретайте велики!

[Vladyslav]

Ну вот "наобещал" и сегодня же (впервые) нарвался на место, где 3-ка предполагает уникальность RecId в пределах всей базы: таблица SpecTrans
Поле RefId было заменено в четверке на RefTableId и RefRecId
Просто если пометить открытые проводки для сопоставления клиентские (CustTransOpen), то можно при наличии "своих" RecId в открытых проводках поставщика (VendTransOpen) доооолго размышлять, чего это она считает, что проводка еще где-то помечена.

[glibs]

По-моему, это бесперспективный путь.

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

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