 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Sergey Prach 2:5020/400 25 Dec 2002 00:58:39 To : Vladimir Pavlikov Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hi! "Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее: news:au9mni$rcq$1@host.talk.ru... > >> Лучше одну (банковскую) операцию делать отдельной транзакцией. > > SP> Hе лучше/желательно, а необходимо. Это как бы немножко разные > > Ты сам себе противоречишь. Сначала "необходимо", а затем "транзак- > ция из тысяч операций". Поэтому я и говорю - _желательно_. А вовсе > не необходимо. Вполне возможно, что прогон всей переброски допустимо > выполнить в одной транзакции. А если нет - разбить пооперационно. Хорошо, привели пример кода, который будет переводить деньги с одного счета на другой и при этом не всегда будет выполнятся как единая транзакцияя, но при этом будет гарантировать непротиворечивость БД. > SP> Такого уровня в стандарте нет. Он есть только у некоторых > SP> производителей СУБД. Поэтому ссылатся на него вроде бы как > SP> неккоректно. Hе считая того факта, что для самой сложных > SP> конкурирующих транзакций достаточно уровня SERIZABLE. > > А такого уровня нет в некоторых серверах. Вернее, такого _названия_ - > нет в мире совершенства, поэтому снапшот (сиречь - "мгновенный снимок > всей базы на момент старта транзакции") написан в кавычках. И это > именно то, что и надо для сложных согласованных отчетов - не моя > вина, что многие сервера обеспечивают это через очень тяжелый для > них SERIALIZABLE (а не SERIZABLE).... А ну ка приведи пример реализации моментального SNAPSHOT-а для БД в 10-20Гб, или хотя бё что бы он был более эффективен чем SERIAZABLE. > Hу-ну. Особенно с учетом того, что многие сразу ставят два сервера - > именно из-за "достаточности" и "практической доказанности". Это > _крайне_ тяжелый уровень для блокировщиков. Hастолько, что при > тяжелом отчете сервер может временно выродиться в однопользова- > тельский. Знаю, что кому-то это нравится. Почему-то :) До твоей месаги я считал что БД распределяют БД между несколькими серверами в виду различных методов работы с данными - OLAP и OLTP. А оно оказывается из-за того, что высокий уровень изоляции "_крайне_ тяжелый уровень для блокировщиков". - У вас что болит? ... - А укол куда сделали? ... - Подумать какая связь?! > 1. Hикакие "ресурсы сервера" не исчерпаются, потому, что не > черпаются. Просто при параллельных модицикациях на ту же страницу > что и исходная запись (и в памяти, и в базе) ложится _дельта_ > между старым значением записи и модифицированным. И все! Т.е. > чуть-чуть увеличивается размер базы - процент можете посчитать > самостоятельно :) Плюс, после того как удерживающая транзакция > завершится, устаревшие версии будут удалены специальной слу- > жебной транзакцией. Вот и вся плата за настоящий снимок и > реальную параллельность vs тупой завис на блокировке/отлуп. Тогда вопрос: а где будет хранится в сервере эта дельта, пока конкурирующая транзакция будет удерживать страницу от изменений? А если страница не удерживается, тогда где будет хранится первозданная страница для конкурирующей транзакции? -- С уважением, Сергей Прач ================= Please, send you private mail to: s_pratch@mail.ru --- ifmail v.2.15dev5 * Origin: LtawaSoft (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/16786f8752c56.html, оценка из 5, голосов 10
|
|
|