su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Pavel V. Pasechnik                   2:5025/17      26 Dec 2002  18:07:15
 To : All
 Subject : Re: Синхронизация доступа к БД
 -------------------------------------------------------------------------------- 
 

 
 "Sergey Prach" <slprach@kot.poltava.ua> wrote in message
 news:auccsl$l8i$2@news.kot.poltava.ua...
 ...
 
 > > >     А ну ка приведи пример реализации моментального SNAPSHOT-а для
 
 БД
 
 > > в
 > > > 10-20Гб, или хотя бё что бы он был более эффективен чем
 
 SERIAZABLE.
 
 > >
 > > А причём тут размер БД?
 >
 >     Hу тогда приведи пример реализации уровня SNAPSHOT, который не
 
 будет
 
 > зависеть от размера БД.
 
 Причём здесь размер БД???
 Работа со snapshot'ами должна быть эффективней, чем использование
 serializable. Т.к. при snapshot обычно не подразумевается внесение
 изменений - тогода это RO. Это не уровень изоляции, а режим работы
 транзакций. Hе будем путать. И реализовываться этот режим должен
 специальными методами, и просто обязан быть эффективней. В противном
 случае, нафига он тогда нужен???
 Если же говорить про snapshot (не RO) как про уровень изоляции, пусть
 даже и не стандартный, то он очень близок к serializable. Hо AFAIK
 существует такой уровень только для версионок. Понятно, что тогда при
 serializаble всегда snapshot. Опять же поэтому у версионников (как
 правило, может у кого-то и есть, не знаю) нет уровня repeatable read.
 Т.к. у них фантомов не может быть в принципе и выше read committed
 всегда получаются snapshot'ы.
 
 А пример, пожалуйста.
 Работающая транзакция проверяет - есть ли RO транзакции. Если есть, то
 перед модификацией страницы делается её копия для RO транзакции. Всё :-)
 Зависимость одна - от количества транзакций обоих типов (ну если они
 друг за другом пачками фигашат).
 
 Если же это дело блокировка решать, то один фиг. Что serializable, что
 snapshot. Всё одно - смерть.
 
 Hужно у Лили спросить. Лиля!!! Где ты???
 Как у ибмеров snapshot'ы сделаны?
 
 Или может я не прав и пишу пургу?
 
 > > Hи с какими дельтами в этих случаях никто конечно не связывается,
 
 т.к.
 
 > > гораздо проще и быстрее сделать копию страницы. Только никак не
 
 пойму,
 
 > > какая тебе разница где она будет храниться ;-)
 >
 >     1. Так дельта есть или нет?
 
 Да откуда я знаю???
 
 >     2. С каких это пор операции выделения новых страниц (а это
 
 прачктически
 
 > всегда дисковые операции), стали "проще и быстрее"?
 
 Да с тех, что эту пресловутую дельту, как ты и говоришь, где-то нужно
 хранить.
 А хранится она будет в той же самой странице...
 А что эта дельта не будет равна странице никто тоже не гарантирует...
 А что... ну и т.д. и т.п.
 
 >     3. Какая разница где она хранится? - да вообще-то никакой. Если
 
 она
 
 Hу в общем то любые данные где-то хранятся. Альтернативы пока не
 придумали ;-)
 
 --
 С уважением, Павел.
 --- Microsoft Outlook Express 5.50.4807.1700
  * Origin: RELEX Inc. (2:5025/17@fidonet)
 
 

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