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() для того, чтобы переложить на ОС управление быстрым созданием больших файлов и виртуальным заполнением этих файлов нулями без лишней фрагментации. Почему они не стали это делать, а пошли другим путём (через лишние привилегии), непонятно.
Очень подробный ответ. Спасибо.

Теперь по поводу осторожности… Если есть возможность ускорить дисковые операции, то почему не воспользоваться? Вопросы безопасности стоят не во всех организациях. Некоторым подавай максимальную производительность. А бывают ситуации, когда сервер ушел в мир иной и нужно в кратчайшие сроки восстановить базу из бекапа на другом железе. Там применение Instant File Initialization может сократить простой организации и нервы окружающих.
Еще забыл добавить… При включении Transparent Data Encryption (позволяет шифровать файлы на диске), 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
Only those users with full accounts are able to leave comments. Log in, please.