база MS SQL 2005 висит в режиме (Restoring...) (Восстановление из копии...) #508018

Есть база для 1С 8.2 на MS SQL 2005. Настроен полный бэкап каждую ночь, бэкап лога транзакций днём каждые 2 часа. На момент 15 часов потребовалось восстановить базу. Восстановил, Managemeng Studio ответил, что восстановлено. А база зависла в состоянии восстановления из копии...

select @@version Microsoft SQL Server 2005 - 9.00.4262.00 (X64)   Aug 13 2009 17:06:39   Copyright (c) 1988-2005 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.1 (Build 7600: )

а ты думал - в сказку попал? Скуль последовательно выполняет все запросы с момента полного бэкапа до 15-ти часов

обновить список баз в ssms не пробовали?

а вообще, restore database [yourdb] with recovery

это как? можно подробнее на 2000 сервере аналогичный приём запуска из консоли срабатывал. А на более продвинутом нужно всё руками делать?   восстановить полную копию, а потом руками каждый файл лога транзакций - порядка 5 штук.

походу ждать

Ага :) Или указать на какую точку времени восстанавливать.

в - это мое предположение, что база в состоянии нормальном, а в списке отображается как restoring - встаньте на databases и тыркните f5. Опишите, подробнее, что вы делали. Мож просто забыли при накате последней копии установить галку "recovery", вот оно и ждет, что вы еще что=-нибудь накатывать будете

4 часа прошло, база со всеми логами восстановилась минут за 10. Эта же база, но полный бэкап без логов транзакций восстанавливается и переходит в нормальное состояние. Пробовал с разных серверов через разные консоли заходить - через английскую и через русскую, ответы однозначные как в subj use skip отвечает так: Database 'skip' cannot be opened. It is in the middle of a restore.

вы все резервные копии журналов транзакций накатили?

Кстати, а нахрена "бэкап лога транзакций днём каждые 2 часа"?

SELECT ost.session_id     , DB_NAME(ISNULL(s.dbid,1)) AS dbname     , er.command     , er.percent_complete     , er.status     , osth.os_thread_id     , ost.pending_io_count     , ost.scheduler_id     , osth.creation_time     , ec.last_read     , ec.last_write     , s.text     , owt.exec_context_id     , owt.wait_duration_ms     , owt.wait_type FROM   master.sys.dm_os_tasks AS ost JOIN   master.sys.dm_os_threads AS osth ON ost.worker_address = osth.worker_address AND    ost.pending_io_count > 0 AND ost.session_id IS NOT NULL JOIN   master.sys.dm_exec_connections AS ec ON ost.session_id = ec.session_id CROSS  APPLY master.sys.dm_exec_sql_text(ec.most_recent_sql_handle) AS s JOIN   master.sys.dm_os_waiting_tasks AS owt ON ost.session_id = owt.session_id AND    owt.wait_duration_ms > 0 JOIN   master.sys.dm_exec_requests AS er ON ost.session_id = er.session_id AND    er.percent_complete > 0 ORDER BY ost.session_id GO Что показывает?

а как тогда обеспечить оптимальное время восстановления при аварии? нужно было делать разностный бэкап каждые 2 часа? А лог иначе растёт если не бэкапить. Activiti Monitor пишет что с этой базой сейчас никто не работает

Да кстати... я вот тоже думаю, у меня тут упала база... а бекап только ночной, кое что нужное потерялось. Бекап лога делать не хочтеся, наверное то что очень нужно буду писать в MySQL в процессе дня.

указал момент времени и выбрал всё из предложенного списка - полный бэкап и все логи... 0 строк, с десяток колонок.

restore database [your] with recovery оно (gui), похоже, само базу в это состояние не перевело. Юзайте православные скрипты.

ну так в том и цель топика. Меня бы устроил такой порядок - восстановил из gui потом дополнительно запустил бы скрипт, чтобы вывести базу из ступора...

ну так запустите... я че-т не понимаю что вас останавливает.. попробуйте посмотреть на скрипт, генерируемый gui - в окне восстановления сверху нажмите script-> to new window (или как-то так). И посмотрите что там в самой последней команде restore - with recovery или with norecovery..

почему gui не работает? Зачем он тогда нужен? Допустим потрачу время, найду способ восстановления с помощью скриптов. Через какой-то время забуду или в отпуск уеду, другой человек так же должен мучатся? в gui в раздере параметры в группе окна Состояние восстановления по умолчанию выбран флаг restore with recovery Попробую пока скриптом и отпишусь. Но мне не нравится такой способ. можно в 2-х словах сказать как правильно обеспечить возможность восстановления базы с максимальной потерей времени 2 часа?

спасибо  виден конец... )) Как последнюю строку записать? Так? RESTORE LOG [МояБаза] FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009301500.trn' WITH  FILE = 1,  RECOVERY RESTORE DATABASE [МояБаза] FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009300425.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10 GO RESTORE LOG [МояБаза] FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009300700.trn' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10 GO RESTORE LOG [МояБаза] FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009300900.trn' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10 GO RESTORE LOG [МояБаза] FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009301100.trn' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10 GO RESTORE LOG [МояБаза] FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009301300.trn' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  STATS = 10 GO RESTORE LOG [МояБаза] FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009301500.trn' WITH  FILE = 1,  NOUNLOAD,  STATS = 10,  STOPAT = N'2010-09-30T15:24:36' GO

Только что проверил - база висит в Restoring после восстановления полного бэкапа с "RESTORE WITH NORECOVERY", она, собссно, ждет журналов транзакций. З.Ы. А сколько база весит-то, что бэкап журнала каждые 2 часа делается?

8Гб SQL база, 10Гб лог через день сжатие базы данных + первая и последние строки, соответственно так: WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 10 WITH  FILE = 1,  RECOVERY,  NOUNLOAD,  STATS = 10 База восстановилась, подключу её обратно к 1С-ке, проверю. А как gui заставить не на момент времени восстанавливать, а... чтобы как в этом ручном скрипте? Неужели всегда руками подправлять?

лог 10Гб при бэкапе каждые 2 часа? О_о

все ясно, gui нормально отработал. Смотрите: В последней команде стоит STOPAT = N'2010-09-30T15:24:36' И там же: FROM  DISK = N'F:BackUp_sqlМояБаза_backup_201009301500.trn', т.е. время создания бэкапа: 201009301500. Т.е. вы пытаетесь восстановиться на несуществующую в ваших бэкапах точку времени. SQL Server понимает, что такого времени нет и оставляет базу данных в состоянии restoring, чтобы вы могли накатить следующие бэкапы, содержащие в себе это время.

а если это последний бэкап, как сказать об этом? смотреть время последнего лога и устанавливать это время? Или дату начала или дату окончания(Start date Finish Date)?

Перед тем как делать восстановление из бэкапа, сделал полный бэкап, поэтому пришлось в gui вводить время чуть больше чем последний лог транзакций и меньше чем последний полный бэкап.

почитайте в BOL про цепочку восстановления. Вы всегда начинаете восстановление с полного бэкапа, а затем, последовательно, "накатываете" резервные копии журналов транзакций. В 2005-м sql server'e полный бэкап не прерывает цепочку журналов (т.е. после снятия последнего полного бэкапа надо было сделать еще одну резервную копию журнала транзакций и использовать ее в своей, "использованной" цепочке) и не поддерживает восстановление на момент времени. Из полного бэкапа вы можете восстановиться только на момент создания бэкапа. Т.е., чтобы вам восстановиться на указанный вами момент времени надо снять еще одну копию журнала транзакций (после полной резервной копии) и проделать все тоже самое, что вы уже делали, но в качестве последней копии указать последнюю копию журнала транзакций. Фух.. надеюсь, понятно :)

сколько делается полный бэкап? может есть смысл делать полные копии вместо бэкапа лога? --- хотя к текущей ситуации это отношения не имеет

только резервное копирование журнала транзакций дает вам возможность восстановиться на ЛЮБОЙ момент времени, начиная от времени создания первой резервной копии журнала транзакций и заканчивая временем создания последней копии.. Вот, нашел-таки ссылку

ну и нафига оно надоть? симпл работает шустрее, чем фулл

Да неужели? В чем это проявляется?

доказывать и спорить нет настроения

понятно, нужно будет потренироваться пока база не перешла на полную нагрузку ;) Можно было поступить так. сделать бэкап лога транзакций, потом полный бэкап, а потом восстановить на нужное время до момента возникновения проблем. Но попробовал глянуть на скрипт для другой базы. Логов там до конца дня, я задал момент времени 13 часов, вот последняя строка: _backup_201009301400.trn' WITH  FILE = 1,  NOUNLOAD,  STATS = 10,  STOPAT = N'2010-09-30T13:16:19' RECOVERY там нет не проверял время, проверил объем.  полный бэкап порядка 4Гб, все логи за весь день порядка 600Мб в сумме. А диск для бэкапов не резиновый ))

слив защитан RECOVERY можно не указывать, оно по-умолчанию. Восстановилось нормально?

20 гб база бэкапится в онлайн режиме 51 сек потом 40 минут сжимается до 1,5 гб но я не навязываю свою точку зрения

не пробовал ещё )) спасибо за ссылку. давно подобное читал, но потерял ссылки. во времена 2000 серверов даже держал в голове ;) самым важным будет время восстановления после сбоя. В течение дня  все сервера загружены делом, сжимать и разжимать нужно время и ресурсы.

Распаковывается база примерно в 20 раз быстрее чем сжимается... (хотя зависит от сервера)

+ На восстоновление после сбоя , больше всего времени ушло на загрузку бекаппа... на тупом серваке 3 часа 30минут... против 30 минут на нормальном серваке... база 80 гб

а чего ты мне-то объясняешь, я в курсе )

закладка