Chỉ mục được nhóm trong SQL Server so với các bảng được tổ chức chỉ mục trong Oracle

Tôi đang thực hiện quá trình chuyển đổi với tư cách là nhà phát triển cơ sở dữ liệu từ SQL Server sang Oracle và đã tìm thấy một số tài nguyên tuyệt vời ở đây ( Làm cách nào để chuyển đổi từ SQL Server DBA sang Oracle? Và là một DBA, tôi sẽ chuyển đổi từ Oracle sang SQL Server như thế nào ? ) nhưng tôi đang gặp khó khăn trong việc tìm kiếm thông tin tốt về việc sử dụng các bảng được tổ chức chỉ mục trong Oracle.

Ở kiếp trước, chúng tôi đã sử dụng rộng rãi các chỉ mục được nhóm trong SQL Server trong bảng dữ liệu OLTP-ish của chúng tôi rất thành công. Các bảng được tổ chức chỉ mục có tiện dụng như một công cụ trong Oracle không?

Nếu bạn đang chuyển đổi từ SQL Server sang Oracle, tôi sẽ khuyên bạn nên thử bảng heap ngay từ đầu vì chúng là hình thức lưu trữ dữ liệu tiêu chuẩn trong Oracle. Đối với hầu hết các khối lượng công việc, các bảng heap với các chỉ mục thông thường trong Oracle là các hình thức lưu trữ cân bằng nhất liên quan đến DML và hiệu năng truy vấn.

Nếu sau này bạn thấy rằng bạn có vấn đề về hiệu năng hoặc nút cổ chai, bạn nên xem xét các phương pháp lưu trữ nâng cao chuyên dụng như IOT, phân vùng, cụm, chỉ mục khóa đảo ngược, v.v.

Nói riêng về IOT, tôi sẽ khuyên bạn không nên sử dụng chung vì có rất nhiều "vấn đề" mà bạn có thể không muốn tham gia khi mới bắt đầu:

• IOT không có hàng thực sự (vì không có bảng nào).
• do đó, các chỉ mục phụ trên IOT không có con trỏ thực sự cho các hàng mà chỉ là các phỏng đoán có thể dẫn đến quét chỉ mục không hiệu quả.
• Một số tính năng bị vô hiệu hóa trên các IOT như cột ảo , nén bảng , phân vùng tổng hợp.
• Bạn phải quyết định khi tạo nơi lưu trữ các cột không có chỉ mục (nội tuyến hoặc trong phân đoạn tràn), có khả năng dẫn đến hiệu suất thảm hại cho một số truy vấn.

Các IOT trong Oracle không hoàn toàn giống với các chỉ mục được nhóm trong SS vì các số liệu thống kê của Oracle bao gồm sự phân tán vật lý của các hàng, trong khi SS không bao gồm vị trí vật lý trong các số liệu thống kê của nó. Xem cuộc tranh luận này giữa Lewis và Fritchey trên Statistics trong Oracle và Sql Server để biết thêm thông tin. ( http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistic-oracle-sql-server-jonathan-lewis ) chỉ số trong SS tốt hơn một đống. Chỉ số cụm thêm dữ liệu vị trí vật lý vào số liệu thống kê. Các IOT rất tốt khi bạn biết rằng chỉ mục cung cấp vị trí của các hàng dữ liệu sẽ được tìm kiếm, ví dụ: chỉ mục trên order_date và khách hàng cho một bảng đặt hàng sẽ tạo ra một IOT tốt.

Vincent đưa ra một số điểm tuyệt vời về sự cẩn thận của IOT, nhưng bạn cũng có thể nhận được một số lợi ích đáng kể từ chúng.

Cá nhân tôi nghĩ rằng chúng được sử dụng đáng kể trong Oracle và nên được xem xét rộng rãi hơn nhiều - không chỉ là giải pháp khả thi cho các vấn đề về hiệu năng. Vì bạn phải tạo lại bảng để chuyển đổi giữa IOT và heap, đây là một thay đổi khó có thể xảy ra trên cơ sở dữ liệu luôn được sử dụng nhiều, trừ khi các vấn đề về hiệu năng nghiêm trọng.

Martin Widlake có một loạt bài viết tuyệt vời về IOT. Có một số lợi ích đáng kể bạn có thể nhận được bằng cách sử dụng chúng:

• Giảm đáng kể số lần đọc IO vật lý và logic
• Sử dụng hiệu quả hơn bộ đệm bộ đệm, có thể có lợi cho hiệu năng toàn hệ thống
• Đã lưu không gian khi bạn chỉ duy trì một chỉ mục, không phải là một bảng (trừ khi bạn có các phân đoạn tràn)

Tuy nhiên, để có được những lợi ích này, bạn cần các bảng trong đó bạn (gần như) luôn bao gồm (các) cột hàng đầu của khóa chính trong các truy vấn và bạn có thể sẽ tìm nạp nhiều hàng cùng một lúc. Một số ví dụ phổ biến của các bảng như vậy là:

• Nhiều chi tiết như thường thấy trong các đơn đặt hàng - đơn hàng, hóa đơn - dòng hóa đơn, v.v.
• Các bảng có độ phân giải nhiều-nhiều thường được truy vấn "một chiều". ví dụ: trong một customer_addressesbảng, việc tìm tất cả các địa chỉ cho một khách hàng, thay vì tất cả các khách hàng cho một địa chỉ là điều phổ biến hơn nhiều.

Một nhược điểm là việc chèn dữ liệu chậm hơn, do đó bạn cần cân nhắc chi phí và lợi ích. Cuối cùng, việc tìm hiểu dữ liệu của bạn và hiểu cách sử dụng dữ liệu sẽ hướng dẫn quyết định.