Bagaimana Saya Mendiagnosis Masalah Pemblokiran. Bagaimana saya mendiagnosis masalah kunci 1c konflik kunci kesalahan saat menjalankan transaksi

Saya tidak dapat menuliskan perubahan untuk transfer ke database terdistribusi, saya menghubungi dukungan 1c dan menawarkan yang berikut ini. Saya memutuskan untuk me-restart server aplikasi dan server dengan SQL. Secara umum, Anda dapat mencentang kotak “Pemblokiran terjadwal
termasuk tugas"
Itu juga membantu tanpa me-reboot.

Operasi terjadwal pada tingkat DBMS untuk MS SQL Server

Instruksi untuk melakukan operasi rutin di tingkat DBMS.

Informasi ini berlaku untuk versi client-server 1C:Enterprise 8 saat menggunakan MS SQL Server DBMS.

Informasi Umum

Salah satu penyebab paling umum dari operasi sistem yang tidak optimal adalah pelaksanaan operasi rutin yang tidak tepat atau tidak tepat waktu pada tingkat DBMS. Sangat penting untuk melakukan prosedur rutin ini dalam sistem informasi besar yang beroperasi di bawah beban yang signifikan dan secara bersamaan melayani sejumlah besar pengguna. Kekhususan sistem tersebut adalah bahwa tindakan yang biasa dilakukan secara otomatis oleh DBMS (berdasarkan pengaturan) tidak cukup untuk operasi yang efisien.

Jika sistem yang berjalan menunjukkan gejala masalah kinerja, Anda harus memverifikasi bahwa sistem dikonfigurasi dengan benar dan secara teratur melakukan semua pemeliharaan rutin yang disarankan pada tingkat DBMS.

Eksekusi prosedur rutin harus otomatis. Untuk mengotomatisasi operasi ini, disarankan untuk menggunakan alat bawaan MS SQL Server: Rencana Pemeliharaan. Ada juga cara lain untuk mengotomatisasi prosedur ini. Dalam artikel ini, untuk setiap prosedur terjadwal, contoh konfigurasinya diberikan menggunakan Rencana Pemeliharaan untuk MS SQL Server 2005.

Disarankan untuk secara teratur memantau ketepatan waktu dan kebenaran pelaksanaan prosedur rutin ini.

Pembaruan statistik

MS SQL Server membangun rencana kueri berdasarkan informasi statistik tentang distribusi nilai dalam indeks dan tabel. Informasi statistik dikumpulkan berdasarkan sebagian (sampel) data dan diperbarui secara otomatis ketika data ini berubah. Terkadang ini tidak cukup bagi MS SQL Server untuk secara konsisten membangun rencana paling optimal untuk mengeksekusi semua kueri.

Dalam hal ini, masalah kinerja kueri mungkin terjadi. Pada saat yang sama, tanda-tanda karakteristik pekerjaan yang tidak optimal (operasi yang tidak optimal) diamati dalam rencana kueri.

Untuk menjamin pengoperasian pengoptimal MS SQL Server yang paling benar, disarankan untuk memperbarui statistik database MS SQL secara berkala.

Untuk memperbarui statistik untuk semua tabel database, Anda harus menjalankan kueri SQL berikut:

exec sp_msforeachtable N"PERBARUI STATISTIK ? DENGAN FULLSCAN"

Memperbarui statistik tidak menyebabkan penguncian tabel, dan tidak akan mengganggu pekerjaan pengguna lain. Statistik dapat diperbarui sesering yang diperlukan. Ingatlah bahwa beban pada server DBMS selama pembaruan statistik akan meningkat, yang dapat mempengaruhi kinerja sistem secara keseluruhan.

Frekuensi pembaruan statistik yang optimal tergantung pada besar dan sifat beban pada sistem dan ditentukan secara eksperimental. Disarankan untuk memperbarui statistik setidaknya sekali sehari.

Kueri di atas memperbarui statistik untuk semua tabel dalam database. Dalam sistem kehidupan nyata, tabel yang berbeda memerlukan tingkat pembaruan statistik yang berbeda. Dengan menganalisis rencana kueri, Anda dapat menentukan tabel mana yang memerlukan pembaruan statistik paling sering, dan menyiapkan dua (atau lebih) prosedur rutin yang berbeda: untuk tabel yang sering diperbarui dan untuk semua tabel lainnya. Pendekatan ini akan secara signifikan mengurangi waktu pembaruan statistik dan dampak dari proses pembaruan statistik pada pengoperasian sistem secara keseluruhan.

Mengonfigurasi pembaruan statistik otomatis (MS SQL 2005)

Mulai MS SQL Server Management Studio dan sambungkan ke server DBMS. Buka folder Manajemen dan buat rencana pemeliharaan baru:

Buat subplan (Tambah Subplan) dan beri nama "Pembaruan Statistik". Tambahkan Tugas Statistik Pembaruan ke sana dari bilah tugas:

Siapkan jadwal pembaruan statistik. Disarankan untuk memperbarui statistik setidaknya sekali sehari. Jika perlu, frekuensi pembaruan statistik dapat ditingkatkan.

Mengatur pengaturan tugas. Untuk melakukan ini, klik dua kali pada tugas di sudut kanan bawah jendela. Dalam formulir yang muncul, tentukan nama database (atau beberapa database) yang statistiknya akan diperbarui. Selain itu, Anda dapat menentukan tabel mana yang akan diperbarui statistiknya (jika Anda tidak tahu persis tabel mana yang perlu Anda tentukan, atur nilainya ke Semua).

Memperbarui statistik harus dilakukan dengan opsi Pemindaian Penuh diaktifkan.

Simpan rencana yang dibuat. Ketika waktu yang ditentukan dalam jadwal tiba, statistik akan diperbarui secara otomatis.

Membersihkan cache prosedural

Pengoptimal MS SQL Server menyimpan rencana kueri untuk dieksekusi ulang. Ini dilakukan untuk menghemat waktu yang dihabiskan untuk menyusun kueri jika kueri yang sama telah dieksekusi dan rencananya diketahui.

Ada kemungkinan bahwa MS SQL Server, dengan mengandalkan informasi statistik yang sudah ketinggalan zaman, akan membuat rencana kueri yang tidak optimal. Rencana ini akan disimpan dalam cache prosedural dan digunakan ketika kueri yang sama dipanggil lagi. Jika Anda telah memperbarui statistik tetapi tidak membersihkan cache prosedural, maka SQL Server dapat memilih paket kueri lama (tidak optimal) dari cache alih-alih membuat paket baru (lebih baik).

Untuk menghapus cache prosedural MS SQL Server, Anda harus menjalankan kueri SQL berikut:

Kueri ini harus dijalankan segera setelah memperbarui statistik. Dengan demikian, frekuensi pelaksanaannya harus sesuai dengan frekuensi pembaruan statistik.

Mengonfigurasi Pembersihan Cache Prosedural (MS SQL 2005)

Karena cache prosedural perlu dibersihkan setiap kali statistik diperbarui, disarankan untuk menambahkan operasi ini ke subplan "Perbarui statistik" yang sudah dibuat. Untuk melakukan ini, buka subplan dan tambahkan Tugas Pernyataan T-SQL Jalankan ke skemanya. Kemudian Anda harus menghubungkan Tugas Statistik Pembaruan dengan panah ke tugas baru.

Dalam teks Tugas Pernyataan T-SQL Jalankan yang dibuat, Anda harus menentukan kueri "DBCC FREEPROCCACHE":

Defragmentasi indeks

Saat Anda bekerja secara intensif dengan tabel database, efek fragmentasi indeks terjadi, yang dapat menyebabkan penurunan efisiensi kueri.

sp_msforeachtable N"DBCC INDEXDEFRAG (<имя базы данных>, ""?"")"

Defragmentasi indeks tidak memblokir tabel dan tidak akan mengganggu pekerjaan pengguna lain, namun, ini membuat beban tambahan pada SQL Server. Frekuensi optimal melakukan prosedur rutin ini harus dipilih sesuai dengan beban pada sistem dan efek yang diperoleh dari defragmentasi. Kami menyarankan Anda untuk mendefrag indeks Anda setidaknya sekali seminggu.

Dimungkinkan untuk mendefrag satu atau lebih tabel, tidak semua tabel dalam database.

Mengonfigurasi defragmentasi indeks (MS SQL 2005)

Dalam rencana pemeliharaan yang dibuat sebelumnya, buat subrencana baru bernama "Indeks Ulang". Tambahkan Tugas Rebuild Index ke dalamnya:

Atur jadwal eksekusi untuk tugas defragmentasi indeks. Disarankan untuk menjalankan tugas setidaknya sekali seminggu, dan jika data dalam database sangat fluktuatif, bahkan lebih sering - hingga sekali sehari.

Mengindeks ulang tabel database

Pengindeksan ulang tabel mencakup pembangunan kembali indeks tabel database secara lengkap, yang mengarah pada optimalisasi signifikan dari pekerjaan mereka. Disarankan untuk melakukan pengindeksan ulang tabel database secara teratur. Untuk mengindeks ulang semua tabel database, Anda harus menjalankan kueri SQL berikut:

sp_msforeachtable N"DBCC DBREINDEX(""?"")"

Mengindeks ulang tabel memblokirnya selama pekerjaan mereka, yang secara signifikan dapat mempengaruhi pekerjaan pengguna. Dalam hal ini, pengindeksan ulang direkomendasikan untuk dilakukan selama beban sistem minimum.

Setelah pengindeksan ulang, tidak perlu mendefrag indeks.

Menyiapkan pengindeksan ulang tabel (MS SQL 2005)

Dalam rencana pemeliharaan yang dibuat sebelumnya, buat subrencana baru bernama "Defragmentasi Indeks". Tambahkan Tugas Rebuild Index ke dalamnya:

Atur jadwal eksekusi untuk tugas pengindeksan ulang tabel. Disarankan untuk menjalankan tugas selama beban minimum pada sistem, setidaknya seminggu sekali.

Kustomisasi tugas dengan menentukan database (atau beberapa database) dan memilih tabel yang diperlukan. Jika Anda tidak tahu persis tabel mana yang harus ditentukan, setel nilainya ke Semua.

Ketika ratusan pengguna bekerja dengan program dan data pada saat yang sama, ada masalah yang hanya melekat pada solusi skala besar. Kita berbicara tentang masalah yang disebabkan oleh kunci data.

Terkadang pengguna mengetahui tentang kunci dari pesan yang menunjukkan ketidakmampuan untuk menulis data atau melakukan beberapa operasi lain. Terkadang karena penurunan kinerja program yang sangat signifikan (misalnya, ketika waktu yang dibutuhkan untuk melakukan operasi bertambah puluhan atau ratusan kali lipat).

Masalah yang disebabkan oleh pemblokiran tidak memiliki solusi umum. Oleh karena itu, kami akan mencoba menganalisis penyebab masalah tersebut dan mensistematisasikan opsi untuk solusinya.

ALASAN BLOKIR TRANSAKSI

Pertama-tama mari kita ingat apa itu kunci, dan pada saat yang sama kita akan mencari tahu apakah itu diperlukan. Mari kita lihat beberapa contoh klasik pemblokiran yang kita temui dalam hidup.

Contoh 1: Membeli tiket pesawat atau kereta api. Misalkan kita menyuarakan keinginan kita kepada kasir. Kasir memberi tahu kami ketersediaan kursi, dari mana kami dapat memilih yang paling kami sukai (jika ada beberapa, tentu saja). Sampai kami memilih dan mengonfirmasi persetujuan kami dengan opsi yang diusulkan, kursi ini tidak dapat dijual kepada orang lain, mis. diblokir sementara. Jika mereka tidak diblokir, maka pada saat konfirmasi mungkin ada situasi di mana tiket yang kami pilih telah terjual. Dan dalam hal ini, siklus seleksi bisa menjadi jumlah pengulangan yang tidak terduga. Sementara kami memilih tempat, tetapi mereka sudah terjual! .. Sementara kami memilih yang lain, dan mereka tidak ada lagi ...

Contoh 2: membeli sesuatu di toko atau pasar. Kami pergi ke konter, memilih apel yang paling indah dari seratus yang tersedia. Mereka memilih dan merogoh saku mereka untuk mencari uang. Seperti apa jadinya jika, saat kita menghitung uang, apel yang kita pilih itulah yang akan dijual kepada pembeli yang datang lebih lambat dari kita?

Dengan demikian, pemblokiran itu sendiri adalah fenomena yang perlu dan berguna. Berkat pemblokiran, kami menjamin eksekusi tindakan dalam satu tahap. Dan paling sering, bukan implementasi perangkat lunak yang paling sukses yang mengarah ke hal negatif, ketika, misalnya:

• jumlah objek yang berlebihan (tiket, apel) diblokir;
• waktu pemblokiran diperpanjang secara tidak wajar.

INTERLOCK BERLEBIHAN DALAM KONFIGURASI KHUSUS 1C

Pada proyek besar, sebagai aturan, kami menggunakan 1C:Enterprise. Oleh karena itu, kami akan mencoba menjelaskan rekomendasi praktis untuk menyelesaikan masalah pemblokiran menggunakan contoh bundel 1C:Enterprise + MS-SQL.

Generasi ke-8 dari 1C:Enterprise menyediakan paralelisme penggunaan yang sangat, sangat baik. Bersamaan dengan satu konfigurasi (yaitu, pada satu basis), dengan server normal dan saluran komunikasi, sejumlah besar pengguna dapat bekerja. Misalnya, ratusan pemilik toko memproses pengeluaran atau penerimaan barang, ekonom secara bersamaan menghitung biaya upah untuk berbagai departemen, akuntan menghitung dan menghitung gaji, dll.

Tetapi ada alasan mengapa ada pendapat yang bertentangan - mitos bahwa dengan penggunaan simultan yang intensif, bekerja dengan solusi berdasarkan 1C: Perusahaan tidak nyaman atau tidak mungkin. Lagi pula, segera setelah ratusan pengguna mulai menggunakan solusi standar untuk 1C:Perusahaan pada skala industri, semakin sering sebuah jendela muncul di layar dengan tulisan bangga: “Kesalahan saat memanggil metode konteks (Rekam): Kunci konflik saat menjalankan transaksi: ..." dan selanjutnya tergantung pada jenis server SQL yang digunakan, seperti "Penyedia DB Microsoft OLE untuk SQL Server: Batas waktu permintaan kunci terlampaui. ...".

Hampir semua solusi standar dalam implementasi "out of the box" yang diusulkan dikonfigurasikan untuk manajemen kunci otomatis. "Otomatis" di sini bisa diartikan sebagai "paranoid". Untuk berjaga-jaga, saat melakukan dokumen apa pun, kami memblokir semua yang entah bagaimana dapat terhubung dengannya. Jadi ternyata ketika satu pengguna menghabiskan sesuatu (dan terkadang hanya menulis), sisanya hanya bisa menunggu.

Saya akan mengungkapkan pendapat saya mengapa 1C memutuskan untuk tidak menyesuaikan solusi standarnya untuk penggunaan paralelisme yang tinggi. Biaya tenaga kerja untuk penyempurnaan tersebut tidak tinggi - beberapa "orang-bulan", yang tidak signifikan dalam skala 1C. Saya pikir alasannya berbeda.

Pertama, penyempurnaan seperti itu secara signifikan mempersulit pemroses untuk memposting semua dokumen. Ini berarti bahwa bagi konsumen yang menggunakan 1C untuk tugas-tugas kecil, tanpa keuntungan apa pun hanya akan ada kekurangannya - kerumitan menyelesaikan konfigurasi tipikal akan menjadi lebih rumit. Pada saat yang sama, statistik menunjukkan kategori pelanggan mana yang merupakan pengumpan utama untuk 1C ...

Alasan kedua terkubur dalam pengaturan dasar khas server SQL, misalnya, MS-SQL, yang masih lebih sering digunakan daripada yang lain. Kebetulan prioritas dalam pengaturan diberikan untuk menghemat RAM server, dan bukan untuk mengurangi pemblokiran. Ini mengarah pada fakta bahwa, jika perlu untuk mengunci beberapa baris, server SQL mengambil keputusan "ekonomis" untuk memori dan prosesor - untuk mengunci seluruh tabel sekaligus!..

Kekurangan dari solusi standar atau spesifikasi dari pengaturan server database yang digunakan sering diidentifikasi dengan masalah yang disebabkan oleh pemblokiran. Akibatnya, kekurangan teknis menyebabkan masalah organisasi yang sangat signifikan. Lagi pula, jika seorang karyawan diberi alasan untuk mengalihkan perhatiannya dari pekerjaannya atau dibenarkan mengapa pekerjaan itu tidak dapat dilakukan, sebagian kecil akan bekerja secara efektif. Nah, pesan tentang pemblokiran transaksi atau program "memperlambat" adalah pembenaran yang ideal mengapa tidak ada yang bisa dilakukan.

REKOMENDASI ​​PENGHAPUSAN BLOKIR BERLEBIHAN UNTUK 1C:ENTERPRISE

Apa yang harus dilakukan jika solusi masalah pemblokiran berlebihan sangat penting?

Pada tahap akhir implementasi semua kompleks besar, perlu dilakukan penyempurnaan yang baik untuk menghilangkan kunci transaksi yang tidak perlu. Sangat penting untuk menyelesaikan masalah yang mungkin timbul dari kondisi pemblokiran yang kurang berkembang atau metodologi implementasi.

Karena Operasi ini sangat penting, harus dilakukan terus-menerus. Oleh karena itu, untuk menyederhanakan implementasi penyempurnaan tersebut, kami telah mengembangkan sejumlah rekomendasi dasar yang coba kami patuhi. Rekomendasi diterima dan diuji berdasarkan pengalaman sejumlah besar implementasi skala besar.

1. Jika DBMS atau sistem pengembangan Anda (misalnya, 1C:Enterprise) menggunakan penguncian data otomatis secara default, nonaktifkan manajemen kunci otomatis. Siapkan aturan pemblokiran sendiri, jelaskan kriteria pemblokiran untuk seluruh tabel atau baris individual.
2. Saat mengembangkan program, jika memungkinkan, lihat tabel dalam urutan yang sama.
3. Cobalah untuk tidak menulis ke tabel yang sama beberapa kali dalam transaksi yang sama. Jika ini sulit, maka setidaknya minimalkan jumlah waktu antara operasi tulis pertama dan terakhir.
4. Analisis kemungkinan menonaktifkan eskalasi kunci di tingkat server SQL.
5. Beri tahu pengguna dengan jelas tentang alasan ketidakmungkinan melakukan tindakan apa pun jika itu karena pemblokiran. Berikan rekomendasi yang dapat diakses dan dimengerti tentang apa yang harus dilakukan selanjutnya.

Jika Anda melihat lebih dekat pada rekomendasi, menjadi jelas bahwa pengembangan seperti itu tidak hanya cocok untuk 1C:Enterprise, tetapi untuk sistem apa pun. Tidak masalah bahasa apa yang mereka gunakan dan server basis data apa yang mereka gunakan. Sebagian besar rekomendasi bersifat universal, dan oleh karena itu sama-sama valid saat menggunakan 1C: Enterprise, dan untuk program "yang ditulis sendiri" atau sistem ERP "kotak" lainnya.

P.S. Tahukah Anda bahwa kami menawarkan bantuan profesional untuk memperbarui 1C dengan harga terbaik?

Cari Tag:

• Kunci transaksi
• Menghilangkan penyumbatan
• Memblokir 1C
• pemblokiran
• Kunci Konflik
• Kunci konflik saat menjalankan transaksi

Halo semua!

Suatu hari di tempat kerja, saya mengalami masalah dengan kunci, yaitu, pesan "Konflik kunci selama eksekusi transaksi. Waktu tunggu maksimum untuk pemberian kunci telah terlampaui" mulai muncul.

Jelas, tidak ada masalah kebuntuan di sini, hanya saja beberapa sesi mengunci dan "lupa" untuk menghapusnya. Pada saat yang sama, masalah terancam dengan konsekuensi serius - dokumen Penjualan barang dan jasa tidak dilakukan. Sekitar 100 orang bekerja di database pada satu waktu, dan tidak mungkin untuk melakukan operasi yang biasa dan sering!

Ada dua solusi - me-reboot server atau mencari sesi yang gagal. Solusi pertama sederhana dan cepat, tetapi, seperti yang sudah ditulis seseorang di sini, Anda dapat mem-boot ulang server hingga Anda dipecat. Memutuskan untuk pergi dengan cara kedua.

Hari pertama - masalah muncul di sore hari, awalnya sepertinya masalahnya ada di remote user yang stuck di Configurator. Sepertinya eksekusi baru saja berhenti di satu titik, dan kuncinya, tentu saja, tidak dilepaskan. Setelah beberapa jam, kami berhasil melepaskan konfigurator, tetapi masalahnya tidak hilang. Sangat tidak diinginkan untuk membunuh konfigurator secara paksa, mungkin mereka bekerja di dalamnya. Setelah itu, Google mengambil alih. Saya menemukan artikel di situs ini, yang mengatakan cara menemukan kunci di MS SQL DBMS, diperiksa, tidak ada kunci di level DBMS. Aneh. Selanjutnya ada upaya untuk menyesuaikan mereka. majalah. Siapkan, apa selanjutnya? Dalam 15 menit beberapa pertunjukan log! Bagaimana cara membacanya, apa yang harus dicari? Tidak dikenal.

Saya menemukan artikel tentang cara melihat apa yang diblokir melalui SQL Trace. Bahkan jika saya menemukannya, lalu apa? Saya butuh sesi!

Mendekati pukul 16:00, ketika saya menyadari bahwa saya tidak dapat menariknya lebih jauh, saya melakukan reboot. Dengan harapan ini tidak akan terjadi lagi (dan ini adalah kasus pertama dalam enam bulan kerja), saya menarik napas lega, semuanya berhasil. Tapi sia-sia ... Hari kedua - situasi yang sama. Saya menggali selama satu setengah jam, upaya lagi dimengerti untuk google dan sebagainya. Tidak ada hasil. Menyalakan ulang. Di penghujung hari itu terjadi lagi. Yah, saya pikir itu bagus, saya akan dengan tenang pulang dan duduk, menggali lebih dalam. Aku pulang, semuanya baik-baik saja. Dengan sedih.

Pada hari ketiga, saya menonton webinar dan berbicara tentang cara yang menarik dan efektif untuk menemukan masalah. Teringat, tapi masalah tidak muncul lagi. Seminggu telah berlalu dan ini dia - lagi memblokir! Aku menggosok tanganku dan mulai bertindak.

Yang pertama adalah mengatur log. Ya, saya tidak dapat melakukannya tanpanya, tetapi sekarang saya dapat membacanya. Kami menetapkan dua acara: yang pertama adalah TLOCK, yang kedua adalah TTIMEOUT. Yang pertama menampilkan semua peristiwa pemblokiran, yang kedua menunjukkan pemblokiran yang tidak dapat dilakukan dalam waktu yang ditentukan. Bahkan, kemungkinan besar, hanya TTIMEOUT yang cukup.

Kami menyalin file log teknis ke tempat yang ditentukan, terbang ke program, memanggil kunci, menerima pesan dan menghapus atau mengganti nama file log teknis. Kami tidak membutuhkan banyak informasi tentang pemblokiran lainnya!

Buka folder rphost_PID, cari file teks dan cari kata TTIMEOUT. Kami melihat garis:

53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID= 2242,Usr=*******,TungguKoneksi=8239

Omong-omong, mungkin ada beberapa folder rphost_PID, semuanya tergantung pada berapa banyak proses pekerja yang berjalan di server.

Dan kemudian semuanya sederhana: lihat di akhir baris - WaitConnections = 8239, ini nomor CONNECTION kami. Kami pergi ke konsol server, pergi ke Koneksi, temukan nomor ini dan lihat nomor sesi. Dalam kasus saya, ada dua sesi per pengguna - yang gagal dan yang lainnya. Menghancurkan sesi yang ditunjukkan oleh log teknis. Dan tentang keajaiban! Semuanya bekerja, tidak ada batasan untuk sukacita! Tapi, ternyata kemudian, sesi itu tidak digantung :), mereka bekerja di dalamnya. Oleh karena itu, untuk kedepannya, disarankan untuk menghubungi pengguna dan memperingatkan.

Menurut pendapat saya, solusi yang cukup khas untuk masalah yang cukup khas. Tidak diketahui mengapa saya tidak menemukannya, mungkin karena saya harus mencarinya di alarm, dan ketika pengguna tidak menekan, maka tidak mungkin untuk melakukan tes - tidak ada kesalahan.

Tidak jarang, saat bekerja di 1C, terjadi error “Lock conflict saat eksekusi transaksi: Waktu tunggu maksimum pemberian kunci telah terlampaui”. Esensinya terletak pada kenyataan bahwa beberapa sesi mencoba melakukan tindakan serupa secara bersamaan, memengaruhi sumber daya yang sama. Hari ini kita akan mencari cara untuk memperbaiki kesalahan ini.

Sejumlah besar operasi

Pertama-tama, ketika mencari alasan, Anda harus mengklarifikasi berapa banyak pengguna yang bekerja secara bersamaan di basis info tempat kesalahan semacam itu dihasilkan. Seperti yang kita ketahui, jumlah maksimum mereka bisa sangat besar. Ini seribu lima ribu.

Mekanisme penguncian dan transaksi dijelaskan dalam panduan pengembang. Mereka digunakan ketika beberapa sesi mengakses data yang sama secara bersamaan. Adalah logis bahwa data yang sama tidak dapat diubah oleh pengguna yang berbeda pada saat yang sama.

Anda juga harus memeriksa apakah ada pengguna yang mulai memproses perubahan data massal. Bisa seperti , tutup bulan dan sejenisnya. Dalam hal ini, setelah pemrosesan berakhir, kesalahan akan hilang dengan sendirinya.

Tugas terjadwal

Tidak jarang penyebab kesalahan terletak pada, yang memproses data dalam jumlah besar. Disarankan untuk melakukan hal-hal seperti itu di malam hari. Jadwalkan pelaksanaan tugas terjadwal tersebut selama jam non-kerja.

Dengan demikian, kedua pengguna akan bekerja dalam sistem yang stabil, dan tugas terjadwal itu sendiri akan berhasil diselesaikan, karena kemungkinan konflik dengan sesi pengguna akan berkurang.

"Sesi Terjebak"

Masalah "sesi gantung" pengguna sudah tidak asing lagi bagi hampir semua orang yang pernah mengalami layanan 1C. Pengguna bisa saja sudah lama keluar dari program, atau menutup dokumen, tetapi sesinya masih tetap berada di sistem. Masalahnya paling sering tunggal dan cukup untuk mengakhiri sesi seperti itu melalui konsol administrator. Masalah yang sama dapat terjadi dengan pekerjaan latar belakang.

Menurut banyak komentar di Internet, situasi seperti itu lebih sering terjadi saat menggunakan kunci keamanan jaringan. Jika situasi dengan "sesi gantung" diulang secara sistematis, ini adalah alasan untuk pemeriksaan dan pemeliharaan sistem dan server secara menyeluruh (jika basisnya adalah klien-server).

Kesalahan saat menulis konfigurasi

Semua konfigurasi tipikal dikembangkan oleh spesialis dan ahli yang berkualifikasi. Setiap sistem diuji dan dioptimalkan dengan cermat untuk pekerjaan yang lebih cepat dan benar di dalamnya.

Dalam hal ini, penyebab kesalahan mungkin terletak pada kode suboptimal yang ditulis oleh pengembang pihak ketiga. Ini mungkin permintaan "berat" yang akan memblokir data untuk jangka waktu yang lama. Juga tidak jarang membangun algoritma dengan kinerja rendah dan pelanggaran logika.

Sangat mungkin bahwa konflik kunci muncul justru karena kesalahan pengembang jika muncul setelah memperbarui program. Untuk memeriksa, Anda cukup "memutar kembali" peningkatan, atau memfaktorkan ulang kode.