mssql belassul

Microsoft Windows

Sziasztok!

Nem boldogulok egy MS SQL szerverrel (SQL Server Enterprise edition). Rendszeresen az egekbe kúszik (1-2 óra, 1-2 nap v. akár 1-2 hét alatt, teljesen változó) a processzor terheltsége, ami alapból 0-5% között szokott lebzselni.
Tűzoltás jelleggel a restart megoldja a problémát, de nem az igazi. Azt figyeltem meg, h a memória használat növekedésével (2-2,5Giga felett) lassul be a masina, ezért jobb megoldás ismerete hiányában bekorlátoztam a memória használatot 1,5Gigára.
Ideiglenesen segített, már úgy is látszott, h működik, de nem.

Egy fórumban még olvastam valami újra indexelés szerű dolgot,
de ahhoz kevés a tudásom, h hogyan kell megcsinálni.
Meg nem is igazándiból értem, h egy sql szervernek mért lehet szüksége ilyesmire.

Logokat is nézegettem, de semmi olyasmit nem találtam amit orvosolni kellene.

Környezet:
MS Server 2003 Ent. Edition, SQL Server Enterprise edition
2x 3GHz HT Xeon, 4G RAM + 2G swap, U320 hw raid alatta
+ még 1x ugyan ez mert fürtben vannak.

7 adatbázis van, de csak 1 van folyamatos használatban.
db1: 5 giga adatbázis méret és 7 giga tr. log
db2: 5 giga adatbázis méret és 3.5 giga tr. log
db3: 5 giga adatbázis méret és 3.5 giga tr. log
db4: 32 mega adatbázis méret és 3 mega tr. log
db5: 32 mega adatbázis méret és 3 mega tr. log
db6: 32 mega adatbázis méret és 3 mega tr. log
db7: 32 mega adatbázis méret és 3 mega tr. log

Hely mindenhol van dögivel, a winyók normál állapotúaknak tűnnek.

Szóval már kezdem fonni a szemöldökömet, segítsetek légyszi.

Kösz, Üdv.: Géza

  • 3051 megtekintés

( trey | 2009. 03. 13., p – 11:05 )

Ha sok tranzakció van, akkor a logfileok képesek nagyon meghízni. Egy shrink nem árthat neki. Volt ahol ez segített. Ha azt mondod, hogy egyébként minden normális. Ettől függetlenül érdemes lenne egy disk queue lenght-t és egyéb diagnosztikai értékeket sasolni amikor belassul.

Mindent leírtál, csak azt nem, hogy hányas SQL szerver.

--
trey @ gépház

Na akkor a shrink-nek utána olvasok, ez mennyire erőforrás igényes művelet, mehet használat közben?

"disk queue lenght-t és egyéb diagnosztikai értékeket" ezeket mivel, hogy tudom megnézni?

Azt hol tudom megnézni, h hányas SQL szerver?
Ezt néztem: http://www.pneu-trade.hu/sql_em.png

Kösz.

Elvileg ha rendszeresen backup-olsz, akkor nem is kell shrink.

A disk queue lenght értéket a Performance Monitor-ban (perfmon.msc vagy Start -> Felügyeleti eszközök -> Teljesítmény), tudod nézni. Tudsz hozzáadni további számlálókat. A disk-nél nézegesd. Érdekesek lehetnek még a memória paraméterek is. Illetve a brand szerverek (pl. a HP Proliantok) kiírják a System Management Homepage-ben is. Már ha van a gépen ilyen (ha szakember telepítette).

"Azt hol tudom megnézni, h hányas SQL szerver?"

Első ránézésre ez egy MS SQL Server 2000 SP4. Ebben a témakörben keresgess a Google-ben.

--
trey @ gépház

Szia!

Új munkanap, új sql halál...

Napi mentés, bár lehet, h az nem ugyanaz, mert egy külső programmal csináljuk.

Rakosgattam be a fizikai lemezből 1-2 dolgot:
http://www.pneu-trade.hu/sql_paff_1.png
http://www.pneu-trade.hu/sql_paff_2.png
http://www.pneu-trade.hu/sql_paff_3.png
És a normál állapota:
http://www.pneu-trade.hu/sql_ok_1.png
http://www.pneu-trade.hu/sql_ok_2.png

Ez valamit jelent neked?

Kösz, üdv.: Géza

( kaltsi | 2009. 03. 13., p – 11:18 )

Én mindenképpen egy defrag-ot javaslok, vagy egy reindex-et, attól függ mennyire állhat le a cucc.
Szintén javaslom shrink-et, sokat dob a működésen. Esetleg tegyél be az ütemezőbe defrag-okat, így mindig renbetevődik az adatbázis.

Egy fél napot állhat, az elég lehet egy reindex-hez?
Már olvastam ezt máshol is, de nem értem, h mit csinál ilyenkor a szerver valójában? Nekem úgy rémlik a dolog, h az sql szervereknek ilyesmire nincs szükségük a folyamatos karbantartás miatt, mintha egyik fontos fícsőrnek emlegették volna a táblás adatforrásokkal szemben.

defrag-ot hogyan?

Kösz.

A reindexeléshez nem kell leállítani, csak közben lassú lesz az adott tábla.

Minden adatbázis motor egy idő után defragmentálódik a diszken. Egyrészt mivel nem egyenletesek az insertek, adott hash-intervallumhoz tartozó blokkok betelnek az index táblában, másrészt az egyenetlen delete-ek miatt lyukas lesz máshol a mezőny.

Az "sql" alatt szerintem relációs adatbázist értesz, de mi a halál a "táblás adatforrás"?

--
The Net is indeed vast and infinite...
http://gablog.eu

( Arbiter | 2009. 03. 16., h – 10:07 )

Szia!

Én nem defragolnék éles szerveren, miközben elérik a kliensek, de majd az okosok megmondják, mi a tuti.
A shrink és defrag előtt mindenképp készíts backup-ot!
Esetleg egy újraindítást is meg lehet próbálni még, az előbbieken kívül...:)
Nincs alul méretezve a kiszolgáló?
És végül, ha minden rendben működik, érdemes egy maintenance plan-t készíteni, hogy elkerüld az ilyen kellemetlen dolgokat a jövőben.

EDIT: FIXME, de az Enterprise Edition tud 4GB-nál több memóriát is kezelni, lehet, hogy egy memóriabővítés is sokat dobna a teljesítményen.

( foci v | 2009. 03. 16., h – 10:03 )

A fentebb leírtakat nem ismételném egy két kiegészítés:

Nem lehet valamilyen rosszul megírt lekérdezés?
Nem lehet hogy valamilyen Job lett definiálva amely butaságot csinál?

Sajnos már mind a kettővel találkoztam.
Első körben meg kellene nézni, hogy mi okozza a problémát.
SQLmonitor akarom mondani MSSQL alatt SQLProfilerrel rá kellene nézni a szerverre, hogy a kérdéses időszakban milyen lekérdezések futnak.
Ha valamilyen erőforrás szűkében van a szerver akkor szintén így a legegyszerűbb kideríteni.

( LMoon | 2009. 03. 30., h – 08:43 )

Sziasztok.

Még mindig nem megoldott a probléma, de mintha 1fokkal jobb lenne.
Reindex megvolt és job-ot is gyártottam, rá.
Most mintha ritkábban jelentkezne a kritikus belassulás problémája, de az újraindításig ritkábban jut el.
A shrink-re még nem vitt rá a lélek, de majd az is meg lesz.

Azt szeretném kérdezni, h a szerver adatbázisait is érdemes néha újra indexelni?

Köszönöm, üdv.: Géza

Mindenkepp meg kellene nezni, hogy az adott idoszakokban mi fut egyaltalan, mitol lassul be. Egy egymagaban acsorgo szerver nem szokott hektikusan eroforrast zabalni, majd visszaalni, olyant csak akkor csinal, ha valaki piszkalja, espedig nem jol piszkalja. Mielott barmi drasztikusba belekezdesz, ezt a kerdest mindenkepp meg kell valaszolni, mert addig nincs ertelmes megoldas. Profiler-t kell nezegetni, hogy a kritikus idoszakban mi fut, aztan a lefuto SQL-ek alapjan nezegetni, hogy mi intezhet ilyen kerdeseket a szervernek. Ennyibol ez lehet lekerdezesoptimalizacios gond is, de lehet tenyleges alulmeretezes is.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( foci v | 2009. 04. 02., cs – 17:52 )

Csak shrinkeléssel nem mész semmire.

Kell előtte egy ilyen utasítás:

BACKUP LOG "DB_NAME" WITH TRUNCATE_ONLY;

(persze ezt a backupban szokás megcsinálni...., de a "next, next" ezt nem csinálja meg)
Ahogyan irtam és már mások is:
SQLProfilerrel kellene megnézni.
Esetleg valamilyen idióta select, vagy Job?
Esetleg taskmgr -t lehet hogy nem is az sqlserv eszi meg a procit.
Nincs beidőzítve víruskeresés?
Bármilyen más processz?

( Little Dragon | 2009. 04. 02., cs – 21:01 )

Irtak nehanyan, a log-ok shrinkeleset.

Nem igazan latom ertelmet.

Ha mentesz rendesen, akkor a log max. akkorara no, amennyi tranzakciod van a ket teljes mentes kozott. (Full recovery eseten).
Szoval, mikor shrink utan ujra noni kezd a log, akkor feleslegesen terheli ujra a diszket, allitja meg az eppen futo tranzakciokat a log kiterjesztese alatt.
Ezert, ha mentesz (full backup), akkor nem kell sem truncate_only sem shrink, csak tornaztatod a diszkeket (bar SQL 2000-nel ez neha nem mukodik, a log meg csak no...).

A Tiedhez hasonlo problema nalunk is eloallt, bar a terheles csak idoszakos volt.
Mint kiderult egy job egy rosszul megirt lekerdezest futtatott (eleve bakloves direkt SQL-t hasznalni programbol), ami mas adattipust hasznalt (valami varchar es nvarchar elteres volt es meg a meretuk sem egyezett, igy remlik), mint ami az adatbazisban volt, igy allandoan konvertalt es ez ette meg a procit.

Ha hasonlo Nalatok is elofordulhat, nezd meg a Cache Hit Ratio erteket es az SQLCompilations/sec es SQL Recompilations/sec ertekeket (elobbi az SQLServer:Plan Cache , az utobbi az SQLServer:SQL Statistics performance object-ben talalhato)

AWE es "lock pages in memory" be van allitva?
Tegyel mar be egy log filet ide ami kozvetlenul az ujrainditas utan van. Hatha latszik valami.
Hatterinfo:
http://blogs.msdn.com/psssql/archive/2007/10/18/do-i-have-to-assign-the…

http://msdn.microsoft.com/en-us/library/ms190673(SQL.90).aspx

http://msdn.microsoft.com/en-us/library/ms190730(SQL.90).aspx

A parameterek kozott irtad: "2G swap" Ez a page file? Ha igen, akkor az nagyon keves (minimum 2xRAM, de lehet sokkal tobb attol fuggoen, mit csinalsz meg a gepen).

Emberek, ez mind nagyon szep es jo, de amig nem tudjuk, pontosan mi fut a kritikus idoszakban, addig ez mind a vajakolas kategoriaja, nem tobb, es nem kevesebb. Ennyi erovel mondhatnank azt is, hogy format c: biztos megoldja minden jelenlegi gondjat. Lesz mas, de az mar kit erdekel? Szerintem varjunk ki.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Alapjaban egyetertek, de ha megvan, hogy mi fut az emlitett idoszakban, akkor jobb ha meg van hozza az emlitett performance counter-ek erteke. Mert, ha az ertekek alacsonyak, akkor mas iranyban keresendo a dolog, ha meg magasak, akkor jo tampont a tovabbi vizsgalathoz.

Az awe-t meg azert javasoltam, mert azt emlitette, hogy nagy memoria hasznalat eseten latszott erosebbnek a dolog. Lehet, hogy a jelenseg tobb problema egyuttes hatasa.

A performance counterek es rendszerbeallitasok ellenorzese pedig nem reinstall. Szerintem minnel tobb realisan problemat jelentheto dolgot javaslunk ellenorzesre, annal tobb idot sporolunk Neki. Nem kell varnia a "postafordultara". Vagy amig var egyre, meg tudja nezni a masik javasolt dolgot is.

Picit feljebb kaptunk mar performance countereket, nem is egeszen haszontalanokat, most tkp. arra varunk, hogy a topicnyito megossza velunk, mi fut a kerdeses idoszakban.

Kulonben meg elnezest a durva megfogalmazasert, igazabol nem ellened iranyult, csak a topicban mar kezdtek tultengeni a jotanacsok, es nemelyik mar tenyleg a birkavese meg a foldrenges kategoriaja, a folyamat pontos ismerete nelkul. Sem a shrink, sem a reindex nem szupermegoldas, csak egyfajta megoldasa egyfajta problemanak. Ettol meg nem feltetlen ez a problema gyokere.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.