DBA đang lo lắng sắp xếp lại hoặc xây dựng lại các chỉ mục có thể gây mất dữ liệu?


14

Chúng tôi có một số cơ sở dữ liệu với phân mảnh chỉ mục> 95%. Như tốt nhất tôi có thể nói các chỉ số chưa bao giờ được xây dựng lại ít tổ chức lại. Trong những năm.

.

Khi tôi hỏi, DBA nói rằng anh ta không muốn xây dựng lại hoặc sắp xếp lại các chỉ số. Khi tôi hỏi tại sao, anh ấy không thể nói rõ điều đó. Cuối cùng, ông nói rằng ông lo ngại về việc mất dữ liệu tiềm năng. Ví dụ, một trong những cơ sở dữ liệu được sử dụng bởi ứng dụng kế toán Great Plains Dynamics của chúng tôi và anh ta có vẻ rất lo lắng về điều đó.

Tôi không phải là một DBA nhưng từ những gì tôi đã đọc, sự lo lắng của anh ấy dường như ... khó hiểu đối với tôi.

Tôi không chắc phải làm gì tiếp theo. Gợi ý tôi nên tiến hành như thế nào?


Trừ khi cơ sở dữ liệu bị ảnh hưởng nặng nề 24/7 và thế giới sẽ chấm dứt nếu nó ngoại tuyến, không có lý do gì cho hành vi đó. Tôi viết kịch bản và thống kê mỗi tuần trên hơn 12.000 cơ sở dữ liệu mà không cần suy nghĩ thứ hai. Trong 16 năm, tôi chỉ có một lỗi do bộ điều khiển kém.
Brain2000

Câu trả lời:


22

Xây dựng lại một chỉ mục cơ sở dữ liệu sẽ không gây mất dữ liệu. Tuy nhiên, nó có thể sẽ gây ra sự suy giảm hiệu suất đáng kể vì các chỉ mục được xây dựng lại thường sẽ không có sẵn để sử dụng cho đến khi việc xây dựng lại kết thúc. Vì lý do đó, nó nên được thực hiện trong giờ làm việc khi các hệ thống bị ảnh hưởng không hoạt động.

Paranoia là một điều tốt trong DBA - Nếu họ lo lắng về việc mất dữ liệu, tôi sẽ yêu cầu họ thực hiện kiểm tra đúng các bản sao lưu (khôi phục chúng vào một hệ thống riêng biệt và đảm bảo dữ liệu ở đó), và nếu chúng vẫn còn lo ngại sau đó thực hiện sao lưu toàn bộ trước khi xây dựng lại các chỉ mục sẽ là một biện pháp phòng ngừa hợp lý cần thực hiện.


11
+1 cho Paranoia là Đặc điểm DBA tốt
Joel Coel

Tôi hoàn toàn hiểu và đánh giá cao sự hoang tưởng lành mạnh. Đo hai lần cắt một lần. Nơi tôi đang bối rối là điều này dường như là về sự thiếu hiểu biết hơn là sự thận trọng. Và thay vì "hãy xác định một cách để thử nó một cách cẩn thận", đó là "vâng, sẽ không xảy ra". Chúng ta có thể (giả sử) tạo ra một phiên bản EC2 thử nghiệm với một bản sao của dữ liệu, sắp xếp lại các chỉ mục, thời gian, đồng bằng các hàng của bảng kết quả để xác nhận không có dữ liệu nào bị hỏng. Đó là loại kế hoạch sẽ thận trọng ... trái ngược với không hành động?
Greg Hendershott

1
Chỉ cần nhắc nhở rằng việc sắp xếp lại chỉ mục luôn trực tuyến (tất cả các chỉ mục đều khả dụng trong khi chống phân mảnh) và việc xây dựng lại chỉ mục cũng có thể được thực hiện trực tuyến ( WITH (ONLINE=ON)miễn là chỉ mục không chứa các cột BLOB.
Remus Rusanu

@Greg Vâng, "Chúng ta đừng chạm vào những chỉ số bị phân mảnh quá nhiều, chúng có lẽ là HURTING hiệu suất" khiến tôi cũng bối rối - Việc thỉnh thoảng REINDEXlà "bảo trì phòng ngừa" trên các bảng có nội dung chỉ số thay đổi rất nhiều phổ biến kinh nghiệm của tôi (nếu chỉ số này chủ yếu là tĩnh nó ít hơn của một điều)
voretaq7

@Remus mẹo hay - Điều này làm giảm tác động hiệu suất (bạn vẫn sẽ có I / O đĩa cao, điều này sẽ làm bạn chậm lại, nhưng ít nhất những thứ sử dụng chỉ mục vẫn có thể sử dụng thay vì quét theo tuần tự )
voretaq7

6

Không có nguy cơ mất dữ liệu từ việc xây dựng lại hoặc chống phân mảnh các chỉ mục.


Trừ khi bạn đã có một số mức độ hỏng dữ liệu, hoặc có lỗi phần cứng. Nhưng trong một trong những trường hợp đó, phân mảnh chỉ số là ít lo lắng nhất của bạn!
db2

Nhưng đó sẽ không phải là tham nhũng từ việc xây dựng lại chỉ mục, mà từ một số vấn đề khác.
mrdenny

4

Sắp xếp lại các chỉ mục sẽ tốn ít thời gian hơn và tốn ít công sức hơn từ máy chủ SQL, do đó chúng có thể được thực hiện trong một loại trường hợp hàng tuần. Nếu bạn nói điều đó là đúng, thậm chí sắp xếp lại các chỉ mục chưa từng có, cũng có thể gây ra tác động lớn hơn trên máy chủ. Việc xây dựng lại các chỉ mục sẽ mất một lượng nỗ lực đáng kể từ máy chủ SQL kể từ khi chúng bị hủy bỏ và được xây dựng lại. Việc xây dựng lại vào một tuần không đáng để rủi ro máy chủ bận rộn với các chỉ mục và không phục vụ những người sử dụng nó.

Tôi đồng ý với voretaq7, nếu anh ấy lo lắng về việc làm việc với các chỉ mục, trước tiên hãy thử nó trên các máy chủ phát triển hoặc thử nghiệm để xem phản ứng như thế nào.


Một cách tiếp cận khác có thể là rõ ràng DROP INDEXvà tái CREATE INDEX- Tôi không chắc chắn về SQL Server, nhưng tôi biết PostgreQuery đôi khi làm tốt hơn việc thổi bay một chỉ mục và bắt đầu lại từ đầu thay vì cố gắng xây dựng lại ( REINDEX) nó.
voretaq7

Tôi khá chắc chắn rằng việc bỏ và tạo lại là không cần thiết trên SQL Server.
Justin thân mến

@Justin Tôi khá chắc chắn rằng bạn đã đúng (thực tế từ những ngày ở Sybase của tôi, tôi nhớ rằng một hành vi giới thiệu lại thực sự là một sự sụt giảm / tạo nên không có sự kỳ quặc khóa chỉ mục như trong Postgres)
voretaq7

Sắp xếp lại các chỉ số có thể mất ít thời gian hơn. Cái nào mất nhiều thời gian hơn sẽ phụ thuộc vào mức độ phân mảnh của chỉ số.
mrdenny
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.