Quay trở lại tháng 8 năm 2015, tôi đã viết một bài báo giới thiệu tính năng Stretch Database mới trong SQL Server 2016. Trong bài viết đó, tôi đã thảo luận về cách bắt đầu với Stretch Database trong SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 được phát hành vào ngày 1 tháng 6 năm 2016 và đã có nhiều bản cập nhật cho sản phẩm. Phương pháp thiết lập Cơ sở dữ liệu Stretch đã thay đổi một chút cũng như một số tính năng.
Bắt đầu với SQL Server 2016, chúng tôi đã có được khả năng lưu trữ các phần của cơ sở dữ liệu trong Cơ sở dữ liệu Azure SQL. Trong các bản xem trước trước đó khi bạn bật tính năng Kéo dài cho cơ sở dữ liệu, bạn phải di chuyển toàn bộ bảng, với bản phát hành RTM của SQL Server 2016, giờ đây bạn có thể chọn một phần của bảng. Sau khi bạn bật tính năng kéo giãn cho một bảng, nó sẽ tự động di chuyển dữ liệu của bạn. Nếu bạn không quen thuộc với Cơ sở dữ liệu Stretch, nó sẽ tận dụng sức mạnh xử lý trong Azure để chạy các truy vấn đối với dữ liệu từ xa bằng cách viết lại truy vấn. Bạn không phải viết lại bất kỳ truy vấn nào. Bạn sẽ thấy đây là toán tử “truy vấn từ xa” trong kế hoạch truy vấn.
Một cách dễ dàng để xác định cơ sở dữ liệu và bảng đủ điều kiện để được kích hoạt Stretch là tải xuống và chạy Trình tư vấn nâng cấp SQL Server 2016 và chạy Trình tư vấn cơ sở dữ liệu Stretch. Aaron Bertrand (@AaronBertrand) đã viết về điều này một thời gian trở lại. Cố vấn nâng cấp đã thay đổi một chút kể từ khi Aaron đăng bài, tuy nhiên, quá trình này hầu như giống nhau:
- Xác định Bảng Ứng viên cho Cơ sở dữ liệu Kéo dài SQL Server 2016
Hạn chế đối với Cơ sở dữ liệu Stretch
Không phải tất cả các bảng đều đủ điều kiện để được bật tính năng Kéo dài. Một số thuộc tính bảng, dữ liệu và kiểu cột, ràng buộc và chỉ mục không được hỗ trợ, chẳng hạn như:
- Bảng sao chép và tối ưu hóa bộ nhớ
- Các bảng có chứa dữ liệu FILESTREAM, hãy sử dụng Theo dõi thay đổi hoặc Thu thập dữ liệu thay đổi
- Các kiểu dữ liệu như dấu thời gian, sql_variant, XML hoặc địa lý
- Kiểm tra hoặc các ràng buộc mặc định
- Ràng buộc khóa ngoại tham chiếu bảng
- Các chỉ mục XML, toàn văn bản, không gian hoặc phân cụm cột
- Các chế độ xem được lập chỉ mục tham chiếu đến bảng
- Bạn không thể chạy các câu lệnh UPDATE hoặc DELETE hoặc chạy các hoạt động CREATE INDEX hoặc ALTER INDEX trên bảng hỗ trợ Stretch
Để có danh sách đầy đủ các giới hạn, bạn có thể truy cập:Yêu cầu và giới hạn đối với Cơ sở dữ liệu Stretch.
Thiết lập cơ sở dữ liệu Stretch
Bắt đầu với bản phát hành RTM hơi khác so với các bản xem trước trước đó. Bạn sẽ cần một tài khoản Azure và sau đó bạn phải bật Cơ sở dữ liệu Stretch trên phiên bản cục bộ.
Để bật Cơ sở dữ liệu Stretch trên một phiên bản, hãy chạy:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Đối với bản trình diễn này, tôi sẽ sử dụng một cơ sở dữ liệu mẫu mà tôi đã tạo có tên là STRETCH. Tôi bắt đầu bằng cách nhấp chuột phải vào cơ sở dữ liệu, chọn Nhiệm vụ, Kéo dài, rồi chọn Bật. Điều này đã được sử dụng SQL Server 2016 Management Studio.
Màn hình tiếp theo cung cấp cho bạn những bảng nào bạn muốn bật cho Stretch:
Tôi đã chọn bảng SALES2. Trình hướng dẫn mặc định là “Toàn bộ bảng”, nhưng bạn cũng có thể thay đổi tùy chọn đó để di chuyển một tập hợp con các hàng.
Nếu bạn chọn theo hàng, bạn phải chọn tên cho tiêu chí của mình, sau đó bạn có thể chọn cột nào sẽ sử dụng trong câu lệnh where cũng như điều kiện và giá trị. Trong ảnh chụp màn hình này, tôi đã chọn các hàng trước năm 2016. Có thể chọn một phần của bảng là một cải tiến lớn so với các bản xem trước trước đó, điều này chỉ cho phép bạn kéo dài toàn bộ bảng. Để đơn giản hơn, trong bản trình diễn này, tôi sẽ di chuyển toàn bộ bảng, vì vậy tôi nhấp vào Hủy, rồi nhấp vào Tiếp theo.
Khi bạn đã chọn các bảng và điều kiện của mình, bạn phải chọn đăng ký Azure mà bạn sẽ sử dụng, khu vực Azure và thông tin máy chủ của bạn.
Khi bạn đã nhập thông tin cần thiết, hãy nhấp vào Tiếp theo.
Một cải tiến mới là sử dụng khóa chính cơ sở dữ liệu để bảo vệ thông tin đăng nhập Azure để kết nối với Azure. Nếu bạn chưa có khóa chính, bạn sẽ được nhắc tạo một khóa chính, nếu bạn đã có, bạn sẽ cần cung cấp mật khẩu. Nhấp vào Tiếp theo.
Bạn sẽ cần tạo quy tắc tường lửa cho máy chủ của mình hoặc bạn có thể nhập dải IP mạng con. Thực hiện lựa chọn của bạn và nhấp vào Tiếp theo.
Đây là nơi mà mọi thứ đã thực sự thay đổi và sẽ khiến tôi xem xét lại việc sử dụng tính năng này. Microsoft đã tạo Đơn vị kéo giãn cơ sở dữ liệu (DSU) để bạn có thể tăng hoặc giảm mức hiệu suất mà bạn cần cho dữ liệu Kéo dài. Kể từ tháng 6 năm 2016, giá hiện tại được lập hóa đơn cho cả máy tính và bộ nhớ mà bạn thấy được trình bày trong hình trên. Đối với bảng 15MB của tôi đã được di chuyển, tôi sẽ bị tính phí $ 61 USD mỗi tháng để lưu trữ, cũng như mức DSU tối thiểu (100) là $ 912,50 mỗi tháng. Các mức DSU bao gồm:
| DSU cấp | Chi phí hàng giờ | Chi phí hàng tháng tối đa (tháng có 31 ngày) |
|---|---|---|
| 100 | $ 1,25 | $ 930 |
| 200 | 2,50 đô la | 1.860 đô la |
| 300 | 3,75 đô la | 2.790 đô la |
| 400 | $ 5,00 | 3.720 đô la |
| 500 | 6,25 đô la | 4.650 đô la |
| 600 | $ 7,50 | 5,580 đô la |
| 1000 | 12,50 đô la | 9.300 đô la |
| 1200 | $ 15,00 | 11.160 đô la |
| 1500 | 18,75 đô la | $ 13,950 |
| 2000 | $ 25,00 | 18.600 đô la |
Tại sao thuật sĩ chỉ cho tôi biết $ 912,50, trong khi bảng giá cho biết nó phải là $ 900 cho tháng 6 (hoặc xếp hạng theo tỷ lệ dựa trên số ngày còn lại trong tháng 6)? Dự đoán của bạn cũng tốt như tôi; Tôi đã thử các công cụ toán học khác nhau và nhận được kết quả trống. Bạn có thể tìm hiểu thêm về các mô hình định giá tại đây:
- Định giá cơ sở dữ liệu SQL Server Stretch
Trước khi tìm hiểu về phương thức thanh toán mới này cho DSU, tôi có thể lập luận rằng sử dụng Cơ sở dữ liệu Stretch sẽ là một phương pháp rất hiệu quả về chi phí để lưu trữ dữ liệu lạnh (dữ liệu chưa sử dụng) vào đám mây. Bằng cách kéo dài dữ liệu này vào Azure, bạn có thể di chuyển một phần lớn dữ liệu cũ hơn, điều này sẽ làm giảm kích thước (và do đó chi phí) của các bản sao lưu cục bộ của bạn. Trong trường hợp bạn phải khôi phục cơ sở dữ liệu, bạn chỉ cần thiết lập kết nối với Azure cho dữ liệu bị kéo dài, do đó loại bỏ nhu cầu khôi phục nó. Tuy nhiên, với chi phí tối thiểu là gần 1.000 đô la mỗi tháng đối với quy mô DSU cấp thấp, nhiều tổ chức sẽ thấy rằng việc lưu giữ dữ liệu ở cấp lưu trữ ít tốn kém hơn trong trung tâm dữ liệu của họ và tìm các phương pháp khác cho HA như phản chiếu, ghi nhật ký vận chuyển hoặc Nhóm sẵn có.
Nhấp vào Hoàn tất để bắt đầu di chuyển.
Xin chúc mừng, tôi hiện đã di chuyển bảng SALES2 sang Cơ sở dữ liệu Azure SQL
Tắt bảng Căng da
Trong các bản xem trước ban đầu của Cơ sở dữ liệu Stretch, nếu bạn muốn vô hiệu hóa một bảng Stretch, bạn sẽ phải tạo một bảng mới và chèn dữ liệu căng vào đó. Sau khi tất cả dữ liệu đã được sao chép, bạn sẽ phải chuyển đổi các bảng theo cách thủ công bằng cách đổi tên chúng hoặc hợp nhất dữ liệu đã kéo dài lại vào bảng sản xuất theo cách thủ công. Với bản phát hành RTM, bạn vẫn có thể xử lý quá trình di chuyển theo cách thủ công, chọn để dữ liệu trong Azure hoặc chọn một tùy chọn để khôi phục dữ liệu từ Azure.
Bất kể bạn sử dụng phương pháp nào để khôi phục dữ liệu, bạn phải chịu phí truyền dữ liệu.
Sao lưu và khôi phục cơ sở dữ liệu Stretch
Sau khi bạn di chuyển dữ liệu vào Cơ sở dữ liệu Stretch, Azure sẽ xử lý việc sao lưu dữ liệu Stretch. Sao lưu diễn ra với một ảnh chụp nhanh được thực hiện cứ sau 8 giờ và ảnh chụp nhanh được duy trì trong 7 ngày. Điều này mang lại cho bạn tối đa 21 điểm trong thời gian 7 ngày trước đó để khôi phục.
Bạn không phải thực hiện bất kỳ thay đổi nào đối với các quy trình sao lưu cục bộ hiện tại của mình. Mọi bản sao lưu cục bộ được thực hiện sẽ chứa tất cả dữ liệu cục bộ và dữ liệu đủ điều kiện chưa được di chuyển. Đây được coi là một bản sao lưu nông và không chứa bất kỳ dữ liệu nào đã được chuyển sang Azure.
DBCC CHECKDB
Bạn cũng không thể chạy CHECKDB dựa trên dữ liệu đã được di chuyển sang Azure.
Khi tôi chạy DBCC CHECKDB trên cơ sở dữ liệu STRETCH của mình trước khi di chuyển, tôi nhận được kết quả sau cho bảng SALES2:
Kết quả DBCC cho 'SALES2'.Có 45860 hàng trong 1901 trang cho đối tượng "SALES2".
Sau khi di chuyển, tôi nhận được kết quả sau cho bảng SALES2 (mỏ nhấn mạnh):
Kết quả DBCC cho 'SALES2'.Có 0 hàng trong 1901 trang cho đối tượng "SALES2".
Bạn có thể chạy DBCC CHECKDB dựa trên Cơ sở dữ liệu Azure SQL, tuy nhiên do không thể kết nối trực tiếp với Cơ sở dữ liệu Azure SQL được kéo dài, bạn hiện không thể chạy DBCC CHECKDB theo cách thủ công đối với dữ liệu được kéo dài cụ thể. Tôi không thể tìm thấy bất kỳ tài liệu nào cho biết Azure đang thực hiện bất kỳ kiểm tra tính nhất quán nào đối với các cơ sở dữ liệu này.
Theo tôi, điều này mang lại rủi ro đáng kể.
Tóm tắt
Cơ sở dữ liệu Stretch là một cách dễ dàng để di chuyển dữ liệu lưu trữ sang Microsoft Azure, nếu cơ sở dữ liệu của bạn hỗ trợ. Hiện tại trong SQL Server 2016 RTM có nhiều hạn chế với thuộc tính bảng, dữ liệu và cột, dữ liệu và kiểu cột, ràng buộc và chỉ mục. Nếu bạn không bị giới hạn bởi những giới hạn đó, thì Cơ sở dữ liệu kéo dài là một cách đơn giản để di chuyển dữ liệu lịch sử sang Cơ sở dữ liệu SQL Azure để giải phóng bộ nhớ cục bộ và giảm thời gian khôi phục của các cơ sở dữ liệu đó nếu chi phí đáng giá. Bạn cũng cần cảm thấy thoải mái, ít nhất là hiện tại, với việc không thể chạy DBCC CHECKDB dựa trên bất kỳ dữ liệu đã di chuyển nào. Việc quản lý khôi phục cũng sẽ phức tạp hơn một chút với việc phải khôi phục kết nối giữa cơ sở dữ liệu SQL Server và cơ sở dữ liệu Azure từ xa.
