locked
sydepends tábla RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hali,

    Általános nézet, hogy a sysdepends táblát az SQL Server nemigen használja. (Az biztos, hogy a módosítások során nem egészen kifogástalanul kezeli.), és a teljesítményre semmi hatással nincs, ha nem tartalmaz minden függőségi információt.

    Az viszont tapasztalati tény, hogy a módosított adatbázisoknál egyes, a függőségi viszonyok szerint magasabb szinten levő eljárások nagyon lelassulnak (lelassulhatnak) timeout hibát okozva a kliens oldalon.

    A megoldás legtöbbször egy alter procedure illetve drop proc -create proc az eredeti kóddal a lelassult eljárásra.

    Ebből kiindulva valahol réges-régen bevezettünk egy eljárást, ami minden módosító csomag után rendbeteszi a sysdepends táblát. Láss csodát: lassulás, timeout amit az előzőekben leírtam, többé nem fordult elő, pedig 2 év az nagy idő.

    A hosszú bevezető után a kérdés: tud ajánlani valaki valami dokumentációt, ahol esetleg utána lehetne nézni vajon miként is használja az SQL server a sysdepends táblát? (Remélem nem belső MS titok)

     

    MCDEBIL

     

    • Moved by Othorvath Saturday, January 16, 2010 2:44 PM (From:Altalanos SQL kerdesek)
    Monday, March 19, 2007 2:22 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Szia,

    valószínűleg a cached plan-ekkel lesz a gond, de semmi biztosat nem tudok erről, régebben olvastam erről egy fórumon, de semmilyen más doksi-t nem találtam akkor erről. Valaki más esetleg?

    Safi

    Tuesday, March 20, 2007 10:48 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Szia,

    Dokumentációról sajnos nem tudok. De ami a sysdepends tábla használatát illeti, 1-2 cikk alapján lehet valamiféle összefüggés a lekérdezési terv és a függőségek között, ha nem is olyan formában ahogy leírtad. A lineti cikkek alapján az ún. lekérdezési terv létrehozási fázisban a parse-olást végző eljárás használ[hat]ja a sysdepends táblát (ahogy használja, a sysobjects, syscolumns és syscomments táblákat is):

    Kimberly L. Tripp prezentációjából:
    http://www.sqlskills.com/resources/conferences/SAV302-TRIPP-OptProcPerf.pdf
    http://www.theserverside.net/tt/articles/content/DevConnectionsP4/Tripp-OptimizeProcedurePerformance.pdf
    http://www.sql.ru/photos/Tech-Ed03/PPT/DBA322.ppt

    Itt is van rá célzás a témával kapcsolatban:
    http://www.itresourcepartners.com/bssug/downloads/BestCodingPractices.ppt

    Ettől függetlenül a lekérdezési tervek frissülésének elmaradását nem tudtam bizonyítani, hiszen akármikor ALTER-elődik egy olyan objektum amit használ egy másik csak éppen nem kerül be a függőségük a táblába, az objektum maga kap egy bélyeget az újrafordításra (plusz lefut egy SP:CacheRemove) így az őt futtató eljárás is újrafordítódik automatikusan.

    Mivel tényleg nem sok írás foglalkozik ezzel (konkrétan "execution plan" és "sysdepends" vagy "dependency" kulcsszavak), így túl nagy szerepet nem kaphatnak a függőségek a lekérdezési tervben (abban sem vagyok biztos, hogy a fenti linkek megalapozottak-e). A javulást az is okozhatta Nálad, hogy a függőségek rendebetétele pl. a tárolt eljárások megfelelő sorrendben történő ALTER-elését jelentette, az ALTER-elés pedig kiváltotta az újrafordításukat...

    Nálam valóban nem kap semmilyen szerepet a sysdepends (főleg, hogy személyes véleményem az, ez egy elég gyengén implementált feature, főként a szétesését figyelembe véve, bár a célját már-már érteném), mivel napi rendszersséggel ürítem a procedúra cache-t (DBCC FREEPROCCACHE) és újrafordításra jelölölm ki mindegyik objektumot (az összes táblát, amely automatikusan kiváltja az összes őt használó objektum újrafordítódását is, ezt sem a sysdepends alapján, ezt kipróbáltam), valamint frissítem a statisztikákat is (sőt heti 1 alkalommal UPDATE STATISTICS WITH FULLSCAN-t is szoktam futtatni).

    MZ

    Wednesday, March 21, 2007 2:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hali

    Köszi a választ, a K. L. Tripp féle prezentációkat már láttam, de a negyedik sem segített sokat.

    A gáz csak az, hogy a DBCC FREEPROCCACHE nem segített eddig ott, ahol a megfelelelő hierarhiában történő ALTER igen. A statisztikák frissítése sem gyógyít. Ahol eddig találkoztam a problémával, csak két féle gyógymód volt: manuálisan alterel-tünk minden a módosított objektumtól függő objektumot, vagy egyszerűen szkriptből helyreraktuk az egész hierarhiát minden módosítás után. Magyarán szólva szintenként ment az alter minden objektumra.

    Az adatbázisok, ahol találkoztam a jelenséggel mind nagyobbak 50 GB-nél, és ~1000 transactions/sec körüli a terhelés. Automata gyártósorok, illetve jelenleg amivel dolgozom több mint 6 M felhasználó fele lóg a rendszeren.

    Ahogy most látom, ez a kérdés elveszik Redmond sötét bugyraiban.

    MCDEBIL

    Friday, March 23, 2007 3:14 PM