«Очистить» файл базы данных SQL Server, созданный с включенной функцией мгновенной инициализации файла?

8

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

Итак, теперь я хочу отправить копию базы данных (возможно, файла резервной копии) за пределы компании. Но внутри файла есть все потенциально конфиденциальные «удаленные» данные. Теперь я хотел бы обнулить неиспользованную часть файла.

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

sql-server sql-server-2008-r2

— paulH
источник

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

— Джон Зигель

5

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

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

Однако, поскольку экстенты - это уровень, на котором происходит резервное копирование, неиспользуемые страницы в экстенте могут по-прежнему потенциально представлять некоторые данные при восстановлении на другом сервере. Не так много, как на исходном сервере, поскольку неиспользуемые экстенты не восстанавливаются.

— ДКП
источник

1

Неиспользуемые экстенты на самом деле. Теоретически даже некоторые из используемых экстентов все еще могут содержать пространство со «старыми данными», что для SQLServer бессмысленно, но может оказаться сокровищницей для конкурента, вооруженного шестнадцатеричным редактором и большим количеством свободного времени. Если ваши данные настолько чувствительны, разве вы не обнуляете все файлы в любом случае?

— Джон Алан

@JohnAlan - изменен для подтверждения воздействия в пределах экстента.

— RLF

Данные не совсем GCHQ - это просто основные данные о клиентах и тому подобное, поэтому вряд ли кто-то собирается приложить слишком много усилий, чтобы получить их. Я не осознавал, что резервные копии работают так, хотя имеет смысл, что так и должно быть. Если нет другого быстрого и простого решения, то это, вероятно, подойдет.

— Пол

1

Рассматривали ли вы восстановление его копии, включение TDE, которое заставит его обнуляться, а затем снова отключение TDE? Я не проверял это, но я думаю, что это сработает, но мы должны это проверить.

И еще кое-что: рассматривали ли вы восстановление копии с отключенным IFI, создание новой файловой группы с новыми файлами, ее сохранение, восстановление кластеризованных и других индексов в новой файловой группе, а затем удаление существующей файловой группы (если это основная файловая группа вам придется уменьшить его, так как вы не можете отказаться от основного)

— Али Разеги
источник

Использование TDE звучит как интересный подход, хотя я не уверен, удалит ли он больше ненужных данных, чем метод резервного копирования и восстановления. Если кто-нибудь знает больше информации об этом, мне было бы интересно узнать.

— Пол