Книга: Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Пакетные добавления

Пакетные добавления

Оператор для пакетных добавлений может выглядеть следующим образом:

INSERT INTO DATATABLE(DATA1, DATA2, DATA3, DATA4, DATA5, . . . другие столбцы)

VALUES ('x', 'у', 'z', 99, '2004-12-25', . . . другие значения);

При использовании параметров он будет выглядеть так:

INSERT INTO DATATABLE(DATA1, DATA2, DATA3, DATA4, DATA5, . . . другие столбцы)

VALUES (?, '?', '?', ?, ?, .... другие значения);

Часто хранимая процедура бывает наиболее элегантным способом выполнения повторяемой пакетной операции, особенно если есть требование преобразования данных по дороге к таблице базы данных или при добавлении строк во множество таблиц.

Два поведения могут привести к огромному объему пакетных операций, резко замедляющих выполнение.

* Использование индексов, которые добавляют задаче работы, а также имеют тенденцию к деформированию геометрии индексных деревьев.

* Накопление предыдущих версий, небольших изменений старых строк, которые отмечаются как устаревшие при подтверждении операций изменения или удаления. Предыдущие версии не будут доступными для сборки мусора, пока не завершится транзакция. В транзакциях, включающих предыдущие версии в количестве десятков или сотен тысяч (или более), сборка мусора никогда не будет победителем в этой битве за очистку базы данных от устаревших версий записей. При этих условиях только резервное копирование и восстановление сможет полностью оздоровить базу данных.

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

ALTER INDEX имя-индекса INACTIVE;

Когда большая пакетная операция закончится, реактивируйте и пересоздайте индексы:

ALTER INDEX имя-индекса ACTIVE;

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

При помещении в базу данных большого количества данных в пакете предпочтительным является разбиение их на группы и подтверждение работы приблизительно через каждые 5000-10 000 строк. Фактический размер оптимального разбиения будет меняться в зависимости от размера строки и размера страниц базы данных. Оптимальные группы могут быть меньше или больше указанного диапазона.

! ! !

СОВЕТ. Когда вам нужно разделять огромные пакеты, часто хранимые процедуры являются способом это сделать. Вы можете использовать локальные переменные-счетчики, сообщения о событиях и возвращать значения для сохранения вызова процедуры с целью синхронизации с вызовами клиента.

. ! .

Оглавление книги