Sziasztok mindenkinek!

A minap a munkahelyemen zárolási problémába ütköztem, nevezetesen a „Tranzakció végrehajtása közben zárolási ütközés van túllépve” üzenet.

Nyilvánvaló, hogy itt nincs holtponti probléma, csak néhány munkamenet zárolt, és „elfelejtette” eltávolítani. Ugyanakkor a probléma súlyos következményekkel fenyegetett - az áruk és szolgáltatások értékesítése dokumentumot nem hajtották végre. Egyszerre körülbelül 100 ember dolgozik az adatbázisban, és nem lehet tipikus és gyakori műveletet végrehajtani!

Két megoldás volt – a kiszolgáló újraindítása vagy a sikertelen munkamenet keresése. Az első megoldás egyszerű és gyors, de ahogy valaki már írta itt, addig újraindíthatja a szervert, amíg ki nem rúg. Úgy döntöttem, hogy a második utat választom.

Az első nap - a probléma a nap folyamán jelent meg először úgy tűnt, hogy a probléma egy távoli felhasználóval van, aki bejelentkezett a Configuratorba. Úgy tűnt, hogy a végrehajtás egy ponton egyszerűen leállt, és a blokkolást természetesen nem szüntették meg. Pár óra múlva sikerült kiadni a konfigurátort, de a probléma nem szűnt meg. Rendkívül nemkívánatos volt erőszakkal megölni a konfigurátort, talán éppen dolgoztak benne. Ezt követően a Google került játékba. Találtam egy cikket ezen az oldalon, ami azt írja, hogyan lehet zárakat találni egy MS SQL DBMS-ben, ellenőrizve, nem voltak zárolások DBMS szinten. Furcsa. Ezután kísérletek történtek a technológia beállítására. magazin. Állítsa be, mi lesz ezután? 15 perc alatt pár giga rönk! Hogyan kell őket olvasni, mire kell figyelni? Ismeretlen.

Találtam egy cikket arról, hogyan lehet megnézni, mi van blokkolva az SQL Trace használatával. Még ha megtalálom is, mi lesz ezután? Kell egy foglalkozás!

16:00 felé, amikor rájöttem, hogy nem tudok tovább várni, újraindítottam. Abban a reményben, hogy ez többé nem fordul elő (és ez volt az első alkalom a hat hónapos munka után), fellélegeztem, minden működött. De hiába... Második nap - ugyanaz a helyzet. Másfél órát ástam, megint érthetetlen próbálkozások guglizni stb. Nincs eredmény. Indítsa újra. A nap végén megismétlődött. Nos, szerintem nagyszerű, nyugodtan hazajövök, leülök és mélyebbre ások. Hazajöttem, minden rendben. Szomorúan.

A harmadik napon megnéztem egy webináriumot, ahol egy érdekes és hatékony módszerről beszéltek a probléma megtalálására. Emlékeztem, de a probléma nem jött elő újra. Eltelt egy hét, és itt van - ismét zárlatok! Megdörzsölöm a kezem, és cselekedni kezdek.

Először állítsa be a naplót. Igen, nem bírom nélküle, de most már tudom, hogyan kell elolvasni. Két eseményt állítunk be: az első a TLOCK, a második a TTIMEOUT. Az első az összes blokkoló eseményt jeleníti meg, a második pedig azokat a blokkoló eseményeket, amelyeket nem lehetett telepíteni a megadott időn belül. Valójában a TTIMEOUT valószínűleg elég.

A műszaki naplófájlt a kijelölt helyre másoljuk, berepülünk a programba, felhívjuk a zárat, üzenetet kapunk és eltávolítjuk vagy átnevezzük a műszaki naplófájlt. Nincs szükségünk rengeteg információra más blokkolásokról!

Lépjen az rphost_PID mappába, keresse meg a szöveges fájlokat, és keresse meg a TTIMEOUT szót. Látjuk a sort:

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

Egyébként több rphost_PID mappa is lehet, minden attól függ, hogy hány worker process fut a szerveren.

És akkor minden egyszerű: nézd meg a sor végét - WaitConnections = 8239, ez a CONNECTION számunk. A szerverkonzolra lépünk, a Kapcsolatok menüpontra, megkeressük ezt a számot, és megnézzük a munkamenet számát. Az én esetemben felhasználónként két munkamenet volt – a sikertelen és egy másik. A munkamenet, amelyre a műszaki folyóirat mutatott, összeomlott. És lám! Minden működött, az öröm nem ismer határokat! De mint utóbb kiderült, az ülés nem volt lefagyva :), dolgoztak benne. Ezért a jövőben tanácsos felvenni a kapcsolatot a felhasználóval és figyelmeztetni.

Véleményem szerint egy meglehetősen standard megoldás egy meglehetősen standard problémára. Nem tudni, miért nem találkoztam vele, talán azért, mert riadtan kellett keresnem, és amikor a felhasználók nem nyomták meg, nem lehetett teszteket végezni - nem volt hiba.

Az 1C-ben végzett munka során nem ritka a „Zárolási ütközés a tranzakciók végrehajtása során: A zárolás megadásához szükséges maximális várakozási idő túllépése” hibaüzenet jelenik meg. Lényege abban rejlik, hogy több munkamenet próbál egyidejűleg hasonló műveleteket végrehajtani, ugyanazt az erőforrást érintve. Ma kitaláljuk, hogyan lehet ezt a hibát kijavítani.

Nagyszámú végrehajtott művelet

Az okok keresésének első lépése annak tisztázása, hogy hány egyidejű felhasználó van abban az információs bázisban, amelyben egy ilyen hiba keletkezik. Mint tudjuk, maximális számuk meglehetősen nagy lehet. Ez ezer és ötezer is.

A zárolás és a tranzakciók mechanizmusát a fejlesztői útmutató ismerteti. Akkor használatosak, ha több munkamenet egyszerre éri el ugyanazt az adatot. Logikus, hogy ugyanazokat az adatokat különböző felhasználók nem módosíthatják egyszerre.

Azt is ellenőriznie kell, hogy valamelyik felhasználó futtat-e tömeges adatmódosítási feldolgozást. Ez lehet például a hónap zárása és hasonlók. Ebben az esetben a feldolgozás befejezése után a hiba magától eltűnik.

Ütemezett feladatok

Nem ritka, hogy a hiba oka egy nagy mennyiségű adatot feldolgozó rendszerben keresendő. Javasoljuk, hogy ilyen dolgokat éjszaka végezzen. Állítson be ütemezést az ilyen rutinfeladatok munkaidőn kívüli elvégzésére.

Ily módon a felhasználók stabil rendszerben dolgoznak, és maguk a rutinfeladatok is sikeresen befejeződnek, mivel csökken a felhasználói munkamenetekkel való ütközések valószínűsége.

"Hung sessions"

A felhasználók „elakadt munkameneteinek” problémája szinte mindenki számára ismert, aki találkozott az 1C szolgáltatással. A felhasználó már régen kiléphetett volna a programból, vagy bezárhatott volna egy dokumentumot, de a munkamenete továbbra is a rendszerben marad. A probléma leggyakrabban elszigetelt, és elegendő egy ilyen munkamenetet a rendszergazdai konzolon keresztül befejezni. Ugyanezek a problémák merülhetnek fel a háttérmunkáknál is.

Számos internetes megjegyzés szerint az ilyen helyzetek gyakrabban fordulnak elő hálózati biztonsági kulcsok használatakor. Ha a „lefagyott munkamenetek” szisztematikusan megismétlődnek, ez indokolja a rendszer és a szerverek (ha az adatbázis kliens-szerver) alapos ellenőrzését és karbantartását.

Hibák a konfiguráció írása közben

Minden szabványos konfigurációt képzett szakemberek és szakértők fejlesztenek ki. Minden rendszert alaposan tesztelnek és optimalizálnak a gyorsabb és pontosabb működés érdekében.

Ebben a tekintetben a hiba oka egy külső fejlesztő által írt, nem optimális kódban keresendő. Ez egy „súlyos” kérés lehet, amely hosszú ideig blokkolja az adatokat. Gyakran előfordulnak olyan esetek is, amikor alacsony teljesítményű és logikát sértő algoritmusokat készítenek.

Nagy a valószínűsége annak, hogy a zárolási konfliktus éppen a fejlesztői hibák miatt keletkezett, ha az egy programfrissítés után keletkezett. Az ellenőrzéshez egyszerűen „visszagörgetheti” a fejlesztéseket, vagy újrafaktorálhatja a kódot.

Amikor több száz felhasználó dolgozik egyidejűleg programokkal és adatokkal, olyan problémák merülnek fel, amelyek csak a nagyszabású megoldásokra jellemzőek. Az adatblokkolás okozta problémákról beszélünk.

Néha a felhasználók azokból az üzenetekből értesülnek a blokkolásról, amelyek azt jelzik, hogy nem tudnak adatokat írni vagy más műveletet végrehajtani. Néha a program teljesítményének igen jelentős csökkenése miatt (például amikor egy művelet végrehajtásához szükséges idő tízszeresére vagy százszorosára nő).

A blokkolás okozta problémákra nincs általános megoldás. Ezért megpróbáljuk elemezni az ilyen problémák okait, és rendszerezni fogjuk a megoldási lehetőségeket.

A TRANZAKCIÓK LETILTÁSÁNAK OKAI

Először emlékezzünk meg, mik azok a zárak, és egyúttal derítsük ki, hogy szükségesek-e. Nézzünk meg néhány klasszikus példát az életünk során tapasztalt elakadásokra.

1. példa: repülőjegy vagy vonatjegy vásárlása. Tegyük fel, hogy hangot adtunk kívánságunknak a pénztárosnak. A pénztáros közli a szabad ülőhelyek számát, amiből kiválaszthatjuk a nekünk leginkább tetszőt (természetesen ha több is van). Miközben kiválasztjuk és megerősítjük, hogy egyetértünk a javasolt opcióval, ezek a helyek nem adhatók el másnak, pl. ideiglenesen „le vannak tiltva”. Ha nem lettek letiltva, akkor a visszaigazolásig előfordulhat, hogy az általunk kiválasztott jegyek már elkeltek. És ebben az esetben a kiválasztási ciklusnak megjósolhatatlan számú ismétlése lehet. Amíg mi választjuk a helyeket, már eladták őket!.. Miközben másokat választunk, és azok már nincsenek...

2. példa: vásárol valamit egy boltban vagy egy bazárban. Odaléptünk a pulthoz, és a rendelkezésre álló több száz közül kiválasztottuk a legszebb almát. Kiválasztották, és a zsebükbe nyúltak a pénzért. Hogy fog kinézni, ha abban a pillanatban, miközben számoljuk a pénzt, az általunk kiválasztott almát eladják egy nálunk később érkező vásárlónak?

Így a blokkolás önmagában is szükséges és hasznos jelenség. A letiltásnak köszönhetően garantáljuk, hogy a műveletek egy lépésben befejeződjenek. Ami pedig leggyakrabban negativitáshoz vezet, az nem a legsikeresebb szoftver implementáció, amikor pl.

• túl sok tárgy (jegy, alma) blokkolva van;
• A letiltás ideje indokolatlanul meghosszabbodik.

TÚLSÁGOS BLOKKOLÁS A TIPPUS 1C KONFIGURÁCIÓKBAN

Nagy projekteknél általában az 1C:Enterprise-t használjuk. Ezért megpróbálunk gyakorlati ajánlásokat leírni a blokkolási problémák megoldására az 1C: Enterprise + MS-SQL kombináció példáján keresztül.

Az 1C:Enterprise 8. generációja nagyon-nagyon jó párhuzamos használatot biztosít. Nagyszámú felhasználó dolgozhat egyidejűleg egy konfigurációval (vagyis egy alapon) normál szerverekkel és kommunikációs csatornákkal. Például raktárosok százai dolgozzák fel az áruk kiadását vagy átvételét, a közgazdászok egyszerre számítják ki a különböző részlegek munkaerőköltségét, a könyvelők végeznek számításokat és bérszámfejtést stb.

De megvan az oka annak, hogy van ezzel ellentétes vélemény - az a mítosz, hogy intenzív egyidejű használat mellett az 1C:Enterprise alapú megoldásokkal dolgozni kényelmetlen vagy lehetetlen. Végül is, amint az 1C:Enterprise szabványos megoldásait több száz felhasználó ipari méretekben kezdi használni, egyre gyakrabban jelenik meg egy ablak a képernyőn büszke felirattal: „Hiba a kontextus metódusának hívásakor (írás) : Ütközés zárolása tranzakció végrehajtása során: ..." és tovább a használt SQL-kiszolgáló típusától függően, valami ilyesmi: "Microsoft OLE DB Provider for SQL Server: A zárolási kérelem időtúllépési ideje túllépte. ...".

A javasolt készenléti megvalósításban szinte minden szabványos megoldás automatikus zárkezelésre van konfigurálva. Az „automatikus” itt „paranoiás”-ként fogható fel. Minden esetre, bármely dokumentum feldolgozása során blokkolunk mindent, ami valamilyen módon kapcsolódik hozzá. Így kiderül, hogy amikor az egyik felhasználó végrehajt valamit (és néha csak leírja), a többi csak várhat.

Kifejtem a véleményemet, hogy az 1C miért döntött úgy, hogy nem konfigurálja szabványos megoldásait magas párhuzamos használathoz. Az ilyen módosítások bérköltségei nem magasak - több „ember hónap”, ami nem jelentős az 1C léptékben. Nekem úgy tűnik, hogy az ok más.

Először is, egy ilyen módosítás jelentősen megnehezíti az összes dokumentum feldolgozását. Ez azt jelenti, hogy azoknak a fogyasztóknak, akik kis feladatokhoz használják az 1C-t, nyereség nélkül csak egy hátránya lesz - a szabványos konfiguráció módosításának nehézsége bonyolultabb lesz. A statisztikák ugyanakkor megmondják, hogy melyik ügyfélkategória a fő feeder az 1C számára...

A második ok az SQL-kiszolgálók tipikus alapbeállításaiban rejlik, például az MS-SQL-ben, amelyet még mindig gyakrabban használnak, mint mások. Történt ugyanis, hogy a beállításoknál a szerver RAM-jának megtakarítása volt a prioritás, nem pedig a blokkolások csökkentése. Ez oda vezet, hogy ha több sor zárolására van szükség, az SQL szerver „memória- és processzorkímélő” döntést hoz - a teljes tábla zárolását egyszerre!

A szabványos megoldásokban vagy a használt adatbázis-kiszolgáló beállításának sajátosságaiban előforduló hiányosságokat gyakran a blokkolás okozta problémákkal azonosítják. Ennek következtében a technikai hiányosságok igen jelentős szervezési problémákhoz vezetnek. Hiszen ha a munkavállalónak okot adnak arra, hogy elvonja a figyelmét a munkáról, vagy megindokolja, miért nem lehetett elvégezni a munkát, akkor a kisebbség fog hatékonyan dolgozni. Nos, a tranzakciók blokkolására vonatkozó üzenet vagy egy „fékező” program ideális indoklás arra, hogy valamit miért nem lehetett megtenni.

AJÁNLÁSOK AZ 1C:ENTERPRISE TÚLZOTT LETILTÁSÁNAK MEGSZÜNTETÉSÉHEZ

Mi a teendő, ha annyira fontos a túlzott zárolás problémáinak megoldása?

Az összes nagy komplexum megvalósításának végső szakaszában finomhangolást kell végezni a szükségtelen tranzakciók blokkolásának kiküszöbölése érdekében. Kritikusan fontos megoldani azokat a problémákat, amelyek a nem megfelelően kidolgozott blokkolási feltételek vagy megvalósítási technikák miatt merülhetnek fel.

Mert Ez a művelet rendkívül fontos, és folyamatosan végre kell hajtani. Ezért az ilyen módosítások egyszerűsítése érdekében számos alapvető ajánlást dolgoztunk ki, amelyeket igyekszünk betartani. Jelentős számú nagyszabású megvalósítás tapasztalata révén beérkezett és tesztelt ajánlások.

1. Ha az Ön által használt DBMS vagy fejlesztőrendszer (például 1C:Enterprise) alapértelmezés szerint automatikus adatzárolási módot használ, utasítsa el az automatikus zárkezelést. Állítsa be saját maga a blokkolási szabályokat, írja le a teljes táblák vagy az egyes sorok blokkolásának feltételeit.
2. Egy program fejlesztésekor lehetőség szerint ugyanabban a sorrendben érje el a táblákat.
3. Próbáljon meg ne írni többször ugyanabba a táblába ugyanazon tranzakción belül. Ha ez nehéz, akkor legalább minimalizálja az első és az utolsó írási művelet közötti időt.
4. Elemezze a zárolási eszkaláció letiltásának lehetőségét az SQL-kiszolgáló szintjén.
5. Világosan tájékoztassa a felhasználókat azokról az okokról, amelyek miatt nem tudnak semmilyen műveletet végrehajtani, ha azok letiltás miatt következnek be. Adjon elérhető és érthető ajánlásokat a következő lépésekre vonatkozóan.

Ha figyelmesen megvizsgálja az ajánlásokat, világossá válik, hogy az ilyen tesztelés nem csak az 1C:Enterprise, hanem minden rendszer számára megfelelő. Egyáltalán nem mindegy, hogy milyen nyelven íródnak, és milyen adatbázis-kiszolgálóval dolgoznak. Az ajánlások többsége univerzális jellegű, ezért egyformán érvényesek az 1C:Enterprise használatakor, valamint „házilag írt” programok vagy más „dobozos” ERP rendszerek esetén.

P.S. Tudta, hogy professzionális segítséget nyújtunk az 1C frissítéséhez a legjobb áron?

Keresendő címkék:

• Tranzakciós zárak
• Duguláselhárítás
• 1C zárak
• Zár
• Lock konfliktus
• Zárja le a versenyt a tranzakció során

Nem tudtam leírni az elosztott adatbázisba való átvitelhez szükséges változtatásokat, ezért felvettem a kapcsolatot az 1C támogatásával, és felajánlottam a következőket. Egyszerűen úgy oldottam meg, hogy újraindítottam az alkalmazásszervert és az SQL szervert. Általában bejelölheti a „Blocking regulatory
feladatokat tartalmaz"
Újraindítás nélkül is segített.

Rutinműveletek DBMS szinten az MS SQL Server számára

Útmutató a DBMS-szintű rutinműveletek végrehajtásához.

Az információk az 1C:Enterprise 8 kliens-szerver verziójára vonatkoznak, ha az MS SQL Server DBMS-t használja.

Általános információk

A szuboptimális rendszerműködés egyik leggyakoribb oka a rutinműveletek helytelen vagy idő előtti végrehajtása DBMS szinten. Különösen fontos ezeknek a szabályozási eljárásoknak a lebonyolítása olyan nagy információs rendszerekben, amelyek jelentős terhelés mellett működnek, és egyszerre nagyszámú felhasználót szolgálnak ki. Az ilyen rendszerek sajátossága, hogy a DBMS által automatikusan (beállítások alapján) végrehajtott szokásos műveletek nem elegendőek a hatékony működéshez.

Ha teljesítményproblémák tünetét észleli egy futó rendszerben, ellenőrizze, hogy a rendszer megfelelően van-e konfigurálva, és rendszeresen végrehajtja-e az összes javasolt rutinműveletet DBMS-szinten.

A szabályozási eljárások végrehajtását automatizálni kell. Ezen műveletek automatizálásához javasolt a beépített MS SQL Server eszköz használata: Karbantartási terv. Ezen eljárások automatizálásának más módjai is vannak. Ez a cikk az egyes szabályozási eljárásokhoz példát mutat be az MS SQL Server 2005 karbantartási tervével történő konfigurálására.

Javasolt ezen szabályozási eljárások időszerűségének és helyes végrehajtásának rendszeres figyelemmel kísérése.

Statisztikák frissítése

Az MS SQL Server lekérdezési tervet készít az indexekben és táblákban lévő értékek eloszlásáról szóló statisztikai információk alapján. A statisztikai információkat az adatok egy része (minta) alapján gyűjtjük, és automatikusan frissítjük, amikor ezek az adatok megváltoznak. Néha ez nem elég ahhoz, hogy az MS SQL Server következetesen elkészítse a legoptimálisabb tervet az összes lekérdezés végrehajtásához.

Ebben az esetben a lekérdezés teljesítménnyel kapcsolatos problémák léphetnek fel. A lekérdezési tervek ugyanakkor a nem optimális működés (nem optimális műveletek) jellegzetes jeleit mutatják.

Az MS SQL Server optimalizáló legpontosabb működésének garantálása érdekében javasolt az MS SQL adatbázis statisztikáinak rendszeres frissítése.

Az összes adatbázistábla statisztikájának frissítéséhez futtassa a következő SQL-lekérdezést:

exec sp_msforeachtable N"STATISZTIKA FRISSÍTÉSE ? FULLSCAN SZÁMÁRA"

A statisztikák frissítése nem vezet az asztal zárolásához, és nem zavarja a többi felhasználó munkáját. A statisztikák szükség szerint frissíthetők. Figyelembe kell venni, hogy a DBMS-kiszolgáló terhelése megnő a statisztikák frissítése közben, ami negatívan befolyásolhatja a rendszer általános teljesítményét.

A statisztikák frissítésének optimális gyakorisága a rendszer terhelésének méretétől és jellegétől függ, és kísérleti úton határozzák meg. A statisztikák frissítése javasolt naponta legalább egyszer.

A fenti lekérdezés frissíti az adatbázisban lévő összes tábla statisztikáit. Egy valós rendszerben a különböző táblázatok eltérő statisztikai frissítési arányt igényelnek. A lekérdezési tervek elemzésével meghatározhatja, hogy mely tábláknak van leginkább szüksége a statisztikai adatok gyakori frissítésére, és két (vagy több) különböző rutin eljárást konfigurálhat: a gyakran frissített táblákhoz és az összes többi táblához. Ez a megközelítés jelentősen csökkenti a statisztikák frissítésének idejét és a statisztikai frissítési folyamat hatását a rendszer egészének működésére.

Automatikus statisztikai frissítések beállítása (MS SQL 2005)

Indítsa el az MS SQL Server Management Studio programot, és csatlakozzon a DBMS-kiszolgálóhoz. Nyissa meg a Kezelés mappát, és hozzon létre egy új karbantartási tervet:

Hozzon létre egy altervet (Alterv hozzáadása), és nevezze el „statisztika frissítése”. Adja hozzá a Statisztika frissítése feladatot a tálcáról:

Állítson be egy statisztikai frissítési ütemezést. Javasoljuk, hogy a statisztikákat naponta legalább egyszer frissítse. Szükség esetén a statisztikai adatok frissítésének gyakorisága növelhető.

Konfigurálja a feladat beállításait. Ehhez kattintson duplán a feladatra az ablak jobb alsó sarkában. A megjelenő űrlapon adja meg annak az adatbázisnak (vagy több adatbázisnak) a nevét, amelyre vonatkozóan a statisztika frissül. Ezenkívül megadhatja, hogy mely táblák statisztikáit kell frissíteni (ha nem tudja, hogy pontosan mely táblákat kell megadnia, akkor állítsa az értéket Mind értékre).

A statisztikát úgy kell frissíteni, hogy a Teljes vizsgálat opció engedélyezve van.

Mentse el a létrehozott tervet. Amikor elérkezik az ütemezésben megadott időpont, automatikusan elindul a statisztika frissítése.

Az eljárási gyorsítótár törlése

Az MS SQL Server optimalizáló gyorsítótárazza a lekérdezési terveket az újravégrehajtáshoz. Ez azért történik, hogy időt takarítson meg a lekérdezés összeállításával, ha ugyanazt a lekérdezést már végrehajtották, és ismert a terve.

Lehetséges, hogy az MS SQL Server elavult statisztikai információk alapján nem optimális lekérdezési tervet készít. Ez a terv az eljárási gyorsítótárban kerül tárolásra, és ugyanazon lekérdezés ismételt meghívásakor kerül felhasználásra. Ha frissíti a statisztikát, de nem törli az eljárás gyorsítótárát, az SQL Server egy régi (szuboptimális) lekérdezési tervet választhat a gyorsítótárból az új (optimálisabb) terv létrehozása helyett.

Az MS SQL Server eljárási gyorsítótárának törléséhez futtassa a következő SQL-lekérdezést:

Ezt a lekérdezést a statisztikák frissítése után azonnal le kell futtatni. Ennek megfelelően a végrehajtás gyakoriságának egybe kell esnie a statisztikák frissítésének gyakoriságával.

Az eljárási gyorsítótár törlésének beállítása (MS SQL 2005)

Mivel az eljárási gyorsítótárat minden statisztika frissítésekor törölni kell, javasolt ezt a műveletet hozzáadni a már létrehozott „Statisztikák frissítése” altervhez. Ehhez nyissa meg az altervet, és adja hozzá az Execute T-SQL utasításfeladatot a sémájához. Ezután a Statisztika frissítése feladatot egy nyíllal kell összekötni az új feladattal.

A létrehozott Execute T-SQL utasításfeladat szövegében meg kell adni a „DBCC FREEPROCCACHE” kérést:

Az indexek töredezettségmentesítése

Az adatbázistáblákkal végzett intenzív munka során index töredezettség lép fel, ami a lekérdezési teljesítmény csökkenéséhez vezethet.

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

Az indexek töredezettségmentesítése nem zárolja a táblákat, és nem zavarja a többi felhasználó munkáját, de további terhelést jelent az SQL Server számára. A rutin eljárás végrehajtásának optimális gyakoriságát a rendszer terhelésének és a töredezettségmentesítés hatásának megfelelően kell kiválasztani. Javasoljuk, hogy legalább hetente egyszer töredezettségmentesítse az indexeket.

Az adatbázisban lévő összes tábla helyett egy vagy több táblát is defragmentálhat.

Az index töredezettségmentesítésének beállítása (MS SQL 2005)

A korábban létrehozott karbantartási tervben hozzon létre egy új altervet „Újraindexelés” néven. Adja hozzá az Index újraépítési feladatot:

Állítsa be az indextöredezettség-mentesítési feladat végrehajtási ütemezését. A feladat elvégzése hetente legalább egyszer, illetve ha az adatbázisban szereplő adatok erősen változóak, akkor még gyakrabban - akár naponta egyszer.

Adatbázistáblák újraindexelése

A tábla újraindexelése magában foglalja az adatbázis tábla indexeinek teljes újraépítését, ami teljesítményük jelentős optimalizálásához vezet. Javasoljuk, hogy rendszeresen újraindexelje az adatbázistáblákat. Az összes adatbázistábla újraindexeléséhez futtassa a következő SQL-lekérdezést:

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

Az újraindexelés a táblákat működésük teljes időtartamára zárolja, ami jelentősen befolyásolhatja a felhasználói élményt. Ebben a tekintetben javasolt az újraindexelés végrehajtása minimális rendszerterhelés alatt.

Az újraindexelés befejezése után nincs szükség az indexek töredezettségmentesítésére.

Tábla újraindexelés beállítása (MS SQL 2005)

A korábban létrehozott karbantartási tervben hozzon létre egy új altervet Index töredezettségmentesítés néven. Adja hozzá az Index újraépítési feladatot:

Állítsa be a tábla újraindexelési feladat végrehajtási ütemezését. A feladat elvégzése minimális rendszerterhelés mellett, hetente legalább egyszer javasolt.

Állítsa be a feladatot egy adatbázis (vagy több adatbázis) megadásával és a szükséges táblák kiválasztásával. Ha nem tudja pontosan, hogy mely táblákat kell megadni, állítsa az értéket Mind értékre.