Есть ли вообще способ определить, кто бросил стол?

Таблица в производственной базе данных «загадочным образом» исчезла.

Кто-нибудь знает какой-либо способ диагностировать, что, черт возьми, случилось с этим? И кто это сделал?

Редактировать 1: Это внутреннее приложение со слабой безопасностью. Все приложения (кроме моего, разумеется ;-) уязвимы для SQL-инъекций, но наши пользователи очень просты, и имя таблицы не было таким, которое могло бы быть сразу очевидным, поэтому я не думаю, что это была SQL-инъекция (не что это имеет значение ... вроде выходит за рамки вопроса).

Редактировать 2: Кроме того, просто к вашему сведению; эта таблица была вокруг в течение долгого времени, поэтому она не была «отменена» с восстановлением.

Вы можете получить информацию из журнала, используя функцию undocumented :: fn_dblog, которая интерпретирует записи журнала. Сейчас я нахожусь в процессе преподавания урока по аварийному восстановлению, но если вы подождете 2-3 часа, я опубликую, как это сделать для вас, - вы также можете получить имя пользователя без необходимости покупать какие-либо инструменты ( Я использовал для записи журнала в 2000 году тонну, так как написал кучу кода для анализа внутреннего журнала, который DBCC CHECKDB использует в 2000 году).

[Отредактировано, чтобы включать инструкции] Хорошо - закончил обучение, и я открыл пост в блоге, чтобы показать вам, как анализировать журнал в 2000, 2005, 2008 годах, чтобы выяснить, когда таблица была отброшена и кто это сделал. Оформите мою запись в блоге, чтобы узнать, кто удалил таблицу, используя журнал транзакций . [/редактировать]

У вас еще есть журнал транзакций? В какой модели восстановления находится база данных? Если это ПРОСТО, не делайте ничего, что могло бы вызвать контрольную точку. Если он ПОЛНЫЙ или BULK_LOGGED, не делайте резервную копию журнала. Любое из этих действий приведет к усечению журнала, и тогда вы можете потерять возможность просматривать журнал, хотя я включил в сообщение блога флаг трассировки, который также может вам в этом помочь.

Спасибо

PS Одним из способов предотвращения отбрасывания таблиц в 2000 году без добавления защиты является создание простого представления с привязкой к схеме - DROP TABLE завершится ошибкой, если представление существует.

Может быть, это были маленькие столики Бобби ...

Возможно, вы сможете восстановить эту информацию из журналов SQL.

Если запущен журнал трассировки по умолчанию, вся информация сохраняется в папке журнала. Вы должны быть в состоянии увидеть, когда объект (таблица) был отброшен и по какому соединению это произошло. Но этот тип разрешения должен быть дан только для администраторов баз данных в любом случае

Я пытаюсь исправить поврежденный MSDB. Извините, я не могу уточнить.

Запустите их, и это должно дать общее представление о том, где искать, если ваша трассировка по умолчанию включена.

SELECT * FROM :: fn_trace_getinfo (по умолчанию)

ВЫБЕРИТЕ t.EventID, t.ColumnID, e.name как Event_Description, c.name как Column_Description FROM :: fn_trace_geteventinfo (1) t JOIN sys.trace_events e ON t.eventID = e.trace_event_id JOIN sys.trace_columns c ON t.colid = c.trace_column_id

Единственный способ узнать эту информацию - прочитать журнал транзакций (при условии, что он находится в режиме полного восстановления).

Два способа сделать это:

• Сторонние инструменты, такие как ApexSQL Log или SQL Log Rescue (бесплатно, но только для SQL 2000)
• Использование таких команд, как DBCC LOG или fn_dblog - ни одна из которых, к сожалению, не документирована

В SSMS вы можете попробовать щелкнуть правой кнопкой мыши по дБ и перейти через Отчеты -> Стандартные отчеты -> История изменений схемы.

Щелкните правой кнопкой мыши отчет и выберите «Сохранить как» в Excel и найдите свой объект.

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