SQLBase 11 представляет новый диспетчер блокировок (Lock Manager) и новый код с поддержкой многоверсионности. Эти возможности значительно увеличивают производительность системы и скорость операций с базами данных (БД).
Данный документ знакомит с этими новыми концепциями, а также предоставляет подробную информацию по изменению приложений с целью максимального использования преимуществ SQLBase 11.
Теория многоверсионности
Многоверсионное управление конкурентным доступом (Multi-version concurrency control, MVCC) представляет собой метод управления конкурентным доступом, который используется системами управления базами данных (СУБД) для предоставления параллельного доступа к объектам БД и повышает производительность в многопользовательской среде.
С точки зрения клиента MVCC предоставляет каждому подключенному пользователю моментальную копию (snapshot) БД. Любые изменения, вносимые одним из пользователей, не будут видны другим пользователям до фиксации транзакции.
СУБД с поддержкой технологии MVCC поддерживают несколько версий объекта, поэтому транзакциям никогда не приходится ожидать блокировки объекта БД. Например, при обновлении элемента БД сохраняется его старая версия. Если транзакция пытается прочитать этот элемент, выбирается соответствующая версия. Таким образом, сохраняется сериализуемость текущих транзакций. Когда транзакция пытается записать элемент, создается новая версия, но старая версия элемента сохраняется.
В своих алгоритмах управления многоверсионностью система SQLBase 11 использует концепцию сериализуемости представления.
Метка времени "начало оператора"
Для достижения сериализуемости системы MVCC используют метки времени.
Как уже обсуждалось выше, СУБД сохраняет версии модифицированных элементов, чтобы использовать их в транзакциях на чтение и запись. Во время операции выбора транзакция может использовать эту версию элемента, и тогда она не столкнется с блокировками. Таким образом, набор данных, который эта транзакция будет "видеть", зависит от метки времени, которая используется уровнем изоляции этой транзакции.
Метка времени "начало оператора" в SQLBase 11 содержит дату и время, когда для выбора был открыт курсор БД. Другими словами, это те дата и время, когда курсор реально начинает сканировать данные. Это означает, что при использовании метки времени "начало оператора", любые нефиксированные данные (либо данные, зафиксированные после того, как курсор начал сканирование), для транзакции будут не видны. Будут видны только те данные, которые были действительно зафиксированы на начало операции выбора.
Краткие сведения об уровнях изоляции до SQLBase 11
Повторяемость чтения (Read Repeatability, RR) - это уровень изоляции по умолчанию. Уровень RR обеспечивает высокий уровень целостности данных ценой параллелизма работы пользователей. Все S-блокировки (т.е. разделяемые блокировки), накладываемые на данные в результате выполнения оператора SELECT, остаются в силе до окончания транзакции. Этот уровень изоляции гарантирует целостность данных на всем протяжении существования транзакции. Идентичные выражения с оператором SELECT вернут идентичные результаты, поскольку другие транзакции не могут изменить данные.
Стабильность курсора (Cursor Stability, CS). Этот уровень обеспечивает среднюю степень целостности данных и среднюю степень параллелизма работы пользователей. При использовании уровня CS S-блокировка сохраняется на текущей странице, которую вы обрабатываете. Т.е. при извлечении строк после выполнения запроса страница текущей строки удерживается S-блокировкой. Вам гарантируется стабильность курсора (под курсором в данном контексте понимается текущая строка набора итоговых данных). При смене страницы по мере извлечения строк S-блокировка на текущей странице освобождается, и устанавливается S-блокировка для следующей страницы.
Снятие блокировок (Release Locks, RL). Этот уровень обеспечивает низкую степень целостности данных и высокую степень параллелизма работы пользователей. Этот уровень изоляции держит блокировки ровно столько, сколько необходимо для считывания данных. Уровень RL устанавливает S-блокировки на данные по мере создания результирующего набора данных. После окончания формирования результирующего набора, когда сервер готов вернуть управление клиенту, все S-блокировки будут сняты. При извлечении строк из результирующего набора S-блокировка быстро устанавливается на страницу строки, чтобы поместить ее в буфер входящих сообщений. В отличие от уровня CS, эта S-блокировка немедленно снимается.
Только чтение (Read Only, RO). Этот уровень обеспечивает высочайшую степень целостности данных и высочайшую степень параллелизма работы пользователей. Уровень RO можно использовать только для запросов (операторы выбора). При использовании уровня RO не допускаются никакие выражения языка манипулирования данными (DML) или языка определения данных (DDL). Для обеспечения уровня RO СУБД SQLBase создает файлы истории модификации данных другими транзакциями. Этот уровень изоляции не использует блокировки и не блокируется ими. Если на страницу, которая содержит нужные для запроса строки, наложена X-блокировка (эксклюзивная), то строка извлекается не из самой БД, а из файла истории.
Новый уровень изоляции: чтение зафиксированных данных
Для улучшения возможностей уровня изоляции RO для операций выборки данных и улучшения возможностей уровня RL для операций вставки и обновления данных система SQLBase 11 претерпела изменения. В этой версии был представлен новый уровень изоляции: чтение зафиксированных данных (Read Committed, RC). Он обеспечивает в СУБД SQLBase поведение, подобное блокировке на уровне строк.
Как это работает? Когда транзакция в SQLBase изменяет страницу, она делает копию этой страницы в кэше. После этого любая транзакция уровня RO или RC может использовать эту копию, не сталкиваясь с блокировками. Для транзакций, которые в основном считывают данные, это значительно повышает параллелизм.
При использовании уровня изоляции RC в момент, когда начинается выполнение оператора выбора, делается моментальная копия данных (см. метку времени "начало оператора" выше). Поэтому любые изменения, внесенные в данные после снятия этой моментальной копии, не будут видны для транзакции, которая запустила выполнение выборки.
В качестве примера выполним следующие два различных сеанса SQLTalk:
Сеанс1
connect db sysadm/sysadm;
set isolation rc;
create table test (col1 int);
commit; prepare select * from test; perform;
<это устанавливает метку времени "начало оператора">
Сеанс2
connect db sysadm/sysadm;
set isolation rc;
insert into test values (1);
commit; select * from test;
<показано значение 1>
Вернемся в Сеанс1 fetch 10; <значение 1 не показывается>
Для решения этой проблемы еще раз выполним оператор perform из Сеанса1, и тогда увидим текущие данные.
На уровне изоляции RC блокировки записи снимаются в конце транзакции.
Заметим, что в отличие от транзакций RO, транзакции RC могут как читать, так и изменять данные. Кроме того, транзакции RO могут "видеть" все данные, которые выбраны на момент начала транзакции. Это отличается от метки времени "начало оператора" в транзакциях RC.
Как и в режиме RO, уровень изоляции RC также создает файл истории для сохранения страниц транзакции фиксированных данных. В этом сценарии можно сказать, что транзакции RC ведут себя подобно уровню RL при обновлениях, и подобно уровню RO - при выборке данных.
Изменения уровня изоляции "только чтение" (RO)
Для поддержки уровней изоляции RC и RO параметр "только чтение" (readonly) для БД в SQLBase должен быть включен.
В прошлом по умолчанию этот параметр был отключен. Благодаря улучшениям в работе транзакций только на чтение в SQLBase 11, параметр "readonly" теперь по умолчанию включен, если это не переопределено в файле sql.ini для всех БД на сервере (readonly=0) либо с помощью команды в SQLTalk SET READ ONLY для текущей БД.
Ниже в таблице показано, как происходит вычисление значения параметра "readonly":
|
Значение в sql.ini | |||
|
Последняя команда SET READONLY |
не установлено |
0 |
1 |
|
DEFAULT |
Включен |
Выключен |
Включен |
|
ON |
Включен |
Включен |
Включен |
|
OFF |
Выключен |
Выключен |
Выключен |
Чтобы выполнить команду SET READONLY OFF или SET READONLY DEFAULT (если по умолчанию значение параметра OFF), запрашивающий курсор не может работать в режиме изоляции RO. Также в БД не должно существовать транзакций в этом режиме.
Другое изменение, относящееся к уровню изоляции RO, заключается в том, что параметр "hisfilesize" теперь устарел. Его по-прежнему можно установить или извлечь, но он не влияет на работу БД. В SQLBase 11 файл истории будет расти или уменьшаться по мере необходимости. Когда последний пользователь отключится от БД, он будет автоматически удален.
Дополнительная информация о параметре "readonly" содержится в руководстве администратора БД SQLBase (SQLBase Database Administrator’s Guide), раздел описаний ключевых слов (Keyword Descriptions).
Несколько подключений с использованием разных уровней изоляции
Для каждого подключения к SQLBase можно иметь один набор курсоров с использованием одного определенного уровня изоляции и другой набор курсоров с другим уровнем изоляции.
Преимуществом такого подхода является то, что приложение, которое интенсивно использует возможности получения отчетов на основе данных (для этого вполне хватит уровня RO) и одновременно нуждается в самой свежей информации, например, о банковских операциях (для этого достаточен уровень RL), может устанавливать несколько соединений с БД. При этом каждое из соединений может использовать один из указанных уровней изоляции.
Поскольку уровень изоляции RC в SQLBase 11 использует преимущества и улучшения уровня только на чтение, Unify рекомендует для всех транзакций использовать уровень RC. Причиной этого является то, что, как сказано выше, уровень чтения фиксированных данных дает наилучшие возможности из обоих "миров": поведение как в RO при выборках и поведение как в RL для вставок и обновлений.
Конечно, перед внесением любых изменений требуется глубокий анализ приложения. Далее в разделе вопросов и ответов приведены проблемы с Team Developer, которые могут возникнуть при использовании нового режима Read Committed в SQLBase 11.
Как транзакция с уровнем чтения только фиксированных данных влияет на другие операции
Одной из опасностей режима чтения только фиксированных данных (RC) является вот что. Если изменение произошло после того, как оператор начал сканировать данные, то различные операции, которые выполняются в пределах одной транзакции, "увидят" разные данные.
Другими словами, моментальная копия данных делается в тот момент, когда начинается выполнение оператора. Если происходит операция выбора, а затем другая операция вставляет строку в таблицу, то курсор не "увидит" модифицированные данные, пока его не перезапустят.
С точки зрения Team Developer команда SqlPrepare() не установит метку времени, а команда SqlExecute() это сделает. Допустим, ваше приложение подготавливает и выполняет операторы выбора, но только сама выборка данных будет выполняться позже. Тогда стоит убедиться, что извлекаемые данные - это именно текущие данные, хранящиеся в БД. Есть несколько способов добиться этого. Они зависят от структуры приложения. Один из способов - это использовать проверку ROWID.
Team Developer и SqlSetIsolationLevel()
В Team Developer (TD) для установки уровней изоляции SQLBase используется интерфейс SQLBase API. Поэтому, чтобы установить изоляцию RC из приложения, разработчики могут продолжать использовать в TD функцию SqlSetIsolationLevel(). Для этого нужно просто передать параметр RC следующим образом:
SqlSetIsolationLevel(hSql,’RC’)
Вопросы и ответы
Этот раздел поможет найти ответы на наиболее часто задаваемые вопросы при миграции приложений с БД, чтобы использовать новые возможности SQLBase 11.
Вопрос (В): При подключении к SQLBase 11 из приложения в Team Developer я получаю ошибку "9283 - Incorrect version of library" ("9283 - неправильная версия библиотеки"). Как это исправить?
Ответ (О): Убедитесь, что в переменной окружения PATH каталог SQLBase 11 указан до каталога с Team Developer.
В: Когда я пытаюсь подключиться к SQLBase 11 из приложения Team Developer, появляется ошибка "10444 - SQL Error 10444, not found in ERROR.SQL file" ("10444 - ошибка SQL 10444, не найдено в файле ER-ROR.SQL").
О: Эта ошибка появляется, если используется неправильная версия SQLBase API. Приложения, которые подключаются к SQLBase 11, должны использовать API также от версии 11. Если в каталоге приложения присутствуют файлы sqlws32.dll и sqlbapw.dll от старой версии SQLBase, то для подключения к БД нужно переименовать их или удалить.
В: Для реализации уровня изоляции RC из приложения Team Developer я использую функцию SqlSetIsolationLevel. При выполнении этой функции я получаю ошибку "227 - Invalid Isolation Level RC" ("227 - неверный уровень изоляции RC"). Почему?
О: Потому что ваше приложение использует более старую версию SQLBase API, не соответствующую SQLBase 11. Убедитесь, что файлы sqlws32.dll и sqlbapw.dll, которыми пользуется приложение, показывают версию 11.0.0.
В: Можно ли установить разные уровни изоляции для разных курсоров в одном подключении?
О: Нет. Разные курсоры в одном подключении должны использовать один уровень изоляции. Например, если вы открыли из Team Developer соединение с SQLBase 11 и установили уровень изоляции RC, то все курсоры в этом подключении также будут использовать уровень изоляции RC.
В: Можно ли использовать несколько подключений к SQLBase 11 с использованием разных уровней изоляции?
О: Да. Например, одно подключение к SQLBase 11 может использовать уровень изоляции RO, а другое - RC.
В: Я пытаюсь из приложения Team Developer установить в SQLBase 11 уровень изоляции RC. После этого я получаю ошибку "258 - Read only mode is disabled for this database" ("258 - для этой БД режим только чтения отключен"). Как это можно исправить?
О: Чтобы использовать в SQLBase 11 новый уровень изоляции RC, необходимо включить режим "readonly" ("только чтение"). По умолчанию при установке SQLBase 11 это так и есть. Однако значение этого параметра могло измениться из-за файла sql.ini для всех БД (readonly=0), либо из-за команд SQLTalk для текущей БД. Убедитесь, что в обоих этих местах режим "readonly" включен.