Странное поведение Sql Server 2005

Question

Фон:
У меня есть сайт, построенный в ASP.NET с Sql Server 2005 в качестве базы данных. Этот сайт является единственным сайтом на Windows Server 2003, который находится в моей клиентской серверной комнате. Клиент - это местный школьный округ, поэтому по соображениям безопасности данных нет доступа к удаленному рабочему столу и удаленного соединения с Sql Server, поэтому, если мне нужно обслуживать базу данных, я должен быть на терминале. У меня есть доступ по FTP для обновления кода ASP.

Проблема:
Мне вчера связались по поводу проблемы с системой. Когда я смотрю на него, кажется, что ошибка, которую я решил почти год назад, вернулась. У меня есть хранимая процедура, которая использовала int в качестве параметра, но год назад мы изменили структуру системы и обновили хранимую процедуру для получения nvarchar (10). Хранимая процедура почему-то вернулась к использованию int вместо nvarchar.

Существует внешний жесткий диск, подключенный к серверу, который периодически копирует данные и имеет возможность восстановить сервер в случае сбоя. Я бы предположил, что каким-то образом более старая версия базы данных была восстановлена, но известные мне данные, которые были вставлены за 7 дней и 1 день до появления ошибки, все еще находятся в базе данных.

Вопрос:
Есть ли в любом случае, что структура базы данных Sql Server 2005 может вернуться к предыдущей версии или быть восстановлена ​​в предыдущей версии, не затрагивая фактические данные? Ни у кого больше не должно быть доступа к серверу, поэтому я немного схожу с ума, пытаясь выяснить, как это вообще произошло.

Есть идеи?

Answer 1

Используя встроенный в SQL Server механизм резервного копирования и восстановления, невозможно выбрать только определенные объекты для восстановления. С помощью резервных копий журнала транзакций вы можете восстановить момент времени, который может быть до того, как была сделана определенная транзакция или оператор ALTER, но это самое близкое к вам значение. Существуют инструменты, которые позволят вам выбрать определенные объекты для восстановления, однако они работают либо путем восстановления базы данных в копию и копирования по нужным объектам, либо чтения резервной копии напрямую и копирования этих объектов. Другими словами, это не то, что могло случиться с использованием встроенных инструментов случайно. Я предполагаю, что кто-то случайно запустил старый скрипт из хранимых процедур, который его перевернул.

Answer 2

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

Одно предложение, запустите

select * from sys.procedures

и проверьте столбцы create_date и modify_date на предмет вашей проблемной процедуры и всех других процедур в базе данных.

Answer 3

Я наблюдал подобные вещи с приложением, которое я установил в одном месте клиента. Время от времени s'procs возвращаются к более старой версии.

Это всего лишь один клиент, приложение установлено у нескольких других, у которых никогда не было этой проблемы, и они также являются школьным округом. Это происходит примерно раз в 3 месяца или около того, и никто не должен прикасаться к этой машине. Я даже не уверен, что у них есть кто-то, кто знает, как открыть менеджера предприятия.

Из любопытства, какое программное обеспечение для резервного копирования использует ваш клиент? и, после проверки дат создания / изменения в процедурах, произошла ли перезагрузка сервера в это время?

Причина, по которой я спрашиваю, состоит в том, что у моего клиента есть программное обеспечение для резервного копирования, которое делает на этом сервере действительно странные вещи. Например, при перезагрузке он должен «воспроизвести» изменения, включая файловые операции, с момента последнего успешного резервного копирования. Кроме того, это установлено в VM?

Answer 4

Через службы преобразования данных (DTS)? или если где-нибудь доступны сценарии, которые устанавливают базу данных ..