Вы уверены, что Oracle - это RDBMS?

[netch80]

> After finishing Oracle RAC update to 11.2.0.3.4

Несколько процессов стартуют одновременно и выполняют один и тот же запрос:

DELETE FROM shared_cookies WHERE sk_expires < :exp_ts;

база получает пачку запросов и... запросы начинают умирать по таймауту. Таймаут - 5 минут. База не загружена. В таблице 5 колонок и десяток записей. Видимо, быстро определить, что один запрос выполнился и отпустил лок, и передать следующему - оно не в состоянии.

Как-то я уже высказывался о нашем опыте работы с этим зверем. Продолжение последовало достаточно быстро.

UPDATE: всё проще - серверный процесс дох из-за бага.

Comments

[vitus_wagner]

Оракл скурвился в районе 8.1

[gds.livejournal.com]

делается ли коммит сразу после этого оператора?

[netch80.livejournal.com]

да
(точнее, там пачка из delete, insert и select. коммит идёт после пачки)

[kranov.livejournal.com]

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

[kranov.livejournal.com]

а вообще скорее всего вся таблица уже кем-то или чем-то заблокирована

[netch80.livejournal.com]

Несколько раз чистили и перезапускали, она всё равно блокируется.
RAC был и до апдейта. В нём что-то сломали.

[netch80.livejournal.com]

Этот вопрос у нас давно решается аж целым DBA.

[kranov.livejournal.com]

странно все это, по опыту с миграцией на 11.2.0.3 мало проблем.
ожидание какое у сессий? v$session поле event

[netch80.livejournal.com]

> странно все это, по опыту с миграцией на 11.2.0.3 мало проблем.

Был тоже 11.2.0.3, чуть более ранний

> ожидание какое у сессий? v$session поле event

уточню.

[netch80.livejournal.com]

Оказалось известным багом, вылечено патчем 14398795.

[kranov.livejournal.com]

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