Làm cách nào để xử lý báo cáo về số lượng cơ sở dữ liệu cực lớn trong SQL Server 2005?


7

Tôi đang tìm kiếm một số lời khuyên về cách xử lý báo cáo cho môi trường của chúng tôi. Chúng tôi hiện có 16 máy chủ với 20 phiên bản SQL Server 2005. Chúng tôi có hơn 6.600 cơ sở dữ liệu và đang phát triển trên các phiên bản này (1 cơ sở dữ liệu cho mỗi khách hàng). Phần lớn các cơ sở dữ liệu của chúng tôi chạy ở kích thước từ 200mb đến 7gb với khoảng 60 cơ sở dữ liệu chạy ở kích thước lớn nhất từ ​​11GB đến 110 gb.

Chúng tôi đang sử dụng SAN để lưu trữ và chúng tôi đang gặp vấn đề với việc chạy các báo cáo ảnh hưởng đến IO.

Một ý tưởng chúng tôi đã có là kéo 60 cơ sở dữ liệu lớn hơn và sau đó sử dụng sao chép giao dịch để sao chép các cơ sở dữ liệu này và chạy báo cáo trên các bản sao.

Điều đó sau đó sẽ để lại tất cả các cơ sở dữ liệu nhỏ hơn để chạy mà không có sự căng thẳng của các cơ sở dữ liệu lớn hơn. Trong tương lai, chúng tôi không tin rằng sẽ có thêm bất kỳ cơ sở dữ liệu lớn hơn dựa trên các mục tiêu của công ty chúng tôi.

Có suy nghĩ gì không?


Bạn có Dịch vụ phân tích trong hỗn hợp này?
Atilla Ozgur

Không, chúng tôi không có dịch vụ Phân tích tại thời điểm này. Chúng tôi đang sử dụng các dịch vụ báo cáo với các procs được lưu trữ được lưu trữ trong cơ sở dữ liệu khách hàng của oltp.
pamozer

1
Thêm một chút thông tin để yêu cầu. Ai đang tiêu thụ những báo cáo này? Chúng có phải là nội bộ không, hay chúng là các báo cáo mà bạn đã tạo cho khách hàng của mình? Khách hàng có được phép chạy truy vấn đặc biệt không? Điều gì về phân phối múi giờ. Tất cả đều là những rào cản đơn giản, nhưng câu trả lời sẽ đi một chặng đường dài trong việc giúp chọn kiến ​​trúc của bạn.
swasheck

1
Bạn phải báo cáo điều gì? Dữ liệu báo cáo có thể được tính toán trước (hàng đêm hoặc ad-hoc, tức là các chế độ xem được lập chỉ mục) không? Các truy vấn báo cáo có mạnh mẽ không - các bảng OLTP có thể được lập chỉ mục sao cho các báo cáo thực hiện quét chỉ mục thay vì quét bảng (rất có thể bạn đã có chỉ mục - chúng có gần với những gì cần thiết để báo cáo không)? Là kích thước lưu trữ là một hạn chế? Làm thế nào là hệ thống hiện tại bị vấn đề I / O? Không đủ thông lượng? Sự tham gia của các bản quét lớn và OLTP viết? Tỷ lệ hoạt động của ứng dụng của bạn được viết (so với đọc)?
Jon Seigel

Câu trả lời:


9

Trong cửa hàng của chúng tôi tại công việc trước đây của chúng tôi, chúng tôi đã có một bộ máy chủ thứ cấp nơi chúng tôi đã thử nghiệm khôi phục. Đối với những khách hàng bận rộn nhất của chúng tôi, chúng tôi sẽ khôi phục bản sao lưu tối nay, đánh dấu nó là read_only và báo cáo của họ vào ngày mai sẽ kết nối với bản sao cơ sở dữ liệu đó cho tất cả các báo cáo từ ngày hôm qua. Điều này đã giảm khoảng 90% khối lượng công việc báo cáo và tăng gấp đôi như một phương thức xác thực sao lưu / khôi phục. Vì vậy, nếu hầu hết các báo cáo không cần dữ liệu ngày nay, bạn có thể xem xét giảm bớt một số khối lượng công việc sản xuất theo cách này với một số phần cứng rẻ hơn - nếu bạn không sử dụng các tính năng Enterprise, bạn thậm chí có thể sử dụng Express cho tất cả các cơ sở dữ liệu <10GB. (Chà, tôi thấy đó là năm 2005, có giới hạn kích thước DB thấp hơn, nhưng bạn luôn có thể khôi phục bản sao của mình vào năm 2008 / R2.


1
Ý tưởng thú vị. Mối quan tâm của tôi sẽ được khôi phục các dbs hơn 20gbs mỗi đêm. Và điều đó sẽ mất bao lâu. Và nếu khôi phục vì một số lý do không thành công, điều tuyệt vời cần biết cho mục đích thử nghiệm, sẽ không tốt cho khách hàng của chúng tôi, những người bây giờ không thể nhận được báo cáo của họ.
pamozer

1
Tôi không biết việc khôi phục của bạn sẽ mất bao lâu, quá nhiều biến số. Nhưng có gì tốt khi lấy một bản sao lưu nếu bạn không kiểm tra rằng nó thực sự là một bản sao lưu tốt (bằng cách khôi phục)? Nếu khôi phục thất bại, có một số cách để ứng dụng của bạn có logic về việc liệu nó có thể sử dụng bản sao lưu hay sẽ quay trở lại bản sao sản xuất. Điều này sẽ dễ dàng TRY / CATCH trong trường hợp khôi phục khiến bản sao không thể sử dụng được, nhưng một số cách khác để công việc khôi phục đăng nhập vào một nơi nào đó đã thành công - ứng dụng có thể kiểm tra cờ đó trước để đảm bảo rằng khôi phục tối qua hoạt động.
Aaron Bertrand

2

Vào năm 2005, tôi có thể nghĩ ra ba chiến lược để giảm tải báo cáo: 1. Dữ liệu cũ sử dụng vận chuyển nhật ký (vận chuyển nhật ký để chờ người dùng loại bỏ mỗi lần khôi phục, do đó, việc khôi phục thực tế chỉ có thể xảy ra khi họ không mong đợi được bật, như vào buổi tối.) Ưu điểm - cập nhật gia tăng. 2. Dữ liệu cũ sử dụng khôi phục đầy đủ. Nhược điểm: phục hồi đầy đủ. 3. Nhân rộng. Điều này mang lại trải nghiệm người dùng tốt nhất, nhưng khó hơn / tốn nhiều nhân lực hơn để thiết lập và duy trì.

Ngoài ra - có bất kỳ lợi thế nào khi chỉ tăng phần cứng có sẵn cho các khách hàng lớn, điều chỉnh và cách ly họ, thay vào đó? Đủ đĩa và bộ nhớ? Tốc biến? Tối ưu hóa chỉ số? Thực sự họ không nghe lớn như vậy theo tiêu chuẩn ngày nay (phải thừa nhận rằng tôi chưa thấy hệ thống của bạn)


1
Nhật ký vận chuyển cũng là một thứ tốt, tuy nhiên tôi có thể xen kẽ nó với việc làm mới hoàn toàn một lần một tuần hoặc mỗi tuần một lần. Tôi có một vài đồng nghiệp với vận chuyển đăng nhập thay thế cho kịch bản chính xác này và họ phải khởi tạo lại mỗi lần một lần - một người nói "vận chuyển nhật ký bị kẹt" và, trong khi tôi không đủ gần để xem chính xác điều gì có nghĩa là trong trường hợp của họ, nó có vẻ khá quen thuộc.
Aaron Bertrand

Hấp dẫn. Chúng ta chưa bao giờ có chuyện đó xảy ra (điều đó không có nghĩa là nó không bao giờ xảy ra với người khác). Gõ gỗ.
onupdatecascade

0

Đi với nhân rộng giao dịch.

Như đã đề cập trong Kho dữ liệu và báo cáo , Sao chép giao dịch rất phù hợp cho các tình huống báo cáo bằng cách cung cấp:

  • Thống nhất giao dịch

  • Độ trễ thấp

  • Thông lượng cao

  • Chi phí tối thiểu

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.