Kuinka diagnosoin esto-ongelmat. Kuinka diagnosoin esto-ongelmat Esto 1 sekunnissa tiedonsiirron aikana

Monen käyttäjän järjestelmissä rakenteen oikealla organisoinnilla ja lukkojen asettamisella on tärkeä rooli. Jos sitä ei ole, käyttäjien on usein käsiteltävä virheitä, jotka johtuvat kilpailusta tietyistä järjestelmäresursseista. Mutta on lukitusristiriitaongelma, joka on tuttu monille käyttäjille. Miksi 1C-lukitusristiriita ilmenee ja kuinka se ratkaistaan?

Lukitse ristiriita kohdassa 1C 8.3 ja sen merkitys

Useimmille käyttäjille viesti 1C-lukitusristiriitasta tarkoittaa vain virhettä, joka estää heitä tekemästä työtään. He haluavat päästä eroon tästä ongelmasta mahdollisimman nopeasti ja piirittää IT-osaston valituksella, että "1C ei toimi".

Mutta järjestelmänvalvojille ja kehittäjille tällainen viesti osoittaa, että kokoonpanorakenteessa saattaa olla ongelmia. Ennen kuin yrität miellyttää käyttäjiä ja poistaa tukoksia, sinun on analysoitava tilanne ja ymmärrettävä virheilmoituksen syy.

Syitä estovirheille 1C:ssä

Demonstroiva kuormitustestaus osoittaa, että 1C-palvelin kestää yli viiden tuhannen käyttäjän rinnakkaistoiminnan. Mutta ihanteellisia olosuhteita tällaisille kokeiluille ei voida saavuttaa suurten ja keskisuurten yritysten arkipäivän olosuhteissa. Samanlaisen suorituskyvyn ja virheettömän toiminnan saavuttamiseksi kokoonpanon on oltava ihanteellisesti suunniteltu ja räätälöity yrityksen erityisiin liiketoimintaprosesseihin.

Jos emme ota ihanteellisia vaihtoehtoja, 1C-lukitusristiriidat ilmenevät seuraavista syistä:

Käyttäjien samanaikainen työ suurella tietomäärällä. Tämän perimmäisen syyn sanelevat 1C:n sisäiset mekanismit. Niihin sisältyy toisen käyttäjän puolesta aloitettuun tapahtumaan liittyvien tietojen muuttamisen kieltäminen;

Virheitä ja puutteita kokoonpanossa. 1C-yhtiön standardiratkaisujen rakenne ottaa huomioon suositukset tuottavuuden maksimoimiseksi. Kolmannen osapuolen kehittäjät eivät kuitenkaan aina noudata korkeita standardeja, ja heidän koodissaan voi usein löytää seuraavat puutteet:

• Epäoptimaaliset kyselyt;
• Saldopyyntö toimien alussa;
• Väärinkäsitys konfigurointiobjektien tarkoituksesta ja niiden virheellinen käyttö;
• Järjestelmään sisäänrakennettujen tai lisäkehitettyjen lukitusten redundanssi.

Lukitusristiriidan korjaaminen 1C 8.3:ssa

Järjestelmäsanoma "lukitusristiriita suoritettaessa 1C 8.3 -tapahtumaa" ei luonnehtia kokoonpanoa virheellisesti suunnitelluksi. Mutta jos tällaiset signaalit jätetään huomiotta, on mahdollista joutua suuriin ongelmiin tärkeimmällä hetkellä, esimerkiksi toimitettaessa neljännesvuosittaisia ​​tai vuosittaisia ​​raportteja. Parhaimmillaan hidas järjestelmä ja tyytymättömät käyttäjät. Pahimmillaan tulostiedot ovat virheellisiä, mikä voi johtaa valvontaviranomaisille seuraamuksiin.

Ratkaisu 1C 8.3:n lukitusristiriidan ongelmaan voi olla konfiguroinnin siirtäminen hallittuun (manuaaliseen) lukonhallintatilaan. Versiossa 8.1 toteutettu mekanismi pätevien asiantuntijoiden käsissä ratkaisee lukitusristiriitojen ongelman 1C:n tapahtuman aikana.

Mutta on syytä pitää mielessä, että tämä toimenpide vähentää tietojen suojaustasoa muutoksilta, kun muut käyttäjät lukevat niitä. Siksi, jos et ole valmis hallitsemaan itsenäisesti kaikkia järjestelmän lukkoja, älä kiirehdi muuttamaan kokoonpanoasetuksia.

Nopea ratkaisu 1C-lukitusristiriitaan

Järjestelmänvalvojan tai kehittäjän työssä voi syntyä tilanne, jossa ei ole aikaa tarkistaa virhettä ja etsiä ongelman perimmäisiä syitä. Esimerkiksi raportti tai tiedot on lähetettävä tiettyyn aikaan, mutta 1C-estovirheet estävät tämän.

On kaksi tapaa ratkaista ongelma nopeasti:

• Etsi ja lopeta istunto, joka estää vaaditut tiedot. Pienissä yrityksissä, joissa 1C-käyttäjien määrä ei ylitä muutamaa kymmentä ihmistä, tämä on optimaalinen ratkaisu;
• Jos hallitset järjestelmää, jossa on satoja työntekijöitä, oikean istunnon löytäminen ilman erikoisohjelmistoja voi kestää kauan. Tässä tapauksessa on paljon tehokkaampaa käynnistää palvelin uudelleen.

Nämä ratkaisut ovat radikaaleja, ja niillä pyritään vain ratkaisemaan ongelma nopeasti ja vapauttamaan tietoja kiireellistä raportointia varten. Se voidaan poistaa vain ymmärtämällä syy, miksi lukitusristiriita syntyi 1C-tapahtumaa suoritettaessa. Tällaisten toimien jälkeen on tarpeen löytää järjestelmän haavoittuvuuksia, optimoida työntekijöiden kokoonpano tai työ. Ei ole suositeltavaa käyttää tällaisia ​​toimenpiteitä jatkuvasti, jos tapahtumissa on säännöllisiä lukitusristiriitoja.

Kun satoja käyttäjiä työskentelee samanaikaisesti ohjelmien ja tietojen kanssa, syntyy ongelmia, jotka ovat tyypillisiä vain suurille ratkaisuille. Puhumme tietojen estämisen aiheuttamista ongelmista.

Joskus käyttäjät oppivat eston viesteistä, jotka osoittavat, että he eivät voi kirjoittaa tietoja tai suorittaa jotain muuta toimintoa. Joskus johtuen erittäin merkittävästä ohjelman suorituskyvyn heikkenemisestä (esimerkiksi kun toiminnon suorittamiseen tarvittava aika kasvaa kymmeniä tai satoja kertoja).

Eston aiheuttamille ongelmille ei ole yleistä ratkaisua. Siksi yritämme analysoida tällaisten ongelmien syitä ja systematisoida vaihtoehtoja niiden ratkaisemiseksi.

SYYT TAPAHTUMAN ESTÄMISEEN

Muistetaan ensin, mitä lukot ovat, ja samalla selvitetään, ovatko ne tarpeellisia. Katsotaanpa paria klassista esimerkkiä elämässä kohtaamistamme tukkeista.

Esimerkki 1: lento- tai junalippujen ostaminen. Oletetaan, että ilmaisimme toiveemme kassalle. Kassa kertoo vapaita paikkoja, joista voimme valita itsellemme mieluisimman (jos niitä on useita). Vaikka valitsemme ja hyväksymme ehdotetun vaihtoehdon, näitä paikkoja ei voida myydä kenellekään muulle, esim. ovat tilapäisesti "estetty". Jos niitä ei estetty, voi vahvistushetkellä olla tilanne, jossa valitsemamme liput olivat jo myyty. Ja tässä tapauksessa valintasyklillä voi olla arvaamaton määrä toistoja. Kun valitsemme paikkoja, ne on jo myyty!.. Samalla kun valitsemme muita, eikä niitä enää ole...

Esimerkki 2: ostaa jotain kaupasta tai basaarista. Menimme tiskille ja valitsimme kauneimman omenan sadoista saatavilla olevista. He valitsivat sen ja kurkoivat taskuihinsa rahaa. Miltä näyttää, jos sillä hetkellä, kun laskemme rahoja, valitsemamme omena myydään ostajalle, joka tuli myöhemmin kuin me?

Siten esto itsessään on tarpeellinen ja hyödyllinen ilmiö. Eston ansiosta takaamme, että toimet suoritetaan yhdessä vaiheessa. Ja se, mikä useimmiten johtaa negatiivisuuteen, ei ole menestynein ohjelmistototeutus, kun esim.

• liiallinen määrä esineitä (liput, omenat) on tukossa;
• Estoaikaa pidennetään kohtuuttomasti.

LIIKAA ESTO TYYPILLISISSÄ 1C-KONFIGUROINTISSA

Suurissa projekteissa käytämme pääsääntöisesti 1C:Enterprise. Siksi yritämme kuvata käytännön suosituksia estoongelmien ratkaisemiseksi 1C:Enterprise + MS-SQL -yhdistelmän esimerkillä.

1C:Enterprisen 8. sukupolvi tarjoaa erittäin, erittäin hyvän rinnakkaisuuden. Valtava määrä käyttäjiä voi työskennellä samanaikaisesti yhdellä kokoonpanolla (eli yhdellä tukiasemalla) normaaleiden palvelimien ja viestintäkanavien kanssa. Esimerkiksi sadat varastonhoitajat käsittelevät tavaroiden luovutusta tai vastaanottoa, ekonomistit laskevat samanaikaisesti eri osastojen työvoimakustannuksia, kirjanpitäjät laskevat ja palkkaavat jne.

Mutta on syy, miksi ollaan päinvastaisia ​​- myytti, että intensiivisellä samanaikaisella käytöllä työskentely 1C:Enterprise-pohjaisten ratkaisujen kanssa on epämukavaa tai mahdotonta. Loppujen lopuksi heti kun sadat käyttäjät alkavat käyttää 1C:Enterprisen standardiratkaisuja teollisessa mittakaavassa, näytölle ilmestyy yhä useammin ikkuna, jossa on ylpeä merkintä: "Virhe soitettaessa kontekstimenetelmää (kirjoita) : Lukitusristiriita tapahtumaa suoritettaessa: ..." ja edelleen riippuen käytetyn SQL-palvelimen tyypistä, esimerkiksi "Microsoft OLE DB Provider for SQL Server: Lukituspyynnön aikakatkaisuaika ylitetty. ...".

Lähes kaikki vakioratkaisut ehdotetuissa valmiissa toteutuksessa on konfiguroitu automaattista lukkojen hallintaa varten. "Automaattinen" tässä voidaan pitää "paranoidisena". Joka tapauksessa, kun käsittelemme mitä tahansa asiakirjaa, estämme kaiken, mikä voi jollain tavalla liittyä siihen. Joten käy ilmi, että kun yksi käyttäjä tekee jotain (ja joskus vain kirjoittaa sen muistiin), loput voivat vain odottaa.

Ilmaisen mielipiteeni, miksi 1C päätti olla konfiguroimatta standardiratkaisujaan korkeaan rinnakkaiskäyttöön. Tällaisen muutoksen työvoimakustannukset eivät ole korkeat - useita "mieskuukausia", mikä ei ole merkittävää 1C: n mittakaavassa. Minusta tuntuu, että syy on eri.

Ensinnäkin tällainen muutos vaikeuttaa huomattavasti kaikkien asiakirjojen käsittelyä. Tämä tarkoittaa, että niille kuluttajille, jotka käyttävät 1C:tä pieniin tehtäviin, ilman voittoa on vain haittapuoli - vakiokokoonpanon muuttamisen vaikeus monimutkaistuu. Tilastot kertovat samalla, mikä asiakasluokka on 1C:n pääsyöttölaite...

Toinen syy on haudattu SQL-palvelimien tyypillisiin perusasetuksiin, esimerkiksi MS-SQL, jota käytetään edelleen muita useammin. Sattui vain niin, että asetuksissa etusijalle annettiin palvelimen RAM-muistin säästäminen estojen vähentämisen sijaan. Tämä johtaa siihen, että jos on tarpeen lukita useita rivejä, SQL-palvelin tekee "muistia ja prosessoria säästävän" päätöksen - lukita koko taulukon kerralla!..

Nämä standardiratkaisujen puutteet tai käytetyn tietokantapalvelimen asennuksen erityispiirteet tunnistetaan usein eston aiheuttamiin ongelmiin. Tämän seurauksena tekniset puutteet johtavat erittäin merkittäviin organisatorisiin ongelmiin. Jos työntekijälle annetaan syy olla hajamielinen töistä tai perustellaan, miksi työtä ei voitu tehdä, vähemmistö toimii tehokkaasti. No, viesti tapahtumien estämisestä tai "jarrutusohjelmasta" on ihanteellinen perustelu sille, miksi jotain ei voitu tehdä.

SUOSITUKSET 1C:ENTERPRISE LIIAALLISTEN ESTOJEN POISTAMISEKSI

Mitä tehdä, jos liiallisen lukituksen ongelmien ratkaiseminen on niin tärkeää?

Kaikkien suurten kompleksien toteutuksen viimeisessä vaiheessa on tarpeen suorittaa hienosäätö tarpeettomien tapahtumien eston poistamiseksi. On ratkaisevan tärkeää ratkaista ongelmat, joita saattaa syntyä riittämättömästi kehitettyjen estoehtojen tai toteutustekniikoiden vuoksi.

Koska Tämä toimenpide on erittäin tärkeä ja sitä on suoritettava jatkuvasti. Siksi tällaisten muutosten yksinkertaistamiseksi olemme kehittäneet joukon perussuosituksia, joita yritämme noudattaa. Suositukset on saatu ja testattu kokemuksen kautta merkittävästä määrästä laajamittaisia ​​toteutuksia.

1. Jos käyttämäsi DBMS tai kehitysjärjestelmä (esimerkiksi 1C:Enterprise) käyttää oletusarvoisesti automaattista tietojen lukitustilaa, hylkää automaattinen lukituksen hallinta. Määritä estosäännöt itse, kuvaile kriteerit kokonaisten taulukoiden tai yksittäisten rivien estämiselle.
2. Kun kehität ohjelmaa, käytä taulukoita samassa järjestyksessä aina kun mahdollista.
3. Yritä olla kirjoittamatta samaan taulukkoon useita kertoja saman tapahtuman aikana. Jos tämä on vaikeaa, niin ainakin minimoi ensimmäisen ja viimeisen kirjoitusoperaation välinen aika.
4. Analysoi mahdollisuutta poistaa lukituksen eskalointi käytöstä SQL-palvelintasolla.
5. Kerro käyttäjille selkeästi syistä, miksi he eivät voi suorittaa mitään toimia, jos ne johtuvat estosta. Anna helppokäyttöisiä ja ymmärrettäviä suosituksia siitä, mitä tehdä seuraavaksi.

Jos tarkastelet suosituksia huolellisesti, se käy selväksi tällainen testaus ei sovellu vain 1C:Enterprise, vaan kaikkiin järjestelmiin. Sillä ei ole lainkaan väliä, millä kielellä ne on kirjoitettu ja minkä tietokantapalvelimen kanssa ne toimivat. Useimmat suositukset ovat luonteeltaan yleismaailmallisia, ja siksi ne ovat yhtä päteviä käytettäessä 1C:Enterpriseä ja "kotikirjoitettuja" ohjelmia tai muita "laatikoituja" ERP-järjestelmiä.

P.S. Tiesitkö, että tarjoamme ammattitaitoista apua 1C:n päivityksessä parhaaseen hintaan?

Hakutunnisteet:

• Kaupan lukot
• Tukosten poistaminen
• 1C lukot
• Lukko
• Lukitse konflikti
• Lukitse kiista tapahtuman aikana

En voinut kirjoittaa muistiin muutoksia siirrettäväksi hajautettuun tietokantaan, joten otin yhteyttä 1C-tukeen ja tarjosin seuraavaa. Ratkaisin sen yksinkertaisesti käynnistämällä sovelluspalvelimen ja SQL-palvelimen uudelleen. Yleensä voit valita ruudun "Blocking regulatory
tehtävät mukana"
Se auttoi myös ilman uudelleenkäynnistystä.

MS SQL Serverin rutiinitoiminnot DBMS-tasolla

Ohjeet rutiinitoimintojen suorittamiseen DBMS-tasolla.

Tiedot koskevat 1C:Enterprise 8:n asiakaspalvelinversiota käytettäessä MS SQL Server DBMS:ää.

Yleistä tietoa

Yksi yleisimmistä syistä järjestelmän epäoptimaaliseen toimintaan on rutiinitoimintojen virheellinen tai epäaikainen suorittaminen DBMS-tasolla. Erityisen tärkeää on näiden säädösten toteuttaminen suurissa tietojärjestelmissä, jotka toimivat merkittävällä kuormituksella ja palvelevat samanaikaisesti suurta määrää käyttäjiä. Tällaisten järjestelmien erityispiirteenä on, että tavalliset DBMS:n automaattisesti suorittamat toiminnot (asetusten perusteella) eivät riitä tehokkaaseen toimintaan.

Jos käynnissä olevassa järjestelmässä havaitaan suorituskykyongelmia, sinun tulee tarkistaa, että järjestelmä on määritetty oikein ja suorittaa säännöllisesti kaikki suositellut rutiinitoiminnot DBMS-tasolla.

Sääntelymenettelyjen täytäntöönpano olisi automatisoitava. Näiden toimintojen automatisoimiseksi on suositeltavaa käyttää sisäänrakennettua MS SQL Server -työkalua: Maintenance Plan. On myös muita tapoja automatisoida nämä toimenpiteet. Tässä artikkelissa on esimerkki kunkin sääntelymenettelyn määrittämisestä MS SQL Server 2005:n ylläpitosuunnitelman avulla.

On suositeltavaa seurata säännöllisesti näiden sääntelymenettelyjen oikea-aikaisuutta ja oikeellisuutta.

Päivitä tilastot

MS SQL Server rakentaa kyselysuunnitelman, joka perustuu tilastotietoihin arvojen jakautumisesta indekseissä ja taulukoissa. Tilastotiedot kerätään osan (näytteen) perusteella ja päivitetään automaattisesti, kun nämä tiedot muuttuvat. Joskus tämä ei riitä, jotta MS SQL Server pystyisi jatkuvasti rakentamaan optimaalisimman suunnitelman kaikkien kyselyjen suorittamiseksi.

Tässä tapauksessa voi ilmetä kyselyn suorituskykyongelmia. Samalla kyselysuunnitelmissa on tyypillisiä merkkejä epäoptimaalisesta toiminnasta (ei-optimaaliset toiminnot).

MS SQL Server -optimoijan mahdollisimman oikean toiminnan takaamiseksi on suositeltavaa päivittää MS SQL -tietokannan tilastot säännöllisesti.

Jotta voit päivittää kaikkien tietokantataulukoiden tilastot, sinun on suoritettava seuraava SQL-kysely:

exec sp_msforeachtable N"PÄIVITYS TILASTOT ? FULLSCAN:lla"

Tilastojen päivittäminen ei johda taulukon lukitsemiseen eikä häiritse muiden käyttäjien työtä. Tilastoja voidaan päivittää niin usein kuin on tarpeen. On otettava huomioon, että DBMS-palvelimen kuormitus kasvaa tilastojen päivityksen aikana, mikä voi vaikuttaa negatiivisesti järjestelmän yleiseen suorituskykyyn.

Tilastojen optimaalinen päivitystiheys riippuu järjestelmän kuormituksen koosta ja luonteesta, ja se määritetään kokeellisesti. On suositeltavaa päivittää tilastot ainakin kerran päivässä.

Yllä oleva kysely päivittää kaikkien tietokannan taulukoiden tilastot. Tosielämän järjestelmässä eri taulukot vaativat erilaiset tilastojen päivitysnopeudet. Analysoimalla kyselysuunnitelmia voit määrittää, mitkä taulukot tarvitsevat eniten säännöllisiä tilastopäivityksiä, ja määrittää kaksi (tai useampia) eri rutiinimenettelyjä: usein päivitettäville taulukoille ja kaikille muille taulukoille. Tämä lähestymistapa vähentää merkittävästi tilastojen päivitysaikaa ja tilastopäivitysprosessin vaikutusta koko järjestelmän toimintaan.

Automaattisten tilastopäivitysten määrittäminen (MS SQL 2005)

Käynnistä MS SQL Server Management Studio ja muodosta yhteys DBMS-palvelimeen. Avaa Hallinta-kansio ja luo uusi ylläpitosuunnitelma:

Luo alasuunnitelma (Lisää osasuunnitelma) ja anna sille nimi "Päivitetään tilastoja". Lisää Update Statistics Task siihen tehtäväpalkista:

Aseta tilastopäivitysaikataulu. On suositeltavaa päivittää tilastot vähintään kerran päivässä. Tilastojen päivitystiheyttä voidaan tarvittaessa lisätä.

Määritä tehtäväasetukset. Voit tehdä tämän kaksoisnapsauttamalla tehtävää ikkunan oikeassa alakulmassa. Määritä näkyviin tulevassa lomakkeessa sen tietokannan (tai usean tietokannan) nimi, jonka tilastot päivitetään. Lisäksi voit määrittää, minkä taulukoiden tilastot tulee päivittää (jos et tiedä tarkalleen, mitkä taulukot sinun on määritettävä, aseta arvoksi Kaikki).

Tilastot on päivitettävä siten, että Full Scan -vaihtoehto on käytössä.

Tallenna luotu suunnitelma. Kun aikataulussa määritetty aika koittaa, tilastojen päivitys alkaa automaattisesti.

Proseduurien välimuistin tyhjennys

MS SQL Server -optimoija tallentaa kyselysuunnitelmat välimuistiin uudelleen suorittamista varten. Tämä tehdään kyselyn kokoamiseen kuluvan ajan säästämiseksi, jos sama kysely on jo suoritettu ja sen suunnitelma on tiedossa.

On mahdollista, että MS SQL Server rakentaa vanhentuneiden tilastotietojen perusteella epäoptimaalisen kyselysuunnitelman. Tämä suunnitelma tallennetaan prosessivälimuistiin ja sitä käytetään, kun samaa kyselyä kutsutaan uudelleen. Jos päivität tilastot, mutta et tyhjennä toimintosarjan välimuistia, SQL Server voi valita vanhan (alioptimaalisen) kyselysuunnitelman välimuistista uuden (optimaalisemman) suunnitelman rakentamisen sijaan.

Tyhjentääksesi MS SQL Serverin prosessivälimuistin, sinun on suoritettava seuraava SQL-kysely:

Tämä kysely tulee suorittaa heti tilastojen päivityksen jälkeen. Sen vuoksi sen suoritustiheyden tulisi olla sama kuin tilastopäivitystiheys.

Proseduurien välimuistin tyhjennys (MS SQL 2005)

Koska prosessivälimuisti on tyhjennettävä joka kerta, kun tilastot päivitetään, on suositeltavaa lisätä tämä toiminto jo luotuun alisuunnitelmaan "Päivitetään tilastoja". Voit tehdä tämän avaamalla alisuunnitelman ja lisäämällä Execute T-SQL-lausekkeen sen skeemaan. Sitten sinun tulee yhdistää Päivitystilastot -tehtävä nuolella uuteen tehtävään.

Luodun Execute T-SQL -lausetehtävän tekstissä sinun tulee määrittää pyyntö "DBCC FREEPROCCACHE":

Indeksien eheyttäminen

Kun työskentelet intensiivisesti tietokantataulukoiden kanssa, indeksi pirstoutuu, mikä voi heikentää kyselyn suorituskykyä.

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

Indeksien eheyttäminen ei lukitse taulukoita eikä häiritse muiden käyttäjien työtä, mutta se aiheuttaa lisäkuormitusta SQL Serverille. Tämän rutiinitoimenpiteen optimaalinen suoritustiheys tulee valita järjestelmän kuormituksen ja eheyttämisen vaikutuksen mukaan. On suositeltavaa eheyttää indeksit vähintään kerran viikossa.

Voit eheyttää yhden tai useamman taulukon kaikkien tietokannan taulukoiden sijaan.

Indeksin eheytyksen määrittäminen (MS SQL 2005)

Luo aiemmin luotuun ylläpitosuunnitelmaan uusi alisuunnitelma nimeltä "Indeksointi uudelleen".

Aseta indeksin eheytystehtävän suoritusaikataulu. Tehtävä on suositeltavaa suorittaa vähintään kerran viikossa, ja jos tietokannan tiedot ovat erittäin vaihtelevia, jopa useammin - enintään kerran päivässä.

Tietokantataulukoiden uudelleenindeksointi

Taulukon uudelleenindeksointi sisältää tietokannan taulukkoindeksien täydellisen uudelleenrakentamisen, mikä johtaa niiden suorituskyvyn merkittävään optimointiin. On suositeltavaa indeksoida tietokantataulukot säännöllisesti uudelleen. Jos haluat indeksoida kaikki tietokantataulukot uudelleen, sinun on suoritettava seuraava SQL-kysely:

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

Taulukoiden uudelleenindeksointi lukitsee ne koko toiminnan ajaksi, mikä voi vaikuttaa merkittävästi käyttökokemukseen. Tässä suhteessa on suositeltavaa suorittaa uudelleenindeksointi minimaalisen järjestelmän kuormituksen aikana.

Kun uudelleenindeksointi on valmis, indeksejä ei tarvitse eheyttää.

Taulukon uudelleenindeksoinnin määrittäminen (MS SQL 2005)

Luo aiemmin luotuun ylläpitosuunnitelmaan uusi alisuunnitelma nimeltä Hakemiston eheytys. Lisää siihen Rebuild Index Task:

Aseta taulukon uudelleenindeksointitehtävän suoritusaikataulu. On suositeltavaa suorittaa tehtävä minimijärjestelmän kuormituksen aikana, vähintään kerran viikossa.

Aseta tehtävä määrittämällä tietokanta (tai useita tietokantoja) ja valitsemalla tarvittavat taulukot. Jos et tiedä tarkalleen, mitkä taulukot tulisi määrittää, aseta arvoksi Kaikki.

Mitä lukot ovat 1C:ssä, miksi niitä tarvitaan ja kuinka välttää ongelmia niiden kanssa työskennellessään

Varmasti monet teistä ovat törmänneet 1C Enterprise -tietojärjestelmiin (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) sellaiseen ilmiöön kuin esto. Lisäksi yleensä kaikki kutsuvat tätä ilmiötä eri tavalla: "1C esto", "1C estoristiriita", "1C estovirheet", "1C-tapahtuman esto" ja muut nimet. Katsotaanpa nopeasti, mitä lukot (ei umpikujat) ovat, miksi niitä tarvitaan ja miten vältetään ongelmia niiden kanssa työskennellessä.

Itse lukot (mukaan lukien 1C:ssä ja muissa järjestelmissä) ovat hyödyllinen työkalu, joka tarjoaa mahdollisuuden työskennellä johdonmukaisesti jaettujen resurssien kanssa. Esimerkiksi käsite "jaetut resurssit" ympäröi meitä läpi elämän, esimerkiksi kun ajat autoa, kukaan muu ei voi ajaa sitä. Siksi auto on yhteinen resurssi. Ja toinen kuljettaja odottaa, kunnes saavut, esimerkiksi vaimosi/aviomies. Kilpailette molemmat yhteisestä resurssista - autosta. Sinä määrittelet käsitteellisellä tasolla kuka tällä hetkellä ajaa autoa, mutta mitä meidän pitäisi tehdä automatisoiduissa järjestelmissä??? Tästä syystä keksimme työkalun esto, jotka järjestävät jaetun resurssin käyttöprosessin ja määrittävät jonon. Pääsääntöisesti elämässä, kuten tietojärjestelmissä (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3), jaettuja resursseja on paljon, joten myös estoja on paljon. Nyt toinen tärkeä kohta on, kuinka kauan vaimosi/miehesi odottaa autosi vapauttamista. On loogista olettaa, että se ei kestä ikuisesti. Siksi lukot asetetaan aikakatkaisurajalle - joka tunnetaan muuten aikakatkaisuajana. Aikakatkaisu on enimmäisaika, jonka kilpaileva osallistuja (vaimosi/miehesi) odottaa jaetun resurssin vapautumista. Sitten hän joko jatkaa odottamista saman ajan tai kävelee. 1C-tietojärjestelmissä aikakatkaisun vanheneminen päättyy viestiin “1C-lukitusristiriita”, “1C-lukitusvirheet”, “1C-tapahtumalukit”, “Aikakatkaisu lukituksen aikana”.

Tärkeä yksityiskohta, joka on myös muistettava, on se, että lukot (erityisesti 1C:ssä) voivat olla eksplisiittisiä (käyttäjän asettamia) ja implisiittisiä (SQL-alustan asettamia). Artikkelissa puhumme eksplisiittisistä lukoista, joten niitä käytetään aina tapahtumassa, joten käy ilmi, että "1C Blocking" ja "1C Transaction Blocking" ovat synonyymejä.

Olemme päättäneet, että jos aikakatkaisu ylittyy, käyttäjä saa virheilmoituksen, itse odotusprosessi näyttää siltä, ​​että 1C-tietojärjestelmän näyttö on jumissa. Aikakatkaisuviestin ilmestymisen todennäköisyyteen (1C-käyttäjän virhe) vaikuttavat seuraavat ilmaisimet:

• Monet 1C lukitsee tapahtuman;
• Kaupan kesto.

Lukitusvirheisiin liittyvien viestien minimoimiseksi on tarpeen joko vähentää lukkojen määrää (optimoida selektiivisyys) tai lyhentää tapahtumien kestoa.
Nyt selvitetään, kuinka näihin indikaattoreihin voidaan vaikuttaa todellisessa 1C-tietojärjestelmässä.

Voit vähentää eston määrää seuraavasti:

1C:Enterprise 7.7:ssä:

Tietojärjestelmä 1C 7.7. Lukitsemiseen käytetään pöytälukkoja, jotka halvaantavat käyttäjien työn. Pääsääntöisesti yli 50 henkilöä yhdessä tietokannassa ei voi toimia ilman virheitä, ja ongelmia voi ilmetä myös 20 käyttäjän tietokannassa.
Ratkaisu:

• Joustavat lukot 1C Softpoint-yhtiöltä. Niiden avulla et vain optimoi monia lukkoja (korvaa pöytälukot käyttäjän lukoilla), vaan myös nopeuttaa valintoja, hakuja ja raportteja.

1C:Enterprise 8.x:ssä:
Tietojärjestelmä 1C 8.1., 1C 8.2., 1C 8.3. automaattitilassa se käyttää redundantteja lukkoja, joiden tyyppi on (REPEATABLEREAD, SERIALIZABLE). Tämä heikentää käyttökokemusta 100 tai enemmän.
Ratkaisu:

• Hallitut lukot 1C - 1C-alustan sisäänrakennettu työkalu lukkojen valikoivampaan konfigurointiin. Käyttääkseen sitä ohjelmoijan on kirjoitettava erikoisoperaattorit oikeisiin paikkoihin koodissa estämään tarvittavat ( hänen mielestään!) tietueet tietojärjestelmän taulukoissa;
• Joustavat lukot 1C - Softpoint-tekniikka vakiolukkojen korvaamiseen mukautetuilla lukoilla.

Voit lyhentää tapahtumaaikoja seuraavasti:

Kaikissa 1C-tietojärjestelmissä (1C 7.7., 1C 8.1, 1C 8.2, 1C 8.3) kuten muissakin tietojärjestelmissä käytetään samanlaisia ​​lähestymistapoja:

Tietokannan rutiinihuollon tarkistaminen ja oikein määrittäminen (tiedostojen, indeksien, tilastojen, väliaikaisten taulukkotietokantojen ylläpito, Windowsin ja SQLServerin asetukset);

Raskaiden 1C- ja SQL-kyselyiden analysointi ja optimointi (indeksin viritys, kyselyjen uudelleenkirjoitus);

Tarkistetaan tapahtumien redundanssia. Monissa tapauksissa liiketoimia sisällytetään kohtuuttomasti tapahtumaan ymmärtämättä, kuinka tämä vaikuttaa kestoon ja sen myötä suorituskykyyn.

1. Jos haluat itsenäisesti käsitellä 1C:n (1C 7.7, 1C 8.1, 1C 8.2, 1C 8.3) ja muiden tietojärjestelmien teknisiä suorituskykyongelmia , niin sinulle on ainutlaatuinen luettelo teknisistä artikkeleista Almanakissamme (estot ja lukkiutumiset, prosessorin ja levyjen raskas kuormitus, tietokannan ylläpito ja indeksin viritys ovat vain pieni osa sieltä löytyvistä teknisistä materiaaleista).
2. Jos haluat keskustella suorituskykyongelmista asiantuntijamme kanssa tai tilata PerfExpert-suorituskyvyn seurantaratkaisun, jätä pyyntö, niin otamme sinuun yhteyttä mahdollisimman pian.

Ei ole harvinaista, että 1C:ssä työskennellessä tulee virheilmoitus "Lukitusristiriita tapahtumia suoritettaessa: Lukon myöntämisen enimmäisodotusaika on ylitetty." Sen ydin on siinä, että useat istunnot yrittävät suorittaa samanaikaisesti samanlaisia ​​​​toimia, jotka vaikuttavat samaan resurssiin. Tänään selvitetään kuinka korjata tämä virhe.

Suuri määrä operaatioita suoritettu

Ensimmäinen askel syitä etsittäessä on selvittää, kuinka monta samanaikaista käyttäjää on tietokannassa, jossa tällainen virhe syntyy. Kuten tiedämme, niiden enimmäismäärä voi olla melko suuri. Tämä on sekä tuhat että viisi tuhatta.

Lukitusmekanismi ja tapahtumat on kuvattu kehittäjän oppaassa. Niitä käytetään, kun useat istunnot käyttävät samaa dataa samanaikaisesti. On loogista, että eri käyttäjät eivät voi muuttaa samoja tietoja samanaikaisesti.

Sinun tulee myös tarkistaa, onko jollain käyttäjistä käynnissä massatietojen muutoskäsittely. Tämä voi olla esimerkiksi kuukauden loppu ja vastaava. Tässä tapauksessa, kun käsittely on valmis, virhe häviää itsestään.

Ajoitetut tehtävät

Ei ole harvinaista, että virheen syy on suuria tietomääriä käsittelevässä järjestelmässä. On suositeltavaa tehdä tällaisia ​​​​asioita yöllä. Aseta aikataulu tällaisten rutiinitehtävien suorittamiselle työajan ulkopuolella.

Tällä tavalla käyttäjät työskentelevät vakaassa järjestelmässä ja itse rutiinitehtävät suoritetaan onnistuneesti, koska ristiriitojen todennäköisyys käyttäjäistuntojen kanssa pienenee.

"Hung sessions"

Käyttäjien "jumiutuneiden istuntojen" ongelma on tuttu melkein kaikille, jotka ovat kohdanneet 1C-huollon. Käyttäjä olisi voinut poistua ohjelmasta kauan sitten tai sulkea dokumentin, mutta hänen istuntonsa pysyy edelleen järjestelmässä. Ongelma on useimmiten eristetty ja riittää, kun lopetat tällaisen istunnon järjestelmänvalvojan konsolin kautta. Samat ongelmat voivat ilmetä taustatöissä.

Lukuisten Internet-kommenttien mukaan tällaiset tilanteet ovat yleisempiä verkon suojausavaimia käytettäessä. Jos "jäädytysistuntojen" tilanne toistuu systemaattisesti, tämä on syy tarkastaa ja huoltaa järjestelmä ja palvelimet perusteellisesti (jos tietokanta on asiakas-palvelin).

Virheitä määritystä kirjoitettaessa

Kaikki vakiokokoonpanot ovat pätevien asiantuntijoiden ja asiantuntijoiden kehittämiä. Jokainen järjestelmä testataan perusteellisesti ja optimoidaan nopeampaa ja oikeampaa toimintaa varten.

Tässä suhteessa virheen syy voi olla kolmannen osapuolen kehittäjän kirjoittamassa epäoptimaalisessa koodissa. Tämä voi olla "raskas" pyyntö, joka estää tiedot pitkäksi aikaa. Usein on myös tapauksia, joissa muodostetaan algoritmeja, joiden suorituskyky on heikko ja logiikkaa rikkoo.

On suuri todennäköisyys, että lukitusristiriita syntyi juuri kehittäjän virheistä, jos se syntyi ohjelmapäivityksen jälkeen. Tarkistaaksesi, voit yksinkertaisesti "palauttaa" parannukset tai muuttaa koodin.