Di chuyển cơ sở dữ liệu SQL Server sang đĩa mới khi trực tuyến

Tôi có Cơ sở dữ liệu SQL Server 1,4TB đang vật lộn ồ ạt với I / O đĩa. Chúng tôi đã cài đặt một mảng SSD mới vào máy chủ sẽ giải quyết tất cả các vấn đề của chúng tôi, chúng tôi chỉ đang tranh luận về cách tốt nhất để di chuyển cơ sở dữ liệu. Lý tưởng nhất là chúng ta có thể làm điều đó mà không có thời gian chết, đó là tốt nhất. Nhưng trong trường hợp lựa chọn là giữa hai ngày hoạt động kém (ví dụ như trong khi sao chép dữ liệu) so với hai giờ ngừng hoạt động, thì lựa chọn sau có thể tốt hơn.

Cho đến nay, các giải pháp chúng tôi đưa ra là:

• Bản sao đơn giản. Lấy DB ngoại tuyến, sao chép các tệp qua, thay đổi vị trí trong SQL Server và đưa nó trở lại trực tuyến. Số liệu thô ước tính việc này sẽ mất tới năm giờ, điều này không thực sự chấp nhận được, nhưng đó là giải pháp dễ nhất.

• Bản sao cấp khối. Sử dụng tiện ích giống như rsync, chúng tôi sao chép các tệp trên nền trong khi DB hoạt động. Khi chúng tôi sẵn sàng di chuyển, chúng tôi đưa DB ngoại tuyến, tạo một bản sao vi sai bằng cách sử dụng tiện ích này, sau đó trỏ máy chủ SQL vào các tệp mới và đưa nó trực tuyến. Thời gian ở đây là không rõ. Chúng tôi không biết sẽ mất bao lâu để phân tích chênh lệch 1,4TB và sao chép nó qua. Mối quan tâm khác của chúng tôi là bản sao ở cấp độ khối sẽ khiến các tệp ở trạng thái không thể đọc được bởi SQL Server và chúng tôi sẽ lãng phí thời gian của chúng tôi.

• Di chuyển SQL. Tạo một tệp dữ liệu SQL 1,4TB mới trên đĩa mới và vô hiệu hóa tự động phát trên tất cả các tệp khác. Sau đó, lần lượt chạy DBBC SHRINKFILE (-file_name-, EMPTYFILE) trên tất cả các tệp dữ liệu khác. Khi tất cả dữ liệu đã được xử lý, tôi sẽ lấy một cửa sổ được lên lịch tại một thời điểm nào đó để di chuyển tệp MDF sang SSD và xóa các tệp không sử dụng khác. Tôi thích điều này vì nó giảm thiểu thời gian chết. Nhưng tôi không biết điều này sẽ kéo dài bao lâu và liệu nó có gây ra sự suy giảm hiệu suất trong khi nó đang diễn ra hay không.

Chúng tôi không có bất kỳ loại môi trường tải & hiệu suất nào để kiểm tra điều này. Tôi có thể xác minh rằng các chiến lược sẽ hoạt động trên môi trường dàn dựng của chúng tôi, nhưng không ảnh hưởng và không phải là hiệu suất.

Một phương pháp để di chuyển toàn bộ cơ sở dữ liệu là với BACKUPvà RESTORE. Cơ sở dữ liệu sẽ không có sẵn trong lần chuyển đổi cuối cùng nhưng thời gian chết nên tối thiểu với kế hoạch. Quy trình này giả định FULLhoặc BULK_LOGGEDmô hình phục hồi:

1) Thực hiện sao lưu ĐẦY ĐỦ (hoặc sử dụng bản sao lưu hiện có của bạn).

2) Khôi phục bản sao lưu đầy đủ mới nhất sang một tên cơ sở dữ liệu khác, chỉ định WITH MOVEtùy chọn di chuyển các tệp trên bộ lưu trữ SSD theo ý muốn và NORECOVERYtùy chọn để có thể khôi phục các bản sao lưu và nhật ký khác biệt tiếp theo.

3) Áp dụng các thay đổi gia tăng cho cơ sở dữ liệu mới cho đến thời điểm cắt giảm cuối cùng với các bản sao lưu nhật ký giao dịch và RESTORE...WITH NORECOVERY. Điều này sẽ giảm thiểu thời gian chết cho việc chuyển đổi cuối cùng sang cơ sở dữ liệu mới.

4) Để chuyển sang cơ sở dữ liệu mới, hãy đưa ứng dụng ngoại tuyến, thực hiện sao lưu nhật ký giao dịch cuối cùng và áp dụng cho cơ sở dữ liệu mới WITH RECOVERY. Cuối cùng, đổi tên cơ sở dữ liệu ban đầu thành một tên khác và đổi tên cơ sở dữ liệu được di dời thành tên ban đầu. Bỏ cơ sở dữ liệu cũ một cách thuận tiện.

Trong mô hình khôi phục SIMPLE, bạn có thể sử dụng một quy trình tương tự nhưng không có bản sao lưu / khôi phục nhật ký giao dịch bước 3. Thay vào đó, sử dụng sao lưu / khôi phục cơ sở dữ liệu khác biệt trong bước cuối cùng. Điều đó có thể yêu cầu nhiều thời gian chết hơn, tùy thuộc vào số lượng thay đổi kể từ lần FULLsao lưu ban đầu .

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.