Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование I

Ответ
 
Опции темы Опции просмотра
  #21  
Старый 24.09.2009, 14:51
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Одновременный доступ



Одновременный доступ

Механизм блокирования по умолчанию работает в дифференцированном (fine¬grained), режиме блокирования на уровне строки (row-level locking mode). Различные транзакции могут обновлять разные строки внутри одной и той же таблицы, не мешая друг другу.

Хотя по умолчанию действует модель блокирования на уровне строк, база данных Oracle 10g поддерживает ручное блокирование на самом высоком уровне, если это необходимо:

Код:
SQL> LOCK TABLE hr.employees  IN EXCLUSIVE MODE; 
Table(s)  Locked.
В соответствие с этой командой любые транзакции, пытающиеся обновить строку в заблокированной таблице, должны ждать в очереди, пока блокирующая транзакция завершится. Режим EXCLUSIVE - наиболее ограничивающий режим блокирования. Другие режимы:

ROW SHARE ; разрешается одновременный доступ к заблокированной таблице, но другим сеансам запрещено блокировать всю таблицу для монопольного (exclusive) доступа

ROW EXCLUSIVE ; то же самое, что и режим ROW SHARE, однако
дополнительно запрещено блокирование в режиме SHARE. Блокировки ROW EXCLUSIVE автоматически предоставляются, когда обновляются, вставляются и удаляются данные.

SHARE ; разрешены одновременно выполняемые запросы, но запрещены изменения заблокированной таблицы. Блокировка SHARE необходима (и автоматически запрашивается) для создания индекса таблицы.

SHARE ROW EXCLUSIVE ; используется для запроса всей таблицы; другим разрешено запрашивать строки таблицы, но запрещено блокировать таблицу в режиме SHARE и изменения строк.

EXCLUSIVE ; разрешены запросы данных из заблокированной таблицы, но все другие операции запрещены. Монопольная (exclusive) блокировка нужна для удаления таблицы.


Команды ручного блокирования так же, как и другие запрашиваемые блокировки, ждут в очереди, пока все сеансы, уже удерживающие или запросившие требуемые блокировки раньше, их освободят. Команда LOCK имеет специальный аргумент NOWAIT, который определяет поведение ждущей блокировки.

Когда NOWAIT задан, управление немедленно возвращается обратно, если таблица уже заблокирована другим сеансом:



Обычно не возникает необходимости в ручном блокировании объектов. Механизм автоматического блокирования обеспечивает одновременный доступ, требуемый большинству приложений.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #22  
Старый 24.09.2009, 14:52
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Блокировки DML



Блокировки DML

Каждая транзакция DML получает две блокировки:

EXCLUSIVE для изменяемой строки или строк.
ROW EXCLUSIVE на уровне таблицы, содержащей изменяемые строки. Когда выполняются изменения, она накладывается для того, чтобы запретить другим сеансам блокирование всей таблицы (возможно для ее удаления или усечения).
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #23  
Старый 24.09.2009, 15:05
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Механизм формирования очередей



Механизм формирования очередей

Запросы блокировок автоматически ставятся в очередь. Как только удерживающая блокировку транзакция завершается, следующий в очереди сеанс получает блокировку.

Механизм очередей отслеживает порядок, в котором блокировки были запрошены и режимы запрашиваемых блокировок.

Сеансы, уже удерживающие блокировку, могут запросить преобразование (convert) блокировки, и при этом они не ставятся в конец очереди. Например, предположим сеанс удерживает разделяемую блокировку таблицы (SHARE) и запрашивает преобразование этой блокировки в монопольную (EXCLUSIVE). После того, как ни у кого не останется монопольной (EXCLUSIVE) или разделяемой (SHARE) блокировки таблицы, сеанс, удерживающий разделяемую блокировку, получит монопольную блокировку без повторного ожидания в очереди.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #24  
Старый 24.09.2009, 15:06
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Конфликты блокировок



Конфликты блокировок

Конфликты блокировок происходят часто. Обычно они со временем разрешаются через механизм очередей. В очень редких случаях конфликт блокировок может потребовать вмешательства администратора. В приведенном на слайде случае транзакция 2 получила блокировку строки в 9:00:00 и не зафиксировала изменение, оставив за собой блокировку. Транзакция 1 попыталась изменить всю таблицу и запросила блокировку всех строк в 9:00:05. В результате транзакция 1 была заблокирована транзакцией 2 до 16:30:01, когда транзакция 2 выполнила фиксацию.

Пользователь, пытающийся выполнить транзакцию 1, конечно будет обращаться к администратору за помощью и АБД должен обнаружить и разрешить конфликт.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #25  
Старый 24.09.2009, 15:08
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Возможные причины конкуренции блокировок



Возможные причины конкуренции блокировок

Незафиксированные изменения - это наиболее общая причиной конфликта блокировок. Но возможны и некоторые другие причины.

Длительно выполняемые транзакции. Во многих приложениях используется пакетная обработка при внесении массовых изменений (bulk updates). Выполнение таких пакетных заданий обычно запланировано в часы низкой активности или во время, когда пользователи не работают. Однако в некоторых случаях задания могут не успеть завершиться до возобновления работы пользователей, или же они слишком долго выполняются в период низкой активности. Конфликты блокировок обычно возникают, когда транзакция и пакетная обработка выполняются одновременно.

Неоправданно высокий уровень блокирования. Не все базы данных поддерживают блокирование на уровне строк (Oracle добавил блокирование на уровни строки в версию 6 в 1988 году). Некоторые базы данных до сих пор блокируют на уровне страницы или таблицы. Разработчики, пишущие свои приложения, которые предполагается использовать с разными базами данных, часто искусственно завышают уровень блокирования. В результате Oracle начинает работать подобно другим базам данных с меньшими возможностями. Пользователи, начинающие использовать Oracle, также часто используют более высокий, чем это необходимо в базе данных Oracle 10g уровень блокировки.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #26  
Старый 24.09.2009, 15:09
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Обнаружение конфликтов блокировок



Обнаружение конфликтов блокировок

Для определения места, в котором возник конфликт блокировок, предназначена страница Blocking Sessions в Enterprise Manager. Конфликтующие запросы блокировок выводятся в иерархическом виде. На верхнем уровне находится сеанс, удерживающий блокировку, а сеансы, стоящие в очереди за этой блокировкой, показаны ниже по порядку.

Для каждого вовлеченного в конфликт сеанса показывается имя пользователя, номер сеанса (session ID) и время ожидания в секундах. Перейдите вглубь (drill down) по номеру сеанса, чтобы увидеть команду SQL, которая реально выполняется или ждет своего выполнения.

Автоматический диагностический монитор базы данных (Automatic Database Diagnostic Monitor, ADDM) также обнаруживает конфликты блокировок и может выдать рекомендации по устранению тенденций неумелого применения блокировок.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #27  
Старый 24.09.2009, 15:10
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Разрешение конфликтов блокировок



Разрешение конфликтов блокировок

Чтобы конфликт блокировок был разрешен, сеанс, удерживающий блокировку, должен ее освободить. Наилучший путь - это связаться с пользователем и попросить его завершить транзакцию а этом сеансе.

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

Пользователи, чьи сеансы были убиты, получат следующее сообщение об ошибке, когда они попытаются ввести очередную команду SQL:

ORA-03135: connection lost contact
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #28  
Старый 24.09.2009, 15:11
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Использование SQL для разрешения конфликтов блокировок



Использование SQL для разрешения конфликтов блокировок

Управление сеансами, как и большинство других операций, доступных в Enterprise Manager, можно осуществлять, выполняя команды SQL.

Представление v$session содержит подробные сведения о всех подсоединенных сеансах.

В столбце blocking_session выводится идентификатор (SID) сеанса, блокирующего данный сеанс. Чтобы удалить блокирующий сеанс с помощью операции kill session, необходимо определить два его атрибута: SID и SERIAL#. Для этого выполняется запрос, в котором выводятся SID и SERIAL# сеанса при условии, что SID совпадает с идентификатором блокирующего сеанса (blocking_session).
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #29  
Старый 24.09.2009, 15:12
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Взаимоблокировки



Взаимоблокировки

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

Сервер Oracle автоматически обнаруживает такую ситуацию и разрешает проблему взаимоблокировки путем аварийного завершения команды. В этом случае после получения сообщения об ошибке можно выполнить либо фиксацию, либо откат, освободив таким образом другие заблокированные сеансом ресурсы, чтобы другой сеанс смог продолжить транзакцию.

В примере на слайде транзакция 1 должна либо выполнить фиксацию, либо откат в ответ на получение сообщения об ошибке, вызванной взаимоблокировкой. Для завершения транзакции путем фиксации ее изменений требуется перед этим повторить вторую команду update. Если же произвести откат, тогда после этого в сеансе надо повторить обе команды, чтобы завершить операции транзакции
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #30  
Старый 24.09.2009, 15:13
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,211
По умолчанию Итоги

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 13:19. Часовой пояс GMT +3.


Powered by vBulletin®