Гриценко А.В.PS
create statistics - только ухудшало ситуацию в моем конкретном случае

Не, ну что тут сложного?! Если есть КОНКРЕТНЫЙ запрос, который после построения статистики начинает тупить, то надо его взять и проанализировать. Смысл не в том, чтобы перебрать все запросы, а в том, что разворачивая конкретную ситуацию можно докопаться до истинной причины торможения множества запросов, до некой системности. Понимаете?

Вот у меня проблема обратная, иногда и непредсказуемо портится статистика. Ее перестроение решает проблему, запросы начинают выполняться нормально. Но не буду же я каждый час перестраивать по шедулеру статистику?! Вот это дейстивтельно проблема. А когда со свежей статистикой запрос идет корявым путем, так это железобетонно причина либо в запросе, либо в структуре БД.

Скорее всего здесь дело именно в неверной структуре. Судя по всему, в результирующий набор попадает очень много данных при низкой селективности tdoc.kol_op и tdoc.ntipdoc. Это становится равносильно сканированию таблицы со всеми вытекающими. Нужно ограничить объем выборки, либо условием и индексом по дате, либо модификаторами TOP N. Может нужно показать оператору только первые/последние? Или по какому-то условию и он что-то ищет? Или грамотный пэйджинг организовать нужно? Ну в чем смысл получения четверти ВСЕЙ таблицы на клиента? С годами такие системы будут только тяжелеть, пока все не встанет.

И второй момент. Как оцениваете скорость выполнения запроса? В ISQL? Ну тут есть подводный камень. При насильном указании индекса может сложится впечатление, что все хорошо, запрос отрабатывает, данные быстренько попадают в ISQL. Но это ложное впечатление, т.к. на получение ПОЛНОГО набора данных серверу придется работать гораздо дольше. А ISQL прекращает выполнение запроса сразу после получения первых ХХХ записей, а это не одно и тоже.

И еще один момент. Есть такая опция, которая кардинально может поменять поведение сервера. OPTIMIZATION_GOAL. Все запросы на сервере будут выполняться, либо с точки зрения сокращения времени получения первой порции данных, либо общего времени получения данных (по умолчанию). Мало ли, вдруг она попорчена кем-то...

авторКонечно можно оптимизировать структуру данных для конкретного запроса, например
создать некое расчетное поле к примеру act=if kol_op*ntipdoc>0 then 1 else 0 endif c индексом по нему специально для такого запроса и условие поменять на act=1.

Такого рода поля - флаги, очень плохие с точки зрения единственного условия поиска. Среднестатистически, флаг с двумя значениями поделит таблицу пополам. Если три значения, то на три части. Смысл в нем и его индексе, если эту безграмотность сервер в основном будет игнорить? Игнорить не будет только опираясь на свою статистику. Но при проектировании, не нужно полагаться на способности сервера. А у Вас "кривое" проектирование. Пока все влезает в кэш, будет все работать быстро. Пока данные упорядочены (после ребилда), тоже все будет работать быстро, т.к. данные последовательно начитываются в кэш и последовательное чтение таблиц несильно заметно. Но это все только "пока", до недавнего времени.

авторПохожие проблемы наблюдались давно и на разных базах
те в 9-й версии все то же самое - база "стареет" и начинает тормозить
Проблема не в отдельных запросах а в общей тенденции
Общая тенденция - безграмотность.

Упертость и "глухота", вот что Вам мешает решить проблемы. Для начала разобраться какой объем выборки действительно нужен пациенту. Если для печати отчетов - это одно дело, там можно ввести их ночную подготовку (или преподготовку), если на экран юзеру, то какого лешего читать всю живую таблицу? Если данных под запрос попадает мало, а таблица здоровая, то подумать над тем, как это множество однозначно изолировать от остального при помощи одного индекса.

Гриценко А.В.iLLer,
Вам бы лучше помолчать если по делу сказать нечего...


Вам по делу было сказано не один раз. Если сударь изволит игнорировать ответы, то нечего ходить на форумы и спрашивать. А раз задаете вопросы, то надо их не только видеть, но и читать. И нечего обижаться на "безграмотность". Вещи надо называть своими именами. И постыдного в этом ничего нет, это не обзывательство.

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