dimon wrote:
>
> Зате в ході вчорашніх і сьогоднішніх нічних експериментів по переходу
> На Classic, отримали іншу проблему. За поточну добу 3 рази отримували
> Lock on WAIT transaction.
Давай вчитися повністю приводити повідомлення про помилку.
Lock conflict on WAIT transaction?
Ще якийсь текст був?
> З огляду на, що попередня версія такого ефекту не давала, закрався
> Сумнів, що я щось не так прочитав в документації або чого то
> Взагалі не розумію. Транзакції з атрибутом WAIT у нас тільки для update
> І delete. Кокретно це "READ WRITE WAIT READ COMMITTED RECORD_VERSION
Якщо немає помилки виду "update conflict", то UPDATE / DELETE тут скоріше всео
взагалі ні до чого. Метадані на ходу не змінюються часом?
> Ще один попутне питання. Для "ручного" виходу з подібної ситуації,
> Ми намагалися зробити -shut full -force 0 для бази, але при спробі
> Повернути базу online отримали помилку lock on wait transaction.
Десь про таке я вже чув.
> Як треба було зробити правильно в цій ситуації.
Відключити всіх клієнтів.
> Gfix -rollback.
Це зовсім з іншої опери.
> І чи можна отримати номер транзакції яка блокує роботу.
Якщо це конфлікт поновлення запису, то можна. В 2.1 :-)
Якщо ж будь-який інший конфлікт блокувань, то не можна в принципі.
Вибачте за затримку. При роботі SuperServer, дійсно чітко
відпрацьовуються значення DeadLockTimeout. Якщо Classic то при
одночасному оновленні одних і тих же даних різними сполуками,
оновлення "зависає" на невизначений час. Я не зміг зрозуміти на
скільки саме. Чому так відбувається. Якщо весь доступ переписати
як NO WAIT, це нам допоможе.
On Jun 28, 12:02 pm, Dmitry Yemanov <[hidden email]> wrote:
> Ddimon wrote:
>> Дмитро ви маєте рацію, повідомлення я навів зовсім не те.
>
> І яке тоді "те саме" повідомлення? Кліщами будемо тягнути?
>
> Дмитро
>
> Зашибись. На поставлені запитання принципово не відповідаємо?
>
Дмитро, ну немає повідомлення. Просто "зависає" на апдейте.
>> При роботі SuperServer, дійсно чітко
>> відпрацьовуються значення DeadLockTimeout.
>
> Звідки ти вирішив, що має місце саме Дедлок, а не конфлікт оновлення?
>
Так ймовірно ви маєте рацію. Оскільки в тестовому прикладі дійсно
робимо оновлення одних і тих же даних.
>> Якщо Classic то при одночасному оновленні одних
>> і тих же даних різними сполуками,
>> оновлення "зависає" на невизначений час.
>
> До коммітов конкурента, мабуть.
>
Як зменшити час очікування. Одне і теж додаток по різному
працює на Super і Classic. Я чесно не розумію де я лоханулся. В
Supere отримуємо помилку точно як вказано DeadLockTimeout, тобто я так
розумію після закінчення цієї затримки, один з апдейтів маркується як
NOWAIT і генерується повідомлення про помилку. Це нормально для нашого
додатки. Ми готові до того, що апдейти можуть завершуватися таким
чином. Але коли апдейт завмирає на невизначений час, це дуже
для нас критично. Переписати всі транзакції як WAIT LOCK TIMEOUT 10
або взагалі NO WAIT. Я просто не розумію чому таке різну поведінку
у сервера.