DBCC freeproccache?

kysymyksiä on joka puolella, joten yritän vastata niihin kaikkiin. Toimenpide välimuisti on vain niin suuri. Menettelyvälimuistisi on voitu täyttää kertakäyttöisillä suunnitelmilla (tällä ei ole vaikutusta tilastoihin, vaikka tilastot voivat vaikuttaa suunnitelman välimuistiin). Voit lukea paljon yksityiskohtia kertakäyttöisistä suunnitelmista Kimberly Trippin blogikirjoituksesta ”Plan cache and optimizing for adhoc workloads” -mukaan lukien kysely SYS.dm_exec_cached_plansia vastaan, joka auttaa tunnistamaan, milloin välimuistissa on paljon kertakäyttöisiä suunnitelmia. Kuten hän ehdottaa, voit estää tämän turvotus käyttämällä optimoida ad hoc työtaakkaa. Jos on tarve tehdä tätä usein, sanoisin, että freeprocachen aikatauluttaminen työksi on laastari, ei ratkaisu.

”huonon” suunnitelman tyhjentämiseksi täytyy ensin tunnistaa ”huono” suunnitelma. Tämä voi olla suunnitelma, joka ylittää tietyn koon ja / tai ei ole toteutettu jonkin aikaa, tai että olet tunnistanut pitkäaikainen kysely, jne. Valitettavasti ei ole helppoa tunnistaa suunnitelmaa, joka on parametrin haistelun uhri, ellet jo tiedä kyselyn tai kyselyt, jotka vaikuttavat. Oletetaan, että haluat löytää kätköstä vanhimmat suunnitelmat, joita ei ole ajettu yli viikkoon.:

;WITH x AS ( SELECT TOP 10 qs., qs.plan_handle, txs = qs.statement_start_offset, txe = qs.statement_end_offset, = cp.size_in_bytes, = SUM(cp.usecounts), = MAX(qs.last_execution_time) FROM sys.dm_exec_query_stats AS qs INNER JOIN sys.dm_exec_cached_plans AS cp ON qs.plan_handle = cp.plan_handle WHERE qs.last_execution_time < DATEADD(DAY, -7, CURRENT_TIMESTAMP) GROUP BY qs., qs.plan_handle, cp.size_in_bytes, qs.statement_start_offset, qs.statement_end_offset ORDER BY DESC) SELECT x.plan_handle, size, uses, , = COALESCE(NULLIF( SUBSTRING(t., x.txs/2, CASE WHEN x.txe = -1 THEN 0 ELSE (x.txe - x.txs)/2 END ), ''), t.) FROM x CROSS APPLY sys.dm_exec_sql_text(x.) AS t;

nyt sinun täytyy tarkistaa, että todella haluat tyhjentää tämän suunnitelman. Jos esimerkiksi tunnistat, että kysely on jotain toimitusjohtaja saattaa ajaa huomenna, ehkä on parasta jättää se siihen. Jos haluat selvittää suunnitelman, voit selvittää sen suoraan sanomalla:

DBCC FREEPROCCACHE();

tämä kuulostaa paljon työläämmältä kuin DBCC FREEPROCCACHE ajaminen globaalisti, mutta jos välimuistissa on paljon hyviä suunnitelmia, se on varmasti parempi käyttäjilleen kaiken kaikkiaan.

silti tämä todella kuulostaa laastarilta. Jos välimuisti on täyttymässä roskaa ja suorituskyky menee WC, kunnes vapauttaa välimuisti, sinun täytyy tarkastella korkeamman tason arkkitehtuuri, miten kyselyt lähetetään, jne. Tätä käyttäytymistä odottaisin LINQ2SQL: n ensimmäisestä iteraatiosta, jossa se kätkisi suunnitelman version jokaisen string-argumentin kyselylle, joka oli eripituinen. Joten jos sinulla olisi parametri ’Tammikuu’, saisit erilaisen suunnitelman kuin parametrilla’ Helmikuu’, koska se määrittelisi tietotyypin arvoksi VARCHAR(7) vs. VARCHAR(8). Melko varma, että käyttäytyminen on kiinteä, mutta en tiedä tarpeeksi ympäristö / sovellus ehdottaa, mistä tarkalleen etsiä ” huonoja ideoita.”