powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Выросло время восстановления из бекапа в 3-4 раза.
6 сообщений из 6, страница 1 из 1
Выросло время восстановления из бекапа в 3-4 раза.
    #39590861
edkuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго времени суток!
Уровень знания sql: простейшие операции над БД и простенькие запросы.

Столкнулся с такой проблемой:

Код: plaintext
1.
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С следующим скриптом:
Код: sql
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


После этого данный бекап восстанавливается в другую базу:
Код: sql
1.
2.
3.
4.
5.
6.
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 гигабайт.

Подскажите, что могло вызвать увеличение времени восстановления?
Можно как-то отследить процесс восстановления, что бы выявить причину?
...
Рейтинг: 0 / 0
Выросло время восстановления из бекапа в 3-4 раза.
    #39590864
Andy_OLAP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
edkuznetsov3 месяца назад процесс восстановления из бекапа занимал около 15 минут, на текущий момент восстановление длится около 50 минут.
Конфигурация сервера не менялась, объем базы вырос за 3 месяца с 120 до 140 гигабайт.

Подскажите, что могло вызвать увеличение времени восстановления?
Можно как-то отследить процесс восстановления, что бы выявить причину?
Подсказываю.
1. Сервер в реальности работает в виртуальной машине, файл начал расти динамически вместо заранее выбранного зафиксированного размера.
2. Место с БД, куда идет рестор, лежит поверх RAID массива, который разлетелся, hotspare диск подцепился взамен умершего - и идет неспешный процесс ребилда. А поскольку hotspare диск периодически отлетает от шины - шнурок плохой, например - то этот ребилд регулярно запускается с нуля и тормозит-тормозит-тормозит работу дисковой подсистемы.
3. База не выросла, журнал вырос. Нужно проверить физические размеры mdf и ldf, сколько они занимают места на дисках там и там.
...
Рейтинг: 0 / 0
Выросло время восстановления из бекапа в 3-4 раза.
    #39590872
edkuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Andy_OLAPedkuznetsov3 месяца назад процесс восстановления из бекапа занимал около 15 минут, на текущий момент восстановление длится около 50 минут.
Конфигурация сервера не менялась, объем базы вырос за 3 месяца с 120 до 140 гигабайт.

Подскажите, что могло вызвать увеличение времени восстановления?
Можно как-то отследить процесс восстановления, что бы выявить причину?
Подсказываю.
1. Сервер в реальности работает в виртуальной машине, файл начал расти динамически вместо заранее выбранного зафиксированного размера.
2. Место с БД, куда идет рестор, лежит поверх RAID массива, который разлетелся, hotspare диск подцепился взамен умершего - и идет неспешный процесс ребилда. А поскольку hotspare диск периодически отлетает от шины - шнурок плохой, например - то этот ребилд регулярно запускается с нуля и тормозит-тормозит-тормозит работу дисковой подсистемы.
3. База не выросла, журнал вырос. Нужно проверить физические размеры mdf и ldf, сколько они занимают места на дисках там и там.

1. Не очень понял, о каком файле речь.
2. Попробую уточнить у админов.. Но мне кажется маловероятным т.к. сервер на котором все это крутится сам по себе виртуальный, и проблема с RAID отразилась бы и на других виртуальных серверах.
3. Из 143488,50 МБ, журнал занимает 7840,20 МБ. Его размер не сильно изменился за эти 3 мес.
...
Рейтинг: 0 / 0
Выросло время восстановления из бекапа в 3-4 раза.
    #39590884
Фотография Yasha123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
учетку, из под которой сервис сервера стартует, не меняли случайно?
может, у ней отобрали perform volume maintenance tasks и сервер перегрузили?
...
Рейтинг: 0 / 0
Выросло время восстановления из бекапа в 3-4 раза.
    #39590895
edkuznetsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Yasha123учетку, из под которой сервис сервера стартует, не меняли случайно?
может, у ней отобрали perform volume maintenance tasks и сервер перегрузили?
Проверил, все на месте.
...
Рейтинг: 0 / 0
Выросло время восстановления из бекапа в 3-4 раза.
    #39590896
Andy_OLAP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
edkuznetsovAndy_OLAPпропущено...

Подсказываю.
1. Сервер в реальности работает в виртуальной машине, файл начал расти динамически вместо заранее выбранного зафиксированного размера.
2. Место с БД, куда идет рестор, лежит поверх RAID массива, который разлетелся, hotspare диск подцепился взамен умершего - и идет неспешный процесс ребилда. А поскольку hotspare диск периодически отлетает от шины - шнурок плохой, например - то этот ребилд регулярно запускается с нуля и тормозит-тормозит-тормозит работу дисковой подсистемы.
3. База не выросла, журнал вырос. Нужно проверить физические размеры mdf и ldf, сколько они занимают места на дисках там и там.

1. Не очень понял, о каком файле речь.
2. Попробую уточнить у админов.. Но мне кажется маловероятным т.к. с ервер на котором все это крутится сам по себе виртуальный , и проблема с RAID отразилась бы и на других виртуальных серверах.
3. Из 143488,50 МБ, журнал занимает 7840,20 МБ. Его размер не сильно изменился за эти 3 мес.
Файл VMDK для VMware. Перешлите админам ссылку , может быть, они не в курсе. Ну или RAID никак не смотрят и думают, что все хорошо, раз никто активно не жалуется.
...
Рейтинг: 0 / 0
6 сообщений из 6, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Выросло время восстановления из бекапа в 3-4 раза.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]