Сравнение Borland InterBase 4.x, Sybase SQL Server и Microsoft SQL Server

ОГЛАВЛЕНИЕ

 

7.2.2. Регистрация транзакций (Transaction Logs)

7.2.2.1. SQL Server

Ttransaction log - системная таблица, в которую записываются все последовательные модификации каждого объекта БД. Он также хранит информацию, необходимую для обеспечения целостности данных при модификации данных. Пространство, необходимое для регистрации транзакций трудно предсказуемо. Представьте себе, что log должен содержать информацию по каждой обновленной записи плюс изменения индексов. Также, представьте что у таблицы много индексов. Объем transaction log зависит от длины записи. Для коротких записей отношение размера log к размеру данных может достигать 10:1. Для длинных записей это отношение меньше. Операции пакетной "заливки" данных или удаления также могут потребовать большого размера transaction log. Как уже указывалось выше, при модификации записей с полями VARCHAR требуется еще больший размер transaction log, т.к. регистрируется не одна операция модификации, а две - удаления и вставки.

Если расписание архивирования БД включает смесь полного (full) и частичного (incremental) архивирования, то это тоже нужно учитывать при определении размера transaction log. Причина в том, что incremental backup - это механизм, используемый в SQL Server для очистки transaction log. Большое влияние оказывают также и длительные транзакции, особенно если они обновляют большое количество записей - в этом случае размер transaction log должен быть установлен в 200% от размера хранимых данных.

Размещение transaction log также критично - если он переполнится, и не оставит свободного места на диске, все операции с БД будут прекращены (буквально произойдет crash). Поэтому размещать БД и transaction log желательно на разных устройства.

7.2.2.2. InterBase

Borland InterBase не использует transaction log для хранения информации о транзакциях и изменениях, которые они производят. Вместо этого используются Transaction Inventory Pages [TIP]. На этих страницах хранится информация о состоянии любой транзакции: активная, подтвержденная, отмененная или подоготовленная (для двухфазного потдтверждения транзакций (2PC).  В случае системного сбоя, как только сервер будет запущен, будут автоматически просканированы TIP с целью поиска неподтвержденных транзакций. Все записи, найденные в неподтвержденном состоянии, будут отменены. Этот процесс практически для БД любого размера происходит в течение нескольких секунд. (Д.К. действительно несколько секунд, потому что отмененные записи при этом не удаляются - отмененные версии записей будут собраны как мусор только тогда, когда какой-нибудь пользователь не обратится к этим данным (кооперативная сборка мусора).

Поскольку transaction log отсутствует, то нет нужды заботиться о его размере. Даже если в вашей БД часто выполняются длительные транзакции, создающие много версий записей, то автоматические увеличение БД будет незначительным - версии записей создаются не как полная копия записи, а как "разница" (delta) между старой версией и новой, размещаются версии на тех-же страницах данных. Кроме того, как только версии становятся ненужными, занимаемое ими пространство автоматически станоится доступным для новых данных.