Версионность в Yukon Иван Бодягин Введение
    Очередную версию СУБД Microsoft SQL Server, являющейся одним из лидеров рынка, ждали довольно долго и, похоже, не зря. В этом продукте только список нововведений будет достаточно увесистым, а уж полное описание новых возможностей потянет на целую книгу. На данный момент доступна лишь альфа-версия продукта, а релиз ожидается примерно через год, но, тем не менее, уже по этой версии можно понять, что нас ожидает в будущем. В данной статье описывается только одно, но достаточно серьезное нововведение, а именно поддержка версионности. Эту функциональность попытались встроить в классический блокирующий сервер (далее - блокировочник), и очень интересно посмотреть, что же из этого получилось. Общие принципы
    Параллельное выполнение транзакций способно привести базу в несогласованное состояние даже в тех случаях, когда каждая транзакция, выполняющаяся отдельно от других, производит полностью корректные изменения. Поэтому очередность операций различных транзакций должна тем или иным образом регулироваться.
    Во всех предыдущих версиях Microsoft SQL Server механизм подобной регулировки был основан на блокировках. Однако в новой версии (кодовое название Yukon) будет введена поддержка другого механизма, основанного на контроле версий (multiversioning). В дальнейшем два этих подхода я буду называть версионным и блокировочным соответственно.
    Версионность сама по себе, не является новым словом в способах обеспечения корректности параллельной обработки транзакций, теоретические работы были еще в начале восьмидесятых, да и появление первых коммерческих реализаций относится примерно к тому же времени. Однако до последнего момента разработчики Microsoft SQL Server последовательно совершенствовали блокировочный механизм, получив в итоге одну из самых удачных реализаций классического блокировочника в индустрии, а вот теперь, похоже, дошли руки и до версионности. Привлекательность данного механизма заключается в том, что читающие запросы никак не мешают пишущим, и наоборот. Но ничто не дается даром. Впрочем, обо всем по порядку.
    От механизма параллельной обработки транзакций формальная теория требует одного: чтобы конечный эффект от параллельного выполнения был таким, как будто бы транзакции выполнялись последовательно, при этом порядок их следования фактически не важен. При соблюдении этого условия, если все транзакции сами по себе корректны, то и их параллельное выполнение целостность базы никоим образом не нарушит. Данное условие носит название "критерия упорядоченности".
    Способов соблюдения вышеупомянутого критерия существует достаточно много. Помимо уже упоминавшихся механизмов, основанных на блокировках и хранении версий, существует еще чуть ли не десяток других. Более того, существует и формальное доказательство того, что этому критерию можно следовать, используя и комбинированные подходы, применяя разные механизмы для разных типов запросов. Опять-таки известны и весьма успешные практические реализации подобных гибридов. Уровни изоляции
    Критерий упорядоченности всем хорош, кроме одного - строгое следование ему слишком дорого обходится с точки зрения производительности. Но, поскольку данный критерий является достаточным, но не необходимым условием корректности параллельной обработки транзакций, то в зависимости от характера транзакций можно повысить степень их вмешательства в работу друг друга без печальных последствий. ............