Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Oracle |
![]() ![]() |
_Nikotin Member Откуда: СПб Сообщений: 2961 |
Привожу просто результат, без комментариев. Повторяется в 11.1 и 11.2.
|
||
12 апр 11, 01:08 [10504056] Ответить | Цитировать Сообщить модератору |
сосед-акцессник
Guest |
Вопрос на понимание: О "рестарте" оператора обычно говорят, когда он выполняется на фоне конкуренции. Здесь, по видимости, все происходит в одном сеансе. Какие основания есть для применения термина "рестарт" в данном случае? |
12 апр 11, 04:18 [10504154] Ответить | Цитировать Сообщить модератору |
Владимир Бегун Member Откуда: Redwood Shores, CA USA Сообщений: 1707 |
|
||
12 апр 11, 04:27 [10504157] Ответить | Цитировать Сообщить модератору |
сосед-акцессник
Guest |
:) т.е. все-таки утверждается, что Set ID=-ID здесь значения не имеет. Зато имеет значение именно пустой триггер. Какой кошмар. кстати, планируется ли торжественное празднование 10-летнего юбилея темы в следующем году? |
12 апр 11, 05:16 [10504162] Ответить | Цитировать Сообщить модератору |
Владимир Бегун Member Откуда: Redwood Shores, CA USA Сообщений: 1707 |
|
||||||||
12 апр 11, 05:22 [10504165] Ответить | Цитировать Сообщить модератору |
Владимир Бегун Member Откуда: Redwood Shores, CA USA Сообщений: 1707 |
|
||
12 апр 11, 05:24 [10504167] Ответить | Цитировать Сообщить модератору |
_Nikotin Member Откуда: СПб Сообщений: 2961 |
Тут как-то по-жеще ситуация, одно дело restart немного увеличивающий redo, другое - увеличивающий его в разы. И, так как костыль с триггером работает, получается это баг. |
12 апр 11, 08:31 [10504303] Ответить | Цитировать Сообщить модератору |
_Nikotin Member Откуда: СПб Сообщений: 2961 |
Что-то это совсем жуткий баг. В 11g update неиндексированного столбца почти всегда приводит к перезапуску(а иногда и не одному) всего update, что в разы замедляет работу. Ситуацию "спасает" триггер :)
P.S. На металинке ничего подходящего не нашёл. |
||
14 апр 11, 01:15 [10516081] Ответить | Цитировать Сообщить модератору |
Владимир Бегун Member Откуда: Redwood Shores, CA USA Сообщений: 1707 |
|
||
15 апр 11, 22:28 [10526768] Ответить | Цитировать Сообщить модератору |
сосед-акцессник
Guest |
сегодня по случаю добрался до 11го оракла и провел тест из стартового поста с малой модификацией. Результат:
Примечания такие: 1) 8 - это просто тык. На первом прогоне было 100, понизил до 8 и этот результат снял. Эксперимент понижающий до воспроизведения исходного поведения не проводился ввиду спешки (база чужая). По этой же причине не снят баннер. Но, чес-слово - там была кака-то из последних 11G R2 под линухом. 2) все-таки веры в то, что в первоначальной постановке речь идет именно о рестарте "в смысле Кайта", у меня так и нет. |
|
15 апр 11, 22:29 [10526776] Ответить | Цитировать Сообщить модератору |
_Nikotin Member Откуда: СПб Сообщений: 2961 |
Попробовал у себя (11.2) - ни 8 ни 100 никак не влиюят на redo.
Что имеется в виду под "в смысле Кайта" ? Триггерами это не поймать - потому как пропадает эффект, но можно, например, посмотреть на результат alter session set events '10014 trace name context forever; name savepoints'; *** 2011-04-17 18:54:41.464 *** SESSION ID:(131.36159) 2011-04-17 18:54:41.464 *** CLIENT ID:() 2011-04-17 18:54:41.464 *** SERVICE NAME:() 2011-04-17 18:54:41.464 *** MODULE NAME:(SQL*Plus) 2011-04-17 18:54:41.464 *** ACTION NAME:() 2011-04-17 18:54:41.464 NO SAVEPOINT FOR CURRENT PROCESS ROLL BACK TO SAVE POINT - xid: 0x0003.000.000053be ROLL BACK TO SAVE POINT - xid: 0x0003.000.000053be *** 2011-04-17 18:54:42.275 ROLL BACK TO SAVE POINT - xid: 0x0003.000.000053be |
||||
17 апр 11, 19:04 [10530420] Ответить | Цитировать Сообщить модератору |
сосед-акцессник
Guest |
Хе-хе, вопрос оказался "интересный" По наивности, в момент объявления "смысла по Кайту", я полагал, что он определен в этих трех постах: http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html http://tkyte.blogspot.com/2005/08/part-ii-seeing-restart.html http://tkyte.blogspot.com/2005/09/part-iii-why-is-restart-important-to.html В них совмещены публичная попытка теоретического объяснения - как устроен мир рестарта, с практическим руководством - как по виду запроса или триггера определить - может ли в такой ситуации он произойти. Под смыслом понималась достаточно тщательно выписанная там теоретическая моделька. Характеристики модельки: 1) Рестрарт происходит на случайной строке, среди попадающих под изменение 2) рестарт стейтмента всегда и обязательно полный, т.к. иначе последствия апдейта непредсказуемы. Этот момент центральный и критичный, определяющий существо модельки Кайта. 3) третьего прохода (повторного рестарта) не бывает В качестве следствия из них рискну предложить такое грубое утверждение: Если размер редо для оператора без рестрарта принять за 1, то размер редо для оператора, испытавшего рестарт представляет собой случайную величину > 1 и <=2 В обсуждаемых примерах смущает то, что речь идет о коэффициенте "строго 2" Это должно означать, что утверждение проваливается всегда на "последней строке", то есть обязательно доходит до конца, прежде чем полностью перезапуститься. Что требует объяснения или поиска иного механизма удвоения редо. Эксперимент, который я пытался ставить, косвенным путем имел целью выяснить - не завязаны ли здесь механизмы более низкого уровня, приводящие к повторному чтению блока, но необязательно осмысленно выразимые в терминах согласованности записи. Возвращяюсь к "смыслу по Кайту". Оказалось, что здесь http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2599480800346313755 он наотрез отказался от обсуждения темы в модельных терминах. Тем самым, косвенно дезавуировав заявленный в "трех постах" смысл. Дело свелось к такому примерно выражению: так оно устроено или не так - это не тот вопрос на котором надо концентрироваться. Надо знать только то, что "оно" вообще есть. В контексте вопроса "что делать с before-триггерами" это имеет практическое значение. В конексте же вопроса "что делать размером redo", такая позиция, на мой взгляд, делает бессмысленным применением термина "рестарт". PS Постараюсь в ближайшие дни добраться до версии, на к-рой проводился эксперимент, снять баннер и, м.б. что-то еще сделать... |
||
18 апр 11, 03:10 [10531440] Ответить | Цитировать Сообщить модератору |
_Nikotin Member Откуда: СПб Сообщений: 2961 |
Понятие рестарта гораздо проще: если во время выполнения statement происходит внутренняя ошибка (вызывающая restart), то откатывается часть/все изменения и попытка повторяется. В некотороых ситуациях, если количество рестартов больше 5000, выпадает ORA-600, например 10428755. В некоторых - нет:
То что описывает Кайт - restart, который происходит для обеспечения read/write consistency (немного странной consistency в случае statement типа update t set x = x + 1 когда restart не происходит).
Бывает.
Слишком грубое. Размер redo зависит не только от изменяемых строк. В обсуждаемых примерах redo был выбран просто как показатель того что "что-то не так".
Про "строго 2" не понял где такое говорилось.
Завязаны :) согласованность тут не при чем.
В общем случае - да. Иногда можно попробовать получить "ведические знания" доступными средствами, ни с какой практической целью. Разве что попытаться спрогнозировать на их основе то или иное поведение.
С одной стороны - да, то что делает оракл - делает прозрачно. Но существует проблема performance. В итоге, мне больше чем размер redo понравился A-rows из display_cursor как индикатор подозрительности. |
||||||||||||||
18 апр 11, 21:06 [10533473] Ответить | Цитировать Сообщить модератору |
Все форумы / Oracle | ![]() |