Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Блокировки при одинаковом ключе в индексе  [new]
ONO
Guest
Коллеги нужен совет.

Есть таблица строк документов. В ней введены поля :

1. дата создания
2. дата изменения.

Можно еще время добавить, но пока не добавляли. Возникла необходимость отбирать записи с фильтром по этим полям. (По ночам работает выгрузка в OLAP и сканирование таблиц из-за их разрастания стало напрягать дисковую подсистему - возникла идея выгружать только последние изменения)

Соответственно напрашивается индекс по указанным полям.

Но есть один вопрос. При активной вставке документов с разных рабочих мест (а их не меньше 20) не будет ли проблем блокировки страницы индекса ? Просто доводилось слышать мнение, что не стоит делать такие индексы. Типа, при вставке движок базы долбится в одну и ту же страницу индекса и блокировки идут, параллелизм нарушается. Правда это говорилось про MS SQL а у нас оракл.

Что скажете ?
11 апр 06, 13:59    [2547783]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
ONO
Что скажете ?

1) В oracle нет ни "страниц", ни механизмов их блокировки.
2) Неким аналогом может служить "горячий" блок, но весьма отдаленным и сложно получаемым на 20 клиентах.
3) Решение же Вашей задачи лежит скорее в области partitioning нежели в области индексирования.
11 апр 06, 15:02    [2548133]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
Desperado
Guest
ONO

Что скажете ?


скажем, что это баг mssql завется row escalation, оракл считает, что блокирование лишних строк приводит к ухудшению конкурентого доступа и всегда блокирует на уровне строк.
11 апр 06, 15:27    [2548283]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
ONO
Guest
Desperado
ONO

Что скажете ?


скажем, что это баг mssql завется row escalation, оракл считает, что блокирование лишних строк приводит к ухудшению конкурентого доступа и всегда блокирует на уровне строк.



Неее
Насколько я понял проблема там была не в эскалации блокировок, а в попытке получить одновременно доступ к одной и той же странице индекса содержащей ссылки на записи с одинаковым значением ключа и вроде как проявлялось прежде всего для кластерных индексов.
11 апр 06, 15:48    [2548443]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
второй клиент
Guest
andrey_anonymous
1) В oracle нет ни "страниц", ни механизмов их блокировки.

В Oracle это просто называется блоком. И есть механизмы их блокировки.

andrey_anonymous
2) Неким аналогом может служить "горячий" блок, но весьма отдаленным и сложно получаемым на 20 клиентах.

Легко получаемым и на 2 клиентах.

PS автору.
Проблема будет. Имя ей - buffer busy waits. Большая или нет - зависит от активности и типа вставок.
Ее единственное полноценное, простое и эффективное решение лежит в реверсивных (reverse) индексах. Есть ограничения. Описаны в доке.

Все остальное сложнее и требует больше мороки, а эффект - меньше.

P.S. Если вставка всегда идет в один блок, то секционирование (partitioning) эту проблему не решит.
11 апр 06, 16:23    [2548658]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
второй клиент
andrey_anonymous
1) В oracle нет ни "страниц", ни механизмов их блокировки.

В Oracle это просто называется блоком. И есть механизмы их блокировки.
Хмык, и какие механизмы блокирования блоков Вы имеете ввиду?
второй клиент
andrey_anonymous
2) Неким аналогом может служить "горячий" блок, но весьма отдаленным и сложно получаемым на 20 клиентах.
Легко получаемым и на 2 клиентах.
Это надо очень-очень постараться :)
второй клиент
P.S. Если вставка всегда идет в один блок, то секционирование (partitioning) эту проблему не решит.

Простите, Вы про какую проблему?
Обратитесь к началу топика:
автор
Возникла необходимость отбирать записи с фильтром по этим полям. (По ночам работает выгрузка в OLAP и сканирование таблиц из-за их разрастания стало напрягать дисковую подсистему - возникла идея выгружать только последние изменения)
11 апр 06, 16:29    [2548699]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
ONO
Guest
>> Возникла необходимость отбирать записи с фильтром по этим полям. (По ночам работает выгрузка в OLAP и сканирование таблиц из-за их разрастания стало напрягать дисковую подсистему - возникла идея выгружать только последние изменения)

На самом деле это только часть проблемы. Наши разработчики захотели решить её при помощи введения полей дата вставки - дата последнего изменения (и подумывают надо внесением еще и времени)

Вот я и спрашиваю, такой подход не приведет ли к блокировкам при одновременной вставке записей / апдейте.

Так как в таком случае совпадают значения указанных полей.
11 апр 06, 16:53    [2548868]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
двадцатый клиент
Guest
andrey_anonymous
Хмык, и какие механизмы блокирования блоков Вы имеете ввиду?

Buffer pin. Плюс очереди (из buffer handles) их удерживающих и ожидающих.

andrey_anonymous
Это надо очень-очень постараться :)

Элементарно, Watson ;)

andrey_anonymous
Простите, Вы про какую проблему?
Обратитесь к началу топика:

Я обратился к концу :)
ONO
Но есть один вопрос. При активной вставке документов с разных рабочих мест (а их не меньше 20) не будет ли проблем блокировки страницы индекса ? Просто доводилось слышать мнение, что не стоит делать такие индексы. Типа, при вставке движок базы долбится в одну и ту же страницу индекса и блокировки идут, параллелизм нарушается
11 апр 06, 17:05    [2548944]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
ONO
Guest
А как тогда обходить эту проблему ?

Это же везде и в других местах может вылезти.
11 апр 06, 17:15    [2549019]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
двадцатый клиент
andrey_anonymous
Хмык, и какие механизмы блокирования блоков Вы имеете ввиду?

Buffer pin. Плюс очереди (из buffer handles) их удерживающих и ожидающих.
Да-да. Именно блокировки :)
двадцатый клиент

andrey_anonymous
Это надо очень-очень постараться :)

Элементарно, Watson ;)
Вы о том, что с дуру можно и ... сломать?
двадцатый клиент
andrey_anonymous
Простите, Вы про какую проблему? Обратитесь к началу топика:

Я обратился к концу :)
Напрасно, поскольку оригинальная проблема (ограничение объемов выгрузки в OLAP) вполне решается partitioning и не требует создания каких-либо индексов ;)
11 апр 06, 17:19    [2549035]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
andrey_anonymous
двадцатый клиент
andrey_anonymous
Хмык, и какие механизмы блокирования блоков Вы имеете ввиду?

Buffer pin. Плюс очереди (из buffer handles) их удерживающих и ожидающих.
Да-да. Именно блокировки :)


Хочется чтобы было слово LOCK?

Oracle8i Internal Services for Waits, Latches, Locks,
and Memory
Steve Adams

4.1 Lock Usage
...
4.1.2 Buffer Locks
Row-level locks protect data integrity at the lowest feasible level of granularity,
and remain in force for the duration of a transaction. However, Oracle also needs
short-term block-level locks to be in force while accessing or modifying blocks in
its cache.
...
4.7 Buffer Locks
A form of enqueue locking is used to protect cached database blocks. For each
buffer in the database buffer cache, there is a buffer header. The buffer headers
constitute a fixed array in the permanent memory part of the shared pool. These
buffer headers act as the resource structures for buffer locks. Sessions manipulate
buffer headers, and thus buffers, via dynamically allocated structures known as
buffer handles. The buffer handles act as the lock structures for buffer locks.
11 апр 06, 17:31    [2549105]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
третий пошел
Guest
andrey_anonymous
Да-да. Именно блокировки :)

Если ты не понимаешь, что блокировки - это не только enqueues, это твои проблемы :)


PS

1. Читать умеешь?
andrey_anonymous
Но есть один вопрос. При активной вставке документов с разных рабочих мест...


2. Если секционировать 100Gb таблицу на 100 секций, это не будет означать, что по ней (ним) не нужно создавать индексы. Кроме того, таблицы имеют свойство быть связанными ограничениями ссылочной целостности. В том числе намекаю на PK/unique.

3. Почти все, что ты сказал в первом своем ответе - полная чушь. Лучше это признать и перестать переводить все в юмор ;)
11 апр 06, 17:35    [2549131]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
Я и ёжик
Хочется чтобы было слово LOCK?

Нет, просто не хочется, чтобы человека запугивали понапрасну

БЛОКИРОВКИ, говорите?
Хоть бы пояснили человеку что именно имеете ввиду... Блокировки... Хмык :\
create table ane_test(d date)
/
Table created

create index ane_test$d on ane_test(d)
/
Index created

insert into ane_test values(trunc(sysdate));
1 row inserted
SQL>

Сессия2:
SQL> insert into ane_test values(trunc(sysdate));
1 row inserted

SQL> 
Сессия3:
SQL> insert into ane_test values(trunc(sysdate));
1 row inserted

SQL> 
Сессия4:
SQL> insert into ane_test values(trunc(sysdate));
1 row inserted

SQL> 
Сессия5:
SQL> insert into ane_test values(trunc(sysdate));
1 row inserted

SQL> 
11 апр 06, 17:45    [2549197]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
третий пошел
1. Читать умеешь?
andrey_anonymous
Но есть один вопрос. При активной вставке документов с разных рабочих мест...

Будьте осторожнее с цитатами. Эта - не из меня.
Теперь про "интенсивную" вставку... Это сколько, по-вашему?
Давайте сравним Ваш ответ (когда уже начнется buffer busy wait) и предположения об интенсивности вставок автора.
третий пошел

2. Если секционировать 100Gb таблицу на 100 секций, это не будет означать, что по ней (ним) не нужно создавать индексы. Кроме того, таблицы имеют свойство быть связанными ограничениями ссылочной целостности. В том числе намекаю на PK/unique.
И все-таки вернитесь к началу топика и перестаньте изобратать. Потенциальная необходимость индексирования с вопросом автора НИКАК не связана. Более того, сегодня вроде все живет и без индексов.
третий пошел

3. Почти все, что ты сказал в первом своем ответе - полная чушь. Лучше это признать и перестать переводить все в юмор ;)

Полная чушь - это рекомендовать reverse index для решения задачи инкрементного копирования. Это - чушь, притом не смешная совсем...
11 апр 06, 17:51    [2549233]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
andrey_anonymous
БЛОКИРОВКИ, говорите?
Хоть бы пояснили человеку что именно имеете ввиду... Блокировки... Хмык :\

Абсолютно то же, что имеется в ввиду под блокировками страницы индекса в MSSQL, защита на момент изменения блока. Если он знает чего боялся в MSSQL, то должен понимать о каких блокировках идет речь, если не знает, то , что поделаешь, будет дуть на воду. Разницы с Oracle тут у MSSQL, насколько я не знаю :), нет.

2 Desperado
В MSSQL нет эскалации до уровня страницы, а только сразу до таблицы целиком.
11 апр 06, 18:16    [2549382]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
Я и ёжик
Абсолютно то же, что имеется в ввиду под блокировками страницы индекса в MSSQL, защита на момент изменения блока.

Хм. Должно быть, это от непроходимой темноты, но мне казклось, что MSSQL снимает блокировки (в т.ч. страничные и табличные) по факту завершения транзакции... Нет?
Погуглил быстренько - ничего внятного не нашел (ссылок много, толку мало :)...
11 апр 06, 18:50    [2549600]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
Desperado
Guest
Я и ёжик

2 Desperado
В MSSQL нет эскалации до уровня страницы, а только сразу до таблицы целиком.


да ну, а тут тогда об чем речь ?

http://msdn2.microsoft.com/en-us/library/ms189286.aspx
11 апр 06, 19:13    [2549713]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
andrey_anonymous

Хм. Должно быть, это от непроходимой темноты, но мне казклось, что MSSQL снимает блокировки (в т.ч. страничные и табличные) по факту завершения транзакции... Нет?

Тут не надо путать блокировки устанавливаемые менеджером транзакций ( системой управления конкурентными заданиями) которые снимаются по завершении транзакции и блокировки поддерживающие целостность внутренних структур ( у них они вроде называются latch).
Поскольку умолчальный уровень для "транзакционных" блокировок в MSSQL ROWLOCK то врят ли в "предостережениях" речь шла о них, а кратковременная блокировка (LATCH) на время изсменения блока накладывается всегда и как раз может оказать влияние при вставке в один блок
(напермер, http://www.rsdn.ru/Forum/Message.aspx?mid=725403&only=1).


andrey_anonymous

Погуглил быстренько - ничего внятного не нашел (ссылок много, толку мало :)...

Про "внутренние" блокировки не знаю, не интересовался, про транзакционные блокировки вот, например, правда тоже не очень интересовался :)
http://www.rsdn.ru/article/db/mssqllocks.xml
http://www.rsdn.ru/article/db/LockEscalation.xml


Desperado
да ну, а тут тогда об чем речь ?

Об общем принципе эскалации и эффективности разного уровня гранулярности в зависимости от длины транзакций. Картинка, кстати, свистнута из учебника Бернштайна "Concurency control in Database Systems" ( очень рекомендую).
Про то что rowlock эскалируется в pagelock там ничего нет

http://msdn2.microsoft.com/en-us/library/ms184286(SQL.90).aspx
The Database Engine does not escalate row or key-range locks to page locks, but escalates them directly to table locks. Similarly, page locks are always escalated to table locks.


Предлагаю про MSSQL закончить, я его не знаю, и знать пока что не хочу :)
11 апр 06, 19:28    [2549771]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Я и ёжик
(напермер, http://www.rsdn.ru/Forum/Message.aspx?mid=725403&only=1).
В напермере имелось ввиду сообщение Merle от 19.07.04 10:00
11 апр 06, 19:35    [2549793]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
Я и ёжик
andrey_anonymous

Хм. Должно быть, это от непроходимой темноты, но мне казклось, что MSSQL снимает блокировки (в т.ч. страничные и табличные) по факту завершения транзакции... Нет?

Тут не надо путать блокировки устанавливаемые менеджером транзакций ( системой управления конкурентными заданиями) которые снимаются по завершении транзакции и блокировки поддерживающие целостность внутренних структур ( у них они вроде называются latch).

Как и "у нас" :)
Посмотрел таки сцылку и не понял, как она касается предмета столь бурной дискуссии ("Блокировки при одинаковом ключе в индексе")...
Я так себе мыслил, что MSSQL блокирует строчку индекса/страницу и не отпускает, пока транзакция не зафиксирована... А сосед не могет вставить запись с тем же ключем
В приведенной же ссылке обсуждаются обычные вопросы "перекоса" индексов, hash partitioning и прочие общечеловеческие проблемы генерации суррогатных ключей...
11 апр 06, 19:44    [2549828]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
andrey_anonymous

Как и "у нас" :)
У нас latch это несколько другое, совсем легкая блокировка, у них Latch это скорее аналог buffer pin, library cahe lock и.т.п.
Хотя может и вру :)

andrey_anonymous
Посмотрел таки сцылку и не понял, как она касается предмета столь бурной дискуссии ("Блокировки при одинаковом ключе в индексе")...
Не получилась ссылка на конкретное сообщение. Имелось ввиду сообщение Merle от от 19.07.04 10:00, там в качестве аргумента присутствует упоминание проблемы при вставки в последний блок индекса ( т.е. в один и тот же "горячий" блок).

andrey_anonymous

Я так себе мыслил, что MSSQL блокирует строчку индекса/страницу и не отпускает, пока транзакция не зафиксирована... А сосед не могет вставить запись с тем же ключем
Это будет запись со ссылкой на другую строку, т.е. другая запись, и в MS не идиоты сидят что бы допускать такую блокировку ключа,
а проблема со страничной блокировкой обхордится переходом на режим строчного блокирования ( который и является режимом по умолчанию, на сколько я знаю).

Отдельный вопрос эксклюзивная блокировка диапазона ключа, при serializable, но это уже совсем отдельный вопрос.:)

В приведенной же ссылке обсуждаются обычные вопросы "перекоса" индексов, hash partitioning и прочие общечеловеческие проблемы генерации суррогатных ключей...[/quot]
11 апр 06, 19:56    [2549867]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
Я и ёжик
andrey_anonymous
как она касается предмета столь бурной дискуссии ("Блокировки при одинаковом ключе в индексе")...
Имелось ввиду сообщение Merle от от 19.07.04 10:00 ... проблемы при вставки в последний блок индекса ( т.е. в один и тот же "горячий" блок).
Я примерно так и понял, но все-таки ИМХО это немного не то. И MSSQL тут не при делах - это общечеловеческие проблемы :)
Я и ёжик
andrey_anonymous
Я так себе мыслил, что MSSQL блокирует строчку индекса/страницу и не отпускает, пока транзакция не зафиксирована... А сосед не могет вставить запись с тем же ключем
Это будет запись со ссылкой на другую строку, т.е. другая запись, и в MS не идиоты сидят что бы допускать такую блокировку ключа

Ну как сказать... Oracle может решать некоторые проблемы из этой области посредством реконструкции блоков (consistent mode get). AFAIK, "классический" MSSQL подобными механизмами не располагает.
Более того, если говорить именно о топике, то конкуренция должна стать проблемой еще позже, поскольку новых ключей в индексе появляется очень мало, а вся нагрузка от вставки приходится на leaf, которые можно просто брать из freelist, заполнять и цеплять к индексу... (может, и гоню немного :)
11 апр 06, 20:14    [2549924]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
Чела совсем заморочили.
При добавлении строк в индексированную таблицу блокируются ключи индекса (но не блоки или, каких называют в MS SQL, страницы) с момента вставки записи до завершения транзакции. Эти блокировки влияют на конкурирующие сессии только в том случае если эти сессии добавляют одинаковые ключи в уникальный индекс. Конкурирующие сессии ждут завершения транзакции и либо сообщают, о нарушении уникальности, либо (в случае отката транзакции) добавляют ключ в индекс. Иначе оракл не препятствует добавлению ключей.

Если вставки интенсивные, может наблюдаться конкуренция за блоки таблицы (поскольку автор не сообщает о таких проблемах, вставки скорее всего не очень интенсивные) и индекса в буферном кэше, которая выражается в ожидании освобождения защёлок. Но защёлки живут очень непродолжительное время. Чтобы получить ощутимое снижение производительности нужно ОЧЕНЬ интенсивно обращаться к одному и тому же блоку в буферном кэше.

И наконец рецепт.
Добавь в таблицу поле с признаком, что запись новая, ещё не выгружалась в OLTP систему. В процессе изменения таблицы заполняй это поле каким нибудь значением, например sysdate или лучше (чтобы индекс не перекашивался) константой или значением циклического счётчика. Построй одноколоночный индекс по этому полю. Для sysdate желательно использовать реверсивный индекс.
В процессе загрузки данных в OLTP очищай это поле, тогда соответствующие ключи будут удаляться из индекса. В результате индекс будет содержать список rowid только новых строк. Будет небольшим по размеру и глубине и весьма эффективным для решения поставленой задачи.
11 апр 06, 21:30    [2550084]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
ONO
Guest
mcureenab
Чела совсем заморочили.


Этт точно.
Однако 3 раза читал. Однако не все понял... :-)
11 апр 06, 22:07    [2550160]     Ответить | Цитировать Сообщить модератору
 Re: Блокировки при одинаковом ключе в индексе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18337
ONO
mcureenab
Чела совсем заморочили.
Этт точно.
Однако 3 раза читал. Однако не все понял... :-)

:)
1. Если есть возможность секционировать табличку по дате изменения (RANGE), то секционируйте. Нарезайте разделы заблаговременно.
Тогда схема будет примерно такая:
- Приложения пишут в один раздел (N) (дата изменения есть ключ секционированя) и дружно переходят писать в раздел (N+1) (а-ля "sliding window")
- Запускается выгрузка в OLAP и вытягивает содержимое разделов от (N-(сколько не копировали)) до N.
Никто никому не помешал, все счастливы.
2. Если возможности секционировать нет (standard edition или уже секционировано по иному, неподходящему ключу), то можно воспользоваться советом mcureenab и сыграть на том, что null-значения не индексируются:
- добавьте поле, не предназначенное ни для чего кроме организации выгрузки.
Можно сделать default sysdate, чтобы не трогать приложения.
- Проиндексируйте это поле. Можно reverse - в данном сценарии это не имеет принципиального значения, но облегчит жизнь индексу.
- Выгрузку проводим, например, в стиле:
а) update table T set SuperField = null WHERE SuperField is not null returning field1, field2, field3...etc bulk collect into <набор массивов>
б) forall i in field1_array.first..field1_array.last insert into OLAP_TABLE values (field1_array(i), field2_array(i), ...)
в) commit.
11 апр 06, 22:23    [2550193]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить