Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Выросло время восстановления из бекапа в 3-4 раза.
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток! Уровень знания sql: простейшие операции над БД и простенькие запросы. Столкнулся с такой проблемой: Код: plaintext 1. Каждый день происходит бекап базы 1С следующим скриптом: Код: sql 1. После этого данный бекап восстанавливается в другую базу: Код: sql 1. 2. 3. 4. 5. 6. 3 месяца назад процесс восстановления из бекапа занимал около 15 минут, на текущий момент восстановление длится около 50 минут. Конфигурация сервера не менялась, объем базы вырос за 3 месяца с 120 до 140 гигабайт. Подскажите, что могло вызвать увеличение времени восстановления? Можно как-то отследить процесс восстановления, что бы выявить причину? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:02 |
|
||
|
Выросло время восстановления из бекапа в 3-4 раза.
|
|||
|---|---|---|---|
|
#18+
edkuznetsov3 месяца назад процесс восстановления из бекапа занимал около 15 минут, на текущий момент восстановление длится около 50 минут. Конфигурация сервера не менялась, объем базы вырос за 3 месяца с 120 до 140 гигабайт. Подскажите, что могло вызвать увеличение времени восстановления? Можно как-то отследить процесс восстановления, что бы выявить причину? Подсказываю. 1. Сервер в реальности работает в виртуальной машине, файл начал расти динамически вместо заранее выбранного зафиксированного размера. 2. Место с БД, куда идет рестор, лежит поверх RAID массива, который разлетелся, hotspare диск подцепился взамен умершего - и идет неспешный процесс ребилда. А поскольку hotspare диск периодически отлетает от шины - шнурок плохой, например - то этот ребилд регулярно запускается с нуля и тормозит-тормозит-тормозит работу дисковой подсистемы. 3. База не выросла, журнал вырос. Нужно проверить физические размеры mdf и ldf, сколько они занимают места на дисках там и там. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:06 |
|
||
|
Выросло время восстановления из бекапа в 3-4 раза.
|
|||
|---|---|---|---|
|
#18+
Andy_OLAPedkuznetsov3 месяца назад процесс восстановления из бекапа занимал около 15 минут, на текущий момент восстановление длится около 50 минут. Конфигурация сервера не менялась, объем базы вырос за 3 месяца с 120 до 140 гигабайт. Подскажите, что могло вызвать увеличение времени восстановления? Можно как-то отследить процесс восстановления, что бы выявить причину? Подсказываю. 1. Сервер в реальности работает в виртуальной машине, файл начал расти динамически вместо заранее выбранного зафиксированного размера. 2. Место с БД, куда идет рестор, лежит поверх RAID массива, который разлетелся, hotspare диск подцепился взамен умершего - и идет неспешный процесс ребилда. А поскольку hotspare диск периодически отлетает от шины - шнурок плохой, например - то этот ребилд регулярно запускается с нуля и тормозит-тормозит-тормозит работу дисковой подсистемы. 3. База не выросла, журнал вырос. Нужно проверить физические размеры mdf и ldf, сколько они занимают места на дисках там и там. 1. Не очень понял, о каком файле речь. 2. Попробую уточнить у админов.. Но мне кажется маловероятным т.к. сервер на котором все это крутится сам по себе виртуальный, и проблема с RAID отразилась бы и на других виртуальных серверах. 3. Из 143488,50 МБ, журнал занимает 7840,20 МБ. Его размер не сильно изменился за эти 3 мес. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:13 |
|
||
|
Выросло время восстановления из бекапа в 3-4 раза.
|
|||
|---|---|---|---|
|
#18+
учетку, из под которой сервис сервера стартует, не меняли случайно? может, у ней отобрали perform volume maintenance tasks и сервер перегрузили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:21 |
|
||
|
Выросло время восстановления из бекапа в 3-4 раза.
|
|||
|---|---|---|---|
|
#18+
Yasha123учетку, из под которой сервис сервера стартует, не меняли случайно? может, у ней отобрали perform volume maintenance tasks и сервер перегрузили? Проверил, все на месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:28 |
|
||
|
Выросло время восстановления из бекапа в 3-4 раза.
|
|||
|---|---|---|---|
|
#18+
edkuznetsovAndy_OLAPпропущено... Подсказываю. 1. Сервер в реальности работает в виртуальной машине, файл начал расти динамически вместо заранее выбранного зафиксированного размера. 2. Место с БД, куда идет рестор, лежит поверх RAID массива, который разлетелся, hotspare диск подцепился взамен умершего - и идет неспешный процесс ребилда. А поскольку hotspare диск периодически отлетает от шины - шнурок плохой, например - то этот ребилд регулярно запускается с нуля и тормозит-тормозит-тормозит работу дисковой подсистемы. 3. База не выросла, журнал вырос. Нужно проверить физические размеры mdf и ldf, сколько они занимают места на дисках там и там. 1. Не очень понял, о каком файле речь. 2. Попробую уточнить у админов.. Но мне кажется маловероятным т.к. с ервер на котором все это крутится сам по себе виртуальный , и проблема с RAID отразилась бы и на других виртуальных серверах. 3. Из 143488,50 МБ, журнал занимает 7840,20 МБ. Его размер не сильно изменился за эти 3 мес. Файл VMDK для VMware. Перешлите админам ссылку , может быть, они не в курсе. Ну или RAID никак не смотрят и думают, что все хорошо, раз никто активно не жалуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 13:31 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39590895&tid=1690428]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
85ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 443ms |

| 0 / 0 |
