Trong cơ sở dữ liệu địa lý được phiên bản, các bảng delta và cây trạng thái có ảnh hưởng gì đến hiệu năng truy vấn?

Chúng tôi có một cơ sở dữ liệu địa lý arcsde phiên bản (arcgis 9.3.1 trên oracle 10g) với một mô hình dữ liệu khá phức tạp bao gồm khoảng 100 featureclass và các bảng không gian, một mạng hình học và nhiều lớp quan hệ.

Dữ liệu được chỉnh sửa hàng ngày bởi 5 hoặc 6 người dùng arcmap sử dụng phiên bản sde. Ngoài ra, các phiên bản được tạo bởi các dịch vụ tự động có giao diện với các hệ thống kinh doanh khác để thực hiện các chỉnh sửa trong cơ sở dữ liệu địa lý. Hiệu suất truy vấn suy giảm đáng chú ý trong suốt cả ngày, vì vậy chúng tôi đã thực hiện một kịch bản hàng đêm để đạt được một nén hoàn toàn. Trong trường hợp khi một số lượng chỉnh sửa tương đối lớn được thực hiện, hệ thống có thể trở nên không sử dụng được cho đến sau khi nén hoàn toàn.

Nó đã được đề xuất rằng orory như được cấu hình không thể đưa ra các kế hoạch thực hiện tốt khi đối mặt với các bảng delta dễ bay hơi này. Đây có phải là một lời giải thích hợp lý? Cách tiếp cận nào nên được thực hiện để giải quyết nó?

Cập nhật để phản hồi ý kiến

• Đến cuối ngày, cây trạng thái rất tuyến tính, chỉ có một ít phân nhánh.
• Chúng tôi nén hàng đêm (có được một nén hoàn toàn bằng cách xóa tất cả các phiên bản).
• Bảng kinh doanh được phân tích thường xuyên.
• Bảng Delta không được phân tích. Chúng bị khóa (Cố gắng phân tích lỗi trả về "Thống kê đối tượng ORA-20005 bị khóa"). Các bảng không dễ bay hơi trong lược đồ sde - STATE, STATE_LINEAGES.

Các bảng delta và cây trạng thái có tác động trực tiếp đến các truy vấn của bạn.

Đầu tiên, bạn cần hiểu phiên bản; Tôi đã làm một lời giải thích ngắn về mối quan hệ của cây trạng thái và nhãn phiên bản trong một câu trả lời khác nhau . Tôi nghĩ rằng nó sẽ giúp bạn vượt qua nó.

Sau khi đọc câu trả lời đó, bạn có thể nhận ra một nhánh id trạng thái dài (từ gốc đến id trạng thái được gọi bởi nhãn sẽ ảnh hưởng đến hiệu suất. Tại sao? Vì bạn có các phép nối phức tạp hơn để tạo lại giao diện "hiện tại" của phiên bản. Vì nén đang cắt tỉa cây, các phép nối bên trong trở nên dễ xử lý hơn bởi db bên dưới và các phiên ArcMap của bạn trở nên nhanh hơn.

Hãy xem tài liệu Luồng công việc Phiên bản từ ESRI sẽ hướng dẫn bạn cách giữ cây trạng thái phiên bản dưới sự kiểm soát lành mạnh. Sử dụng GDBT để xem cây trạng thái trước và sau để bạn có thể thấy một quy trình công việc tốt ảnh hưởng đến cây như thế nào.

Thứ hai, nếu bạn có thể thoát khỏi việc không phải sử dụng Mạng hình học cho hầu hết các trường hợp sử dụng của mình, thì hãy làm điều đó. Nó sẽ làm chậm FeatureClass có liên quan vì nó sử dụng nhắn tin phức tạp cho mỗi cuộc gọi lưu trữ Row :: trái ngược với việc chỉ lưu trữ hàng trong bảng và được thực hiện với nó).

Để cập nhật số liệu thống kê, hãy sử dụng chức năng Phân tích của Công cụ quản lý dữ liệu (đánh dấu tất cả). Nó sẽ biết cách xử lý các bảng delta (và bất kỳ bảng nào khác) cần thiết.

[Lời xin lỗi bài đăng đầu tiên: Đây có nghĩa là một nhận xét không phải là một câu trả lời dứt khoát.] Nếu bạn có bất kỳ phiên bản chỉnh sửa nào tương đối cũ và chưa được đăng, chúng nên được xóa, đăng hoặc đối chiếu. Một phiên bản chưa được chỉnh sửa cũ giữ một chế độ xem cũ về mặc định, điều này ngăn các bản ghi delta thuộc các phiên bản mới hơn được nén vào các bảng cơ sở. Có thể có một số lượng lớn các bản ghi delta không nén này được ghim vào một phiên bản cũ và hiệu suất bị ảnh hưởng vì tất cả các phiên bản đều là các khung nhìn trên các bảng delta và cơ sở. Hiệu năng hệ thống có liên quan đến số lần chỉnh sửa do mỗi phiên bản được điều chỉnh lần cuối (hoặc được tạo). Vì vậy, trong ngắn hạn; nếu có bất kỳ phiên bản nào mà bạn không thể đăng thì hãy đối chiếu chúng thường xuyên và nén lại.