MS SQL 2005 anvender alt RAM og gør serveren sløv

Det oplever vi også. Til sidst fylder servicen 2Gb. Vi løste det med en skeduelret genstart af servicen. Bemærk (inden andre gør dig opmærksom på det), jeg er ingen adm-haj på SQL-server - og har i øvrigt ingen idé til hvorfor servicen nogle gange tæller ram og og andre gange kører perfekt ... så jeg lytter med nu.

Lyder sært at websider ikke kan tilgåes, Sql Serveren bruger alt ram som den kan få man frigiver det ligeså hurtigt igen når andre processer har brug for det.
Det som justeres i hukommelsesgrænsen er hvor meget Sql Serveren vil frigive ned til, men altså når rammen ikke er brug så suger den :)
Som oftest burde det ikke medføre problemer.

http://support.microsoft.com/kb/321363

Troubleshooting:
http://support.microsoft.com/kb/907877

Side note:
Den memory setting man kan stille på og angive max memory, gælder kun for buffer poolen - altså data pages der gemmes i mem. Derudover bruger sql serveren mem til cachede planer bl.a., og det kan sagtens fylde meget, hvis man sløser om sig med ikke-parameteriseret sql i sin applikation.

sjang: Hvad mener du med "ikke-parameteriseret sql"?

select * from name = 'ditnavn'
select * from name = 'ditnavnd'

Følgende vil give 2 cache plans. Da den på forhånd ikke kender typen.

de skulle gerne være noget ala:
select * from name = @name

@name er så typen etc. og så vil den kunne genbruge den cache plan.

sjang kan måske rette mig .... og give sql til at finde ud af om det er problemet.

mvh

Du har helt ret, og en af de klassiske måde at lave sådanne queries på, er hvis man fra applikationslaget - fx asp, skriver sådan noget med (pseudo kode):

dim sql
sql = "select * from mintabel where navn = " & navn
execute(sql)

Man kan kigge i plan cachen efter det potentielle problem ved denne:

WITH PlanCache
AS
(
SELECT
    bucketid,
    usecounts,
    size_in_bytes/1024 size_in_KBytes,
    creation_time,
    last_execution_time,
    execution_count,
    total_worker_time,
    total_physical_reads,
    total_logical_reads,
    total_elapsed_time,
    text,
    ROW_NUMBER() OVER(PARTITION BY bucketid ORDER BY bucketid) AS rn
FROM
    sys.dm_exec_cached_plans t1
    LEFT JOIN sys.dm_exec_query_stats t2 ON t1.plan_handle = t2.plan_handle
    OUTER APPLY sys.dm_exec_sql_text(sql_handle)
WHERE text IS NOT NULL
)
SELECT * INTO #tmp FROM PlanCache
WHERE
    rn = 1

SELECT * FROM #tmp
ORDER BY text

Det man skal kigge efter, er en masse rækker, hvor text kolonnen er "ens", dvs hvor selve sql'en er ens, men hvor parametrene er forskellige... lige som i buzzzz's eksempel. Disse vil typisk have usecount på 1 eller 2, hvor de i stedet burde have én row i plan cachen, med usecount 1000 (eller hvor mange gange det pågældende kode nu er blevet eksekveret).


Hvis man vil vide hvor mange MB der ligger i ens plan cache, kan man så sige:

select sum(size_in_KBytes)/1024. from #tmp