Tabellen Optimieren / Archivieren

Hallo,

ich habe eine Tabelle in der sehr viele Datensätze sind.
Um den Zugriff (Performance) auf diese Tabelle zu verbessern habe ich überlegt, alte Datensätze zu Archivieren in eine andere Tabelle.
In der Original Tabelle würden nur noch die Primärschlüssel relevanten Daten bleiben. Nach dem Archivieren würde ich den Inhalt der nicht mehr benötigten Felder löschen.
Meine Fragen:
1. Wenn ich nach dem Archivieren die Tabellenoptimierung von Navision durchlaufen lasse, müsste sich der Platzbedarf der Original Tabelle verringern
2. Eine Tabelle die auf diese weise vom Ballast befreit würde, müsste eine bessere Performace haben, oder liege ich da falsch

3. Habt ihr andere Ideen ?
Gruß Mikka

der Platzbedarf sollte sich nicht ändern, wenn keine Blobfelder dabei sind, solange du die Felder nur leermachst und nicht aus dem Design entfernst.
insofern wird auch die Performance nicht besser werden.
Vorrausgesetzt du hast die Optimierung vor dem Löschen auch laufen lassen um einen eindeutigen Vergleichswert zu haben.
Wenn nicht, wird schon die Optimierung was bringen, ohne dass du was löschen musst.

[...]
1. Wenn ich nach dem Archivieren die Tabellenoptimierung von Navision durchlaufen lasse, müsste sich der Platzbedarf der Original Tabelle verringern
[...]

VORSICHT! Die Navision-Datenbank-Funktion "Tabelle optimieren" sorgt nicht für einen Performance-Schub, sondern ordnet die Daten nur direkt hintereinander auf der Festplatte an!
Dies ist gerade bei Datenbanken, welche über mehrere Festplatten verteilt laufen, schädlich für die Performance!

Siehe hierzu auch meine Anmerkungen.

Bei nur einer Platte und dann auch noch einen Defrag bei beendetem Server wird die Performance nach der Optimierung allerdings besser sein.... aber das hilft dem Mikka sicher auch nicht weiter.

Hach was bin ich wieder ein Schelm heute

Hallo,
danke für eure Beiträge.
Ist mir einleuchtend.
Ich habe Überlegt, das die Performance von mehreren Punkten aus Betrachtet werden muss.
Einmal von DB + Hardware & Co. Seite aus.
Und einmal von der Logischen Seite, also dem Ablauf wie Navision die Daten behandelt.

Wenn ich eine Tabelle habe in der jedes Feld einen Eintrag hat, diese dann sortiere und durchsuche,
muss Navision jedes Feld prüfen obwohl dort Einträge aus dem 18`ten Jahrhundert drin sind

In der Optimierten (Vom Ballast befreiten Tabelle) sind alle alten Felder leer, außer die Prim Key Felder (mal abgesehen von den Neueinträgen!).
Wenn ich nach einem Secondary Key sortiere und dann einen Eintrag suche, muss Navision nur noch die Neueinträge durchsuchen, da die "alten" Felder leer sind und nach dem Index ganz unten stehen!
Für das Suchen bzw. Filtern im Prim.Key bringt das natürlich nichts!
Mir fällt gerade noch ein, das eine "Vom Ballast befreite" Tabelle natürlich auch für den Anwender übersichtlicher ist!

Oder seit Ihr da anderer Meinung?
Gruß Mikka
(Hier Schneit es! Juhu.....)

Optimierte Tabellen haben allerdings immer weniger Platzbedarf. Wenn die Datenbank schon bei 85 % steht und neue Hardware noch nicht verfügbar ist,
regelmäßig optimieren. Besonders die Postentabellen mit Millionen Datensätzen nehmen dann etliche 100 MB weniger Platz als vorher in Anspruch. In diesem Fall lieber einen Performanceverlust als den Betriebsstillstand in Kauf nehmen.

Ich hoffe das mir das mit dem Platzmangel nicht Passieren wird. Wenn doch, behalte ich es im Hinterkopf.
Gruß Mikka

Ich habe nochmal darüber Nachgedacht --> Raid und Datenbanken

Timo Lässer hat geschrieben
VORSICHT! Die Navision-Datenbank-Funktion "Tabelle optimieren" sorgt nicht für einen Performance-Schub, sondern ordnet die Daten nur direkt hintereinander auf der Festplatte an!
Dies ist gerade bei Datenbanken, welche über mehrere Festplatten verteilt laufen, schädlich für die Performance!

Hmm, ich will ja nicht deinen Erfahrungen wiedersprechen, aber sollte ein Raid Array z.B. 1 oder 5 nicht die Daten Verteilt schreiben.
Der Controller der Festplatten schreibt die Daten gleichzeitig auf alle verfügbaren HDDs(Zur erhöung der Performace)! Wenn das nicht so währe, würde ein Raid ja nur die Datensicherheit erhöhen durch Redundanz!
Also ist meiner Meinung nach der Raidcontroller uninteressant bezüglich diesen Themas.

Was wohl ehr zutrifft ist, das die DB Intern sequentiell angeordnet wurde und diese einer "Gewissen" Anlaufzeit bedarf
Es erscheint mir so, als wenn Navision mit einer Fragmentierten DB besser zurecht kommt?! (Wobei ich nicht die DB Internas genau kenne!)
Gruß Mikka

[...]
Was wohl ehr zutrifft ist, das die DB Intern sequentiell angeordnet wurde und diese einer "Gewissen" Anlaufzeit bedarf
[...]

Richtig, Navision schreibt die zusammengehörenden Daten einer Tabelle bei der Optimierung direkt hintereinander in die Datenbank.

[...]
Es erscheint mir so, als wenn Navision mit einer Fragmentierten DB besser zurecht kommt?! (Wobei ich nicht die DB Internas genau kenne!)
Gruß Mikka

Rein theoretisch (!) käme Navision mit einer optimierten Tabelle besser zurecht, da es für das Lesen der Datensätze nur einmal auf die Festplatte zugreifen müsste.
Da in 99% der Fälle jedoch mehrere User gleichzeitig auf die Daten einer Tabelle zugreifen ist es sinnvoller, wenn diese Daten über mehrere Festplatten verteilt liegen, da dann mehrere Festplatten (und somit mehrere Leseköpfe) gleichzeitig die Daten zur Verfügung stellen können.


Wie ein RAID-System die aktuell zu schreibenden Daten über die Festplatten verteilt ist mir jetzt nicht ganz geläufig.
Für die Performance von Navision ist es auf jeden Fall von großem Vorteil, wenn die Daten einer Tabelle gleichmäßig über alle Festplatten verteilt sind.

Bei einem Raid 1 System unter Voraussetzung das jede Platte ihren eigenen Kanal hat, hat folgende Vorteile / Eigenschaften.
1. Die Daten werden gespiegelt, daher auch Mirroring
2. Beim Schreiben der Daten keinen nenneswerten Performacegewinn
3. Beim Lesen verdoppelt sich nahezu die Geschwindigkeit gegenüber einem Einzelplatten System (Daher gut für DBs!)
4. Die Daten bleiben bei Ausfall einer Platte erhalten

Weitere Informationen hierzu kann ich unter: http://www.tecchannel.de/storage/grundlagen/401665/ empfehlen.

Timo Lässler schrieb
Wie ein RAID-System die aktuell zu schreibenden Daten über die Festplatten verteilt ist mir jetzt nicht ganz geläufig.
Für die Performance von Navision ist es auf jeden Fall von großem Vorteil, wenn die Daten einer Tabelle gleichmäßig über alle Festplatten verteilt sind.

Da die Daten also nur als Kopie der ersten Platte vorliegen, kann der spürbare Geschwindigkeitszuwachs nicht an dem Raid 1 System liegen.
Hier muss die Interne DB-Struktur verantwortlich sein, nicht das Raid, da die Daten schon verteilt worden sind!
Gruß Mikka

Optimierte Tabellen haben allerdings immer weniger Platzbedarf. Wenn die Datenbank schon bei 85 % steht und neue Hardware noch nicht verfügbar ist,
regelmäßig optimieren. Besonders die Postentabellen mit Millionen Datensätzen nehmen dann etliche 100 MB weniger Platz als vorher in Anspruch. In diesem Fall lieber einen Performanceverlust als den Betriebsstillstand in Kauf nehmen.

Ich habe unsere DB Optimiert (Grösse 29 GB, DB-Art: Nativ), die Werte sahen wie folgt aus:
Auslastung vor der Optimierung: 78 %
Auslastung nach der Optimierung: 61 %

Von Performanceeinbrüchen nach der Optimierung kann ich nicht nicht sprechen.
Ich kann daher dieses nur weiterempfehlen, auch wenn die DB evtl. die ersten Tage nach der Optimierung langsamer sein soll.

Hinweiß:
Die Optimierung ist ca. 4 - 5 Wochen her und die Auslastung ist jetzt bei 68%, was dem "normalen" zuwachs unserer DB entspricht.
Daher würde ich behaupten (zumindest bei unserer DB), das Altdaten nicht alzu stark sich wieder Fragmentieren.