Kemacetan basis data file - cara menghindarinya (dari pengalaman terkini). Perlambatan berbasis file - cara menghindari (dari pengalaman terkini) Versi berbasis file memperlambat 1C 8.3 melalui jaringan

2. Fitur program. Seringkali, bahkan dengan pengaturan optimal, 1C bekerja sangat lambat. Performa turun tajam terutama ketika jumlah pengguna yang bekerja secara bersamaan dengan database melebihi 4-5 pengguna.

Siapa Anda di perusahaan?

Solusi untuk masalah lambatnya pengoperasian 1C tergantung pada siapa Anda di perusahaan tersebut. Jika Anda seorang teknisi, baca terus. Jika Anda seorang direktur atau akuntan, ikuti tautan khusus ↓

Bandwidth Jaringan

Sebagai aturan, bukan hanya satu, tetapi beberapa pengguna bekerja dengan satu basis informasi (IS). Pada saat yang sama, terjadi pertukaran data yang konstan antara komputer tempat klien 1C diinstal dan komputer tempat keamanan informasi berada. Volume data ini cukup signifikan. Situasi yang sering muncul ketika jaringan lokal yang beroperasi pada kecepatan 100 Mbit/s, yang merupakan kecepatan paling umum, tidak dapat mengatasi beban. Dan lagi-lagi pengguna mengeluhkan programnya yang lambat.

Masing-masing faktor ini secara individual sudah secara signifikan mengurangi kecepatan program, namun hal yang paling tidak menyenangkan adalah biasanya hal-hal ini bertambah.

Sekarang mari kita lihat beberapa solusi untuk masalah kecepatan 1C yang rendah dan biayanya, dengan menggunakan contoh jaringan lokal 10 komputer berukuran sedang.

Solusi satu. Modernisasi infrastruktur

Ini mungkin merupakan solusi yang paling jelas. Mari kita hitung biaya minimumnya.

Minimal, untuk setiap komputer kita memerlukan RAM 2 GB, yang harganya rata-rata 1.500 rubel, kartu jaringan yang mendukung kecepatan 1 Gbit/s berharga sekitar 700 rubel. Selain itu, Anda memerlukan setidaknya 1 router yang mendukung kecepatan 1 Gbit/s, yang biayanya sekitar 4.000 rubel. Total biaya - 26.000 rubel untuk peralatan, tidak termasuk pekerjaan.

Pada prinsipnya kecepatan dapat meningkat secara signifikan, namun kini tidak mungkin lagi membeli komputer murah untuk kantor. Selain itu, solusi ini tidak berlaku bagi mereka yang menggunakan Wi-Fi atau ingin bekerja melalui Internet - dalam kasus mereka, kecepatan jaringan bisa sepuluh kali lebih rendah. Muncul pemikiran: “Apakah tidak mungkin untuk mengimplementasikan seluruh program pada satu server yang kuat, sehingga komputer pengguna tidak berpartisipasi dalam perhitungan yang rumit, tetapi hanya berfungsi untuk mentransfer gambar?” Kemudian Anda dapat bekerja bahkan pada komputer yang sangat lemah, bahkan pada jaringan bandwidth rendah. Tentu saja, solusi seperti itu ada.

Solusi kedua. Server Terminal

Ini mendapatkan popularitas besar pada masa 1C 7. Ini diimplementasikan pada versi server Windows dan melakukan pekerjaan yang sangat baik dengan tugas kami. Namun, ada kendalanya, yaitu biaya perizinan.

Sistem operasinya sendiri akan menelan biaya sekitar 40.000 rubel. Selain itu, setiap orang yang berencana untuk bekerja di 1C memerlukan lisensi Windows Server CAL, yang harganya sekitar 1.700 rubel, dan lisensi Windows Remote Desktop Services CAL, yang harganya sekitar 5.900 rubel.

Setelah menghitung biaya untuk jaringan 10 komputer, kami mendapatkan 116.000 rubel. hanya untuk satu lisensi. Ditambah lagi biaya server itu sendiri (setidaknya 40.000 rubel) dan biaya implementasi, namun, bahkan tanpa ini, harga lisensinya ternyata sangat mengesankan.

Solusi ketiga. Layanan 1C Perusahaan

1C telah mengembangkan solusinya sendiri untuk masalah ini, yang dapat meningkatkan kecepatan program secara signifikan. Tapi ada nuansa di sini juga.

Faktanya adalah biaya solusi semacam itu berkisar antara 50.000 hingga 80.000 rubel, tergantung pada edisinya. Untuk perusahaan dengan pengguna hingga 15 orang ternyata cukup mahal. Harapan besar ditempatkan pada "server mini perusahaan 1C", yang menurut perusahaan 1C, ditujukan untuk usaha kecil dan biayanya sekitar 10.000 - 15.000 rubel.

Namun saat mulai dijual, produk ini mengecewakan besar. Faktanya adalah jumlah maksimum pengguna yang dapat menggunakan server mini hanya 5.

Seperti yang ditulis oleh salah satu programmer 1C di forum: “Masih belum jelas mengapa 1C memilih tepat 5 koneksi! Masalahnya hanya dimulai dengan 4 pengguna, tetapi dengan lima pengguna semuanya berakhir. Kalau mau menghubungkan orang keenam, bayar 50 ribu lagi. Setidaknya kita bisa membuat 10 koneksi…”

Tentu saja, server mini juga menemukan konsumennya. Namun, untuk perusahaan di mana 5 orang atau lebih bekerja dengan 1C, solusi sederhana dan murah belum muncul.

Selain metode akselerasi program yang dijelaskan di atas, ada satu lagi yang ideal untuk segmen 5 - 15 pengguna, yaitu akses web untuk 1C dalam mode file.

Solusi keempat. Akses web untuk 1C dalam mode file

Prinsip operasinya adalah sebagai berikut: peran tambahan server web dipasang di komputer, tempat keamanan informasi dipublikasikan.

Tentu saja, ini harus berupa komputer paling kuat di jaringan, atau mesin terpisah yang didedikasikan untuk peran ini. Setelah itu, Anda dapat bekerja dengan 1C dalam mode server web. Semua operasi berat akan dilakukan di sisi server, dan lalu lintas yang dikirimkan melalui jaringan akan diminimalkan, begitu pula beban pada komputer klien.

Dengan demikian, bahkan mesin yang sangat lemah pun dapat digunakan untuk bekerja di 1C, dan bandwidth jaringan menjadi tidak kritis. Pengujian kami menunjukkan bahwa Anda dapat bekerja dengan nyaman melalui Internet seluler di tablet murah tanpa mengalami ketidaknyamanan.

Opsi ini lebih rendah daripada server perusahaan 1C dalam hal kecepatan operasi, tetapi perbedaan ini praktis tidak terlihat hingga 15-20 pengguna. Omong-omong, untuk mengimplementasikan server web Anda dapat menggunakan IIS (untuk Windows) dan Apache (untuk Linux) dan kedua solusi ini gratis!

Terlepas dari keuntungan yang jelas, metode mengoptimalkan operasi 1C ini belum mendapatkan banyak popularitas.

Saya tidak bisa memastikannya, tetapi kemungkinan besar hal ini disebabkan oleh dua alasan:

  • Deskripsi yang cukup lemah dalam dokumentasi teknis
  • Terletak di persimpangan tanggung jawab administrator sistem dan pemrogram 1C

Biasanya, ketika administrator sistem didekati dengan masalah kecepatan rendah, ia menawarkan untuk meningkatkan infrastruktur atau server terminal, jika spesialis 1C dihubungi, ia ditawari server perusahaan 1C. Jadi, jika di perusahaan Anda seorang spesialis yang bertanggung jawab atas infrastruktur dan seorang spesialis yang bertanggung jawab atas 1C bekerja “bergandengan tangan”, maka Anda dapat dengan aman menggunakan solusi berbasis server web.

Ayo percepat 1C. Dari jarak jauh, cepat dan tanpa partisipasi Anda

Kami tahu cara mempercepat 1Ski tanpa mengganggu pelanggan. Kami menyelidiki masalahnya, melakukan pekerjaan kami dan pergi. Jika Anda ingin program berfungsi normal, hubungi kami. Kami akan mencari tahu.

Tinggalkan permintaan dan dapatkan konsultasi gratis tentang percepatan program.

Dalam banyak hal, pengoptimalan dan kecepatan kerja 1C bergantung pada bekerja dengan kunci, kueri, dan indeks. Kami akan mencoba menjawab pertanyaan “bagaimana mempercepat kerja 1C” (pertanyaan tentang bagaimana mempercepat peluncuran 1C akan kami pertimbangkan di artikel lain) dan menghindari keluhan pengguna tentang “pemrosesan dokumen yang lama”, yang pasti mempengaruhi proses bisnis.

Bagian 3. Kinerja 1C

Kunci di 1C 8.3: pencarian dan penghapusan dalam kode, transfer ke kunci yang dikelola

Kunci adalah bagian dari mekanisme ACID. Mari kita perhatikan konsepnya, disajikan dalam bentuk diagram yang disederhanakan, menggunakan contoh SQL SERVER

Dalam mode otomatis, kunci dikelola oleh DBMS itu sendiri. Pada saat yang sama, efek samping muncul di server MS SQL, seperti mengunci tabel kosong dan rentang data batas (level Serializable), yang menciptakan masalah tambahan dalam pekerjaan multi-pengguna. Untuk mengatasi masalah ini, 1C menciptakan kunci terkontrol.

Kunci terkontrol 1C

Mekanisme penguncian dipindahkan ke server 1C, dan pada tingkat DBMS, isolasi dikurangi seminimal mungkin. Di MS SQL, tingkat isolasi diturunkan menjadi Read Commited dengan mekanisme penguncian bersama pada platform 8.2 dan mekanisme pembuatan versi baris pada platform 8.3 (yang disebut Read Commited Snapshot Isolation). Lebih tepatnya, ini adalah properti database dengan nama yang sama dan dua mode operasi Read Commited yang bergantung pada parameter ini.

Pada tingkat isolasi terakhir (RCSI), mekanisme ini memungkinkan untuk tidak memotong transaksi membaca dan menulis pada sumber daya yang sama di server DBMS. Semua pekerjaan utama diambil alih oleh layanan pemblokiran 1C, yang menentukan, berdasarkan metadata asli, mengizinkan transaksi ke server DBMS atau tidak, sehingga tidak ada pelanggaran logika bisnis. Masalah dengan mengunci tabel kosong dan rentang batas sudah berlalu.

DBMS Jenis kunci Tingkat isolasi transaksi Baca di luar transaksi
Kunci otomatis
Basis Data Berkas Tabel Dapat diserialkan Bacaan kotor
MSSQL Server Postingan Bacaan kotor
IBM DB2 Postingan Baca Berulang atau Serializable Bacaan kotor
PostgreSQL Tabel Dapat diserialkan Membaca secara konsisten
Basis Data Oracle Tabel Dapat diserialkan Membaca secara konsisten
Kunci yang dikelola
Basis Data Berkas Tabel Dapat diserialkan Bacaan kotor
MSSQL Server 2000 Postingan Baca Berkomitmen Bacaan kotor
MS SQL Server 2005 dan lebih tinggi Baca Cuplikan yang Dikomitmenkan Membaca secara konsisten
IBM DB2 sebelum versi 9.7 Postingan Baca Berkomitmen Bacaan kotor
IBM DB2 versi 9.7 dan lebih tinggi Postingan Baca Berkomitmen Membaca secara konsisten
PostgreSQL Postingan Baca Berkomitmen Membaca secara konsisten
Basis Data Oracle Postingan Baca Berkomitmen Membaca secara konsisten

Untuk mengetahui mode pemblokiran database program 1C, Anda perlu menjalankan permintaan berikut dari SSMS dalam konteks database yang diinginkan:


kunci 1C. Pengguna tidak akan menunggu kunci, 1C akan mempercepat jika Anda mematuhi aturan tertentu:

  • Durasi transaksi harus dikurangi sebanyak mungkin. Melakukan perhitungan yang panjang dalam suatu transaksi dalam 100% kasus akan menyebabkan pemblokiran saat bekerja pada sistem OLTP.
  • Operasi eksternal yang panjang dalam suatu transaksi dihilangkan, misalnya mengirim dan menerima konfirmasi melalui email, bekerja dengan sistem file, dan tindakan tambahan lainnya. Semua operasi harus ditempatkan dalam tugas singkat yang ditangguhkan.
  • Kueri dioptimalkan secara maksimal.
  • Indeks harus dibuat hanya jika diperlukan untuk memastikan kinerja kueri yang optimal dalam aplikasi.
  • Penyertaan kolom yang sering diperbarui dalam indeks berkerumun telah diminimalkan. Pembaruan pada kolom kunci indeks berkerumun memerlukan kunci pada indeks berkerumun dan semua indeks yang tidak berkerumun (karena baris pencari lokasinya berisi kunci indeks berkerumun).
  • Jika memungkinkan, indeks penutup dibuat dan digunakan untuk mengurangi waktu pengambilan data.
  • Menggunakan tingkat isolasi transaksi terendah, yang memerlukan peralihan ke mode penguncian terkelola.

Alat untuk mendiagnosis penyumbatan:

  • Majalah teknologi;
  • Pusat Manajemen Kinerja dari alat 1C;
  • Layanan cloud Gilev;

Di bawah ini adalah contoh monitoring sistem menggunakan layanan Gilev. Total durasi pemblokiran adalah ~15 jam. Lebih dari 400 pengguna aktif. Setelah pengambilan keputusan dan pengoptimalan, waktu tunggu kurang dari satu menit, dan jumlah pemblokiran telah berkurang ~670 kali lipat.

Dulu:



Menjadi:


Dalam situasi di mana "semuanya hang dan memakan waktu lama", dan layanan pemantauan tidak dikonfigurasi atau tidak digunakan sama sekali, mengingat prinsip Pareto, Anda harus fokus pada kode.

Dalam mode otomatis, keberadaan kunci di server dapat dideteksi menggunakan prosedur sistem dalam konteks database yang diinginkan. Prosedur tersimpan ini memungkinkan Anda menentukan dalam mode apa kunci beroperasi, statusnya, jenisnya, dll.:



Setelah menyelesaikan prosedur untuk 1C, Anda bisa mendapatkan informasi visual tentang apa yang sedang terjadi di server, dengan mempertimbangkan spesifikasi tabel 1C:


Fragmen 1

//Kunci dalam istilah 1C SELECT * FROM dbo.ReturnLockName1C(DEFAULT,DEFAULT) sebagai t Dimana TableName1C BUKAN NULL ORDER BY t.Resource

Penggunaan mekanisme ini memungkinkan Anda memperoleh informasi lengkap tentang kunci saat ini. Jika laporan hanya berisi kunci S, masalahnya mungkin berupa kueri atau kueri yang sudah berjalan lama. Untuk mengetahui penyebab dan tempat kemunculannya dalam kode, Anda dapat mengambil jalur yang berbeda: menggunakan objek DMO dari server SQL (tetapi perlu diingat bahwa data dari objek tersebut disetel ulang setelah server di-boot ulang) atau konfigurasikan Pengumpul Data, menyimpan data pemantauan dalam tabel untuk waktu tertentu. Hal utama adalah mendapatkan teks permintaan yang bermasalah.

Menggunakan Objek DMO SQL Server

Kami menampilkan tanggal mulai server untuk memahami relevansi data. Kami membagi paket berdasarkan pembacaan rating (fisik, logis, beban prosesor). Dalam hal ini, data master dari sys.dm_exec_query_stats digunakan. Kami menerjemahkan teks permintaan ke dalam istilah 1C. Jika Anda dapat memahami konteks panggilan dari teks permintaan, yang tersisa hanyalah melihat rencana permintaan, menemukan operator yang bermasalah, dan memahami apa yang dapat dilakukan.

Fragmen 2

//waktu mulai PILIH sqlserver_start_time DARI sys.dm_os_sys_info; //Permintaan teratas untuk pembacaan fisik SELECT TOP (50) (total_physical_reads) AS Total_physical_reading,

Mengidentifikasi kueri bermasalah akibat pengumpulan Pengumpul Data

Dengan menggunakan alat ini, Anda dapat mengurutkan data berdasarkan parameter yang diperlukan, seperti beban prosesor, durasi, I/O logis, operasi pembacaan fisik, yang memungkinkan Anda menyimpan statistik lengkap untuk analisis lebih lanjut, meskipun server SQL telah di-reboot.


Setelah permintaan bermasalah dikumpulkan oleh server tanpa pemantauan pihak ketiga, Anda dapat memberi peringkat pada data yang diterima sesuai dengan parameter yang diperlukan.

Selanjutnya, dengan mengaktifkan log teknologi dan menentukan dalam pengaturan "pencarian berdasarkan string" dan bagian dari permintaan yang dijamin akan ditemui, Anda dapat mengetahui dari mana permintaan yang bermasalah itu dipanggil. Jika server memiliki beberapa database atau nama pengguna diketahui, ada baiknya menambahkan kolom tambahan untuk filter guna mengurangi beban di server saat mengumpulkan log proses.

Contoh permintaan masalah dan contoh pengaturan log teknologi:



Optimalisasi kueri sebagai peluang untuk mempercepat 1C 8.3


Konsekuensi dari kueri yang kurang optimal dapat terwujud dalam bentuk pemrosesan dokumen yang lama, pembuatan laporan yang sangat lama, sistem macet, dan kejadian tidak menyenangkan lainnya.

Saat menangani permintaan, Anda TIDAK BISA:

  • Bergabunglah dengan tabel dengan subkueri;
  • Hubungkan tabel biasa dengan tabel virtual;
  • Gunakan logika "ATAU" dalam kondisi;
  • Gunakan subkueri dalam kondisi gabungan;
  • Menerima data melalui titik dari bidang tipe komposit tanpa kata kunci “Ekspres”.

Saat menangani permintaan, ANDA DAPAT:

  • Membuat indeks berdasarkan kondisi kueri, bidang gabung, agregasi, dan pengurutan;
  • Pemfilteran tabel virtual harus dilakukan menggunakan parameter pemilihan.

Menggunakan indeks dan dampaknya terhadap kualitas kinerja sistem

Banyak yang telah ditulis tentang indeks, kebutuhan penggunaannya dan dampaknya terhadap kualitas operasi sistem. Mari kita coba memahami seluk-beluk “desain” indeks, opsi aplikasi, dan keunggulan dibandingkan tabel biasa.

Pengindeksan adalah bagian penting dari kernel DBMS. Indeks tidak ada, atau sebaliknya, terlalu banyak indeks, mempengaruhi kecepatan pengambilan, modifikasi, penambahan dan penghapusan data. Mari kita lihat pengindeksan menggunakan contoh Microsoft DBMS yang paling umum.

Untuk pemahaman umum tentang cara kerjanya, mari kita lihat detail mekanisme penyimpanan data, yang biasanya kita gambarkan dalam bentuk tabel (misalnya Excel).

Unit penyimpanan data fisik adalah halaman - modul 8 KB yang hanya dimiliki oleh satu objek (misalnya, tabel atau indeks). Halaman adalah unit terkecil untuk membaca dan menulis. Halaman dikumpulkan ke dalam luasan. Luasnya terdiri dari 8 halaman berturut-turut. Halaman perluasan dapat dimiliki oleh satu atau lebih objek. Jika halaman dimiliki oleh beberapa objek, luasnya disebut "campuran".

Isinya dapat dilihat di bawah ini:





Sekarang kita sudah mempunyai gambaran tentang cara kerja unit penyimpanan disk, mari kita bahas lebih lanjut tentang tabel dan indeks.

Secara default, jika Anda tidak menggunakan pernyataan T-SQL khusus, tabel kosong dibuat sebagai "heap" - satu set halaman dan luasan sederhana. Data di heap tidak memiliki urutan logis. Mesin SQL Server melacak kepemilikan halaman dan luas objek tertentu menggunakan halaman sistem khusus yang disebut Peta Alokasi Indeks. Setiap tabel atau indeks memiliki setidaknya satu halaman IAM, yang disebut "halaman IAM pertama".


Jadi, setelah membuat tabel biasa, secara default, hasilnya adalah susunan data yang kacau. Anda dapat melihat status tabel menggunakan prosedur berikut:


Indeks utama yang digunakan oleh platform 1C

Fragmen 3

Mitos dan kenyataan:

Mitos pertama: indeks berkerumun dan tabel data adalah dua entitas berbeda, disimpan secara terpisah satu sama lain.

Mitos kedua: bisa ada banyak indeks yang berkerumun dalam satu tabel.

Saya mengunduh program untuk mengoptimalkan DBMS. Membuat indeks yang direkomendasikan. Kecepatan pengambilan sampel meningkat sebesar 50%. Mengubah dan menambahkan data melambat 7 kali.

Indeks berkerumun (berkelompok).

Indeks terkluster adalah sekumpulan halaman yang mengurutkan dan menyimpan baris data dalam tabel atau tampilan berdasarkan nilai kuncinya—kolom yang disertakan dalam definisi indeks. Ada batasan pada jenis indeks ini yaitu 16 kolom dan 900 byte. Untuk setiap meja hanya ada satu indeks berkerumun, karena baris data hanya dapat diurutkan dalam satu urutan. Pembuatan indeks berkerumun dilakukan dengan menata ulang tabel, bukan menyalin data, sehingga tabel dapat disimpan sebagai pohon seimbang.

Fragmen 4

PILIH NAMA, JENIS, TYPE_DESC DARI sys.indexes WHERE object_id = OBJECT_ID("Lacak Data")

Indeks non-cluster

Indeks yang tidak berkerumun memiliki struktur yang terpisah dari baris data. Indeks non-cluster berisi nilai kunci indeks cluster, dan setiap record berisi kunci indeks cluster (bukan RID, karena tabel 1C tidak menggunakan heap, dengan pengecualian yang jarang terjadi).

Anda dapat menambahkan kolom bukan kunci ke tingkat daun indeks noncluster dan melewati batas kunci indeks yang ada (900 byte dan 16 kolom kunci) dengan menjalankan kueri yang diindeks sepenuhnya.

Setelah menambahkan indeks non-cluster, data disalin dan objek lain muncul:



Fragmen 5

PILIH NAMA, JENIS, TYPE_DESC DARI sys.indexes WHERE object_id = OBJECT_ID("Lacak Data")

Skema indeks cluster setelah mengambilnya dari heap dalam bentuk pohon seimbang:



Skema indeks non-cluster yang berasal dari tabel cluster (perhatikan bahwa kolom pencari baris memiliki kunci indeks cluster):



Dampak indeks pada kinerja kueri

Dengan menggunakan indeks, pengoptimal kueri mencari kolom kunci dalam indeks, menemukan tempat baris kueri disimpan, dan mengambil baris yang cocok dari sana. Pencarian indeks jauh lebih cepat daripada pencarian tabel karena, tidak seperti tabel, indeks sering kali berisi lebih sedikit kolom per baris, dan baris-barisnya diurutkan secara berurutan.

Membuat beberapa indeks mengarah pada fakta bahwa kecepatan pengambilan sampel meningkat, dan kecepatan tulis selama modifikasi berkurang secara signifikan. Untuk mengatasi masalah ini, pertama-tama, Anda perlu menghapus indeks yang tidak diperlukan atau menguncinya terlebih dahulu tanpa menghapusnya, sehingga Anda dapat dengan mudah mengaktifkannya jika diperlukan.

Harap dicatat bahwa indeks berkerumun tidak dapat diblokir dalam keadaan apa pun, karena ini akan memblokir akses ke data tabel. Ini hanya berlaku untuk indeks yang Anda buat sendiri melalui T-SQL. Alasan pembuatan indeks menggunakan T-SQL, melewati 1C:Enterprise, pertama-tama disebabkan oleh terbatasnya kemampuan platform 1C dalam hal memanipulasi indeks dan memasukkan bidang tambahan dalam indeks yang dibuat.

Pernyataan T-SQL yang melakukan tindakan mengunci indeks:

//Kunci indeks terpisah dalam tabel -ALTER INDEX _Reference22_ByPredefinisiIDNotUniq ON _Reference22 DISABLE; //Sertakan indeks yang diinginkan -ALTER INDEX _Reference22_ByPredefinisiIDNotUniq ON _Reference22 REBUILD;

Selain langkah-langkah di atas, penting untuk membuat grup file pada disk fisik yang tidak berisi file database saat ini dan memindahkan indeks non-cluster ke sana. Ini akan mempercepat modifikasi data dengan memparalelkan pencatatannya.

Menentukan indeks mana yang diperlukan atau tidak untuk mempercepat kueri

Secara default, 1C membuat kumpulan indeks dasar tertentu. Seringkali jumlahnya tidak cukup. SQL Server memiliki mekanisme yang memungkinkan Anda memahami, berdasarkan beban kerja Anda, betapa pentingnya indeks yang ada.

Database Engine Tuning Advisor menganalisis database dan membuat rekomendasi untuk mengoptimalkan kinerja kueri. Ini dapat digunakan untuk memilih dan membuat kumpulan indeks yang optimal tanpa harus memiliki tingkat pemahaman ahli tentang desain database atau proses internal SQL Server. Asisten Konfigurasi Mesin Basis Data memungkinkan Anda melakukan tugas-tugas berikut:

  • Memecahkan masalah kinerja kueri tertentu yang bermasalah;
  • Konfigurasikan sekumpulan besar kueri dalam satu atau lebih database.

DMO (objek manajemen dinamis), yang mencakup tampilan manajemen dinamis dan fungsi manajemen dinamis. Misalnya, pernyataan T-SQL dapat mengambil semua indeks yang belum digunakan sejak server terakhir kali dimulai.



Fragmen 6

DENGAN vl sebagai (PILIH OBJECT_NAME(I.object_id) SEBAGAI nama objek, I.nama SEBAGAI nama indeks, I.index_id AS indeksid DARI sys.indexes SEBAGAI SAYA DALAM GABUNG sys.objects AS O ON O.object_id = I.object_id WHERE I.object_id > 100 DAN I.type_desc = "NONCLUSTERED" DAN I.index_id TIDAK DALAM (PILIH S.index_id DARI sys.dm_db_index_usage_stats AS S WHERE S.object_id=I.object_id DAN I.index_id=S.index_id AND database_id = DB_ID("Database_name '))) PILIH nama objek,T1.NamaTable1C, indeksid, nama indeks DARI vl LUAR BERLAKU dbo.ReturnTableName1C(nama objek) sebagai T1 ORDER BY nama objek, nama indeks;

Petunjuk yang dapat digunakan untuk membuat indeks yang diperlukan yang direkomendasikan oleh kernel DBMS:



Fragmen 7

PILIH T1.NameTable1C sebagai Table_Name_1C, "CREATE INDEX " + " ON "
Pengoptimal kueri, saat membuat rencana eksekusi kueri, mengidentifikasi kebutuhan untuk membuat indeks yang hilang. Ini menyimpan informasi ini dalam XML ShowPlan. Karena rencana kueri di-hash dan instruksi disimpan (sampai server restart berikutnya), kemudian dapat diambil, diproses dan instruksi siap pakai untuk membuat indeks yang diperlukan untuk setiap rencana eksekusi dalam cache diperoleh. Perlu diperhatikan frekuensi eksekusi kueri: semakin tinggi frekuensinya, semakin relevan hasil kueri dan, karenanya, indikator yang dikumpulkan. Jika kueri dijalankan satu kali, hasilnya tidak begitu indikatif.


Fragmen 8

CROSS APPLY query_plan.nodes('//StmtSimple") AS stmt(stmt_xml) WHERE stmt_xml.exist("QueryPlan/Missinglndexes") = 1) PILIH 30 Nama Basis Data TERATAS sebagai Nama_Database, NamaTabel sebagai Nama_Tabel, T1.NamaTabel1C sebagai Nama_Tabel 1C, kolom_kesetaraan ns sebagai Kolom_Perbandingan, sertakan_kolom sebagai Kolom_ke_termasuk,

Fragmen 9

GUNAKAN [Nama_Database] BUAT INDEKS NONCLUSTERED PADA .[_Document497] ([_Fld12771_TYPE],[_Fld12771_RTRef]) TERMASUK ([_Fld12784]) GO Beberapa fitur pengindeksan berdasarkan bidang agregat dan bidang pengurutan.

Membuat indeks pada kolom yang ditentukan dalam klausa ORDER BY membantu pengoptimal kueri dengan cepat mengatur kumpulan hasil karena nilai kolom diurutkan terlebih dahulu dalam indeks. Implementasi internal mekanisme GROUP BY juga mengurutkan nilai kolom terlebih dahulu untuk mengelompokkan data yang diperlukan dengan cepat.

Saat menggunakan rekomendasi standar, ada baiknya memeriksa hasilnya sebelum dan sesudah optimasi. Mari kita beri contoh penggunaan gabungan logis "ATAU" dan alternatifnya (untuk menyelesaikan masalah menggunakan rekomendasi standar) - teknik mengubah kueri menggunakan sintaksis "UNITE ALL".

Permintaan 1C itu sendiri dengan "ATAU":

PILIH Kode, Nama, Tautan DARI Direktori. Counterparty SEBAGAI Counterparties WHERE Counterparties. Kode = "000000004" ATAU Counterparty. Kode = "0074853" OR Counterparty. Kode = "000000024" ATAU Counterparty. Kode = "009679294" ATAU Counterparty. Kode = " 0074742" ATAU Rekanan.Kode = "000000104";

Memodifikasi kueri dengan “UNITE ALL”:

PILIH Kode, Nama, Tautan DARI Direktori.Counterparty SEBAGAI Counterparties WHERE Counterparties.Kode = "000000004" GABUNGKAN SEMUA PILIH Kode, Nama, Tautan DARI Direktori.Counterparty SEBAGAI Counterparties WHERE Counterparties.Kode = "0074853" GABUNGKAN SEMUA PILIH Kode, Nama, Tautan DARI Direktori.Counterparties SEBAGAI Counterparties WHERE Counterparties.Code = "000000024" GABUNGKAN SEMUA PILIH Kode, Nama, Tautan DARI Direktori.Counterparties SEBAGAI Counterparties WHERE

Rencana kueri aktual (untuk kemudahan tampilan dan perbandingan kinerja, kueri dicegat dan dieksekusi di SSMS):


Dalam hal ini, setelah pengoptimalan, performa turun setengahnya karena penggunaan berulang kali operator Pencarian Kunci, yang selalu disertai dengan operator Nested Loops. Oleh karena itu, saat menggunakan skema pengoptimalan kueri, Anda harus mengukur waktu target sebelum dan sesudah menggunakan peningkatan. Contoh ini ditampilkan untuk tujuan “percaya tetapi verifikasi”, karena mungkin ada ketidakkonsistenan antara rekomendasi umum dan masalah praktis.

Cara mempercepat pekerjaan di 1C: Accounting 8.3 (edisi 3.0) atau menonaktifkan tugas rutin dan latar belakang

15-01-2019T13:28:19+00:00

Anda yang telah beralih ke edisi baru 1C: Accounting 8.3 (edisi 3.0) menyadari bahwa ini menjadi lebih lambat dari 2. Beberapa perlambatan yang aneh, tugas latar belakang yang tak ada habisnya beberapa kali sehari, yang tidak diminta oleh siapa pun tanpa sepengetahuan kami.

Akuntan saya segera memberi tahu saya setelah transisi bahwa edisi baru 1C: Accounting 3.0 benar-benar lambat dibandingkan edisi sebelumnya! Dan itu tidak mungkin berhasil.

Saya mulai menyelidikinya dan segera menemukan bahwa penyebab utama pembekuan dan ketidakpuasan pengguna berikutnya adalah tugas-tugas rutin dan latar belakang, banyak di antaranya diaktifkan secara default, meskipun bagi sebagian besar akuntan hal tersebut tidak diperlukan.

Misalnya, mengapa kita perlu menjalankan tugas "Ekstraksi Teks" seratus kali sehari jika kita tidak melakukan pencarian teks lengkap (akuntan, jangan khawatir) di semua objek di database kita.

Atau mengapa terus-menerus mendownload nilai tukar mata uang jika kita tidak memiliki transaksi mata uang atau kita melakukannya sesekali (dan sebelum itu kita sendiri dapat mengklik tombol download nilai tukar).

Hal yang sama berlaku untuk upaya terus-menerus 1C untuk terhubung ke situs dan memeriksa serta memperbarui pengklasifikasi bank. Untuk apa? Saya sendiri akan menekan tombol untuk memperbarui pengklasifikasi jika saya tidak menemukan bank yang tepat berdasarkan BIC-nya.

Cara melakukannya langkah demi langkah di bawah ini.

1. Buka bagian "Administrasi" dan pilih "Pemeliharaan" () di panel tindakan:

2. Di jendela yang terbuka, cari dan pilih “Tugas rutin dan latar belakang”:

3. Buka setiap tugas yang memiliki tulisan “On” pada kolom “On”. ada gagak.

4. Hapus centang "Diaktifkan" dan klik tombol "Simpan dan Tutup".

5. Lakukan ini dengan setiap tugas yang disertakan dan nikmati edisi baru. Secara keseluruhan, menurut saya, ini jauh lebih baik daripada dua.

Pada saat yang sama, platform akan tetap mengaktifkan beberapa tugas terjadwal yang Anda nonaktifkan.

Sistem 1C saat ini merupakan salah satu alat utama untuk menjalankan usaha kecil dan menengah. Sebagai aturan, semua karyawan organisasi memiliki akses ke program ini. Jadi, jika 1C mulai melambat atau bekerja lambat, hal ini berdampak signifikan terhadap jalannya bisnis. Mari kita lihat bagaimana Anda sendiri dapat mempercepat dan mengoptimalkan pekerjaan di 1C.


Optimasi menggunakan pembaruan 1C

Versi baru 1C selalu bekerja lebih sukses dan cepat, jadi sangat penting untuk mengikuti pembaruan. Disarankan untuk memperbarui catatan akuntansi Anda sesering mungkin. Terutama ketika versi pelaporan yang diatur dirilis.

Banyak orang telah lama menggunakan kemampuan untuk memperbarui program secara otomatis. Meskipun masalah ini dapat dengan mudah diselesaikan secara manual untuk 1C Enterprise 8.3, pembaruannya tidak akan menimbulkan masalah apa pun.

Langkah pertama adalah mendownload versi terbaru platform yang Anda gunakan saat ini. Hal ini dilakukan baik dengan menggunakan disk ITS, atau melalui antarmuka web, di mana mereka memberikan dukungan berkelanjutan kepada pengguna program seperti 1c Enterprise 8.3, pembaruan konfigurasi yang juga disediakan secara resmi.

Dalam kasus terakhir, arsip dengan data pembaruan diunduh secara terpisah. Itu dibongkar ke folder mana pun yang dianggap paling nyaman bagi pengguna. Maka Anda perlu menjalankan file .exe. Di jendela berikutnya, cukup klik tombol “Berikutnya”.

Halaman lain akan muncul. Di atasnya, pengguna memilih jalur di mana instalasi selesai. Namun langkah ini disarankan hanya untuk pemilik komputer pribadi tingkat lanjut. Fungsi default biasanya cukup untuk menyelesaikan sebagian besar masalah. Secara default, dalam hal ini, satu folder ditentukan tempat semua pembaruan diinstal sekaligus. Ini jauh lebih nyaman dibandingkan ketika jalur akhir berbeda. Kami cukup mengklik tombol "Berikutnya" beberapa kali di program 1c Enterprise 8.3, yang konfigurasinya harus diperbarui dengan cepat.

Yang tersisa hanyalah tombol terakhir, yang menawarkan “Instal”.

Cara mempercepat 1C jika platformnya lambat

Masalah paling sering timbul dari kenyataan bahwa pada salah satu tahap konsentrasi perhatian pemain menurun. Di sini penting untuk memilih skema pembaruan yang tepat, hanya dalam hal ini kita tidak akan menemui masalah ketika 1c macet selama pembaruan.

Pembaruan versi 7.7

Ada beberapa jenis konfigurasi. Tergantung pada ini, tindakan selanjutnya dipilih.

  • Standar – dalam hal ini diasumsikan bahwa pembaruan juga dilakukan untuk pelaporan yang diatur.
  • Konfigurasi industri pada umumnya sebagian besar mengingatkan pada opsi sebelumnya. Penting untuk membaca instruksi yang diberikan oleh pengembang terlebih dahulu. Jika tidak, Anda tidak akan dapat mengetahui mengapa 1C 8.3 mogok selama pembaruan.
  • Standar yang dimodifikasi - pengguna selalu memiliki kesempatan untuk memodifikasi aplikasinya sendiri sehingga memenuhi kebutuhan saat ini. Pilihan lain untuk memperluas fungsionalitas adalah berpindah ke platform baru. Misalnya versi 8.

Tentang versi 8.0 dan 8.1

Saat ini, platform 8.0 sudah ditarik dari dukungan. Perkembangan standar baru hanya akan berfungsi bila menggunakan versi terbaru. Anda hanya perlu mengingat bahwa semua rilis perantara diselesaikan tanpa gagal. Jika tidak, ada kemungkinan besar kehilangan informasi. Atau menghadapi situasi di mana 1c macet saat memperbarui konfigurasi.

Suatu pilihan dimungkinkan ketika konfigurasi standar baru diterapkan, dan kemudian sisa-sisa dari database informasi lama ditransfer ke sana.

Sedangkan untuk versi 8.1, Anda dapat memperbaruinya dengan beberapa cara:

  1. secara manual;
  2. dalam mode otomatis;
  3. menghubungi spesialis dari perusahaan yang menyediakan layanan di bidang ini.

Bekerja dengan versi non-standar atau modifikasi

Awalnya, konfigurasi apa pun mengacu pada pengembangan standar. Hal ini tidak lagi terjadi jika perubahan tertentu dilakukan di perusahaan. Misalnya pada saat instalasi. Ada dua kelas yang menonjol di antara konfigurasi non-standar:

  1. berubah;
  2. dibuat dari awal, dengan mempertimbangkan kebutuhan perusahaan tertentu.

Terkadang konfigurasi kelas kedua didistribusikan secara aktif di antara pengguna. Maka itu dianggap tipikal. Hanya saja yang dianggap bukan 1C itu sendiri adalah pabrikannya, melainkan perusahaan yang membuat versi baru tersebut.

Konfigurasi dapat selalu diperbarui dengan tindakan berikut:

  • Koreksi kesalahan.
  • Perluasan fungsionalitas.
  • Peningkatan.
  • Perubahan di 1C 8.3, konfigurasi tidak diperbarui jika terjadi kesalahan pemeliharaan.

Proses instalasi mungkin memerlukan waktu yang berbeda-beda tergantung pada kecepatan Internet yang Anda gunakan saat ini. Di jendela terpisah, pengguna memilih apakah akan memperbarui setelah pekerjaan selesai, atau segera. Dengan opsi terakhir, Anda perlu memastikan tidak ada orang lain yang bekerja dengan aplikasi tersebut. Prosesnya sendiri melibatkan penggunaan mode eksklusif dalam aplikasi 1c Enterprise 8.3, tidak terkecuali pembaruan terbaru.

  • Kita harus ingat bahwa tidak semua versi rilis cocok untuk konfigurasi saat ini.
  • Jika pembaruan sudah lama tidak dilakukan, Anda mungkin harus mengunduh beberapa file atau arsip sekaligus.
  • Dalam daftar, mudah untuk memahami versi 1C Enterprise 8.3 mana yang diperlukan, pembaruan dipilih oleh pengguna.

Ketika proses selesai, Configurator itu sendiri dapat ditutup. Mode ini paling sering digunakan jika pembaruan diperlukan. Ini nyaman dan mengotomatiskan hampir seluruh proses. Saat Anda meluncurkannya untuk pertama kali, sebuah pesan mungkin muncul yang menunjukkan bahwa platform tersebut sudah ketinggalan zaman. Dan tidak disarankan untuk menggunakannya saat ini.

Alasan tambahan untuk pengereman

Jika program diperbarui dengan benar dan tanpa kesalahan apa pun, namun 1C masih melambat, alasannya mungkin sebagai berikut:

  • Antivirus - jika dikonfigurasi dengan benar, tidak ada antivirus yang akan mengganggu sistem, namun jika Anda menggunakan pengaturan pabrik, kinerja 1C dapat menurun sebesar 5–10%. Anda dapat mengoptimalkan antivirus Anda menggunakan pengaturan tambahan dengan menghapus mode latar belakang (jika benar-benar diperlukan).
  • Parameter komputer - seringkali komputer yang tidak cukup kuat menyebabkan penurunan kinerja 1C secara signifikan. Perhatian khusus harus diberikan pada kartu video, sistem operasi, dan prosesor.

Metode seperti itu akan secara signifikan mengoptimalkan dan mempercepat pekerjaan di 1C untuk perusahaan atau perusahaan mana pun, setelah itu kinerja program akan meningkat secara signifikan.

Cara meningkatkan kecepatan dan kemudahan penggunaan di 1C

Gejala dan riwayat pasien:

Pekerjaan beberapa pengguna melalui jaringan dengan file (database) yang sama mencakup mekanisme pemblokiran jaringan. Hal ini memaksa sistem membuang waktu yang berharga untuk mengidentifikasi sesi rekaman terbuka dan menyelesaikan konflik yang sesuai.

Tanda-tanda utama operasi pemblokiran:

  • pengguna cepat bekerja dengan database melalui jaringan dalam mode eksklusif dan sangat lambat ketika beberapa pengguna bekerja secara bersamaan
  • pengalaman pengguna yang cepat dengan database lokal di server dan kerja lambat melalui jaringan
  • akses sistem file hanya di bawah 10 MB/detik

Jadi, saya diberi tugas untuk memastikan bahwa sebanyak tiga pengguna dapat bekerja di 1C secara bersamaan! Lucu, bukan?

Saya lupa semua lelucon ketika melihat apa yang harus saya hadapi: sebuah “server” berupa sebuah komputer kantor biasa dan dua buah laptop.

Kebahagiaan tidak akan lengkap jika bukan karena sistem operasi yang luar biasa - Windows 7 di komputer dan di satu laptop, Windows 8 di laptop lainnya.

Saat mencoba memposting dokumen secara bersamaan di laptop, yang satu macet sekitar satu menit, dan yang kedua keluar dari 1C dengan teks kesalahan "tidak dapat mengunci tabel...".

Meluncurkan 1C di laptop adalah pertunjukan tersendiri yang berlangsung sekitar 3 menit!

Di banyak sumber saya menemukan saran untuk beralih bekerja di akses terminal. Sayangnya, Windows 7 tidak mengizinkan Anda untuk berubah menjadi server terminal menggunakan alat standar - maksimal satu koneksi aktif. Dalam hal ini, sesi yang tersisa tidak berakhir; Anda dapat menyambung kembali di bawah pengguna lain - "membuang" pengguna sebelumnya, tetapi tanpa menghentikan sesinya. Oleh karena itu, Anda harus mentransfer 1C ke OS server, di mana tidak ada batasan seperti itu. Klien, atas risikonya sendiri, memecahkan masalah menggunakan utilitas pihak ketiga Windows7_SP1_RDPhack.

Namun petualangannya tidak berakhir di situ. Bahkan pada sambungan terminal pun terjadi penundaan yang signifikan. Sekali lagi mesin pencari yang maha kuasa membantu saya. Berikut tips mempercepat file 1C yang saya ikuti:

1. Cacat penggunaan protokol jaringan IPv6, konfigurasikan pengalamatan pada IPv4 "lama".

2. Tambahkan proses 1C ke pengecualian firewall Windows, serta pengecualian antivirus, atau nonaktifkan sepenuhnya (lebih berisiko, tetapi tes sederhana menunjukkan peningkatan kecepatan transfer ulang dokumen ketika antivirus Avast dinonaktifkan faktor!)

3. Mulai mengindeks pencarian teks lengkap di 1C atau matikan sepenuhnya

4. Jalankan Pengujian dan perbaikan database, periksa dengan utilitas ChDbfl

5. Jalankan item Periksa Konfigurasi di konfigurasi (jika konfigurasinya tidak standar, ini mungkin berguna). Berdasarkan hasil pengecekan konfigurasi, secara ajaib ukurannya berkurang hampir sepertiganya. Saya tidak benar-benar menyelidiki apa yang diperbarui oleh pemrogram sebelum saya, tetapi faktanya jelas.

6. Nonaktifkan opsi fungsional yang tidak diperlukan.

7. Atur hak pengguna. (Ini dan saran sebelumnya tampak bodoh sampai saya mengamati rendering formulir terkelola saat membuka daftar dokumen. Semakin sedikit hal yang tidak diperlukan dalam antarmuka terkelola, biasanya semakin cepat kerjanya)

8. Mulailah menghitung ulang total dan memulihkan urutannya (peningkatan yang signifikan hanya dapat terjadi jika totalnya sudah lama tidak dipulihkan)

9. Tentukan "Kecepatan koneksi - rendah" dalam pengaturan daftar database (ini tidak memberikan banyak hasil, kecuali gambar subsistem dimatikan :))

Setelah menyelesaikan semua langkah ini, database file 1C mulai bekerja lebih cepat. Ini mulai diluncurkan dalam waktu maksimal 10 detik, dan kecepatan transfer dokumen meningkat rata-rata 12 kali lipat.

Mungkin artikel singkat ini bermanfaat bagi Anda jika Anda tiba-tiba perlu mempercepat database file 1C Anda.

P.S: Namun meluncurkan file 1C menggunakan akses jaringan ke folder bersama masih tidak realistis, karena... Bahkan solid-state drive, RAM, dan prosesor tercepat pun akan mengalami penyumbatan jaringan, dan pekerjaan lebih dari satu pengguna hampir tidak mungkin dilakukan. Kita berbicara secara khusus tentang konfigurasi UT 11.1. Konfigurasi kecil yang ditulis sendiri dapat bekerja cukup cepat bahkan dalam versi file.

Tambahan dari komentar untuk publikasi:

Defragmentasi Disk dengan basis file

Lilitan database (mungkin berguna jika database berukuran besar, misalnya untuk beberapa tahun). Basis data klien masih cukup muda, jadi pengurangannya tidak praktis.

Peningkatan perangkat keras - hard drive yang lebih cepat, switch baru, prosesor, dll.

Instal di server web, akses menggunakan klien tipis. Di sini pendapat terbagi. Ada yang mengatakan ini berkali-kali lebih cepat, ada pula yang mengatakan tidak ada akselerasi yang tercatat.

Publikasi tentang topik tersebut