Capiz
#0
Hej.
Jeg er lidt ny på cluster sql, og jeg har fået til opgave at finde en løsning på et omfattende fragmenterings problem.
I dag har vi 2 servere, mirror setup. Men vi har rigtig mange entiteter i databasen, og det gør vores dB rigtig langsom, specielt hvis vi ikke får fragmenteret ordentligt, og ofte.
Det jeg tænker er, om det er muligt at køre de entiteter der på ugentlig basis ryger ind på serveren, og så de entiteter der er over 1 uge gammel, skal på en anden sql server "archive".
Vi snakker måske 300.000 entiteter på en uge.
Ydermere, kan man have en fælles søgning for begge databaser?
Håber det er forståeligt, ellers må i spørge ind til det i mangler informationer om.
Mvh
Rasmus
Jeg er lidt ny på cluster sql, og jeg har fået til opgave at finde en løsning på et omfattende fragmenterings problem.
I dag har vi 2 servere, mirror setup. Men vi har rigtig mange entiteter i databasen, og det gør vores dB rigtig langsom, specielt hvis vi ikke får fragmenteret ordentligt, og ofte.
Det jeg tænker er, om det er muligt at køre de entiteter der på ugentlig basis ryger ind på serveren, og så de entiteter der er over 1 uge gammel, skal på en anden sql server "archive".
Vi snakker måske 300.000 entiteter på en uge.
Ydermere, kan man have en fælles søgning for begge databaser?
Håber det er forståeligt, ellers må i spørge ind til det i mangler informationer om.
Mvh
Rasmus
#1
Hvad med at smide jeres SQL DB'er over på nogle Enterprise SSD'er?
Ved det er en dyr løsning, men det burde afhjælpe problemet :)
Ved det er en dyr løsning, men det burde afhjælpe problemet :)
#2
Det virker mere som dårlig optimeret tabeller / forespørgsler 300k er jo ikke voldsomt meget...(ms sql server management studio kan lave performance måling/forslag
Du kunne også overveje at smide det i noget datawarehouse
Du burde kunne lave views på begge db via union select
Men har I ram nok og bruger i outer joins etc
Du kunne også overveje at smide det i noget datawarehouse
Du burde kunne lave views på begge db via union select
Men har I ram nok og bruger i outer joins etc
#3
Det er også latterligt dårlige tabeller... Random guid, som id.
Men vi begynder på sequentially id, men lige nu tager indexering knap 24 timer, hvilket er helt sindsygt.
Har ingen ide om datawarehouse, eller union select.
Ram har vi rigeligt af, og outer joins bed jeg heller ikke.
Men vi begynder på sequentially id, men lige nu tager indexering knap 24 timer, hvilket er helt sindsygt.
Har ingen ide om datawarehouse, eller union select.
Ram har vi rigeligt af, og outer joins bed jeg heller ikke.
#4
Fine diske, men det bliver sq dyrt i drift.. ??