Tạo một bản sao chỉ đọc của cơ sở dữ liệu SQL Server cho các báo cáo


7

Tôi đã gặp phải một vấn đề khi ứng dụng web .Net của tôi chạy chậm, ngay cả khi tôi đã tối ưu hóa tất cả các truy vấn. Khi nó bật ra một nhà phát triển khác, người đang thực hiện các báo cáo chạy một loạt các truy vấn không được tối ưu hóa mọi lúc. Vì vậy, tôi đã quyết định tạo một máy chủ riêng cho anh ấy. Hiện tại tôi đã tạo Jobs để sao lưu, sao chép nó sang một máy chủ khác và khôi phục nó. Nhưng đó là giải pháp tạm thời, vì vậy để máy chủ thứ hai có dữ liệu cập nhật hoặc ít nhất là với độ trễ tối thiểu, tôi đang nghiên cứu một cơ hội để tạo bản sao chỉ đọc.

Vì tôi không phải là một DBA Tôi đã đọc một loạt hoặc các bài viết liên quan đến cơ chế sao chép của SQL Server. Tùy chọn tốt nhất cho tôi là khi ứng dụng web SẢN PHẨM của tôi không bị ảnh hưởng bởi sự sao chép, ý tôi là rất nhiều khóa trên các bảng đồng bộ hóa. Tôi không cần đồng bộ hóa thời gian thực như phản chiếu, tôi cũng không cần bất kỳ giải pháp cụm nào, chỉ đọc bản sao đồng bộ hóa cơ sở dữ liệu SẢN PHẨM của tôi. Vì vậy, tôi đã chọn Transactionalcơ chế sao chép (không thể cập nhật) với chính sách phân phối không đồng bộ (theo lịch trình).

Vì vậy, tôi có một số câu hỏi:

  1. Bản sao giao dịch có phù hợp với vấn đề của tôi nhất trong số các cơ chế sao chép của SQL Server không?

  2. Nếu tôi có cơ hội di chuyển từ SQL Server 2008 sang SQL Server 2012, liệu sao chép giao dịch có một số thay đổi đột phá không? Tôi đã đọc một bài viết về Technet rằng có thể xảy ra lỗi?

  3. Không phải Always Oncơ chế SQL Server 2012 tốt hơn để giải quyết vấn đề của tôi (Tôi đang xem xét tùy chọn này là lựa chọn cuối cùng, vì tôi vẫn đang sử dụng 2008 R2, và việc di chuyển sang năm 2012 sẽ được lên kế hoạch sớm)?

Câu trả lời:


10

Bản sao giao dịch có phù hợp với vấn đề của tôi nhất trong số các cơ chế sao chép của SQL Server không?

Trong số tất cả các tùy chọn nhân rộng - Âm thanh giao dịch giống như nó là thứ giúp bạn nhiều nhất ở đây. Nó cho độ trễ tối thiểu và nó không cần phải (nhưng có thể) hai chiều. Bạn không hợp nhất các thay đổi và không cần ngang hàng.

Điều đó nói rằng - Sao chép không "miễn phí" - bạn cần quản trị và giám sát nó và một thiết lập kém có thể làm cho vấn đề hiệu suất trở nên tồi tệ hơn. Bạn nên tìm hiểu về các tùy chọn tốt nhất cho hiệu suất và thiết lập tốt nhất cho hiệu suất và ghi nhớ điều đó và theo dõi môi trường nhân rộng của bạn.

Nhân rộng giao dịch "dễ dàng" hơn so với nhân rộng Hợp nhất. Nhưng điều đó không có nghĩa là bạn sẽ luôn có một cánh buồm mượt mà và luôn có thể thoát khỏi mà không cần ai đó có kinh nghiệm nhân rộng giúp đỡ.

Nếu tôi có cơ hội chuyển từ SQL Server 2008 sang SQL Server 2012, liệu sao chép giao dịch có thay đổi gì không? Tôi đã đọc một bài viết về Technet rằng có thể xảy ra lỗi?

Thật không may, đây là một loại câu hỏi "nó phụ thuộc". Về mặt lý thuyết chúng tôi có thể cung cấp cho bạn câu trả lời từ kinh nghiệm của chúng tôi, nhưng bạn sẽ cần phải kiểm tra. Nếu bạn va vào các vấn đề thì chúng không nhất thiết là những vấn đề không thể mà bạn không thể khắc phục, chúng sẽ yêu cầu thử nghiệm và điều chỉnh.

Không phải SQL Server 2012 Luôn bật cơ chế tốt hơn để giải quyết vấn đề của tôi (Tôi đang xem xét tùy chọn này là lựa chọn cuối cùng, vì tôi vẫn đang sử dụng 2008 R2, và việc di chuyển đến năm 2012 sẽ không được lên kế hoạch sớm)?

Trong SQL Server 2012 Luôn luôn có một cái gì đó cho bạn ở đây có khả năng hoạt động. Các nhóm sẵn có là một câu trả lời ở đây với khái niệm về một Hoạt động thứ cấp cho mục đích đọc. Nhưng có những lo ngại về cấp phép - bạn cần phải ở trong Doanh nghiệp trên cả chính và chỉ đọc / hoạt động thứ cấp. Với phương pháp nhân rộng, bạn vẫn cần phải được cấp phép ở cả hai đầu, nhưng đây là một lựa chọn tốt cho chắc chắn. Nó cũng có chi phí liên quan và một số vấn đề hành chính mà bạn nên tìm hiểu - nhưng nó là một lựa chọn tuyệt vời.


5

Tôi không cần đồng bộ hóa thời gian thực như phản chiếu, tôi cũng không cần bất kỳ giải pháp cụm nào, chỉ đọc bản sao đồng bộ hóa cơ sở dữ liệu SẢN PHẨM của tôi.

Như Mike đã đề cập, T-Rep không miễn phí. Bạn phải duy trì cơ sở dữ liệu nhà phân phối và có sự phụ thuộc vào tác nhân log-reader. Nếu số lượng thay đổi xảy ra trên Ấn phẩm lớn và tùy thuộc vào độ trễ của mạng, sẽ có các lệnh được tích lũy trong cơ sở dữ liệu phân phối chờ tác nhân đọc nhật ký quét và gửi chúng đến thuê bao. Thay đổi lược đồ sẽ yêu cầu một ảnh chụp nhanh mới - điều này gây ra khóa trên cơ sở dữ liệu xuất bản cho đến khi ảnh chụp nhanh kết thúc. Ngoài ra, sao chép toàn bộ cơ sở dữ liệu trái ngược với một tập hợp con dữ liệu (các bảng được chọn, SP, v.v.) thường dẫn đến các vấn đề liên quan đến bảo trì của nó.

Dựa trên tình hình của bạn, tôi muốn giới thiệu logshipping . Nó dễ dàng để thiết lập và có sự phụ thuộc tối thiểu (chia sẻ mạng - nên có quyền thích hợp).

Điểm hay của logshipping là bạn có thể có cơ sở dữ liệu thứ cấp dưới dạng chỉ đọc ở chế độ STANDBY.

Bạn có thể trì hoãn việc khôi phục bản sao lưu nhật ký trên thứ cấp .

Lưu ý: nếu bạn sử dụng logshipping với tùy chọn STANDBY, cơ sở dữ liệu thứ cấp có thể ở phiên bản cao hơn của máy chủ sql so với máy chủ chính.


0

Mike là một điểm tốt về sao chép giao dịch. Chúng tôi có tình huống tương tự và tôi đang cố gắng để Giao dịch sao chép hoạt động vào lúc này, nó vẫn hoạt động như vậy, nhưng nếu tôi thêm một bài viết mà tôi biết đang tạo ra nhiều Xóa và Chèn khiến DB phân phối bị sa lầy ở phía Nhà xuất bản ( đó là một trong những cảnh báo với sao chép giao dịch). Đây là câu hỏi của tôi:

Cơ sở dữ liệu phân phối sao chép giao dịch SQL Server không theo kịp

Tôi vẫn đang cố gắng tìm hiểu tại sao Phân phối DB không theo kịp nhà xuất bản. Hy vọng rằng môi trường của bạn sẽ không tạo ra nhiều thay đổi này và bạn sẽ ổn với việc sao chép giao dịch, vì đó có vẻ là điều tốt nhất cho cách tiếp cận của bạn.

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.