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

Не обязательно.
Posted via ActualForum NNTP Server 1.4

spc пишет:

> В хранимке необходимо создавать временные таблицы и индексы на них,
> которые затем используются в запросах
>
> Например,
>
> create table #tmp (
> id numeric(*15*, *0*)
> ,name varchar(*255*)
> )
> create index i1 on #tmp(name)
>
> set forceplan on

Вам здесь forceplan не нужен, вам нужен хинт на индекс.
Это разные вещи. forceplan on убирайте, а если впредь
будете ставить, то ставьте ТОЛЬКО НА ОДИН КОНКРЕТНЫЙ
ЗАПРОС, а после него убирайте. Иначе можете поиметь
очень много проблем с фактически отключенным оптимизатором.

>
> insert #tmp
> select top *100000* it.InstitutionID, it.Name
> from tInstitution it
>
> select *
> from #tmp t (index i1)
> where t.name like 'Иванов%'
>
> drop table #tmp
>
> этот скрипт индекс не использует
>
> Index 'i1' specified as optimizer hint in the FROM clause of table '#tmp' does not exist. Optimizer will choose another index instead.

Процедура оптимизируется ДО выполнения, и комманда create index еще не успевает
отработать, поэтому индекса еще нету. Текст процедуры анализируется на предмет
создания временных таблиц, но не на предмет создания индексов на них.
Вот это причина того, почему это не работает. Но вообще вопрос сложный.

0) То, что порекомендовал komrad - это правильно, и это один из подходов
к решению этой проблемы. Но он не единственный и возможно даже не нужный.
Объяснения ниже.

1) Создавать индекс имеет смысл ПОСЛЕ вставки данных во временную таблицу.
Во-первых, вставка будет быстрее, во-вторых, CREATE INDEX соберет уже реальную
статистику с таблицы. Хотя, если мы будем форсировать индекс, она нас уже мало
интересует.

2) Указывать индекс в хинте можно не только по имени индекса, но и по его
номеру. В этом случае оптимизатор не проверяет наличие индекса, а тупо его
использует. Вставляет в план, а потом процессор запросов уже во время
выполнения если его не найдет, будет план подгонять. Номер индекса в хинте -
это на самом деле просто идентификатор индекса для этой таблицы в sysindexes,
т.е.

0 - это сама таблица (table scan) для heap-таблиц (без кластерного
индекса или DOL-таблиц (они все heap).

1 - это кластерный индекс для APL-таблиц, он же - сама таблица.

>1 - все остальные индексы (nonclustered index or a clustered index
on a data-only-locked table).

Пишется это так:

2 здесь - наиболее вероятное зачение именно этого индекса, потому как он
некастерный , а других индексов нет. Но вы должны четко знать номер индекса
в вашей конкретной таблице, это зависит от типа таблицы (APL/DOL), от типа
индекса (clustered/nonclustered) и от порядка создания индексов. В случае
каких-то сомнений можно создать такую же невременную таблицу с индексами
и посмотреть вывод sp_helpindex или напрямую содержимое sysindexes.

3) Ну и совсем теоретическое отступление - дело в том, что вопрос-то
часто поднимается всем сообществом пользователей ASE, и когда он задавался
в sybase.public.ase.performance+tuning , Eric Miner, инженер группы
оптимизатора, если не ошибаюсь, ведущий, уверял, что такое ДОЛЖНО
работать в современных версиях ASE (тогда была 12, и только вышла 12.5).
Что при этом, когда изменяется схема таблиц, в том числе и временный,
во время выполнения процедуры, увеличивается внутренний счетчик схемы
в сервере и это должно приводить к тому, что план процедуры пересоздается
с учетом изменений в схеме и далее уже выполнение идет по новому плану,
с учетом индекса. Т.е. CREATE INDEX на временную таблицу должен приводить
к пересозданию плана и к видимости этого индекса для запроса. НО правда
в рассматриваемом нами случае сообщение возникает, конечно же, при первом
создании плана, а используется ли индекс во втором плане, в общем, и не
известно.

Я не смог найти конкретно ту ветку, в которой выступал Eric, но
вот что-то аналогичное, где Iann излагает что-то похожее.

http://groups.google.com/group/sybase.public.ase.performance+tuning/browse_frm/thread/96f2232fb08f369b/b1f7650bdff9616d?lnk=gst&q=temporary+table+index&rnum=5#b1f7650bdff9616d

Так что в общем, я думаю, если бы индекс создавался ПОСЛЕ заполнения данных,
и не использовался бы хинт (index) , то я думаю индекс бы пошел в запрос,
конечно, при условии его полезности для запроса (высокой селективности индекса).

Итог: выполните требования пунктов 1) и 2) и будет работать.
Posted via ActualForum NNTP Server 1.4