Опросы
Активных опросов на данный момент нет.
Счетчики
Rambler's Top100





Яндекс цитирования


Rambler's Top100
А  Б  В  Г  Д  Е  Ж  З  И  К  Л  М  Н  О  П  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Э  Ю  Я
0-9  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z
Страниц: << < 1 2 3 4 5 > >>

Я проектировал базу данных таким образом, чтобы она не выдавала ошибок
блокировки вообще, а в случае возникновения конфликтов ждала, пока
блокирующая транзакция завершится, и продолжала свою работу (разумеется о
deadlock'ах здесь речь не идет, когда две транзакции взаимоблокируются,
ожидая окончания друг друга, т.к. в нормально спроектированной базе такого
быть не должно). Для этих целей все транзакции должны стартовать с
параметром WAIT и быть максимально быстрыми, чтобы надолго не блокировать
работу других конкурентных транзакций. Очевидно, что уровень изоляции
SNAPSHOT для транзакций, изменяющих данные, в данном случае не подойдет.
Решено было остановится на READ COMMITTED RECORD_VERSION. Прочитав много
разных статей и документацию я был убежден, что такая транзакция, запущенная
с параметром WAIT, в случае попадания на конфликт при изменении данных будет
ждать окончания блокирующей транзакции, и независимо от того, чем та
закончится - COMMIT или ROLLBACK, продолжит свою работу по изменению этих
данных. Все оказалось не так. Транзакция READ COMMITED RECORD_VERSION WAIT
действительно может изменять данные, которые были изменены другой
транзакцией, стартовавшей позже, и подтверждены по COMMIT, но только в том
случае, если подтверждение было раньше, чем первая транзакция приступит к
изменению этих данных и попадет на конфликт и последующее ожидание. Если
случится конфликт, то в случае если блокирующая транзакция откатится,
ожидающая транзакция сможет изменить данные и продолжит свою работу, однако
если блокирующая транзакция подтвердится, то ожидающая транзакция вместо
того, чтобы увидеть подтвержденные данные и изменить их снова, выйдет по
ошибке deadlock, что является странным для READ COMMITTED транзакции. В этом
случае ее поведение ничем не отличается от транзакции SNAPSHOT и
практическое применение параметра WAIT кажется сомнительным.

В отличие от большинства баз данных, IB не хранит лог отмены транзакций, а вместо этого использует версии записей для конкурентного доступа, для неизменяемого представления данных, и для восстановления.

  Если требуется вставить в строку произвольный символ (например, символ переноса каретки CRLF), то это можно сделать по коду символа в таблице символов при помощи функции ASCII_CHAR().

  Очень часто начинающий разработчик на IB/FB, особенно имеющий опыт работы на SQL-серверах блокировочного типа, задаётся вопросом – а как же мне добиться в многопользовательской среде того, чтобы пользователи не редактировали одновременно одни и те же данные, и не записывали их изменения один поверх другого? И начинают искать способы блокирования записей, которых в IB/FB в чистом виде нет. А точнее, не было до FB 1.5, но об этом мы поговорим в конце статьи.

  Начиная с версии InterBase 6.0 все нижеизложенное является хаком, т.к. в InterBase 6 и всех версиях выше (InterBase, Firebird, Yaffil) поддерживается оператор table column. См. документацию.

  Этот документ описывает методы и правила получения статистики из баз данных InterBase/Firebird (при помощи gstat или IBAnalyst).


 Публикации 

Начало раздела > Публикации > Базы данных > InterBase/Firebird

Как работает версионность данных


>Под стоимостью транзакции я предполагаю затраты для пользователя A,
>получающего большой набор записей, в то время как другие пользователи
>модифицируют записи этого набора.

Из этого вопроса я делаю вывод, что есть некоторое непонимание версионности данных в IB, поэтому ответ на этот вопрос будет длинным и детальным.

  IB Database обладает интересной недокументированной возможностью. Обычно при объявлении вычисляемого поля COMPUTED BY придерживаются синтаксиса

  Известно, что InterBase/Firebird - это версионный сервер. Версии записей создаются при update и , живут определенное время (пока нужны транзакциям), и убираются как мусор в определенные моменты. Мусорные версии записей - это те, которые уже не нужны ни одной активной транзакции.

  Иногда возникает необходимость проводить с датой какие-либо операции что мы и попытаемся изложить.

Страниц: << < 1 2 3 4 5 > >>
 
 
© 2018