Dalam geodatabase versi, dampak apa yang dilakukan tabel delta dan pohon status terhadap kinerja kueri?

Kami memiliki geodatabase arcsde versi (arcgis 9.3.1 pada oracle 10g) dengan model data yang cukup kompleks yang mencakup sekitar 100 kacamata fitur dan tabel non spasial, jaringan geometris, dan banyak kelas hubungan.

Data diedit setiap hari oleh 5 atau 6 pengguna arcmap yang menggunakan versi sde. Selain itu, versi dibuat oleh layanan otomatis yang berinteraksi dengan sistem bisnis lain untuk melakukan pengeditan di geodatabase. Kinerja kueri menurun secara nyata selama hari itu, jadi kami telah menerapkan naskah malam hari untuk mencapai kompres penuh. Pada saat-saat ketika sejumlah besar pengeditan dilakukan, sistem dapat menjadi tidak dapat digunakan sampai setelah kompres penuh.

Disarankan bahwa oracle yang dikonfigurasi tidak dapat datang dengan rencana eksekusi yang layak ketika dihadapkan dengan tabel delta yang tidak stabil ini. Apakah ini penjelasan yang masuk akal? Pendekatan apa yang harus diambil untuk mengatasinya?

Perbarui dalam menanggapi komentar

• Pada akhir hari, pohon negara sangat linier, dengan hanya sedikit bercabang.
• Kami mengompres setiap malam (dapatkan kompres penuh dengan menghapus semua versi).
• Tabel bisnis dianalisis secara teratur.
• Tabel delta tidak dianalisis. Mereka dikunci (Mencoba menganalisis kesalahan pengembalian "statistik objek ORA-20005 terkunci"). Baik tabel volatil dalam skema sde - STATES, STATE_LINEAGES.

Tabel delta dan pohon status memiliki dampak kinerja langsung pada kueri Anda.

Pertama, Anda perlu memahami versi; Saya melakukan penjelasan singkat tentang hubungan pohon status dan label versi dalam jawaban yang berbeda . Saya pikir itu akan membantu Anda untuk membahasnya.

Setelah membaca jawaban itu, Anda kemudian dapat menyadari bagaimana cabang id state yang panjang (dari root ke state-id yang dirujuk oleh label akan memengaruhi kinerja. Mengapa? Karena Anda memiliki gabungan yang lebih kompleks untuk membuat kembali tampilan "saat ini" dari versi tersebut. Karena kompres memangkas pohon, gabungan bagian dalam menjadi lebih mudah diproses oleh db yang mendasarinya dan sesi ArcMap Anda menjadi lebih cepat.

Lihatlah dokumen Alur Kerja Versi dari ESRI yang akan mengajarkan Anda bagaimana menjaga pohon status versi di bawah kontrol yang waras. Gunakan GDBT untuk melihat pohon status sebelum dan sesudah sehingga Anda dapat melihat bagaimana alur kerja yang baik memengaruhi pohon.

Kedua, jika Anda bisa pergi tanpa harus menggunakan Jaringan Geometrik untuk sebagian besar kasus penggunaan Anda, maka lakukan itu. Ini akan memperlambat FeatureClasses yang terlibat karena menggunakan pesan kompleks untuk setiap panggilan Baris :: toko (bukan hanya menyimpan baris di tabel dan dilakukan dengan itu).

Untuk memperbarui statistik, gunakan fungsi Analisis Alat Manajemen Data (tandai semuanya). Ini akan tahu bagaimana menangani tabel delta (dan tabel lainnya) yang diperlukan.

[Posting pertama permintaan maaf: Ini dimaksudkan sebagai komentar, bukan jawaban yang pasti.] Jika Anda memiliki versi edit yang relatif lama dan belum diposting mereka harus dihapus, diposting atau direkonsiliasi. Versi lama yang tidak direkonsiliasi menyimpan pandangan lama default, yang mencegah catatan delta milik versi yang lebih baru dari dikompresi ke dalam tabel dasar. Mungkin ada sejumlah besar catatan delta yang tidak terkompresi ini disematkan ke versi lama dan kinerja akan terpengaruh karena semua versi dilihat pada tabel delta dan dasar. Kinerja sistem terkait dengan jumlah pengeditan karena setiap versi terakhir direkonsiliasi (atau dibuat). Singkatnya; jika ada versi yang Anda tidak dapat memposting maka rekonsiliasi mereka secara teratur, dan kompres.