Tệp chỉ mục hiện tại CDX & Windows 2003 Server


1

Chúng tôi đang gặp phải sự cố hỏng chỉ mục cơ sở dữ liệu hàng ngày trên Windows Server 2003. Tôi tự hỏi liệu nó có thể được kết nối bằng cách nào đó với bộ đệm hay các cài đặt máy chủ khác không.

Chúng tôi đang chạy một ứng dụng cũ sử dụng các bảng DBF / CDX. Mọi thứ đều ổn trong nhiều năm, nhưng 6 tháng sau khi chúng tôi cài đặt Máy chủ cơ sở dữ liệu lợi thế (cho phép truy cập vào một số bảng vào trang web của chúng tôi), chúng tôi bắt đầu gặp vấn đề về tham nhũng chỉ mục. Và chúng ta không biết trách ai. ADS trả về lỗi: Lỗi 7017: Chỉ mục .ADI, .CDX hoặc .IDX bị hỏng. Tên bảng: RBOOKM

Chúng tôi đã cố gắng loại trừ tất cả các nguyên nhân có thể của tham nhũng này. Bây giờ tất cả người dùng làm việc ở chế độ đầu cuối - vì vậy không có vấn đề mạng nào có thể gây ra điều đó, OpLocks cũng không thể là một lý do. Chúng tôi đã thay đổi phần cứng, card mạng, thiết bị chuyển mạch, Máy chủ được cài đặt lại và thậm chí chuyển sang máy chủ chuyên dụng mới. Điều duy nhất chúng tôi không thể loại trừ là ADS - vì nó sẽ hoạt động.

Có thể là bộ nhớ đệm đọc / ghi cục bộ gây ra vấn đề đó? Ví dụ: một người dùng hoặc quá trình sử dụng dữ liệu được lưu trong bộ nhớ cache, sau đó người dùng / quy trình khác sẽ thay đổi dữ liệu đó và sau đó người dùng đầu tiên thay đổi lại mà không biết về thay đổi đầu tiên. Có thể về mặt lý thuyết?

Có thể vấn đề này là do máy chủ tệp nhập khẩu hoặc cài đặt bộ đệm? Có thể người dùng bình thường sử dụng dữ liệu không được lưu trong bộ nhớ cache và ADS đang sử dụng dữ liệu được lưu trong bộ nhớ cache? Hoặc ngược lại? Có thể là mỗi người dùng thiết bị đầu cuối có bộ đệm riêng của mình? Hoặc có thể vấn đề là về bộ nhớ đệm RAID bằng cách nào đó can thiệp vào bộ đệm của Windows Server? Hoặc có thể có một số cài đặt đặc biệt cho Windows Server để làm việc với các bảng DBF đang được viết bởi một số người dùng thiết bị đầu cuối? Có lẽ có một cách để tắt bộ nhớ đệm cho một số tệp nhất định để kiểm tra nó?

Đôi khi chúng tôi nhận được chỉ số sụp đổ hai lần một ngày, đôi khi mọi thứ đều ổn trong 5 ngày liên tiếp. Nhưng thường thì nó gặp sự cố hàng ngày. Hôm nay chỉ có một người dùng làm việc vào buổi tối với cơ sở dữ liệu (thường có 30-50 người dùng đang làm việc đồng thời vào giờ làm việc). Vì vậy, nó gần như không tải trên máy chủ. Đồng bộ hóa với trang web được thực hiện cứ sau 5 phút trong giờ làm việc và cứ sau 15 phút vào buổi tối và cuối tuần.

Chúng tôi đã thực hiện kiểm tra truy cập tệp và nó cho thấy rằng trong quá trình đồng bộ hóa trang web, máy chủ ADS mở bảng và tệp chỉ mục cho ReadEA và WriteEA mặc dù nó chỉ thực hiện các truy vấn CHỌN. ADS thực hiện các truy vấn CẬP NHẬT / CHERTN nhưng ít thường xuyên hơn - không phải trong quá trình đồng bộ hóa thông thường, mà chỉ khi một đơn đặt hàng được đặt bởi khách truy cập trang web).

Làm ơn giúp tôi. Chúng tôi đang vật lộn với vấn đề này trong gần một năm và vẫn không thể tìm thấy bất kỳ mô hình hoặc bất kỳ manh mối nào về vấn đề này.

Đây là câu hỏi trước đây của tôi về vấn đề này trên DBA: https://dba.stackexchange.com/questions/8646/foxpro-dbf-index-corruption


Một trong những khách hàng của tôi luôn bị hỏng chỉ mục trên các bảng DBF / CDX. Đó là một vấn đề được biết đến như các nhà cung cấp có liên quan. Chỉ một di chuyển đến SQL Server đã khắc phục vấn đề.

cảm ơn, nhưng tôi nghĩ nên có một giải pháp vì chúng ta đã sống mà không bị hỏng chỉ số (không sao, với các lỗi hỏng một tháng một lần) trong hơn 10 năm ngay cả với rất nhiều người dùng mạng.
pablomedok

1
Hôm qua, sau một lần thất bại chỉ mục khác, tôi đã sao lưu tệp bảng hiện tại, cũng như tệp chỉ mục của nó. Và sau đó tôi quyết định kiểm tra tệp chỉ mục bị hỏng. Hóa ra mọi thứ đều ổn với nó. Tôi cũng đã cố gắng kết nối tập tin này với cơ sở dữ liệu và cũng đã thành công. Tôi có thể mở tập tin này và thêm một bản ghi. Vì vậy, nó trông giống như vấn đề không phải chỉ mục, nhưng vấn đề từ chối truy cập - trong một số trường hợp, tệp chỉ mục trở nên không thể truy cập được vì một số lý do.
pablomedok

Xử lý sự cố tốt! Hãy cho chúng tôi biết nếu bạn đến gần hơn với vấn đề.
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.