|
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
