Tôi có nên di chuyển dữ liệu bằng cách sử dụng tách / sao chép / đính kèm hoặc thông qua sao lưu-khôi phục-phát lại?


17

Tôi sắp bắt tay vào việc di chuyển các tệp cơ sở dữ liệu sang SAN mới (từ SAN cũ) abd Tôi có một vài tùy chọn để thực hiện việc này. (1) Có ý kiến ​​cho rằng tôi xem xét mức độ nỗ lực khôi phục bản sao lưu đầy đủ vào cơ sở dữ liệu mới trên máy chủ. Tuy nhiên, (2) kế hoạch ban đầu của tôi là sao chép các tệp từ SAN cũ sang SAN mới bằng cách tách ra và sau đó gắn lại cơ sở dữ liệu.

Ruột của tôi nói với tôi rằng tôi muốn tách ra, sao chép và đính kèm vì nó có vẻ không an toàn hơn, nhưng đó có thể chỉ là sự ngây thơ của tôi. Tôi không muốn bỏ lỡ một giao dịch hoặc bằng cách nào đó "phá vỡ một cái gì đó" trong quá trình đổi tên cơ sở dữ liệu.

Tôi đoán câu hỏi của tôi là liệu tôi có hợp lý trong sự hoài nghi của tôi về tùy chọn BACKUP-RESTORE-Replay không và những lợi ích hay rủi ro khác của tùy chọn đó là gì?

Câu trả lời:


16

Cá nhân, tôi sẽ tránh các cơ chế tách / đính kèm. Đặc biệt trong SQL Server 2000, tôi không tin tưởng rằng bạn sẽ luôn mang máy chủ sao lưu và có thể đính kèm các tệp đó. Tôi đã nghe rất nhiều câu chuyện trong đó điều này không xảy ra một cách sạch sẽ - chỉ vì bạn có Kế hoạch B không tự động làm cho Kế hoạch A trở nên hợp lý.

Với sao lưu / khôi phục, bạn không có nguy cơ phải vào Kế hoạch B. Nếu sao lưu thất bại, cơ sở dữ liệu của bạn vẫn hoạt động. Nếu khôi phục thất bại, cơ sở dữ liệu cũ của bạn vẫn còn. Trong cả hai trường hợp, bạn có thể khôi phục hoạt động của cơ sở dữ liệu gốc và xem lại kế hoạch sau. Ngoài việc bảo mật thêm ở đây khi dừng SQL Server và / hoặc tách ra, điều này cũng có nghĩa là bạn có thể kiểm tra phương pháp sao lưu / khôi phục (giả sử bạn hiện có không gian để thực hiện sao lưu và một trường hợp khác để kiểm tra khôi phục). Bạn thực sự không thể kiểm tra phương pháp tách rời mà không tách rời cơ sở dữ liệu hoặc dừng SQL Server và điều đó khó thực hiện ngoài cửa sổ bảo trì thích hợp. Và cuối cùng, với các cách tiếp cận khác, bạn thậm chí không thể bắt đầu sao chép các tệp cho đến khi bạn tách ra hoặc đưa SQL Server xuống.

Một lợi ích khác so với phương pháp pull-the-drive-out-from-under-SQL-Server: với sao lưu / khôi phục, bạn có thể di chuyển các tệp khác nhau sang các ký tự ổ đĩa khác với trước đây. Ví dụ: khi chúng tôi di chuyển sang SAN mới, chúng tôi có thể có nhiều khối lượng hơn, vì vậy chúng tôi có thể di chuyển tempdb sang T: \ (trước đây không tồn tại), một số dữ liệu và tệp nhật ký sang ký tự ổ đĩa mới, v.v. để sử dụng tốt hơn tất cả năng lực I / O mới mà chúng tôi có. Nếu bạn chỉ cần tắt SQL Server và sau đó trao đổi các đĩa, bạn cần phải có cùng tên ổ đĩa và cùng số lượng ổ đĩa.


7

Tôi đã sử dụng để di chuyển cơ sở dữ liệu gần như liên tục, do cấu hình lại và di chuyển SAN.

Giả sử rằng bạn đang di chuyển toàn bộ máy chủ tại một thời điểm, tôi sẽ đi với một cái gì đó giống như đường dẫn số 2 của bạn. (Nếu bạn đang di chuyển một cơ sở dữ liệu tại một thời điểm và cuối cùng thực hiện mọi cơ sở dữ liệu trên máy chủ, điều đó sẽ gặp nhiều vấn đề hơn vì bạn sẽ phải thay đổi đường dẫn đến các tệp.)

Lưu ý rằng "single_user" không nhất thiết có nghĩa là BẠN. Bạn có thể truy cập DBCC CHECKDB một cơ sở dữ liệu và không thể truy cập được vì đã có người ở đó. Chuẩn bị một tập lệnh mà bạn có thể chạy để khởi động "mọi người trừ bạn" ra khỏi cơ sở dữ liệu và giữ nó ở nơi thuận tiện. Lưu ý rằng SQL 2000 không có các tính năng "tránh xa mọi người" giống như các phiên bản hiện đại hơn.

Một mẹo cũ là tạm dừng dịch vụ SQL Server. Điều này sẽ ngăn đăng nhập mới, nhưng bất kỳ ai đã kết nối đều có thể tiếp tục như bình thường. Vì vậy: kết nối qua cửa sổ SSMS để bạn có thể thực hiện công việc, sau đó tạm dừng dịch vụ, sau đó loại bỏ các kết nối không mong muốn, thực hiện công việc của bạn thông qua cửa sổ lệnh SSMS (không phải GUI, nó tạo và ngắt nhiều kết nối) và sau đó tạm dừng dịch vụ. Cảnh báo: Tôi không chắc điều đó sẽ diễn ra như thế nào trên một cụm. Nó có thể muốn chuyển đổi dự phòng.

Thật tiện lợi khi có một cách để giữ tất cả người dùng ứng dụng ra khỏi máy chủ cho đến khi bạn hoàn thành công việc của mình. Mặt khác, các kết nối có thể bắt đầu bật lên trong khi bạn đang cố gắng thực hiện, điều này có thể dẫn đến tranh chấp tài nguyên và / hoặc chậm. Tôi đã sử dụng các cách sau trong quá khứ, tùy thuộc vào tình huống chính xác: Tắt (các) máy chủ ứng dụng Sử dụng ALTER DATABASE .. SET RESTRICTED_USER (Nếu tài khoản ứng dụng là thành viên của vai trò db_owner, sysadmin hoặc dbcreator, thì đó là một vấn đề. ) Nói với người dùng rằng hệ thống sẽ ngoại tuyến vào một số thời điểm cụ thể, như một buổi sáng Chủ nhật. (Điều này sẽ không hoạt động trong môi trường 24x7 "thực sự".) Rút phích cắm NIC đối diện với máy chủ ứng dụng hoặc người dùng. (Trong trường hợp này, tôi có thể truy cập thông qua một NIC khác được kết nối với mạng chỉ dành cho quản trị viên hoặc thông qua ILO.)

Việc tách một số lượng lớn các cơ sở dữ liệu và gắn lại chúng có thể là rất nhiều công việc. Nếu bạn làm điều đó, hãy chắc chắn rằng bạn có tập lệnh "đính kèm" được viết trước thời hạn.

Tôi đã thành công trong việc dừng SQL Server, sao chép mọi thứ, thay đổi ký tự ổ đĩa và khởi động SQL Server. Không tách / đính kèm. Miễn là SQL Server tắt và bạn đang sao chép các tệp (không phải MOVING), bạn không thể gặp quá nhiều rắc rối, ngay cả khi bạn đang di chuyển cơ sở dữ liệu hệ thống. Vì các đường dẫn là như nhau, SQL Server sẽ không nhận ra bất cứ điều gì đã thay đổi trong khi dịch vụ bị tắt. Chỉ cần đảm bảo rằng bạn nhận được các ký tự ổ đĩa quay lại đúng khối lượng hoặc mọi thứ sẽ trở nên tồi tệ cho bạn.

Vấn đề thường gặp nhất của tôi là không nhận được ACL trên các thư mục tệp chính xác. Các phiên bản SQL Server hiện đại hơn sẽ tốt hơn khi chỉ thiết lập các quyền mà tài khoản dịch vụ cần trong khi các phiên bản cũ có vẻ ít cầu kỳ hơn. Nếu bạn quên đặt ACL và tài khoản dịch vụ không phải là quản trị viên cục bộ (không phải tôi khuyên bạn nên như vậy), một hoặc nhiều cơ sở dữ liệu có thể không mở khi phiên bản bắt đầu. Đừng hoảng sợ, chỉ cần thay đổi ACL và đính kèm cơ sở dữ liệu.

Tôi thường sử dụng ROBOCOPY để thực hiện công việc này. Có một công tắc dòng lệnh để bảo toàn ACL.

Sử dụng tính toán / xác minh CRC không phải là ý tưởng tồi, nhưng tôi chưa bao giờ thực hiện điều đó. Khi cơ sở dữ liệu hoạt động trở lại, tôi chạy CHECKDB () trên tất cả chúng. Tôi thường sẽ chuẩn bị một kịch bản cho việc này trước thời hạn, thay vì dựa vào việc tự khởi động một công việc bảo trì. Bằng cách đó, tôi có thể kiểm tra một vài cơ sở dữ liệu nhỏ hơn trước khi kiểm tra một cơ sở dữ liệu lớn có thể mất nhiều phút hoặc nhiều giờ để chạy. Tôi nghi ngờ rằng kiểm tra CRC (hoặc công cụ So sánh dữ liệu Redgate) sẽ tìm thấy thứ gì đó mà CHECKDB () sẽ bỏ lỡ và nếu SQL Server không thể sửa nó.

Sau khi tôi sao chép các tệp, nhưng trước khi tôi khởi động lại thể hiện, tôi sẽ đi và thay đổi một chút filepath của các thư mục OLD bằng cách đổi tên một trong các thư mục. Đây là một kiểm tra bổ sung đối với vấn đề "rất tiếc, máy chủ vẫn đang chỉ đến các tệp cũ".

Đừng vội vứt các tệp cũ và khôi phục dung lượng lưu trữ cũ và đảm bảo nhân đôi rằng các bản sao lưu đầy đủ của bạn đã chạy thành công. Kiểm tra khôi phục một vài trong số các bản sao lưu đó vào một nơi khác. Khi bạn đã chạy checkdb () tốt và sao lưu toàn bộ tốt, thì bạn có thể nghĩ đến việc bỏ bộ nhớ cũ đó và tắt Lefthand.

Những vấn đề tồi tệ nhất tôi gặp phải với những cuộc di cư này đã xảy ra sau khi tôi nghĩ rằng mình đã xong. Đó sẽ là quản trị viên SAN nói với tôi rằng đã có chuyện gì đó xảy ra và hệ thống tệp của tôi bị xáo trộn. (Phân vùng lại, định dạng lại, sao chép lại.)

Một vấn đề thú vị khác là SAN bị chậm mà không có lý do rõ ràng. Nếu bạn nghĩ rằng sẽ mất 10 giờ để sao chép dữ liệu của bạn và bạn được sao chép 30% vào giờ số 9, bạn có vấn đề. Xem thời gian chuyển (bản sao hiển thị% được sao chép và đưa ra ước tính thời gian, hoặc bạn có thể sử dụng Perfmon) và có kế hoạch dự phòng nếu có gì đó tồi tệ hơn.

Ngoài ra, tôi không chắc liệu khối lượng của bạn sẽ được phân vùng cho bạn hay không, nhưng bạn có thể muốn chắc chắn rằng họ đang sử dụng mức bù 1 MB. Trên Windows Server 2008 và tốt hơn, đây không phải là vấn đề. Trên hệ điều hành cũ, nó là. Có rất nhiều thứ có thể hiểu được về điều này, và những người lưu trữ của bạn nên biết về nó, nhưng tôi sẽ hỏi.


2

Đầu tiên tôi sẽ xem xét tùy chọn chỉ đơn giản là sử dụng tính năng của mảng lưu trữ để xử lý việc di chuyển dữ liệu. Nếu những thứ đó không có sẵn bởi vì nhà cung cấp không hỗ trợ nó, thì bạn đã không mua nó, hoặc quản trị viên SAN không biết làm thế nào ...

Sau đó, tôi chỉ cần sử dụng các bước sau.

  1. Trình bày bộ lưu trữ mới cho SQL Server.
  2. Dừng dịch vụ SQL
  3. SAO CHÉP tất cả dữ liệu từ ổ đĩa cũ sang ổ đĩa mới (đừng quên bao gồm các quyền nếu sử dụng bản sao)
  4. Loại bỏ các ký tự ổ đĩa từ các ổ đĩa cũ.
  5. Thay đổi ký tự ổ đĩa trên các ổ đĩa mới để khớp với các ký tự ổ đĩa cũ
  6. Bắt đầu dịch vụ SQL

Đó là nó.

Không có tách / đính kèm cần thiết, theo như SQL Server biết không có gì thay đổi. Và nếu có gì đó không ổn, bạn đã có bản sao cũ của cơ sở dữ liệu trên LUN cũ trên mảng lưu trữ cũ. Thất bại trở lại chỉ là một vấn đề thay đổi các ký tự ổ đĩa xung quanh.

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.