rthsw

Das Transactionlog wird 1 x Monatlich auf 20 Gb gestutzt. 1 x wöchentlich wird ein kompletter Mandant der Datenbank in einen anderen Mandant gespiegel. Dies findet innerhalb einer geschloßenen Transaktion statt, welche das Log so auf ca. 17 Gb bringt. Das Translog wird regelmässig defragmentiert (auf Plattenebene), so das die VLF's recht linear über die Platte wandern, und sich dadurch kein Flaschenhals ergibt. Es sind eigene Platten nur für's Log reserviert, so das auch die Seekzeiten durch die hohe lokalität der normalen Altagstransaktionen im Rahmen bleiben. Würde ich das Log ständig auf ein Gig halten (das würde im Regelfall völlig ausreichen, dann würde mir die Mandantenspiegelung zeitmässig um die Ohren fliegen, weil erst das Log so weit erweitert werden muss. Und: Ja, es ist nötig, das diese Riesenaktion innerhalb einer Transaktion läuft, im Fehlerfall muss ein komplettes, nicht nur ein partielles Redo durchgeführt werden. Deshalb läuft dieses Monster auch nur am Wochenende. – Anmerkung: Das Transactionlog hab ich inzwischen von 60 auf 20 Gb gekürzt. Aber 20 Gb * 32 = 640 Gb (+ die Monatssicherungen) sind immer noch viel Speicher für den Müll. Ein Umstellen in den Simple-Mode nach dem Einlesen löscht die ldf-datei nicht, also müsste ich diese erst shrinken. Das könnte ich sparen, wenn ich so was wie Restore with truncate, oder Restore without Tranlog oder irgendsoeinen lustigen Befehl hätte. Gibts das?

Hi ich hab schon viel gesucht, gegoogelt udn auch die SQL-books online durchstöbert, aber mein wunsch scheint zu exotisch zu sein. Vielleicht hat jemand von euch einen Hack für mich? Unser Prdouktivsystem läuft auf einem MS-SQL 2000 Server im Recoverymode Full. Das ist gut so und soll so bleiben. Daraus wird jede Nacht eine komplette Datensicherung gezogen, und ca. alle 2 Stunden eine Transactionlogsicherung (with init). Das ist auch gut so. Aus dieser Sicherung wird jede Nacht eine Testumgebung mit unterscheidlichen Namen erstellt (Fin_01 Fin_02 Fin03 tec, für jeden Tag des Monats eine Version). Insgesammt halten wir pro Tag eine aktuelle, pro Tag des Monats eine, und pro Monat eine komplette Datensicherung für Testzwecke vor. (á ca. 75 Gb Daten + ca. 60 Gb Translog, wobei das Translog nur zu ca 3 % gefüllt ist) Diese Testversionen brauchen massig speicherplatz, und laufen daher auf komprimierten Laufwerken. Das Rücklesen benötigt pro version (2-3 Stck pro Tag) ca. 2 Std. Ein Verlust dieser Datenbanken, eine Beschädigung der Inhalte, Probleme mit der Datenbank sind völlig nebensächlich, da sie automatisch am nächsten tag erneut erstellt wird bzw. spätestens nach einen Monat durch die neue Tagessicherung ersetzt wird. Ich möchte aus der vollständigen Sicherung, die ohnehin und weiterhin jede Nacht läuft), wie bisher eine komplette Datenbank zurückzulesen ("restore with replace, move"), ABER dies OHNE das Transactionlog (welches ohnehin so gut wie leer ist), und diese Datenbank im recoverymode simple betreiben (wegen Geschwindigkeit auf den komprimierten Laufwerken). Ein Alter Database NACH dem Einlesen der Sicherung hilft zwar für den testbetrieb, aber dann wurde bereits unnötigerweise eine 60 Gb Transactionlogdatei geschrieben. Ein Alter Database VOR dem Einlesen bringt nichts, weil ich die Datenbank ja vorher löschen muss/sollte, damit das Restore fehlerfrei läuft. Ein Replace ist zwar schon drin, aber doppelt hält besser. Beim Restorecommand finde ich keinen Befehl, der das Transactionlog ignoriert/neu anlegt. Bei manueller Einlesung kann ich das Transactionlog nicht deaktivieren, aber wenn ich ein Datenbank detach/Atacht durchführe, kann ich es weglassen. Aber dafür muss ich wieder jeden Tag manuell eingreifen. Die Modeldatenbank wurde bereits auf Simple gestellt, aber das interessiert den SQL2000 beim Restore nicht. Hat jemand einen Tip für mich, wie ich mir die 60Gb und die Zeit dafür sparen kann? Weil ich insgesammt 32 Datenbanken (+ die Monatssicherungen) regelmässig per Script aktualisiere, wäre eine TSQL-Lösung wunderbar. Der CopyDatabaseWizzard hilft nicht, weil ich damit nur eine einzige Datenbank mit dem Namen der Originaldatenbank anlegen kann.