Наконец таки я закончил свой многострадальный труд " Все что мы знаем об индексах в ASA ". Не гарантирую конечно, что я там все полностью выложил в описаниях и все правильно, но более менее вроде похоже на правду. Жду замечаний и критики.

P.S. Думаю этот труд и можно будет выложить в сентябрьскую рассылку по ASA.

Кстати, в ASA есть такая пынька, как оракловые кластерные таблицы? (просто спросил).
Скорее всего нет, но для этого нужно мне разжевать, что это такое и чем они отличаются от обычных таблиц с кластерным индексом.

авторБитмап-индексы, видимо, это уже для IQ? (просто спросил)
Угу, ASA не так давно вылезла из детских штанишек Workgroup, а именно с 9-ой версии и постепенно подтягивается до уровня Enterprise. Благо ее движок работает и для IQ и уже изначально ясно, куда нужно подтягиваться :)

автор ASCRUSуникальные индексы позволяют ASA эффективно реализовывать механизм блокировок, снимая кол-во блокировок
Как именно? Тема не раскрыта.
Тема не раскрыта, потому что она уже касается принципов работы оптимизатора, а не индексов :) Вкратце: при наличие уникального ключа оптимизатор ASA использует специальные механизмы для вставки, изменение и удаления записей, которые вместо блокирования записей в таблице блокируют нужные ноды в индексе, таким образом с одной стороны контролируя ненарушение уникальности по заявленным полям, но с другой стороны не блокируя другие записи, которые не были затронуты при модификации, а значит позволяя по ним проводить выборки. Этими и другими алгоритмами достигается "честная" позаписная блокировка и в ASA можно быть всегда уверенным, что сессия проводя транзакцию блокирует только изменяемые данные, что с одной стороны снимает лишнюю головную боль по борьбе с блокировками, а с другой стороны позволяет "лично" блокировать и контролировать записи, изменение которых было бы нежелательно по правилам производимой в транзакции бизнес-логики. Добавлю, что PAGE-LOCK в ASA нет, есть SHARE-LOCK, ROW-LOCK и TABLE-LOCK (вызывается оператором LOCK TABLE).

авторПонравилось, что есть такая возможность. Но что-то я сомнечаюсь насчет описанного сочетания PCTFREE и эффективности кластерного индекса. Он сам по себе неэффективен при модификации ключевых полей. Не могли бы Вы привести (провести) сперимент, разделяющий влияние кластерного индекса и PCTFREE?
Хорошо - провожу эксперимент. Есть у меня не маленькая табличка, по составному PRIMARY KEY стоит кластерный индекс. Так как при выборках никто не гарантирует, что записи будут возвращаться в том порядке, как они в таблице стоят, то выгружаю без сортировки их в файл командой UNLOAD TABLE. Далее изменяю у последней записи первичный ключ так, чтобы запись по идее была бы первой. Выгружаю в файл и смотрю - осталась последней. Далее добавляю запись в таблицу с ключом, который должен ее поставить в число первых записей. Выгружаю в файл и смотрю - так и есть, стоит самой первой (хотя по идее должна стоять 7-ой). Какие выводы мы делаем из такого эсперимента:
1. Как я и говорил, у ASA кластерные индексы отличаются от обычных в нашем понятии кластерных индексов.
2. При обновлении ключевых полей кластерного индекса ASA никуда запись не дергает и оставляет на своем месте.
3. При добавлении записей ASA ищет подходящую страницу в таблице по кластерному индексу и добавляют запись в наиболее близжайшую по значению, где есть свободное место. При этом физически записи на странице таблицы не сортируются, в основном ASA стремиться к тому, чтобы рядом лежали.
4. Кластерный индекс на таблицу при таких условиях не сильно тормозит операции вставки, вообще не тормозит при обновлениях и фактически регулируется самим приложением, которое периодически само должно дефрагментировать таблицу.
4. По идее при таких вот выводах все что я сказал про PCTFREE должно быть верно.

автор ASCRUSПосле выявления "тормозящего" запроса, которое можно сделать через профайлер хранимых процедур, дебаггер или же просто путем его вычисления
Непонятно, что означает "путем его вычисления". (просто спросил)
Профайлер ХП в ASA позволяет собирать информацию по всем выполняющимся ХП, UDF и триггерам, регистрируя время выполнения, кол-во вызовов и процент от общего выполнения времени. При чем так же ведеться детальная расшифровка по каждой строке скрипта обьекта. Очень удобно - отсортировал по большему времени, вошел в ХП и там посмотрел, где затык.
Дебаггер является полноценным отладчиком и можно нащелкать бряк-пойнтов, поставить на них если надо условия и пошагово двигаться в нужном направлении, попутно просматривая локальные, глобальные переменные, а так же выполняя прямо из под сессии отладки нужные запросы (вплоть до триггерных таблиц Inserted и Deleted) и вживую глядя на планы запросов. Ну а путем вычисления я называю все остальное - запуск консультанта индексов, который так же попытается по полочкам разложить запросы и чего нибудь посоветовать, вставка в скрипты посыла сообщений клиенту с текущим временем и т.д. (люди с MSSQL например любят еще в табличку писать всякие сообщения, чтобы поймать тяжелый запрос).

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

авторКстати, ASA умеет делать zig-zag ordered scan в случае если такой индекс будет в наличии? (просто спросил)
Без понятия, так как не знаю ничего про "зигзаги" :)

автор ASCRUSЧем больше значений имеет поле индекса, тем больше веток имеет индекса, а значит он занимает больше страниц в базе данных
Это про составной индекс. Есть ли какие численные оценки, как зависит число дисковых операций от разветвленности составного индекса?
В ASA есть специальные процедуры (одна из них упоминалась в статье), которые позволяют посмотреть кол-во уровней вложенности индекса, его расположение на таблицах, фрагментированность, PCTFREE и другие параметры.

автор ASCRUSЭто достаточно быстрая операция, хотя по стоимости она чуть больше, чем операция равенства
Ой-ли? Так уж и чуть? А если недостаток кеша?
Действительно быстрая. Ничем не медленнее, чем соединить с большой табличкой через INNER JOIN маленькую, в принципе такая же операция, только что вместо маленькой таблички виртуальный массив IN.

автор ASCRUSВ данном случае будет целесообразней вместо "OR" разбить запрос на серию аналогичных запросов, соединенных через "UNION ALL", где на каждый запрос накладывается условие из части условия "OR"
В 21-м веке оптимизатор должен это делать автоматически, точнее, в своем внутреннем представлении приводить эти два запроса к одному и тому же. (мысли вслух)
Думаю к этому придет, сейчас идет активное обсуждение среди разработчиков 10-ой версии и много чего планируется делать.

автор ASCRUSОднако оптимизатор ASA умеет во время выполнения запроса использовать только один индекс на таблицу
Ламеры они.
Очень спорный вопрос для блокировочника. MSSQL умеет много индексов использовать на таблицу, однако помниться с этим столько проблем возникало, что пусть уж лучше так. Во всяком случае это приучает разработчиков не лепить индексы на все поля для всех случаев жизни, а сначала думать головой.

авторМолодец. И пусть Вас не страшат слова типа "для этого понадобится написать книгу". Кому надо - те прочитают.
Большое спасибо за комментарии и похвалу :)

авторНе только. Еще увеличивается пространство возможных планов запроса в котором осуществляется поиск. Как следствие - возможен выбор худшего (по сравнению с тем, который выбирался) плана исполнения, даже если вновь созданный индекс использоваться и не будет.
Еще замечание (но может быть это от того, что я быстро прочитал статью и не
нашел этого). Если таблица занимает всего несколько страниц данных,
то для поиска _одного_ значения в этой таблице всегда будет эффективнее table scan. В других случаях, при таком размере таблицы есть варианты (в зависимости от количества записей в странице), но в этом случае выигрыш будет мнимальным, т.к. весь поиск осуществляется в ОЗУ.

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

авторТакже, возможно, следует упомянуть о покрывающих индексах.
Для ASA в этой статье упоминать о них нельзя, так как оптимизатор не поддерживает такую возможность.

Добавлена статья " Как простому пользователю обратиться к таблице не указывая ее владельца? ".

Добавлена статья " Сохранение и открытие графического плана запроса ".

Нет, не наблюдал. А что VALIDATE говорило на БД ?

P.S. Кстати на сваливание сервера могла повлиять фича с кэшем ХП: когда изменяется структура таблиц, то нужно или перекомпилить все обьекты, которые на нее ссылаются или же перегрузить сервер. Иначе если они уже висят в кэше, ASA попытается их выполнить и результатом может быть от ошибок до сваливания сервера. Например, в ХП у нас стоит SELECT * FROM Table1, мы ее выполняем, потом с таблицы удаляем 10 полей и при новом выполнении ХП получим ошибку, что такие то поля не существуют. А если бы запрос был покруче, то могли бы и ошибки получить покруче.

Если будет еще раз такая проблема, то я рекомендую поиграться с опциями запуска сервера "-cc", "-cr" и "-cv", которые отвечают за сохранение кэшированных страниц в БД и поднятии их при запуске сервера.

угу, иногда помогает. особенно в случаях, когда процедура вызвается как SELECT * FROM Procedure() и в таблицах, которую она использует изменилась структура.

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