|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 22 Aug 2002 15:46:37 To : Sergey Pratch Subject : Re: Отчеты -------------------------------------------------------------------------------- Hello, Sergey Pratch! You wrote to Vladimir Pavlikov on Wed, 21 Aug 2002 20:13:36 +0000 (UTC): >> Это прокатит только на IB, в режиме изоляции RR. В остальных нет, >> из-за возможных фантомов вставки. SP> Это в IB фантомы блокруются в режиме RR, у "ненормальных" - SP> уровень serizable. ;-) Serializable. Увы, и в нем фантомы отсутствуют лишь при повторении _того же самого_ запроса, так что... SP> Так как на этом уровне блокируется слишком много в БД, то лучше SP> залить а этом уровне предварительные выборки во временные таблицы, SP> потом закончить транзакцию, и продолжить работу со временками на SP> стандартном уровне, никому дальше не мешая. А поможет? Вполне возможно, что получение предварительных выборок займет 90+ % от полного, так что игра не стоит свеч. Да и фантомов не убирает. SP> А на счет IB: я в нем небольшой спец. Hо если то, что ты написал SP> правда, то это тоже не настолько хорошо, как может тебе показатся. SP> Сам факт перепрыгивания через уровень изоляции в сравнении со SP> стандартом - не есть good. Кроме того, такой подход заствляет Мне ничего не кажется, с чего ты взял? Что до стандарта - можешь назвать ОДИH сервер, поддерживающий все стандартные уровни изоляции (и никаких других) ровно в том виде, в каком они изложены в стандарте (ни больше, ни меньше) и при этом так, чтобы двумя последними можно было б.м. пользоваться? Hет таких, и это и есть гуд - больно они корявы и бес- смысленны в своем большинстве. Что до IB - это единственный из мне известных серверов, обеспечиваю- щий _единственный_ полностью осмысленный уровень - "мгновенный снимок базы" без большого оверхеда и "выключения" конкурирующих транзакций. Плюс RC - у него их всего два :) SP> разработчика пять раз взвесить, прежде чем им воспользоватся и SP> малейший просчет в эксплуатации может в любой момент вылезть боком. Это еще почему? Именно IB-шный снимок позволяет работать как бы в монопольном режиме, безо всяких проблем. А вот стандартные RR и сериа- лизация вылезают боком _сразу_, вышибая параллельные транзакции и при этом вовсе не гарантируя сходимость балансов... SP> Так как при таком "закрученном до отказа" уровне на время транзакции SP> вся БД для остального мира переходит в режим ReadOnly. А с поправкой Щас. IB RR - это для остальных легче, чем MS RC. SP> на то, что транзакциями в IB управляет сам клиент, а не процедуры на SP> уровне сервера, то это больше похоже парашют в пассажирском SP> авиалйнере - вроде как и дополнительная возможность спастись есть, SP> но только воспользоватся ей практически не возможно. Вот написал же сам выше - "я в нем небольшой спец". Стоит ли после этого писать глупости, основанные на верном понимании уровня собст- венного понимания? :) :( Hет необходимости спасаться (от чего?!). Есть возможность более гибко управлять "разведением" юзеров, что есть гуд. Ибо знающие задачу программист и админ завсегда понимают это лучше, чем не знающий задачу даже супер-пупер сервер. Кроме отдельных ситуаций, которыми рулит как раз сервер :) --------------------------------------------- Владимир Павликов. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6488faae5883.html, оценка из 5, голосов 10
|