Nhiều quản trị viên cơ sở dữ liệu thấy mình phải hỗ trợ các phiên bản của Dịch vụ Báo cáo Máy chủ SQL (SSRS), hoặc ít nhất là các cơ sở dữ liệu phụ trợ được yêu cầu cho SSRS. Trong nhiều năm, SSRS được đóng gói cùng với việc cài đặt SQL Server, điều này đã góp phần làm tăng thêm một số nhầm lẫn xung quanh việc cấp phép và hỗ trợ cho sản phẩm, vì vậy bắt đầu từ SSRS 2017, gói cài đặt cho Dịch vụ báo cáo là một bản tải xuống riêng biệt.

Bài viết này sẽ đề cập đến nhiều lĩnh vực mà người quản trị cơ sở dữ liệu cần biết để cấp phép, khôi phục và điều chỉnh cài đặt Dịch vụ Báo cáo một cách chính xác. Các chủ đề này áp dụng cho cả Dịch vụ Báo cáo Máy chủ SQL cũng như Máy chủ Báo cáo Power BI.

Cấp phép

Việc cài đặt và hỗ trợ SSRS có thể gây nhầm lẫn. Dịch vụ báo cáo có thể được cài đặt như một phiên bản độc lập trên một máy chủ chuyên dụng, trên cùng một phiên bản SQL Server hoặc trong một triển khai quy mô lớn (chỉ dành cho Phiên bản Doanh nghiệp). Mỗi phiên bản nơi SSRS được cài đặt trong sản xuất yêu cầu giấy phép SQL Server, cũng như cấp phép phiên bản SQL Server nơi cơ sở dữ liệu ReportServer và ReportServerTempDB cư trú.

Cách tôi muốn giải thích cách cấp phép Dịch vụ báo cáo là nghĩ về dịch vụ báo cáo như một ứng dụng sử dụng SQL Server ở mặt sau. Trong những ngày đầu của SSRS, một yêu cầu cũng là cài đặt và cấu hình Dịch vụ Thông tin Internet (IIS). SSRS 2008 đã đưa thành phần đó vào mô-đun dịch vụ báo cáo. Rất thường thấy SSRS và MSSQL được cài đặt trên cùng một phiên bản do được cấp phép và điều này có thể hoạt động tốt đối với các triển khai nhỏ hơn. Đối với các triển khai lớn hơn, bạn thường thấy một máy chủ dịch vụ báo cáo chuyên dụng với ReportServer và ReportServerTempDB trên SQL Server hợp nhất. Đối với các cài đặt rất lớn, triển khai quy mô lớn được sử dụng để cung cấp cân bằng tải cho dịch vụ máy chủ báo cáo. Trong triển khai quy mô lớn, mỗi phiên bản trong trang trại phải được cấp phép.

Khôi phục

Trong mỗi mô hình triển khai, vai trò của người quản trị cơ sở dữ liệu là đảm bảo rằng SSRS là ổn định, đáng tin cậy và có thể phục hồi. Phần có thể khôi phục là thứ gây ra một số vấn đề về DBA. Cơ sở dữ liệu ReportServer được mã hóa và các hoạt động nhất định yêu cầu khôi phục khóa đối xứng. Nếu có sự cố và cơ sở dữ liệu phải được khôi phục sang một máy chủ khác, tên tài khoản hoặc mật khẩu dịch vụ Windows của Máy chủ Báo cáo bị thay đổi, tên máy tính bị thay đổi, bạn di chuyển sang máy chủ khác hoặc bạn thêm máy chủ mới vào một quy mô- ngoài cấu hình, bạn sẽ được yêu cầu khôi phục khóa mã hóa. Trừ khi khóa được sao lưu, mọi dữ liệu được bảo vệ, chẳng hạn như chuỗi kết nối và mật khẩu, đều không thể được giải mã. Tôi nhận thấy rằng nhiều DBA không biết về điều này cho đến khi quá muộn. Khóa có thể được sao lưu và khôi phục theo cách thủ công bằng Trình quản lý cấu hình dịch vụ báo cáo, sử dụng tiện ích rskeymgmt.exe hoặc sử dụng PowerShell. Về mặt kỹ thuật, bạn chỉ cần sao lưu một bản sao của khóa đối xứng.

Cơ sở dữ liệu ReportServer và ReportServerTempDB là cơ sở dữ liệu SQL Server và phải là một phần của quy trình sao lưu thường xuyên, giống như các cơ sở dữ liệu người dùng khác. ReportServer nên sử dụng mô hình khôi phục đầy đủ trong khi ReportServerTempDB có thể sử dụng mô hình khôi phục đơn giản. Về mặt kỹ thuật, ReportServerTempDB có thể được tạo lại bằng tập lệnh trong trường hợp xảy ra thảm họa, tuy nhiên Dịch vụ báo cáo không thể khởi động mà không có ReportServerTempDB. Các DBA quen thuộc với việc khôi phục cơ sở dữ liệu, thay vì tìm kiếm một tập lệnh để tạo lại cơ sở dữ liệu. Không giống như tempdb cơ sở dữ liệu hệ thống, ReportServerTempDB không được tạo lại khi khởi động. Phương pháp hay nhất cho DBA thực sự là chỉ coi ReportServer và ReportServerTempDB giống như bất kỳ cơ sở dữ liệu người dùng nào khác.

Có những tệp cấu hình lưu trữ cài đặt ứng dụng cũng cần được sao lưu. Những điều này có thể được bao phủ bởi các bản sao lưu cấp hệ điều hành của bạn; tuy nhiên, DBA phải đảm bảo các tệp này được sao lưu sau khi cấu hình ban đầu và / hoặc sau khi áp dụng bất kỳ phần mở rộng tùy chỉnh nào. Các tệp này bao gồm:

• Rsreportserver.config
• Rssvrpolicy.config
• Rsmgrpolicy.config
• Reportingservciesservice.exe.config
• Web.config
• Machine.config

Cân nhắc sao lưu các tệp Trình thiết kế báo cáo của bạn chẳng hạn như; Các tệp .rdl, .rds, .dv, .ds, rptproj và .sln nên được cung cấp.

Tùy chọn điều chỉnh

Điều chỉnh SSRS cũng giống như bất kỳ ứng dụng nào khác. Người dùng đang thực hiện báo cáo từ máy chủ ứng dụng đang giao tiếp với cơ sở dữ liệu. Sự khác biệt lớn là bạn có một máy chủ ứng dụng (Dịch vụ Báo cáo) với cơ sở dữ liệu của riêng nó, nhưng báo cáo có các nguồn dữ liệu kết nối với cơ sở dữ liệu người dùng khác. DBA phải điều chỉnh tình trạng chung của cơ sở hạ tầng Dịch vụ báo cáo cũng như điều chỉnh các báo cáo thực tế.

Cơ sở hạ tầng Dịch vụ Báo cáo

Độ trễ đĩa cho ReportServer và ReportServerTempDB là rất quan trọng. Tùy thuộc vào khối lượng công việc, những cơ sở dữ liệu đó có thể cần được đặt trên các đĩa nhanh hơn. Bộ nhớ đệm của kết quả báo cáo được lưu trữ trong cơ sở dữ liệu ReportServerTempDB và hiệu suất I / O có thể trở thành một vấn đề ở đây.

Khối lượng công việc của Dịch vụ báo cáo có thể quy định rằng cần có các phiên bản Dịch vụ báo cáo bổ sung để xử lý khối lượng công việc đó. Triển khai quy mô lớn yêu cầu giấy phép Phiên bản Doanh nghiệp. Lợi ích của việc triển khai theo quy mô bao gồm cung cấp cho khách hàng cân bằng tải để có thông lượng cao hơn, tính sẵn sàng cao cũng như khả năng phân đoạn xử lý máy chủ báo cáo.

Hãy tận dụng Ảnh chụp nhanh ở những nơi chúng có ý nghĩa. Nếu bạn có các báo cáo đang sử dụng dữ liệu cũ, hãy cân nhắc sử dụng Ảnh chụp nhanh để các chế độ xem tiếp theo của báo cáo đó đang sử dụng Ảnh chụp nhanh thay vì phải tạo lại toàn bộ báo cáo.

Đăng ký theo hướng dữ liệu có thể được sử dụng để chạy báo cáo và cung cấp nội dung dựa trên cơ sở người đăng ký và theo lịch trình. Dựa trên lịch trình, nhiều báo cáo trong số này có thể được chạy sau khi quá trình xử lý dữ liệu hoàn tất, trước khi người dùng đến nơi làm việc, trong thời gian ít bận rộn hơn cho môi trường.

Các DBA nên quen thuộc với việc ghi nhật ký thực thi vì điều đó có thể giúp xác định các báo cáo có thể là ứng cử viên cho bộ nhớ đệm cũng như các báo cáo cần được xem xét để cải thiện hiệu suất dựa trên xử lý thực thi. Ghi nhật ký thực thi cung cấp thông tin chi tiết về những thứ như tần suất chạy báo cáo, định dạng được yêu cầu nhiều nhất và tỷ lệ xử lý gắn với một giai đoạn của quy trình báo cáo. Dữ liệu này có thể được truy cập bằng cách sử dụng các dạng xem tích hợp cho ExecutionLog, ExecutionLog2 và ExecutionLog3.

Điều chỉnh chung

Đối với cơ sở dữ liệu người dùng đang được sử dụng bởi các báo cáo và phiên bản giữ ReportServer và ReportServerTempDB, bạn muốn theo dõi và đánh giá hiệu suất cơ sở. Bạn cần theo dõi việc sử dụng bộ nhớ / đĩa / CPU, I / O mạng, sử dụng tempdb, số lần chờ và các bộ đếm khác để biết khối lượng công việc tổng thể của các hệ thống đó là như thế nào. Nếu người dùng bắt đầu báo cáo sự cố, bạn cần biết liệu việc sử dụng hiện tại có bình thường hay không. Nếu bạn không theo dõi nó, làm thế nào bạn có thể đo lường nó?

Ngoài việc giám sát và kiểm tra cơ sở, các phương pháp hay nhất được ngành công nghiệp chấp nhận cũng nên được áp dụng. Tôi đã đề cập đến cài đặt bộ nhớ, duy trì chỉ mục, thống kê, MAXDOP và ngưỡng chi phí cho tính song song trong bài viết trước, Những rủi ro máy chủ SQL thường gặp.

Điều kỳ diệu thực sự để làm cho báo cáo chạy nhanh hơn là tối ưu hóa cho báo cáo đó. Một báo cáo về cơ bản chỉ là một truy vấn khác. Để điều chỉnh báo cáo chậm, điều đó thường có nghĩa là bạn cần tạo chỉ mục cho báo cáo cụ thể đó hoặc điều chỉnh mã trong báo cáo. Nếu đây là những báo cáo đang tấn công cơ sở dữ liệu OLTP, thì việc tạo chỉ mục cho báo cáo có thể ảnh hưởng đến hệ thống OLTP bằng cách sử dụng nhiều dung lượng hơn, tạo thêm I / O để cập nhật, chèn và xóa và phát sinh thêm chi phí để duy trì các chỉ mục đó. Bạn phải cân bằng giữa rủi ro và phần thưởng. Một số khách hàng có thể tách cơ sở dữ liệu báo cáo khỏi OLTP bằng cách sử dụng sao chép giao dịch và điều này cho phép lập chỉ mục cơ sở dữ liệu báo cáo mà không ảnh hưởng đến cơ sở dữ liệu OTLP.

Mặc dù bạn có thể theo dõi việc sử dụng báo cáo bằng ExecutionLog, nhưng bạn sẽ cần nghiên cứu trường hợp cơ sở dữ liệu người dùng để biết các truy vấn có chi phí cao và chạy lâu để điều chỉnh các cơ hội. DMV và Cửa hàng truy vấn cũng là một trợ giúp rất lớn, nhưng một công cụ giám sát như SQL Sentry có thể mạnh mẽ và linh hoạt hơn nhiều. SQL Sentry không có "Bảng điều khiển Dịch vụ Báo cáo", nhưng bạn có thể tạo chế độ xem lịch của các sự kiện SSRS, dễ dàng lọc các chỉ số và báo cáo tích hợp để tập trung vào hoạt động SSRS và tạo Điều kiện Tư vấn mạnh mẽ để theo dõi các khía cạnh chính xác của Dịch vụ Báo cáo mà bạn quan tâm (và không có tiếng ồn nào mà bạn không làm). Ngay cả khi bạn không chạy SSRS trên máy SQL Server, bạn vẫn có thể sử dụng Win Sentry để có được thông tin chi tiết về hiệu suất phong phú về hoạt động cấp dịch vụ và quy trình hiện tại và lịch sử.

Kết luận

Điều chỉnh Dịch vụ báo cáo SQL Server có một số đặc điểm riêng, tuy nhiên, điều chỉnh hiệu suất tiêu chuẩn vẫn có thể áp dụng để tối ưu hóa báo cáo và giám sát cơ sở dữ liệu ReportServer và ReportServerTempDB. Sao lưu khóa mã hóa là cần thiết cho bất kỳ nỗ lực di chuyển hoặc khôi phục sau thảm họa nào. Để hiểu rõ hơn về việc sử dụng các báo cáo, các DBA nên bắt đầu sử dụng ExcecutionLog.