[MSSQL 2005] Andere collation vreet geheugen

[Xion]

Ik ben een beetje ten einde raad.

Ik heb vanochtend een database omgezet naar een andere collation, van SQL_Latin1_General_CP1_CI_AS => Latin1_General_CI_AS (lees: ook elke column omgezet.)

Sindsdien vreet de SQL Server bijna dubbel zoveel geheugen dan normaal. Tot overmaat van ramp wordt de server traag en kunnen mensen bijna niet werken op ons intranet. De CPU load is echter niet veel anders dan normaal.

Nou ben ik geen database expert, maar dit lijkt me toch geen normaal gedrag? Google biedt tevens weinig uitkomst, ik kan niet echt overeenkomstige problemen vinden.

Zijn er mensen die dit probleem kennen?


Nog wat specs:
- SQL 2005 Workgroup Server
- Windows 2003 Standaard
- Intel Xeon 3.2 Ghz
- 2 GB geheugen

NB: Vanavond zal ik nog proberen de database te reorganiseren / shrinken, misschien haalt dat nog iets uit.

[lier]

Wat is je initiële reden geweest om de collation aan te passen ?

[Xion]

Voornamelijk vanwege de sortering, zie:

code:

SQL_Latin1_General_CP1_CI_AS     Latin1_General_CI_AS
---------------------------------------------------------
Foto                             Foto
Foto's                           Foto1
Foto-lijst                       Foto-lijst
Foto1                            Foto's

Waarbij ik de tweede kolom het beste vind. Tevens las ik op diverse sites dat deze collation wordt aangeraden tenzij je compatible wil blijven met oudere versies of replicatie servers.
Toen ik van de gekkigheid niet meer wist wat ik moest doen, heb ik alles terug gezet naar SQL collation, maar dat hielp ook niet. Uit eindelijk kwam ik het volgende script tegen:

SQL:

DECLARE tabcurs CURSOR FOR
                        SELECT NAME
                        FROM sysobjects
                        WHERE xtype = 'u'
OPEN tabcurs

DECLARE @tname VARCHAR(300)

FETCH NEXT FROM tabcurs INTO @tname
WHILE @@fetch_status = 0
    BEGIN
        PRINT 'Reindexing: ' + @tname
        DBCC dbreindex(@tname)
        FETCH NEXT FROM tabcurs INTO @tname
    END
CLOSE tabcurs

DEALLOCATE tabcurs
PRINT 'Klaar'

Dit zorgde er weer voor dat de database een fatsoenlijke grootte kreeg. En alles loopt weer zoals voorheen.

Ik heb nu in een test omgeving alles weer op de 'Latin1_General_CI_AS' collation gezet en het script uitgevoerd, dit geeft een goed resultaat. Alleen groeit de database bij de eerste de beste insert met 200 MB (550 MB naar 760 MB). Dat heeft volgens mij met de reservering van ruimte te maken, maar op de productie doet ie dit niet met de standaard SQL collation.

(Excuus voor mijn late reactie, maar ik ben nogal druk geweest)

[ Voor 9% gewijzigd door Xion op 15-05-2008 10:42 ]

[Fiander]

Heb je met de profiler gekeken wat er op de server gebeurde op het moment dat ie traag was?
lage CPU load betekend meestal veel HD IO.

hoe is je server ingericht ?
Gescheiden disks ?
log op andere schijven ?
sectorgroote van je Data drive ?
zijn je schijven überhaupt ntfs ?

verder is 2GB wat weinig voor een productie server.

wat betreft de vergroting zodra je een insert doet. dat komt omdat je je database geschriked hebt.
iets wat je eigenlijks NOOIT zou moeten doen. door te schrinken, en daarna de db weer te laten groeien fragmenteer je je schijf heel erg, en das niet goed. Als er gepland word dat een app een db van 1GB nodig zal hebben in de toekomst, dan maak je de database meteen die groote, dat voorkomt fragmenteren, en geeft ook een duidelijk beeld over hoeveel capaciteit een server nog heeft.
en aangezien vrije ruimte geen backup ruimte kost....

[ Voor 44% gewijzigd door Fiander op 16-05-2008 10:27 ]

[Xion]

Ik heb op dat moment niet met de profiler gegeken, echter de performance monitor gaf idd 100% IO activiteit.

Het is op dit moment nog 1 server met 2 schijven in een mirror (2 NTFS partities). De log staat dus
op dezelfde schijf.

2 GB is idd krap, maar nu alles weer normal draait is dat goed te doen. De provider heeft ons ook voorgesteld om over te stappen naar een opstelling met 2 twee servers (load balanced) en 1 storage aparaat (raid 5).

wat betreft de vergroting zodra je een insert doet. dat komt omdat je je database geschriked hebt.

Dat begrijp ik, wat ik echter minder goed snap is het verschil (in groei) tussen de twee collations (zie vorige post).

Het schrinken was overigens wel nodig, want de db was driemaal groter dan normaal, dat lijkt me ook niet echt de bedoeling, afgezien van het geheugen en IO gebruik.

[StevenK]

Heb je de SQL server een memory-limit gegeven?

[Xion]

StevenK schreef op zaterdag 17 mei 2008 @ 14:22:
Heb je de SQL server een memory-limit gegeven?

Ja, maar...

Die stond altijd op 1200 MB en dat heeft altijd gefunctioneerd. Dit kwam echter omdat ie dat nooit haalde. Toen de db zo enorm gegroeid was, ging die daar wel over heen / tegen aan. Dat heeft denk ik ook de 100% IO activiteit veroorzaakt.

Ik heb later het limit weggehaald en toen was het systeem weer werkbaar. Welliswaar met een SQL load van 1,5 GB, maar er kon gewerkt worden.

En daarna heb ik het het probleem opgelost zoals ik eerder had beschreven.

Tja, met vallen en opstaan leer je, dat blijkt.