|
|
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Ситуация. Началась транзакция Т1 При её работе используется множество таблиц М1 Позже начинается транзакция Т2 использует и подмножество данных из М - М2 Транзакция Т2 комитится Транзакция Т2 прерывается , т.е. не рольбакится а, к примеру, снимается процесс, рвется связь и проч Что происходит с данными М2? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2000, 15:57 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
А причем тут T1 вместе с M1? И что такое просто M? И как T2 может прерываться если она уже закоммичена? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2000, 07:14 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
При снятии процесса всегда делается роллбак. Если "рвется связь и проч" - должен сниматься процесс (встречались случаи, когда не снимается - из-за ошибок в настройках сети). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2000, 07:15 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Извините за ошибку в описании ситуации. В действительности фраза "Транзакция Т2 прерывается , т.е. не рольбакится а, к примеру, снимается процесс, рвется связь и проч" должна звучать как Транзакция Т1 прерывается , т.е. не рольбакится а, к примеру, снимается процесс, рвется связь и проч т.е. - прерывается именно Т1 что касается ролбака при прерывании - опыт показал, что это не так. На клиенте выскочил таймаут, но транзакция продолжает висеть. При снятии её (например, через Enterprise Manager), отката не происходит. Происходит возврат в первоначальное состояние данных множества М1 С описанными последствиями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2000, 10:20 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Цитирую предыдущее сообщение: "На клиенте выскочил таймаут, но транзакция продолжает висеть. При снятии её (например, через Enterprise Manager), отката не происходит. Происходит возврат в первоначальное состояние данных множества М1" Но что же такое откат транзакции? Я всегда думал, что если произошёл "возврат в первоначальное состоение данных множества M1" (с которыми транзакция T1 работала), то следовательно это и есть откат транзакции. А вообще всё зависит от того, какая из двух транзакций первой успеет заблокировать строки этих таблиц M. Ведь каждая команда UPDATE (DELETE) накладывает исключительную блокировку на строку (если используется индекс) или на 8 К страницу данных (если индекс не используется). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2000, 10:35 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
To AnatolyS "что касается ролбака при прерывании - опыт показал, что это не так. На клиенте выскочил таймаут, но транзакция продолжает висеть. При снятии её (например, через Enterprise Manager), отката не происходит." Описанная ситуация совершенно фантастическая. Никогда, ни на каких версиях MSSQL не видел и не слышал о ТАКОМ. Можете прислать скрипт, который иллюстрирует ЭТО? Может-быть, Вы не полностью описали ситуацию? Эти 2 транзакции, конечно, выполняются в разных коннектах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2000, 16:13 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Бред какой-то!!! Что происходит, не происходит???!!! Может тебе надо сначало понять что такое транзакция? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2000, 12:30 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Э, уважаемый, эмоциональность высказываний поубавь пожалуйста. Я говорю про конкретную ситуацию, возникшую при эксплуатации промышленной БД, не про теоретизирование по поводу и без. Уточняя - вопрос касается случая "оторванных" соединений в системе с большим количеством транзакций, "затрагивающих" большое кол-во таблиц. Как известно, сервер периодически проверяет (используя механизмы протокола, в данном случае TCP/IP), живое еще соединение или нет. В последнем случае происходит описанная ситуация. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2000, 16:30 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Если Вас не затруднит, подскажите с помощью чего (ф-ции DBLIB, DBNETLIB(DBMSSOCN)) "сервер периодически проверяет (используя механизмы протокола, в данном случае TCP/IP),живое еще соединение или нет." или, хотя бы ссылки ... Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2000, 18:43 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Не проверял на 7.0 и 2000, но Enterprise Manager 6.5 прежде чем выполнить любой запрос посылает сначала команду select "Test Connection". "...сервер периодически проверяет(используя механизмы протокола, в данном случае TCP/IP), живое еще соединение или нет..." - что-то меня терзают смутные сомнения. Стал бы он слать такие тупые запросы, если бы были "механизьмы"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2000, 07:27 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Прошу прощения за несколько некорректное описание механизма обработки "осиротевших" (официальный термин) сессий. В действительности всё достаточно полно описано в разделе Orphaned Sessions sql серверных Books Online. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2000, 09:47 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Самое полезное, что написано в Books Online на тему Orphaned Sessions это: To close an orphaned SQL Server session, use the KILL command поскольку Windows NT only performs a check every one or two hours. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2000, 10:12 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Собственно, мне и интересно знать, что происходит с Orphaned Sessions в части транзакций при уничтожении процесса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2000, 10:24 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Что касается Orphaned Sessions, то за 5 лет работы с с-мой, в которой большое кол-во пользователей работают на плохих линиях, эффектов с "половинчатыми" транзакциями не наблюдал. При этом никаких попыток сервера "проверить" соединение не наблюдалось, соответственно, он "рвался" или руками или по таймауту со стороны клиента. Трудно предположить, что подобные механизмы существуют в зависимости от используемой сетевой библиотеки, т.к. Named Pipes (p.e. над TCP/IP) не "умеют" (по определению) инициировать операцию со стороны сервера (выполняющего только Listen On). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2000, 21:58 |
|
||
|
Прерывание транзакции
|
|||
|---|---|---|---|
|
#18+
Да происходит, уважаемый. Например, у нас происходит. Аэропорт Внуково. В сети все протоколы, куча серверов. И вот иногда (вырастает в частенько) мы по два часа и ждем, так как кроме Kill выхода нет, и сам M$ говорит, что лучше им не пользоваться. А иногда эта пара часов длится до перезагрузки сервера.... Посему мне тоже интересно, в чем грабли. Причем иногда бываю сбои в транзакциях из одного оператора (то есть при вызове серверной процедуры). И сама процедура из одного оператора Insert. В процессе трассировки смотрится, что он после Insert ищет @@Identity и на нем виснет, так вот... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2000, 20:08 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32001042&tid=1827527]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 153ms |
| 0 / 0 |
