Ищу пояснения по полям User

← →
Desdechado © (2006-10-17 17:50) [0]

ORA 9.2 Enterprise Edition

Тех, что описаны в документе A96536-02, недостаточно. Уж слишком там кратко. Если кто поделится ссылочкой, буду очень благодарен.

В частности, очень интересует, что значит поле NUM_ROWS для BITMAP-индексов.
Для NORMAL-индекса это вроде кол-во индексированных ключей.

PS на SQL.ru почему-то тему зарубили :(

← →
evvcom © (2006-10-17 18:32) [1]

Я создал сейчас битмап индекс на столбец, в таблице 2 записи. В индексированном столбце 1 запись null, другая not null, выполнил селект из User_Indexes. NUM_ROWS в результате null. Сделал Analyze Index, в результате 2. Добавил еще пару таких же записей и analyze. В результате 4. Т.е. количество записей.

> Для NORMAL-индекса это вроде кол-во индексированных ключей.

Наверное, все же проиндексированные записи имелись ввиду?

← →
Desdechado © (2006-10-17 18:41) [2]

вот из реальной БД:

index_name, index_type, distinct_keys, num_rows ----------------------------------------------- FK_ZAYAVKA_OBJNAMES NORMAL 987 188262 FK_ZAYAVKA_REGIONS BITMAP 14 22

← →
Desdechado © (2006-10-17 18:43) [3]

> все же проиндексированные записи имелись ввиду?
Нет, именно ключи. Бо NULL не индексируется (отсутствует) в NORMAL-индексах.

← →
ANB © (2006-10-17 18:45) [4]

> Бо NULL не индексируется (отсутствует) в NORMAL-индексах

Не знаю, не знаю. Запрос Is null работает заметно шустрее на индексированном поле.

← →
evvcom © (2006-10-17 18:46) [5]

А эти индексы
> FK_ZAYAVKA_OBJNAMES
> FK_ZAYAVKA_REGIONS

к одной таблице?

← →
evvcom © (2006-10-17 18:49) [6]

> [4] ANB © (17.10.06 18:45)
> Не знаю, не знаю.

null-ы точно не индексируются в NORMAL. Если индекс составной, тогда там хитрее.

> Запрос Is null работает заметно шустрее на индексированном
> поле

может is not null? И то не факт, что индекс будет выбран. План смотри.

← →
evvcom © (2006-10-17 18:53) [7]

Пока нет ответа на [5], (думаю таблицы разные) мои предположения. В битмапе у тебя всего 22 строки, из них различных значений поля 14. Null здесь индексируется.
В normal у тебя 188262 не нульных записи, и из них 987 различных значений.

← →
Desdechado © (2006-10-17 18:56) [8]

evvcom © (17.10.06 18:46) [5]
К одной. У меня правило именования такие:
FK = Foreign KEY
затем имя таблицы, которая индексируется
затем имя таблицы, на которую FK ссылается
затем (при необходимости) имя поля в таблице, на которую FK ссылается

← →
Desdechado © (2006-10-17 18:57) [9]

статистика, естественно, собрана

← →
Desdechado © (2006-10-17 18:59) [10]

> Запрос Is null работает заметно шустрее на индексированном поле.
Кайта читай, план смотри.
IS NULL вызывает полный перебор таблицы.

> [8] Desdechado © (17.10.06 18:56)
> К одной

Да, я уже потом подумал об этом.
Дропнул индекс из [1] и создал заново. DISTINCT_KEYS/NUM_ROWS стало 2/2. Добавил еще запись: 2/3. Еще запись 2/4. Опять drop/create: 2/2.
Похоже NUM_ROWS отображает какое-то внутреннее количество каких-то строк в битмап-индексе и может говорить, видимо, только об оптимальности занимаемого индексом места, а стало быть эффективности его использования. Информация для админа, видимо.

> IS NULL вызывает полный перебор таблицы.

Действительно, по плану - фулл скан.

Однако :

создал таблицу на 10 миллионов записей. В каждой 1000-й записи - налл.
Дернул is null. Сервер лег.
Проиндексировал поле (индекс обычный, не уникальный). Дернул - 5 секунд.

> Проиндексировал поле (индекс обычный, не уникальный). Дернул - 5 секунд.
Прокэшировалась.

Вообще-то я просил ссылку на материалы по этому поводу, если кто находил.

Кому интересно, продолжение дискуссии здесь
http://sql.ru/forum/actualthread.aspx?bid=3&tid=351036&pg=-1

Поучительно. Все из понимания внутреннего устройства. Кое-что из этого знал, на курсах говорили, но говорили очень уж туманно. А кое-чего действительно не знал, потому не понимал.

Ищу пояснения по полям User_Indexes Найти похожие ветки