Khi thời gian trôi qua, nhiều công ty đang chuyển sang hoặc ít nhất là đánh giá Cơ sở dữ liệu Azure SQL như một giải pháp thay thế cho chi phí cao của việc chạy SQL Server tại chỗ.
Kiểm tra khả năng tương thích
Một trong những khía cạnh đầu tiên của việc di chuyển cơ sở dữ liệu của bạn sang Cơ sở dữ liệu Azure SQL là kiểm tra tính tương thích và Microsoft cung cấp cho bạn rất nhiều cách thực hiện việc này cho Cơ sở dữ liệu Azure SQL V12 (sau đây được gọi là 'V12'). Một trong những phương pháp này là sử dụng Công cụ dữ liệu SQL Server cho Visual Studio (SSDT) sử dụng các quy tắc tương thích gần đây nhất để phát hiện sự không tương thích V12. Trong SSDT, bạn có thể nhập lược đồ cơ sở dữ liệu của mình và xây dựng dự án để triển khai V12 và nếu tìm thấy bất kỳ điểm không tương thích nào, chúng có thể được sửa trong SSDT và sau đó được đồng bộ hóa trở lại cơ sở dữ liệu nguồn.
Bạn cũng có thể sử dụng công cụ dòng lệnh có tên SqlPackage có thể tạo báo cáo về các vấn đề tương thích (và luôn đảm bảo rằng bạn có phiên bản mới nhất). SQL Server Management Studio là một cách thực hiện khác, sử dụng tính năng Export Data-tier Application, tính năng này có thể phát hiện và báo cáo lỗi ra màn hình. Nếu không có lỗi nào được phát hiện, bạn có thể di chuyển cơ sở dữ liệu của mình sang V12. Nếu phát hiện thấy các điểm không tương thích, chúng có thể được sửa bằng SSMS trước khi di chuyển.
Hỗ trợ di chuyển dữ liệu là một công cụ độc lập (dễ bị nhầm lẫn với Hỗ trợ di chuyển máy chủ SQL) có thể được sử dụng để giúp giảm nỗ lực nâng cấp và thay thế Bản xem trước cố vấn nâng cấp SQL Server 2016. DMA cũng có thể đề xuất các cải tiến về hiệu suất và độ tin cậy. Một công cụ khác, SQL Azure Migration Wizard (SAMW), là một công cụ Codeplex sử dụng các quy tắc tương thích của Cơ sở dữ liệu Azure SQL V11 để phát hiện sự không tương thích của V12. SAMW cũng có thể hoàn tất quá trình di chuyển sang V12 và khắc phục một số vấn đề về khả năng tương thích. Một điều cần lưu ý khi sử dụng SAMW là nó có thể phát hiện các điểm không tương thích không cần sửa.
Dữ liệu di chuyển
Khi cơ sở dữ liệu của bạn đã vượt qua kiểm tra tính tương thích, bạn phải xác định phương pháp tốt nhất để di chuyển. Một số phương pháp phổ biến hơn bao gồm sử dụng Trình hướng dẫn di chuyển SSMS, xuất sang BACPAC, sử dụng sao chép giao dịch hoặc viết kịch bản cho cơ sở dữ liệu và chèn dữ liệu của bạn theo cách thủ công.
Sử dụng Trình hướng dẫn di chuyển SSMS là rất tốt cho SQL Server 2005 và các cơ sở dữ liệu có kích thước nhỏ đến trung bình. Bạn có thể kích hoạt trình hướng dẫn này trong SSMS 2016, bằng cách nhấp chuột phải vào cơ sở dữ liệu, chọn Nhiệm vụ, sau đó Triển khai Cơ sở dữ liệu lên Cơ sở dữ liệu Microsoft Azure SQL. Trong SSMS 2014, nó được gọi là Triển khai Cơ sở dữ liệu lên Cơ sở dữ liệu SQL của Windows Azure. Sử dụng trình hướng dẫn này cho phép bạn chỉ định cơ sở dữ liệu để di chuyển, kết nối với đăng ký Azure của bạn, chọn vị trí cho tệp .bacpac, tên cơ sở dữ liệu mới và cấp để di chuyển đến. Khi bạn nhấp vào kết thúc, trình hướng dẫn sẽ trích xuất và xác thực lược đồ, sau đó xuất dữ liệu. Sau khi dữ liệu được xuất, nó sẽ tạo một kế hoạch triển khai và bắt đầu nhập dữ liệu vào cơ sở dữ liệu V12 mới.
Rất giống với Trình hướng dẫn di chuyển SSMS là Ứng dụng tầng dữ liệu xuất. Để chọn tùy chọn này, hãy nhấp chuột phải vào cơ sở dữ liệu, chọn Nhiệm vụ, sau đó Xuất Ứng dụng cấp dữ liệu. Trong cài đặt xuất, bạn chỉ định nơi bạn muốn tạo tệp .bacpac. Bạn có thể lưu tệp này cục bộ hoặc lưu trực tiếp vào tài khoản lưu trữ Azure của mình. Ngoài ra còn có một tab nâng cao, nơi bạn có thể chọn những bảng cần đưa vào. Điều này rất hữu ích nếu cơ sở dữ liệu cục bộ của bạn chứa các bản sao của bảng mà bạn không muốn chuyển sang V12. Khi bạn chọn Hoàn tất, nó sẽ xuất dữ liệu của bạn. Sau đó, bạn có thể kết nối với máy chủ Azure của mình thông qua SSMS và chọn Nhập ứng dụng cấp dữ liệu. Bạn sẽ chỉ định vị trí của tệp, tên cơ sở dữ liệu và cấp của Cơ sở dữ liệu Azure SQL. Khi bạn chọn kết thúc, cơ sở dữ liệu sẽ bắt đầu nhập. Phương pháp này cho phép bạn kiểm soát nhiều hơn một chút đối với quy trình vì nó tách biệt việc xuất và nhập. Nó cũng cung cấp cho bạn tùy chọn lưu trữ tệp .bacpac trong tài khoản lưu trữ Azure của bạn để quá trình nhập dễ bị tấn công hơn sẽ không phụ thuộc vào kết nối internet của bạn.
Một tùy chọn khi sử dụng Trình hướng dẫn di chuyển SSMS hoặc Ứng dụng tầng dữ liệu xuất, là tạo một máy ảo Azure với SQL Server và thiết lập vận chuyển nhật ký. Thao tác này sẽ tạo trước cơ sở dữ liệu của bạn trong đám mây Azure để giúp giảm thiểu thời gian nhập cơ sở dữ liệu. Khi đến lúc thực hiện di chuyển, bạn chỉ cần khôi phục các bản sao lưu nhật ký cuối cùng trên thiết bị phụ và sau đó xóa vận chuyển nhật ký. Để đưa cơ sở dữ liệu trực tuyến, hãy thực hiện khôi phục bằng recovery. Điều này về cơ bản sẽ loại bỏ thời gian sao chép cơ sở dữ liệu của bạn từ trung tâm dữ liệu của bạn vào trung tâm dữ liệu Azure.
Sao chép giao dịch là một phương pháp khác để giúp giảm thời gian chết khi chuyển sang V12. Đó là lựa chọn tốt nhất nếu bạn có một cửa sổ bảo trì cực kỳ nhỏ để chuyển sang V12, nếu cơ sở dữ liệu có thể hỗ trợ sao chép giao dịch. Việc thiết lập sao chép giao dịch yêu cầu các khóa chính cho mỗi bảng đã xuất bản, điều này có thể gây khó khăn cho nhiều cơ sở dữ liệu. Việc định cấu hình sao chép giao dịch cũng có thể phức tạp, vì bạn phải thiết lập cơ sở dữ liệu phân phối, thiết lập nhà xuất bản và người đăng ký cũng như theo dõi công việc.
Bạn cũng có thể di chuyển theo cách thủ công bằng cách sử dụng trình hướng dẫn Tạo tập lệnh và viết kịch bản ra lược đồ cơ sở dữ liệu và / hoặc dữ liệu. Sau đó, bạn có thể tạo cơ sở dữ liệu trống trong Azure và nhập lược đồ và hoặc dữ liệu của mình bằng cách thực thi tập lệnh. Tôi đã nghe nói về một số người sử dụng phương pháp này để tạo cơ sở dữ liệu trống và sau đó chèn dữ liệu của họ vào một bảng theo cách thủ công tại một thời điểm bằng cách sử dụng SSMS và một máy chủ được liên kết. Phương pháp này có thể phù hợp với bạn, nhưng cũng có thể rất phức tạp nếu bạn có nhiều cấu trúc lược đồ như mối quan hệ khóa ngoại và cột nhận dạng, trong trường hợp đó, các phương pháp khác ở trên sẽ đáng tin cậy và hiệu quả hơn.
Những vấn đề cần cân nhắc khi di chuyển khác
Khi lập kế hoạch di chuyển cơ sở dữ liệu trên cơ sở sang V12, kích thước của cơ sở dữ liệu là một yếu tố rất lớn trong việc di chuyển sẽ mất bao lâu. Việc xuất cơ sở dữ liệu, chuyển dữ liệu và nhập đều sẽ tăng tương ứng với kích thước của cơ sở dữ liệu.
Một yếu tố quan trọng khác trong thời gian khôi phục / nhập khi di chuyển cơ sở dữ liệu của bạn sang V12 là cấp hiệu suất bạn cũng đang khôi phục. Quá trình khôi phục / nhập yêu cầu rất nhiều mã lực, vì vậy để giúp đẩy nhanh quá trình di chuyển của bạn, bạn nên xem xét khôi phục lên cấp hiệu suất cao hơn. Khi cơ sở dữ liệu trực tuyến, bạn có thể dễ dàng và nhanh chóng thả xuống cấp thấp hơn đáp ứng nhu cầu hiệu suất hàng ngày của bạn. Có thể thay đổi các cấp hiệu suất bằng một vài cú nhấp chuột là một trong những lợi ích lớn của Cơ sở dữ liệu Azure SQL.
Giám sát
Một phần quan trọng của việc quản trị bất kỳ cơ sở dữ liệu nào là giám sát. Nếu bạn không giám sát một cái gì đó, bạn không thể đo lường nó. Nếu bạn không biết chỉ số của mình là gì khi mọi thứ đang hoạt động bình thường, làm thế nào bạn biết được điều nào tồi tệ hơn khi hiệu suất bị suy giảm? Với cơ sở dữ liệu tại chỗ, chúng ta có các công cụ mà chúng ta quen thuộc:SQL Server Management Studio, Performance Monitor, Task Manager, DMV, v.v. Khi chúng tôi chuyển cơ sở dữ liệu của mình sang V12, chúng tôi sẽ mất khả năng giám sát từ góc độ hệ điều hành và các khái niệm khác cũng thay đổi một chút. Bây giờ chúng tôi có số liệu này được gọi là DTU để làm việc, viết tắt của Đơn vị giao dịch cơ sở dữ liệu. Hãy nghĩ về nó như một sự kết hợp của CPU, dữ liệu và I / O nhật ký giao dịch và bộ nhớ. Azure Portal bao gồm một biểu đồ giám sát được mặc định kiểm tra tỷ lệ phần trăm DTU và bạn có thể chỉnh sửa biểu đồ này để bao gồm các số liệu bổ sung, chẳng hạn như:
- Bị chặn bởi Tường lửa
- % CPU
- Giới hạn DTU
- DTU được sử dụng
- Dữ liệu I / O%
- Kích thước cơ sở dữ liệu%
- Bế tắc
- Kết nối không thành công
- Bộ nhớ OLTP trong bộ nhớ%
(xem trước)
- Ghi nhật ký I / O%
- Số phiên%
- Kết nối thành công
- Tổng kích thước cơ sở dữ liệu
- Công nhân%
Ở mức tối thiểu, tôi sẽ thêm tỷ lệ phần trăm CPU, tỷ lệ phần trăm I / O dữ liệu, số lần bế tắc và tỷ lệ phần trăm kích thước cơ sở dữ liệu. Hiện tại, biểu đồ này hiển thị giờ sử dụng tài nguyên trước đó.
Việc giám sát bởi các DMV không có nhiều thay đổi, ngoài việc có một vài DMV mới liên quan đến các chỉ số cơ sở dữ liệu riêng lẻ và cách tính toán kích thước cơ sở dữ liệu. Một trong những bài viết trước đây của tôi ở đây, Bắt đầu điều chỉnh Hiệu suất trong Cơ sở dữ liệu Azure SQL, đề cập đến một số điểm khác biệt trong các tập lệnh phổ biến được sử dụng để thu thập độ trễ đĩa và số liệu thống kê chờ liên quan đến Cơ sở dữ liệu Azure SQL.
Các công cụ của bên thứ ba cũng đã bắt đầu bao gồm các móc vào Cơ sở dữ liệu Azure SQL, chẳng hạn như SentryOne với DB Sentry. DB Sentry cung cấp cho bạn khả năng giám sát hiệu suất và quản lý các sự kiện đang xảy ra trong hệ thống của bạn. Một tính năng thú vị là hàm Top SQL cho phép bạn xem các truy vấn có tác động nhiều nhất đến hiệu suất tổng thể của bạn để bạn có thể điều chỉnh / khắc phục bất kỳ vấn đề nào với truy vấn đó. Một cách khác là lập biểu đồ DTU theo thời gian và hiển thị điều đó trên trang tổng quan cùng với các số liệu quan trọng khác.
 SQL hàng đầu trong máy khách SentryOne |  Sử dụng DTU trên Bảng điều khiển DB Sentry |
Các chỉ số này được lưu trữ trong cơ sở dữ liệu chuyên dụng, cung cấp cho bạn khả năng xác định đường cơ sở và xu hướng theo hiệu suất theo thời gian, tốt hơn nhiều so với các biểu đồ hạn chế mà bạn hiện nhận được trong Azure Portal.
Tóm tắt
Có nhiều lợi ích khi di chuyển sang Cơ sở dữ liệu Azure SQL V12, nếu cơ sở dữ liệu của bạn tương thích, vì vậy hãy tận dụng một trong những công cụ có sẵn để kiểm tra khả năng tương thích của bạn với V12. Nếu cơ sở dữ liệu của bạn tương thích hoặc có thể dễ dàng sửa đổi để trở nên tương thích, thì bạn có thể dễ dàng chuyển sang Cơ sở dữ liệu Azure SQL V12 và bắt đầu thử nghiệm cũng như đánh giá điểm chuẩn các ứng dụng và khối lượng công việc của mình.
