[alg] SQL Server Data Archiveren

[Scare360]

Stel: ik heb een database vol met data omtrent een productie proces (bv auto's) en wil deze data i.v.m. de regelgeving archiveren (jaarlijks). Probleem is dat een back-up draaien van de db betekend dat de server waar de productie db op draait te zwaar belast wordt. De productie mag in geen geval in gevaar komen en zou het dus wenselijk zijn om het back-uppen van data s'nachts te doen en wel met een lage proces prioriteit.

Iemand ervaring in deze richting? Betreft een SQL Server db. Ik dacht zelf aan een service ontwikkelen die periodiek data overpompt, probleem is dat dit dus de "werk db" vertraagt en dus risico met zich meebrengt.

[Verwijderd]

Je kan zelf bv stored procedures schrijven die maar een bepaalde tijd mogen draaien.
(door condities toe te voegen, die een tijd check uitvoeren; WHILE @maxtijd < @currenttijd)

Mbv je SP kan je dan je data overpompen naar andere tabellen in een andere database. Door deze te schedulen ('snachts) kan je ze laten draaien in de periodes dat het systeem het minst belast wordt...

[Annie]

Als een volledige database backup te veel vraagt van de server kan je misschien de backups "opsplitsen". M.a.w. 1 malig een full backup en daarna differentials bijhouden of transaction log backups (of een combinatie daarvan) en deze bewaren voor een jaargang.
Alle backups opgeteld zijn dan weer je volledige backup (kost je natuurlijk wel behoorlijk wat tijd om een eventuele restore uit te voeren als je jaargang uit veel backups bestaat).

Andere optie is misschien de database dubbel uitvoeren en met bijv. log shipping de tweede database up-to-date houden. De backup kan dan jaarlijks op het tweede systeem gedaan worden.
En bovendien heb je dan een failover systeem, 2 vliegen in 1 klap

Meer info bijvoorbeeld in de resource kit of een willekeurig ander (goed) boek over sql server.
Let wel dat dit niet het standaard sql werk is en als het inderdaad zo belangrijk is als je het doet voorkomen lijkt het me verstandig als je er door een pro naar laat kijken.

[ Voor 4% gewijzigd door Annie op 04-02-2003 18:42 ]

[Verwijderd]

Ehh, zeg je dus eigenlijk dat de productie db op dit moment nooit gebackupt wordt omdat dan de machine te zwaar belast wordt??

[EfBe]

met dts heb je in no time vele rows overgesjoeld. Gaat het om vele miljoenen rows of niet? Indien niet, dan is een DTS job wellicht een optie. Die kun je in een job starten welke je schedulet in de sql agent.

[Scare360]

Verwijderd schreef op 04 februari 2003 @ 20:03:
Ehh, zeg je dus eigenlijk dat de productie db op dit moment nooit gebackupt wordt omdat dan de machine te zwaar belast wordt??

Nee, maar zodra productie lijnen leeggedraaid worden is de werkdatabase op voorraadbeheer etc nagenoeg leeg. Om aan de wetgeving te voldoen alsmede het tracking & tracing systeem geen invloed op de werkdatabase te laten hebben MOET er wel aan data wharehousing gedaan worden. Nu worden s'nachts mutaties uitgevoerd, ivm track & tracing moet dit ook geforceerd kunnen worden, wat nu als gevolg heeft dat de hele fabriek plat gaat. Dit komt weer door locks, waardoor alle clients time-outs krijgen en op control nivo dus alles in de soep loopt.

[brainstorm-mode]
Ik dacht aan periodiek data overhevelen naar de historie db, waarna ik de history db een datamodel vult (lazy load), dit model wordt gebruikt voor de view (met name track & trace data) Dit gaat dus echt over enorme data hoeveelheden.
[/brainstorm-mode]

Ik neem alle ideen mee in een vooronderzoek... bedankt voor de reacties tot dusver!

EfBe: Inderdaad, maar wellicht is het toch een optie. Momenteel wordt getest of een batch door de plant gedraaid is en/of processen deze nog vast houden, zo ja wordt deze aan de history toegevoegd. Die werkdatabase MOET gewoon zo min mogelijk belast worden. In de plant wordt van alle kanten vanuit middleware op de database gehamerd... komt er nog eens bij dat de implementaties niet_je_van_het zijn.

[ Voor 16% gewijzigd door Scare360 op 04-02-2003 21:04 ]