Zdravo svima!

Pre neki dan na poslu sam naišao na problem zaključavanja, odnosno na poruku „Postoji sukob zaključavanja prilikom izvršavanja transakcije Maksimalno vrijeme čekanja za odobravanje zaključavanja je prekoračeno.

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 budete otpušteni. Odlučio sam da krenem drugim putem.

Prvi dan - problem se pojavio u toku dana, isprva se činilo da je problem sa udaljenim korisnikom koji se prijavio u konfigurator. Izgledalo je kao da je izvršenje jednostavno stalo u jednom trenutku, a blokiranje, naravno, nije uklonjeno. Nakon par sati uspjeli smo pustiti konfigurator, ali problem nije nestao. Bilo je krajnje nepoželjno nasilno ubiti konfigurator, možda su radili u njemu. Nakon toga, Google je ušao u igru. 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. Zatim su uslijedili pokušaji postavljanja tehnologije. magazin. Postavite, šta dalje? Za 15 minuta, par svirki trupaca! Kako ih čitati, šta tražiti? Nepoznato.

Našao sam članak o tome kako vidjeti što je blokirano pomoću SQL Trace-a. Čak i ako ga nađem, šta dalje? Treba mi sesija!

Bliže 16:00, kada sam shvatio da ne mogu više čekati, napravio sam restart. U nadi da se ovo više neće ponoviti (a to je bilo prvi put u šest mjeseci rada), odahnula 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, doći ću mirno kući i sjediti i kopati. Dođem kući, sve je u redu. Nažalost.

Trećeg dana sam gledao webinar, pričali su o zanimljivom i efikasnom načinu pronalaženja problema. Sjetio sam se, ali problem se više nije pojavio. Prošla je sedmica i evo je - ponovo blokade! Trljam ruke i počinjem djelovati.

Prvo, postavite dnevnik. Da, ne mogu bez njega, ali sada znam kako da ga čitam. Postavljamo dva događaja: prvi je TLOCK, drugi je TTIMEOUT. Prvi prikazuje sve događaje blokiranja, drugi prikazuje događaje blokiranja koji nisu mogli biti instalirani u zadanom vremenu. U stvari, najvjerovatnije je dovoljno samo TTIMEOUT.

Kopiramo datoteku tehničkog dnevnika na određeno mjesto, uletimo u program, pozovemo bravu, primimo poruku i uklonimo 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 - neuspješna i još neka. Sesija na koju je tehnički časopis ukazivao je pala. I eto! Sve je upalilo, radosti nema granica! Ali, kako se kasnije ispostavilo, sesija nije bila zamrznuta :), radili su u njoj. Stoga je ubuduće preporučljivo kontaktirati korisnika i upozoriti.

Po mom mišljenju, prilično standardno rješenje za prilično standardan problem. Ne zna se zašto nisam naišao, možda zato što sam morao da ga tražim iz alarma, a kada ga korisnici nisu pritisnuli, nije bilo moguće izvršiti testove - nije bilo greške.

Nije neuobičajeno da kada radite u 1C dobijete grešku „Konflikt zaključavanja prilikom izvršavanja transakcija: Maksimalno vrijeme čekanja za odobravanje zaključavanja je prekoračeno.“ Njegova suština leži u činjenici da nekoliko sesija pokušava istovremeno izvršiti slične radnje, utječući na isti resurs. Danas ćemo shvatiti kako popraviti ovu grešku.

Urađen veliki broj operacija

Prvi korak u traženju razloga je da se razjasni koliko je istovremenih korisnika u bazi podataka u kojoj je takva greška generisana. Kao što znamo, njihov maksimalni broj može biti prilično velik. Ovo je i hiljadu i pet hiljada.

Mehanizam zaključavanja i transakcija opisan je u vodiču za programere. Koriste se kada više sesija istovremeno pristupa istim podacima. Logično je da iste podatke ne mogu mijenjati različiti korisnici u isto vrijeme.

Također biste trebali provjeriti da li neki od korisnika pokreće obradu masovnih promjena podataka. Ovo može biti kao, kraj mjeseca i slično. U tom slučaju, nakon završetka obrade, greška će sama nestati.

Planirani zadaci

Nije neuobičajeno da uzrok greške leži u sistemu koji obrađuje velike količine podataka. Preporučljivo je raditi takve stvari noću. Odredite raspored za obavljanje takvih rutinskih poslova van radnog vremena.

Na taj način će korisnici raditi u stabilnom sistemu, a sami rutinski zadaci će biti uspješno završeni, jer će se smanjiti vjerovatnoća sukoba sa korisničkim sesijama.

"Hung sessions"

Problem "zaglavljenih sesija" korisnika poznat je gotovo svima koji su se susreli s održavanjem 1C. Korisnik je mogao odavno napustiti program ili zatvoriti dokument, ali njegova sesija i dalje ostaje u sistemu. Problem je najčešće izolovan i dovoljno je da prekinete takvu sesiju preko administratorske konzole. Isti problemi mogu se pojaviti i sa poslovima u pozadini.

Prema brojnim komentarima na Internetu, takve situacije su češće kada se koriste mrežni sigurnosni ključevi. Ako se situacija sa „zamrznutim sesijama“ sistematski ponavlja, to je razlog za temeljnu provjeru i održavanje sistema i servera (ako je baza podataka klijent-server).

Greške prilikom pisanja konfiguracije

Sve standardne konfiguracije razvijaju kvalifikovani stručnjaci i stručnjaci. Svaki sistem je temeljno testiran i optimizovan za brži i ispravniji rad.

S tim u vezi, uzrok greške može biti u neoptimalnom kodu koji je napisao programer treće strane. Ovo bi mogao biti "težak" zahtjev koji će blokirati podatke na duži vremenski period. Česti su i slučajevi konstruisanja algoritama sa niskim performansama i kršenjem logike.

Postoji velika vjerovatnoća da je sukob zaključavanja nastao upravo zbog grešaka programera ako je nastao nakon ažuriranja programa. Da biste provjerili, možete jednostavno "vratiti" poboljšanja ili refaktorirati kod.

Kada stotine korisnika istovremeno rade s programima i podacima, nastaju problemi koji su karakteristični samo za rješenja velikih razmjera. Govorimo o problemima uzrokovanim blokiranjem podataka.

Ponekad korisnici saznaju o blokiranju iz poruka koje ukazuju da ne mogu pisati podatke ili izvršiti neku drugu operaciju. Ponekad zbog vrlo značajnog pada performansi programa (na primjer, kada se vrijeme potrebno za izvođenje operacije poveća desetinama ili stotinama 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 shvatimo jesu li potrebne. Pogledajmo nekoliko klasičnih primjera blokada s kojima se susrećemo u životu.

Primer 1: kupovina karte za avion ili voz. Pretpostavimo da smo svoje želje izrekli blagajniku. Blagajnica nam govori o raspoloživosti slobodnih mjesta, od kojih možemo izabrati ono koje nam se najviše sviđa (naravno, ako ih ima nekoliko). Dok biramo i potvrđujemo da se slažemo sa predloženom opcijom, ova mjesta se ne mogu prodati nikome drugom, tj. su privremeno „blokirani“. 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 imati nepredvidiv broj ponavljanja. Dok biramo mesta, već su prodata!.. Dok biramo druga, a njih više nema...

Primjer 2: kupujete nešto u prodavnici ili na bazaru. Prišli smo pultu i izabrali najljepšu jabuku od stotine dostupnih. Izabrali su to i posegnuli za novcem u džep. Kako će izgledati ako u tom trenutku, dok brojimo novac, jabuka koju smo izabrali bude prodata kupcu koji je došao kasnije od nas?

Dakle, blokiranje je samo po sebi neophodan i koristan fenomen. Zahvaljujući blokiranju garantujemo da su radnje završene u jednom koraku. A ono što najčešće dovodi do negativnosti nije najuspješnija softverska implementacija, kada je npr.

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

PREKOMERNO BLOKIRANJE U TIPIČNIM 1C KONFIGURACIJAMA

Na velikim projektima u pravilu koristimo 1C:Enterprise. Stoga ćemo pokušati opisati praktične preporuke za rješavanje problema blokiranja na primjeru kombinacije 1C:Enterprise + MS-SQL.

Osma generacija 1C:Enterprise pruža vrlo, vrlo dobar paralelizam korištenja. Ogroman broj korisnika može istovremeno raditi sa jednom konfiguracijom (odnosno na jednoj bazi) sa normalnim serverima i komunikacijskim kanalima. Na primjer, stotine skladištara obrađuju izdavanje ili prijem robe, ekonomisti istovremeno obračunavaju troškove rada za različite odjele, računovođe vrše obračune i obračun plaća itd.

Ali postoji razlog zašto postoji suprotno mišljenje - mit da je uz intenzivnu istovremenu upotrebu rad s rješenjima zasnovanim na 1C:Enterpriseu neugodan ili nemoguć. Uostalom, čim standardna rješenja za 1C:Enterprise počnu koristiti stotine korisnika u industrijskim razmjerima, sve češće se na ekranu pojavljuje prozor s ponosnim natpisom: „Greška pri pozivanju metode konteksta (Write) : Konflikt zaključavanja 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 izvan kutije su konfigurirana za automatsko upravljanje zaključavanjem. “Automatski” se ovdje može shvatiti kao “paranoičan”. Za svaki slučaj, prilikom obrade bilo kojeg dokumenta, blokiramo sve što je na neki način povezano s njim. Tako ispada da kada jedan korisnik nešto uradi (a ponekad samo zapiše), ostali mogu samo da čekaju.

Izneću svoje mišljenje zašto je 1C odlučio da ne konfiguriše svoja standardna rešenja za visoko paralelno korišćenje. Troškovi rada za takvu modifikaciju nisu visoki - nekoliko "čovjekomjeseca", što nije značajno na skali 1C. Čini mi se da je razlog drugačiji.

Prvo, takva izmjena značajno otežava obradu svih dokumenata. To znači da će za one potrošače koji koriste 1C za male zadatke, bez ikakvog dobitka postojati samo nedostatak - poteškoće modifikacije standardne konfiguracije će postati složenije. Statistika istovremeno ukazuje na to koja kategorija klijenata je glavna hranilica za 1C...

Drugi razlog je zakopan u tipičnim osnovnim postavkama SQL servera, na primjer, MS-SQL, koji se i dalje koristi češće od ostalih. Desilo se da su prioriteti u postavkama dali čuvanju serverske RAM memorije, a ne smanjenju blokiranja. To dovodi do činjenice da, ako je potrebno zaključati nekoliko redova, SQL server donosi odluku o "štedi memorije i procesora" - da zaključa cijelu tablicu odjednom!..

Ovi nedostaci u standardnim rješenjima ili specifičnosti korištenog postavljanja poslužitelja baze podataka često se identificiraju s problemima uzrokovanim blokiranjem. Kao rezultat, tehnički nedostaci dovode do veoma značajnih organizacionih problema. Na kraju krajeva, ako se zaposleniku da razlog da se odvrati od posla ili da se opravda zašto posao nije mogao da se obavi, manjina će raditi efikasno. Pa, poruka o blokiranju transakcija ili „kočećem“ programu je idealno opravdanje zašto se nešto nije moglo učiniti.

PREPORUKE ZA OTKLANJANJE VEĆIH BLOKIRANJA ZA 1C:PREDUZEĆE

Šta učiniti ako je rješavanje problema prekomjernog zaključavanja toliko važno?

U završnoj fazi implementacije svih velikih kompleksa, potrebno je izvršiti fino podešavanje kako bi se eliminiralo nepotrebno blokiranje transakcija. Ključno je riješiti probleme koji mogu nastati zbog nedovoljno razvijenih uslova blokiranja ili tehnika implementacije.

Jer Ova operacija je izuzetno važna i mora se izvoditi stalno. Stoga, da bismo pojednostavili takve izmjene, razvili smo niz osnovnih preporuka kojih se trudimo pridržavati. Preporuke primljene i testirane kroz iskustvo značajnog broja velikih implementacija.

1. Ako DBMS ili razvojni sistem koji koristite (na primjer, 1C:Enterprise) po defaultu koristi način automatskog zaključavanja podataka, odbijte automatsko upravljanje zaključavanjem. Sami konfigurirajte pravila blokiranja, opišite kriterije za blokiranje cijelih tablica ili pojedinačnih redova.
2. Kada razvijate program, kad god je to moguće, pristupajte tabelama istim redoslijedom.
3. Pokušajte da ne pišete u istu tabelu više puta u okviru iste transakcije. Ako je to teško, barem minimizirajte vremenski interval 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 zbog kojih ne mogu izvršiti nikakve radnje ako su do njih došlo zbog blokiranja. Dajte pristupačne i razumljive preporuke šta dalje.

Ako pažljivo pogledate preporuke, postaje jasno da takvo testiranje je prikladno ne samo za 1C:Enterprise, već i za sve sisteme. Uopšte 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 kada se koristi 1C:Enterprise i za "kućno pisane" programe ili druge "upakirane" ERP sisteme.

P.S. Jeste li znali da nudimo stručnu pomoć pri ažuriranju 1C po najboljoj cijeni?

Oznake za pretraživanje:

• Transakcione brave
• Uklanjanje blokada
• 1C brave
• Blokiranje
• Konflikt zaključavanja
• Zaključaj sukob tokom transakcije

Nisam mogao zapisati promjene za prijenos u distribuiranu bazu podataka, pa sam kontaktirao 1C podršku i ponudio sljedeće. Rešio sam to jednostavnim ponovnim pokretanjem servera aplikacija i SQL servera. Općenito, možete označiti okvir „Blokiranje regulatorno
uključeni zadaci"
Pomoglo je i bez ponovnog pokretanja.

Rutinske operacije na nivou DBMS za MS SQL Server

Upute za izvođenje rutinskih operacija na nivou DBMS.

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

Opće informacije

Jedan od najčešćih razloga za neoptimalni rad sistema je netačno ili neblagovremeno izvršavanje rutinskih operacija na nivou DBMS-a. Posebno je važno ove regulatorne procedure provoditi u velikim informacionim sistemima 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 se uoče bilo kakvi simptomi problema s performansama u sistemu koji radi, trebali biste provjeriti da li je sistem ispravno konfigurisan i da redovno izvodi sve preporučene rutinske operacije na nivou DBMS-a.

Implementacija regulatornih procedura treba da bude automatizovana. Za automatizaciju ovih operacija preporučuje se korištenje ugrađenog MS SQL Server alata: Plan održavanja. Postoje i drugi načini za automatizaciju ovih procedura. Za svaki regulatorni postupak, ovaj članak daje primjer kako ga konfigurirati pomoću Plana održavanja za MS SQL Server 2005.

Preporučuje se redovno praćenje blagovremenosti i pravilne primjene ovih regulatornih procedura.

Ažuriraj statistiku

MS SQL Server gradi plan upita na osnovu statističkih informacija o distribuciji vrijednosti u indeksima i tabelama. Statističke informacije 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, planovi upita pokazuju karakteristične znakove neoptimalnog rada (neoptimalne operacije).

Kako bi se garantovao najispravniji rad optimizatora MS SQL Servera, preporučuje se redovno ažuriranje statistike MS SQL baze podataka.

Da ažurirate statistiku za sve tablice baze podataka, morate pokrenuti sljedeći SQL upit:

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

Ažuriranje statistike ne dovodi do zaključavanja tabele 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 povećati tokom ažuriranja statistike, što može negativno uticati na ukupne performanse sistema.

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 su tabele najpotrebnije za česta ažuriranja 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.

Postavljanje 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 održavanja:

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.

Konfigurirajte 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 treba ažurirati statistiku (ako ne znate tačno koje tablice trebate navesti, tada postavite vrijednost na Sve).

Statistike se moraju ažurirati sa omogućenom opcijom Full Scan.

Sačuvajte kreirani plan. Kada dođe vrijeme navedeno u rasporedu, ažuriranje statistike će početi automatski.

Brisanje proceduralne keš memorije

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

Moguće je da će MS SQL Server, na osnovu zastarjelih statističkih informacija, izgraditi neoptimalan plan upita. Ovaj plan će biti pohranjen u proceduralnoj keš memoriji i korišten kada se isti upit ponovo pozove. Ako ažurirate statistiku, ali ne izbrišete predmemoriju procedure, SQL Server može izabrati stari (podoptimalan) plan upita iz keša umjesto da gradi novi (optimalniji) plan.

Za brisanje proceduralne predmemorije MS SQL Servera potrebno je pokrenuti sljedeći SQL upit:

Ovaj upit treba pokrenuti odmah nakon ažuriranja statistike. Shodno tome, učestalost njegovog izvršavanja treba da se poklapa sa učestalošću ažuriranja statistike.

Postavljanje proceduralnog čišćenja predmemorije (MS SQL 2005)

Budući da se proceduralni keš mora obrisati svaki put kada se statistika ažurira, preporučuje se da se ova operacija doda već kreiranom podplanu „Ažuriranje statistike“. 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 zahtjev “DBCC FREEPROCCACHE”:

Defragmentacija indeksa

Kada se intenzivno radi sa tabelama baze podataka, dolazi do fragmentacije indeksa, što može dovesti do smanjene performanse upita.

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

Defragmentiranje indeksa ne zaključava 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čuje se da defragmentirate indekse barem jednom sedmično.

Možete defragmentirati jednu ili više tabela, umjesto svih tablica u bazi podataka.

Postavljanje defragmentacije indeksa (MS SQL 2005)

U prethodno kreiranom planu održavanja, kreirajte novi podplan pod nazivom “Reindeksiranje”.

Postavite raspored izvršavanja za zadatak defragmentacije indeksa. Zadatak je preporučljivo obavljati najmanje jednom sedmično, a ako su podaci u bazi vrlo varijabilni, i češće - do jednom dnevno.

Ponovno indeksiranje tablica baze podataka

Ponovno indeksiranje tablice uključuje potpunu rekonstrukciju indeksa tablice baze podataka, što dovodi do značajne optimizacije njihovih performansi. Preporučuje se redovno reindeksiranje tablica baze podataka. Da biste ponovo indeksirali sve tablice baze podataka, morate pokrenuti sljedeći SQL upit:

sp_mforeachtable N"DBCC DBREINDEX (""?")"

Ponovno indeksiranje tablica ih zaključava za cijelo vrijeme njihovog rada, što može značajno utjecati na korisničko iskustvo. U tom smislu, preporučljivo je izvršiti ponovno indeksiranje za vrijeme minimalnog opterećenja sistema.

Nakon što je ponovno indeksiranje završeno, 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čljivo je izvršiti zadatak pri minimalnom opterećenju sistema, barem jednom sedmično.

Postavite zadatak navođenjem baze podataka (ili nekoliko baza podataka) i odabirom potrebnih tablica. Ako ne znate tačno koje tabele treba navesti, onda postavite vrednost na Sve.