Hejsan
jag har ett problem med vår miljö.
Vi har db servrar med MS SQL server 2000. Vi har en Merge replikering mellan servrarna som går var 10:e minut. Det tas en fullbackupp en gång per dygn och sedan transationsbackupp var timme.
Eftersom vi använder mergereplikering så är våra identity kolumner GUID:s.
Alla databaserna accessas 24/7 med en ganska hög belastning dygnet runt.
Jag behöver hjälp med att bygga om indexen på databaserna.
Blir konstant problem med låsningar och för långa svarstider till klienterna när vi försöker bygga om indexen.
Hur löser jag detta problemet?

Om problemet är fragmenterade index kan du testa att köra DBCC INDEXDEFRAG + UPDATE STATISTICS istället för DBREINDEX, då denna ska vara betydligt snällare i låsningen av tabeller. Har ingen erfarenhet av det själv dock.

Varför bygger ni om indexen? Vad är det för typ av miljö?
Ofta, i vanliga transaktionssystem, kan det räcka att uppdatera statistik för att få bra (t.o.m. bättre än vid rebuild) prestanda.

/micke

Ska kolla på uppdatera statistiken för att se om det hjläper.

Men jag vill bygga om indexen eftersom vi har ca 500.000 transaktioner per dygn på ca 15 tabeller.
Allt från nyinläggningar till uppdatering av befintliga poster.
Och med GUID som klustrat index så blir det väldigt spritt.
Och det är en realtidsmiljö på klienterna så gäller det att hålla svartiderna nere.

Är som sagt inte så erfaren av det hära men det låter lite overkill att ha inkludera GUID:et i ett klustrat index - både för att själva indexet då blir större (ett guid är väl typ 16 bytes eller nåt sånt?) och för att det inte är monotont ökande.

Kanske vore det värt att ta en engångs-prestandasmäll och byta klustrat index till en annan kolumn för att i framtiden kunna slippa köra lika frekventa/tunga DBREINDEX? Eller tänker jag galet nu?

GUID används för att du kan göra insert på alla servrar.
De ska sedan flyttas till runt och då får de inte krocka med andras id.
Egentligen finns det två sätt att använda id:en vid Merge replikering,
GUIDs för de blir unika. Eller ett sammatsatt index med två kolumner, där en är tex en räknare och den andra anger usrprungsserver. Tillsamans blir de unika i systemet.

Jo exakt, men måste du verkligen ha GUIDarna som klustrade index? Går det inte att välja en annan kolumn att skapa klusterindexet på men fortfarande ha GUID som primärnyckel (eller på annat sätt garantera att GUID-kolumnen är unik)?

Jag måste ha guidarna som klustrade index då Merge replikeringen använder sig av dem vid replikering. Annars skulle det ta för lång tid.

1. Du kan ha GUIDarna som NONCLUSTERED primary key också.
2. OM du nu har GUIDar som klustrade, så är det ju inga dubletter - eller? Då spelar det ingen roll om ditt index ligger huller om buller, eller om du kör en indexdefragmentering, för du plockar ändå bara ut en(1) post i taget - Eller kör ni med WHERE GuidCol Like 'aac%' ????
Detta gäller för övrigt även om inte GUID är klustrat, för det finns säkert ett par kolumner som skulle vara bättre klustrade än just en unik kolumn.

/micke

1 Ja, det går. Men inte önskvärt då det är stor skillnad på svarstiderna mellan ett klustrat och ett icke klustrat index.
2 Ett klustrat index behöver inte vara unika poster. Unika index poster kan användas både på klustrade och icke klustrade index.

Det jag behöver är ett sätt att bygga om indexen i produktion.

1. Som jag skrev innan: Det är en mariginell skillnad mellan klustrat och icke klustrat index på en primärnyckel. Har du testat att göra din primärnyckel ickeklustrad?
2. Du missuppfattade totalt denna del... Jag ger en lösning, ställde inga frågor!

Lösning:
Gör primärnyckeln icke klustrad
Sluta optimera databasens index

Mät sedan prestandaskillnaden före och efter. Vad har du att förlora, eftersom det uppenbarligen inte funkar nu.
Det finns inget sätt att bygga om indexen i produktion som inte påverkar prestandan MYCKET!

Utom möjligtvis att köpa en SQL 2005 Enterprise (från 130000:-) och bygga om indexen ONLINE

/micke

Hepp
Jag jagar millisekunder på varje select, update eller insert.
I testmaskinerna "vinner" jag 3-5 ms vid rebuild av index.
De största vinterna görs i Merge replikeringens egna tabeller.
Men då står maskinen "låst" i 1 timme. Den tiden har jag inte i produktion :(
Har inte provat ändra nycklarna som du föreslår. Men ska göra det i test.
Ska se om det ger några vinster.

Måste bara slinka in med en kommentar, även om jag vet 0 om ämnet ni diskuterar.

Om maskinen står låst 1 timme när du gör en Merge replikering så kan det väl inte vara så svårt att vinna över den tiden? 1 h = 3,6 miljoner millisekunder som förloras. ;)

Men som sagt, kan inget om ämnet i sig :)

Vill bara flinka in lite...

Det finns många faktorer...
Men några grejer att titta på är fillfactor, kolla radbredden och kolla av hur många rader som ryms i en datasida. Gör sedan ett överslag på hur många rader som tillkommer per datasida vid din tunga merge. Med det i tanke räknar du ut hur mycket utrymme du behöver förallockera. Dvs FILLFACTOR på det klustrade indexet, flika på PAD_INDEX med när du ändå håller på.

Sedan skulle jag kolla på definitionen av tabellerna, inte bara index. Många var-kolumner med data som förändras i längd, dvs blir längre resulterar i flytt av raden inom datasidan vilket ökar io.

Tror inte heller att din GUID behöver vara med i det klustrade indexet. Kolla på Range'r av data och på dina förändringar, låt det återspegla klustrade index. Precis som Wedham säger. Använder du GUID för unika uppslag låt då den vara ett icke-klustrat index istället. Håll även ner antalet kombinerade index, och framförallt gäller det här din klustrade index.

Har du flera fysiska disksubsystem. Smeta på en gäng filgrupper och placera index i andra filgrupper, eller flytta ut det klustarade indexet till en annan filgrupp. Då flyttar du även tabellen. Ligger allt på samma fysiska disksubsystem bygger optimizern en serialiserad exekveringsplan, flera fysiska disksubsystem så försöker den parallellisera.

Lite tips, är trött i skallen - det är sent...

Lycka till!
Mattias