Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
edkuznetsov Member Откуда: Сообщений: 3 |
Доброго времени суток! Уровень знания sql: простейшие операции над БД и простенькие запросы. Столкнулся с такой проблемой: Microsoft SQL Server 2016 (RTM-GDR) (KB4019088) - 13.0.1742.0 (X64) Jul 5 2017 23:41:17 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows Server 2016 Standard 6.3 <X64> (Build 14393: ) (Hypervisor) Каждый день происходит бекап базы 1С следующим скриптом: BACKUP DATABASE [trade_work] TO DISK = N'\\s-report04\D$\BACKUP\trade_work_olap.bak' WITH NOFORMAT, INIT, NAME = N'trade_work', SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 10 После этого данный бекап восстанавливается в другую базу: USE MASTER ALTER DATABASE [trade_develop2] SET SINGLE_USER WITH ROLLBACK IMMEDIATE RESTORE DATABASE [trade_develop2] FILE = N'NSI' FROM DISK = N'D:\BACKUP\trade_work_olap.bak' WITH FILE = 1, MOVE N'NSI' TO N'D:\DATA\trade_develop2.mdf', MOVE N'NSI_log' TO N'D:\LOG\trade_develop2.ldf', NOUNLOAD, REPLACE, STATS = 10 ALTER DATABASE [trade_develop2] SET MULTI_USER 3 месяца назад процесс восстановления из бекапа занимал около 15 минут, на текущий момент восстановление длится около 50 минут. Конфигурация сервера не менялась, объем базы вырос за 3 месяца с 120 до 140 гигабайт. Подскажите, что могло вызвать увеличение времени восстановления? Можно как-то отследить процесс восстановления, что бы выявить причину? |
25 янв 18, 13:02 [21137996] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Подсказываю. 1. Сервер в реальности работает в виртуальной машине, файл начал расти динамически вместо заранее выбранного зафиксированного размера. 2. Место с БД, куда идет рестор, лежит поверх RAID массива, который разлетелся, hotspare диск подцепился взамен умершего - и идет неспешный процесс ребилда. А поскольку hotspare диск периодически отлетает от шины - шнурок плохой, например - то этот ребилд регулярно запускается с нуля и тормозит-тормозит-тормозит работу дисковой подсистемы. 3. База не выросла, журнал вырос. Нужно проверить физические размеры mdf и ldf, сколько они занимают места на дисках там и там. |
||
25 янв 18, 13:06 [21138013] Ответить | Цитировать Сообщить модератору |
edkuznetsov Member Откуда: Сообщений: 3 |
1. Не очень понял, о каком файле речь. 2. Попробую уточнить у админов.. Но мне кажется маловероятным т.к. сервер на котором все это крутится сам по себе виртуальный, и проблема с RAID отразилась бы и на других виртуальных серверах. 3. Из 143488,50 МБ, журнал занимает 7840,20 МБ. Его размер не сильно изменился за эти 3 мес. |
||||
25 янв 18, 13:13 [21138053] Ответить | Цитировать Сообщить модератору |
Yasha123 Member Откуда: Сообщений: 1955 |
учетку, из под которой сервис сервера стартует, не меняли случайно? может, у ней отобрали perform volume maintenance tasks и сервер перегрузили? |
25 янв 18, 13:21 [21138108] Ответить | Цитировать Сообщить модератору |
edkuznetsov Member Откуда: Сообщений: 3 |
Проверил, все на месте. |
||
25 янв 18, 13:28 [21138184] Ответить | Цитировать Сообщить модератору |
Andy_OLAP Member Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион Сообщений: 3151 |
Файл VMDK для VMware. Перешлите админам ссылку, может быть, они не в курсе. Ну или RAID никак не смотрят и думают, что все хорошо, раз никто активно не жалуется. |
||||
25 янв 18, 13:31 [21138200] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |