moris пишет:

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

Ой, что-то я сильно сомневаюсь в правдивости этих слов.

Планы строятся на процедуры, триггера или запросы. View при этом
расшивается (подставляется в исходный запрос), и, на сколько я знаю,
и вообще-то это очень логично, плана на VIEW отдельного не строится.
Следовательно, его нет в процедурном кэше и нет нужны очищать кэш
при его использовании. Но с другой стороны, в кэше могут находится
планы запросов и процедур, использующих эту view. Тогда надо пересоздавать,
но не VIEW, а эти процедуры или запросы. Или выполнять их с with recompile
один раз, чтобы заново наполнить процедурный кэш.

Но если подходить чисто формально, то в документации сказано чётко
и ясно -- при любых изменниях таблицы нужно пересоздать все объекты,
ссылающиеся на эту таблицу, а значит и VIEW тоже.

На практике мы НЕ пересоздаём VIEW, а переливаем нужные процедуры.
Или выполняем их с with recompile один раз. Этого достаточно, но,
естественно, только для этой конкретной процедуры.
Posted via ActualForum NNTP Server 1.4

Kru wrote:

> Ситуация понятна - вьюху и использующие её процедуры и триггеры нужо
> будет перекомпиллить.

Да говорю же, не обязательно. Только процедуры и триггера.
Posted via ActualForum NNTP Server 1.4

Kru пишет:

> Хотелось бы услышать мнение, насколько подобное решение надёжно.

Ну, если следовать документации, надо именно пересоздавать объекты.
sp_recompile этого не делает. Она только очищает процедурный кэш
от плана запросов всех объектов, зависящих от данного (как вычисляются
зависимости, кстати, отдельный разговор, если по sysdepends, то
надёжно это работать будет только для table & view.)
Posted via ActualForum NNTP Server 1.4