Halo!
Dalam serangkaian posting, kami ingin berbagi pengalaman kami dalam pengembangan dan pengoperasian sistem keluarga MS Dynamics AX (sebelumnya Axapta).
Tentang kami
Kami adalah jaringan retail supermarket grosir yang relatif muda "Da!" Saat artikel ini ditulis, kami memiliki lebih dari 100 toko. Proses utama aktivitas operasi perusahaan diotomatiskan dalam paket sistem MS Dynamics Ax 2012 + MS Dynamics 365 FO. Sistem beroperasi 24/7. Rata-rata, sekitar satu juta jalur penerimaan dan sekitar 70.000 jalur pesanan perakitan melalui sistem setiap hari.
Panduan rencana
Penyetelan kinerja Axapts dapat dilakukan dengan berbagai cara. Cara yang paling efisien tentu saja dengan mengoptimalkan kode sumber aplikasi. Tetapi ada situasi ketika ini bermasalah. Kemudian Anda dapat menggunakan alat yang disediakan oleh MS SQL Server DBMS. Ini disebut - Panduan rencana. Muncul di versi SQL Server 2005. Namun menurut perasaan kami di komunitas Axapters (apalagi jika perusahaannya tidak memiliki DBA profesional), dia tidak selalu dikenal dan digunakan. Meskipun, dalam beberapa kasus, penggunaannya bisa sangat efektif.
Untuk apa?
Berikut adalah alasan utama saat Anda harus melihat ke alat ini:
1. Data yang tidak konsisten dalam parameter kueri. Hasil sampling (jumlah record) untuk kriteria sampling yang sama (kumpulan field) berbeda-beda bergantung pada nilai variabel dalam kriteria sampling. Atau, dengan cara yang lebih sederhana, ketika kueri yang sama untuk parameter input yang berbeda menghasilkan jumlah record yang sangat berbeda (terkadang satu, terkadang sepuluh ribu). Ini karena apa yang disebut "sniffing" dari parameter permintaan. Saat rencana kueri dibuat sekali di bawah topeng kueri, lalu diambil dari cache. Tidak melihat nilai parameter yang sama ini.
Ini sering terjadi pada kueri yang melibatkan tabel InventSum dan InventDim. Misalnya, ketika dalam analitik, Partai untuk beberapa nomenklatura hanya memiliki satu pihak, dan untuk yang lain - beberapa ribu. Permintaan pertama ke database dapat melewati item yang akuntansi batch-nya dinonaktifkan. Pengoptimal akan membuat rencana kueri untuk itu. Dan taruh di cache. Permintaan berikutnya ke database bisa melalui item yang akuntansi batch diaktifkan. Dan berikan beberapa ribu catatan dalam pemilihan InventSum dan InventDim. Dan untuk sampel seperti itu, rencana dari cache tidak akan optimal.
Salah satu cara untuk mengatasi masalah ini adalah dengan menggunakan petunjuk forceLiterals dalam isi permintaan. Ini menandakan mesin SQL untuk menghasilkan rencana kueri baru setiap kali. Tetapi ini memberikan beban nyata tambahan pada CPU. Dan dengan permintaan sisa yang sama menggunakan InventDim bukanlah pilihan yang dapat diterima. Nah, Anda perlu memahami bahwa pengoptimal SQL Server tidak sempurna dan terkadang, bahkan dengan statistik lengkap, menghasilkan rencana yang aneh.
Dan dalam hal ini, Panduan Rencana hadir untuk menyelamatkan, dengan bantuannya Anda dapat memilih rencana kueri yang memberikan kecepatan eksekusi yang dapat diterima untuk parameter input kueri apa pun. Dan lampirkan rencana ini ke topeng kueri menggunakan Panduan Rencana.
2. Pengoptimal memilih indeks yang menghasilkan kunci panjang. Dengan menggunakan Panduan Rencana, Anda dapat "menentukan" penggunaan indeks tertentu, yang akan mempersempit sampel dan mengurangi jumlah kunci.
3. Sumber (tempatkan dalam kode) permintaan bermasalah tidak dapat diidentifikasi dengan cepat, dan masalah penurunan kinerja database harus segera diselesaikan.
4. Kode sumber aplikasi tidak dapat diubah karena beberapa alasan (solusi mitra, permintaan dari kernel, dll.). Ini terutama berlaku untuk D365, yang melarang overlay.
Bagaimana?
Saya tidak akan menjelaskan secara rinci panduan langkah demi langkah untuk membuat Panduan Rencana. Ada deskripsi yang bagus di situs vendor (kami tertarik pada jenis rencana - SQL) Dan jaringan memiliki lautan tutorial.
Tetapi penting untuk mengetahui bahwa ada alat SQL Server lain yang akan sangat membantu Anda jika Anda perlu membuat Panduan Paket baru. Ini disebut Toko Kueri. Muncul tahun 2016. Penjelasan rinci tentang itu di sini .
Ide utama alat ini adalah, selain rencana kueri saat ini di cache, ia menyimpan seluruh riwayat rencana yang dibuat pengoptimal untuk waktu tertentu. Jika Anda tahu bahwa fungsionalitas bermasalah bekerja "normal" sebelumnya. Tidak melambat. Anda hanya perlu menemukan rencana yang Anda perlukan di repositori dan membuat Panduan Rencana berdasarkan itu. Sayangnya, karena kekhasan Axapta, tidak mungkin membuat Panduan Rencana dengan satu tombol "rencana paksa". Anda harus menyalin rencana kueri dari repositori dan membuat Panduan Rencana secara manual. Tapi ini masih sangat menyederhanakan tugas.
Juga harus diingat bahwa penggunaan Query Store memberikan sedikit biaya tambahan pada sumber daya komputasi dari server DBMS yang digunakan. Tetapi dalam praktik kita, mereka tidak signifikan, dan ini dapat diabaikan.
Contoh dari
Berikut adalah beberapa contoh Panduan Rencana dari markas pertempuran kami yang sebenarnya. Harap perhatikan bahwa ini hanyalah contoh yang relevan dengan proses bisnis khusus kami. Mereka mungkin tidak berlaku atau bahkan berbahaya untuk instalasi Anda.
1. InventSum
Panduan Rencana ini memecahkan masalah rencana suboptimal dalam kasus kueri untuk item dengan sejumlah kecil catatan di tabel InventDim. Dengan menggunakan panduan ini, Anda selalu dapat menggunakan rencana yang optimal untuk pengambilan sampel dengan sejumlah besar kombinasi SKU InventDim. Kueri untuk item dengan sedikit SKU akan sedikit lebih lambat. Tetapi ini bukan harga yang mahal untuk membayar kecepatan yang stabil dan dapat diprediksi untuk kombinasi parameter input apa pun.
Kueri ini terutama dihasilkan oleh metode InventSum :: findSum (). Dan bergantung pada pengelompokannya, pola kueri mungkin sedikit berbeda. Jadi pada kenyataannya kami memiliki Panduan Rencana yang lebih mirip, yang disesuaikan untuk varian pengelompokan yang berbeda.
2. InventSumDelta
Panduan Rencana ini memungkinkan Anda membuat rencana kueri yang optimal untuk tabel InventSumDelta, menghindari kunci yang tidak perlu pada tabel ini. Kekhususan tabel ini sedemikian rupa sehingga data tidak disimpan di dalamnya. Tetapi mereka ditambahkan / dihapus dengan sangat intensif. Ini pada dasarnya adalah tabel semaphore. Dalam hal ini, tidak mungkin mengumpulkan statistik normal pada tabel ini. Oleh karena itu, pengoptimal terkadang membuat rencana suboptimal yang mengakibatkan pemblokiran.
Sedikit offtopik - juga untuk tabel ini Anda perlu menonaktifkan kunci halaman pada indeks. Karena pemilihan dari tabel ini selalu dilakukan dengan ID unik, meningkatkan kunci ke tingkat halaman tidak ada artinya dan bahkan berbahaya di sini.
kesimpulan
Tetapi dalam kasus umum, izinkan saya menarik perhatian Anda sekali lagi, Anda tidak boleh menyalahgunakan alat ini. Jika kode ditulis secara optimal, statistik diperbarui secara teratur, indeks tidak terlalu terfragmentasi - pengoptimal dalam banyak kasus akan memilih paket yang benar itu sendiri. Tetapi jika panduan rencana dikonfigurasi, kriteria masukan dari permintaan mungkin tidak sesuai sehingga panduan rencana hanya akan merugikan.