su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Ilya Bricker                         2:5020/400     05 Jun 2001  15:12:24
 To : All
 Subject : Re: Informix ?
 -------------------------------------------------------------------------------- 
 

 
 Привет,
 
 "Lilya A. Kozlenko" <Lilya.A.Kozlenko@f17.n5025.z2.fidonet.org> wrote in
 message news:479329431@mail.relex.ru...
 
 > Hi!
 >
 >
 > > Я не специалист в MS SQL, но не понимаю, зачем это убрали.
 > > Это же касается настройки блокировки на уровне строк. Она-то хоть была?
 >
 > В 6.х была, но частично, на insert была страничная, для delete, update
 > строковые. Сейчас вот наконец-то сделали для всех dml.
 
 Я говорю про _настройку_ блокировок, т.е. как этим можно управлять,
 а если нельзя управлять прямо, то как можно управлять косвенно,
 это касается и эскалации, какие предположения я как разработчик
 могу делать, а какие нет, что почитать на эту тему
 
 > > Как он узнает, что если из таблицы в которой 10 млн. строк я удаляю 8
 > млн.,
 > > то не надо блокировать таблицу? не хочу я этого, я лучше подожду, у меня
 >
 > В данном случае возникнет эскалация блокировки. Можешь шуметь
 > по этому поводу сколько угодно, но для таких длинных модификаций
 > (они же long lived transaction) существуют свои протоколы обработки.
 > Если их нет у сервера, то реализуют ручками. И опять же, если тебе
 > надо столько записей удалить, то обязательно ли надо делать
 > это одной большой пачкой и напрягать журнал. Вот в чем вопрос.
 
 Как ты узнала что будет эскалация? ;-)
 Может, общепринятая практика - добавлять в таблицу из 100 строк
 еще тысячу незначащих записей? чтобы сервер вдруг не решил
 что ему пора сделать табличную блокировку если я в этой таблице
 десяток-другой записей заапдейтил.
 Причем 10 или 80, решаю не я, а пользователь, он галки ставит
 
 > Hадо сделать так, как это для сервера лучше, а не для тебя любимого
 > (хотя это тоже не наказуемо, только вот архитектуру сервера ты не
 > изменишь, как не старайся).
 
 Почему же. Ты же для своей задачи изменила :-)
 
 > Здесь надо идти по пути снижения
 > конфликтности транзакций. например, разбивать long lived transaction
 > на несколько мелких кусков и вводить механизм контроля атомарности -
 
 Транзакция атомарна по сути, только механизм хранения контекста
 у такой транзакции несколько иной, а именно доморощенный,
 а сервер занимается sub-транзакцими. То что транзакция раз начавшись
 уже не может откатиться, не мешает ей формально называться
 транзакцией, просто все конечные состояния объявляем
 консистентными ;-)
 То что ты предлагаешь сделать мне безусловно известно, только ведь
 сколько кода надо написать, таких мест не должно быть в системе
 много.
 Сервер железный, его задача миллион моих строчных локов
 обработать и не заблокировать кого ненароком, а не демонстрировать
 спринтерские качества за счет динамического изменения стратегии
 блокирования и эскалаций, это не моя задача создавать свой
 транзакционный механизм каждый раз когда есть опасность нарваться
 на эскалацию. Мне надо чтобы система работала всегда, а не через раз,
 а блокирование таблицы в длинной транзакции это останов :(
 
 Может, есть какие-то новые хинты в запросах?
 
 --
 Илья Бриккер
 http://ivb.unact.ru
 --- ifmail v.2.15dev5
  * Origin: MTU-Intel ISP (2:5020/400)
 
 

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