#sql-server #azure-virtual-machine #database-backups
#sql-server #azure-virtual-machine #база данных-резервные копии
Вопрос:
У меня есть виртуальная машина Azure со следующим: Windows DataCenter 2019 Виртуальный накопитель для разработчиков SQL Server 2017 объемом 6 ТБ (состоящий из 12 512 ГБ SSD-дисков премиум-класса), 112 ГБ оперативной памяти, 16 процессоров VCPU
У меня есть БД, в которой имеется файл данных объемом около ~ 5 ТБ (2 ТБ пусто) и файл журнала объемом около ~ 1 ТБ (99% пусто). Я скопировал это в хранилище больших двоичных объектов Azure (64 больших двоичных объекта).
Когда я восстанавливаюсь на своем SQL Server с включенной мгновенной инициализацией файлов, это занимает ~ 40 часов. Я вижу, что пропускная способность сети и диска действительно низкая.
Когда я отключаю мгновенную инициализацию файлов, для обнуления файлов требуется ~ 3 часа, а затем я получаю хорошую производительность при восстановлении ~ 1 1/2 часа (в дополнение к ~ 3 часам для обнуления файлов)
Кто-нибудь знает, почему это может быть.
Мой код для восстановления
restore database [<db_name>] from
url = 'https://.....url_1.bak',
...
url = 'https://.....url_64.bak',
move 'db_log' to 'new log location' -- i am only moving the log file, as the data file's location doesn't change
stats = 1, norecovery;
Комментарии:
1.
Azure VMозначает, что у вас нет диска объемом 6 ТБ, у вас есть что-то, что будет выделять до 6 ТБ, когда вас попросят об этом. Хост виртуальной машины Azure не знает, что вам это нужно для SQL Server, поэтому это задержит реальное выделение любого хранилища до тех пор, пока оно не понадобится. Он не будет выделять какие-либо блоки, пока ему действительно не нужно будет что-то в них хранить. Без мгновенной инициализации файла виртуальная машина с самого начала запрашивает 5 ТБ данных с конкретными данными , поэтому хост выделяет это хранилище и возвращает его.2. При мгновенной инициализации файла ничего не нужно записывать, поэтому хост ничего не выделит, пока RESTORE не начнет записывать страницы диска. Не тогда, когда файлы базы данных растут, а когда фактические блоки должны быть записаны на диск
3. Вы проверили конфигурацию хранилища для виртуальных машин SQL Server ? Хотя я подозреваю, что вы уже это сделали
4. Я следовал этому, за исключением того, что файл журнала и файл данных находятся на одном диске, может ли это быть причиной?
5. Это очень большая проблема, тем более что руководство рекомендует использовать различное кэширование для дисков данных и журналов. Если бы у вас был встроенный сервер, у вас все равно была бы большая проблема, поскольку записи данных и журналов конкурировали бы за одинаковую пропускную способность ввода-вывода. Данные не записываются в файл данных до записи изменений в журнал транзакций, поэтому использование одного и того же диска для обоих существенно сокращает пропускную способность вдвое и добавляет дополнительную задержку. Использование отдельных файлов данных и журналов является стандартной конфигурацией для любой базы данных, а не только для SQL Server.