su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Lilya A. Kozlenko                    2:5025/17      04 Jun 2001  09:56:19
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 
 
 > Я не специалист в MS SQL, но не понимаю, зачем это убрали.
 > Это же касается настройки блокировки на уровне строк. Она-то хоть была?
 
 В 6.х была, но частично, на insert была страничная, для delete, update
 строковые. Сейчас вот наконец-то сделали для всех dml.
 
 > То есть что получается, что раз на MS SQL нельзя принудительно
 > выставить row-level locking для таблицы, нельзя управлять трешолдами
 > эскалации,
 > то как работать-то? Hеужели сервер умнее человека?
 
 Эскалация блокировки зависит от общего количества блокированных
 записей, страниц, и т.п. в таблице - раз, от загруженности структуры,
 которая хранит и обрабатывает блокировки - два.
 В большинстве реализаций эскалация возникает тогда, когда одну
 грубую блокировку хранить выгоднее, чем много мелких (в данном
 случае строковых). Именно это влияет на эскалацию блокировок.
 В некоторых реализациях можно управлять процессом эскалации,
 в некоторых нет, в этом нет ничего сверхординарного.
 
 > Как он узнает, что если из таблицы в которой 10 млн. строк я удаляю 8
 
 млн.,
 
 > то не надо блокировать таблицу? не хочу я этого, я лучше подожду, у меня
 
 В данном случае возникнет эскалация блокировки. Можешь шуметь
 по этому поводу сколько угодно, но для таких длинных модификаций
 (они же long lived transaction) существуют свои протоколы обработки.
 Если их нет у сервера, то реализуют ручками. И опять же, если тебе
 надо столько записей удалить, то обязательно ли надо делать
 это одной большой пачкой и напрягать журнал. Вот в чем вопрос.
 Hадо сделать так, как это для сервера лучше, а не для тебя любимого
 (хотя это тоже не наказуемо, только вот архитектуру сервера ты не
 изменишь, как не старайся). Здесь надо идти по пути снижения
 конфликтности транзакций. например, разбивать long lived transaction
 на несколько мелких кусков и вводить механизм контроля атомарности -
 то есть контролировать, чтобы все мелкие транзакци обязательно
 выполнились (atomicity + durability контролировать обязательно надо),
 isolation придется в этом случае немного принебречь, так как
 у тебя будут фиксироваться изменения после прохождения каждой
 мелкой транзакции. Тоже касается consistency - возможно потребуется
 вводить компенсирующую транзакцию, а возможно и нет, это уже
 зависит от твоего конкретного приложения.
 И опять же, сам подумай, у сервера будет 8 000 000 записей о блокиросках,
 а он ведь не только delete твой обрабатывает, вот и сам смотри, каким
 замедляющим фактором при запросе "а можно ли заблокировать объект"
 будет такой объем блокировок. Ведь прежде, чем наложить блокировку,
 менеджер транзакций запрошивает ее, то есть проверяется не
 заблокирован ли объект, и если, то чем и как.
 
 --
  Regards, Lilya Kozlenko
 --- Microsoft Outlook Express 5.50.4522.1200
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор