|
|
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
hi all Запустил на копии продакшена некий тягомотный отчет (с трейсом). Никаких "помех" выполнению на хосте нет: top Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Код: sql 1. Трейс, однако, показывает только вот это: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Между тем, запрос продолжает молотить - вижу песочные часики, окно приложения недоступно для переключения на него фокуса. Повторил еще несколько раз грохнуть его из mon$statements - без толку :( Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Это в 2.5 не пролечено, что ли ? В аттаче - несколько mon$-снапшотов по нему. PS. LI-V2.5.3.26737, SuperServer ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:21:01 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
пардон, отправил раньше основного вопроса: а почему, соб-сно, delete from mon$ возвращает управление в подсказку ДО того, как действительно всё срубит ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:21:56 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, это всегда так было. И с чего бы это он синхронным стал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:29:43 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, лечили shutdown ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:30:29 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денисэто всегда так было. И с чего бы это он синхронным стал?ну ладно, а срубать-то он ДОЛЖЕН или нет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:31:29 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, должен конечно. Это наверное откаты долго делаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:33:56 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, а если все-таки указать, кого именно срубать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:36:35 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
LI-V2.5.3.26737, SuperServer упс. А тут фиг его знает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:37:39 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
dimitr, забавно. Ты намекаешь на то что он может себя раньше рубануть. Думаю этого позволять нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:39:40 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
dimitrа если все-таки указать, кого именно срубать?т.е. where attach_id <> current_connection добавить ? попробую... PS. "дощитался", гад. И не срубился, конечно же: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:43:00 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
кстати, в InterBase сделано иначе. при убиении коннектов через tmp$ (апдейтом состояния) собственный коннект не трогается. Все остальные - рубятся. Код: sql 1. Что интересно (и нелепо), что до сих пор в ИБ нет current_attachment, поэтому узнать собственный ID коннекта невозможно, а среди tmp$attachments его идентифицировать можно только по косвенным признакам. То есть, добавить к этому оператору where tmp$attachment_id <> nnn было бы можно, если бы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:51:06 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
kdv, вот интересно, а что будет в TMP$ATTACHMENTS после сего UPDATE, если ничего кроме своего коннекта, то синтаксис срубания оператора выглядит как минимум странным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:08:04 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денисесли ничего кроме своего коннекта именно, остальные издыхают. Симонов Денисто синтаксис срубания оператора выглядит как минимум странным ну, в tmp$ с этим делом несколько иначе - меняются состояния "записей", а не "записи удаляются". Транзакции не убивается, а им делается rollback или commit (правда, про коммит почему-то написано в отношении limbo-транзакций). А если нужно прекратить выполняемый запрос, то пишется UPDATE TMP$ATTACHMENTS SET TMP$STATE = 'CANCEL' Как по мне, так и то (удаление) и это (обновление) немного странно. Объединить было бы логичнее. Впрочем, х.з. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:13:16 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
kdv, ещё более странно. Какой из нескольких выполняемых запросов прекратит этот оператор Код: sql 1. Что касается транзакций, то ROLLBACK это хорошо (в FB этого сделать нельзя), но COMMIT незавершённой транзакции это уже не в какие ворота. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:28:51 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
dimitrа если все-таки указать, кого именно срубать?не работает. Код: plaintext 1. 2. 3. 4. 5. в трейсе: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Мониторинг показывает всё то же самое: срубаемому аттачу до лампады мои потуги.DTSREADSWRITESFETCHESMARKSSEQ_READSIDX_READSINS_CNTUPD_CNTDEL_CNTBK_OUTSPURGESEXPUNGES18:28:45.711988652174626901443623436571211457889274529414093586406812129920018:28:50.754990133174626911673303436571211457900637929414093586406812129920018:28:55.793991348174626921959223436571211457912066729414093586406812129920018:29:00.832992564174626932241093436571211457923491029414093586406812129920018:29:05.917993794174626942645813436571211457935051829414093586406812129920018:29:10.953995020174626953052063436571211457946614329414093586406812129920018:29:15.992996232174626963357243436571211457958064529414093586406812129920018:29:21.034997449174626973678353436571211457969532429414093586406812129920018:29:26.071998668174626983987283436571211457980986729414093586406812129920018:29:31.11110001641746269943339034365712114579924801294140935864068121299200 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:32:39 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, а на CS/SC работает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:38:23 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Блин, НЕСТАБИЛЬНАЯ зараза! Воспроизводится только изредка. Судя по всему, надо ждать некоторое время, не менее 5 минут. Иначе SQL> set list on; set warning off; set sql dialect 3; select current_timestamp from rdb$database; commit; delete from mon$statements where mon$attachment_id<>current_connection; select current_timestamp from rdb$database; - выдаёт обе строки немедленно, а через 20 сек запрос действительно срубается. Такого я еще не видел PS. про SC попозжее отпишусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:03:00 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, у меня такие подозрения. Поскольку в 2.5 SS не параллелится, то коннекту из которого ты срубаешь тяжёлый запрос просто не даётся квант единственного ядра и он вынужден ожидать пока тяжёлый запрос сам завершиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:18:35 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, у него запрос отмены успешно завершается, т.е. он ничего не ждет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:33:23 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
dimitrу него запрос отмены успешно завершается, т.е. он ничего не ждета чего он тогда наверху ждал 20 сек ? Вот: Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:38:01 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, я имел ввиду не ждет окончания твоего тяжелого запроса. А свой квант времени он есс-но ждет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:45:19 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
увы, *не* могу воспроизвести, уже в надцатый раз пробую :( Время реакции срубаемого аттача как-то зависит от длительности времени его работы, т.е. сколько он там намолотил (м.б. из-за роста объема того, что он должен откатывать ?) Но повторить этот "подвиг" снова - не получается, даже если дать ему проработать 20 минут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 20:09:40 |
|
||
|
commit + delete from mon$statements в 2.5: "асинхронный" ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денисно COMMIT незавершённой транзакции это уже не в какие ворота. для лимбо-шмимбо - вполне даже очень, только непонятно, в случае облома какого фига такая транзакция делает в tmp$transactions. В общем, куча вопросов, которые как-то лень проверять :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 23:24:01 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38563509&tid=1563881]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
175ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 224ms |
| total: | 513ms |

| 0 / 0 |
