Goedendag, momenteel bouwen wij een Acceptatie omgeving op door simpelweg een backup van sql-server te restoren naar een separate sql server.
Echter nu is er vanuit het bedrijf de vraag of we niet x Acceptatie omgevingen kunnen opzetten voor bepaalde specifieke toepassingen.
Nu kan dit op de huidige manier uiteraard gebeuren, alleen vanuit management is de vraag gekomen of dit niet goedkoper kan, aangezien we enkele tabellen hebben die 80% van de data vertegenwoordigen die niet relevant zijn voor deze nieuwe acceptatie omgevingen.
De totale database betreft 500 Gb en wat er nodig is voor deze acceptatie omgevingen vertegenwoordigt slechts 100Gb.
We hebben wat zitten experimenteren met :
- standaard backup terugzetten
- Met scripts de foreign keys uitzetten, tabellen truncaten en foreign keys weer recreaten
- nieuwe backup maken
- nieuwe backup restoren voor de nieuwe omgevingen.
Alleen stap 2 blijft hierbij extreem lang duren (ter indicatie, backup restoren duurt 30 minuten voor totale dbase, stap 2 blijft ergens rond de 3 uur duren)
Nu proberen we het probleem eens om te draaien en te kijken hoe we we in een lege database via scripts en metadata tabellen kunnen opbouwen om die daarna te kunnen vullen.
Alleen het begon makkelijk : Select * from tableA into tableB where 1=2
Alleen nu lopen we toch tegen allerlei issues aan in de range van constraints die moeilijk te kopieren zijn, default values die moeilijk te achterhalen zijn, computed columns die problematisch zijn en dat is slechts bij de schema's, bij de data voorzien we nog issues met referentiele integriteit die eerst uit moet tijdens kopieren en daarna aan moet, het behouden van id's terwijl de originele tabel automatische id's kent etc.
En nu zat ik mezelf even af te vragen iemand de problematiek kent (dus gedeeltelijke database kopieren) en of we hier wel op de goede weg zijn, of dat de huidige weg een wekenlang project gaat worden om alle uitzonderingen goed te krijgen.
Kijk opzich kunnen er best een aantal dagen aan gespendeerd worden, maar het gaat al heel snel worden dat ontwikkeluren kosten vs storage kosten gaan betekenen dat we jaren vooruit kunnen met meer storage ipv weken te gaan steken in dit soort scriptjes.
Of zijn er bestaande oplossingen voor?
Echter nu is er vanuit het bedrijf de vraag of we niet x Acceptatie omgevingen kunnen opzetten voor bepaalde specifieke toepassingen.
Nu kan dit op de huidige manier uiteraard gebeuren, alleen vanuit management is de vraag gekomen of dit niet goedkoper kan, aangezien we enkele tabellen hebben die 80% van de data vertegenwoordigen die niet relevant zijn voor deze nieuwe acceptatie omgevingen.
De totale database betreft 500 Gb en wat er nodig is voor deze acceptatie omgevingen vertegenwoordigt slechts 100Gb.
We hebben wat zitten experimenteren met :
- standaard backup terugzetten
- Met scripts de foreign keys uitzetten, tabellen truncaten en foreign keys weer recreaten
- nieuwe backup maken
- nieuwe backup restoren voor de nieuwe omgevingen.
Alleen stap 2 blijft hierbij extreem lang duren (ter indicatie, backup restoren duurt 30 minuten voor totale dbase, stap 2 blijft ergens rond de 3 uur duren)
Nu proberen we het probleem eens om te draaien en te kijken hoe we we in een lege database via scripts en metadata tabellen kunnen opbouwen om die daarna te kunnen vullen.
Alleen het begon makkelijk : Select * from tableA into tableB where 1=2
Alleen nu lopen we toch tegen allerlei issues aan in de range van constraints die moeilijk te kopieren zijn, default values die moeilijk te achterhalen zijn, computed columns die problematisch zijn en dat is slechts bij de schema's, bij de data voorzien we nog issues met referentiele integriteit die eerst uit moet tijdens kopieren en daarna aan moet, het behouden van id's terwijl de originele tabel automatische id's kent etc.
En nu zat ik mezelf even af te vragen iemand de problematiek kent (dus gedeeltelijke database kopieren) en of we hier wel op de goede weg zijn, of dat de huidige weg een wekenlang project gaat worden om alle uitzonderingen goed te krijgen.
Kijk opzich kunnen er best een aantal dagen aan gespendeerd worden, maar het gaat al heel snel worden dat ontwikkeluren kosten vs storage kosten gaan betekenen dat we jaren vooruit kunnen met meer storage ipv weken te gaan steken in dit soort scriptjes.
Of zijn er bestaande oplossingen voor?