Cơ sở dữ liệu nội bộ kém - thay thế nó hoặc chuck phần cứng tại nó?

Vì vậy - chúng tôi có một cơ sở dữ liệu công ty nội bộ, loại công cụ thông thường: quản lý khách hàng, gọi điện thoại, giao dịch bán hàng và thỏa thuận / kế hoạch khách hàng.

Đó là một front-end Access 2000 và một back-end SQL Server 2000 Standard. Máy chủ đơn, Xeon kép 3,2 GHz, RAM 2 GB, Windows Server 2003, tải CPU khoảng 40% cả ngày, trải đều trên 4 lõi mà HĐH (HT) có thể nhìn thấy.

Cơ sở dữ liệu phụ trợ được thiết kế kém và đã phát triển hữu cơ hơn 10 năm, được duy trì bởi các cá nhân kém kỹ năng. Nó được chuẩn hóa rất tệ và một số vấn đề rõ ràng bao gồm các bảng có hàng chục nghìn hàng không có khóa hoặc chỉ mục chính, cũng được sử dụng nhiều trong các phép nối nhiều bảng cho một số phần được sử dụng nhiều nhất của hệ thống (ví dụ: ứng dụng quản lý cuộc gọi nằm trên màn hình thứ hai của mọi người trong 8 giờ mỗi ngày và chạy một truy vấn không hiệu quả lớn cứ sau vài giây).

Giao diện người dùng không tốt hơn nhiều, đó là mớ hỗn độn điển hình của hàng trăm biểu mẫu, truy vấn đã lưu lồng nhau, SQL nhúng kém trong mã VBA, hàng tá "quirks", v.v. và bất cứ khi nào thay đổi được thực hiện đều có vẻ không liên quan. Chúng tôi đã giải quyết một MDB hoạt động "đủ tốt" và hiện có chính sách không thay đổi về điều đó vì chúng tôi không có đối thủ nặng ký trong nhà (và cũng không có kế hoạch thuê một).

Công ty hiện đang tăng trưởng chậm, tăng số lượng khách hàng, cuộc gọi, v.v., cũng như sự gia tăng khiêm tốn về số lượng người dùng đồng thời và hiệu suất đã trở nên tồi tệ đáng chú ý chỉ gần đây (chờ chuyển giữa các biểu mẫu, chờ danh sách xuất hiện, v.v. )

Perfmon nói:

• Chuyển đĩa mỗi giây: từ 0 đến 30, trung bình 4.
• Chiều dài hàng đợi đĩa hiện tại: dao động khoảng 1

Trình hồ sơ của SQL Server thấy hàng trăm ngàn truy vấn mỗi phút. Việc sử dụng CPU trên các máy khách gần như bằng không, cho thấy nó đang chờ các truy vấn phía máy chủ để thực thi. Tôi đã đặt khối lượng công việc này thông qua Trình cố vấn điều chỉnh động cơ DB, áp dụng các đề xuất của nó cho bản sao lưu thử nghiệm, nhưng điều này thực sự không có nhiều khác biệt.

Nhân tiện, chúng tôi có sự kết hợp của ethernet 100MB và gigabit, tất cả trên một mạng con, 40 người dùng ish trên hai tầng.

Cho câu hỏi.

Theo tôi thấy, chúng tôi có hai lựa chọn để giải quyết / cải thiện tình trạng này.

• Chúng tôi có thể loại bỏ nó và thay thế nó bằng một hệ thống CRM hoàn toàn mới, bespoke hoặc một phần bespoke
• Chúng ta có thể kéo dài tuổi thọ của hệ thống này bằng cách sử dụng phần cứng.

Chúng tôi có thể xây dựng một hệ thống Intel i7 với số hiệu năng điên rồ với chi phí thấp hơn so với việc thay thế phần mềm.

Khi một hệ thống mới cuối cùng được phát triển, nó có thể được lưu trữ trên hộp này, do đó không có phần cứng bị lãng phí. Một hệ thống CRM mới liên tục bị tắt, tắt và tắt - Tôi không thấy điều đó xảy ra trong ít nhất một năm.

Bất kỳ suy nghĩ về tình huống này, đặc biệt là nếu bạn đã từng ở đây, sẽ được đánh giá cao nhất.

Cảm ơn

Tôi sẽ không đồng ý với mọi người ở đây. Chuck một số phần cứng tại nó. Đó là giá rẻ, nhanh chóng, dễ dàng và sẽ giúp bạn có thời gian cần thiết để thực hiện một giải pháp CRM phù hợp. Lý do tôi ủng hộ điều gì đó là sự vô cảm đối với tất cả mọi người không chỉ trong hội đồng này, mà cả stackoverflow, là tôi đã từng là người quản lý / quản lý dự án và đã ở bên "Kinh doanh" một thời gian (kinh doanh là trong trích dẫn do sự ghét bỏ của tôi đối với từ này). Dựa trên mô tả của bạn về phần mềm, sẽ mất gần một năm để xây dựng lại một cái gì đó khác. Chỉ cần khám phá / ghi lại các quy tắc kinh doanh / quirks, có thể sẽ mất 2 tháng. Nó cũng sẽ tốn kém không thể tin được để phát triển. Đặc biệt là khi so sánh với chi phí của một máy chủ bị lừa.

Tôi thực sự sắp lưu trữ một bộ ứng dụng web cho một công ty chỉ vì lý do đó. Bộ phận CNTT nội bộ sẽ không chuyển nó sang phần cứng tốt hơn vì họ muốn phát triển lại chúng trên nền tảng mới. Chi phí đó xấp xỉ gấp ba lần chi phí để chuyển nó sang phần cứng mới. Không quá đề cập rằng công ty có thể không được gia hạn hợp đồng trong một năm.

Bạn có thể không cần phải làm một trong hai. Đề nghị của tôi là chỉ cần thêm một số chỉ mục / khóa vào bảng.

các bảng có hàng chục nghìn hàng không có khóa hoặc chỉ mục chính, cũng được sử dụng nhiều trong các phép nối nhiều bảng

Trước khi chi nhiều tiền hoặc thời gian, hãy dành vài giờ và thêm các chỉ mục (hoặc khóa chính nếu bạn có thể) vào bất kỳ bảng nào liên quan đến các phép nối đó ... đặc biệt cho các cột được sử dụng trong mệnh đề where. Bạn có thể dễ dàng cải thiện hiệu suất theo hệ số 10 chỉ sau vài giờ.

Việc thiếu I / O đĩa ngụ ý rằng các truy vấn được cung cấp chủ yếu từ RAM. Nếu bạn 'đột nhiên' có các bảng nóng không còn phù hợp với RAM nữa và máy chủ bắt đầu làm việc với các đĩa, bạn có thể đang ở trong một chuyến đi tồi tệ. 2GB hoặc RAM không nhiều lắm trong những ngày này, nhưng trở lại thời kỳ SQL2000, nó sẽ có kích thước lớn. Tôi đoán rằng lượng dữ liệu mà ứng dụng thường thao tác nhỏ hơn RAM mà bạn có. Bạn có thể muốn xem xét dung lượng "đã sử dụng" trong các tệp dữ liệu. Điều này sẽ cho bạn ý tưởng về việc cơ sở dữ liệu có thể tiêu thụ bao nhiêu RAM, trong trường hợp xấu nhất. SQL Server không giữ dữ liệu mà nó không cần trong RAM, nhưng có thể khó biết được bảng nào được sử dụng và khi nào.

Siêu phân luồng không phải lúc nào cũng hữu ích với SQL Server. Bạn có thể có hiệu suất tốt hơn tắt nó đi. Thật khó để kiểm tra vì lật nó lên và yêu cầu khởi động lại, và đó là một rắc rối lớn trên máy chủ sản xuất.

"Hàng trăm ngàn truy vấn một phút" chuyển thành hàng nghìn truy vấn một giây. Nghe có vẻ khá bận rộn, nhưng phần lớn lưu lượng truy cập đó có thể chỉ là con trỏ tìm nạp bởi Access. Truy cập đặc biệt tệ trong việc truy xuất hiệu quả các tập kết quả từ SQL. Bạn có thể có hiệu suất tốt hơn bằng cách tắt cài đặt song song SQL Server.

Bạn cũng muốn tìm kiếm chặn. Ném phần cứng vào một vấn đề chặn không phải lúc nào cũng tạo ra sự cải thiện đáng mong đợi. Nếu không có nhiều chặn và các truy vấn được thỏa mãn bởi RAM, thay vì đĩa, thì về cơ bản, bạn đang dựa vào tiếng cằn nhằn của bộ xử lý và khả năng kéo dữ liệu của chúng qua các kênh bộ nhớ. Trong trường hợp đó, phần cứng nhanh hơn nên cung cấp một cải tiến tốt. Nếu bạn đang vội (để vượt qua vấn đề này) và phát triển chậm, điều đó có thể đủ tốt.

Là một giải pháp, việc thêm phần cứng không mở rộng quy mô cũng như cải thiện cơ sở dữ liệu. Nếu bạn có sự tăng trưởng đột biến, bạn có thể thấy phần cứng mới của mình gặp khó khăn. Một suy nghĩ khác là các ứng dụng thành công thu hút người dùng. Nếu ứng dụng trở nên nhạy hơn, người dùng có thể chạy nhiều báo cáo hơn và tương tự như vậy nếu họ cần đi uống cà phê trong khi chờ báo cáo kết thúc.

Nếu lược đồ cơ sở dữ liệu thực sự xấu, bạn có thể có được một số chiến thắng hiệu suất chỉ bằng cách xem chỉ mục trên các bảng. Tập trung vào các bảng mà bạn biết được truy vấn thường xuyên. Bạn có thể sử dụng Profiler để xem các truy vấn chạy trên máy chủ, chỉ cần yêu cầu nó tìm kiếm các truy vấn đọc nhiều dữ liệu (như 100.000 trang) và sau đó tìm kiếm các truy vấn không đọc nhiều. Bạn đã đề cập rằng một số bảng không có khóa. Có các khóa tự nhiên trong dữ liệu, chỉ không được thực thi bởi các ràng buộc hoặc các chỉ mục duy nhất?

Các bảng có chỉ mục cụm? Thiếu lập chỉ mục cụm có thể gây ra tất cả các loại hiệu ứng phụ.

Có rất nhiều chỉ mục không bao gồm, với nhiều cột? Đây thường là một nỗ lực để xây dựng nhiều chỉ số bao trùm, thay vì thực hiện chiến lược lập chỉ mục hiệu quả hơn. SQL Server có thể xây dựng hiệu quả các chỉ mục bao phủ một cách nhanh chóng trong một truy vấn, nếu nó hợp lý để làm như vậy và có hỗ trợ các chỉ mục không bao gồm và phân cụm.

Cuối cùng, đáng để hỏi: Việc bảo trì (reindexing và / hoặc cập nhật thống kê) có được thực hiện trên các bảng không?

Đây là một câu hỏi kinh doanh không phải là một câu hỏi kỹ thuật.

Là chủ doanh nghiệp: Hệ thống đối với doanh nghiệp như thế nào? càng ít chiến lược, tôi càng ít quan tâm và sửa chữa nó & bất kỳ khoản tiền nào đã bỏ ra, là tiền tôi có thể sử dụng ở nơi khác để phát triển doanh nghiệp của mình.

Dân gian máy tính làm tôi sợ khi tất cả họ vào một căn phòng lớn và tranh cãi về thiết kế và khiến tôi phải trả giá. Giữ cho hệ thống đi! cho dù điều này có nghĩa là điều chỉnh hiệu suất (không cần kiến ​​trúc lại) hoặc ném thêm phần cứng vào nó, đó chỉ là ưu tiên nếu nó ngừng hoạt động.

Là một nhà tư vấn CNTT: Hệ thống của bạn là di sản và có chi phí hoạt động ẩn. Chúng tôi có thể thiết kế một hệ thống phù hợp với bạn, sẽ mở rộng quy mô và cung cấp nền tảng cho lợi thế chiến lược và tăng trưởng trong tương lai. Ký vào đây & tất cả những giấc mơ của bạn sẽ trở thành sự thật.

Là một nhân viên IT: Tôi có thể trở thành siêu anh hùng ở đây và cứu công ty bằng cách ngăn chặn một thảm họa sắp xảy ra bằng cách tối ưu hóa địa ngục khỏi điều này! quản lý của tôi sẽ tặng tôi những món quà và lời khen ngợi vì tôi đã cứu hàng ngàn công ty.

Tôi nói làm cả hai.

Ngay bây giờ CPU của bạn ở mức 40% hoặc hơn như vậy bạn đã nói? Bạn có đang phàn nàn (rất nhiều) chưa? Nếu không bạn vẫn còn phòng thở. Nhiều bộ nhớ hơn có thể chỉ đủ để làm điều đó trong một thời gian.

Câu hỏi cho con đường để đi, bạn có nhà phát triển phần mềm nội bộ không? Nếu câu trả lời là KHÔNG thì thậm chí đừng cố gắng làm lại. Bạn sẽ kết thúc chính xác nơi bạn đang ở.

Giả sử bạn có nhà phát triển nội bộ, nhà phát triển nội bộ của bạn có khả năng thực hiện đúng dự án không? Tôi đang nói về dòng thời gian đầy đủ, chính xác (tương đối), về cơ bản giống như đó là một dự án của khách hàng. Nếu không, sau đó đừng bận tâm hoặc nó sẽ trở lại nơi bạn đang ở.

Cho đến khi các công ty liên quan đến họ, họ cũng là khách hàng của chính họ và cần cung cấp các nguồn lực tương tự cho các dự án nội bộ, bạn sẽ kết thúc chính xác nơi bạn đang ở. Ở đó, làm điều đó, có toàn bộ tủ áo phông.

Vì vậy, nếu bạn không thể thực hiện đúng cách, hai lựa chọn của bạn nằm ngoài chìa khóa xoay, điều mà nhân viên của bạn sẽ ghét vì giờ đây bạn phải lắp khuôn của hệ thống bạn mua. Hoặc nó sẽ có thể tùy chỉnh và bạn vẫn sẽ phải dành thời gian DỰ ÁN để tùy chỉnh nó.

HOẶC Tái cấu trúc những gì bạn có. Hãy nhớ rằng mọi người sẽ mong đợi tất cả các chức năng hoàn chỉnh giống nhau khi cái mới xuất hiện, vì vậy đó là lý do tại sao bất kỳ cách nào khác bạn phải làm mọi thứ cùng một lúc. Nếu bạn tính lại nó, bạn có cơ hội tìm ra cách thức hoạt động của nó và sau đó thay đổi đặc biệt, bạn lên kế hoạch cho nhiều dự án nhỏ.

Không nhìn thấy hệ thống, tôi có thể thấy về việc bình thường hóa hết mức có thể trong back-end, chuyển càng nhiều SQL vào các procs được lưu trữ. Sau đó, xây dựng một giao diện người dùng mới từ C # Forms hoặc webapp. Nếu bạn có thể đưa logic kinh doanh và SQL của bạn ra khỏi giao diện người dùng, việc làm lại sau này sẽ dễ dàng hơn. Bằng cách giữ những gì bạn làm cho các dự án nhỏ, nếu nó bị đẩy sang một bên bất cứ lúc nào hoặc dừng lại, bạn sẽ đạt được tiến bộ sẽ được sử dụng.

Một số câu trả lời tốt đã có ở đây- nhưng tôi có thể chỉ ra rằng (giả sử có nhà phát triển nội bộ) một lượng công việc tương đối nhỏ sẽ có tác động lớn - thêm khóa chính (thậm chí bạn không cần phải thay đổi tất cả các truy vấn của mình thành sử dụng chúng), thêm chỉ mục vào các trường bạn sử dụng và điều chỉnh truy vấn của bạn một chút và bạn có thể thấy mức tăng hoàn toàn lớn. Mua cho mình một số RAM cho nó ngay bây giờ để mua thời gian và khoảng trống bạn cần sửa, và sau đó đi làm.

Về chủ đề "sửa chữa hoặc bỏ nó", nếu các tính năng của hệ thống về cơ bản hoạt động cho bạn và làm những gì bạn cần, đừng viết lại bánh xe. Nếu người dùng của bạn phải tập thể dục để sử dụng thứ này vì nó không phù hợp với nhu cầu của bạn, thì không có lý do gì để nỗ lực vào nó.

Chà ... đây là một thời gian trước đây, nhưng tôi nghĩ rằng tôi đã ghi lại kết quả ở đây.

Cuối cùng, tôi bước qua dòng VBA để đối phó với một vấn đề khác. Đó là lúc tôi nhận ra rằng một số cuộc gọi để tìm nạp các hàng đã bị chặn trong 20-30 + giây.

Khi tôi tìm hiểu sâu về chúng, tôi thấy rằng các hàng dựa trên truy vấn MS Access.

Đó là chọn dữ liệu từ một truy vấn Access khác.

Đó là chọn dữ liệu từ một truy vấn Access khác.

Tất cả trông giống như chúng đã được kéo và thả lại với nhau bằng trình thiết kế truy vấn.

Tôi đã đi qua nửa tá điểm đau đầu của người dùng và thấy rằng không có thất bại, tất cả đều giống hệt như thế này.

Vì vậy, tôi đã loại bỏ hoàn toàn các ngăn truy vấn chuỗi và thay thế từng truy vấn bằng một truy vấn chuyển qua duy nhất có thể được viết bằng T-SQL và được thực hiện trực tiếp trên máy chủ.

Sự cải thiện là vô cùng lớn trong mọi trường hợp mà không thất bại và không còn phải chờ đợi truy vấn nữa cho bất kỳ ai.

Và sau đó tôi rời công ty. Không biết liệu nó có còn ở đó không ... nhưng tôi không bỏ lỡ nó.

Tôi đang đăng một câu trả lời riêng thay vì chỉ thêm vào câu trả lời của Dayton vì có một số chi phí mà một số người đầu tiên không tính đến để trả lời: Chi phí đào tạo lại người dùng và chi phí thay đổi thủ tục kinh doanh của bạn để phù hợp với một chương trình phần mềm mới. Nếu không, những gì anh nói.

Một trong những lý do chính khiến các công ty phát triển phần mềm của riêng họ là vì họ có các quy trình kinh doanh không phù hợp với thứ gì đó trên thị trường. Điều này thật tuyệt - thủ tục kinh doanh cá nhân của một công ty là một phần quan trọng của giá trị mà một công ty mang lại, và là lợi thế cạnh tranh mà một công ty có được trên phần còn lại của thị trường. Để thay thế phần mềm bằng một cái gì đó chung chung sẽ yêu cầu bạn đào tạo lại người của mình và hy sinh lợi thế cạnh tranh hoặc bạn phải tùy chỉnh giải pháp để phù hợp với quy trình kinh doanh của mình. Cả hai đều đắt tiền và tốn thời gian. Là một nhà tư vấn kinh doanh cũng như một sysadmin, tôi đã thấy những chi phí này tự giết chết các công ty nhỏ.

Từ các tuyên bố của bạn, có vẻ như bạn bị ràng buộc khá nhiều bộ xử lý / phần mềm. Tôi sẽ làm hai việc - thêm chỉ mục (trong giới hạn), đặc biệt là các cột hiện không sử dụng chúng. Và tôi sẽ chộp lấy bộ vi xử lý nhanh nhất mà bạn có thể sử dụng, bởi vì có vẻ như đó là nơi bạn ràng buộc nếu bạn không có nhiều ổ đĩa đọc được ở mức cao nhất.

(Ngoài ra, tôi sẽ nâng cấp phiên bản máy chủ càng nhiều càng tốt - vào thời điểm bạn đưa nó vào vị trí, Access 2000 và SQL Server 2000 sẽ được mười năm tuổi. Đó là OLD trong những năm máy tính!)

Điều này cần một cấu trúc lại tổng thể (tái kiến ​​trúc). Xây dựng lại hệ thống từ mặt đất lên. Điều này sẽ giúp bạn tiết kiệm rất nhiều trong thời gian dài (chi phí bảo trì). Đối với thời gian trung bình, chuck phần cứng tại nó. Tôi nghĩ rằng câu hỏi này là một "trường hợp kinh doanh" hơn là một cuộc điều tra kỹ thuật. Về mặt kỹ thuật, câu trả lời là "hoàn toàn có sức mạnh hơn". Kinh doanh khôn ngoan, Xây dựng một hệ thống mới!

Câu trả lời kỹ thuật:

Bạn đã có một loạt các đề xuất nêu rõ các khóa chính và lập chỉ mục cần được xem xét kỹ lưỡng. Access cũng thực sự thích sử dụng cột SQL Server TimeStamp hay còn gọi là RowVersion trên mỗi bảng vì điều này giúp giảm rất nhiều thời gian mà Access dành quyết định nếu một bản ghi đã bị thay đổi khi cập nhật các bản ghi.

Câu trả lời kinh doanh:

Một giải pháp CRM mới là rất nhiều công việc trong việc đào tạo mọi người và bạn sẽ không bao giờ kết thúc với một hệ thống phù hợp chính xác với yêu cầu kinh doanh của bạn.

Tôi sẽ tìm thấy một người truy cập tốt, người rất am hiểu về SQL Server và khiến họ dành 3 hoặc 6 tháng để bình thường hóa các bảng và khắc phục các điểm đau của người dùng. Đảm bảo rằng người đó làm việc trên các tầng saem như người dùng của bạn, mặc dù trong một không gian yên tĩnh và có thể truy cập được. Mặc dù không quá dễ tiếp cận. Các nhà phát triển không thích sự gián đoạn. S

Dựa trên thông tin đã cho, tôi sẽ thay thế hệ thống. Tốt nhất là với một CRM khác cho phép tích hợp linh hoạt với các hệ thống khác (điều đó sẽ làm tổn hại đến IS IS của bạn ).

Phần khó nhất sẽ là thuyết phục ban quản lý và người dùng cần nâng cấp.

Sự quản lý

Thể hiện mối quan tâm của bạn về các vấn đề kỹ thuật, hiệu suất thấp, sợ thất bại của Byzantine, v.v ... Sau đó trình bày 2 CRM thay thế. Nói về tích hợp kinh doanh, chiến lược ERP tổng thể cho doanh nghiệp và quan trọng nhất là làm thế nào điều này sẽ giúp nhân viên làm việc hiệu quả hơn và có lợi nhuận cao hơn. Sử dụng nghiên cứu trường hợp. Làm điều này không quá 15 phút (trừ khi họ muốn biết thêm thông tin). Sau đó, bạn cần thuyết phục người dùng.

Người dùng

Các kế hoạch đào tạo (mà một nhà cung cấp có thể cung cấp [và quản lý sẽ cần phải chứng thực]), tiếp tục liên lạc với 20% người dùng hàng đầu của bạn (những người sử dụng điện, những người gây rắc rối) và cam kết chắc chắn để giữ cho hệ thống hoạt động 100% trong tháng đầu tiên (tháng đầu tiên sẽ thực hiện hoặc phá vỡ bất kỳ IS mới nào).

Có rất nhiều sản phẩm CRM, hãy chọn một sản phẩm phù hợp nhất với nhu cầu kinh doanh của bạn.

Ném phần cứng vào nó chỉ khuyến khích thiết kế và quản lý kém hơn, cho đến khi hệ thống quá thảm hại, nó sẽ không chạy tốt trên cả phần cứng mới nhất và tốt nhất. Đã đến lúc xem xét một triển khai tốt hơn. Đầu tiên phân tích những gì được yêu cầu. Chỉ khi bạn hiểu đầy đủ các yêu cầu, bạn mới có thể bắt đầu xem xét cách tốt nhất để thực hiện chúng. Một khi bạn chắc chắn rằng bạn hiểu các yêu cầu bắt đầu xem xét liệu nó tốt hơn / hiệu quả hơn về chi phí để sửa đổi những gì bạn có hoặc bắt đầu lại từ đầu, có thể với một cái gì đó hoàn toàn khác.

Về lâu dài có lẽ bạn sẽ tốt nhất khi làm lại cơ sở dữ liệu. Ném thêm phần cứng vào nó sẽ giải quyết vấn đề của bạn trong một thời gian ngắn, nhưng nếu bạn tiếp tục sử dụng nó, bạn sẽ phải ném thêm phần cứng vào nó sau một thời gian ngắn.

Thông thường, khi có vấn đề về hiệu năng, bạn nhìn vào những thứ như tắc nghẽn trên đĩa cứng / RAID, bảo vệ cơ sở dữ liệu, v.v. Từ âm thanh của nó, ứng dụng của bạn sẽ không bao giờ có thể mở rộng được.

Về lâu dài, việc làm lại cơ sở dữ liệu và phần mềm giao diện người dùng để phản ánh tốt hơn nhu cầu kinh doanh hiện tại của bạn sẽ phục vụ bạn tốt hơn trong thời gian dài. Người dùng của bạn sẽ cảm ơn bạn, phần cứng của bạn sẽ tồn tại lâu hơn và về lâu dài sẽ tiết kiệm được nhiều tiền hơn so với việc ném phần cứng khổng lồ vào vấn đề này.

Theo mô tả của bạn, việc tạo ra một hệ thống bespoke hoàn toàn mới là vô nghĩa - bạn sẽ kết thúc ngay tại nơi bạn bắt đầu, hoặc thậm chí có thể tồi tệ hơn so với hiện tại. Vì vậy, trừ khi bạn có thể thuyết phục ai đó mua giải pháp của bên thứ ba, cách tốt nhất của bạn là tái cấu trúc tốt nhất có thể và ném phần cứng vào đó.

Tôi muốn nói rằng bạn nên làm hai việc: 1) Phân tích hiệu suất trên máy chủ SQL. Bạn dường như đã xác định phía máy chủ là nguồn gốc của độ trễ, vì vậy bây giờ bạn cần biết truy vấn nào bị trễ và tại sao. Trong mọi trường hợp, bạn có thể tìm thấy một số truy vấn điểm nóng để tối ưu hóa sẽ mang lại cho bạn những lợi ích lớn. Heck, nếu bạn có khách hàng cập nhật cứ sau vài giây, hãy xem liệu bạn có thể giảm tốc độ cập nhật của họ không (Danh sách trên màn hình CÓ THỰC SỰ cần cập nhật cứ sau 5 giây không? Có phải 30 không? ). Những thứ ngớ ngẩn như tăng thời gian làm mới có thể giúp bạn tiết kiệm rất nhiều chi phí, nếu bạn có thể thoát khỏi nó.

2) Ném thêm phần cứng vào nó. ĐẶC BIỆT ném một lượng lớn ram vào nó. Bạn muốn có nhiều bộ nhớ để cơ sở dữ liệu phù hợp hoàn toàn với RAM. Theo dõi các phiên bản HĐH và phần mềm của bạn ( rõ ràng có khá nhiều quy tắc với các phiên bản Windows và phần cứng nào chúng thực sự hỗ trợ). Nếu bạn có thể thuyết phục bản thân rằng nhiều lõi hơn sẽ giúp ích, thì hãy ném càng nhiều CPU và lõi càng tốt.

Bạn đã đề cập đến RAM và bộ xử lý, nhưng không phải đĩa. Tôi thừa nhận đã gần một thập kỷ kể từ khi tôi xử lý SQL Server của MS, nhưng nó bị ràng buộc với các đĩa giống như bất kỳ cơ sở dữ liệu nào khác, nếu nó không thể phù hợp với mọi thứ trong bộ nhớ.

Trước tiên tôi có thể thử lấp đầy máy bằng nhiều RAM nhất có thể - sau đó tôi chắc chắn rằng các bản ghi đang được ghi vào các đĩa không được sử dụng cho các bảng hoặc chỉ mục. Sau đó, tôi sẽ cố gắng đảm bảo rằng không có bảng nào có chỉ mục của chúng trên cùng một trục chính.

Sau đó, tôi lo lắng về việc điều chỉnh mức cơ sở dữ liệu, nhưng với điều đó, bạn sẽ cần xác định các thử nghiệm của mình và mục tiêu tối ưu hóa để bạn không phá vỡ mọi thứ hoặc làm cho các truy vấn trở nên tồi tệ hơn. Mặc dù bạn nói rằng các khóa chính không thể hiện nhiều lợi thế trong cơ sở dữ liệu kiểm tra của bạn, nhưng bạn nên xem phương pháp kiểm tra của mình - các khóa chính có thể cho phép một số cơ sở dữ liệu (không chắc chắn nếu MS SQL là một trong số chúng) sử dụng khóa mức ghi , thay vì khóa cấp bảng, có thể làm giảm sự tranh chấp có thể không được hiển thị trong thử nghiệm chỉ với một vài người dùng.

Đầu tiên, tôi đồng ý với Kyle Hodgson và thêm PK. Nó rẻ (chỉ có thời gian) và bạn có thể thấy sự gia tăng các truy vấn của mình. Còn các chỉ mục về các cột tham gia trong 10 truy vấn xấu nhất của bạn thì sao? Bàn quét ở đâu?

Thứ hai, những gì về cắt dữ liệu trong cơ sở dữ liệu? Là nhiều hàng được trả lại trong các truy vấn hơn là thực sự cần thiết? Tôi cũng đồng ý với đề xuất về RAM của Kyle (thêm hai GB).

Đặt tất cả những điều này vào bài viết của bạn (Joseph Kern) về những gì bạn đề xuất tạm thời trong khi vạch ra tương lai. Hỏi quản lý và người dùng điều gì sẽ xảy ra với tổ chức nếu ứng dụng CRM hiện tại bị hỏng và không khả dụng. Có lẽ điều đó sẽ giúp họ suy nghĩ về tương lai.

Nhận phần cứng!

Không chỉ là tin rất rẻ tại thời điểm này nếu bạn sử dụng chip dòng Xeon 55xx, nó sẽ hét lên cho bất cứ điều gì bạn có thể ném vào nó.

Đó chỉ là một điều rủi ro / phần thưởng - bạn có thể dành tiền và nhiều thời gian để làm cho DB tốt hơn hoặc mua theo cách của bạn nhanh hơn và rẻ hơn.

Cân nhắc lật công tắc bộ nhớ 3 GB và thêm 2 GB bộ nhớ.