Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2
Курдль © (2004-04-30 13:21:00)
Как с ними бороться. Я имею в виду отказ сервера в выборе записей, когда кто-то открыл транзакцию на изменение.

Курдль (2004-04-30 14:29:00) [21]

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

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

Курдль (2004-04-30 14:26:00) [22]

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

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

DenK_vrtz (2004-04-30 14:22:00) [23]
>Курдль © (30.04.04 14:16) [11]
>> в Oracle нет блокировок ?

>Нет

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

Polevi (2004-04-30 14:18:00) [24]
>Курдль © (30.04.04 14:16) [11]
а кроме вас об этом ктонибудь знает ?

roottim (2004-04-30 14:18:00) [25]
в этом то и сложность, которую многие не могут понять, что универсального решения для всех баз нет... многие мсскл-ки пытаются перейти на оракле с малой кровью .. эээ не получиться... временные таблицы, блокировки, и многое что другое организовано по разному...
вообще 1-й том тома кайта (эх как тафтологично :)) думаю дал бы представления по разнице подходов..

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

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

Курдль (2004-04-30 14:16:00) [26]

> 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 для своего зловещего внешнего ключа.

Ega23 (2004-04-30 14:07:00) [27]
1. ЮЗЕР1 открыл транзакцию, создал запись в ТАБЛИЦЕ1 и начал заполнять ее данными.
Т.е. сначала был INSERT, потом, через какое-то время, Юзер1 захотел сделать UPDATE?
Но update ведь, как правило, не по ключевому полю идёт, а по информативным полям.

clickmaker (2004-04-30 14:06:00) [28]

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

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

Polevi (2004-04-30 13:51:00) [29]
>Курдль © (30.04.04 13:35) [4]
в Oracle нет блокировок ?

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

Ega23 (2004-04-30 13:50:00) [31]
А не попахивает ли это "грязным чтением"? :)

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

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

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

clickmaker (2004-04-30 13:41:00) [32]
select что-то from таблица with (nolock)

Курдль (2004-04-30 13:35:00) [33]

> SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

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

Ega23 (2004-04-30 13:33:00) [34]
В смысле?

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Курдль (2004-04-30 13:29:00) [35]
Я уже недавно это слышал и на время даже заткнулся со своими воплями, что oraсle - the best!. Но не хило бы предупреждать непосвященных, чем это грозит!

Ega23 (2004-04-30 13:25:00) [36]
ISOLATION LEVEL поменять

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »