1. Введение

Motorola, Nokia, MCI, Northern Telecom, Philadelphia Stock Exchange, Bear Stearns, First National Bank of Chicago, the Money Store, the US Army, NASA, Boeing. Все эти компании, независимо от направления бизнеса, имеют одно общее: они выбрали InterBase в качестве ключевого компонента их информационных систем. Borland InterBase одинаково хорошо применяется и для "домашнего" управления ракетными системами, сбора данных для аэрокосмических исследований или хранения и обработки данных биржи. Приложения подобного рода имеют много общих требований: легкость использования и управления, производительность, масштабируемость, переносимость, использование ресурсов и восстановление после сбоя. Borland InterBase разработан именно с целью удовлетворять всем этим требованиям.

Даже если большинство систем не требуют экзотических возможностей, как вышеперчисленные, они все равно желают от РСУБД тех-же характеристик для реальных задач и решения реальных проблем бизнеса. Перечисленные характеристики Borland InterBase также очень хорошо подходят для рабочих групп, отделов, и приложений уровня предприятия. Цель этого документа - продемонстрировать преимущества Borland InterBase в сравнении с SQL-серверами Microsoft SQL Server и Sybase, или дать вам возможность сравнить архитектуры и особенности этих SQL-серверов.

1.1. Замечания

До выпуска Microsoft SQL Server 6.0, Sybase SQL Server и Microsoft SQL Server были одним и тем-же продуктом. Microsoft SQL Server 4 был лицензирован у Sybase и продавался под маркой Microsoft. В 1995 году Microsoft выкупил исходные тексты у Sybase и модифицировал их для того, чтобы выпустить Microsoft SQL Server 6.0. Sybase продолжила разработку своего SQL Server и в настоящее время выпускает его под названием Sybase SQL Server System 10 и System 11. Тем не менее, и Microsoft SQL Server и Sybase SQL Server имеют одно и то-же ядро сервера баз данных. Поэтому в большинстве случаев они ведут себя совершенно одинаково. По этой причине, термин “SQL Server” в этом документе будет относиться и к Microsoft SQL Server и к Sybase SQL Server. Там, где эти продукты отличаются, будут упоминаться их соответствующие полные имена.

1.2. Немного Истории

InterBase был придуман и создан группой сотрудников Digital Equipment Corporation [DEC], желавших воплотить в RDBMS ряд уникальных технологических решений, обеспечивающих большие преимушества по сравнению с существовавшими серверами баз данных. InterBase начался в 1985 году как Groton Database Systems (GDS) и вскоре был переименован в InterBase. Группа была приобретена Ashton Tate в 1991 году. Borland получил InterBase в 1992 году как часть приобретения Ashton Tate.

Как и планировалось разработчиками, InterBase продемонстрировал целый ряд технологических новшеств. Среди них Множественные поколения записей, автоматическое двухфазное подверждение транзакций, зеркалирование базы данных, большие двоичные объекты [BLObs], битовые индексы, многмерные массивы и уведомления о событиях.

Боьшинство существующих RDBMS не смогли воспроизвести или создать эквивалентные технологии. Например, архитектура SQL Server использует комбинацию страничных, индексных и табличных блокировок для обеспечения конкурентного доступа к данным. SQL Server также поддерживает двухфазное подтверждение транзакций, однако требует большого количества кода для реализации подтверждения или отката. SQL Server обеспечивает хранение данных типа BLOb, но в более ограниченном и менее быстродействующем варианте чем это реализовано в InterBase.

2. Механизмы Блокировок

2.1. Background

Целостность данных - самое важное качество для корпоративных данных. Существует много способов для обеспечения целостности данных в RDBMS. Наиболее распространены пессимистическая и оптимистическая схемы блокировок. Пессимистические блокировки - простейший в реализации способ, когда блокируются страницы, индексы или таблицы для обеспечения целостности транзакции. Оптимистические блокировки предполагают отсутствие блокировок для клиентского приложения. При этом используются более сложные механизмы для обеспечения целостности транзакции. Оптимистические блокировки, обеспечивая целостность данных, обладают оптимальной производительностью и легкостью в использовании.

2.2. SQL Server

2.2.1. Страничные Блокировки

Для того, чтобы гарантировать целостность данных, архитектура SQL Server использует механизм блокировок страниц данных. Страница данных это набор записей, хранимых в некоторой области жесткого диска на сервере. Все страницы имеют один и тот-же размер, который определяется конфигурацией сервера и базы данных. В зависимости от длины записей и размера страницы, страница может содержать определенное количество записей. Записи в большинстве случаев добавляются в конец таблицы. Базовый размер страницы в SQL Server равен 2K, и это является минимальной единицей блокировкиl. Страничные блокировки требуют от разработчика глубоких знаний о конкурентной работе с данными и настройке кода для получения максимально конкурентного доступа. Страничная блокировка блокирует все записи или соответствующие ссылки в индексах, хранимые на одной странице. Например, если размер записи в таблице равен 100 байт, а размер ключа индекса равен 10 байт, то блокировка одной страницы данных и одной страницы индекса приведет к куммулятивному эффекту блокирования 18-ти записей и 180-ти ключей индекса.

Figure 1 SQL Server Page Locks

Когда происходит запись в таблицу, то для обеспечения целостности записи RDBMS блокирует страницу, на которой находится эта запись. Блокирование целой страницы намного быстрее блокирования отдельной записи, и требует намного меньше ресурсов сервера для управления блокировками. Вместе с тем, блокирование целой страницы, приводит к блокированию других пользователей от изменения данных на этой-же странице. В дополнение к блокированию страницы, на которой находится интересующая запись, SQL Server дополнительно блокирует предыдущу и следующую страницу (относительно блокируемой). Доступ к записям на блокированных страницах будет невозможен в течение действия блокировки. Блокирование может возникнуть во многих ситуациях. Наиболее частая причина блокировки - добавление записи или ее модификация. Кроме этого, использование курсоров клиентским приложением может также производить большое количество блокировок страниц. В таких ситуациях пользователь, всего-лишь просматривающий записи, блокирует других пользователей от внесения изменений на эти-же страницы до тех пор, пока не закроется курсор либо блокировка не переместится на другие страницы.

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

2.2.2. Блокировки Индексов

Индексы SQL Server блокируются точно так-же, как и страницы данных соответствующих таблиц, однако эффект блокировки страницы индекса значительно шире. Записи в таблице хранятся в большинстве случаев в случайном порядке (исключение составляют кластерные индексы). Когда обновляется страница данных, то должен обновиться соответствующий индекс. Как и у таблиц, данные индексов хранятся на страницах. Для обновления страницы индекса, эта страница должна быть сначала заблокирована. Если данные в таблице распределены случайным образом, то блокировка страницы индекса приведет к блокировке большого количества страниц данных, поскольку страница индекса ссылается на большое количество страниц данных. Это значит что модификация одного ключевого значения на странице может заблокировать множество совершенно посторонних записей на страницах данных. Если для таблицы определено несколько индексов, то изменение одной записи приведет к лавинообразному росту блокировок страниц, не относящихся к странице где находится модифицируемая запись. В приложениях, работающих с большими объемами данных, это может сильно снизить производительность системы.

2.2.3. Блокировки Таблиц

Целостностное представление базы данных иногда требует уровня изоляции "воспроизводимое чтение". "Воспроизводимое чтение" гарантирует неизменность видимых данных на время действия транзакции. Это очень важно в финансовых приложениях или при создании отчетов по большим объемам данных в то время как другие пользователи модифицируют записи. Для обеспечения целостного представления данных  в Sybase или Microsoft SQL Server разработчик должен использовать блокировки таблиц. Блокировка таблицы вызывает полную блокировку, разделяемую, для обновления или исключительную [Shared, Update, or Exclusive]. Представьте себе свод баланса бухгалтером -  пока свод не закончен, архитектура SQL Server требует чтобы разработчик полностью заблокировал таблицу на время свода. Кроме этого может потребоваться полное блокирование связанных таблиц. Более подробно эта тема обсуждается в секции 6.3.

2.2.4. Эскалация страничных блокировок в Блокировки Таблиц

Длинные транзакции, затрагивающие большое количество записей, требуют большого количества страничных блокировок. Как только количество страничных блокировок достигает определенного предела, SQL Server автоматически включает полную блокировку таблицы. Назначение такого механизма в том, чтобы уменьшить работу RDBMS по управлению блокировками и обеспечению конкурентного использования данных, и чтобы предотвратить деградацию производительности. Естественно, что полная блокировка таблицы заблокирует другим пользователям доступ к этой таблицы. Эскалация может произойти как при обновлениях, так и при обычной выборке данных. Для того, чтобы обеспечить оптимальную производительность при многопользовательском доступе, администратор БД должен тщательно проанализировать структуры БД и алгоритмы клиентских приложений на пересекающиеся запросы по чтению и обновлению данных. После этого администратор должен определить уровень эскалации табличных блокировок чтобы сбалансировать управление большим количеством блокировок страниц и блокировку доступа при эскалации табличных блокировок. Разработчики приложений также должны понимать особенности страничных и табличных блокировок, и соответственно программировать обработку доступа при блокировках. Такие требования добавляют к приложениям дополнительную сложность кода, увеличивая стоимость разработки и сопровождения.

2.2.5. Варианты решения проблем

Для того, чтобы обрабатывать множество ограничений механизма блокировок SQL Server, разработчики должны использовать  множество решений для оптимизации баланса между конкурентным доступом и производительностью:

• Использовать администратора БД, хорошо знакомого с SQL Server, для проведения анализа клиентских приложений, статистики базы данных и структур данных, чтобы установить оптимальное значение уровня эскалации табличных блокировок.
• Буферизировать данные локально (например использовать Cached Updates в BDE 3.x) для сокращения времени транзакции до минимума. В любом случае необходимо специально программировать обработку ситуаций, когда разные пользователи пытаются обновить одни и те-же записи.
• Использовать репликацию данных, над которыми может произоводиться длительная обработка (сложные отчеты). К сожалению, репликация в SQL Server является односторонней. Это ограничение часто делает невозможным использование репликации для более сложных задач. В Sybase, репликация производится при помощи отдельного продукта, называемого “Replication Server”.
• Использовать временные таблицы для пакетных обновлений данных. Это может вызвать другие проблемы, поскольку пользователи могут параллельно такому обновлению модифицировать данные в других таблицах, и данные во временной таблице станут неактуальными.
• Использовать HOLDLOCK для установления блокировки SHARE на выбранные элементы данных, чтобы предотвратить обновление этих данных другими пользователями. При большом количестве пользователей, возможно что другие пользователи будут пытаться обновить одни и те-же страницы данных или индексов. Множественные блокировки SHARE могут быть применены к одним и тем-же элементам чтобы блокировать обновления. При таком сценарии, другой пользователь получит deadlock и один из двух пользователей должен быть отключен для прекращения ситуации deadlock. Использование монопольных блокировок предотвратит deadlock, но и сделает невозможным просмотр заблокированных данных другими пользователями. Ненормальное завершение приложения может оставить неразрешенные блокировки до тех пор, пока сервер определит что связь с приложением оборвалась.

2.2.6. Операция Вставки в Microsoft SQL Server

В Microsoft SQL Server 6.5 механизм блокировок улучшен по сравнению с версией 6.0 и Sybase SQL Server поддержкой блокировок на уровне записей при вставке. Это увеличивает производительность вставки записей, но никак не решает другие проблемы со страничными, индексными или табличными блокировками. Поэтому, независимо от версии, обновление данных в архитектуре SQL Server все-равно требует табличных или страничных блокировок для обеспечения целостности данных.

2.3. InterBase

2.3.1. Архитектура Многоверсионности Записей

InterBase обеспечивает оптимистические блокировки при помощи Архитектуры Многоверсионности Записей (Multi-Generational Architecture- [MGA]). Этот механизм создает оптимизированные версии для новых, удаленных или обновляемых записей, которые видны только в контексте конкретной транзакции, изменяющей данные. Реально, InterBase версионирует только изменяемые столбцы (поля) путем создания deltas. Это обеспечивает максимальную производительность и минимальные требования к дисковому пространству.

Состояние "невидимости" версионированных записей длится только в течение транзакции. После подтверждения (committing) транзакции, измененные записи становятся видимы транзакциям, стартовавшим до завершения этой транзакции (Д.К. - только если эти транзакции ReadCommitted или стартовали после завершения транзакции, менявшей данные. Для транзакций RepeatableRead, стартовавших до завершения такой транзакции, изменения  записей не видны). Вообще, все другие транзакции имеют свое собственное представление изменяемых записей, пока они (транзакции) не закончатся подтверждением или отменой. Как только транзакции, читавшие или обновлявшие записи, завершились, InterBase освобождает старые версии записей. Когда две транзакции пытаются обновить одну и ту-же запись, транзакция, первой сделавшая обновление является "владельцем", и вторая транзакция получит сообщение об ошибке. Разработчики приложений как для SQL Server так и для InterBase одинаково могут управлять такими ситуациями. В любом случае, приложение для  SQL Server должно сначала перечитать запись чтобы убедиться что она не изменена. В зависимости от средств разработки приложений, разработчику, использующему SQL Server, может потребоваться написать дополнительный код для такой операции. Вместо того, чтобы писать код обработки страничных, индексных и табличных блокировок, разработчик при использовании InterBase должен обрабатывать только конфликты обновления с другими транзакциями. Это означает значительно меньшие затраты при разработке и сопровождении для корпораций, использующих InterBase.
(Д.К.- на самом деле механизм многоверсионности значительно сложнее. Например, блокировки в терминах MS SQL, Sybase, Oracle даже на уровне записей в InterBase отсутствуют. 

2.4. Производительность

Результаты тестов на производительность в основном зависят от механизмов блокировок, используемых в тестируемой СУБД. Страничные и табличные блокировки SQL серверов Microsoft и Sybase могут сильно влиять на производительность, когда многим пользователям требуется доступ к одним и тем-же данным (или находящимся на близлежащих страницах). Например, в реальных ситуациях, страничные блокировки в SQL Server могут замедлять доступ к данным (ожидание освобождения блокировок страниц, индексов или таблиц). Этот эффект может быть заметен в системах с большим объемом данных или когда пользователи выполняют создание длительных отчетов по данным в тот момент, когда другие пользователи модифицируют данные. Архитектура Многоверсионности Записей InterBase гарантирует доступность данных на чтение для любых пользователей и в любое время. Клиентское приложение никогда не ждет доступности таблиц, записей или индексов, независимо от числа пользователей в системе или длительности и сложности какой-либо транзакции. Разработчики, использующие InterBase, автоматически получают максимум производительности приложений, безотносительно сложности обработки данных.

3. Двухфазное Подтверждение Транзакций

3.1. Background

Слово "транзакция" произошло от слияния слов "акция трансформации". Транзакция это действие или группа действий, которые переводят систему из одного целостного состояния в другое. Например, при переводе денег с одного счета на другой, должна быть изменена сумма либо обоих счетов, либо ни одного в случае ошибки.

Транзакци характеризуются свойствами ACID:

Atomicity (атомарность) - "все или ничего". Либо вся транзакция завершается, либо ни одна из ее частей. Если транзакция не может быть завершена, то все операции, произведенные внутри транзакции, отменяются.

Consistency (целостность) - Транзакция должна переводить базу данных из одного целостного состояния в другое. Целостность определяется бизнес-правилами (логикой базы данных) и вводится в действие приложением.

Isolation (изоляция, изолированность) - Поскольку может возникать множество конкурентных транзакций, каждая транзакция должна быть изолирована от действий, производимых другими транзакциями. Т.е. транзакции должно "казаться", что она является единственной, выполняемой над базой данных.

Durability (прочность)- Изменения, подтвержденные транзакцией, обязаны вступить в силу.

Если использовать в качестве примера оплату по кредитной карте, то все ACID-свойства должны иметь место. Представим что информация кредитной карты хранится в одной БД, а информация о счете клиента - в другой. В этом случае при изменении количества денег на кредитной карте соответственно должен измениться счет клиента, и выполняться это должно в одной транзакции. Такие ситуации обрабатываются при помощи двухфазного подтверждения транзакций (Two Phase Commit - 2PC). Это механизм, который применяет к  изменениям в обоих базах данных свойства ACID.Двухфазное подтверждение транзакций имеет две отдельные фазы: подготовка и подтверждение. Если по какой-то причине процесс не может быть выполнен в течение фазы подготовки, например после снятия денег с кредитной карты но до изменения суммы счета клиента, то транзакция должна быть отменена (rollback). Это гарантирует что на счету не останется денег больше, чем на кредитной карте (или наоборот). Пока обе базы данных не будут изменены правильным образом, любые действия над БД должны оставаться неподтвержденными. Если все порции транзакции выполнились успешно, то подтверждение производится над двумя БД. Это называется двухфазным подтверждением транзакций.

3.2. Microsoft SQL Server

Архитектура SQL Server позволяет программировать 2PC используя Координатор Распределенных Транзакций (Microsoft Distributed Transaction Coordinator [MSDTC]). MSDTC требует чтобы разработчик создавал объекты транзакций используя OLE. Если меняется приложение, то код 2PC должен быть повторно протестирован и сопровождаться все время жизни приложения. При этом сопровождаться должны не только клиентское приложение и база данных, но и объекты MSDTC также должны сопровождаться и координироваться с остальными частями системы. Это ухудшает переносимость, и требует дополнительных затрат на разработку и сопровождение. .

3.3. Sybase SQL Server

В Sybase SQL Server, разработчики должны использовать 2PC для обеспечения целостности транзакций, производимых над разными БД. В двадцатитомной документации на  Sybase System 10 есть только одно упоминание 2PC. Конечно, на WEB-сервере Sybase есть некоторое количество документов, поясняющее как обработку 2PC можно писать на C , FORTRAN , Pascal и COBOL . Каждый из этих примеров содержит более чем 100 строк кода. В результате разработчикам приходится создавать сложные внешние процедуры, недокументированные  Sybase, и использовать другие языки программирования вместо использования естественных возможностей RDBMS. Переход на другую платформу может потребовать перекомпиляцию или переписывание кода. Как и в случае Microsoft SQL Server, необходимо сопровождать и синхронизировать внешние (по отношению к БД) объекты, что увеличивает стоимость разработки и усложняет сопровождение. Ситуация может еще больше осложниться, если используются серверы Sybase для разных платформ.

3.4. InterBase

InterBase обеспечивает автоматическую обработку 2PC в соответствии со всеми требованиями ACID без дополнительного программирования на любых платформах (Windows NT, DEC UNIX, HP-UX, Irix и т.д.). Это обеспечивает максимум легкости сопровождения при отсутствии дополнительных затрат.

4. CHAR и VARCHAR

4.1. Хранение

4.1.1. SQL Server

4.1.1.1. CHAR или VARCHAR

Практически во всех SQL-серверах реализовано два главных типа данных для хранения символьной информации. Первый - фиксированной длины, и известный как CHAR. В большинстве РСУБД CHAR занимает пространство фиксированной длины независимо от длины действительно хранимых данных. Свободное пространство поля типа CHAR "дополняется" до объявленной длины пробелами. Тип CHAR полезен если длина хранимых данных практически не меняется, например как для кодов стран и штатов США. CHAR может быть использован и для хранения имен или адресов, но это приведет к большим потерям дискового пространства.

VARCHAR хранит символьные данные с переменной длиной. Это значит что на диске распределяется пространства столько-же, сколько нужно для хранения символьных данных. Максимальная длина поля типа VARCHAR указывается при создании таблицы. Когда значение типа VARCHAR записывается на диск, РСУБД определяет его фактическую длину, и отводит под его хранение столько-же байт на диске. VARCHAR обеспечивает эффективное использование дискового пространства при хранении символьных данных, когда длина значения символьного поля варьируется в больших пределах.

4.1.1.2. Ограничения Длины

Длина типа VARCHAR в SQL Server ограничена 255 байтами. Если требуется хранение строк длиной более 255 символов, то необходимо использовать тип поля TEXT. Данные в поле типа TEXT хранятся как данные BLOb с размером сегмента 2K (минимальный размер страницы). Другими словами, даже если данные в поле TEXT занимают один байт или 1500 байт, SQL Server распределяет блок размером 2K для хранения значения поля. SQL Server жертвует дисковым пространством с целью обеспечения производительности при работе с полями  BLOb. Разработчик должен тщательно планировать структуру базы данных для баланса между занимаемым дисковым пространством и производительностью, и иногда идти на компромисс, используя комбинацию из двух или более VARCHAR для хранения строковых данных, которые превышают 255 символов но гарантированно меньше 2К. Соответственно и приложение должно извлекать данные из таких полей и группировать их в одно поле для нормального представления данных..

4.1.2. InterBase

4.1.2.1. CHAR или VARCHAR

Как и семейство СУБД SQL Server, InterBase поддерживает типы как CHAR так и VARCHAR. С точки зрения клиентского приложения они выглядят так-же, как и в SQL Server. Это обеспечивает совместимость приложений. Внутри, InterBase обеспечивает хранение этих типов данных иначе, чем SQL Server. В InterBase, данные CHAR и VARCHAR хранятся одинаково - концевые пробелы обрезаются, и только строка фактической длины хранится в базе данных. В случае VARCHAR, когда данные запрашиваются с сервера, клиентскому приложению возвращается значение переменной длины. В случае CHAR, InterBase дополняет строку пробелами до длины, указанной в структуре таблицы, и возвращает данные как строку с фиксированной длиной. Кроме этого, InterBase использует алгоритм сжатия (RLE) для экономии места, занимаемого данными на диске, как для типа CHAR так и для VARCHAR.

4.1.2.2. VARCHAR

Максимальная длина поля типа VARCHAR в InterBase равна 32K (такое-же ограничение длины имеет и CHAR).Разработчик может использовать всю выгоду от VARCHAR без ограничения в 255 символов. Такая возможность имеет большое значение для разработчиков, которые хотят производить поиск или манипулировать большими потоками текста, такими как поля MEMO, без необходимости использовать поля BLOb и их ограничений [в реализации Sybase и Microsoft]. Если размер данных MEMO может превысить 32K, то только InterBase позволяет эффективно использовать тип BLOb с определяемым размером сегмента. Кроме этого, операции поиска LIKE, CONTAINING и STARTING WITH можно применять к CHAR, VARCHAR и BLOB-полям любого типа.

4.2. Производительность

4.2.1. SQL Server

При всей очевидности гибкости и эффективности хранения символьных данных в полях типа VARCHAR может показаться, что это наилучший выбор для хранения символьных данных. Напротив, использование VARCHAR в SQL Server приводит к ухудшению производительности из-за дополнительных затрат на извлечение данных. Поэтому разработчики должны выбирать между эффективным хранением и эффективным извлечением данных.

4.2.2. InterBase

И наоборот, поскольку способ хранения CHAR и VARCHAR в InterBase идентичен, разработчик никогда не заботится о выборе типа данных с учетом производительности. Вместо этого разработчик может основать свой выбор на том, как представляется соответствующий тип данных в клиентском приложении. Разработчик также может не беспокоиться об оптимальном хранении данных и о затратах дискового пространства, поскольку InterBase использует алгоритмы сжатия строковых данных.

4.3. Модификация CHAR и VARCHAR "на месте"

4.3.1. SQL Server

Пространство, распределяемое для индивидуальных значений VARCHAR, определяется при первом сохранении записи на диск. Любые произвольные модификации значений VARCHAR могут потребовать другого пространства для хранения данных. Изменение размера данных приводят к тому, что SQL Server перераспределяет пространство для данных на основе их новой длины. Например, если пользователь обновляет список поставщиков, и модифицирует адрес с “6475 Christie Avenue” на “100 Borland Way”, то SQL Server должен удалить запись целиком и добавить ее в таблицу чтобы произвести обновление данных.
Существует несколько замечаний, относящихся к этому процессу:

1. Transaction Log: Каждое удаление или вставка приводит к регистрации этого действия в Transaction Log. Периодически администратор БД должен очищать записи в Transaction Log. Неправильно или нерегулярно обслуживаемые transaction logs могут переполниться и вызвать "падение" SQL Server. Для небольших организаций, без специально выделенного администратора БД, это может стать катастрофой.
2. Длинные транзакции: Длинные транзакции, обновляющие большое количество значений полей VARCHAR могут блокировать последние страницы данных таблицы на длительный период времени. Транзакция, обновляющая поле типа VARCHAR у каждой записи таблицы приведет к тому, то все записи будут удаляться из таблицы и добавляться в ее конец. Это может привести к росту  transaction log большему, чем рост данных в базе данных.
3. Свободное пространство: Пространство, занимаемое удаленными записями остается незаполненным, пока над базой данных не будут произведены процедуры по ее сопровождению. В результате таблица может занимать пространство более чем вдвое превышающее реальный объем данных плюс размер transaction log, который вырос в результате регистрации удаления старых записей и добавления обновленных.
4. Неуспешные транзакции: Добавление обновленной записи перемещает изменяемую запись в конец таблицы. Это действие блокирует последние страницы таблицы пока не завершится транзакция. Другие пользователи, создающие новые записи, или редактирующие записи с полями VARCHAR, могут также делать попытки записи в конец таблицы. В архитектуре SQL Server, существует много ситуаций, когда "читатели" блокируют "писателей". Поэтому, другие пользователи могут заблокировать обновление записей с полями VARCHAR из-за блокировок последних страниц таблицы, вызывая неуспешное выполнение транзакции.
5. Производительность: Блокировка дополнительных страниц ухудшит пропускную способность БД, заставляя пользователей ожидать окончания блокировок страниц. При большом количестве записей, содержащих поля VARCHAR, производительность может существенно упасть.

4.3.2. InterBase

InterBase перераспределяет пространство для хранения VARCHAR "на лету". Это означает что процесс "удаление-добавление", используемый в  архитектуре SQL Server, не возникает в InterBase. Вместо этого на странице данных добавляется версия значения CHAR или VARCHAR (delta), а модифицируемая запись остается на своем месте и не модифицируется. Результатом такого механизма является максимальная производительность при обновлениях CHAR и VARCHAR. Кроме этого, в InterBase отсутствует transaction log (благодаря многоверсионности записей), что не только повышает производительность, но и избавляет администратора БД от дополнительной работы. Никаких других блокировок, кроме блокировки обновленной записи от обновления ее другими пользователями, не возникает.