1C Enterprise'i konfiguratsioonides on ajastatud ja taustaülesanded. Need tööd on planeeritud vastavalt iga töö graafikule. Mõned ülesanded täidetakse algselt taimeriga teatud arvu sekundite järel, mis võib jõudlust negatiivselt mõjutada ja selgelt segada infobaasis töötamist.
Ajastatud ja taustaülesannete muutmiseks administreerimiskaardil valige vasakult "Tavalised ja taustatoimingud". Kuvatakse olemasolevate ülesannete loend, nende olek, ajakava ja muu teave.
Kui klõpsate paar korda mis tahes ülesandel, avaneb aken selle ülesande omadustega. Siin saate oma maitse järgi muuta paljusid seadeid, sealhulgas selle ülesande ajakava. Ülesande keelamiseks tuleb märkeruut "Lubatud" eemaldada. Aga kui ülesanne on ajakava järgi töötada, on äärmiselt oluline kasutada kõigi taustatoimingute jaoks eraldi kasutajat, kellel on täielikud õigused.
Tööülesannete ajakava parameetrid on väga paindlikud, kuid siiski on soovitav seada kõik ülesanded nii, et korraga ja soovitavalt töövälisel ajal töötaks ainult 1 ülesanne. Erandiks võib olla vaid mitme seotud infobaasi sünkroonimine, näiteks ettevõtte raamatupidamine + palgaarvestus ja personalijuhtimine.
Panga klassifikaatori allalaadimine – pühapäev 4:30
Vahetuskursside laadimine - iga päev; 7:00
Tekstide väljavõtmine - iga päev; 6:00.
Sõnumid töövookontode jaoks – iga päev; iga 10800 sekundi järel.
Üksuste värskendamine - iga päev; alates 5:00:00 üks kord päevas
Raamatupidaja tööülesannete uuendamine - iga päev; alates 6:30:00 üks kord päevas
PPD indeksi uuendamine (täistekstiotsing) - iga päev; iga 10800 sekundi järel.
Agregaatide taastamine – iga päev, nädalapäevade kaupa [laupäev]; alates 3:00:00 üks kord päevas
Muudatuste keelu suhteliste kuupäevade praeguste väärtuste ümberarvutamine - iga päev; alates 7:00:00 üks kord päevas
Ühenda indeks PPD (täistekstiotsing) - iga päev; alates 4:00:00 üks kord päevas
Aegunud sünkroonimisteabe kustutamine - iga päev; alates 3:30:00 üks kord päevas
Arvutatud summade perioodi määramine - iga päev, kuu 5. kuupäeval; alates 1:00:00 üks kord päevas
Täistekstiotsingu mehhanism 1C-s võimaldab kiiresti leida vajaliku teabe. Seda tüüpi otsing on eriti tõhus, kui infobaasis on palju infot, samuti pole täpselt teada, kus kasutajat huvitavad andmed asuvad, või nagu sageli juhtub, pole nende täpne nimi teada. Täistekstiotsingu juhtakna avamiseks tehke järgmist: menüükäsk Operatsioonid Täistekstiotsingu haldamine .
Selles aknas on kolm nuppu: Seadistamine - Täistekstiotsingu lubamine/keelamine;
Uuenda indeksit – Indeksi loomine/indeksi uuendamine; Tühjenda indeks – indeksi nullimine (soovitatav pärast kõigi andmete uuendamist); lõik Luba indeksite liitmine – vastutab esmase ja teisese indeksi ühendamise eest.
Täistekstiotsing tehakse täistekstiindeksi abil. Indeksi puudumisel ei ole täistekstiotsing kui selline võimalik. Otsingu õnnestumiseks peavad kõik vajalikud andmed sisalduma täisteksti indeksis. Kui kasutaja sisestab andmebaasi uusi andmeid, tuleb need lisada kõnealusesse indeksisse, vastasel juhul ei osale ta otsingus. Selle vältimiseks peate uuendama täisteksti registrit. Värskendamisel analüüsib süsteem ainult teatud tüüpi andmeid: String, viiteandmed (lingid dokumentidele, juhenditele), Number, kuupäev, salvestusväärtused. Kui kasutajal ei ole teatud teabele juurdepääsuõigusi, siis ta seda otsingutulemustes ei näe. Samuti tuleb meeles pidada, et objektide atribuudid, mille järgi otsing tehakse, peavad olema seatud Täisteksti otsing – kasutamine, mis on vaikimisi määratud.
Nagu näete kinnisvara Kasutage seatud kogu kataloogi jaoks RegNumbrid , kuid seda saab teha ka iga selle vastavat tüüpi atribuudi puhul.
Vaatame lähemalt täisteksti indeksit, mis koosneb kahest osast (indeksitest): põhiindeks ja lisa . Suure andmeotsingu kiiruse tagab põhiindeks, kuid selle värskendamine on suhteliselt aeglane, olenevalt andmemahust. Täiendav indeks on selle vastand. Andmed lisatakse sellele palju kiiremini, kuid otsimine on aeglasem. Süsteem otsib mõlemat indeksit korraga. Suurem osa andmetest asub põhiindeksis, samas kui süsteemi lisatud andmed jõuavad teise indeksisse. Kuni teisese indeksi andmete hulk on väike, on selle kaudu otsimine suhteliselt kiire. Ajal, mil süsteemi koormus on madal, toimub indeksi liitmise operatsioon, mille tulemusena lisaindeks kustutatakse ja kõik andmed paigutatakse põhiindeksisse. Eelistatav on indekseid liita ajal, mil süsteemi koormus on minimaalne. Sel eesmärgil saate luua reguleeritud ülesandeid ja ajastatud ülesandeid.
Vaatleme indeksi automaatse värskendamise juhtumit rakenduse käivitamisel. See ümbris sobib ühe kasutaja andmebaaside jaoks (ühe kasutaja andmebaasid võivad olla sellised tooted nagu 1C raamatupidamise alus, 1C lihtsustatud), kuna suure hulga kasutajate puhul toimub värskendus pärast iga kasutaja rakenduse käivitamist, mis mõjutab oluliselt süsteemi jõudlust.
Kõigepealt loome ühise mooduli ja kutsume seda näiteks PP. Kirjutame sellesse järgmise protseduuri:
Protseduur UpdateIndexes() Eksport
FulltextSearch.UpdateIndex();
Lõppprotseduur
Lihtsalt määrake omadused nagu joonisel.
Seejärel paremklõpsake konfiguratsioonipuus konfiguratsiooni nimel ja käivitage käsk Avage hallatud rakenduse moodul. Valige ülaltoodud väikeses aknas eelmääratletud funktsioon Enne süsteemi käivitamist ja sisestage sellesse protseduuri järgmine rida:
UpdateFullTextSearch.UpdateIndexes();
Salvestame tehtud muudatused. Seega uuendatakse indeksit automaatselt pärast iga rakenduse käivitamist.
Mõelge nüüd juhtumile, kui kasutajaid on mitu. Siin kasutame Reguleerimisülesanded ( konfiguraatori režiimis: konfiguratsioonipuus – Üldine – Regulatiivsed ülesanded). Sel juhul oleme huvitatud ainult kahest ülesandest: Uuenda FullTextSearchIndex ja MergeFullTextSearchIndex. Valige nende ülesannete atribuutides Ajakava ja klõpsake lingil Avatud.
Seadistage mõlema ülesande jaoks ajakava. Sel juhul pole seadistussoovitusi, siin määratakse seadistus süsteemi toimimise funktsioonide (koormus, teabe hulk, selle värskendamise sagedus jne) põhjal. Ülesanded ise ei tööta, meil peab olema režiimis töötav programmiseanss Ettevõtted kes nende ülesannete eest vastutab. Tuleb kohe märkida, et seda valikut kasutatakse failisüsteemi jaoks. Sellel seansil peab toimuma ootetöötlus, mis käivitab 1-keelse meetodi kutse. See töötlemine näeb välja selline:
Lülitume Enterprise režiimi ja teeme järgmist: Käivitage meie töötlemine, mida sel juhul kutsutakse iga 5 sekundi järel ja mis omakorda kutsub välja meetodi "ExecuteJobProcessing()". See meetod kontrollib, kas on aeg töid nende ajakava järgi täita. Järgmisena minge menüüelemendi juurde Toimingud – Konstandid – Programmi sätted – Vahekaart Andmevahetus.
Määrake täitmise eest vastutav kasutajaseanss ja määrake ajastatud toimingute jaoks küsitlusintervall. Sellel seansil ei ole soovitatav töötada, kuna see võib mõjutada süsteemi jõudlust. Ka ITS-ketastel on töötlus " Käivitage Regulaarsed ülesanded”, mis sunnib käivitama ajastatud toiminguid kasutaja valikul. Selle töötlemise vorm on järgmine:
Seega on kõik ettevalmistustööd tehtud ja saate otse andmete otsimise enda juurde minna.
Täistekstiotsinguga töötamise alustamiseks peate täitma järgmise käsu: menu Teenus à Andmete otsing.
Seejärel ilmub järgmine aken:
Klõpsates nupul Seaded, ilmub väli lisaseadetega, näiteks: Otsingu ulatuse piirang, Hägusus, Portsjon(antud juhul väärtus = 5, mis tähendab viit otsingutulemust lehe kohta). Parameeter Hägusus tähistab mõne otsingupäringu märgi ja otsingu käigus saadud teabe mittevastavust. Hägusus määrata protsendina.
Täistekstiotsing võib kasutada järgmisi operaatoreid:
Lisaks võimaldab täistekstiotsingu mehhanism kirjutada mõned venekeelse sõna tähemärgid üheklahviliste ladina tähtedega. Otsingutulemused ei muutu.
Klient-server versioonis vastutab ülesannete täitmise ajastamise eest ülesannete planeerija.
Tegumiplaneerija on serveri aktiivne komponent, st. olenemata kliendiühenduste olemasolust serveriga, suudab see ajastatud ülesandeid täita. Planeerija aktiivsus on eriti märgatav, kui see küsitleb järjestikku kõigist teabebaasidest, kas neis on ajastatud toiminguid. Planeerija saab konkreetse teabebaasi küsimise edasi lükata, kui teabebaasis on ühenduseplokk või ajastatud toiminguplokk.
Ajastaja praegune ajastatud ülesannete loend võib automaatselt muutuda (näiteks kui luuakse uus ajastatud ülesanne või kustutatakse olemasolev ajastatud ülesanne). Igal juhul tagab ülesannete mehhanism, et planeerija ajastatud ülesannete loend on ajakohane ja ühtib klastri teabebaasides olevate ajastatud ülesannete loenditega.
Kui plaanitud tööde esialgne loend on edukalt vastu võetud, kontrollib planeerija perioodiliselt, kas taustatööde käivitamiseks on taotlusi ja kas plaanitud töid tuleb nende ajakava järgi täita. Pärast seda, kui töövoog on ülesande vastu võtnud, loob töövoog ühenduse teabebaasiga ja täidab ülesande selles ühenduses. Kuna töövoog on optimeeritud mitme kasutajaga tööks, on ainult esimene teabebaasi ühenduse loomine kulukas toiming. Järgmiste ühenduste loomine sama infobaasiga võtab oluliselt vähem aega ja ressursse, sest enamik sisemistest andmestruktuuridest on jagatud sama teabebaasi ühenduste vahel. Pärast töö käivitamist teavitab töövoog planeerijat töö õnnestumisest või ebaõnnestumisest. Tarkvara tõrke korral saab planeerija ajastatud toimingu taaskäivitada (kui tõrge ilmnes taustaülesande täitmisel, siis seda ei taaskäivitata).
Aitäh!
Täisteksti otsing- võimaldab leida tekstilist teavet, mis on paigutatud peaaegu kõikjale kasutatavas konfiguratsioonis. Samal ajal saate otsida vajalikke andmeid kas kogu konfiguratsioonist tervikuna või kitsendada otsinguala mõnele objektile (näiteks teatud tüüpi dokumentidele või kataloogidele). Otsingukriteeriumid ise võivad varieeruda üsna laias vahemikus. See tähendab, et leiate vajalikud andmed, isegi kui ei mäleta täpselt, kus need konfiguratsioonis on salvestatud ja kuidas need täpselt salvestatakse.
Täistekstiotsing pakub järgmisi funktsioone:
- Toetatakse transliteratsiooni (venekeelsete sõnade kirjutamine ladina tähtedega vastavalt standardile GOST 7.79-2000). Näide: "Vene fraas" = "Vene fraza".
- Toetatakse asendamist (osa märkide kirjutamine vene sõnadega üheklahviliste ladina tähtedega). Näide: "russrfz frapf" (iga sõna lõpud trükitakse näiteks operaatorivea tõttu ladina keeles).
- Võimalik on uduotsing (leitud sõnade tähed võivad erineda) koos hägususläve näitamisega. Näide: määrates otsingustringis sõna "tere" ja udususe 17%, leiame kõik sarnased sõnad vigadega ja ilma: "tere", "tere", "too".
- Valitud metaandmeobjektide jaoks on võimalik määrata otsingu ulatus.
- Standardväljade nimede täisteksti indekseerimine ("Kood", "Kirjeldus" jne) toimub kõigis konfiguratsioonikeeltes.
- Otsing tehakse vene, inglise ja ukraina keele sünonüüme arvesse võttes.
- Vene keele morfoloogiline sõnastik sisaldab mitmeid konkreetseid sõnu, mis on seotud tegevusvaldkondadega, mis on automatiseeritud programmisüsteemi 1C:Enterprise abil.
- Standardina sisaldavad tarnitavad sõnastikud sõnavara andmebaase ja tesauruse sõnastikke ning vene, ukraina ja inglise keele sünonüüme, mida pakub Informatik.
- Saate otsida kasutades metamärke ("*"), samuti määrates otsinguoperaatoreid ("AND", "OR", "NOT", "NEAR") ja erimärke.
Täistekstiotsingut saab teha mis tahes konfiguratsioonis platvormil 1C: Enterprise 8
Täistekstiotsingu juhtakna avamiseks tehke järgmist.
Üldine rakendus- menüüelement Toimingud – täistekstiotsingu haldamine.
Hallatud rakendus- menüüelement Peamenüü - Kõik funktsioonid - Standardne -Täistekstiotsingu haldamine.
- Uuenda indeksit– indeksi loomine/indeksi uuendamine;
- Tühjenda indeks– indeksi nullimine (soovitatav pärast kõigi andmete uuendamist);
- üksus Luba indeksite liitmine- vastutab põhi- ja lisaindeksi ühendamise eest.
Täistekstiotsing tehakse täistekstiindeksi abil. Indeksi puudumisel ei ole täistekstiotsing kui selline võimalik. Otsingu õnnestumiseks peavad kõik vajalikud andmed sisalduma täisteksti indeksis. Kui kasutaja sisestab andmebaasi uusi andmeid, tuleb need lisada kõnealusesse indeksisse, vastasel juhul ei osale ta otsingus. Selle vältimiseks peate uuendama täisteksti registrit. Uuendamisel analüüsib süsteem ainult teatud tüüpi andmeid: string, viitetüüpi andmed (lingid dokumentidele, kataloogidele), number, kuupäev, väärtuste salvestus. Kui kasutajal ei ole teatud teabele juurdepääsuõigusi, siis ta seda otsingutulemustes ei näe. Samuti tuleb meeles pidada, et objektide atribuudid, mille järgi otsing tehakse, peavad olema seatud Täisteksti otsing – kasutamine, mis on vaikimisi määratud.
Nagu näete kinnisvara Kasutage seatud kogu kataloogi jaoks Vastaspooled, kuid seda saab teha ka iga selle vastavat tüüpi atribuudi puhul.
Vaatleme üksikasjalikumalt täisteksti indeksit, mis koosneb kahest osast (indeksist): põhiindeksist ja lisaindeksist. Suure andmeotsingu kiiruse tagab põhiindeks, kuid selle värskendamine on suhteliselt aeglane, olenevalt andmemahust. Täiendav indeks on selle vastand. Andmed lisatakse sellele palju kiiremini, kuid otsimine on aeglasem. Süsteem otsib mõlemat indeksit korraga. Suurem osa andmetest asub põhiindeksis, samas kui süsteemi lisatud andmed jõuavad teise indeksisse. Kuni teisese indeksi andmete hulk on väike, on selle kaudu otsimine suhteliselt kiire. Ajal, mil süsteemi koormus on madal, toimub indeksi liitmise operatsioon, mille tulemusena lisaindeks kustutatakse ja kõik andmed paigutatakse põhiindeksisse. Eelistatav on indekseid liita ajal, mil süsteemi koormus on minimaalne. Sel eesmärgil saate luua reguleeritud ülesandeid ja ajastatud ülesandeid.
Otsinguavaldise määramisel on lubatud kasutada erioperaatoreid
Täistekstiotsingu mehhanism võimaldab kirjutada osa venekeelse sõna tähemärkidest üheklahviliste ladina tähtedega. Otsingutulemused ei muutu.
Kaks operaatorit kõrvuti
- lihtsustatud. 8 sõna vahega
- NEAR/[+/-]n – andmete otsimine ühest atribuudist n-1 sõna kaugusel.
Märk näitab, millises suunas alates esimesest sõnast teist sõna otsitakse. (+ - pärast, - enne)
Metamärki "*" saab kasutada ainult sõna lõpu asendusena
Hägune operaator "#". Kui nime täpne kirjapilt pole teada.
Tarkvara tööriistad ja tööriistad 1s: programmeerimine.
Sünonüümoperaator "!". Võimaldab leida sõna ja selle sünonüüme
Kuidas programmiliselt uuendada täisteksti otsinguindeksit?
Kood 1C v 8.x Protseduur UpdateIndexes() EksportFulltextSearch.UpdateIndex();
Lõppprotseduur
Täisteksti andmete otsimise näide
Muutuja definitsiooni otsinguloend
Kood 1C v 8.x Muutujate otsinguloend;
Lisaks defineerime sündmuse töötlemise protseduuris Vormi avamisel, et see muutuja sisaldab täisteksti otsinguloendit, mille abil otsime andmetest
Kood 1C v 8.x Protseduur OnOpen()
SearchList = FullTextSearch.CreateList();
Lõppprotseduur
Nüüd, kui klõpsate nupul Otsi, kirjutame koodi, mis võimaldab meil otsida vastavalt väljal SearchExpression määratud väljendile
Kood 1C v 8.x Protseduur FindClick (element)
SearchList.SearchString = SearchExpression;
Katse
Otsinimekiri.FirstPart();
Erand
Hoiatus(ErrorDescription());
Katse lõpp;
Kui SearchList.TotalCount() = 0 Siis
FormElements.MessageOResult.Value = "Ei leitud";
FormElements.SearchResult.SetText("");
Muidu
PrintSearchResult();
EndIf;
Lõppprotseduur
Esiteks määrame selles protseduuris kasutaja sisestatud otsinguavaldise täistekstiotsingu otsingustringiks. Seejärel käivitame meetodi FirstPart(), mis tegelikult käivitab täistekstiotsingu ja tagastab esimese tulemuste partii. Vaikimisi sisaldab osa 20 üksust. Pärast seda analüüsime otsinguloendis olevate elementide arvu. Kui see ei sisalda ühtegi elementi, kuvame vormil vastava teate. Vastasel juhul kutsutakse välja protseduur OutputSearchResult(), mis kuvab tulemused kasutajale.
Loome vormimoodulis samanimelise protseduuri ja kirjutame sinna koodi,
Kood 1C v 8.x Protseduur DisplaySearchResult()
FormElements.MessageORsult.Value = "Näidatud" + String(Otsinguloend.Alguspositsioon() + 1) + " - " + String(Otsinguloend.Alguspositsioon() +Otsinguloend.Arv()) + "from" + SearchList.FullCount();
Tulemus = SearchList.GetDisplay(FullTextSearchDisplayType.HTMLText);
FormElements.SearchResult.SetText(Result);
AccessibilityButtons();
Lõppprotseduur
Selle protseduuri sammud on lihtsad. Esiteks moodustame sõnumi selle kohta, milliseid elemente kuvatakse ja kui palju elemente kokku leiti. Seejärel saame täistekstiotsingu tulemuse HTML-teksti kujul ja kuvame selle teksti vormil asuva HTML-dokumendi väljale.
Lõpuks anname juhtimise üle protseduurile ButtonsAccess(), et teha kättesaadavaks või, vastupidi, keelata juurdepääs nuppudele Eelmine osa ja Järgmine osa (olenevalt sellest, millist tulemuste osa kuvatakse). Selle protseduuri tekst on esitatud koodeksis
Kood 1C v 8.x nuppude juurdepääsetavuse protseduur ()
FormElements.NextPortion.Availability = (SearchList.FullCount() - SearchList.StartPosition()) > SearchList.Quantity();
FormElements.PreviousPortion.Availability = (SearchList.StartPosition() > 0);
Lõppprotseduur
Nüüd peate nuppude PreviousPortion() ja NextPortion() vajutamiseks looma sündmuste käitlejad.
Kood 1C v 8.x Protseduur PrevPartPress (Element)
Otsinimekiri.EelminePart();
PrintSearchResult();
Lõppprotseduur
Protseduur NextBatchClick (üksus)
Otsinimekiri.NextPart();
PrintSearchResult();
Lõppprotseduur
Viimane puudutus on vormil asuva HTML-dokumendi välja onclick sündmuse jaoks sündmuste käitleja loomine. Fakt on see, et täistekstiotsingu tulemus, mis esitatakse HTML-tekstina, sisaldab hüperlinke otsinguloendi elementide arvule. Ja me soovime, et süsteem avaks selles loendielemendis sisalduva objekti vormi, kui kasutaja sellel lingil klõpsab. Selleks peatame HTML-dokumendi väljal oleva HTML-dokumendi onclick sündmuse, saame hüperlingilt loendi üksuse numbri ja avame vastava objekti vormi. Koodis esitatakse HTML-dokumendi välja onclick sündmuste töötleja tekst
Kood 1C v 8.x ProcedureSearchResultonclick (Element, pEvtObj)
htmlElement = pEvtObj.srcElement;
// Kontrollige elemendi ID-d
Kui (htmlElement.id = "FullTextSearchListItem") Siis
// Hangi faili nimi (otsingunimekirja rea number),
// sisaldub hüperlingis
NumberInList = Number(htmlElement.nameProp);
// Hankige otsinguloendi string numbri järgi
ValitudRida = Otsinimekiri[loendinumber];
// Avage leitud objekti vorm
OpenValue(SelectedRow.Value);
pEvtObj.returnValue = Väär;
EndIf;
Lõppprotseduur
Artikli pealkirjas tõstatatud küsimus on asjakohane paljude selle tootega töötavate süsteemiadministraatorite jaoks. Võimaluse piires püüame rääkida parameetritest, mis mõjutavad 1C jõudlust, ja kummutada populaarseid müüte. Täna tahame ühe hiljutise juhtumi näitel rääkida veel ühest aspektist, mis võib jõudlust tõsiselt mõjutada – ajastatud ülesannetest.
Alustame reaalse juhtumiga. Mitte nii kaua aega tagasi pöördus üks meie klient meie poole kaebusega ühe oma töötaja 1C "pidurite" kohta. Sümptomid väljendusid selles, et teatud aja möödudes hakkas Trade Management 10 konfiguratsioon kõvasti aeglustuma ehk siis jäi mõnda aega rippuma.
Olukorda üksikasjalikumalt analüüsides selgus, et seda juhtub ainult ühe töötajaga ja igal töökohal, pikka aega, kuid kui varem kestsid "pidurid" umbes sekundi, siis nüüd, pärast värskendust, need võivad kesta kuni 15-20 sekundit, mis muudab töö äärmiselt ebamugavaks.
Põhimõtteliselt piisab juba esialgsetest andmetest esimeste järelduste tegemiseks. Võtame need uuesti:
- "Pidurid" toimuvad pidevalt, teatud sagedusega
- "Aeglustab" ainult ühe kasutaja jaoks
- "Aeglustab" igal töökohal
Oma oletuste kinnitamiseks vaatame Raamatupidamisseaded:
Tõepoolest, "probleemne" kasutaja on loetletud rutiinsete ülesannete täitmiseks. Nagu selgus, töötas kunagi selle kasutaja nimel RIB-i automaatvahetusülesanne. Jääb üle vaadata, mis täpselt oli episoodilise "pidurdamise" põhjuseks. Seda on ka lihtne teha:
Ja siin on "sündmuse kangelane" - ülesanne värskendada täisteksti otsinguindeksit, mis käivitati iga 2,5 minuti järel. Sel juhul lahendati probleem täielikult, keelates sellel kasutajal ajastatud ülesannete täitmise, kuid see ei ole alati võimalik või soovitatav, seega vaatleme allpool, kuidas ajastatud ülesandeid saab hallata ja kuidas tagada, et neil ei oleks negatiivne mõju jõudlusele.
Üldine rakendus
Tavarakendusel põhinevates konfiguratsioonides pole ajastatud toimingute haldamiseks ühtset tööriistakomplekti. See on suuresti tingitud asjaolust, et nende esialgse väljatöötamise ajal oli menetlusülesannete kontseptsioon üsna nõrk.
Paljusid ajastatud ülesandeid hallatakse nendega seotud alamsüsteemide konfiguratsiooni kaudu. Näiteks andmevahetusega seotud rutiinsete ülesannete seadeid tuleks otsida ühtse riigi automatiseeritud infosüsteemiga seotud vahetusseadetest alkoholikaubanduse seadetes jne.
Esmapilgul on kõik üsna loogiline, kuid ühe tööriista puudumine muudab konfigureeritud ajastatud ülesannete ja nende seadete optimaalsuse juhtimise keeruliseks. Noh, kui ülesandeid on üks või kaks ja kui neid on rohkem või, nagu meie puhul, kahtlustatakse mõnda ajastatud ülesannet, kuid teil pole õrna aimugi, kes ja mis selles andmebaasis üles seadis.
Sel juhul peaksite kasutama välist töötlemist ConsoleQuests (JobsConsole), mis sisaldub standardtöötluse komplektis ITS-kettal. Töötlemine pakub kõigi tööde jaoks ühtset liidest ja võimaldab neid tsentraalselt konfigureerida, samuti juhtida hetkel töötavaid töid.
Seda nimekirja tuleks hoolikalt uurida, kõik mittevajalikud ülesanded välja lülitada ja vajalikud ajastada vastavalt kiireloomulistele vajadustele ja tervele mõistusele. Näiteks meie puhul pole vaja EGAIS-i vastuseid töödelda üks kord iga 30 sekundi järel (see seadistus on tehtud testimiseks) ja töörežiimis piisab sellest näiteks kord poole tunni jooksul.
Hallatud rakendus
Hallatud rakendusel põhinevates konfiguratsioonides mängivad olulisemat rolli ajastatud toimingud, neid saab kasutada erinevate toimingute tegemiseks teabebaasi hooldamiseks ja ajakohasena hoidmiseks, kuid samal ajal põhjustavad kõige sagedamini ajastatud ülesanded " pidurid".
Rutiinsete ülesannete haldamiseks on menüüs hotelliüksus Administreerimine – tugi ja hooldus.
Võib kohe märkida, et ülesanded on oluliselt suurenenud (näiteks võtsime sama konfiguratsiooni - Jaemüük) ja nende pädev konfiguratsioon võib oluliselt parandada infobaasi jõudlust. Vaikesätted teeb 1C keskmise sfäärilise ettevõtte vajadustest lähtuvalt vaakumis ega ole optimaalsele lähedalgi.
Esiteks keelame selle, mis on selgelt ebavajalik, millega te ei tööta. Seejärel optimeerime harva kasutatavate funktsioonide ajakava, näiteks pangaklassifikaatori uuendamist Jaekaubanduses, samuti vastaspoolte kontrollimist saab teha kord nädalas töövälisel ajal või tööpäeva lõpus (alguses).
Erilist tähelepanu tuleks pöörata kõigele, mis on seotud otsinguindeksiga. Täistekstiotsing on kindlasti mugav asi, kuid selle indeksiga töötamine on väga-väga ressursimahukas ülesanne. Seetõttu ei tohiks minna äärmustesse ja sellest loobuda, vaid tuleks selle parameetrid tõsiselt üle vaadata ja kohendada.
Alustame sellest teksti väljavõte, võimaldab see toiming otsida manustatud failide sisust, nii et kui te neid ei kasuta, ei otsi neid või teil on seal ainult pilte, saab selle toimingu keelata, igal juhul tehke seda üks kord 85 sekundit – selge loetelu.
PPA indeksi värskendus- üks ressursimahukamaid toiminguid, vaikimisi tehakse seda kord minutis.
Mõelgem nüüd sellele, kui sageli lisatakse või uuendatakse teavet teie kõige sagedamini otsitavasse andmebaasi? Ilmselgelt mitte iga minut, seega piisab indeksi värskendamisest palju harvemini: kord tunnis, kord päevas või isegi kord nädalas.
Sama kehtib ka PPD indeksi ühinemine, kui värskendate indeksit üks kord päevas, peaksite ühendamise määrama kord nädalas, valides töö alguseks kõige vähem häiriva aja.
Need lihtsad toimingud võimaldavad teil tõsta sellega töötamise mugavuse uuele tasemele, ilma et see kahjustaks konfiguratsiooni funktsionaalsust, keeldudes sageli tegemast üsna ressursimahukaid toiminguid. Ärge minge äärmustesse, otsustage õigesti, kui palju teatud funktsioone vajate ja kui sageli peaksite nendega seotud ülesandeid täitma.
Sildid:
Küsimus: 1C indeksi taastamine
Tere pärastlõunal, SQL 2014 kohta on olemas SCP andmebaas, seal on rutiinsed ülesanded:
1)
2)
Kõik töötas alguses ideaalselt, midagi ei pidurdanud, poolteist kuud möödus ja pidurid hakkasid käima. Installisin uuesti 1C, SQL, 1C serveri lootuses, et olen midagi valesti seadistanud, aga jamb jäi alles. vaatas aruannet
Ma näen killustatust, see ei lähe läbi indeksi ümberehitamise ja ümberkorraldamise. Kas on mingeid võimalusi normaalse töö taastamiseks ja killustatusest vabanemiseks?
(Võib-olla on see jama, mis pidureid ei mõjuta?)
Vastus: ()
Küsimus: SQL ja indeksi killustatus
Statistikat kogudes näitab see, et üle saja indeksi vajab ümberehitamist, nende killustatus on üle 50%, kuid pärast indeksite ümberehitamist jääb killustatus samaks, mida teha?
Vastus: ok aitäh ma õpin
Küsimus: Indeksi kustutamise tagajärjed
Hea kellaaeg. Seal on SQL-vormingus andmebaas 1C, millele peate tegema TII, mida ei tehta, mis annab järgmised vead:
Ma ei saa kindlaks teha, milliste 1C andmetega on ülaltoodud tabelid seotud. Mis võib viga olla, kui jätan ülaltoodud indeksid pukseerimisindeksi kaudu maha?
Ma ei ole teema autor.
Kõik käsud saadab 1s sql serverisse, indeksid luuakse ja kustutatakse.
tulnukas - kui me ei loo indekseid läbi konfiguraatori, vaid sql serveris ise.
tavaprotseduuri 1s käigus loodud indeks ei erine sql-serveri loodud indeksist
Küsimus: kuidas õigesti konfigureerida protseduure "PPD indeksi värskendamine" ja "PPD indeksi ühendamine" (Loe 19
Vastus:
Küsimus: küsimused indeksite kohta 1s
Millistel juhtudel on parem neid kasutada? kui palju võib põhi sagedase kasutamise korral paisuda? mis vahe on: indeksid ja indeksid koos add. tellimine.
Võite linkida ka tavalisi näiteid.
Aitäh.
Vastus:() Indeksid võivad olla suuremad kui andmete suurus :)
() Mulle tundub, et indeksite suurus ei ole nende peamine miinus, olulisem on see, et "lisa" indeksite puhul on "lisa" salvestamise kulud. MINU ARVATES.
Aga suurte (sadade või tuhandete GB) andmebaaside puhul tuleb muidugi ka suurust vaadata :)
Üldine põhimõte - kui sellel väljal on valikud - indekseerime, kui valikuid pole - me ei indekseeri. Kui välja jaoks on vaja valikut, kuid ridade arv on väike, pole indeksit vaja. Kui välja jaoks on vaja valikut, kuid selle alla mahub peaaegu kogu tabel, pole indeksit vaja. MINU ARVATES.
Küsimus: Väärtustabeli indeksid
Vastus:
Küsimus: Juurdepääs PM-elemendile indeksi järgi
Seadsime õppeülesandeks sorteerida PM dokumenti mitte sisseehitatud funktsiooniga, vaid käsitsi mingi algoritmi järgi.
Huvitav, kas PM-elemendile on võimalik ligi pääseda indeksi järgi?
Vastus: Tabeliosaga sama tähendus.
Kopeeri-kleebi SP-st:
Tabelijaotis
Kollektsiooni elemendid:
Tabelirida
Objekti puhul on võimalik läbida kogu, kasutades operaatorit For Every ... From ... Loop. Läbimine valib kollektsiooni elemendid.
Kogu elemendile on võimalik juurde pääseda operaatori [...] abil. Stringi indeks (nummerdatud alates 0) edastatakse argumendina.
Küsimus: pärast platvormi värskendamist läks otsinguindeksi värskendamise reg töös tõrge
osadele serveritele installitud 12.1616, kõik on korras, aga konsolideerimisega server hakkas kohutavalt üles ütlema, 2...3 minuti pärast kukuvad rhostid välja...
Sain teada, et kõiges oli süüdi reg ülesanne "täistekstiotsingu indeksi värskendamine", kuni see välja lülitati ...
samal ajal tavalistel rindadel - tundub, et probleem ei ilmne
küsimused
1. Kellel veel see probleem on?
2. kuidas otsida üksikasjalikku põhjust
3. mida teha
Vastus: Ma pole päris keevitaja, aga prooviks keelaks kõik tööreeglid peale "täistekstiotsingu indeksi uuendamise" ja vaataks seda läbi tehnilise logi.
Küsimus: SQL-spetsialistid – kuidas üldised üksikasjad indeksi statistikat mõjutavad?
Küsimus: Kui aeganõudev on andmete eraldamise tavaliste detailide konfiguratsioonist välja lõikamine? Kas seda tasub üldse teha?
BSP vaatas, üldiselt ei tundu, et väga palju kohti oleks, aga süvaõppeks polnud aega.
Ja nüüd – põhjustest, miks see mind huvitab.
BP 3.0 andmebaas, umbes 1 TB suurune, millest 200 GB on raamatupidamisregistri tabelid, kirjeid 50 kuni 250 miljonit. Serveris olevates tabelites on Data AreaMainData väljal Numeric (7,0) tüüpi, seega globaalselt I ruumi ei säästa (sellele väljale jääb praegu umbes 9 GB).
Peamine eesmärk on andmebaasiga töötamist veidi kiirendada, kuna:
*tabelite ja indeksite suuruse vähendamine; * valiku kiirendamine andmerea (ja indeksite) suuruse ja täpsemate päringuplaanide vähendamise kaudu; * 'uuenda statistika' käsu kiirendamine; * veerustatistika pidamise kulu vähendamine (võib-olla ei pea mõne välja puhul seda üldse eraldi pidama, sest see väli jääb registris kõige vasakpoolsemaks).
Ühe rea toimingu pisut kiirendamine miljonite ridade osas annab märkimisväärse aja kokkuhoiu. Ja aasta arvestuses - isegi rohkem, nii et mulle tundub, et eesmärk on õigustatud.
Ja väike teooria, millel ma toetun.
On üldteada, et MSSQL loob statistikat ainult kõige vasakpoolsemas indeksi veerus ja salvestab sinna 200 väärtuste jaotusintervalli.
Standardse raamatupidamise 3.0 indeksites on vasakpoolne veerg "DataAreaMainData", tippige Number. Kui eraldamist ei kasutata, on see väli kõikjal null. Allpool on näide sellisest indeksist (raamatupidamisregistrist). 49 miljonit kirjet, mis kõik on koondatud histogrammi ühele reale.
Server loob veergude statistika kõigi päringutes osalevate väljade kohta
Näiteks registripidaja sõnul