ИТ-специалисты поняли, что в нашем производственном SQL Server 2005 произошла ошибка записи на диск, что привело к сбою резервного копирования. К тому времени, когда они это осознали, ночная резервная копия была устаревшей, поэтому было невозможно просто восстановить резервную копию на другом сервере.
База данных все еще работает и используется постоянно. Однако DBCC CheckDB не работает. Также происходит сбой задачи резервного копирования SQL Server, сбой копирования базы данных, сбоя мастера экспорта данных. Однако кажется, что все данные можно прочитать из таблиц (например, с помощью bcp и т. Д.)
Еще одно наблюдение, которое я сделал, заключается в том, что размер журнала транзакций почти вдвое превышает размер базы данных. (Означает ли это, что все изменения не записываются в MDF?)
Каков был бы лучший план атаки, чтобы привести базу данных в состояние, в котором резервные копии работают, а данные в безопасности?
ИТ-менеджер говорит, что данные в безопасности, так как в случае отказа сервера данные можно восстановить из mdf / ldf. Я не уверен, поэтому настаивал на том, чтобы мы начали экспортировать данные каждую ночь в качестве отказоустойчивого (например, используя bcp).
У ИТ-специалистов также есть проблемы с аппаратным обеспечением, так как предположительно ошибка диска на виртуализированном диске не может быть восстановлена, как обычный массив рейдов (или что-то в этом роде).
Прошу прощения за использование неправильной терминологии и неверных предположений о том, как работает Sql Server. Я разработчик приложений, и меня вызвали на помощь (поскольку кажется, что ИТ-специалисты знают о SQL Server меньше, чем я).
Большое спасибо, Амит
Результаты DBBC CheckDB:
Msg 1823, Level 16, State 2, Line 1
A database snapshot cannot be created because it failed to start.
Msg 7928, Level 16, State 1, Line 1
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
Msg 5030, Level 16, State 12, Line 1
The database could not be exclusively locked to perform the operation.
Msg 7926, Level 16, State 1, Line 1
Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details.
Msg 823, Level 24, State 3, Line 1
The operating system returned error 1(error not found) to SQL Server during a write at offset 0x00000674706000 in file 'G:\AX40_Dynamics_Live.mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Во-первых, будьте очень осторожны - вы не хотите усугублять ситуацию. Я настоятельно рекомендую проконсультироваться со службой поддержки продуктов Microsoft (вам придется заплатить), найти специалиста или поискать в Интернете материалы от Пола Рэндала.
Вы упоминаете, что существует старая резервная копия ... Вы пытались создать резервную копию журнала транзакций (GUI Management Studio позволяет вам это легко сделать), а затем восстановить старую резервную копию и эту новую резервную копию журнала транзакций - на новом , резервный сервер?
Огонь IT. Очевидно некомпетентный.
Попробуйте отбросить и воссоздать все индексы. Если вы правы в отношении возможности редактирования всех данных, ошибка записи должна быть в индексе - следовательно, вы можете «обойти ее».
LDF больший MDF означает, что журналы, возможно, не копируются. Учитывая продемонстрированную некомпетентность ИТ-администраторов, это весьма вероятно.
ИТ-менеджер не знает, что говорит. Если сервер выходит из строя, нет никакой гарантии, что mdf / ldf все еще можно будет редактировать без внешних инструментов (читайте: возможно, много денег). Маловероятно, но ИТ-менеджер должен знать, что в данный момент он рискует компанией. Ну, тогда - очевидно, он нанял ЭТО.
Попробуйте dbcc checkdb, опубликуйте результаты здесь, чтобы мы действительно могли вам помочь.
Этот вывод DBCC выглядит так, как будто он не может получить монопольный доступ к базе данных, поэтому он отказывается даже запускаться. Если вы хотите выбросить всех из базы данных, чтобы она действительно запускалась, используйте следующую команду:
ALTER DATABASE database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE
Как только вы это сделаете, DBCC CHECKDB должна быть готова к сотрудничеству. После того, как вы закончите, верните базу данных в многопользовательский режим:
ALTER DATABASE database_name SET MULTI_USER
Первое, что я бы порекомендовал сделать, - это отключить приложение и запустить checkdb, чтобы убедиться, что база данных не повреждена. Если это не так, тогда все наладится. Если это так, то нам нужно выяснить, насколько повреждены и какие данные мы можем восстановить.
Чтобы прямо сейчас запустить checkdb, вам нужно перевести базу данных в однопользовательский режим, возможно, затем запустить dbcc checkdb для каждой из баз данных.
Что происходит при попытке вручную запустить резервную копию базы данных?
Основываясь на том факте, что это динамика (и она управляет вашим бизнесом), вы можете потратить деньги и попросить либо PSS по телефону, либо консультанта по SQL, чтобы он посмотрел на это (даже с консультантом по SQL вы все равно можете звонить в PSS) .
Что касается самого вопроса в заголовке, вы не хотите просто экспортировать данные и повторно импортировать их. Скорее всего, это не будет поддержано.