Добрый день!

Возник странный вопрос, хочется посоветоваться с сообществом.
Опишу ситуацию - есть небольшая база на Oracle 11.2, в базе 100-150 таблиц, десятки тысяч строк в основных 15-20 таблицах, остальное справочники. Суммарный размер дампа базы около 100 гигабайт, но в основном он набрал блобами Word-документов.

Есть запрос (вьюшка), которые собирает данные из 20-30 таблиц.
Скорость работы запроса недавно внезапно упала в несколько раз - было 5-7 секунд, стало около 25 секунд.

В ходе выяснения причины оказалось, что на тестовой копии базы запрос выполняется за 2-3 секунды,
то есть даже быстрее чем раньше было в рабочей базе, хотя тестовый сервер сильно слабее.

Начали искать отличия - и оказалось, что в тест не перенесены данные самой большой таблицы -
бинарные данные (блобы) хранимых в системе документов, которые составляют более 98% размера дампа базы.

В результате выяснили, что если перенести в тест все таблицы с данными, кроме одной, которая содержит 300 тысяч блобов,
то всё летает. А потом добавляем в базу данные блобов (100 гигабайт) и запрос начинает тормозить, хотя в нём нет обращения к этим блобам. После удаления из базы таблицы с блобами запрос опять начинает работать быстро.

Собственно вопрос - чтоб это было? может ли физический размер табличных пространств/дата-файлов влиять на скорость выполнения запросов? почему таблица с блобами влияет на запрос, в котором никак не участвует?

с уважением,
Дмитрий Жучков

oragraf,
все поля явно указаны и проименованы, вьюшка же

Надфиль,
структура таблицы с блобами грубо говоря такая:


никаких особенностей хранения таблица не имеет, всё параметры по умолчанию,

длина записи в самой таблице или средняя длина блоба?
в самой таблице - байт 400 от силы,
блобы в среднем по 30килобайт - вордовские документы на 5-10 страниц.

Надфиль,

да, все перечисленные этапы пройдены -
проблема в том, что эта таблица с блобами никаким образом не связана с запросом,
который начал тормозить.
ее можно переименовать, можно удалить - запрос работает, только время отклика меняется

грубо говоря картина такая - есть база на 100 таблиц,
в ней есть достаточно сложный запрос, который выполняется за 2-3 секунды и все этим временем довольны,

в базу добавляется 101-я таблица, которая раздувает размер базы на диске в 100 раз,
это практически реальные цифры - наша база без блобов 1.3 гига, с блобами 124 гига.

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

полный запрос это многие сотни строк, таблица с блобами в нём не участвует ни разу и никак вообще

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


других сессий нет - тестовая система однопользовательская


да, одно табличное пространство, одна схема, один диск, один процессор на сервер, только дата-файлов 6 штук и ядер у процессора 4


планы одинаковые, трассировку на тестовом и именно во время этого эффекта не делали и сегодня уже не сделать

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

я так понял, что явление массовым и общеизвестным не является
и причины эффекта скорее всего находятся за пределами Oracle

самоизоляция, сотни пользователей на удалёнке (включая всех участников тестов),
нагрузка на сервера и сети... где-то там будем искать

коллеги, спасибо за интересную дискуссию на тему "как лучше хранить блобы" :)
наша система хранит блобы в БД достаточно давно и успешно, чтобы не думать об этом,
и да, фрондэнд системы на Делфи, и не просто на Делфи, а на Делфи 7, если вы понимаете о чём я

а по существу исходного вопроса темы, чтобы закрыть тему и зафиксировать для истории -
где тут иконка про посыпание головы пеплом?! :))

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


всем cпасибо за помощь!