Câu trả lời:
Hãy nhớ rằng cắt ngắn là một hoạt động đăng nhập hiệu quả .
Vì bạn đang chạy trong chế độ Khôi phục đơn giản và với điều kiện nhật ký T của bạn không bị cắt ngắn, bạn có thể lấy nó bằng cách sử dụng không có giấy tờ fn_dblog
:
SELECT [Current LSN]
,[Operation]
,[Begin Time]
,[Transaction ID]
,[Transaction Name]
,[Transaction SID]
,SUSER_SNAME([Transaction SID]) as UserWhoIssuedTruncate
FROM fn_dblog(NULL, NULL)
WHERE Operation = 'LOP_BEGIN_XACT' and
[Transaction ID] IN (
SELECT [Transaction ID]
FROM fn_dblog(NULL, NULL)
WHERE [Transaction Name] = 'TRUNCATE TABLE'
)
GO
Ngoài ra, bạn có thể chạy theo dõi phía máy chủ hoặc bật Kiểm toán SQL.
Luôn cung cấp quyền tối thiểu (nguyên tắc đặc quyền tối thiểu) cho người dùng của bạn.
Có thể nếu tôi thay đổi nó thành FULL?
Đúng vậy (và mô hình khôi phục nên được xác định bởi doanh nghiệp của bạn - bạn có muốn khôi phục kịp thời không? Doanh nghiệp của bạn có thể mất bao nhiêu dữ liệu? V.v.) Bạn phải bắt đầu duy trì nhật ký T bằng cách chạy nhật ký thường xuyên sao lưu. Điều này sẽ giữ nhật ký T của bạn ở một kích thước hợp lý.
Truy vấn đã chỉnh sửa sử dụng "IN" thay vì "=" vì có thể có nhiều kết quả trong truy vấn phụ.
Tôi e rằng không thể biết lần cuối cùng một bàn bị cắt mà không thiết lập một cái gì đó để ghi lại sự kiện.
Theo dõi mặc định không lưu giữ thông tin cho truncate
các sự kiện và sys.dm_dm_index_usage_stats
sẽ không giúp bạn ở đây.
Lựa chọn của bạn là:
Theo như câu hỏi thứ hai của bạn, mô hình phục hồi cho cơ sở dữ liệu sản xuất thường là FULL
bởi vì việc khôi phục cơ sở dữ liệu tại một thời điểm cụ thể nói chung là một yêu cầu. Cơ sở dữ liệu chỉ chứa dữ liệu có thể được xây dựng lại dễ dàng và nhanh chóng từ các nguồn dữ liệu khác thường không cần phải khôi phục tại một thời điểm cụ thể, vì vậy chúng thường nằm trong SIMPLE
mô hình khôi phục