Апологетам "MS SQL Server" - что там с блокировками записей?

← →
Курдль © (2004-04-30 13:21) [0]

Как с ними бороться. Я имею в виду отказ сервера в выборе записей, когда кто-то открыл транзакцию на изменение.

← →
Ega23 © (2004-04-30 13:25) [1]

ISOLATION LEVEL поменять

← →
Курдль © (2004-04-30 13:29) [2]

Я уже недавно это слышал и на время даже заткнулся со своими воплями, что oraсle - the best!. Но не хило бы предупреждать непосвященных, чем это грозит!

← →
Ega23 © (2004-04-30 13:33) [3]

В смысле?

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

← →
Курдль © (2004-04-30 13:35) [4]

> SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

А не попахивает ли это "грязным чтением"? :)

← →
clickmaker © (2004-04-30 13:41) [5]

select что-то from таблица with (nolock)

← →
Ega23 © (2004-04-30 13:50) [6]

А не попахивает ли это "грязным чтением"? :)

Оно и есть. Есть и другие уровни :-) Это я так, для примера из SP-хи одной выдрал.

select что-то from таблица with (nolock)

Тоже вариант.

← →
Курдль © (2004-04-30 13:51) [7]

Пример бизнес-процесса.
1. ЮЗЕР1 открыл транзакцию, создал запись в ТАБЛИЦЕ1 и начал заполнять ее данными.
2. ЮЗЕР2 открыл транзакцию и начал заполнять ТАБЛИЦУ2, в частности - выбрал из нее последнюю появившуюся запись из ТАБЛИЦЫ1 (ту самую, которую тока что внес, не закоммитив, ЮЗЕР1).
3. ЮЗЕР1 задолбался заполнять и сделал CANCEL (ROLLBACK).
Ваши прогнозы, плз.

← →
Polevi © (2004-04-30 13:51) [8]

>Курдль © (30.04.04 13:35) [4]
в Oracle нет блокировок ?

← →
clickmaker © (2004-04-30 14:06) [9]

> Курдль © (30.04.04 13:51) [7]

Дык надо учитывать ситуации, в которых можно грязно читать, а в которых нет. Искать компромисс: слишком высокий уровень транзакций при большой загруженности может приводить к deadlock"ам, слишком низкий - к недостоверности данных.
Если транзакции относительно длинные, то лучше хинты update таблицу with (rowlock) внутри них юзать. А вообще стараться короче их делать

← →
Ega23 © (2004-04-30 14:07) [10]

1. ЮЗЕР1 открыл транзакцию, создал запись в ТАБЛИЦЕ1 и начал заполнять ее данными.
Т.е. сначала был INSERT, потом, через какое-то время, Юзер1 захотел сделать UPDATE?
Но update ведь, как правило, не по ключевому полю идёт, а по информативным полям.

← →
Курдль © (2004-04-30 14:16) [11]

> Polevi © (30.04.04 13:51) [8]
> в Oracle нет блокировок ?

Нет.

> Ega23 © (30.04.04 14:07) [10]
> Т.е. сначала был INSERT, потом, через какое-то время, Юзер1
> захотел сделать UPDATE?

Нет.
Предположим, что в момент t1 сделал INSERT а в момент t2 сделал ROLLBACK, но именно между этим, возможно даже очень малым промежутком времени, ЮЗЕР2 и сделал своё черное дело - получил ID записи из ТАБЛИЦЫ1 для своего зловещего внешнего ключа.

← →
roottim (2004-04-30 14:18) [12]

в этом то и сложность, которую многие не могут понять, что универсального решения для всех баз нет... многие мсскл-ки пытаются перейти на оракле с малой кровью .. эээ не получиться... временные таблицы, блокировки, и многое что другое организовано по разному...
вообще 1-й том тома кайта (эх как тафтологично :)) думаю дал бы представления по разнице подходов..

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

а чтение грязных данных - это вообще приведет к краху.. особенно фин-систем

← →
Polevi © (2004-04-30 14:18) [13]

>Курдль © (30.04.04 14:16) [11]
а кроме вас об этом ктонибудь знает ?

← →
DenK_vrtz © (2004-04-30 14:22) [14]

>Курдль © (30.04.04 14:16) [11]
>> в Oracle нет блокировок ?

>Нет

Ты наговоришь! В документации этому аж целая главая посвящена.
Каких блокировок там только нет.

← →
Курдль © (2004-04-30 14:26) [15]

> Ты наговоришь! В документации этому аж целая главая посвящена.
> Каких блокировок там только нет.

Только нет таких, которые мешают работать с базой :(
Я вот все думал, откуда берутся программеры, у которых в голове всё какие-то временные таблицы или хуже того - трехзвенки. Оказывается - с MSSQL-я. :(

← →
Курдль © (2004-04-30 14:29) [16]

> roottim (30.04.04 14:18) [12]
> для оракла любая транзакция по длительности есть гуд , то
> биш нет проблем...

Если не считать, что он начинает дико жрать ресурсы.

← →
Ega23 © (2004-04-30 14:30) [17]

Предположим, что в момент t1 сделал INSERT а в момент t2 сделал ROLLBACK, но именно между этим, возможно даже очень малым промежутком времени, ЮЗЕР2 и сделал своё черное дело - получил ID записи из ТАБЛИЦЫ1 для своего зловещего внешнего ключа.

Может я конечно чего-то недопонимаю, но разве в один момент времени могут обрабатываться сервером 2 разные транзакции?

← →
jocko © (2004-04-30 14:34) [18]

>Как с ними бороться.
1. не открывать транзакции с клиента (есть такие любители)
2. сузить транзакции, т.е. не вычислять переменные внутри транзакций, не делать селектов внутри тран. (иначе на время выполнения тран. записи блокируются, и надо помнить еще про эскалации)
3. разбивать длинные транзакции (по возможности)
4. следить за тем, чтобы небыло прерываний timeout при вызове с клиента (это вообще полная ж...), или вовремя отслеживать и делать например, while @@trancount > 0 rollback tran, иначе эта гадость будет вообще висеть непонятное количество времени :-(

← →
roottim (2004-04-30 14:36) [19]

>Если не считать, что он начинает дико жрать ресурсы.
это какие???... и при каких условиях ?
и всеже почитай тома.. со вкусом написано... и на понятном каждому уровне, думаю многие вопросы отпадут сами сабой...

← →
bushmen © (2004-04-30 14:47) [20]

>Только нет таких, которые мешают работать с базой :(

Если блокировки мешают работе, то это уже зависит от программиста, который коряво пишет программы.

← →
Курдль © (2004-04-30 14:52) [21]

> Если блокировки мешают работе, то это уже зависит от программиста,
> который коряво пишет программы.

Если программист пишет программы с базами на "парадоксе", которые (как неоднократно здесь упомяналось) имеют свойство рушить собственные индексы, то это я называю "коряво писать программы". Т.е. как бы ни был хорош программист - рано или поздно юзер останется без данных.

← →
dimm22 (2004-04-30 14:59) [22]

Сразу чувствуется, что пятница. Народ пофлеймить потянуло. Даёшь версионность всем БД !!!(Читать как Ibase, Oracle - cool; MSSQL- shit.)

← →
Polevi © (2004-04-30 15:17) [23]

да макрософт вообще ацтой, виндовс масдай
даешь оркл на линуксе !

← →
Fay © (2004-04-30 16:43) [24]

2Polevi © (30.04.04 15:17) [23]
В таких ответах принято ставить смайлики.

← →
Fay © (2004-04-30 16:46) [25]

2Курдль © (30.04.04 14:26) [15]
Для такого ответа необходим скромный (и только!) опыт работы с Oracle и никакой с MSSQL.

> jocko © (30.04.04 14:34) [18]
> вовремя отслеживать
> и делать например, while @@trancount > 0 rollback tran

Роллбэк из внутренней транзакции октатит все внешние транзакции тоже. Просто перед коммитом или роллбэком нужно проверять значение @@trancount. Но в цикле - ? Смысл?

Nikolay M. © (30.04.04 16:51) [26]
>> Но в цикле - ? Смысл?
В MSSQL есть такая фигня в процедурах - не всегда очевидно, какой @@trancount. Обычное дело при явном старте транзакции в процедуре.

> не всегда очевидно, какой @@trancount

Можно пример, если не трудно?
Впервые слышу, что после ролбэка может быть @@trancount <> 0.

В таких ситуациях второй print может выдать нечто большее нуля.
print @@trancount begin tran tran1 ... rollbact tran tran1 print @@trancount

Сейчас времени на эксперименты нет, но потом обязательно исследую этот вопрос. Хочешь сказать, что пкоа сервер освобождает ресурсы, схаванные транзакцией, он не выставит правильное значение @@trancount?

Когда я сам на такое нарвался, бяда проявлялась в том, что оставались открытые транзакции. С тех пор выходили всякие servicefuck-и, но я по сию пору пишу с циклом. 8)

> С тех пор выходили всякие servicefuck-и

Так может в них уже проблема решена? Я, признаться, без SP4 на 2000-м даже и не работал...

У меня 4-ы ещё не установлен.Проверка временем не прошла.
Проверю на 3-м - любопытно стало. 8)

> Проверка временем не прошла.

Why?

> Проверю на 3-м - любопытно стало. 8)

Жду-с :)

Это будет не сегодня. День не подходящий 8)

> Для такого ответа необходим скромный (и только!) опыт работы
> с Oracle и никакой с MSSQL.

Совершенно в точку! :(
А MSSQL вообще прозвучал в топике, для привлечения внимания (т.к. он младший брат Sybase - тоже, млин, "блокировщик").
Однако, мой скромный опыт работы с ораклом не принес ни одного разочарования. Ну, если не считать легкой SQL-ной недостаточности в 8-м и тяжелой - в 7-м. :)

Апологетам "MS SQL Server" - что там с блокировками записей? Найти похожие ветки