Update probleem SQLServer database

[Verwijderd]

De dagelijkse update van onze database (SQLServer 2000) verliep tot voor kort zonder enig probleem. Het betreft hier een gewone update van 7 tabellen. Dagelijks wordt er hier door een heel team van mensen nieuwe data ingevoerd, deze data wordt dan tijdens het update proces doorgesluisd naar onze Backup- SQLServer, en eens hier alles in orde is, wordt deze data gekopieerd naar onze "Live" SQLServer toegankelijk voor onze klanten.
Dit hele proces duurde oorspronkelijk ongeveer 3 uur.
We gebruikten hiervoor een relatief simpele package in de DTS-manager. Deze stond gepland om 5 uur 's morgens en tegen 8u was alles klaar.

Het probleem is nu dat door een gebrek aan bandbreedte onze "live" SQLServer verhuisd is naar een andere locatie. Hierdoor is de doorvoersnelheid naar die server voor ons natuurlijk verminderd. Resultaat, deze update duurt ineens 14 uur.
Dit is uiteraard onaanvaardbaar.

Ik heb al vanalles opgezocht en hetgeen ik nu geprobeerd heb is om met BCP de data van onze backup server naar een bestand te exporteren, dit bestand te zippen en door te sturen. Op de Live server wordt dit bestand dan automatisch unzipped, de oude tabel wordt leeggemaakt en de nieuwe data wordt geimporteerd.

Dit is inderdaad een heel stuk sneller, maar het probleem is dus dat er een hele tijd helemaal geen data staat in de verschillende tabellen. Dit kan dus ook niet.

Is er iemand die een idee heeft hoe dit dan wel kan?
(Als iemand nog meer info nodig heeft, vraag gerust)

[The Eagle]

Ik weet niet hoever het is van jullie locatie naar de andere locatie, maar is het anders een optie om de nieuwe data op tape of cd te kwatsen en op de andere locatie te importeren?

[Verwijderd]

Dit zou inderdaad een makkelijke en simpele oplossing zijn, maar in dit geval spijtig genoeg niet haalbaar ...

[TAA]

Een 2e "backup" server op locatie bij de live server voorzien van de automatische import van tabellen en van hieruit een update doen zoals in de oude situatie?

[Verwijderd]

Geen idee wat de hoeveelheid data is die dagelijks ververst wordt, maar ik zou het gebruik van incrementele updates (alleen dat updaten wat daadwerkelijk gewijzigd is) gaan overwegen.
Ik ken ook de complexiteit niet van de database, maar met een dag knutselen zou je toch een end moeten komen.
Praten we over 64k lijntjes?

[Verwijderd]

Je zipped het nu, maar er zijn nog een aantal wat betere formaten te vinden dan zip. Het is voorlopig misschien niet dé oplossing maar je zou eens kunnen kijken naar die andere formaten: 10 tot 20% winnen moet wel lukken, wat zich ook weer uit in het snellere overzenden natuurlijk

[lordgandalf]

en als je eens ipv het direct over smijten eens een sql bestand exporteerd en dan die weer importeerd in je live server heb je alleen tijdens het opbouwen even legen tabellen.
En anders een manier weten te fixen die een update statement brouwt en die over knalt en uitvoert.

my 2 cents

PS: het gaat de TS niet over het overzenden imo maar over dat ie eerst de DB leeg gooit voordat ie de nieuwe + aangepaste data importeerd dit is in feiten dubbel werk

[ Voor 23% gewijzigd door lordgandalf op 20-09-2004 09:51 ]

[Verwijderd]

Al ns naar SQL Server replicatie gekeken?

[soepkip]

of distributed transactions ?

[Verwijderd]

Maak een backup van de databases naar een .bak file op de harddisk, schedule dat, en dan kun je die rustig naar de backup-server transferren en daar weer restoren. Dan is de impact op de databaseserver het minste (denk ik)

[FragFrog]

Correct me if I'm wrong (SQL server n00b hier ), maar is het restoren van een database niet langzamer dan het importeren van data?

Maar als ik het goed begrijp hebben je klanten alleen read acces op je primary SQL server, en wordt de data eens per dag geupdate? Wat nu als je de backup server in je server group gooit en/of tijdelijk je ODBC links aanpast zodat ze tijdens het restore proces de backup server gebruiken? Of zit ik nu weer dom te l*llen?