Có cách nào để xác định ai đã đánh rơi một cái bàn không?

Một bảng trong cơ sở dữ liệu sản xuất đã "biến mất một cách bí ẩn".

Có ai biết cách nào để chẩn đoán cái quái gì đã xảy ra với nó không? Và ai đã làm điều đó?

Chỉnh sửa 1: Đây là một ứng dụng nội bộ, có bảo mật yếu. Tất cả các ứng dụng (trừ mỏ của khóa học ;-) dễ bị SQL Injection, nhưng người dùng của chúng tôi là rất không phức tạp và tên bảng không phải là một mà có thể ngay lập tức rõ ràng, vì vậy tôi không nghĩ đó là một SQL Injection (không rằng nó quan trọng ... loại vượt quá phạm vi của câu hỏi).

Chỉnh sửa 2: Ngoài ra, chỉ là một FYI; bảng này đã có từ lâu, vì vậy nó không 'hoàn tác' với việc khôi phục.

Bạn có thể lấy thông tin ra khỏi nhật ký bằng cách sử dụng hàm :: fn_dblog không có bản quyền để giải thích các bản ghi nhật ký. Tôi đang ở giữa giảng dạy một lớp khắc phục thảm họa ngay bây giờ, nhưng nếu bạn có thể đợi 2-3 giờ tôi sẽ đăng cách làm điều đó cho bạn - nên cũng có thể lấy tên người dùng mà không phải mua bất kỳ công cụ nào ( Tôi đã từng chơi trò chơi quanh bản ghi một tấn vào năm 2000 khi tôi viết một loạt mã phân tích nhật ký nội bộ mà DBCC CHECKDB sử dụng vào năm 2000).

[Đã chỉnh sửa để bao gồm hướng dẫn] Ok - dạy xong và tôi đã gõ một bài đăng trên blog để chỉ cho bạn cách phân tích nhật ký vào năm 2000, 2005, 2008 để tìm hiểu khi nào bảng bị bỏ và ai đã làm nó. Kiểm tra bài đăng trên blog của tôi tại Tìm hiểu ai đã đánh rơi bảng bằng nhật ký giao dịch . [/biên tập]

Bạn vẫn có nhật ký giao dịch xung quanh? Những mô hình phục hồi là cơ sở dữ liệu trong? Nếu đó là ĐƠN GIẢN, đừng làm bất cứ điều gì có thể gây ra điểm kiểm tra. Nếu đó là FULL hoặc BULK_LOGGED, đừng thực hiện sao lưu nhật ký. Một trong hai điều này sẽ khiến nhật ký bị cắt ngắn và sau đó bạn có thể mất khả năng nhìn lại nhật ký, mặc dù tôi đã bao gồm một cờ theo dõi trong bài đăng trên blog cũng có thể giúp bạn điều đó.

Cảm ơn

PS Một cách để ngăn chặn bảng giảm vào năm 2000 mà không cần thêm bảo mật là tạo chế độ xem lược đồ đơn giản trên nó - DROP TABLE sẽ thất bại nếu chế độ xem tồn tại.

Có lẽ đó là Little Bobby Bàn ...

Bạn có thể khôi phục thông tin này từ nhật ký SQL.

Nếu nhật ký theo dõi mặc định đang chạy, tất cả thông tin được lưu trữ trong thư mục nhật ký. Bạn sẽ có thể thấy khi nào đối tượng (bảng) bị hủy và kết nối nào đã thực hiện. Nhưng kiểu này cho phép nên chỉ trao cho DBA s nào

Tôi đang cố gắng sửa một MSDB bị hỏng. Xin lỗi tôi không thể giải thích.

Chạy những thứ này và nó sẽ đưa ra một ý tưởng chung về nơi cần tìm, giả sử dấu vết mặc định của bạn được bật.

CHỌN * TỪ :: fn_trace_getinfo (mặc định)

CHỌN t.EventID, t.ColumnID, e.name dưới dạng Event_Des mô tả, c.name dưới dạng Cột = c.trace_column_id

Cách duy nhất để tìm hiểu thông tin này là bằng cách đọc nhật ký giao dịch (giả sử nó ở chế độ khôi phục hoàn toàn).

Hai cách để làm điều này:

• Các công cụ của bên thứ ba như ApexSQL Log hoặc SQL Log Rescue (chỉ miễn phí nhưng chỉ có sql 2000)
• Sử dụng các lệnh như DBCC LOG hoặc fn_dblog - không có lệnh nào trong số đó là tài liệu tốt

Trong SSMS, bạn có thể thử nhấp chuột phải vào dB và điều hướng qua Báo cáo -> Báo cáo chuẩn -> Lịch sử thay đổi lược đồ.

Nhấp chuột phải vào báo cáo và 'SaveAs' Excel và tìm namne đối tượng của bạn.

Bạn sẽ không thể nhận được bất cứ điều gì nếu máy chủ đã được khởi động lại hơn năm lần sau khi đối tượng đã bị hủy.