Giữ các bản sao lưu (một phần) nhỏ khi sử dụng SQL Server FILESTREAM


12

Tôi có một cơ sở dữ liệu với gần 1TB FILESTREAMdữ liệu mà tôi không cần sao lưu (nếu dữ liệu bị xóa, nó sẽ được tạo lại tự động sau vài giờ, vì vậy nó không quan trọng). Hầu hết dữ liệu được thay đổi mỗi vài ngày, do đó, sao lưu vi sai sẽ không thực sự giúp giảm kích thước.

Tôi đã có các bản sao lưu hoạt động theo cách tôi cần bằng cách đặt Chế độ khôi phục thành Full, tạo một bản sao riêng FILEGROUPcho FILESTREAM, sau đó chỉ lấy các bản sao lưu của "Chính" FILEGROUP. Vấn đề gây ra là tệp nhật ký (cũng được sao lưu) hiện lớn không cần thiết vì nó bao gồm FILESTREAMdữ liệu.

SIMPLEChế độ phục hồi lấy đi khả năng của tôi để thực hiện sao lưu các FILEGROUPs cụ thể , vì vậy tôi cũng không nghĩ đó sẽ là một lựa chọn.

Suy nghĩ của tôi là chỉ chuyển FILESTREAMdữ liệu sang một cơ sở dữ liệu riêng biệt, nhưng bây giờ tôi đang mất tính toàn vẹn tham chiếu và chắc chắn cũng thừa hưởng một loạt các vấn đề khác.

Có cách nào để tạo bản sao lưu một phần trong Simplechế độ phục hồi (mà không đặt FILESTREAMbảng chỉ đọc) không? Nếu không, có giải pháp lành mạnh nào khác cho vấn đề của tôi không?

Câu trả lời:


3

Vấn đề gây ra là tệp nhật ký (cũng được sao lưu) hiện lớn không cần thiết vì nó bao gồm dữ liệu FILESTREAM.

Tôi không chắc nếu bạn có nghĩa là tệp nhật ký quá lớn hoặc sao lưu tệp nhật ký trở nên quá lớn.

Nếu đó là trước đây thì bạn có thường xuyên sao lưu đăng nhập không? Tùy thuộc vào thiết kế ứng dụng, bạn có thể giảm kích thước bằng cách sao lưu thường xuyên hơn (và cứ sau 5 phút là không quá thường xuyên). Tuy nhiên nếu bạn đã làm điều đó và nó vẫn đang phình to thì có lẽ bạn đã hết may mắn. Tại sao tệp nhật ký lớn lại là một vấn đề?

Nếu đó là cái thứ hai - có vẻ như bạn rất vui khi tiếp tục với mô hình khôi phục đơn giản và không có thời gian khôi phục nếu nó cho phép bạn có các bản sao lưu nhỏ hơn; trong trường hợp đó ở chế độ đầy đủ và loại bỏ các bản sao lưu nhật ký của bạn.


Tôi đã không nhận ra các bản sao lưu nhật ký thường không phổ biến! "Tại sao tệp nhật ký lớn lại gặp sự cố?" câu hỏi thực sự khiến tôi suy nghĩ về điều đó và tôi đã không có câu trả lời. Vì vậy, +100 cho bạn!
David Murdoch

3

Một giải pháp cho cơ sở dữ liệu được đặt ở chế độ khôi phục SIMPLE đang có dữ liệu FILESTREAM trong nhóm tệp chỉ đọc (không phải là tùy chọn lý tưởng của bạn), và sau đó chỉ sao lưu các nhóm tệp đọc / ghi với DIFFERENTIAL như thế này:

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

Nó sẽ nhận được bất kỳ dữ liệu nào đã thay đổi trong bất kỳ nhóm fileg đọc / ghi nào. Đó là cách dễ nhất, vượt trội, mà bạn có thể quản lý các bản sao lưu một phần mà không cần lấy dữ liệu FILESTREAM. Tuy nhiên, sẽ yêu cầu quá trình tải dữ liệu nói trên sẽ cần phải sửa đổi nhóm tệp thành đọc / ghi, tải bất kỳ dữ liệu bổ sung nào và sau đó được đặt thành chỉ đọc lại. Chắc chắn không lý tưởng.


Điều này sẽ là hoàn hảo nếu hệ thống tự động của chúng tôi được thiết kế để đối phó với việc LẬP TỨC đôi khi S READN SÀNG. Thật không may, việc tái cấu trúc tất cả các dịch vụ sẽ mất quá nhiều thời gian, đặc biệt là vì chúng ta có thể ném các ổ cứng vào vấn đề ngay bây giờ. Nhờ có bạn, trong tương lai, tất cả các dịch vụ mới sẽ được thiết kế với mục đích này và kế hoạch cập nhật các dịch vụ cũ theo thời gian có hiệu lực. (Tôi ước tôi có thể thưởng cho bạn một nửa số tiền thưởng!
David Murdoch

2

Tôi cảm thấy bẩn khi cung cấp tùy chọn này, nhưng nếu bạn chọn cách ly dữ liệu FILESTREAM vào cơ sở dữ liệu của riêng mình, bạn có thể duy trì RI giữa các bảng trong các dbs riêng biệt bằng cách kích hoạt :

Kích hoạt -> Nhận xét -> Hạn chế:
Một trình kích hoạt chỉ được tạo trong cơ sở dữ liệu hiện tại; tuy nhiên, một kích hoạt có thể tham chiếu các đối tượng bên ngoài cơ sở dữ liệu hiện tại.

Mong đợi các vấn đề về hiệu suất và một phần da đầu của bạn trở nên không có lông sau khi nhổ tóc búi đầu trong sự thất vọng, nhưng về mặt lý thuyết bạn có thể làm điều này. Tôi không khuyến nghị phương pháp này ở bất kỳ cấp độ nào, thay vào đó tôi thực sự khuyên bạn nên tăng tần suất sao lưu tlog và / hoặc chuyển sang mô hình khôi phục được ghi nhật ký hàng loạt và xem bạn tiết kiệm được bao nhiêu dung lượng, NHƯNG đây là một giải pháp khả thi. Thực sự bạn cần cân nhắc lợi ích của việc tách dữ liệu này và xử lý thiết kế cơ sở dữ liệu của Frankenstein, nhưng đó là một lựa chọn.

... Tôi phải đi tắm bây giờ ...


1

Tôi biết câu hỏi này đã được trả lời, nhưng có một giải pháp khác có thể giúp đỡ người khác. Gần đây tôi đã học được từ blog của Brent Ozar rằng có một tùy chọn để loại bỏ các bản sao lưu nhật ký của bạn ngay lập tức:

BACKUP LOG MyDb TO DISK='NUL:'

Vì vậy, bạn có thể để cơ sở dữ liệu của mình ở FullChế độ khôi phục và thực hiện sao lưu các nhóm fileg. Khi nhật ký giao dịch của bạn quá lớn, sau đó chỉ cần đưa ra lệnh nhật ký dự phòng và bạn đã hoàn tất.


Tôi vẫn khuyên bạn nên sao lưu nhật ký hoạt động như một công việc được lên lịch, để đảm bảo rằng hoạt động không mong muốn không làm tăng kích thước tệp nhật ký một cách vô lý.
RDFozz
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.