Всем привет!
R3 -4.7, ora - 9.20
Чтение кол-ва записей из BSEG - 500 сек. при 2,3 млн. записей; все бух. отчеты тормозят.

Возможно после патчевания.

Как исправить, поможет ли реорганизация таблицы?

Смотрите трассы на эти отчеты. Если full table scan по BSEG, то надо смотреть сами запросы и/или статистику. А вообще часто можно обойтись вьюшками или смежными таблицами.
А что было до апгрейда? Все ок? И с чего апгрейдились?

На BSEG-то вьюшками ?

А почему нет? И потом, я ведь не ограничил поле деятельности вьюшками - это скорее общая рекомендация.

Для BSEG, обшая рекомендация?! И как сам пробовал, прирост скорости заметил наверное существенный был

как кардинальный вариант - конвертация в прозрачную таблицу

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

Точно! ST04 в студию!

Всем привет.
уточню, se16 bseg Число записей - 500 сек.

Самое простое и стандартное.
В процессах пишет: Последов. считывание RFBLG

Господа, про какие вюьшки вы говорите?!
BSEG - это кластер, а не прозрачная таблица! Физически информация лежит в таблице RFBLG. Первым делом нужно идти в DB02 и смотреть состояние этой таблицы. Статистика по RFBLG стандартным заданием из DB13 не собирается. Смотри количество экстентов таблицы и индекса RFBLG~0. Если экстентов много, то имеет смысл сделать export/import и увеличить значение next extent.
Дальше собери принудительно статистику по таблице и индексу. В свойствах таблицы смотри значение chained rows. Если значение большое относительно total rows, то также имеет смысл сделать export/import таблицы.
В свойствах индекса смотри значения deleted blocks и used in tree %.
Если в индексе много удаленных строк и используется меньше 50% дерева, то нужно сделать rebuild.
После всего этого удали статистику.

Гм, так в этом вся проблема?!
По кластеру нельзя просто сделать select count(*) from RFBLG, этим и объясняется большое время выполнения.
Поэтому только из-за se16 не стоит городить весь сыр-бор - кому еще придет в голову выполнять селект по всей BSEG?

Знамо дело, мы про проекционные вьюшки говорим!

Оффтоп: кто-нибудь разбирался в структуре хранения информации в таблицах типа RFBLG, STXL и т.д.? Насколько смог понять, данные там хранятся в зашифрованном виде. Можно их оттуда как-нибудь вытащить неабапными средствами?

Для увеличения производительности по связке BSEG и BKPF лучше пользоваться таблицы вторичных индексов: BSID, BSAD, BSAS, BSIS, ...

Совершенно верно, с BSEG'ом напрямую никто не работает.