TransactionLog verwalten

[lnaemi]

Hallo!
ich habe einen sql-datenbank(2008 R2).
standard recovery model: full
durch einen Importtool(x64-c#) wird jeden Tag millionen Datensätze in meinem Datenbak hinzugefügt (ausser eine Tabelle werden alle andere Tabellen ducrh den Tool die Daten weggelöscht und die neue daten hinzugefügt. es gibt aber eine sehr wichtige tabelle, die nie weggelöscht werden darf).
und dann werden mehrere Views ausgeführt und viele Reports rausgeschickt (Reporting Server).

mein transactionLog wächst ja unglaublich, ich habe maintance-geschrieben, die rechtzeitig backup und schrink ausführen muss, aber einwandfrei funktionieren sie nicht. deshalb habe ich immer montags probleme mit datenbank, so wie "logfile groß-keine imports wurden durchgeführt".

letzte Woche habe ich den recovery model auf bulk-logged geändert und heute war sehr erschreckend. viele tabellen waren leer , logfile riesig, und die tabelle, die nie weggelöscht wird, war auch Leer!!! (nirgendwo im Tool oder sql existiert für diese Tabelle eine delete -befehl ), kann mir jemand sagen, was los ist??


ich habe jetzt ein paar neue jobs erstellt (tägliche Jobs):
job1: vor import, recovery model auf simple ändern, logfile shrinken, und recovery model auf Bulk-logged ändern
job2: nach dem import recovery model aud full ändern
einen job für nur freitag: fullbackup und shrink db.

kann mir jemand was besseres empfehlen??

Danke im Voraus
lnaemi

[O. Helper]

Hallo lnaemi,

alle Transaktionen werden nun mal in Log geschrieben und wenn große Datenmengen geändert werden, wächst es halt. Wie löscht Du z.B. die Tabelleninhalte, mit DELETE oder TRUNCATE TABLE; letztes wird nur minimal protokolliert.

Wenn ich Dein Szenario richtig verstehe, baust Du da ein Datawarehouse auf und die einzigen Transaktionen, die es im Großen gibt, ist der ETL Prozess.
Wenn Du also nicht wirklich LOG-Sicherungen benötigst, um z.B. bis zu einem bestimmten Zeitpunkt rücksichern willst/musst, könntest Du das RecoveryModel auf Simple stellen und es dabei belassen. Brauchst Du trotzdem noch zwischendurch Sicherungen, könntest Du ein Differential Backup machen.

Das "viele Tabellen" leer waren, liegt aber nicht am Ändern des RecoveryModels, da wird eher Dein ETL Prozess schief gelaufen sein.