I flerbrukersystemer er riktig organisering av strukturen og innstillingen av låser viktig. Hvis ikke, vil brukere ofte måtte møte feil forårsaket av konkurranse om visse systemressurser. Men det er et låsekonfliktproblem som er kjent for mange brukere. Hvorfor er det en 1C-låskonflikt og hvordan eliminere den?
Lås konflikt i 1C 8.3 og dens betydning
For de fleste brukere betyr en melding om en 1C-låskonflikt kun en feil som hindrer dem i å gjøre jobben sin. De ønsker å bli kvitt dette problemet så fort som mulig og beleirer IT-avdelingen med klager om at «1C ikke fungerer».
Men for systemadministratorer og utviklere indikerer en slik melding et mulig problem i konfigurasjonsstrukturen. Før du prøver å glede brukere og fjerne låser, er det nødvendig å analysere situasjonen og forstå årsaken til feilmeldingen.
Årsaker til blokkeringsfeil i 1C
Demonstrative belastningstester viser at 1C-serveren tåler parallelldrift av mer enn fem tusen brukere. Men de ideelle forholdene for slike eksperimenter er uoppnåelige i hverdagsforholdene til store og mellomstore bedrifter. For å oppnå samme hastighet og feilfri ytelse, må konfigurasjonen være ideelt utformet og skreddersydd til de spesifikke forretningsprosessene til bedriften.
Hvis du ikke tar de ideelle alternativene, oppstår 1C-låskonflikter av følgende årsaker:
Samtidig arbeid av brukere med en stor mengde data. Denne grunnårsaken er diktert av de interne mekanismene til 1C. De innebærer forbud mot å endre dataene som er involvert i en transaksjon lansert på vegne av en annen bruker;
Feil og mangler i konfigurasjonen. I strukturen til typiske løsninger fra 1C-selskapet, tas det hensyn til anbefalinger for å maksimere produktiviteten. Men tredjepartsutviklere følger ikke alltid høye standarder, og følgende mangler kan ofte finnes i koden deres:
- Suboptimale forespørsler;
- Forespørsel om saldo ved begynnelsen av handlinger;
- Misforståelse av formålet med konfigurasjonsobjekter og feil bruk av dem;
- Redundans av innebygd system eller tilleggsutviklede låser.
Hvordan fikse en låsekonflikt i 1C 8.3
Systemmeldingen "lås konflikt ved utførelse av transaksjon 1C 8.3" karakteriserer ikke konfigurasjonen som feildesignet. Men hvis slike signaler ignoreres, er det en mulighet for å få store problemer i det mest avgjørende øyeblikket, for eksempel ved innsending av kvartals- eller årsrapporter. I beste fall - et bremsesystem og misfornøyde brukere. I verste fall feil utdata, noe som kan føre til straff fra tilsynsmyndighetene.
Løsningen på problemet med en konflikt mellom låser i 1C 8.3 kan være overføring av konfigurasjonen til en kontrollert (manuell) låsekontrollmodus. Implementert i versjon 8.1, løser mekanismen i hendene på kompetente spesialister problemet med låsekonflikter under transaksjoner i 1C.
Men det bør tas i betraktning at denne handlingen vil redusere beskyttelsesnivået for data fra å bli endret i prosessen med å bli lest av andre brukere. Derfor, hvis du ikke er klar til å kontrollere alle låsene i systemet uavhengig, må du ikke skynde deg å endre konfigurasjonsinnstillingene.
Rask løsning av 1C-låskonflikt
I arbeidet til en administrator eller utvikler kan det oppstå en situasjon når det ikke er tid til å sjekke feilen og søke etter årsakene til problemet. For eksempel må du sende inn en rapport eller sende inn data innen et bestemt tidspunkt, og 1C-blokkeringsfeil forhindrer dette.
Det er to måter å raskt løse problemet på:
- Finn og avslutt økten som blokkerte de nødvendige dataene. I små selskaper, hvor antallet 1C-brukere ikke overstiger et par dusin personer, er dette den beste løsningen;
- Hvis du kontrollerer et system der hundrevis av ansatte jobber, kan det ta lang tid å finne den rette økten uten spesialisert programvare. I dette tilfellet vil det være mye mer effektivt å starte serveren på nytt.
Disse løsningene er radikale og tar kun sikte på å raskt løse problemet og frigjøre data for rask levering av rapporter. Det kan bare utryddes ved å forstå årsaken til at det var en låsekonflikt når du utfører en 1C-transaksjon. Etter slike handlinger er det nødvendig å finne sårbarheter i systemet, optimalisere konfigurasjonen eller arbeidet til ansatte. Det anbefales ikke å bruke slike tiltak fortløpende ved regelmessige låsekonflikter på transaksjoner.
Koster 8,1 sett for 5 brukere.
Vi bruker standard regnskap.
De jobber hovedsakelig gjennom terminalen, noen ganger uten.
Databasealternativ - fil
Feil ble lagt merke til av de i terminalen
noe sånt som dette. Rotet i nettet, Yandex - generelt, liksom vagt alt.
Hovedanbefalingene funnet:
1) Loss / Last base - i betydningen en ny å lage fra konfiguratoren
2) kjør \ Program Files \ 1cv81 \ bin \ chdbfl.exe - sjekk den fysiske integriteten til databasen
3) Test og fiks infobasen
4) oppdatering til siste versjon 8.1
Er det noen som vet noe mer spesifikt?
13.5.2010, 10:05
Alt du trenger, du har allerede blitt tilbudt, prøv det først. Det er ingen fysiske feil på media?
Er det mer spesifikt hvem som vil si.
13.5.2010, 10:56
Så dette ... hvis vi vurderer det uten hensyn til 1C, men generelt sett er det dumt at noen fra to steder prøver å blokkere ett bord, det første har tid, og resten blir sendt. Se hvilke operasjoner / transaksjoner / behandling (eller som det heter i 1C) som utføres på dette tidspunktet. Det kan godt være at poenget ikke er i plattformen, men i skjevt skrevne konfigurasjoner eller særegenhetene ved arbeidet med disse konfigurasjonene på dataene dine.
P.S. Og fildatabaser i flerbrukermodus er en perversjon.
13.5.2010, 10:58
Selv om i helvete vet hvordan 1C-in har laget en database, kan det godt hende at et sted i databasen for en sikring og alle slags repirer vil hjelpe.
13.5.2010, 11:06
Ja, det virker for meg som om oktalen er som en plattform - den er fortsatt fuktig. Et sted skrev de at det PERIODISK må testes med en fiksering
13.5.2010, 11:10
usannsynlig. For de åtte ble det kjøpt en ny server med en lisensiert Windows
Poenget er at man låser bordet, resten venter til timeout.
Hvorfor de ikke har tid er et stort spørsmål. Det fysiske mediet ser ut, kanskje det er dumt. Systemlogg, MHDD. Og alle handlingene som er skrevet i det første innlegget er påkrevd.
P.S. Ny betyr ikke 100% jobbing.
13.5.2010, 11:38
Alt du trenger, du har allerede blitt tilbudt, prøv det først
så ja, du må vente til kvelden.
Det var lite håp om å høre noe nytt
Ikke fortell mirakler. Det er nok problemer, men det er de ikke.
hvor er miraklene? Jeg skjønte ikke, noen skulle hevde at 8.1 er en kul feilfri plattform?
skrev at det PERIODISK må testes med korreksjon
vi ser ut til å ha en slik sak.
En undersøkelse blant brukere én etter én (for ikke å lyve i minnelighet) viste at denne situasjonen ser ut til å oppstå BARE blant brukere som jobber i terminalen. Og de som ikke går gjennom terminalen som
Windows Server 2003 R2 Standart 64, husker enten ikke en slik situasjon, eller så hadde de det rett og slett ikke.
Dessuten bemerket to spesielt observante at for 1,5-2 måneder siden ble dette fenomenet observert MYE sjeldnere.
13.5.2010, 12:42
Født morder, Hvilken antivirustråd er på serveren? I så fall, prøv å deaktivere den eller legg til basen til unntakene
13.5.2010, 13:14
Hvilken tråd er antivirus på serveren?
xs, du må se. Dette er en fiendtlig server
smart-ass franchis tok en av våre baser for vedlikehold, sikret serveren deres, og som om de overvåker arbeidet vårt
tilgang til serveren deres ble gitt, men i en avkortet versjon.
Jeg skal ta en titt.
nei det ser ut til å være et antivirus...
13.5.2010, 13:23
Jeg skjønte ikke, noen skulle hevde at 8.1 er en kul feilfri plattform?
å vel nei. 7.7 som er rotete på steder så langt, men omtrent 8-ku akkurat passe til å lage legender om dens glitches
Hvor mye er grunnstørrelsen og hvor mange brukere?
Sminke. Gi et konkret eksempel.
Hvor mye er grunnstørrelsen og hvor mange brukere?
laget en tester om natten og korrigerte den. Før det var 1cv8.1CD 2 GB, nå er den 1,5 GB.
Det er 5 brukere, samt selve lisensen.
Når det gjelder legendene om glitchiness, var det ett tilfelle. Nå, hvis du tar 7.7 og bare kopierer 1 base gjennom Total til et annet sted - en kopi uten problemer.
Når jeg prøvde å gjøre det samme med en åttepunkts base, kopierte jeg basekatalogen til et annet sted,
registrert, åpnet begge basene samtidig, den ene skulle være pervers.
Jeg merket flere dokumenter for sletting i kopien, byttet til vinduet med en ekte database, jeg kunne ikke tro mine egne øyne: de samme dokumentene ble merket for sletting der også
Askestubb, 1C har et svar på alt: lag en daglig kopi av databasen.
Ja, bare dette er et jævla svar
MMMarina
Født morder,
Hei venn...
Myte!
Slik blir legender født ...
Hei venn...
Hei venn. Nå ble du revet med
Og så ble ikonene på skrivebordet pasifisert
Myte!
Slik blir legender født ...
Jeg så det. Det var ikke morsomt for meg senere å skille mellom postede dokumenter fra ikke-posterte dokumenter, etter å ha fjernet slettemerket blir de alle ikke-posterte.
Jeg husker ikke hvilken plattform det var da.
prøv å gjøre det samme. Kanskje du kan gjøre det også
Slik blir legender født ...
Jeg vil si mer: når jeg manuelt fjerner merkingen av et par dokumenter i en kopi for sletting,
det samme skjedde i den virkelige databasen. På den tiden hadde jeg ikke tid til på en eller annen måte å dokumentere denne sensasjonen.
Så jeg la den bare tilbake og gjorde det ikke igjen.
fikse gapende hull i datakunnskap ...
etter min mening er jeg virkelig håpløs...
dette spesielle emnet er ikke for deg i det hele tatt, kjære (e)
generelt gir alt seg til forståelse
få en nerdevenn, som et alternativ)))
Jeg merket flere dokumenter for sletting i kopien, byttet til vinduet med en ekte database, jeg kunne ikke tro mine egne øyne: de samme dokumentene ble merket for sletting og der shok.gif
Jeg har aldri kopiert en filbase med en 8-bit
Det var på ingen måte en sensasjon.
Faen du tror kanskje ikke, men det VAR.
Faktum er at jeg jobbet veldig tett med 8 i flere år. Så snart de ikke ble kopiert. Så jeg kan ikke tro det
Men jeg kan anta at når en person er overarbeidet, er mye mulig. Jeg vet fra meg selv.
Ikke bekymre deg, filbasen kan enkelt kopieres og heves hvor som helst. Det skal ikke være noen feil.
14.5.2010, 10:52
14.5.2010, 11:28
Det er et forslag - på parkeringen foreskrev jeg den samme basen 2 ganger
8 foreslår å erstatte
14.5.2010, 11:31
hennes ... 7.7 når du prøver å gjøre dette, er det dumt stille og legger ikke basen til listen (den reagerer bare ikke på noen måte)
8 foreslår å erstatte
Vi kan bare savnet musen og kjørte den samme ... Mirakler skjer ikke
14.5.2010, 11:47
Vi kan bare bommet med en mus og kjørte den samme ...
Jeg skal prøve å simulere noe slikt hjemme. Da vil jeg avslutte abonnementet.
Vanligvis, før enhver farlig handling, i 1C (7.7. Eller 8-ke) trykker jeg på spørsmålstegnet (der banen til basen vises).
Her lo folket så minnelig av legenden min at jeg tvilte.
Selv om det er flere feil i åtten enn i de syv.
Å, her er en feil, ikke bare jeg så den.
Generelt spottet de en av de åttende basene på klienten, da jeg fortsatt jobbet i franchik.
En dag en person, en annen - den andre, den tredje gikk jeg. Jeg spurte dem - tok dere en sikkerhetskopi før bedriftene? Som svar ler de som hester, de scoret kortere, bare de tok basen på den bilen
14.5.2010, 12:35
- le som hester, scoret kortere, bare de tok basen lokalt,
og jeg hadde en sjanse til å knulle henne fra nettverket. Jeg bestemte meg for ikke å ta en sikkerhetskopi etter eksemplet med tidligere tavarisches,
han var ung og dum - mye show-off.
Generelt gjorde jeg endringer i konfaen, jeg lagrer konfaen, på tidspunktet for å lagre konfaen skjedde det en slags ulykke, og basen falt om kvelden. Sjokk. Om morgenen dro 3 spesialister, inkludert meg der.
Ulykken bestod i at slippnummeret ble revet av fra basen, d.v.s. i konfigurasjonen, når du klikket på spørsmålet, var det tomt, og navnet på selve konferansen manglet. og når i løpet av basen, var det heller ikke synlig, ikke en jævla ting, grensesnittet inkl. fløy av gårde, var det umulig å gå inn i dokumentjournalene.
Vi løste problemet ved å oppdatere den drepte databasen med en relativt fersk konfigurasjonsfil, alt ordnet seg.
Alt ble gjenopplivet.
Dette er et eksempel på en ekte legende. 3 personer skal ikke være buggy samtidig
14.5.2010, 13:53
på tidspunktet for lagring av konfigurasjonen skjedde en slags ulykke, og basen falt
Vel, hvis det var en jernfeil, så ikke rart.
Men hvis du fant en feil som vises stabilt etter å ha utført visse handlinger, så en annen samtale.
14.5.2010, 14:39
Vel, hvis det var en jernfeil, så ikke rart
xs det var. maskinvare, mesh eller plattform er ikke så viktig nå.
Det virker på meg som om softinaen ikke skal oppføre seg så fortryllende
Dette er det samme som å gi ut Vista, og innrømme at dette er dritt. Hvor raskt de hoppet fra 8,0 til 8,1
P.S. betydningen av ordet feil er tydelig for meg, takk for bekymringen)))
14.5.2010, 19:37
For eksempel, hvis en lignende "feil" oppstår når du ruller servicepakker eller noe viktig for samme Vista, er det sannsynlig at systemet da, hvis det starter, vil være ekstremt ustabilt.
Eller si, i øyeblikket du tar insulin, oppstår et jordskjelv, da kan diabetikeren gi opp, fordi sprøyten rullet under sofaen mens den ristet.
14.5.2010, 22:32
Born Killer, hvilken tråd er det på serveren? I så fall, prøv å deaktivere den eller legg til basen til unntakene
Hvordan kan antivirus påvirke bordlåser? base 8.x er én fil.
Jeg merket flere dokumenter for sletting i kopien, byttet til vinduet med en ekte database, jeg kunne ikke tro mine egne øyne: de samme dokumentene ble merket for sletting og der shok.gif
Generelt likte jeg ikke denne jævla toppen, siden da har jeg laget en kopi av databasen kun gjennom Last opp / Last ned.
Hvordan gjør du sir, en så trist legende?
Og hvis jeg ble revet med og gjorde mer alvorlige ting i kopien (for eksempel slette dokumenter merket for sletting), og på en eller annen uklar måte ble de samme handlingene utført i hoveddatabasen?
Nei, dette kan ikke være, mirakler skjer ikke. Du har sannsynligvis skrevet inn samme base ... I 8 kan du enkelt gå inn i databasen 2 ganger under samme navn.
jambs klatret med jevne mellomrom når du utfører / registrerer dokumenter med en feil i skjemaet
"Låsekonflikt under utføring av transaksjon: Kunne ikke låse tabellen" _DOCUMENT158 "
Så det første trinnet er å bestemme hvilket metadatadokument "_DOCUMENT158"-tabellen tilsvarer. For dette er det en metode for den globale konteksten "GetDatabaseStorageStructure". Så du vil i det minste forstå nøyaktig hvilket dokument som er "buggy".
Da må du forstå om noen endret modulen i den og banke på hodet hvis de endret den gjennom ett sted. Mest sannsynlig er registerpostsett skrevet eksplisitt via Write-metoden i stedet for å la plattformen gjøre det riktig. Og rekkefølgen deres er rotete ..
Og det er ingen vranglås?
Generelt bør 5 personer ikke holdes i filmodus. Subd kan tas gratis, kjøp kun nøkkelen til klyngeserveren og det er det. Eller er det dyrt for kontoret?
Jeg husker ikke om en teknologisk logg kan filmes i filmodus eller ikke ...
14.5.2010, 22:53
=========================================================
http://odines.ru/thread1386.html er dette tråden din?
Det vil si at transaksjonen ikke går gjennom selv når en bruker jobber? Da ligger nok ikke problemet i den skjeve koden ved registrering av bevegelser. Fordi det ikke kan være låser i enkeltbrukermodus. Opptaket gjøres sekvensielt.
Da ser det ut til at problemet nettopp ligger i brudd på strukturen til selve basen.
Det er bedre å først kjøre Testing og reparasjon av databasen med avmerkingsboksen "Restrukturering av infobasetabeller" aktivert.
Å laste opp til dt med påfølgende opplasting er også fornuftig ...
chdbfl.exe i dette tilfellet er usannsynlig å hjelpe ... selv om det selvfølgelig er verdt å prøve hvis resten ikke hjelper.
Jøss - akkurat nå så jeg på datoen for innlegg i tråden http://odines.ru/thread1386.html Og utviklingen av standard i en ny kontrollert modus er ikke langt unna.
Og forskjellen mellom 8.2 og 8.1 er mye større enn mellom 8.1 og 7.7, spesielt for utviklere må hjernen overhales for utvikling for en "kontrollert" driftsmodus
Hvor ofte ser du denne meldingen? Jeg tror alle som har lang erfaring med 1C har støtt på en slik feil minst én gang. Hvorfor gir programmet denne feilen? "Låse konflikt mens transaksjonen utføres: Kunne ikke låse bordet"?
Vel, oftest skjer dette på grunn av det faktum at en av brukerne allerede utfører en slags operasjon som har låst dette bordet. For å løse dette problemet trenger alle brukere bare å avslutte programmet. Men det hender også at brukeren forlot programmet, men programprosessen fra minnet blir ikke lastet ut. Ikke få panikk! Hvis alle brukere har avsluttet programmet, og meldingen fortsatt kommer ut, må du åpne menyen Verktøy -> Aktive brukere.
Og se hvem unntatt deg som jobber med programmet for øyeblikket. Hvis alle brukerne har gått, og du fortsatt ser at det er noen andre enn deg, ikke bli skremt. Det skjer. Prosessen henger. Start den aktive brukerens datamaskin på nytt.
Men noen ganger løser ikke det problemet. Det hender at et lys blinker på transaksjonstidspunktet, eller for eksempel en harddisk er på siste ben. Og det som også er sannsynlig, tok noen ut ledningen til nettverkshuben og satte på vannkokeren på sin plass, og i det øyeblikket beregnet du verdifallet. Så i slike øyeblikk kan databasen bli skadet eller dataene kan skrives med en feil.
I dette tilfellet, og nesten alltid, hvis oppskriftene ovenfor ikke hjalp, hjelper chdbfl.exe-verktøyet. Den ligger i mappen med den kjørbare 1C-filen. Banen til filen vil være noe sånt som "C: \ Program Files \ 1Cv82 \ platform_version_number \ bin \ chdbfl.exe". Vær oppmerksom på at dette verktøyet fra én versjon av plattformen kanskje ikke fungerer med en annen.
Derfor må du åpne en mappe med nummeret til den gjeldende plattformen du jobber på.
Hvordan kan jeg se plattformnummeret? Veldig enkelt. Vi går til menyen Tjeneste -> Om. Og videre viser bildet hvor man kan se på plattformnummeret.
Vi setter et hake for "fiks feilene som ble funnet". Og vi trykker på utfør-knappen. Dette verktøyet fikser 90 % av alle feil som oppstår. Jeg anbefaler på det sterkeste at du tar en sikkerhetskopi av databasen før du bruker dette verktøyet, men hvis det oppstår en feil akkurat på tidspunktet for lossing, kopier hele mappen med informasjonsdatabasen.
Ikke sjelden, når du jobber i 1C, oppstår feilen "Konflikt av låser ved utføring av transaksjoner: Maksimal ventetid for innvilgelse av lås er overskredet". Essensen ligger i det faktum at flere økter prøver å utføre lignende handlinger samtidig, og påvirker den samme ressursen. I dag skal vi finne ut hvordan vi fikser denne feilen.
Et stort antall operasjoner utført
Det første trinnet i å lete etter årsaker er å avklare hvor mange samtidige brukere som er i infobasen der en slik feil er utstedt. Som vi vet, kan det maksimale antallet av dem være ganske stort. Dette er tusen og fem tusen.
Mekanismen for låser og transaksjoner er beskrevet i utviklerveiledningen. De brukes når flere økter får tilgang til samme data samtidig. Det er logisk at de samme dataene ikke kan endres av forskjellige brukere i samme øyeblikk.
Du bør også sjekke om noen av brukerne har begynt å behandle for massedataendringer. Det kan være som å lukke måneden og lignende. I dette tilfellet, etter slutten av behandlingen, vil feilen forsvinne av seg selv.
Planlagte oppgaver
Det er ikke uvanlig at årsaken til feilen ligger i en stor mengde databehandling. Det anbefales at du gjør dette om natten. Planlegg disse planlagte jobbene utenom arbeidstiden.
Dermed vil begge brukerne jobbe i et stabilt system, og selve de planlagte oppgavene vil bli fullført, siden sannsynligheten for konflikter med brukerøkter vil reduseres.
"Henge økter"
Problemet med "stuck sessions" av brukere er kjent for nesten alle som har møtt 1C-tjenesten. Brukeren kunne ha gått ut av programmet for lenge siden, eller lukket et dokument, men økten hans forblir fortsatt i systemet. Problemet er oftest et enkelt og det er nok å avslutte en slik økt gjennom administratorkonsollen. De samme problemene kan oppstå med bakgrunnsjobber.
I følge en rekke kommentarer på Internett er slike situasjoner mer vanlige når du bruker nettverksbeskyttelsesnøkler. Hvis situasjonen med "hengende økter" gjentar seg systematisk, er dette en grunn til å kontrollere og vedlikeholde systemet og serverne grundig (hvis basen er klient-server).
Feil under skriving av konfigurasjon
Alle typiske konfigurasjoner er utviklet av kvalifiserte spesialister og eksperter. Hvert system er grundig testet og optimalisert for raskere og mer korrekt drift i det.
I denne forbindelse kan årsaken til feilen ligge i suboptimal kode skrevet av en tredjepartsutvikler. Dette kan være en "tung" forespørsel som vil blokkere data i lang tid. Det er også tilfeller av å bygge algoritmer med lav ytelse og logikkbrudd.
Det er høyst sannsynlig at låsekonflikten oppsto nettopp på grunn av utviklerfeil, hvis den oppsto etter at programmet ble oppdatert. For å sjekke kan du ganske enkelt "rulle tilbake" forbedringene, eller refaktorere koden.
Pasientsymptomer og historie:
Arbeidet til flere brukere over nettverket med samme fil (database) inkluderer en nettverksblokkeringsmekanisme. Dette tvinger systemet til å kaste bort dyrebar tid på å identifisere åpne opptaksøkter, og følgelig løse konflikter.
De viktigste tegnene på arbeidet med låser:
- raskt brukerarbeid med basen over nettverket i eksklusiv modus og ekstremt sakte - når flere brukere jobber samtidig
- raskt brukerarbeid med den lokale databasen på serveren og sakte - over nettverket
- filsystemet har tilgang til i underkant av 10 MB/s
Så, jeg fikk oppgaven - å gjøre det slik at så mange som tre brukere kan jobbe i 1C samtidig! Morsomt, ikke sant?
Jeg glemte alle vitsene da jeg så hva jeg måtte forholde meg til: en «server» i møte med en vanlig kontordatamaskin og to bærbare datamaskiner.
Lykken ville være ufullstendig hvis det ikke var for de fantastiske operativsystemene - på en datamaskin og på en bærbar Windows 7, på en annen - Windows 8.
Når du prøver å samtidig sende dokumenter på bærbare datamaskiner, en dum i omtrent et minutt, og den andre fløy ut av 1C med feilteksten "kunne ikke blokkere bordet ...".
Å lansere 1C på en bærbar PC er et eget show som varte i ca 3 minutter!
På mange ressurser kom jeg over råd om å bytte til jobb med terminaltilgang. Dessverre tillater ikke Windows 7 at den blir til en terminalserver ved å bruke standardverktøy - maksimalt én aktiv tilkobling. I dette tilfellet avsluttes ikke resten av øktene, du kan koble til på nytt under en annen bruker - "kaste ut" den forrige brukeren, men ikke avslutte økten hans. Derfor bør du overføre 1C til et server-OS, der det ikke er slike begrensninger. Kunden løste problemet på egen risiko ved å bruke et tredjepartsverktøy i stedet. Windows7_SP1_RDPhack.
Men eventyret sluttet ikke der. Selv i terminalforbindelsen gjensto betydelige bremser. Nok en gang hjalp de allmektige søkemotorene meg. Nedenfor er tipsene for å øke hastigheten på fil 1C, som jeg fulgte:
1. Deaktiver bruk av nettverksprotokoll IPv6, konfigurer adressering til "gammel" IPv4.
2. Legg til 1C-prosesser til Windows-brannmur-unntakene, så vel som til antivirus-unntakene, eller deaktiver dem helt (mer risikabelt, men en enkel test viste hastighetsøkning legge ut dokumenter på nytt med Avast antivirus deaktivert faktor av!)
3. Begynn å indeksere fulltekstsøk i 1C eller slå det av helt
4. Begynn å teste og fikse databasen, sjekk med ChDbfl-verktøyet
5. Kjør Config-kontrollelementet i konfigurasjonen (hvis konfigurasjonen ikke er typisk, kan dette være nyttig). Basert på resultatene av konfigurasjonssjekken, ble den på magisk vis redusert i størrelse med nesten en tredjedel. Hva og hvordan de kommende programmererne oppdaterte før meg - jeg fordypet meg egentlig ikke i det, men faktum er åpenbart.
6. Deaktiver unødvendige funksjonelle alternativer.
7. Konfigurer brukerrettigheter. (Dette og det forrige rådet virket dumt, helt til jeg så på gjengivelsen av administrerte skjemaer når jeg åpnet en liste over dokumenter. Jo mindre unødvendig i et administrert grensesnitt, jo raskere fungerer det vanligvis)
8. Begynn å beregne totalene på nytt og gjenopprette sekvensen (en betydelig økning kan bare være hvis totalene ikke har blitt gjenopprettet på lang tid)
9. Spesifiser "Tilkoblingshastighet - lav" i innstillingene til listen over baser (dette ga ikke mye resultat, bortsett fra at bildene av undersystemene ble deaktivert :))
Etter å ha fullført alle disse trinnene, begynte 1C-fildatabasen å fungere mye raskere. Den ble lansert på maksimalt 10 sekunder, og hastigheten på dokumentrepostering økte i gjennomsnitt 12 ganger.
Kanskje denne korte artikkelen vil være nyttig for deg hvis du plutselig trenger å øke hastigheten på 1C-filbasen.
P.S: Og å starte en fil 1C ved å bruke nettverkstilgang til en delt mappe er fortsatt urealistisk, fordi Hvis du gir den raskeste solid-state-stasjonen, vil RAM og prosessor bli begravd i nettverkslåser, og arbeidet til mer enn én bruker vil være praktisk talt umulig. Vi snakker spesifikt om konfigurasjonen av UT 11.1. Selvskrevne små konfigurasjoner kan fungere veldig raskt selv i filversjonen.
Tilføyelser fra kommentarer til publisering:
Diskdefragmentering med filbase
Konvolusjon base (kan være nyttig hvis basen er stor, for eksempel i flere år). Klientens base var ganske ung, så opprullingen var ikke praktisk.
Maskinvareoppgradering - raskere harddisk, ny bryter, prosessor, etc.
Installer på webserver, tilgang ved hjelp av en tynn klient. Her var meningene delte. Noen sier, mange ganger raskere, noen - at akselerasjon ikke er notert.
