Nisam mogao zapisati promjene za prijenos u distribuiranu bazu podataka, kontaktirao sam 1c podršku i ponudio sljedeće. Odlučio sam jednostavno ponovo pokrenuti aplikacijski server i server sa SQL-om. Općenito, možete označiti okvir „Blokiranje zakazano
uključeni zadaci"
Pomoglo je i bez ponovnog pokretanja.

Planirane operacije na nivou DBMS za MS SQL Server

Upute za izvođenje rutinskih operacija na nivou DBMS.

Informacije su primjenjive na klijent-server verziju 1C:Enterprise 8 kada se koristi MS SQL Server DBMS.

Opće informacije

Jedan od najčešćih uzroka neoptimalnog rada sistema je neispravno ili neblagovremeno izvršavanje rutinskih operacija na nivou DBMS-a. Posebno je važno slijediti ove rutinske procedure u velikoj mjeri informacioni sistemi ah, koji rade pod značajnim opterećenjem i istovremeno opslužuju veliki broj korisnika. Specifičnost ovakvih sistema je da uobičajene radnje koje DBMS izvršava automatski (na osnovu podešavanja) nisu dovoljne za efikasan rad.

Ako pokrenuti sistem pokazuje bilo kakve simptome problema s performansama, trebali biste provjeriti da li je sistem ispravno konfiguriran i da redovno izvodi svo preporučeno rutinsko održavanje na razini DBMS-a.

Izvršenje rutinskih procedura treba biti automatizirano. Za automatizaciju ovih operacija preporučuje se korištenje ugrađenih alata MS SQL Servera: Plan održavanja. Postoje i drugi načini za automatizaciju ovih procedura. U ovom članku, za svaku zakazanu proceduru, dat je primjer njene konfiguracije pomoću Plana održavanja za MS SQL Server 2005.

Preporučuje se redovno praćenje blagovremenosti i ispravnosti provođenja ovih rutinskih procedura.

Ažuriranje statistike

MS SQL Server gradi plan upita na osnovu statističkih informacija o distribuciji vrijednosti u indeksima i tabelama. Statistički podaci se prikupljaju na osnovu dijela (uzorka) podataka i automatski se ažuriraju kada se ti podaci promijene. Ponekad to nije dovoljno da MS SQL Server dosljedno izgradi najoptimalniji plan za izvršavanje svih upita.

U ovom slučaju može doći do problema s performansama upita. Istovremeno, karakteristični znaci neoptimalnog rada (neoptimalne operacije) se uočavaju u planovima upita.

Da bi se garantovao maksimum korektan rad MS SQL Server optimizator preporučuje da redovno ažurirate statistiku MS SQL baze podataka.

Da biste ažurirali statistiku za sve tablice baze podataka, morate izvršiti sljedeći SQL upit:

exec sp_msforeachtable N"AŽURIRAJ STATISTIKU ? SA FULLSCAN"

Ažuriranje statistike ne dovodi do zaključavanja tabela, i neće ometati rad drugih korisnika. Statistika se može ažurirati onoliko često koliko je potrebno. Treba uzeti u obzir da će se opterećenje na DBMS serveru tokom ažuriranja statistike povećati, što može negativno uticati ukupne performanse sistemima.

Optimalna učestalost ažuriranja statistike zavisi od veličine i prirode opterećenja na sistemu i određuje se eksperimentalno. Preporučuje se ažuriranje statistike najmanje jednom dnevno.

Gornji upit ažurira statistiku za sve tabele u bazi podataka. U stvarnom sistemu, različite tabele zahtevaju različite stope ažuriranja statistike. Analizom planova upita možete odrediti koje tabele trebaju najčešće ažuriranje statistike i postaviti dvije (ili više) različite rutinske procedure: za često ažurirane tabele i za sve ostale tabele. Ovaj pristup će značajno smanjiti vrijeme ažuriranja statistike i uticaj procesa ažuriranja statistike na rad sistema u cjelini.

Konfiguriranje automatskog ažuriranja statistike (MS SQL 2005)

Pokrenite MS SQL Server Management Studio i povežite se na DBMS server. Otvorite direktorij za upravljanje i kreirajte novi plan usluga:

Kreirajte podplan (Dodaj podplan) i nazovite ga "Ažuriranje statistike". Dodajte mu zadatak ažuriranja statistike sa trake zadataka:

Postavite raspored ažuriranja statistike. Preporučuje se ažuriranje statistike barem jednom dnevno. Ako je potrebno, učestalost ažuriranja statistike može se povećati.

Postavite postavke zadatka. Da biste to učinili, dvaput kliknite na zadatak u donjem desnom kutu prozora. U obrascu koji se pojavi navedite naziv baze podataka (ili nekoliko baza podataka) za koje će se ažurirati statistika. Osim toga, možete odrediti za koje tablice želite ažurirati statistiku (ako ne znate tačno koje tablice trebate navesti, tada postavite vrijednost na Sve).

Ažuriranje statistike mora biti obavljeno sa omogućenom opcijom Full Scan.

Sačuvajte kreirani plan. Kada dođe vrijeme navedeno u rasporedu, statistika će se automatski ažurirati.

Brisanje proceduralne keš memorije

MS SQL Server optimizator kešira planove upita za ponovno izvršenje. Ovo se radi kako bi se uštedilo vrijeme utrošeno na sastavljanje upita ako je isti upit već izvršen i njegov plan je poznat.

Moguće je da će MS SQL Server, oslanjajući se na zastarjele statističke informacije, izgraditi neoptimalan plan upita. Ovaj plan će biti pohranjen u proceduralnoj keš memoriji i korišten kada se isti upit ponovo pozove. Ako ste ažurirali statistiku, ali niste obrisali proceduralni keš, onda SQL Server može izabrati stari (neoptimalan) plan upita iz keša umjesto da pravi novi (bolji) plan.

Za brisanje proceduralne predmemorije MS SQL Servera, morate izvršiti sljedeći SQL upit:

Ovaj upit treba pokrenuti odmah nakon ažuriranja statistike. Shodno tome, učestalost njegovog izvršavanja treba da odgovara učestalosti ažuriranja statistike.

Konfiguriranje proceduralnog brisanja predmemorije (MS SQL 2005)

Budući da proceduralni keš treba obrisati svaki put kada se statistika ažurira, preporučuje se dodavanje ove operacije u već kreirani podplan "Ažuriraj statistiku". Da biste to učinili, otvorite podplan i dodajte zadatak Izvrši T-SQL naredbu njegovoj šemi. Zatim biste trebali povezati zadatak ažuriranja statistike sa strelicom na novi zadatak.

U tekstu kreiranog Zadatka Izvrši T-SQL naredbe treba navesti upit "DBCC FREEPROCCACHE":

Defragmentacija indeksa

Kada intenzivno radite sa tabelama baze podataka, dolazi do efekta fragmentacije indeksa, što može dovesti do smanjenja efikasnosti upita.

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

Defragmentacija indeksa ne blokira tabele i neće ometati rad drugih korisnika, ali stvara dodatno opterećenje na SQL Serveru. Optimalna učestalost izvođenja ove rutinske procedure treba odabrati u skladu sa opterećenjem sistema i efektom defragmentacije. Preporučujemo da defragmentirate svoje indekse barem jednom sedmično.

Moguće je defragmentirati jednu ili više tabela, a ne sve tabele u bazi podataka.

Konfiguriranje defragmentacije indeksa (MS SQL 2005)

U prethodno kreiranom planu održavanja, kreirajte novi podplan pod nazivom "Reindex". Dodajte mu zadatak Rebuild Index:

Postavite raspored izvršavanja za zadatak defragmentacije indeksa. Preporučljivo je pokrenuti zadatak najmanje jednom tjedno, a ako su podaci u bazi vrlo promjenjivi, čak i češće - do jednom dnevno.

Ponovno indeksiranje tablica baze podataka

Ponovno indeksiranje tablica uključuje potpunu rekonstrukciju indeksa tablica baze podataka, što dovodi do značajne optimizacije njihovog rada. Preporučuje se redovno reindeksiranje tabela baze podataka. Za ponovno indeksiranje svih tablica baze podataka, morate izvršiti sljedeći SQL upit:

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

Ponovno indeksiranje tabela ih blokira za vrijeme njihovog rada, što može značajno utjecati na rad korisnika. S tim u vezi, preporučuje se ponovno indeksiranje da se izvrši za vrijeme minimalnog opterećenja sistema.

Nakon ponovnog indeksiranja, nema potrebe za defragmentiranjem indeksa.

Postavljanje ponovnog indeksiranja tablice (MS SQL 2005)

U prethodno kreiranom planu održavanja, kreirajte novi podplan pod nazivom "Defragmentacija indeksa". Dodajte mu zadatak Rebuild Index:

Postavite raspored izvršavanja za zadatak ponovnog indeksiranja tablice. Preporučuje se pokretanje zadatka za vrijeme minimalnog opterećenja sistema, barem jednom sedmično.

Prilagodite zadatak navođenjem baze podataka (ili više baza podataka) i odabirom potrebnih tablica. Ako ne znate tačno koje tabele da navedete, postavite vrednost na Sve.

Šta su brave u 1C, zašto su potrebne i kako izbjeći probleme pri radu s njima

Sigurno su mnogi od vas, kada su koristili informacione sisteme 1C Enterprise (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), naišli na takav fenomen kao što je blokiranje. Štoviše, u pravilu svi različito nazivaju ovu pojavu: "1C zaključavanja", "1C sukob zaključavanja", "1C greške zaključavanja", "1C zaključavanja transakcija" i druga imena. Hajde da ukratko shvatimo šta su brave (ne zastoje), zašto su potrebne i kako izbjeći probleme pri radu s njima.

Same brave (uključujući u 1C i drugim sistemima) koristan alat, koji pruža mogućnost uzastopnog rada sa zajedničkim resursima. Na primjer, koncept “zajedničkih resursa” nas okružuje u životu, na primjer, dok vozite auto, niko drugi ga ne može voziti. Dakle, automobil je zajednički resurs. A drugi vozač čeka da stignete, na primjer vaša žena/muž. Oboje se takmičite za zajednički resurs - automobil. Ko će voziti auto ovog trenutka Vi definišete na konceptualnom nivou, ali kako da budemo automatizovani sistemi??? Da bi to učinili, smislili su alat blokiranje, koji organiziraju proces pristupanja zajedničkom resursu i definiraju red čekanja. Po pravilu, u životu, kao iu informacionim sistemima (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), postoji mnogo zajedničkih resursa, a samim tim i mnogo brava. Sada druga važna stvar - koliko dugo će vaša žena / muž čekati na puštanje vašeg automobila, logično je pretpostaviti da to neće trajati zauvijek. Stoga je za zaključavanja postavljeno ograničenje vremenskog ograničenja - inače, vrijeme čekanja. Vremensko ograničenje je maksimalno vrijeme koje rivalski učesnik (vaša žena/muž) može čekati da se zajednički resurs oslobodi. Onda ili nastavlja da čeka isto vreme, ili ide peške. U informacionim sistemima 1C, istek vremenskog ograničenja završava se porukom "1C lock konflikt", "1C lock greške", "1C transakcija zaključavanja", "Timeout on lock".

Važan detalj koji također treba imati na umu je da su zaključavanja (posebno u 1C) eksplicitna (koju postavlja korisnik) i implicitna (koja postavlja SQL platforma). U članku govorimo o eksplicitnim zaključavanjima, dakle uvijek se koriste u transakciji, pa se ispostavilo da su "1C Lock" i "1C Transaction Lock" sinonimi.

Odlučili smo da kada se istekne vremensko ograničenje, korisniku se prikaže poruka o grešci, a sam proces čekanja za njega izgleda kao ljepljivi ekran informacionog sistema 1C. Sljedeći indikatori utječu na vjerovatnoću isteka poruke (1C greške za korisnika):

• Mnogo 1C zaključavanja u transakciji;
• Trajanje transakcije.

Da bi se minimizirale poruke povezane s greškama zaključavanja, potrebno je ili smanjiti skup zaključavanja (optimizirati selektivnost) ili smanjiti trajanje transakcija.
Sada ćemo odlučiti kako se na ove pokazatelje može utjecati u stvarnom informacionom sistemu 1C.

Da biste smanjili mnogo blokiranja:

U 1C:Enterprise 7.7:

Informacioni sistem 1C 7.7. za brave se koriste stolne brave koje paraliziraju rad korisnika. U pravilu više od 50 ljudi u jednoj bazi ne može raditi bez grešaka, a problemi se mogu pojaviti i u bazama podataka od 20 korisnika.
Rješenje:

• Fleksibilne brave 1C kompanije "Softpoint". Uz njihovu pomoć, ne samo da optimizirate mnogo zaključavanja (zamjenjujući zaključavanja tablice prilagođenim), već i ubrzavate odabire, pretraživanja i izvještaje.

U 1C:Enterprise 8.x:
Informacioni sistem 1C 8.1., 1C 8.2., 1C 8.3. automatski koristi zaključavanja redundantnog tipa (REPEATABLREAD, SERIALIZABLE). To dovodi do pogoršanja korisničkog iskustva sa 100.
Rješenje:

• Upravljane brave 1C je ugrađeni alat 1C platforme za selektivnije postavke zaključavanja. Da bi ga koristio, programer mora napisati posebne operatore na pravim mjestima u kodu kako bi blokirao potrebne ( po njegovom mišljenju!) unose u tabele informacionog sistema;
• Fleksibilne brave 1C - Softpoint tehnologija za zamjenu standardnih brava bravama po mjeri.

Da biste smanjili trajanje transakcija:

Za bilo koji informacioni sistem 1C (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3), kao i za druge informacione sisteme, koriste se slični pristupi:

Provjerite i ispravite postavku rutinsko održavanje baze podataka (održavanje datoteka, indeksa, statistike, privremenih tabličnih baza podataka, Windows i SQLServer podešavanja);

Analiza i optimizacija teških 1C i SQL upita (podešavanje indeksa, prepisivanje upita);

Provjera redundantnosti transakcije. U mnogim slučajevima, nerazumno je uključiti operacije u transakciju bez shvaćanja kako će to uticati na trajanje, a time i na performanse.

1. Ako se želite samostalno baviti tehničkim problemima performansi 1C (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) i drugih informacionih sistema , a zatim za vas jedinstvena lista tehničkih članaka u našem Almanahu (Brave i zastoji, veliko opterećenje CPU-a i diska, održavanje baze podataka i podešavanje indeksa samo su mali dio tehničkog materijala koji ćete tamo pronaći).
2. Ako želite da razgovarate o problemima performansi sa našim stručnjakom ili naručite PerfExpert rešenje za praćenje performansionda ostavite zahtjev i mi ćemo Vas kontaktirati u najkraćem mogućem roku.

Zdravo svima!

Pre neki dan na poslu sam naišao na problem sa zaključavanjem, naime počela je da se pojavljuje poruka "Konflikt zaključavanja prilikom izvršavanja transakcije. Prekoračen je maksimalni timeout za odobravanje zaključavanja".

Očigledno, ovdje nema problema sa zastojem, samo je neka sesija stavila zaključavanje i "zaboravila" ga ukloniti. Istovremeno, problem je prijetio ozbiljnim posljedicama - dokument Prodaja robe i usluga nije izvršen. U bazi podataka istovremeno radi oko 100 ljudi i nemoguće je izvesti tipičnu i čestu operaciju!

Postojala su dva rješenja - ponovno pokretanje servera ili traženje neuspjele sesije. Prvo rešenje je jednostavno i brzo, ali, kao što je neko ovde već napisao, možete ponovo pokrenuti server dok ne dobijete otkaz. Odlučio sam krenuti drugim putem.

Prvi dan - problem se pojavio popodne, isprva se činilo da je problem u udaljenom korisniku koji je zaglavio u konfiguratoru. Izgledalo je kao da je pogubljenje u jednom trenutku stalo, a brava, naravno, nije otpuštena. Nakon par sati uspjeli smo pustiti konfigurator, ali problem nije nestao. Bilo je krajnje nepoželjno nasilno ubiti konfigurator, možda su oni radili u njemu. Nakon toga, Google je preuzeo. Našao sam članak na ovoj stranici, koji kaže kako pronaći brave u MS SQL DBMS-u, provjerio, nije bilo brava na nivou DBMS-a. Čudno. Dalje je bilo pokušaja da se oni prilagode. časopis. Postavite, šta je sljedeće? Za 15 minuta par svirki balvana! Kako ih čitati, šta tražiti? Nepoznato.

Našao sam članak o tome kako vidjeti što je blokirano kroz SQL Trace. Čak i ako ga nađem, šta onda? Treba mi sesija!

Bliže 16:00, kada sam shvatio da ne mogu dalje, napravio sam restart. U nadi da se ovo više neće ponoviti (a ovo je bio prvi slučaj u šest mjeseci rada), odahnuo sam, sve je uspjelo. Ali uzalud... Drugi dan - ista situacija. Kopao sam sat i po, opet neshvatljivi pokušaji guglanja i tako dalje. Nema rezultata. Ponovo pokreni. Na kraju dana to se ponovilo. Pa, mislim da je super, mirno ću doći kući i sjediti, kopati dublje. Dođem kući, sve je u redu. Nažalost.

Trećeg dana sam gledao webinar, pričao o zanimljivom i efikasan metod tražiti problem. Zapamtio, ali problem više nije nastao. Prošla je sedmica i evo - opet blokada! Trljam ruke i počinjem djelovati.

Prvi je postavljanje dnevnika. Da, ne mogu bez njega, ali sada mogu da ga čitam. Postavljamo dva događaja: prvi je TLOCK, drugi je TTIMEOUT. Prvi prikazuje sve događaje blokiranja, drugi prikazuje blokade koje nije bilo moguće uspostaviti u zadanom vremenu. U stvari, najvjerovatnije je samo TTIMEOUT dovoljan.

Kopiramo datoteku tehničkog dnevnika na dodijeljeno mjesto, letimo do programa, pozivamo bravu, primamo poruku i uklanjamo ili preimenujemo datoteku tehničkog dnevnika. Ne trebaju nam tone informacija o drugim blokiranjima!

Idite u folder rphost_PID, pronađite tekstualne datoteke i potražite riječ TTIMEOUT. Vidimo liniju:

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=*******,WaitConnections=8239

Usput, može postojati nekoliko foldera rphost_PID, sve ovisi o tome koliko radnih procesa se pokreće na serveru.

A onda je sve jednostavno: pogledajte na kraju reda - WaitConnections = 8239, ovo je naš CONNECTION broj. Idemo na konzolu servera, idemo na Connections, pronalazimo ovaj broj i gledamo broj sesije. U mom slučaju su bile dvije sesije po korisniku - jedna neuspješna i još neka. Srušila sesiju naznačenu tehničkim dnevnikom. I o čudu! Sve je uspjelo, radosti nema granice! Ali, kako se kasnije ispostavilo, sesija nije okačena :), oni su radili u njoj. Stoga je ubuduće preporučljivo kontaktirati korisnika i upozoriti.

Po mom mišljenju, prilično tipično rješenje za prilično tipičan problem. Ne zna se zašto nisam naišao, možda zbog činjenice da sam ga morao tražiti na alarmu, a kada korisnici nisu pritisnuli, onda nije bilo moguće provesti testove - nije bilo greške.

Kada stotine korisnika istovremeno rade s programima i podacima, problemi su svojstveni samo velikim rješenjima. Govorimo o problemima uzrokovanim zaključavanjem podataka.

Ponekad korisnici saznaju za zaključavanje iz poruka koje ukazuju na nemogućnost pisanja podataka ili obavljanja neke druge operacije. Ponekad zbog vrlo značajnog pada performansi programa (na primjer, kada vrijeme potrebno za izvođenje operacije raste desetine ili stotine puta).

Problemi uzrokovani blokiranjem nemaju opće rješenje. Stoga ćemo pokušati analizirati uzroke ovakvih problema i sistematizirati mogućnosti za njihovo rješavanje.

RAZLOZI ZA BLOKIRANJE TRANSAKCIJA

Prvo se prisjetimo šta su brave, a istovremeno ćemo shvatiti jesu li potrebne. Pogledajmo nekoliko klasičnih primjera blokiranja s kojima se susrećemo u životu.

Primjer 1: Kupovina karte za avion ili vlak. Pretpostavimo da smo svoje želje izrekli blagajniku. Blagajnica nam govori o raspoloživosti mjesta, od kojih možemo izabrati ono koje nam se najviše sviđa (naravno ako ih ima nekoliko). Dok ne izaberemo i potvrdimo da se slažemo sa predloženom opcijom, ova mjesta se ne mogu prodati nikome drugom, tj. privremeno blokiran. Ako nisu blokirane, tada bi do trenutka potvrde mogla doći do situacije da su karte koje smo odabrali već prodane. I u ovom slučaju, ciklus selekcije može biti nepredvidiv broj ponavljanja. Dok biramo mesta, ali su već prodata!.. Dok biramo druga, a njih više nema...

Primjer 2: kupujete nešto u prodavnici ili na pijaci. Otišli smo do pulta, izabrali najljepšu jabuku od stotinu dostupnih. Birali su i posegnuli za novcem u džep. Kako će izgledati ako, dok brojimo novac, jabuka koju smo odabrali bude prodata kupcu koji je došao kasnije od nas?

Dakle, blokiranje je samo po sebi neophodan i koristan fenomen. Zahvaljujući blokiranju garantujemo izvršenje radnji u jednoj fazi. I najčešće ne najuspješnija implementacija vodi u negativno softver kada, na primjer:

• blokiran je preveliki broj objekata (karte, jabuke);
• vrijeme blokiranja je neopravdano produženo.

PREVEĆE ZAKLJUČAVANJA U TIPIČNIM 1C KONFIGURACIJAMA

On velikih projekata U pravilu koristimo 1C:Enterprise. Zbog toga praktični saveti Pokušat ćemo opisati rješenja problema blokiranja na primjeru paketa 1C:Enterprise + MS-SQL.

Osma generacija 1C:Enterprise pruža vrlo, vrlo dobar paralelizam korištenja. Istovremeno sa jednom konfiguracijom (odnosno na jednoj bazi), sa normalnim serverima i komunikacijskim kanalima, može raditi velika količina korisnika. Na primjer, stotine skladištara obrađuju izdavanje ili prijem robe, ekonomisti istovremeno obračunavaju trošak plaća prema razne divizije, kalkulatori vrše obračun i obračun plata itd.

Ali postoji razlog zašto postoji suprotno mišljenje - mit da je, uz intenzivnu istovremenu upotrebu, neugodno ili nemoguće raditi s rješenjima zasnovanim na 1C: Enterprise. Uostalom, čim stotine korisnika počnu koristiti standardna rješenja za 1C:Enterprise u industrijskim razmjerima, sve češće se na ekranu pojavljuje prozor s ponosnim natpisom: „Greška pri pozivanju metode konteksta (Snimanje): Zaključaj konflikt prilikom izvršavanja transakcije: ...” i dalje u zavisnosti od tipa korišćenog SQL servera, nešto poput „Microsoft OLE DB dobavljač za SQL Server: Vremensko ograničenje zahteva za zaključavanje je prekoračeno. ...".

Gotovo sva standardna rješenja u predloženoj implementaciji "out of the box" konfigurirana su za automatsko upravljanje zaključavanjem. "Automatski" se ovdje može shvatiti kao "paranoičan". Za svaki slučaj, kada vodimo bilo koji dokument, blokiramo sve što se može nekako povezati s njim. Tako ispada da kada jedan korisnik nešto potroši (a ponekad samo napiše), ostali mogu samo čekati.

Iznijet ću svoje mišljenje zašto je 1C odlučio da svoja standardna rješenja ne prilagodi za visoku paralelnost upotrebe. Troškovi rada za takvo usavršavanje nisu visoki - nekoliko "čovjek-mjeseci", što nije značajno u smislu 1C skale. Mislim da je razlog drugačiji.

Prvo, takva dorada značajno komplikuje procesore za knjiženje svih dokumenata. To znači da će za one potrošače koji koriste 1C za male zadatke, bez ikakvog dobitka postojati samo nedostatak - složenost finalizacije tipične konfiguracije će postati složenija. Istovremeno, statistika sugerira koja kategorija kupaca je glavni hranitelj za 1C ...

Drugi razlog je zakopan u tipičnom osnovna podešavanja SQL serveri, kao što je MS-SQL, koji se i dalje koristi češće od drugih. Desilo se da se prioriteti u postavkama daju čuvanju RAM-a servera, a ne smanjenju blokiranja. To dovodi do činjenice da, ako je potrebno zaključati nekoliko redova, SQL server donosi "ekonomičnu" odluku za memoriju i procesor - da zaključa cijelu tablicu odjednom!..

Evo mana standardna rješenja ili specifičnosti podešavanja servera baze podataka koje se koriste često se mešaju sa problemima uzrokovanim zaključavanjem. Kao rezultat toga, tehnički nedostaci dovode do vrlo značajnih organizacioni problemi. Na kraju krajeva, ako se zaposleniku da razlog da se odvrati od posla ili se opravda zašto posao nije mogao da se obavi, manjina će raditi efikasno. Pa, poruka o blokiranju transakcija ili o "usporavajućem" programu je idealno opravdanje zašto se ništa nije moglo učiniti.

PREPORUKE ZA OTKLANJANJE PREKOJERNOG BLOKIRANJA ZA 1C:PREDUZEĆE

Što učiniti ako je rješenje problema prekomjernog blokiranja toliko važno?

U završnoj fazi implementacije svih velikih kompleksa, potrebno je izvršiti finu doradu kako bi se eliminisala nepotrebna blokada transakcija. Ključno je riješiti probleme koji mogu nastati zbog nedovoljno razvijenih uslova blokiranja ili metodologije implementacije.

Jer ovu operaciju izuzetno važno, mora se provoditi stalno. Stoga smo, kako bismo pojednostavili implementaciju takve dorade, razvili niz osnovnih preporuka kojih se nastojimo pridržavati. Primljene i testirane preporuke na iskustvu značajnog broja implementacija velikih razmjera.

1. Ako vaš DBMS ili razvojni sistem (na primjer, 1C:Enterprise) koristi automatski način zaključavanja podataka prema zadanim postavkama, odbacite automatska kontrola brave. Sami postavite pravila blokiranja, opišite kriterije blokiranja za cijele tablice ili pojedinačne redove.
2. Kada razvijate program, kad god je to moguće, pogledajte tabele istim redosledom.
3. Pokušajte da ne pišete u istu tabelu više puta u okviru iste transakcije. Ako je to teško, onda barem minimalizirajte vrijeme između prve i posljednje operacije pisanja.
4. Analizirajte mogućnost onemogućavanja eskalacije zaključavanja na razini SQL servera.
5. Jasno informirajte korisnike o razlozima nemogućnosti izvođenja bilo kakvih radnji ukoliko su one uzrokovane blokiranjem. Dajte pristupačne i razumljive preporuke šta dalje.

Ako pažljivo pogledate preporuke, postaje jasno da takav razvoj je prikladan ne samo za 1C: Enterprise, već i za sve sisteme. Nije bitno na kom su jeziku napisani i sa kojim serverom baze podataka rade. Većina preporuka je univerzalne prirode, te su stoga podjednako valjane i za korištenje 1C: Enterprise, i za "samopisne" programe ili druge "upakirane" ERP sisteme.

P.S. Jeste li znali da nudimo stručnu pomoć pri ažuriranju 1C softvera najbolja cijena?

Search Tags:

• Transakcione brave
• Uklanjanje blokada
• Blokiranje 1C
• blokiranje
• Lock Conflict
• Konflikt zaključavanja prilikom izvršavanja transakcije

Na višekorisničkim sistemima važnu ulogu igra pravilnu organizaciju konstrukcije i postavljanje brava. U suprotnom, korisnici će često naići na greške uzrokovane konkurencijom za određene sistemske resurse. Ali postoji problem sukoba zaključavanja s kojim su mnogi korisnici upoznati. Zašto dolazi do sukoba zaključavanja 1C i kako ga popraviti?

Sukob zaključavanja u 1C 8.3 i njegovo značenje

Za većinu korisnika, poruka o sukobu 1C zaključavanja znači samo grešku koja ih sprečava da rade svoj posao. Žele se što prije riješiti ovog problema i opsjedati IT odjel pritužbama da "1C ne radi".

Ali za administratori sistema i programerima, takva poruka ukazuje na mogući problem u strukturi konfiguracije. Prije nego pokušate zadovoljiti korisnike i ukloniti blokove, morate analizirati situaciju i razumjeti uzrok poruke o grešci.

Uzroci grešaka u blokiranju u 1C

Demonstrativni testovi opterećenja pokazuju da 1C server može izdržati paralelni rad više od pet hiljada korisnika. Ali idealni uslovi za ovakve eksperimente nedostižni su u svakodnevnim uslovima velikih i srednjih kompanija. Da bi se postigle slične performanse i performanse bez grešaka, konfiguracija mora biti idealno dizajnirana i prilagođena specifičnim poslovnim procesima preduzeća.

Ako ne uzmete idealne opcije, tada dolazi do sukoba zaključavanja 1C iz sljedećih razloga:

Istovremeni rad korisnika sa velikom količinom podataka. Ovaj osnovni uzrok je diktiran unutrašnjim mehanizmima 1C. Oni podrazumijevaju zabranu promjene podataka uključenih u transakciju pokrenutu u ime drugog korisnika;

Greške i nedostaci u konfiguraciji. Struktura standardnih rješenja kompanije "1C" uzima u obzir preporuke za maksimiziranje produktivnosti. Ali programeri trećih strana ne pridržavaju se uvijek visokih standarda i često možete pronaći sljedeće nedostatke u njihovom kodu:

• Suboptimalni zahtjevi;
• Zahtjev za stanje na početku akcija;
• Nerazumijevanje svrhe konfiguracijskih objekata i njihove nepravilne upotrebe;
• Redundantnost svojstvena sistemu ili dodatno razvijene brave.

Kako popraviti sukob zaključavanja u 1C 8.3

Sistemska poruka "konflikt zaključavanja tokom izvršavanja transakcije 1C 8.3" ne karakteriše konfiguraciju kao pogrešno dizajniranu. Ali ako se takvi signali zanemare, onda postoji mogućnost da u najbitnijem trenutku, na primjer, pri podnošenju kvartalnih ili godišnjih izvještaja, dođe do velikih problema. U najboljem slučaju, sistem koji usporava i nezadovoljni korisnici. U najgorem slučaju, netačni izlazni podaci, što može dovesti do kazni od strane regulatornih tijela.

Rješenje problema sukoba brava u 1C 8.3 može biti prijenos konfiguracije u upravljani (ručni) način upravljanja bravama. Implementiran u verziji 8.1, mehanizam u rukama kompetentnih stručnjaka rješava problem sukoba zaključavanja tokom transakcija u 1C.

Ali treba imati na umu da će ova akcija smanjiti nivo zaštite podataka od promjena u procesu čitanja od strane drugih korisnika. Stoga, ako niste spremni samostalno kontrolirati sve brave u sistemu, nemojte žuriti s promjenom postavki konfiguracije.

Brzo rješavanje sukoba 1C zaključavanja

U radu administratora ili programera može doći do situacije u kojoj nema vremena za provjeru greške i pronalaženje osnovnih uzroka problema. Na primjer, morate podnijeti izvještaj ili dostaviti podatke do određenog vremena, a greške blokiranja 1C to sprečavaju.

Postoje dva načina za brzo rješavanje problema:

• Pronađite i završite sesiju koja je zaključala potrebne podatke. IN mala preduzeća, gdje broj korisnika 1C ne prelazi nekoliko desetina ljudi, ovo je najbolje rješenje;
• Ako kontrolišete sistem koji ima stotine zaposlenih, pronalaženje prave sesije bez specijalizovanog softvera može potrajati. U ovom slučaju biće mnogo efikasnije ponovo pokrenuti server.

Ova rješenja su radikalna i usmjerena samo na brzo rješavanje problema i puštanje podataka za hitno izvještavanje. Može se iskorijeniti samo razumijevanjem razloga zbog kojih je došlo do sukoba zaključavanja tokom izvršenja 1C transakcije. Nakon ovakvih radnji potrebno je pronaći ranjivosti u sistemu, optimizirati konfiguraciju ili rad zaposlenih. Ne preporučuje se korištenje takvih mjera na stalnoj osnovi s redovnim sukobima zaključavanja transakcija.