Khi nào nên sử dụng sort_in_tempdb khi xây dựng lại chỉ mục?

Chúng tôi đang tranh luận về việc có nên sử dụng tùy chọn SORT_IN_TEMPDB cho các bảng DW của chúng tôi hay không. Sự hiểu biết của tôi là có nhiều ghi hơn khi sử dụng tùy chọn này, mặc dù chúng có tính tuần tự hơn. Chúng tôi có một SAN (đôi khi đã nổi tiếng là chậm), vì vậy trong trường hợp của chúng tôi, chúng tôi muốn giới hạn số lượng viết càng nhiều càng tốt. Tôi tin rằng tempdb nằm trên một LUN (bộ đĩa) riêng biệt.

Chúng tôi có nhiều không gian đĩa trong tệp dữ liệu và trên tệp tempdb của chúng tôi. Trong trường hợp này, chúng tôi có được hưởng lợi từ việc sử dụng SORT_IN_TEMPDB không?

Một điều gây ấn tượng với tôi là nhận xét về câu trả lời này

Khi xây dựng lại một chỉ mục, bạn sẽ cần gấp đôi không gian của chỉ mục + 20% cho việc sắp xếp. Vì vậy, nói chung để xây dựng lại mọi chỉ mục trong db của bạn, bạn chỉ cần 120% chỉ mục lớn nhất trong DB của bạn. Nếu bạn sử dụng SORT_IN_TEMPDB, bạn chỉ giành được 20%, bạn vẫn cần 100% quảng cáo trong tệp dữ liệu của mình. Hơn nữa, việc sử dụng sort trong tempdb làm tăng đáng kể tải IO của bạn, vì thay vì Viết chỉ mục một lần vào tệp dữ liệu, giờ đây bạn viết nó một lần vào tempdb và sau đó ghi nó vào tệp dữ liệu. Vì vậy, đó không phải lúc nào cũng lý tưởng.

Chúng tôi chắc chắn không muốn tăng tải IO của chúng tôi với SAN chậm / có thể bị định cấu hình sai.

Điều gì sẽ là cách tốt nhất để kiểm tra điều này? Bằng cách đơn giản là xây dựng lại bảng có và không có tùy chọn và đăng nhập thời gian?

Chỉnh sửa : Chúng tôi có 8 tệp tempdb, mỗi tệp 15 GB. Chúng tôi có các cờ TF 1117/1118 được đặt và IFI được bật. Chúng tôi hiện đang thực hiện một hỗn hợp xây dựng lại với tùy chọn sort_in_tempdb và không có nó.

Cảm ơn!

Máy chủ SQL 2012

SORT_IN_TEMPDBcó nghĩa là máy chủ SQL sẽ sử dụng tempdbđể phân bổ không gian tạm thời thay vì phân bổ không gian trong cơ sở dữ liệu người dùng có chỉ mục đang được xây dựng lại. Điều này có nghĩa là bạn sẽ cần ít không gian trống hơn trong cơ sở dữ liệu người dùng của mình trong quá trình xây dựng lại chỉ mục và nhiều không gian trống hơn trong tempdb.

Nó mang lại cho bạn lợi thế tốt hơn khi tempdb nằm trên một bộ đĩa (LUN) khác từ cơ sở dữ liệu người dùng.

Từ tùy chọn SORT_IN_TEMPDB - BOL :

Nếu tùy chọn SORT_IN_TEMPDB được đặt thành BẬT và tempdb nằm trên một bộ đĩa riêng biệt từ nhóm tệp đích, trong giai đoạn đầu tiên, việc đọc các trang dữ liệu xảy ra trên một đĩa khác từ ghi vào vùng làm việc sắp xếp trong tempdb. Điều này có nghĩa là các lần đọc đĩa của các khóa dữ liệu thường tiếp tục tuần hoàn hơn trên đĩa và việc ghi vào đĩa tempdb cũng thường là nối tiếp, cũng như ghi để xây dựng chỉ mục cuối cùng. Ngay cả khi những người dùng khác đang sử dụng cơ sở dữ liệu và truy cập các địa chỉ đĩa riêng biệt, thì kiểu đọc và ghi tổng thể sẽ hiệu quả hơn khi SORT_IN_TEMPDB được chỉ định so với khi không.

Hãy chắc chắn rằng bạn đã đọc các yêu cầu về dung lượng ổ đĩa khi SORT_IN_TEMPDB được BẬT .

chậm / có thể cấu hình sai SAN

Bạn biết điểm đau. Tại sao bạn không làm việc với quản trị viên SAN của mình để sửa nó? Cấu hình sai và SAN chậm sẽ gây ra tất cả các loại vấn đề như chậm .

Một số điểm quan trọng cần lưu ý:

• Sử dụng MAXDOP = 1 khi thực hiện xây dựng lại chỉ mục trực tuyến - nếu không, nó sẽ gây tăng phân mảnh.
• Thông minh sắp xếp lại / xây dựng lại các chỉ mục của bạn dựa trên mức độ phân mảnh cũng như các phân đoạn trang.
• Đọc trải nghiệm của SQLFool với Tạo chỉ mục 60 GB
• Hãy chắc chắn rằng bạn đã cấu hình tempdb đúng cách - TF 1117 (TĂNG TẤT CẢ CÁC PHIM TRONG MỘT THIẾT BỊ PHIM) và 1118 (CHỈ CÓ ĐẦY ĐỦ) và có nhiều dữ liệu tempdb hơn .

Điều gì sẽ là cách tốt nhất để kiểm tra điều này?

Có, bạn phải kiểm tra nó bằng cách phân tích các Waitstats khi bạn xây dựng lại chỉ mục có và không có SORT_IN_TEMPDB. Đo thời gian chạy cũng như khi thực hiện trong SẢN PHẨM, đảm bảo bạn thực hiện trong cửa sổ bảo trì hoặc ít hoạt động của máy chủ. Ngoài ra kiểm tra dữ liệu đọc / ghi của bạn và độ trễ đăng nhập .

Tôi không chắc chắn bạn có khởi tạo tệp tức thì , nhưng nó sẽ có lợi khi khôi phục, trong quá trình tự động phát triển tệp dữ liệu và khi tạo cơ sở dữ liệu mới (chỉ đề cập đến tính đầy đủ).