Jump to content

Indexe Neuerstellen in großer DB mit Modus Vollständig


Direkt zur Lösung Gelöst von NilsK,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Geschrieben

Hallo Zusammen,

 

wie kann ich bei dem Thema am besten vorgehen, die Datenbank ist > 100 GB und läuft im Vollständigen Modus.

Eine Sicherung der Protokolle läuft von Mo - Fr und 07:00 - 19:00 Uhr, alle 30 Minuten.

Am Wochenende würde ich gerne die Indexe Neuerstellen lassen, das resultiert aber in einem riesigen Logfile, bis die Platte voll ist.

 

Was macht Ihr in einem solchen Fall? Die DB vorher in den Einfachen Modus versetzen, dann wäre aber ja wieder der Sicherungssatz hinüber...

 

Gruß

  • Beste Lösung
Geschrieben

Moin,

 

wenn in dem Fall die Logfiles vollaufen, hast du zwei Möglichkeiten

  1. während des Vorgangs keine (bleibenden) Logfiles erzeugen
  2. während des Vorgangs aggressiv die Logfiles in kurzer Frequenz sichern

In Fall 2 brauchst du den Platz dann eben woanders. Und du verzögerst den Vorgang - ob das spürbar ist, kann ich aus der Ferne nicht beurteilen.

In Fall 1 würde ich die Datenbank umkonfigurieren, ein Full Backup machen und dann loslegen. Nach Abschluss des Vorgangs die Datenbank wieder auf "Full" setzen und sofort ein Full Backup, dann die Log Backups wieder einrichten.

 

Gruß, Nils

Geschrieben

Hi

was spricht dagegen solche große DBs im SIMPLE Modus laufen zu lassen.

 

wir fahren etliche DBs jede um die 200GB im Simple Modus und reorg der wichtigisten IDX laufen mal grade 20 Minuten.

 

Diff laufen mehrmals am Tage (10 Minuten, Full-backp abends (30Minuten)

 

@TE

was habt ihr denn für Reorg- und Backuplauftzeiten.

Geschrieben

allerdings hat der TE das Problem, keinen Platz für die logs zu haben und aber gleichzeitig die Notwendigkeit eines Reorgs.

 

Da kommt er um den Simple modus für die Dauer des Reorges NICHT herum. Da muss er einen Tod sterben. Da können wir

 

ihn nicht bei helfen.

 

vllt sollte der TE mal aufzeigen welchen Charakter die DB hat: OLTP , OLAP, Batch, Transit.

Geschrieben

Moin,

 

grundsätzlich spricht überhaupt nichts gegen den Simple Mode. der ist nicht irgendwie böse oder prinzipiell unangemessen. Wie "wiri" schon richtig sagt, ist es eine Frage der Anforderungen - und da erleben wir es in der IT leider viel zu oft, dass die völlig ungeklärt sind. Ich bin ebenfalls der Meinung, dass für sehr viele Datenbanken der Simple Mode in Wirklichkeit die bessere Wahl ist, weil ohnehin in der Praxis nur Full Backups gemacht (und wiederhergestellt) werden.

 

Beim Full Mode muss man erhebliche Sorgfalt aufwenden. Das muss sich lohnen oder zwingend nötig sein. Sonst ist Simple vielleicht wirklich besser.

 

Gruß, Nils

Geschrieben

Hi

sowie Nils es gesagt hat, haben bei uns ne externe Fa. die Sharepoint Serverfarm aufgesetzt und dort waren alle DB auf Simple.

 

Da einen genauen Zeitstempelrecovery hinzulegen in faktisch ein Ding der Unmöglichkeit.

Geschrieben

Nur weil es eine externe Firma so macht ist das nicht immer das richtigste. Vermutlich wurde das nie definiert, wie der Recovery Mode gesetzt werden soll.

 

Es geht ja nicht nur um einen Point In Time Restore, sondern auch das man einen Restore machen kann ohne Datenverlust (!).

Geschrieben

Moin,

 


Es geht ja nicht nur um einen Point In Time Restore, sondern auch das man einen Restore machen kann ohne Datenverlust (!).

 

es spricht ja auch überhaupt nichts gegen das Full Recovery Model - wenn man es braucht. Da es aber erhebliche Folgen hat, wenn man es einschaltet (und sich bei uns mindestens einmal pro Monat ein Kunde meldet, dem die Log-Disks vollgelaufen sind, weil er im Full-Model keine Log-Backups gemacht hat), empfehle ich es heute auch nicht mehr pauschal. Denn viele brauchen es eben nicht, weil sie keine Anforderung dafür haben.

 


http://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/

 

Gruß, Nils

Geschrieben

Hallo zusammen,

 

hier wurde ja kräfitg diskutiert :) Danke.

Ich werde vermutlich die Lösung von NilsK fahren, per TSQL vorher die DB auf Simple und danach auf Full setzen, jeweils mit einem Vollbackup.

 

Die Anforderung ist eigentlich schon da, es handelt sich um ein Warenwirtschaftssystem, meist im Zusammenhang mit einer Fibu.

Sollte es wirklich zu einem Crash kommen, dann bin ich über jede Sekunde die ich wiederherstellen kann froh.

 

Einen Nachteil durch den Modus Full konnte ich bisher nicht feststellen, außer das die Logs eben bei gewissen Transaktionen enorm anwachsen können.

So gewaltige Transaktionen sind ja aber nicht an der Tagesordnung, es dreht sich hier nur um den Reorg (oder um Kollegen die meinen 10 Mio. Datensätze zu updaten, die sind dann aber selbst schuld).

 

Gruß und danke.

Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...