Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Задался вот каким вопросом. Зачем unique constraint на таблице требует обязательного наличия индекса, уникального или нет, по всем полям, входящим в уникальный ключ?
Сама вариативность уникальный/неуникальный индекс наводит на мысль, что индекс как таковой используется только для быстрого поиска строк для блокировки.
У меня периодически возникает желание сделать уникальный ключ по индексу, включающему в себя только часть полей. Например, ключ состоит из колонок a1 .. a6, причем a1,a2 дает селективность в ~ 10 строк. Индекс по ним будет размером куда меньше, нежели индекс по всем 6 полям, а для цели отобрать и заблокировать до окончания транзакции строки его вполне достаточно.
20 мар 12, 11:46    [12279692]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
Vint
Member

Откуда: Москва
Сообщений: 4564
collow,
стоит почитать документацию и прекратить хотеть странного...
зы. на луну не хочется слетать за пол часика? с среднесветовой скоростью это дело пяти минут....)
20 мар 12, 11:49    [12279723]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Документацию в плане как есть? Я это знаю. Документацию в плане почему так? Вот это не встречал. Дайте ссылку, если не затруднит?
20 мар 12, 12:43    [12280244]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
Vint
Member

Откуда: Москва
Сообщений: 4564
collow,
в "документации как есть" - объясняется почему "именно так".
"уникальный ключ по индексу ... селективность в ~ 10 строк" - это "бред сивой кобылы"(или "мерина")
20 мар 12, 13:21    [12280591]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Ссылки тем не менее не последовало.
Поясните, что именно считаете бредом и почему?
20 мар 12, 13:32    [12280707]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
Vint
Member

Откуда: Москва
Сообщений: 4564
collow,
я Вам ничем не обязан) учись искать информацию.
20 мар 12, 14:07    [12281055]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Ага, уже теплее, но все равно не то. Я и не искал, признаться, причину во внутреннем строении блока.
Новым для меня была блокировка блока уникального индекса, а не строки таблицы, если это действительно так. Надо проверить. Потому что из этого будет следовать, что если используется под уникальным констрейнтом неуникальный индекс, то будут блокироваться все строки, попадающие в блок. Ну, может путано написал.

Но тем не менее, из ссылки не вытекает ничего, что объяснило бы, зачем индексу все поля ключа.
20 мар 12, 17:09    [12282937]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
индукс
Guest
collow
Задался вот каким вопросом. Зачем unique constraint на таблице требует обязательного наличия индекса, уникального или нет, по всем полям, входящим в уникальный ключ?


А как можно обеспечить целостность по-другому, не через индекс?
20 мар 12, 17:14    [12282980]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
-2-
Member

Откуда:
Сообщений: 15330
индукс
А как можно обеспечить целостность по-другому, не через индекс?
для операции удаления можно уникальность и без индекса обеспечить.
20 мар 12, 17:20    [12283034]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Например, для обеспечения целостности на внешних ключах без индекса производится блокировка всей таблицы.
20 мар 12, 17:21    [12283043]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
ukku
Member

Откуда: 59
Сообщений: 195
индукс,

на уравне процедур и триггеров.
20 мар 12, 17:21    [12283047]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
индукс
Guest
collow
Например, для обеспечения целостности на внешних ключах без индекса производится блокировка всей таблицы.


Причём тут внешний ключ.

Исходная ситуация: таблица table1, должна быть уникальность ключа по полю field1.
Индекса по полю field1 нет.

Вопрос: как обеспечить уникальность при insert, update?
20 мар 12, 17:31    [12283116]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
индукс
Guest
ukku
индукс,

на уравне процедур и триггеров.


каких процедур, каких тригерров?
Как понять, что данного значения в столбце нет, если не по индексу - только фулскан.
Вы будете на каждый insert, update делать фулскан?
20 мар 12, 17:33    [12283136]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
ukku
Member

Откуда: 59
Сообщений: 195
индукс,
То что это плохо другой вопрос, вопрос был КАК кроме индекса - да и индекс будет на два поля, так что уже врятли фулл скан. ТС то хоть как скорее всего фигней страдает.
20 мар 12, 17:39    [12283184]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Внешний ключ как пример того, что может выполняться лок + фуллскан. И заявление типа "это плохо" - не катит, потому что бывают разные ситуации.
20 мар 12, 17:47    [12283226]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Я просто хочу прояснить для себя, почему логика именно такова. Чисто академический интерес, не более.
20 мар 12, 17:48    [12283239]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
индукс
Guest
collow
Внешний ключ как пример того, что может выполняться лок + фуллскан. И заявление типа "это плохо" - не катит, потому что бывают разные ситуации.


Это не плохо - это очень плохо.
1) Интенсивное использование FTS - это buffer busy wait, cache buffer chains - это ожидания на которых вы будете просто висеть и ничего полезного не делать

2) Блокировка всей таблицы при работе внешнего ключа, без наличия индекса - как следствие массовые deadlock ora-060

Если вы не понимаете, как работает Oracle, вам рано делать выводы о необходимости того или иного.
20 мар 12, 17:51    [12283265]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Если эта таблица модифицируется только одной сессией в принципе, то все блокировки меня мало волнуют. Индексы на чтение далеко не всегда совпадают с индексами на модификацию для устранения фуллсканов. Ну и т.д. Ситуации бывают, когда полный лок таблицы не есть плохо. И не надо тут рассказывать свое понимание того, как базе работать будет лучше.
20 мар 12, 18:22    [12283491]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
индукс
ukku
индукс,

на уравне процедур и триггеров.


каких процедур, каких тригерров?
Как понять, что данного значения в столбце нет, если не по индексу - только фулскан.
Вы будете на каждый insert, update делать фулскан?

гыгы. это - чистая очевидность (в том числе - даже и безотносительно сабжа )
на самом деле - возможны варианты. индекс может быть, но не уникальный да и не полный по составу полей ключа.
партишенинг тоже добавляет вариантов реализации. можно (если таки нужно) ключ строить не над самой таблицей, а над коммиттошным матвью над ней.. на крайняк - и на вопрос
автор
Вы будете на каждый insert, update делать фулскан?

ответ не однозначный (т.е. в зависимости от расклада - может быть и "да" )
20 мар 12, 18:24    [12283501]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Про матвью знаю вариант, фактически, это поддерживаемый системой процедурный способ обеспечения уникальности. Но не всегда их можно применить, к сожалению, на fast refresh.
20 мар 12, 18:29    [12283530]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
ukku
Member

Откуда: 59
Сообщений: 195
collow, вы память на индекс жалете, какая вам мат. вьюха)
20 мар 12, 18:31    [12283543]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Ну так я его и не использую :)
20 мар 12, 18:32    [12283548]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
индукс
Guest
collow
Если эта таблица модифицируется только одной сессией в принципе, то все блокировки меня мало волнуют. Индексы на чтение далеко не всегда совпадают с индексами на модификацию для устранения фуллсканов. Ну и т.д. Ситуации бывают, когда полный лок таблицы не есть плохо. И не надо тут рассказывать свое понимание того, как базе работать будет лучше.


Это не моё понимание. Так работает Oracle.
Но в чём вы правы, в том, что даже будучи очень зелёным админом, много лет назад, не сталкивался с такой ситуацией, гениальной как у вас - "таблица модифицируется одной сессий".
20 мар 12, 18:40    [12283587]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
Vint
Member

Откуда: Москва
Сообщений: 4564
индукс,
значит мало систем видели) представте себе систему где все глобальные настройки APP сервера хранятся в 1 таблице. и только суперадмин, который 1. может в эксклюзивном режиме ее изменять))

collow
прошу пояснить фразу "индекс на модификацию для устранения фуллсканов" - это что за зверь?
вообще из всех словоизлияний, понял только то, что Вы сами не знаете чего хотите. и чётко вопрос сформулировать не можете... от этого все проблемы.
20 мар 12, 18:47    [12283631]     Ответить | Цитировать Сообщить модератору
 Re: Unique constraint + index  [new]
collow
Member

Откуда:
Сообщений: 324
Индекс на модификацию - имел ввиду что модифицировать обычно надо по первичному ключу, а читать - по другим ключам. Например, если есть суррогатный первичный и уникальный естественный. То есть выборка строк для модификации использует обычно не те индексы, которые использует выборка для построения отчета.

Хочу я сформулировал по-моему четко: понять, почему принципиально нельзя подсунуть "частичный индекс" под уникальный ключ, чем собственно он принципиально отличается от неуникального индекса.
И попутно еще родился вопрос - а зачем собственно есть возможность использовать неуникальный индекс? В каких случаях это может быть востребовано, за исключением очевидных "был старый неуникальный индекс, логика поменялась, навесили констрейнт, и не хотим делать новый/пересоздавать старый индекс.
20 мар 12, 18:58    [12283682]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить