Comments 12
Если фича такая прекрасная, то почему она не включена «из коробки»? Наверное, есть какие-то минусы от ее использования — о них в статье умолчали?
Судя по материалам из быстрого поиска — только соображения безопасности. Возможность прочитать «сырые» «стёртые» данные от других баз?
Дык это проблема процедуры удаления предыдущих данных, при чем здесь создание новой базы? Ведь новую мог никто и не создавать, а просто пойти почитать байты на диске.
Для того, чтобы пойти и почитать любые байты на диске (в том числе и удаленные файлы старых бэкапов таких директорий, как %SystemRoot%\System32\config, ну или ещё какие чувствительные данные), MSSQL как раз и требуется привилегия «Perform volume maintenance tasks». Я бы с осторожностью применял это, т.к. любая потенциальная уязвимость в MSSQL позволяющая удаленное исполнение кода (даже из-под пользователя с правами NT SERVICE\MSSQL$SQL_2012) может привести к утечке данных, к которым, по идее, доступа у NT SERVICE\MSSQL$SQL_2012 быть не должно.
Команда, писавшая MSSQL, могла бы использовать FSCTL_SET_SPARSE + FSCTL_SET_ZERO_DATA + FSCTL_QUERY_ALLOCATED_RANGES + SetFilePointerEx() + SetEndOfFile() для того, чтобы переложить на ОС управление быстрым созданием больших файлов и виртуальным заполнением этих файлов нулями без лишней фрагментации. Почему они не стали это делать, а пошли другим путём (через лишние привилегии), непонятно.
Команда, писавшая MSSQL, могла бы использовать FSCTL_SET_SPARSE + FSCTL_SET_ZERO_DATA + FSCTL_QUERY_ALLOCATED_RANGES + SetFilePointerEx() + SetEndOfFile() для того, чтобы переложить на ОС управление быстрым созданием больших файлов и виртуальным заполнением этих файлов нулями без лишней фрагментации. Почему они не стали это делать, а пошли другим путём (через лишние привилегии), непонятно.
Очень подробный ответ. Спасибо.
Теперь по поводу осторожности… Если есть возможность ускорить дисковые операции, то почему не воспользоваться? Вопросы безопасности стоят не во всех организациях. Некоторым подавай максимальную производительность. А бывают ситуации, когда сервер ушел в мир иной и нужно в кратчайшие сроки восстановить базу из бекапа на другом железе. Там применение Instant File Initialization может сократить простой организации и нервы окружающих.
Теперь по поводу осторожности… Если есть возможность ускорить дисковые операции, то почему не воспользоваться? Вопросы безопасности стоят не во всех организациях. Некоторым подавай максимальную производительность. А бывают ситуации, когда сервер ушел в мир иной и нужно в кратчайшие сроки восстановить базу из бекапа на другом железе. Там применение Instant File Initialization может сократить простой организации и нервы окружающих.
Instant File Initialization я включал для всех серверов, на которых работал и за два года не увидел никаких проблем при ее использовании. Кто столкнулся с проблемами – напишите в комментариях. Буду очень благодарен.
Потому что права системы — настройка windows, а не SQL Server. А вот давать всем подряд права Perform volume maintenance tasks действительно не стоит из соображений безопасности.
Единственная киллер-фича MS — это откаты. Других причин выделять на них бюджеты нет. Тем более — в современном мире.
Некоторые системы хранения позволяют детектить «забите нулями» и дедуюлицировать их на ходу, сильно снижая нагрузку на свою дисковую подсистему.
Добавляю еще один способ: «Как проверить включен ли Instant File Initialization?»:
IF OBJECT_ID('tempdb.dbo.#temp') IS NOT NULL
DROP TABLE #temp
GO
CREATE TABLE #temp (Value VARCHAR(8000))
GO
IF EXISTS (
SELECT 1
FROM sys.configurations
WHERE name = 'xp_cmdshell'
AND value_in_use = 1
AND IS_SRVROLEMEMBER('sysadmin') = 1
)
BEGIN
INSERT INTO #temp
EXEC('xp_cmdshell ''whoami /priv''')
SELECT IsEnabled =
CASE WHEN Value LIKE '%Enabled%' COLLATE SQL_Latin1_General_CP1_CI_AS
THEN 1
ELSE 0
END
FROM #temp
WHERE Value LIKE '%SeManageVolumePrivilege%'
END
Sign up to leave a comment.
Instant File Initialization