|
Sybase
|
|
|
|
|
|
|
Продукты
|
|
|
|
|
|
|
Сообщества
|
|
|
|
|
|
|
Меню
|
|
|
|
|
|
|
Вход
|
|
|
|
|
|
|
Рассылка
|
|
|
|
|
|
|
Статистика
|
|
|
|
|
|
|
Выпуск 15
|
Выпуск 15
Доброй день, уважаемые подписчики. Предлагаю Вашему
вниманию очередной, 15-й номер рассылки. В данном номере
рассылки я публикую свою статью, посвященную механизму
транзакций в ASA 9.
Все что мы знаем о
транзакциях в ASA 9
Вступление от
автора
Данная статья рассчитана на
читателей, имеющих как минимум представление о таких
понятиях, как транзакции и зачем они нужны. Если Вы
точно не представляете себе, что такое транзакции, то
рекомендую прочитать вводную статью "Введение в управление транзакциями",
опубликованную издательством "Открытые
системы".
Реализация транзакционного механизма в ASA
9
Данная версия РСУБД является чистым
блокировочником. Соответствующе, как и полагается для
чистого блокировочника, писатели всегда блокируют
читателей, а читатели блокируют писателей в зависимости
установленного для них уровня изоляции. Для обеспечения
надежной реализации транзакций используется специальный
лог-файл для каждой базы данных. В него фиксируются все
проводимые операции DDL и DML. Используется
оптимистическая модель реализации транзакций, т.е.
предполагается, что в большинстве случаев транзакции
будут закончены успешно (по COMMIT). Соответствующе сам
оператор COMMIT занимает минимальное кол-во времени, в
то время как откат транзакции ROLLBACK достаточно
большое время. В связи с этим рекомендуется не делать
без необходимости длинные транзакции, в которых
участвует большое кол-во данных.
Поддерживаемые уровни изоляции
транзакций
READ UNCOMMITED
(опция
ISOLATION_LEVEL=0)
Определение:
Уровень
грязного чтения.
Описание:
На этом уровне
изоляции читающая сессия видит все данные, даже те,
которые сейчас изменяются другими сессиями-писателями и
еще не были подтверждены COMMIT. Во время выполнения
самого SELECT никакие блокировки текущей сессией не
устанавливаются. Таким образом, данный уровень изоляции
является с одной стороны самым быстрым, не зависящим от
пишущих сессий, не блокирующим пишущие сессии и не
ресурсоемким, за счет того, что во время чтения данных
не приходится ждать снятия блокировок пишущих сессий и
тратить ресурсы на установку своих блокировок. С другой
стороны этот способ является самым плохим в плане
получения актуальных данных – нет никаких гарантий, что
после того, как будут возвращаться данные, эти данные в
том же виде присутствуют в базе данных, любая пишущая
сессия может добавить, изменить или удалить записи.
Область применения:
Данный уровень
изоляции с точки зрения производительности идеально
подходит для чтения тех данных, для которых есть 100%
гарантия, что они ни кем не могут изменяться. В качестве
примера можно привести учетные задачи, где есть понятие
закрытия расчетного периода (бухгалтерия, заработная
плата, коммунальные платежи, опердень и т.д.) или
архивные данные. Так же данный уровень изоляции удобно
использовать для получения текущего состояния данных с
не критичным понятием актуальности данных. Здесь в
качестве примера можно привести сам Sybase Central,
который, используя данный уровень изоляции, позволяет
просматривать данные по таблицам, вне зависимости от
того, изменяются ли они в текущий момент в пишущих
транзакциях.
READ COMMITED (опция
ISOLATION_LEVEL=1)
Определение:
Чтение
только подтвержденных данных.
Описание:
На
этом уровне изоляции читающая сессия видит только
подтвержденные данные. Если в ходе выполнения запроса
встречаются данные, которые по условиям запроса подходят
по своим параметрам, но на текущий момент они находятся
в еще неподтвержденной транзакции, то выполнение запроса
будет остановлено и сессия будет ожидать снятия
блокировки с таких данных, чтобы окончательно решить,
войдут ли эти данные в результат выполнения запроса.
Сама читающая сессия во время чтения записей, будет
вешать блокировку только на текущую обрабатываемую
запись. При переходе на следующую подходящую запись в
таблице, блокировка с предыдущей будет снята и
установлена на новую обрабатываемую запись. Таким
образом, данный уровень изоляции с одной стороны
является зависящим от блокировок пишущих сессий,
частично блокирующим пишущие сессии и не ресурсоемким,
за счет того, что во время обработки записей
накладывается всего лишь одна блокировка на текущую
обрабатываемую запись. Однако этот уровень изоляции так
же не гарантирует получения актуальных данных, так как
во время выполнения запроса, вполне возможны действия
пишущих сессий по изменению и удалению данных, которые
уже были обработаны в ходе запроса и добавление новых,
которые подойдут своими параметрами под условия текущего
выполняемого запроса.
Область
применения:
Данный уровень изоляции идеально
подходит для возврата информации клиентским приложениям
для ее последующей визуализации в виде гридов, форм
данных и т.д., где текущее состояние данных на момент
запроса не критично и служит в основном для
информативного представления (среза) о данных на текущий
момент. Рекомендуется этот уровень изоляции поставить по
умолчанию для всех подключаемых
сессий.
REPEATABLE READ (опция
ISOLATION_LEVEL=2)
Определение:
Гарантия
повторного чтения данных.
Описание:
Данный
уровень изоляции гарантирует, что до завершения
транзакции, прочитанные данные при их повторном чтении
не будут изменены или удалены. Если в ходе выполнения
запроса встречаются данные, которые по условиям запроса
подходят по своим параметрам, но на текущий момент они
находятся в еще неподтвержденной транзакции, то
выполнение запроса будет остановлено и сессия будет
ожидать снятия блокировки с таких данных, чтобы
окончательно решить, войдут ли эти данные в результат
выполнения запроса. Сама читающая сессия во время чтения
записей, будет вешать блокировку на каждую подходящую
под условия запроса запись, что гарантирует, что их не
смогут изменить или удалить пишущие сессии. Таким
образом, данный уровень изоляции с одной стороны
является зависящим от блокировок пишущих сессий,
блокирующим пишущие сессии на изменение и удаление
вошедших в запрос записей и ресурсоемким, за счет того,
что во время обработки записей накладывается блокировки
на все обрабатываемые записи. Однако этот уровень
изоляции так же не гарантирует получения полностью
актуальных данных, так как во время выполнения запроса,
вполне возможно добавление записей пишущими сессиями или
изменения существующих других записей, которые по своим
параметрам подойдут под условия текущего выполняемого
запроса.
Область применения:
Данный уровень
изоляции идеально подходит для получения и обработки
информации в виде ограничивающих запросов, для тех
случаев, где основной операцией является добавление
записей, операции изменения и удаления записей
достаточно редки и есть возможность получения последней
точки подтвержденной информации с целью задания условия
запросу, позволяющему 100% гарантировать, что новые
добавляемые записи другими сессиями уже не подойдут
своими параметрами под условия запроса. Например, это
удобно для таблиц с TIMESTAMP полем, фиксирующим время
добавления и изменения записи. Если получить TIMESTAMP
последней подтвержденной вставленной записи на данном
уровне изоляции, то до момента завершения транзакции по
COMMIT можно уверенно считать, что любой запрос, имеющим
в условии ограничение по эту точку, будет содержать в
себе актуальные данные, при условии, что TIMESTAMP
всегда проставляется сервером в восходящем порядке.
Таким образом пишущие сессии, добавляющие данные, не
будут блокированы и смогут продолжать свою работу, а
сессии, пытающиеся изменить или удалить данные,
попадающие по условиям на обрабатываемые записи в
текущей сессии, будут вынуждены остановиться и ждать
окончания транзакции и снятия с записей
блокировок.
SERIALIZABLE (опция
ISOLATION_LEVEL=3)
Определение:
Гарантия
полной актуальности данных при повторном
чтении.
Описание:
Данный уровень изоляции
гарантирует, что до завершения транзакции, прочитанные
данные при их повторном чтении не будут изменены или
удалены, а так же добавлены новые, которые могли бы
подойти под условия выполняемого запроса. Если в ходе
выполнения запроса встречаются данные, которые по
условиям запроса подходят по своим параметрам, но на
текущий момент они находятся в еще неподтвержденной
транзакции, то выполнение запроса будет остановлено и
сессия будет ожидать снятия блокировки с таких данных,
чтобы окончательно решить, войдут ли эти данные в
результат выполнения запроса. Сама читающая сессия во
время чтения записей, будет вешать блокировку на каждую
обрабатываемую запись, что гарантирует, что их не смогут
изменить или удалить пишущие сессии.
Таким образом,
данный уровень изоляции с одной стороны является
зависящим от блокировок пишущих сессий. Этот уровень
является наиболее ресурсоемким, за счет того, что во
время обработки записей накладывается блокировки не
только на все подходящие под условия запроса записи, но
и другие записи, изменение параметров которых другими
сессиями могло бы сделать их подходящими под условия
запроса, т.е. на потенциальных фантомов. Это означает,
что другие пишущие сессии могут быть полностью
блокированы на добавление, изменение и удаление даже тех
данных, которые не попали под условие выполняющегося
запроса, но все равно были им заблокированы (фактически
могут быть заблокированы записи всех обрабатываемых
таблиц). Если в условии фильтрации или соединении таблиц
запроса используются только булевые операции равенства
(“=” и “IN”), а так же на какое либо поле или поля,
участвующие в условиях запроса, организован индекс, то
возможно уменьшение кол-ва блокировок и ресурсоемкости
запроса, путем использования индексных блокировок (о
видах блокировок читайте в следующей рассылке).
Например, если присутствует уникальный индекс (PK,
UNIQUE CONSTRAINT или UNIQUE INDEX), то серверу будет
достаточно повесить блокировку на соответствующий
блокируемой записи узел индекса, таким образом
гарантировав, что никто из сессий не может добавлять,
изменять или удалять данные, что привело бы к
перестройке индекса, начиная с заблокированного узла.
Если же присутствует неуникальный индекс (Foreign Key
или INDEX), то серверу придется заблокировать не только
соответствующий блокируемой записи узел индекса, но и
следующий за ним узел, чтобы никто из сессий не мог
провести операции с записями, что привело бы к
перестройке индекса между этими узлами. Таким образом
операция сравнения на равенство в условии запроса и
уникальный индекс дает блокировку только на подходящую
под условие запись, а не уникальный индекс на подходящую
под условие запись и следующую за ним, пусть и
неподходящую под условию запись. Однако любое
использование других операций сравнения (“<”, “>”,
“<>”, “NOT” и BETWEEN) не позволяет задействовать
блокировки по индексам и таким образом ведет к полной
блокировке используемых в запросе таблиц.
Область
применения:
Подразумевается, что данный уровень
изоляции идеально подходит для получения полностью
согласованных и актуальных данных и отчетов на момент их
построения, однако большая ресурсоемкость данного уровня
и его способность полностью перекрыть блокировками
другие пишущие транзакции, заставляет использовать этот
уровень только в действительно необходимых и оправданных
случаях и только при грамотном подходе реализации
архитектуры базы данных для минимизации затрат
выполнения запросов. Данный уровень, прежде всего
следует использовать для таких критических операций, как
закрытие расчетных периодов, с расчетом остатков,
балансов и другой критической информации, для которой
важно, чтобы во время проведения расчета, никакая
пишущая сессий не могла повлиять на используемую в
расчетах информацию и исказить ее, что привело бы к
неправильным результатам расчетов и противоречивым
данным в базе данных. Здесь вполне закономерны и
обоснованы затраты на повышенные требования во время
проведения операции к ресурсам и полной блокировке
других пишущих сессий. Стоит только заметить, что
следует стремиться к сокращению времени выполнения
запросов на таком уровне изоляции, чтобы не создавать
длительных блокировок большого числа записей, что может
остановит работу всех других пишущих сессий и заморозить
всю работоспособность системы на уровне времени отклика
системы.
Однако для аналитических отчетов, где
требуется только полный срез актуальной информации для
дальнейшей обработки и уже не важно, в каком дальше
состоянии будет информации БД во время проведения хода
работ, рекомендуется краткосрочно использовать этот
уровень изоляции для перегонки необходимых для отчетов
данных во временные таблицы. Далее уже имея во временных
таблицах данные, можно смело освобождать блокировки и
закрывать транзакцию COMMIT и строить отчет по данным
временным таблиц, которые гарантированно содержат
актуальные на момент среза данные и не могут измениться
никакой другой сессией. Для некоторых серверов других
производителей реализован специальный режим уровня
изоляции SNAPSHOT, позволяющий автоматически делать
срезы данных, без явного описания временных таблиц и
кода их заполнения, вполне возможно, что в 10-ой версии
ASA так же будет поддерживаться этот уровень изоляции
SNAPSHOT, позволяющий читателям не зависеть от
блокировок писателей и снимающий необходимость самому
проектировщику реализовывать данную функциональность
посредством временных таблиц.
Резюме материала
ASA 9
является полноценным сервером баз данных, обеспечивающим
4 уровня транзакций, задекламированных в стандарте SQL.
Данный сервер полностью гарантирует актуальность и
целостность информации на высшем уровне изоляции
SERIALIZABLE. Реализация транзакционного механизма
данного сервера по мнению автора рассылки является
достаточно удачной, очень надежной, легкой в освоении,
гарантированно работающей по заявленной функциональности
без каких либо исключений из правил, что позволяет
проектировщикам баз данных быть твердо уверенными, что
сервер обеспечит именно то поведение, которое они
ожидают при указании нужного уровня изоляции транзакции.
Наличие нелогируемых временных таблиц, оператора
блокировки всей таблицы (LOCK TABLE), событийной модели
(EVENTS), средств мониторинга блокировок, расширенной
поддержки OLAP запросов и прочей функциональности,
позволяют при грамотном подходе в реализации архитектуры
баз данных и написания запросов, использовать данный
сервер баз данных для любых областей применения – от
учетных задач, до крупных биллинговых систем, используя
сервер как в качестве OLTP сервера, так и OLAP для
создания аналитического учета. Грамотный подход при
реализации структуры БД, правильном использовании
уровней изоляции, представление внутренних механизмов
работы сервера на различных уровнях изоляции и способах
блокировок, а так же полное представление и грамотная
реализация бизнес-процессов в базе данных согласно
четкому ТЗ, позволит создать масштабируемое, надежно и
быстро работающее при больших нагрузках, с достаточно
низкими требованиями к аппаратной части решение,
удовлетворяющее нужды заказчиков и легкое в доработке и
сопровождении.
Материалы данной
рассылки являются собственностью ее автора. При
использовании информации из рассылки, ссылка на автора
обязательна.
|
|
Дата публикации: Monday 27 March 2006 16:23:04
Материал прочитан: 16655 раз(а)
[ Назад ] |
|
|
|
|
|
|
