114
4
。
Bài viết này chỉ là tổng quan về các tính năng mới của SQL Server 2022, cũng như hiểu biết của cá nhân tôi về từng tính năng từ góc độ người dùng. Một số tính năng sẽ được mô tả dựa trên một số trải nghiệm của tôi. ở cấp độ động cơ, đây thực sự là một cấp độ quan trọng và mỗi điểm chức năng liên quan có thể được phát triển thành một bài viết riêng biệt. Tuy nhiên, bài viết này chỉ mang tính tổng quan và không giải thích sâu từng tính năng.
Bài viết này tập trung thảo luận về bản thân công cụ SQL Server 2022. Việc tích hợp với Azure và tích hợp S3 Blob cũng như các cải tiến ở cấp độ triển khai của Trên Linux và K8S không nằm trong phạm vi của bài viết này.
。
Bài viết này sẽ thử nghiệm một số chức năng mới, nhưng sẽ không tiến hành thử nghiệm chuyên sâu và chỉ thực hiện xác minh sơ bộ. Do đó, môi trường về cơ bản là đơn giản và sẽ được phát hành ngay khi được sử dụng.
Alibaba Cloud RDS dành cho SQL Server 2022 Enterprise Cluster Edition.
mssql.x4.medium.e2（2c8g） 。
Cơ sở dữ liệu mẫu: https://github.com/microsoft/sql-server-samples/tree/master/samples/databases/wide-world-importers.
。
Một số tính năng được giới thiệu trong SQL Server 2022 có thể cải thiện hiệu suất ngay lập tức và chúng cũng là những tính năng mang lại sự cải tiến lớn nhất. Đối với hầu hết các sản phẩm, việc nâng cao hiệu quả của sản phẩm đòi hỏi phải thay đổi hành vi sử dụng, điều này thường dẫn đến chi phí cao hơn. Ngược lại, chỉ cần nâng cao khả năng của bản thân sản phẩm mà không thay đổi cách sử dụng là mang lại lợi nhuận cao nhất.
Ví dụ, khi nguồn pin của điện thoại di động không thay đổi, việc thay đổi thói quen sử dụng như tắt thủ công các chức năng không sử dụng để tiết kiệm điện sẽ tốn kém hơn rất nhiều so với việc hệ điều hành thường xuyên tự động tắt các chức năng theo quy định cụ thể để tiết kiệm điện. . đến sau này.
Điều này cũng đúng với cơ sở dữ liệu. Nhiều tính năng mới có thể yêu cầu thay đổi mã ứng dụng, điều này có thể dẫn đến chi phí sử dụng cao hơn. Ngược lại, nếu cải tiến ở cấp độ kernel, chỉ cần đặt công tắc của một số chức năng và chi phí sử dụng phần này sẽ tương đối thấp.
Toàn bộ bức tranh tổng thể về Thông minh truy vấn tích hợp như sau. Bạn có thể thấy rằng Kho truy vấn là cốt lõi của việc hiện thực hóa những điều cơ bản này.
。
Trước đây, một phần công việc quan trọng hơn của DBA là điều chỉnh hiệu suất và một phần công việc quan trọng hơn trong việc điều chỉnh hiệu suất là "thiết lập Đường cơ sở". Các chỉ số về tình trạng sức khỏe Giống như Base dòng, là chỉ báo về trạng thái bình thường của một người, khi một người cảm thấy không thoải mái, việc so sánh dữ liệu đã kiểm tra với Đường cơ sở có thể nhanh chóng thu hẹp nguyên nhân gây bệnh. Tương tự, khi xảy ra tắc nghẽn trong hệ thống, việc so sánh các chỉ số hiện tại với. Đường cơ sở có thể giúp thu hẹp nhanh chóng phạm vi điều tra.
Một phần khác của công việc điều chỉnh hiệu suất là nắm bắt "SQL chậm" bằng cách thường xuyên ghi lại các câu lệnh tiêu thụ tài nguyên cao và điều chỉnh các câu lệnh này theo cách thủ công.
Mặc dù SQL Server có rất nhiều thông tin thống kê bản ghi DMV tích hợp nhưng phần thông tin này dựa trên bộ nhớ và biến mất sau khi khởi động lại, đồng thời chỉ có dữ liệu tổng hợp và không có dữ liệu được phân đoạn.
Hai phần trên yêu cầu thu thập dữ liệu. Hành động này thường yêu cầu một nền tảng SQL Server nhất định và cũng yêu cầu triển khai các thành phần bổ sung như thu thập giám sát, xử lý dữ liệu và hiển thị.
Cách truyền thống là sử dụng trình thu thập plug-in, chẳng hạn như hệ thống hiểu biết sâu sắc về hiệu suất của Alibaba Cloud RDS cho SQL Server mà tôi đã đề cập trước đây.
SQL Server đã giới thiệu Query Store từ năm 2016, có thể lưu trữ nhiều siêu dữ liệu khác nhau về hiệu suất SQL được thực thi vào đĩa bằng cơ sở dữ liệu. Phương thức kích hoạt chỉ là một tùy chọn. Siêu dữ liệu này bao gồm:
。
Ví dụ: chúng ta có thể sử dụng Query Store để sắp xếp các truy vấn theo CPU và tóm tắt chúng theo từng phút. Ví dụ: trong hình bên dưới, SQL chỉ tương ứng với 1 phương án thực thi, được thực hiện 379 lần trong 1 phút, thời gian CPU và các thông tin liên quan khác. .
。
Sau đó, với Cửa hàng truy vấn, một phiên bản đơn giản của phương pháp điều chỉnh DBA trước đây:
Query Store đã phát triển qua nhiều phiên bản và trở thành tùy chọn được bật mặc định trong SQL Server 2022. Được bật theo mặc định có nghĩa là Microsoft cần phải chịu trách nhiệm về các tác dụng phụ do tính năng này gây ra, vì vậy theo tôi, tính năng này đã bước vào một giai đoạn rất khó khăn. giai đoạn trưởng thành.
Do đó, Kho truy vấn cung cấp dữ liệu quyết định cho một số hàm tối ưu hóa được thảo luận bên dưới.
。
SQL sẽ trải qua một loạt quy trình trong trình tối ưu hóa từ phân tích cú pháp đến kế hoạch thực thi được tạo cuối cùng. Chất lượng của kế hoạch thực thi được phân tích cú pháp bởi SQL thường liên quan trực tiếp đến hiệu suất SQL và quy trình phân tích cú pháp yêu cầu tham chiếu đến nhiều loại khác nhau. Chất lượng của những dữ liệu này Độ chính xác rất quan trọng đối với việc thực hiện kế hoạch, giống như nếu bạn muốn đi mua sắm, cách nhanh nhất để đi từ nhà đến trung tâm mua sắm phụ thuộc vào việc có tắc đường hay không. là ùn tắc giao thông, tàu điện ngầm sẽ nhanh hơn lái ô tô và ngược lại, tàu điện ngầm sẽ nhanh hơn " Siêu dữ liệu "điều kiện giao thông trên đường" rất quan trọng để tạo ra "đường thực thi" tốt hơn.
Việc phân tích cú pháp SQL thành một kế hoạch thực thi cũng yêu cầu tham chiếu đến nhiều siêu dữ liệu, chẳng hạn như thông tin thống kê, liệu có chỉ mục hay không, số lượng hàng ước tính sau khi lọc, v.v. Ước tính số lượng đề cập đến số lượng hàng được SQL ước tính sau khi truy cập các đối tượng bảng dựa trên các hoạt động như lọc hoặc Tham gia. Độ chính xác của số lượng hàng này ảnh hưởng trực tiếp đến chất lượng của kế hoạch thực hiện.
Việc đánh giá SQL Server từ 7.0 đến trước 2014 (mức tương thích thấp hơn 2014) dựa trên giả định không có sự tương quan giữa các dữ liệu, ví dụ ước lượng số hàng trong đó a =1 và b=2 = độ chọn lọc của a * việc lựa chọn b giới tính * tổng số hàng.
Kịch bản mặc định cho SQL Server 2014 trở lên (mức tương thích >= 2014) là dữ liệu có nhiều mối quan hệ và số lượng hàng ước tính giữa nhiều điều kiện trong cùng một bảng sẽ nhiều hơn. Để biết thuật toán cụ thể, hãy xem liên kết.
Cả hai đều thích ứng với các loại tải khác nhau. Mô hình cũ phù hợp hơn với các loại tải đơn giản có độ tương quan thấp và mô hình mới phù hợp với các truy vấn phức tạp hơn (Microsoft gọi đó là "khối lượng công việc hiện đại"). mức độ tương thích hoặc thông qua Gợi ý được kiểm soát riêng, điều này cũng không hoàn hảo.
Cơ chế được cung cấp vào năm 2022 là cung cấp phản hồi thông qua các truy vấn lịch sử, liên kết giữa trình tối ưu hóa truy vấn và Cửa hàng truy vấn, biên dịch SQL để tìm các câu lệnh có chênh lệch chi phí lớn giữa các CE khác nhau và cố gắng đính kèm CE Hint và sửa cơ chế này dựa trên kết quả của Kho truy vấn (Gợi ý bổ sung sẽ không cải thiện đáng kể hoặc thậm chí làm giảm hiệu suất, tương tự như hình ảnh bên dưới, trích từ Bob Ward).
Điều này có nghĩa là mô hình CE có thể được điều chỉnh cho phù hợp với các truy vấn khác nhau ở cấp độ Mỗi truy vấn. Phần công việc này đã là công việc của một DBA cấp cao, tức là đưa ra các quyết định tối ưu hóa dựa trên nhiều bản ghi lịch sử. kích hoạt chức năng này chỉ cần đáp ứng các điều kiện sau:
。
。
Khi SQL Server thực thi Truy vấn, một số thao tác rõ ràng sẽ dựa vào bộ nhớ, chẳng hạn như Sắp xếp hoặc Tham gia băm. Kế hoạch thực hiện sẽ đặt trước việc sử dụng bộ nhớ. Hai vấn đề sẽ gặp phải ở đây:
。
Dung lượng bộ nhớ được cấp tùy thuộc vào kế hoạch thực hiện. Ví dụ: bộ nhớ cần thiết để sắp xếp 10.000 dữ liệu và 100.000 dữ liệu chắc chắn là khác nhau, nhưng kế hoạch thực hiện thường được ước tính không chính xác, dẫn đến bộ nhớ không chính xác.
SQL Server 2022 cung cấp các bản ghi lịch sử bộ nhớ dựa trên Kho lưu trữ truy vấn. Dựa trên bộ nhớ thực tế cần thiết để thực hiện Truy vấn trước đây, việc cấp bộ nhớ cho truy vấn mới nhất được xác định. Tuy nhiên, điều này cũng dựa trên một ngưỡng và sẽ chỉ được thực hiện. trong các trường hợp cấp bộ nhớ có sự điều chỉnh rất khác nhau.
Điều kiện kích hoạt:
。
。
Như đã đề cập trước đó, siêu dữ liệu mà quy trình Truy vấn->Kế hoạch thực thi trong SQL Server dựa vào phụ thuộc vào ước tính chi phí. Điều kiện tiên quyết để ước tính chi phí chính là tham số đó. Ví dụ: trong đó a =1 trả về 10.000 hàng và trong đó a=2 trả về 1 hàng, các kế hoạch thực hiện thường khác nhau. Ví dụ: tham số 1 trong hình bên dưới tương ứng với Tìm kiếm và tham số 2 tương ứng với Quét:
。
Ngoài ra, điều tốt nhất về cơ sở dữ liệu thương mại như SQL Server và Oracle là khả năng xử lý SQL phức tạp (ở một mức độ nào đó, đó là ưu điểm và cũng là nhược điểm. Công cụ SQL mạnh mẽ dẫn đến lạm dụng. So với mysql pg, SQL thường được sử dụng sẽ đơn giản hơn rất nhiều, phù hợp hơn với các khái niệm thiết kế DDD và phương pháp triển khai microservice ngày nay (tất nhiên đây là một chủ đề khác). Kế hoạch thực thi lớn nhất mà tôi từng thấy là một thủ tục được lưu trữ với hơn 10.000 dòng và việc thực thi. bản thân kế hoạch là 80 MB.
Chi phí biên dịch loại kế hoạch thực thi này rất cao. Nó không chỉ tiêu tốn CPU mà còn làm tăng thời gian thực hiện câu lệnh. Khi các câu lệnh tương tự xuất hiện đồng thời, nó cũng có thể gây ra tắc nghẽn biên dịch ở cấp hệ thống. các loại và bộ đếm hiệu suất để hiển thị điều này, chẳng hạn như Một số bộ đếm hiệu suất có liên quan bị chặn trong bảng điều khiển Đám mây của Alibaba:
Do đó, việc lưu vào bộ nhớ đệm kế hoạch thực hiện đã biên dịch là lựa chọn tốt hơn. Lúc này, chúng ta sẽ gặp phải một vấn đề khác. Chúng ta nên làm gì nếu kế hoạch thực thi được lưu trong bộ nhớ đệm không chính xác? Điều gì sẽ xảy ra nếu chi phí sử dụng kế hoạch thực thi được lưu trong bộ nhớ đệm cao hơn nhiều so với việc biên dịch lại? Trước đó, vấn đề này luôn để lại nhiều khó khăn cho các đồng nghiệp DBA. Hiểu khái niệm này và không hiểu khái niệm này cũng là bước ngoặt cho việc có nên bắt đầu hay không :-).
Các phương pháp truyền thống cũng thể hiện sự kỳ diệu của chúng, bắt đầu từ SQL, tối ưu hóa việc ghi tham số, cập nhật thường xuyên thông tin thống kê, thêm gợi ý biên dịch lại vào các câu lệnh, điều chỉnh chỉ mục, phân tách SQL và giám sát tích cực nâng cao hơn các câu lệnh tiêu thụ nhiều để dọn sạch bộ đệm riêng lẻ tại các điểm cố định . . tất nhiên cũng có một phương thức thấp hơn, khởi động lại trực tiếp (tất cả các bộ nhớ đệm của kế hoạch thực thi không tồn tại sau khi khởi động lại nên tất cả đều được biên dịch lại).
PSP, được giới thiệu trong SQL Server 2022, được sử dụng để giải quyết vấn đề này. Vì Cửa hàng truy vấn có khả năng lưu trữ nhiều kế hoạch thực thi cho một SQL nên việc chọn một kế hoạch thực thi phù hợp hơn dựa trên các tham số là rất hiệu quả.
Thêm một bộ phân phối giữa Query Hash -> lập kế hoạch băm bộ đệm và quyết định sử dụng kế hoạch thực thi được lưu trong bộ nhớ đệm nào dựa trên bộ phân phối. Chức năng này chắc chắn là sát thủ đối với các cơ sở dữ liệu lớn hơn với các truy vấn phức tạp hơn. Mặc dù tôi chưa có cơ hội xem một số trường hợp nhưng theo kinh nghiệm, chức năng này sẽ giảm đáng kể ngưỡng vận hành và bảo trì.
。
Điều kiện kích hoạt:
Mức độ tương thích 160 (SQL Server 2022).
。
Một chỉ báo của SQL Server là "mức độ song song tối đa" và chỉ báo còn lại là "ngưỡng chi phí song song". Chỉ số trước đề cập đến số lượng Lõi tối đa có thể được thực thi đồng thời cho một Truy vấn và chỉ báo sau có nghĩa là chi phí thực hiện sẽ song song khi nó đạt đến một giá trị nhất định.
Hai giá trị này là sản phẩm của những năm 1990. Giá trị mặc định lần lượt là 0 và 5 đề cập đến quyền kiểm soát của chính SQL Server đối với số lượng Lõi được sử dụng để thực thi song song, về cơ bản bằng số lượng. số lõi vật lý thuộc sở hữu của máy hiện tại. Trên các máy hiện đại, do có nhiều Ổ cắm và Numa. Cấu hình này cực kỳ không hợp lý. Đối với các hệ thống OLTP thông thường, chúng tôi điều chỉnh nó thành 2 hoặc 4 theo mặc định. cũng sẽ được đặt riêng.
"Ngưỡng chi phí song song" được mặc định là 5, đây cũng là một giá trị cực kỳ thấp. Khả năng phần cứng ngày nay hoàn toàn không nhất quán. Trước đây, các CPU đa lõi hoàn thành các nhiệm vụ mà CPU lõi đơn ngày nay thậm chí còn nhanh hơn nhờ khả năng cộng tác lõi cao hơn. chi phí song song Nếu nó quá thấp Điều này sẽ khiến chi phí cộng tác thậm chí còn cao hơn chi phí thực hiện Truy vấn.
Hai giá trị này ở cấp độ phiên bản. Mặc dù sau đó đã được đưa vào cấp độ thư viện, nhưng Phạm vi vẫn quá lớn. Có thể câu lệnh giống AP yêu cầu DOP lớn hơn và lớp TP thậm chí còn được đặt thành 1. cái nào hợp lý hơn.
Phản hồi DOP tương tự như Phản hồi khác được đề cập ở trên. Dựa trên trải nghiệm phản hồi được thu thập trước đây, tác vụ nền của Cửa hàng Truy vấn sẽ đánh giá xem truy vấn có phù hợp để sử dụng phản hồi DOP hay không dựa trên một loạt các yếu tố, bao gồm cả. thời gian thực hiện truy vấn, thời lượng và tính song song, v.v., điều chỉnh động DOP cho các câu lệnh theo quy tắc tích hợp:
。
Điều kiện kích hoạt:
Trung tâm cá nhân
Điều phát hành
từ bỏ
ALTER DATABASE SCOPED CONFIGURATION SET DOP_FEEDBACK = ON
。
。
Thông tin truy vấn tích hợp cho phép SQL Server thực hiện các điều chỉnh tốt hơn dựa trên dữ liệu lịch sử khi trình tối ưu hóa đưa ra quyết định, điều này đã đạt đến một tầm cao mới về khả năng thích ứng. Theo tôi, cơ sở dữ liệu cũng nên đi theo hướng này trong tương lai. Với tư cách là hệ thống nền tảng cơ bản, cơ sở dữ liệu sẽ cho phép người dùng chú ý hơn đến hoạt động kinh doanh trong hầu hết các tình huống, thay vì sự phức tạp của việc sử dụng dữ liệu cơ bản.
Tất cả các chức năng được cung cấp ở trên có thể cải thiện đáng kể hiệu suất và độ ổn định của hệ thống mà không thực hiện bất kỳ thay đổi mã nào. Do đó, nếu có thể, bạn nên nâng cấp lên 2022 và kích hoạt Query Store.
Nếu bạn quan tâm đến một số khái niệm về cơ sở dữ liệu thích ứng, bạn có thể đọc một bài báo cũ của Andy Pavlo Hệ thống quản lý cơ sở dữ liệu tự lái là gì?
。
Cơ sở dữ liệu sổ cái đã được giới thiệu trong SQL Server 2019 và được cải tiến một phần vào năm 2022. Cơ sở dữ liệu này sử dụng chuỗi khối để tạo cơ sở dữ liệu sổ cái phân tán chống giả mạo và không tin cậy. Loại chức năng này, như SSL và TDE, là nhu cầu yếu ở Trung Quốc. Đối với các bên kinh doanh, đó là "Tôi không cần, nhưng các bên thứ ba như cơ quan giám sát bắt tôi phải làm", vì vậy tôi sẽ không đi sâu vào chi tiết. đây.
。
Hàm này giải quyết vấn đề về siêu dữ liệu TempDB một lần và mãi mãi.
Mỗi khi bạn thực hiện DDL, chẳng hạn như tạo bảng, xóa bảng, v.v., bạn cần sửa đổi siêu dữ liệu được sử dụng trong phân bổ nội bộ của các thẻ cơ sở dữ liệu. Đây được gọi là trang PFS trong SQL Server. trở thành nút cổ chai, nhưng các bảng tạm thời và các biến bảng là câu lệnh DDL đặc biệt, nếu các bảng và biến bảng tạm thời được tạo thường xuyên và đồng thời, thì bản thân trang PFS cần phải được sửa đổi thường xuyên thông qua "kiểm soát đồng thời bi quan". là, thông qua một khóa đặc biệt trong cơ sở dữ liệu để bảo vệ cấu trúc bộ nhớ, tên khoa học là Latch. Lock, bản thân nó sẽ trở thành nút cổ chai trong cơ sở dữ liệu.
Là một DBA SQL Server trong nhiều năm, ý thức chung là tạo một phiên bản dựa trên số lõi máy TempDB bắt đầu với ít nhất 4 tệp có nghĩa là nhiều trang PFS, điều này làm giảm khả năng bị chặn khóa.
SQL Server 2022 cập nhật các trang PFS thông qua "kiểm soát đồng thời lạc quan", về cơ bản có thể giải quyết vấn đề tranh chấp và chi phí của đồng thời lạc quan chỉ cho một vài trang hệ thống có thể kiểm soát được. Sự cải tiến này vẫn nhằm giảm bớt hoạt động và bảo trì.
Tùy chọn này yêu cầu kích hoạt thủ công:
ALTER SERVER CONFIGURATION SET MEMORY_OPTIMIZED TEMPDB_METADATA = ON
。
Vùng đệm dựa trên cấu trúc bộ nhớ. Chi phí tìm kiếm ngẫu nhiên trong bộ nhớ rất thấp và phù hợp hơn với cấu trúc Hash. Do đó, việc tìm kiếm ngẫu nhiên thường không phải là vấn đề. Tuy nhiên, việc quét các phiên bản có kích thước lớn thường tốn kém. -các phiên bản có kích thước thường có giá trị bộ nhớ từ 256GB trở lên. Khi bộ nhớ >64GB, quá trình quét Vùng đệm trước đây đơn luồng sẽ trở thành đa luồng, điều này sẽ cải thiện hiệu suất quét.
Các hoạt động bị ảnh hưởng bao gồm:
。
Theo kinh nghiệm của tôi, chức năng này đã được cải thiện cho các phiên bản có bộ nhớ 256G trở lên. Đặc biệt, AlwaysOn sẽ nhanh hơn nhiều khi xảy ra chuyển đổi dự phòng. Điều này không rõ ràng trong các trường hợp khác nên khả năng ứng dụng của nó bị hạn chế.
。
。
Chức năng này chủ yếu cho phép các cụm Luôn bật chứa Cơ sở dữ liệu Chứa, tức là các đối tượng cấp phiên bản trước đây như công việc, thông tin đăng nhập và đối tượng máy chủ được liên kết có thể được di chuyển cùng với cơ sở dữ liệu hoặc đảm bảo tính nhất quán với chuyển đổi HA.
Tôi nghĩ chức năng này có thể giảm chi phí vận hành và bảo trì hơn nữa, sau khi HA xảy ra, nếu công việc hoặc thông tin đăng nhập bị mất, về cơ bản nó tương đương với một lỗi được chứa trong cơ sở dữ liệu và kernel đảm bảo tính nhất quán sẽ ổn định hơn nhiều.
。
Bài viết gốc: Nhiệm vụ khôi phục cơ sở dữ liệu hiện được chạy với mức độ ưu tiên bế tắc cao hơn để tránh bị chọn là nạn nhân bế tắc với các giao dịch của người dùng.
Điều đó có nghĩa là, mức độ ưu tiên bế tắc phiên của luồng hệ thống được sử dụng để khôi phục là "cao".
Mặc dù khả năng xảy ra điều này là thấp nhưng đáng tiếc là Microsoft đã thiết kế theo cách này từ lâu. Tôi đã từng gặp phải việc sau khi switch AlwaysOn, kết nối mới của người dùng đã giết chết luồng Recovery do bế tắc, khiến cơ sở dữ liệu vẫn còn nguyên. ở trạng thái Khôi phục. Nó chỉ được giải quyết sau khi khởi động lại, điều này trực tiếp gây ra thời gian không khả dụng.
。
Mô tả gốc:
Chúng tôi đã khắc phục sự cố khiến cơ sở dữ liệu bản sao bị kẹt ở trạng thái chờ khôi phục.
Đảm bảo việc di chuyển dữ liệu không bị tạm dừng đến các bản sao do lỗi khối nhật ký nội bộ.
Đã loại bỏ các vấn đề tranh chấp khóa lược đồ trên các bản sao thứ cấp.
。
Nghĩ tới câu đó, tôi đã hiểu ra tất cả, chẳng may tôi đã gặp phải cả 3 điều trên, hậu quả tệ nhất là phải cài đặt lại AlwaysOn vài terabyte dữ liệu một lúc, sảng khoái hơn cả việc ăn mỳ bắp cải muối Lão Tấn. . Hiện tại không có cơ hội để xác minh sự cải thiện. Tôi sẽ thêm tác dụng thực tế sau khi có cơ hội xác minh nó.
。
Một tính năng rất quan trọng của cơ sở dữ liệu quan hệ là "ACID", trong đó D đề cập đến độ bền. Một điểm rất quan trọng trong việc đảm bảo độ bền là khả năng phục hồi "tính nhất quán khi gặp sự cố". Ví dụ: khi cơ sở dữ liệu bị tắt hoặc quá trình gặp sự cố, tính nhất quán của dữ liệu trong cơ sở dữ liệu sẽ không bị ảnh hưởng.
Để đạt được điều này, hành động Khôi phục được thực hiện vào lần khởi động cơ sở dữ liệu tiếp theo, nghĩa là giao dịch chưa được gửi nhưng dữ liệu đã được lưu vào đĩa sẽ được khôi phục, giao dịch đã được gửi nhưng bị bẩn. các trang chưa được thả vào đĩa sẽ được làm lại và toàn bộ quá trình cũng được gọi là "khôi phục hoàn tác/làm lại".
Tuy nhiên, độ dài của quá trình khôi phục phụ thuộc vào giao dịch hoạt động sớm nhất khi quá trình gặp sự cố, khởi động lại và tắt. Tôi nhận thấy quá trình khôi phục kéo dài trong 8 giờ. đêm và có hàng trăm gigabyte nhật ký giao dịch đang hoạt động), sau đó khởi động lại phiên bản, bạn cần quét toàn bộ hàng trăm gigabyte nhật ký và thực hiện khôi phục. Nó trực tiếp dẫn đến 8 tiếng không có mặt (Này, suýt nữa tôi đã nhận lỗi, tôi không đành lòng nhìn lại :-( ).
Microsoft đã thực hiện khôi phục song song trong các phiên bản trước để giải quyết vấn đề chậm, nhưng theo kinh nghiệm của tôi, hiệu quả tương đối trung bình, đồng thời có sự bế tắc giữa các quá trình khôi phục đồng thời (tôi thực sự nhận lỗi về điều này và cả lỗi. Càng nghĩ càng tức giận - .-).
ADR được giới thiệu vào năm 2019 và nhiều cải tiến về cơ chế đã được thực hiện vào năm 2022. Nguyên tắc cơ bản là kiểm soát sự đồng thời của nhiều phiên bản, do đó, nhược điểm tương tự như cách ly ảnh chụp nhanh giao dịch, đòi hỏi nhiều không gian lưu trữ hơn cũng như sử dụng thêm CPU và bộ nhớ.
Những lợi ích thu được:
https://cloudblogs.microsoft.com/sqlserver/2023/03/28/accelerated-database-recovery-enhancements-in-sql-server-2022/ Dữ liệu xác minh từ blog chính thức của Microsoft là chênh lệch thời gian khôi phục là 49 giây và 4 giây, sự cải thiện vẫn còn rất lớn.
。
Tóm lại, thời gian khôi phục có thể từ nhật ký giao dịch sớm nhất trong quá khứ đến Điểm kiểm tra mới nhất (thường là 60S), điều này sẽ làm giảm đáng kể thời gian khôi phục, đồng thời, do tồn tại ảnh chụp nhanh dữ liệu nên nhật ký có thể. được cắt bớt mạnh mẽ hơn và cũng tránh được Dung lượng ổ đĩa là một vấn đề. Do đó, việc bật chức năng này có thể cải thiện tính khả dụng cho các cơ sở dữ liệu có dung lượng lớn hơn vài trăm G, có tải trọng cao và thường có các giao dịch dài.
。
Trực tiếp sửa đổi các thuộc tính của cơ sở dữ liệu trong bảng điều khiển Alibaba Cloud RDS.
。
Parallel Redo chủ yếu được sử dụng bởi AlwaysOn, nhưng hiệu quả còn hạn chế. Đôi khi, chúng tôi thậm chí cần phải tắt nó. Việc tối ưu hóa vào năm 2022 là loại bỏ giới hạn Worker là 100. Điều này sẽ hữu ích cho những trường hợp có số lượng cơ sở dữ liệu lớn, nhưng. Tôi không biết một số vấn đề với Redo song song trước đây liệu nó đã được sửa chữa hay chưa.
。
。
JSON về cơ bản là tiêu chuẩn thực tế cho hầu hết các hoạt động trao đổi dữ liệu hiện nay. SQL Server 2016 đã bắt đầu hỗ trợ JSON trong T-SQL. Vào năm 2022, các hàm JSON_ARRAY và IS_JSON đã được thêm vào. Về cơ bản, bạn có thể biết chức năng của chúng bằng cách xem tên. , bạn có thể xem tài liệu của Microsoft.
Nói chung, các ứng dụng ngày nay đã rất hoàn thiện trong việc xử lý JSON và có các giải pháp và thư viện lớp hoàn thiện. Việc phân tích cú pháp JSON ở phía cơ sở dữ liệu thường không mang lại nhiều lợi ích, vì vậy tôi sẽ không đi sâu vào chi tiết ở đây.
。
Chúng đều là các chức năng liên quan đến thời gian, vui lòng xem trang web chính thức của Microsoft để biết chi tiết.
。
。
。
Tôi luôn thận trọng về khả năng bổ sung để cung cấp các phương ngữ SQL được tích hợp trong cơ sở dữ liệu. Do đặc điểm của cơ sở dữ liệu, chi phí mở rộng quy mô rất cao và ứng dụng dễ dàng mở rộng quy mô hơn vì nó không có trạng thái. ngôn ngữ ứng dụng có khả năng xử lý logic mạnh mẽ hơn, vì vậy các cá nhân thường thích hoàn thành công việc bên ngoài cơ sở dữ liệu và chuyển sức mạnh tính toán khác hơn là truy cập dữ liệu vào ứng dụng.
。
Bản thân chức năng này được sử dụng để mã hóa đầu cuối. Phía ứng dụng nắm giữ khóa mã hóa và toàn bộ dữ liệu liên kết được mã hóa. Cá nhân tôi nghĩ rằng dữ liệu được mã hóa không thể được xem trong SQL Server để giải quyết vấn đề tin cậy giữa khách hàng và nhà cung cấp đám mây. Ngay cả khi phía PaaS trên đám mây chịu trách nhiệm vận hành và bảo trì cơ sở dữ liệu, nó cũng không thể xem nội dung của cơ sở dữ liệu. .
Một số cải tiến đã được thực hiện vào năm 2022 và Khóa ứng dụng được đặt trong khu vực bảo mật của SQL Server để một số thao tác chuỗi có thể có hiệu lực, chẳng hạn như thao tác Like, sẽ không được mô tả ở đây.
。
Nó chủ yếu hỗ trợ TLS1.3 và mã hóa liên kết. Các chức năng này chủ yếu đáp ứng các yêu cầu tuân thủ và sẽ không được mô tả chi tiết.
。
Ví dụ: ##MS_DefinitionReader##, ##MS_ServerStateReader## và ##MS_ServerPerformanceStateReader## được thiết kế chủ yếu để có thể xem các dữ liệu hiệu suất khác nhau của hệ thống nhưng không thuận tiện cho một số hoạt động của bên thứ ba. và nhân viên bảo trì sử dụng, nhưng họ cũng lo lắng về việc rò rỉ Dữ liệu, theo tôi, loại chức năng này tương đối vô dụng ở Trung Quốc.
。
Nhìn chung, SQL Server 2022 vẫn đáng để đầu tư nâng cấp, đặc biệt là phần "truy vấn thích ứng" tuy không mạnh bằng "lái xe tự động" nhưng có thể coi là đã vào cấp độ lái xe hỗ trợ L2.5.
Những cải tiến khác về HA/DR cũng được mong đợi, đặc biệt là thời gian khôi phục DR được rút ngắn đáng kể, điều này rất quan trọng đối với các ứng dụng cấp doanh nghiệp.
Nếu các vấn đề về tính khả dụng và hiệu suất với cơ sở dữ liệu của bạn là vấn đề hiện tại thì việc đầu tư vào nâng cấp lên SQL Server 2022 sẽ mang lại kết quả.
Lưu ý: Bài viết này không đề cập đến mối liên kết với Azure/AWS, cũng như không đề cập đến các phần K8S và Trên Linux. Ngoài ra, sao lưu ảnh chụp nhanh không được đề cập vì đây là một trường hợp thích hợp.
。
。
SQL Server 2022 được tiết lộ: Nền tảng dữ liệu kết hợp được hỗ trợ bởi tính bảo mật, hiệu suất và tính khả dụng.
Bob Ward 。
Blog chính thức của SQL Server 2022: https://cloudblogs.microsoft.com/sqlserver/tag/sql-server-2022-blogging-series/.
。
。
。
。
Cuối cùng, bài viết tổng quan về các tính năng mới của SQLServer2022 kết thúc tại đây. Nếu bạn muốn biết thêm về tổng quan về các tính năng mới của SQLServer2022, vui lòng tìm kiếm các bài viết về CFSDN hoặc tiếp tục duyệt qua các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi. tương lai! .
114
4
0
Trong thư viện lớp Windows của tôi (được sử dụng bởi trang web MVC), tôi đã cài đặt NugetPackage Microsoft.SqlServer.Types (Spatial). Bây giờ tôi đang sử dụng ado.net
Kiểm tra sql: Sao chép mã như sau: SET STATISTICS IO ON SET STATISTICS TIME ON SELECT COUNT(1)&n
Tôi đang xây dựng DbContext từ SqlConnection. Khi tôi sử dụng nó, tôi gặp lỗi sau: Loại nhà cung cấp Entity Framework 'System.Data.Enti
Tôi đã tạo dịch vụ WCF bằng dotNet 4.5. Lớp cơ sở dữ liệu được xây dựng bằng Entity Framework 6. Tôi đã lưu trữ dịch vụ bằng IIS 8. Nó chạy tốt. Bây giờ tôi cần sử dụng dịch vụ bằng ứng dụng khách Windows Forms,
Tôi đang cố xuất một số bảng từ cơ sở dữ liệu sql trên SqlServer 1. Trong mạng LAN nội bộ của chúng tôi (ngay bên cạnh tôi) có một Máy chủ Sql tạm thời mà tôi đã tạo có tên là SqlServer 2. Tôi không muốn sao lưu toàn bộ dữ liệu
Lỗi 1 Sao chép tệp bin\EntityFramework.SqlServer.xml vào obj\Debug\Package\PackageTmp\bin\Entit
Tôi đang cố gắng khôi phục cơ sở dữ liệu qua Powershell bằng SMO, nhưng khi tôi cố gắng xác định và sử dụng đối tượng máy chủ, tôi gặp lỗi sau: Không thể chuyển đổi đối số "srv", có giá trị:
Vì lý do nào đó, tôi cần cập nhật một trong các cột trong bảng của mình từ "NOT NULL" thành "NULL". Lệnh rất đơn giản: ALTER TABLE TBLOGDOCMESSAGE ALTER COLUMN PROCESSID BIGI
Tôi muốn biết liệu điều tôi đang cố gắng làm có khả thi hay không. Tôi tin rằng nó đang sử dụng hàm PIVOT trong TSQL nhưng không có đủ kinh nghiệm với hàm PIVOT để biết bắt đầu từ đâu. Về cơ bản, tôi đang cố gắng thực hiện phương pháp sau có tên là #tmpbudgetdat
Tôi đang cố gắng truy vấn con dưới dạng cột có điều kiện. Lỗi tôi nhận được từ SQL Server là: Truy vấn con trả về nhiều hơn 1 giá trị. Điều này không được phép khi truy vấn con được theo sau bởi =, !=,, >= hoặc khi truy vấn con được sử dụng làm biểu thức. Tôi đang chọn thêm
Tôi có cơ sở dữ liệu máy chủ SQL mà tôi đang truy vấn và tôi chỉ muốn nhận thông tin khi một hàng cụ thể trống. Tôi đã sử dụng câu lệnh Where như: WHERE database.foobar = NULL không trả về bất kỳ thứ gì. Nhưng tôi biết
1. Các bước nối chuỗi (không chia toàn bộ chuỗi): Đầu tiên, thêm dấu ngoặc đơn vào trước và sau chuỗi; Các biến trong chuỗi được biểu thị trong chuỗi bằng '''+@para+'''; trong khi thực hiện Lỗi chuyển đổi loại, hãy áp dụng loại tương ứng
Lưu ý: Có nhiều nguyên nhân khiến nhật ký bị thu nhỏ, một số là do không đủ dung lượng, một số là do hạn chế của ứng dụng. ?
Hàm Rand() là chức năng riêng của hệ thống để lấy số ngẫu nhiên. Bạn có thể chạy trực tiếp select rand() để lấy số kiểu float trong khoảng từ 0 đến 1. Nếu bạn muốn lấy một số nguyên ngẫu nhiên trong khoảng từ 0 đến 100, bạn có thể sử dụng select ro như thế này
Lưu nội dung sau dưới dạng openSql.bat và nhấp đúp để chạy nó để sao chép mã như sau: @echo ========= Cổng máy chủ SQL =========== ========= @ech
Toán tử bảng ÁP DỤNG mới áp dụng biểu thức bảng bên phải cho mỗi hàng trong biểu thức bảng bên trái. Không giống như THAM GIA, biểu thức bảng nào có thể được tính toán trước, APPLY phải tính toán biểu thức bên trái một cách hợp lý trước tiên. Thứ tự logic của các đầu vào tính toán này cho phép biểu thức bên phải có liên quan đến biểu thức bảng bên trái.
Bản thân SQL Server cung cấp một DMV như vậy để trả về thông tin này, đó là sys.dm_exec_sessions. Ví dụ: hãy thực hiện một truy vấn trên máy của tôi: Sao chép mã như sau: CHỌN * TỪ
Mặc dù việc tính toán các hàm xếp hạng khác về mặt kỹ thuật tương tự như ROW_NUMBER nhưng ứng dụng thực tế của chúng ít phổ biến hơn nhiều. RANK và DENSE - RANK chủ yếu được sử dụng để xếp hạng và tính điểm. NTILE được sử dụng nhiều hơn để phân tích. Đầu tiên tạo một bảng mẫu: Sao chép
1. Ý nghĩa và mối quan hệ của các tệp và nhóm tệp. Mỗi cơ sở dữ liệu có một tệp dữ liệu chính và một số tệp phụ. Các tập tin là hiện thân vật lý của cơ sở dữ liệu. Một nhóm tệp có thể bao gồm các tệp được phân phối trên nhiều phân vùng hợp lý để đạt được cân bằng tải. Nhóm tệp cho phép các tệp được nhóm lại để quản lý và dữ liệu dễ dàng hơn
Tôi nghĩ nhiều người biết rằng trong Oracle, các mảng (chẳng hạn như int[]) có thể được chuyển vào các thủ tục lưu trữ, điều đó có nghĩa là nhiều bản ghi có thể được chuyển đến dữ liệu và được cập nhật cùng nhau. Giảm số lượng yêu cầu cơ sở dữ liệu. Nhưng còn SqlServer thì sao? số lượng lớn Chèn cái này
Tôi là một lập trình viên xuất sắc, rất giỏi!