1. Синтаксис

vacuum-stmt: hide

2. Описание

Команда VACUUM восстанавливает файл базы данных, повторно упаковывая его в минимальную сумму дискового пространства. Есть несколько причин, по которым приложение могло бы сделать это:

• Если SQLite не запущен в режиме "auto_vacuum=FULL", когда большой объем данных удален из файла базы данных, это оставляет пустое место или "свободные" страницы базы данных. Это означает, что файл базы данных мог бы быть больше, чем строго необходимо. Управление VACUUM, чтобы восстановить базу данных исправляет эту проблему и уменьшает размер файла базы данных.

• Частые вставки, обновления и удаления могут заставить файл базы данных становиться фрагментированным, где данные для единственной таблицы или индекса рассеяны по файлу базы данных. Управление VACUUM гарантирует, что каждая таблица и индекс в основном сохранены рядом в файле базы данных. В некоторых случаях VACUUM может также сократить количество частично заполненных страниц в базе данных, уменьшив размер файла базы данных далее.

• Когда содержание удалено из базы данных SQLite, содержание обычно не стирается, а пространство, использованное, чтобы хранить содержание, отмечено как доступное для повторного использования. Это может позволить удаленному содержанию быть восстановленным хакером или судебным анализом. Управление VACUUM очистит базу данных от всех следов удаленного содержания, таким образом препятствуя тому, чтобы противник возвратил удаленное содержание. Использование VACUUM таким образом это альтернатива PRAGMA secure_delete=ON .

• Обычно page_size базы данных и должна ли БД поддерживать auto_vacuum настраивается перед тем, как файл базы данных на самом деле создается. Однако, если не в режиме журнала с упреждающей записью page_size и/или auto_vacuum существующей базы данных могут быть изменены при помощи page_size и/или pragma auto_vacuum, а затем немедленно вакуумируя БД. В режиме журнала с упреждающей записью можно так менять только auto_vacuum.

По умолчанию VACUUM воздействует на главную базу данных. Приложенные базы данных могут пропылесоситься, приложив соответствующее schema-name.

Предупреждение совместимости: способность пропылесосить приложенные базы данных была добавлена в version 3.15.0 (2016-10-14). Раньше schema-name было бы тихо проигнорировано, обрабатывалась только схема "main".

2.1. VACUUM с INTO

Если есть INTO, то оригинальный файл базы данных неизменен, и новая база данных создается в файле, названном аргументом пункта INTO. Аргумент это скалярное выражение, такое как буквальный текст. Новая база данных будет содержать то же самое логическое содержание как оригинальная база данных, полностью вакуумированная.

VACUUM с INTO это альтернатива backup API для создания резервных копий живой базы данных. Преимущество использования VACUUM INTO в том, что получающаяся резервная база данных минимальна в размере и следовательно сумма I/O файловой системы может быть уменьшена. Кроме того, все удаленное содержание очищено от резервной копии, не оставив издержек. С другой стороны, backup API использует меньше циклов CPU и может быть выполнен с приращением.

Имя файла в пункте INTO может быть произвольным SQL-выражением, которое оценивается к последовательности. Файл, названный пунктом INTO, не должен существовать или это должен быть пустой файл, иначе VACUUM INTO прервется с ошибкой.

Аргументом INTO может быть URI filename, если включены URI filename. URL filename доступны если какое-либо следующее утверждение верно:

• Библиотека SQLite была собрана с -DSQLITE_USE_URI=1.
• sqlite3_config( SQLITE_CONFIG_URI,1) был вызван во время запуска.
• Соединение с базой данных, которое управляет VACUUM INTO, было первоначально открыто, используя флаг SQLITE_OPEN_URI.

VACUUM INTO транзакционная в том смысле, что произведенная выходная база данных это последовательный образ оригинальной базы данных. Однако, если VACUUM INTO прервана незапланированным закрытием, то произведенная выходная база данных могла бы быть неполной и поврежденной. Кроме того, SQLite не вызывает fsync() или FlushFileBuffers() на произведенной базе данных, чтобы гарантировать, что это достигло энергонезависимой памяти перед завершением.

3. Как работает VACUUM

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

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

VACUUM может изменить ROWID записей в любых таблицах, у которых нет явного INTEGER PRIMARY KEY.

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

Альтернатива использованию команды VACUUM, чтобы восстановить пространство после удаления данных, это автовакуумный режим через auto_vacuum pragma. Когда auto_vacuum включен для базы данных, свободные страницы могут быть исправлены после удаления данных, заставив файл сжаться, не восстанавливая всю базу данных, используя VACUUM. Однако, использование auto_vacuum может привести к дополнительной фрагментации файла базы данных. auto_vacuum не уплотняет частично заполненные страницы базы данных, как VACUUM.