Thêm chỉ mục được nhóm vào bảng HEAP trên ứng dụng của người khác


7

Chúng tôi đang sử dụng một ứng dụng độc quyền dựa trên SQL Server 2005, có nhiều bảng dựa trên HEAP (nghĩa là không có chỉ mục Clustered). Trong những năm qua, các bảng này đã phát triển bị phân mảnh kém (ví dụ như phân mảnh 99%). Tôi cần chống phân mảnh chúng.

Bây giờ, trong SQL Server 2005, không có cách nào để làm điều đó trực tiếp. Tôi có thể:

  1. Tạo một chỉ mục Clustered trên một trường có sẵn và giữ nó
  2. Tạo chỉ mục đó, xây dựng lại bảng và sau đó thả nó
  3. Thêm trường của riêng tôi (ví dụ: khóa tự động)

Bây giờ, đây là một ứng dụng lớn, được viết bởi một nhà cung cấp - một hộp đen khổng lồ. Tôi không háo hức với những thứ của họ. Tôi không biết nhiều về cách các bảng được sử dụng. Cách ít tác động nhất để làm điều này là gì?

Và, như một cách tiếp theo: Có rất nhiều bảng dựa trên HEAP này, hơn một chục cơ sở dữ liệu được ứng dụng sử dụng. Có cách nào để tự động hóa lựa chọn # 2 hoặc # 3 không? Hoặc, tôi nên chọn bảng nào để sửa đổi?


CẬP NHẬT:
Để trả lời các câu hỏi được đặt ra bởi các câu trả lời (rất hữu ích):

  • Hiệu suất đã không thể chấp nhận. Nhà cung cấp nói với khách hàng của tôi rằng họ là vì các bảng cực kỳ phân mảnh và khách hàng có trách nhiệm phân mảnh chúng thường xuyên
  • Chúng tôi có hai phiên bản của ứng dụng: một thử nghiệm và một sản xuất
  • Trước tiên tôi phân mảnh tất cả các bảng Clustered, giúp cải thiện hiệu năng rất nhiều
  • Nhóm hỗ trợ của nhà cung cấp đã rất không có ích. Họ đã nói với chúng tôi rằng trách nhiệm của chúng tôi là chống phân mảnh các bảng. Khi tôi hỏi họ làm thế nào họ khuyên bạn nên chống phân mảnh các bảng dựa trên HEAP - tôi có nên thêm Chỉ mục cụm không? - họ chỉ trả lời "Đó là câu hỏi của Microsoft".

Nói tóm lại, nhóm hỗ trợ khách hàng đã nói rõ: Bạn phải chống phân mảnh các bảng, cách bạn thực hiện nó là doanh nghiệp của bạn.

Đối với các phiên bản trong tương lai: Có, các phiên bản mới đang được phát triển và cuối cùng chúng sẽ chuyển sang SQL Server 2012. Nhưng chúng cần các giải pháp hiệu suất ngay hôm nay .

Cuối cùng, đối với việc chống phân mảnh mất quá nhiều thời gian: Không thành vấn đề. Họ có những cái bàn khổng lồ với độ phân mảnh 99%; ứng dụng không được sử dụng vào ban đêm; Tôi có thể dễ dàng dành hàng giờ đồng hồ để chống phân mảnh chúng.


Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .
Paul White 9

Câu trả lời:


1

Đống mảnh vỡ vấn đề. Heap càng lớn, càng khó đi lại dữ liệu. Hiệu suất bị ảnh hưởng.

Tạo và thả CI sẽ sắp xếp lại các hàng trong bảng khi bạn biết. Nếu nhà cung cấp không đưa ra giải pháp và bạn có trách nhiệm giải quyết sự phân mảnh, đó chính xác là những gì tôi đã làm trong quá khứ. Tôi sẽ không rời khỏi CI nếu là tôi, tôi sẽ bỏ nó. Tôi sẽ tránh thêm một cột vì điều đó làm thay đổi chức năng của bảng vĩnh viễn và có thể đưa ra lập luận tương tự nếu bạn để CI đúng chỗ.

Nếu bạn làm điều này, hãy chắc chắn rằng bạn có bộ lưu trữ phù hợp để tạo CI vì nó sẽ yêu cầu lưu trữ ít nhất bằng với kích thước của heap, và cũng xem xét khi bạn thực hiện lại: yêu cầu cấp độ dịch vụ của bạn.


8

Tôi sẽ tiếp tục giả định rằng bạn đã xác định được một vấn đề cần khắc phục ... mặc dù tôi chưa hoàn toàn bị thuyết phục về điều đó.

Tương tự như câu trả lời của tôi ở đây , có hai trường hợp khi nói đến các ứng dụng của nhà cung cấp.

  1. Ứng dụng hiện đang được cấp phép và / hoặc nhà cung cấp / chủ sở hữu không muốn bạn can thiệp.

    Trong trường hợp này, chắc chắn không thay đổi lược đồ theo bất kỳ cách nào, bao gồm thêm các chỉ mục dưới bất kỳ hình thức nào.

    Thực hiện thay đổi lược đồ trên thực tế có thể làm mất hiệu lực hợp đồng giấy phép của bạn, nhưng điều này cũng có thể gây ra sự cố cho nhà cung cấp nếu họ quyết định khắc phục các sự cố trong bản cập nhật lược đồ trong tương lai. Phát biểu từ kinh nghiệm cá nhân theo quan điểm của nhà cung cấp, đôi khi chúng tôi phải rất tích cực nói với khách hàng ngừng tạo đối tượng trong cơ sở dữ liệu của mình, vì nó ảnh hưởng đến khả năng áp dụng thành công các thay đổi lược đồ. (Tôi không chỉ nói rằng - chúng tôi đã có một trường hợp vài tháng trước khi một bản cập nhật lược đồ không thành công cho một khách hàng vì sự phụ thuộc không mong muốn từ một đối tượng do khách hàng tạo. Kịch bản hơi khác so với việc thêm một chỉ mục, nhưng vẫn vậy không đi lên.)

    Có những trường hợp hiếm hoi khi thay đổi cấp cơ sở dữ liệu là ổn, nhưng bạn cần chắc chắn rằng nhà cung cấp hoàn toàn ổn với những gì bạn dự định làm.

    Tùy chọn tốt nhất cho kịch bản này là ... thực sự, không tự mình thực hiện bất kỳ thay đổi nào. Kết hợp một trường hợp hấp dẫn để chứng minh tại sao những thay đổi quan trọng này được thực hiện và trình bày cho nhà cung cấp để họ thực hiện trong phiên bản tương lai.

    Từ quan điểm của một nhà cung cấp, các đề xuất lý tưởng là cụ thể, đơn giản để thực hiện và thử nghiệm và có tác động tích cực cao cho tất cả các khách hàng. Trong một ứng dụng lớn, đề xuất rằng tất cả các bảng là đống được chuyển đổi thành các chỉ mục được nhóm có thể là (và có lẽ là) một ý tưởng tốt, nhưng đó không phải là một khởi đầu hoàn chỉnh. Thay vào đó, hãy tìm ra 5-10 bảng quan trọng nhất hoặc 2-3 khu vực ứng dụng sẽ được hưởng lợi từ loại thay đổi này trong môi trường của bạn.

  2. Ứng dụng không có giấy phép hoặc nhà cung cấp / chủ sở hữu không quan tâm bạn làm gì với nó.

    Trong trường hợp này, bạn có thể thêm bất kỳ chỉ mục nào bạn muốn, nhưng các đối tượng nên giữ nguyên vị trí có cùng tên (lưu ý tôi không nói cùng một đối tượng). Có nhiều tùy chọn ở đây, tùy thuộc vào cách ứng dụng và cơ sở dữ liệu hoạt động bên trong. Nếu bạn vẫn có kế hoạch để áp dụng thay đổi schema nhà cung cấp dịch tương lai, lốp rất cẩn thận và chắc chắn rằng bạn tạo lùi lại kịch bản cho tất cả các thay đổi của bạn.

    Chìa khóa để thực hiện thay đổi thành công là duy trì chức năng ứng dụng ... nói dễ hơn làm, tất nhiên, nếu bạn có kế hoạch thực hiện thay đổi đáng kể.

    Điều đó nói rằng, chỉ cần thêm các chỉ mục cụm là khá an toàn. Thách thức sẽ là chọn một khóa thích hợp cho từng chỉ mục và điều này nên được thực hiện bằng tay, không phải tự động. Cách duy nhất để làm tốt phần này là bằng cách tự làm quen với các mục đích và kiểu truy cập của bảng.

    Nghĩ về nó, bạn có thể trải qua quá trình tương tự như trong trường hợp khác: xác định 5-10 bảng sẽ có tác động tổng thể cao nhất và khắc phục chúng trước. Bạn có thể thấy đó là tất cả những gì cần phải làm.

Chỉnh sửa: câu trả lời này, theo nghĩa chung hơn, hiện có sẵn ở dạng video .


Cảm ơn bạn đã nghĩ ra trả lời. Cho rằng tôi có sự cho phép từ nhà cung cấp, nhưng không liên quan, tôi muốn thực hiện sửa chữa ít xâm lấn nhất mà tôi có thể làm. Dường như với tôi đó vẫn là: Tạo một CI, Xây dựng lại, Thả CI.
S. Robert James

1
Bạn không cần phải "xây dựng lại". Việc tạo CI sẽ sắp xếp lại heap như là một phần của hoạt động tạo CI.
Eric Higgins
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.