ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Вечная сессия
20 сообщений из 20, страница 1 из 1
Вечная сессия
    #39334410
Быдло____кодер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Быдло____кодер
Гость
Есть сессия которая блокирует кучу других. Решили ее убить, статус поменялся на killed и на этом все. блокировки ее так и живут
Размер анду сегмента маленький, непонятно что оно там откатывает так долго
Мало того, сессия держит только блокировки TM на таблицах, и ни одной ТХ, и успешно блокирует сессии, которые просто апдейтят данные, и не меняют структуру БД, почему - не пойму

Стоит ли грохнуть поток сессии через orakill? Что может случится плохо из-за этого?
...
Рейтинг: 0 / 0
26.10.2016, 14:20
| Ответить | Цитировать | Написать  
Вечная сессия
    #39334486
Быдло____кодер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Быдло____кодер
Гость
Глянул в v$lock эта сессия еще удерживает блокировку AE, lmode=4 но по идее это пофигу должно быт
...
Рейтинг: 0 / 0
26.10.2016, 15:14
| Ответить | Цитировать | Написать  
Вечная сессия
    #39334590
Melkomyagkii_newbi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkomyagkii_newbi
Участник
У меня недавно похожая ситуевина была, только сессии не блокировали, а жрали много pga. У меня так получилось как мне кажется, потому что команда приложения, когда узнала что это их запросы, начала рестарт сервера приложений - клиент не получил ошибку что его сессия убита. Имхо можно грохнуть, так как у меня коллеги в итоге ребутнули базу с шатаун иммедиэйт - при таком вроде должны были все равно ждать пока откатится, но прошло без задержек.
...
Рейтинг: 0 / 0
26.10.2016, 16:22
| Ответить | Цитировать | Написать  
Вечная сессия
    #39334622
Быдло____кодер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Быдло____кодер
Гость
Отпустило, 6 часов блин откатывалась, причем поприбивались и сессии которые ее ждали
Хорошо что юзеры не знают где я живу
...
Рейтинг: 0 / 0
26.10.2016, 16:42
| Ответить | Цитировать | Написать  
Вечная сессия
    #39334722
Стромпрстен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стромпрстен
Гость
Быдло____кодер,

вот тут понаписали всякой ерунды, почитай: http://www.sql.ru/forum/842542/raznica-mezhdu-alter-system-kill-session-i-alter-system-disconnect-session
...
Рейтинг: 0 / 0
26.10.2016, 18:25
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335305
Быдло____кодер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Быдло____кодер
Гость
Продолжение истории
Ночью без активных сессий запустил скрипт (который запускался в проблемных сессиях), прибил сессию, в результате она висела и блокировала вторую такую же сессию опять 6 часов, хотя скрипт вставлял в 3 таблицы по 3к записей, т.е откатывать там особо нечего было
Оптимизировал скрипт который выполняли эти сессии, теперь он выполняется 10 секунд вместо 10 минут (если другие сессии не мешают)

Сегодня таже картина - сессия висит, блокировки только ТМ, выстроилась очередь из других сессий которые ее ждут
причем в других сессиях все время висит запрос на выборку и event = cursor: pin S
В кильнутой сессии event = async descriptor resize
...
Рейтинг: 0 / 0
27.10.2016, 13:27
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335342
Быдло____кодер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Быдло____кодер
Гость
Посмотрел через Process Explorer поток убитой сессии , он занимает львую долю ЦПУ, а вторую львиную долю занимают сессии которые его ждут
Такое впечателнение что они ждут одна другую, но дедлока при этом нету
...
Рейтинг: 0 / 0
27.10.2016, 13:44
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335370
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
А почему бы для начала не избавиться от TM блокировок? Их наличие говорит об отсутствии индексов на внешние ключи, что приводит к блокировке всей таблицы вместо построчной.
Если возникает необходимость прибивать активную сессию делать это точно лучше через прибивание процесса в операционке или утилитой ORAKILL, а не KILL SESSION.
...
Рейтинг: 0 / 0
27.10.2016, 14:08
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335374
Быдло____кодер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Быдло____кодер
Гость
События ожидания для проблемной сессии (счастливый номер)
Код: plsql
1.
2.
3.
4.
5.
6.
7.
select event, wait_class_id, seconds_in_wait
from v$session_wait
where sid=13

EVENT                                                            WAIT_CLASS_ID SECONDS_IN_WAIT
---------------------------------------------------------------- ------------- ---------------
asynch descriptor resize                                            1893977003           14431



Что это за магический asynch descriptor resize , чего сессия его 4 часа ждет? (убил я ее час назад)
...
Рейтинг: 0 / 0
27.10.2016, 14:11
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335379
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Их наличие в первую очередь говорит о внесении изменений
То, что они есть -- это нормально
Другой вопрос, если они удерживаются в ненормальном режиме, из-за чего может возникнуть ожидание -- так это в первую очередь DDL или LOCK TABLE
...
Рейтинг: 0 / 0
27.10.2016, 14:13
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335386
Быдло____кодер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Быдло____кодер
Гость
Taciturn12А почему бы для начала не избавиться от TM блокировок? Их наличие говорит об отсутствии индексов на внешние ключи, что приводит к блокировке всей таблицы вместо построчной.
Если возникает необходимость прибивать активную сессию делать это точно лучше через прибивание процесса в операционке или утилитой ORAKILL, а не KILL SESSION.
Дык ТМ блокировки ж вроде должны запрещать только ДДЛ операции?
Индексы есть на внешние ключи, лочатся таблицы которые меняются
Сессии только делают вставки и апдейты, никакого ДДЛ
...
Рейтинг: 0 / 0
27.10.2016, 14:17
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335415
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
Нет. Механизм работы системы такой, что если нет индекса на внешний ключ, Oracle блокирует всю таблицу, что мешает делать все изменения в таблице. Если индекс есть, тогда блокировка ставится только на те строки, в которые вносятся изменения.
Здесь с примерами
...
Рейтинг: 0 / 0
27.10.2016, 14:40
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335917
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Любое изменение (или даже попытка) вызывает TM блокировку

Про неиндексированные внешние ключи -- ситуация стреляет только в случае попытки удаления/изменения ключа/merge родительской таблицы . На мой взгляд, не очень распространенная ситуация (хотя, говорят, есть приблуды, любящие при обновлении любого поля, обновлять всю строку, включая ключи).
При этом на момент операции делается попытка получить TM блокировку в Share (4) или Share Row Exclusive (5) режиме для дочерней таблицы, затем она сразу снимается , остается только обычная Row Exlusive (3). Вот если на ней (дочерней таблице) уже висит RX блокировка от другой сессии (кто-то ее изменял или приехала от изменения родительской) и возникает ожидание. Ну, а остальные уже встают в очередь.
Соответственно, если на ней еще нет ничьей блокировки или кто-то захочет обновить ее позже -- тут проблем не возникнет.

В случае индекса на внешний ключ при удалении / изменении ключа родительской таблицы (или вставки в нее при неиндексированных ключах) TM блокировка на дочернюю таблицу все равно берется, просто в Row Exclusive Mode, что совместимо с остальными держателями этой блокировки при обычном изменении.

Обновление неключевых полей родительской таблицы вообще никак не влияет

На ожидании TM блокировки сессии еще могут висеть в случае невозможности выделить новый слот для транзакции или при параллельных/прямых обновлениях
Я бы таки больше склонялся к PDML или APPEND без коммита.

PS. Продолжительность и режим блокировок для внешних ключей менялись от версии к версии.

2ТС
А всякие там AWR/ASH/DBA_HIST_ACTIVE_SESS_HISTORY (Statspack, в крайнем случае) кажут что-нибудь ?

Быдло____кодерсессия держит только блокировки TM на таблицах, и ни одной ТХВот это или LOCK TABLE, или DML c %rowcount=0, но разБыдло____кодеруспешно блокирует сессии, которые просто апдейтят данныебольше похоже на LOCK TABLE

asynch descriptor resize -- это связано с асинхронным вводом-выводом, и вроде как юзается только в юниксах, а у тебя вроде как винда
Но можешь попробовать отключить DISK_ASYNCH_IO=FALSE
...
Рейтинг: 0 / 0
28.10.2016, 09:26
| Ответить | Цитировать | Написать  
Вечная сессия
    #39335941
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Elic
Участник
Вячеслав ЛюбомудровПро неиндексированные внешние ключи -- ситуация стреляет только в случае попытки удаления/изменения ключа/merge родительской таблицы . На мой взгляд, не очень распространенная ситуацияНужна не сама попытка, а лишь её декларативная возможность. Вроде упоминания ключа в out-позиции в триггере:
Код: plsql
1.
2.
3.
4.
5.
trigger before insert or update 
...
begin 
  if inserting then
    :new.id := ...;

И при любом изменении будут блокировки, что при стечении обстоятельств оказывается чревато :|
...
Рейтинг: 0 / 0
28.10.2016, 09:53
| Ответить | Цитировать | Написать  
Вечная сессия
    #39336068
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
У нас это очень распространенная ситуация. При открытии редактировании записи через форму, TM блокировка устанавливается на все время, пока форма открыта, может быть и час и два, пока пользователь ее не закроет. Изменить механизм редактирования невозможно, т.к. он используется во всей системе и заставить разработчиков переписать механизм проблематично. Поэтому приходится при возникновении длительных TM блокировок строить индексы на нужное поле. После этого проблема уходит. (У нас обычно TM блокировка со статусом INACTIVE).
...
Рейтинг: 0 / 0
28.10.2016, 11:49
| Ответить | Цитировать | Написать  
Вечная сессия
    #39336208
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
ElicВячеслав ЛюбомудровПро неиндексированные внешние ключи -- ситуация стреляет только в случае попытки удаления/изменения ключа/merge родительской таблицы . На мой взгляд, не очень распространенная ситуацияНужна не сама попытка, а лишь её декларативная возможность. Вроде упоминания ключа в out-позиции в триггере:
Код: plsql
1.
2.
3.
4.
5.
trigger before insert or update 
...
begin 
  if inserting then
    :new.id := ...;

И при любом изменении будут блокировки, что при стечении обстоятельств оказывается чревато :|Действительно, засада
...
Рейтинг: 0 / 0
28.10.2016, 13:39
| Ответить | Цитировать | Написать  
Вечная сессия
    #39337787
Стромпрстен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Стромпрстен
Гость
Taciturn12,

А если вместо одного триггера сделать два, before insert и before update?
...
Рейтинг: 0 / 0
31.10.2016, 12:39
| Ответить | Цитировать | Написать  
Вечная сессия
    #39337826
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
Я про триггеры не писал, у нас проблема была в том, что транзакция начинается при открытии формы и заканчивается когда пользователь форму закрывает, а это иногда и на час и больше растягивается. Если блокируется только та запись с которой он работает то все нормально, если вся таблица, тогда остальные не могут работать. Приходится строить индекс на поле, т.к. изменить код приложения сложнее (из-за организационных моментов).
...
Рейтинг: 0 / 0
31.10.2016, 13:06
| Ответить | Цитировать | Написать  
Вечная сессия
    #39337904
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Ты что-то путаешь
Блокировка не держится "навсегда"
Она берется на очень короткое время -- чтобы просто понять что никто не заблокировал в несовместимом режиме -- это такой способ борьбы с "deadlock"
...
Рейтинг: 0 / 0
31.10.2016, 14:00
| Ответить | Цитировать | Написать  
Вечная сессия
    #39338449
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
Вячеслав Любомудров,

Может я не совсем правильно выразился или непонятно рассказал про ситуацию. Именно поэтому я указал ссылку, где подробно с примерами ситуация расписана, щелкаем по ней, читаем, проверяем и убеждаемся что TM блокировка висит до самого коммита или отката. И там же показано, что построение индекса эту проблему убирает. У Тома Кайта есть еще более подробное описание про не индексированные внешние ключи.
...
Рейтинг: 0 / 0
01.11.2016, 07:53
| Ответить | Цитировать | Написать  
20 сообщений из 20, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Вечная сессия
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39334486&tid=1887111]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 170ms
get topic data:
 6ms
get forum data:
 2ms
get page messages:
 40ms
get tp. blocked users:
 1ms
others: 227ms
total:  473ms
созд. / загр.: 473ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]