 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Dmitry Kuzmenko 2:5020/400 08 Jan 2003 14:40:44 To : Sergey Prach Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hello, Sergey! Sergey Prach wrote: > Хорошо, давай без "ну". Володенька, приведи пожалуйста пример реализации > моментального SNAPSHOT-а для БД в 10-20Гб, или хотя бы что бы он был более > эффективен чем SERIALIZABLE, когда модификации подвергаются около 20% > данных. SNAPSHOT не может быть более эффективным чем SERIALIZABLE как минимум потому, что первый ниже по уровню изолированности чем второй, по определению. если в IB стартануть snapshot, то даже если он не будет ничего читать или писать, то при обновлении 20% данных другими транзакциями БД увеличится в размере где-то на 15% или меньше, в зависимости от физического кол-ва изменений (если в записи из 100 полей менять только одно поле, то delta будет очень маленькой). > Володенька, совместный доступ на модификацию конкурентных даных - это > всегда проблема, хоть для версионников, хоть для блокировочников. И при > решениии этой проблемы всегда одна транзакция погибает. Только у ? в версионнике ничего не погибает, даже если у транзакции стоит параметр WAIT. Другое дело, что от приложения зависит, чем завершить транзакцию, в которой одна из операций завершилась с ошибкой по блокировке. для ReadCommitted операцию можно повторить, и если все будет OK, то сделать commit. А вот для snapshot - увы, да, придется делать rollback (т.к. он не имеет права видеть чужие committed изменения). > Так вот и в споре про блокировочник и версионник: если в первом одна из > транзакций практически всегда сдыхает, и только в редких случаях (dead > lock) - обе, то в версионнике приведение всех версий в соотвтетстве - всегда > головная боль и всегда довольно большие затраты на дисковый обмен. не вижу головной боли. Конфликт обновлений в версионнике это банальная проверка на существование non-committed версии конкретной записи. Если таковая есть - оператор update/delete обламывается по ошибке, и в RC его можно повторить. Если таковой нет - запись не "блокирована". -- Dmitri Kouzmenko, www.ibase.ru, 953-13-34 Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: iBase (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/27749805252a.html, оценка из 5, голосов 10
|
|
|