 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 26 Dec 2002 18:44:25 To : Sergey Prach Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hello, Sergey Prach! You wrote to Vladimir Pavlikov on Tue, 24 Dec 2002 20:58:39 +0000 (UTC): >> Ты сам себе противоречишь. Сначала "необходимо", а затем "транзак- >> ция из тысяч операций". Поэтому я и говорю - _желательно_. А вовсе не >> необходимо. Вполне возможно, что прогон всей переброски допустимо >> выполнить в одной транзакции. А если нет - разбить пооперационно. SP> Хорошо, привели пример кода, который будет переводить деньги с SP> одного счета на другой и при этом не всегда будет выполнятся как SP> единая транзакцияя, но при этом будет гарантировать SP> непротиворечивость БД. "Перевод денег с одного счета на другой" - это _одна_ операция. Разумеется, проводится в одной транзакции. Это не "тысячи операций в транзакции". Даже как-то странно слышать такое от тебя - это же не версионность :), тут у тебя проблем быть не должно. SP> А ну ка приведи пример реализации моментального SNAPSHOT-а для SP> БД в 10-20Гб, или хотя бё что бы он был более эффективен чем SP> SERIAZABLE. "Hукать" дома будешь. IB. Фиксация самого факта старта транзакции с уровнем RR (а это все, что нужно) времени не требует вообще. И никак не зависит от размера базы - что мег, что тера - все одно. За подробностями - к Диме на сервер. >> Hу-ну. Особенно с учетом того, что многие сразу ставят два сервера - >> именно из-за "достаточности" и "практической доказанности". Это >> _крайне_ тяжелый уровень для блокировщиков. Hастолько, что при >> тяжелом отчете сервер может временно выродиться в однопользова- >> тельский. Знаю, что кому-то это нравится. Почему-то :) SP> До твоей месаги я считал что БД распределяют БД между SP> несколькими серверами в виду различных методов работы с данными - SP> OLAP и OLTP. А оно оказывается из-за того, что высокий уровень SP> изоляции "_крайне_ тяжелый уровень для блокировщиков". А сейчас считаешь по другому? Жаль - я написал то же самое : корот- кие модификации - это OLTP. Длинные отчеты по всей базе - OLAP. Hу а то, что блокираторы эту смесь не тянут никак - общеизвестно. Ибо сериализация одних просто вырубает других. Где противоречие? SP> - У вас что болит? ... - А укол куда сделали? ... - Подумать какая SP> связь?! "Hе проще ль на себя, кума, оборотиться?" (С) SP> Тогда вопрос: а где будет хранится в сервере эта дельта, пока SP> конкурирующая транзакция будет удерживать страницу от изменений? А SP> если страница не удерживается, тогда где будет хранится первозданная SP> страница для конкурирующей транзакции? Уже отвечено, и не одним. ЗЫ. Сначала безапелляционные утверждения, затем - вопросы... Этот симптом прохожу далеко не впервые :) --------------------------------------------- Владимир Павликов. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/6488aaad8f77.html, оценка из 5, голосов 10
|
|
|