Таблица в производственной базе данных «таинственным образом» исчезла.
Кто-нибудь знает способ диагностировать, что, черт возьми, с этим случилось? А кто это сделал?
Изменить 1: Это внутреннее приложение со слабой безопасностью. Все приложения (кроме моего, конечно ;-) уязвимы для SQL Injection, но наши пользователи очень бесхитростным, а имя таблицы не могло быть сразу очевидным, поэтому я не думаю, что это была SQL-инъекция (не то чтобы это имеет значение ... что-то выходит за рамки вопроса).
Изменить 2: Кроме того, просто к вашему сведению; эта таблица существует уже давно, поэтому она не была «отменена» при восстановлении.
Вы могли бы получить информацию из журнала, используя недокументированную функцию :: fn_dblog, которая интерпретирует записи журнала. Я сейчас преподаю курс по аварийному восстановлению, но если вы подождете 2-3 часа, я опубликую, как это сделать для вас - тоже можно будет получить имя пользователя без необходимости покупать какие-либо инструменты ( Я имел обыкновение копаться в журнале тонну в 2000 году, когда я написал кучу кода внутреннего анализа журнала, который DBCC CHECKDB использует в 2000 году).
[Отредактировано, чтобы включить инструкции] Хорошо - закончил обучение, и я создал сообщение в блоге, чтобы показать вам, как анализировать журнал в 2000, 2005, 2008 годах, чтобы узнать, когда стол был брошен и кто это сделал. Проверьте мою запись в блоге на Выяснение, кто сбросил таблицу, с помощью журнала транзакций. [/редактировать]
У вас все еще есть журнал транзакций? В какой модели восстановления находится база данных? Если это ПРОСТО, не делайте ничего, что могло бы вызвать контрольную точку. Если это FULL или BULK_LOGGED, не делайте резервную копию журнала. Любой из них приведет к усечению журнала, и тогда вы можете потерять возможность просматривать журнал, хотя я включил в сообщение в блоге флаг трассировки, который может помочь вам и в этом.
Спасибо
PS Один из способов предотвратить падение таблицы в 2000 без добавления безопасности - создать для нее простое представление, связанное со схемой - DROP TABLE завершится ошибкой, если представление существует.
Может, это были маленькие столики Бобби ...
Возможно, вы сможете восстановить эту информацию из журналов SQL.
Если журнал трассировки по умолчанию запущен, вся информация сохраняется в папке журнала. Вы должны увидеть, когда объект (таблица) был удален и через какое соединение это произошло. Но такое разрешение следует давать только DBAв любом случае
Я пытаюсь исправить поврежденный MSDB. Извините, я не могу уточнить.
Запустите их, и это должно дать общее представление о том, где искать, если ваша трассировка по умолчанию включена.
SELECT * FROM :: fn_trace_getinfo (по умолчанию)
ВЫБЕРИТЕ t.EventID, t.ColumnID, e.name как Event_Description, c.name как Column_Description FROM :: fn_trace_geteventinfo (1) t ПРИСОЕДИНЯЙТЕСЬ к sys.trace_events e ON t.eventID = e.trace_event_id JOIN sys.trace_columns c ON t.columns = c.trace_column_id
Единственный способ узнать эту информацию - прочитать журнал транзакций (при условии, что он находится в режиме полного восстановления).
Это можно сделать двумя способами:
В SSMS вы можете попробовать щелкнуть правой кнопкой мыши по дБ и перейти через Отчеты -> Стандартные отчеты -> История изменений схемы.
Щелкните правой кнопкой мыши отчет и Excel «Сохранить как» и найдите название объекта.
Вы не сможете ничего получить, если сервер был перезапущен более пяти раз после удаления объекта.