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

8

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

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

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

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

security sql-server

— Джон Макинтайр
источник

Ты имеешь в виду, что призрак "Не Я" тоже тебя получил?

— Ник ДеВор

у вас есть отдельные учетные записи базы данных для всех или все входят в систему как 'dba' или что-то подобное?

@ Zerofiz-Мы используем встроенную безопасность Windows, так что да, каждый пользователь может быть идентифицирован.

— Джон Макинтайр

Я наткнулся на этот блог, в котором объясняется пошаговый процесс определения, кто отбросил таблицу dbarepublic.com/2015/01/who-dropped-table.html .

14

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

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

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

Спасибо

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

— Пол Рэндал
источник

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

— Джон Макинтайр

8

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

— Майкл Боргвардт
источник

1

Приятно :) Было бы +1 за юмор, но это было бы глупо, так как единственный другой ответ также имеет 1 голос.

2

Нет, это достаточно забавно для возражения.

— Electrons_Ahoy

2

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

— RSolberg
источник

Я знаю, что эта информация находится в журналах SQLServer, но я думал, что вы ничего не можете прочитать из них. Я хотел бы узнать, что вы можете. Кто-нибудь знает?

— Джон Макинтайр

Я знаком только с Sybase SQL Anywhere, но у них есть утилита для преобразования файлов журналов в операторы SQL ...

1

Этот инструмент может помочь вам прочитать журналы. red-gate.com/products/SQL_Log_Rescue/index.htm

— RSolberg,

+1 за ссылку инструмента журнала. Почему бы тебе не вставить это в ответ?

— Джон Макинтайр

2

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

— TStamper
источник

2

Я пытаюсь исправить поврежденный 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

Спасибо, я думаю, что таблицы sys. * 2005 года, не так ли? Есть ли эквивалент 2000?

— Джон Макинтайр

2

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

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

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

— Энтони Хоровиц
источник

2

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

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

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

— user204862
источник

Просмотр журналов не удался для меня. Большинство из них были переполнены из-за большого количества транзакций в нашей системе. Ваш метод работал отлично. Спасибо, что поделился!

— Tylerjgarland