|
Страница 12 из 25
4.3. Модификация CHAR и VARCHAR "на месте" 4.3.1. SQL Server Пространство, распределяемое для индивидуальных значений VARCHAR, определяется при первом сохранении записи на диск. Любые произвольные модификации значений VARCHAR могут потребовать другого пространства для хранения данных. Изменение размера данных приводят к тому, что SQL Server перераспределяет пространство для данных на основе их новой длины. Например, если пользователь обновляет список поставщиков, и модифицирует адрес с “6475 Christie Avenue” на “100 Borland Way”, то SQL Server должен удалить запись целиком и добавить ее в таблицу чтобы произвести обновление данных.
Существует несколько замечаний, относящихся к этому процессу: - Transaction Log: Каждое удаление или вставка приводит к регистрации этого действия в Transaction Log. Периодически администратор БД должен очищать записи в Transaction Log. Неправильно или нерегулярно обслуживаемые transaction logs могут переполниться и вызвать "падение" SQL Server. Для небольших организаций, без специально выделенного администратора БД, это может стать катастрофой.
- Длинные транзакции: Длинные транзакции, обновляющие большое количество значений полей VARCHAR могут блокировать последние страницы данных таблицы на длительный период времени. Транзакция, обновляющая поле типа VARCHAR у каждой записи таблицы приведет к тому, то все записи будут удаляться из таблицы и добавляться в ее конец. Это может привести к росту transaction log большему, чем рост данных в базе данных.
- Свободное пространство: Пространство, занимаемое удаленными записями остается незаполненным, пока над базой данных не будут произведены процедуры по ее сопровождению. В результате таблица может занимать пространство более чем вдвое превышающее реальный объем данных плюс размер transaction log, который вырос в результате регистрации удаления старых записей и добавления обновленных.
- Неуспешные транзакции: Добавление обновленной записи перемещает изменяемую запись в конец таблицы. Это действие блокирует последние страницы таблицы пока не завершится транзакция. Другие пользователи, создающие новые записи, или редактирующие записи с полями VARCHAR, могут также делать попытки записи в конец таблицы. В архитектуре SQL Server, существует много ситуаций, когда "читатели" блокируют "писателей". Поэтому, другие пользователи могут заблокировать обновление записей с полями VARCHAR из-за блокировок последних страниц таблицы, вызывая неуспешное выполнение транзакции.
- Производительность: Блокировка дополнительных страниц ухудшит пропускную способность БД, заставляя пользователей ожидать окончания блокировок страниц. При большом количестве записей, содержащих поля VARCHAR, производительность может существенно упасть.
4.3.2. InterBase InterBase перераспределяет пространство для хранения VARCHAR "на лету". Это означает что процесс "удаление-добавление", используемый в архитектуре SQL Server, не возникает в InterBase. Вместо этого на странице данных добавляется версия значения CHAR или VARCHAR (delta), а модифицируемая запись остается на своем месте и не модифицируется. Результатом такого механизма является максимальная производительность при обновлениях CHAR и VARCHAR. Кроме этого, в InterBase отсутствует transaction log (благодаря многоверсионности записей), что не только повышает производительность, но и избавляет администратора БД от дополнительной работы. Никаких других блокировок, кроме блокировки обновленной записи от обновления ее другими пользователями, не возникает. |