Datenquelle leeren
Author: kraemer
Publication Date: 3/28/2013 10:32
Hallo,
wir haben in einem Projekt eine Datenquelle, in der sehr viele Datensätze (>100k) importiert wurden. Die würde ich jetzt gerne los, zumal sie auch das System nicht unbedingt schneller machen. Gibt es eine Möglichkeit die Daten wirklich zu löschen, im im Work- und Release-State?
Ich weiss schon wie ich sie per Skript über Content2 löschen kann, aber am liebsten wäre mir wirklich auch die History loszuwerden. Dafür suche ich einen Weg und wäre über Hinweise dankbar.
Grüsse
Michael
Tags: content2, database, datenbank, datenquelle
-
Author: broszeit - 4/2/2013 11:22
Hallo,
haben diese Datensätze Fremdschlüsselbeziehungen? Wenn nein, dann können sie am einfachsten direkt aus der Datenbank gelöscht werden. Dies geschieht natürlich auf eigene Gefahr und sollte mit größter Vorsicht gemacht werden.
Alternativ kann man im Projekt die Datensätze zuerst per Skript über Content2 löschen und das Projekt dann exportieren. Beim Export kann man auswählen, dass man nur neuere Revisionen als das Löschdatum exportieren möchte. Nach dem erneuten Importieren des Projekts sind die gelöschten Datensätze nicht mehr vorhanden. Es werden hierbei aber auch alle anderen alten Revisionen entfernt, deshalb sollte überlegt werden ob das in Kauf genommen werden kann.
Als dritter Ansatz könnte noch überlegt werden, ob die Projektarchivierung (evtl. auch EnterpriseBackup Funktionalität) hierfür genutzt werden kann, ohne das wirklich wichtige Informationen verloren gehen.
Viele Grüße
Rouven
0 -
Author: kraemer - 4/2/2013 12:28
Hallo Rouven,
vielen Dank für die Info. Die Datensätze haben Fremdschlüsselbeziehungen, allerdings ist die Tabelle die ich löschen möchte (price) die N-Seite der 1:N Beziehung (zur Tabelle product). In einer normalen relationalen DB wären die FKs also sowieso in der Tabelle die ich löschen möchte. Ich weiss allerdings nicht, wie FirstSpirit die Daten in der SQL ablegt.
Gibt es eine Doku darüber, wie die Datenquellen in SQL persistiert werden, so dass ich sehe was ich ggf. beachten muss? Mich würde vor allem interessieren was mit ForeignKeys und der History passiert.
Den Projektexport / -import möchte ich gern vermeiden, ich möchte nicht die History von allem verlieren.
Gibt es dazu noch ein paar Informationen?
Grüsse
Michael
0 -
Author: Peter_Jodeleit - 4/2/2013 14:34
Über Projekt-Ex/Import geht keine Historie verloren.
0 -
Author: kraemer - 4/2/2013 15:09
Peter Jodeleit schrieb:
Über Projekt-Ex/Import geht keine Historie verloren.
So wie in diesem Kontext hier besprochen geht sie verloren. Wie auch immer, ich hoffe es gibt noch ein paar Infos zu dem SQL-Thema wie oben geschrieben.
0 -
Author: Peter_Jodeleit - 4/3/2013 7:34
Ich bezog mich auf diese Aussage von dir:
Den Projektexport / -import möchte ich gern vermeiden, ich möchte nicht die History von allem verlieren.
0 -
Author: klein - 4/4/2013 16:00
Hi Michael,
>allerdings ist die Tabelle die ich löschen möchte (price) die N-Seite der 1:N Beziehung (zur Tabelle product).
d.h. ein Produkt hat mehrere Preise?
>In einer normalen relationalen DB wären die FKs also sowieso in der Tabelle die ich löschen möchte
richtig, auch in FS existiert in diesem Fall eine FK-Spalte in der Tabelle "price", die auf die PK der Tabelle "product" verweist und die in Deinem Fall so heißen müsste "<FKTAB>_fs_id".
D.h. wenn Du nun alle Werte in der Tabelle "price" löschst, werden in der entsprechenden Komponetente in der Tabelle "product" leere Werte angezeigt :smileysad:
Also sollst Du nicht alles löschen, sondern nur die historischen Datensätze. Das kann man über ein Delete-Statement direkt in der DB tun. Dies ist jedoch kein offizieller Weg und die Durchführung eines manuellen DB-Eingriffs erfolgt daher auf eigene Gefahr!
Ein solches DB-Statement sieht wie folgt aus:
DELETE FROM <DB_NAME>.<TABLE_NAME> t0 where t0.fs_release_to<9223372036854775807 and t0.fs_valid_to<9223372036854775807
Desweiteren kannst auch die Datensätze löschen, die zwar aktuell sind (also keine histotische Datensätze), aber die in der Tabelle "product" nicht referenziert werden.
DELETE FROM <DB_NAME>.<TABLE_NAME> t0 where t0.<FKTAB>_fs_id=null
Entschließt man sich, diesen Weg zu wählen, dann sollte man vorher sicherheitshalber ein DB-Backup durchführen.
Gruß,
Walter.
0 -
Author: kraemer - 4/5/2013 17:00
Hallo Walter,
danke, ich bin dabei es zu testen.
Gruss
Michael
0 -
Author: kraemer - 4/10/2013 7:45
Ich habe das Löschen getestet, aber gestern hat mir der Client im Anschluss OR-Fehler angezeigt, daher gehe ich nochmal im Detail auf deine Antworten ein.
klein schrieb:
d.h. ein Produkt hat mehrere Preise?
ja
klein schrieb:
richtig, auch in FS existiert in diesem Fall eine FK-Spalte in der Tabelle "price", die auf die PK der Tabelle "product" verweist und die in Deinem Fall so heißen müsste "<FKTAB>_fs_id".
D.h. wenn Du nun alle Werte in der Tabelle "price" löschst, werden in der entsprechenden Komponetente in der Tabelle "product" leere Werte angezeigt :smileysad:
Was meinst du denn mit leeren Werten? Da die Spalte mit dem FK in der Tabelle price steht, müssten doch einfach die Produkte noch da sein, aber dürften keine Preise mehr haben. Oder?
klein schrieb:
Ein solches DB-Statement sieht wie folgt aus:
DELETE FROM <DB_NAME>.<TABLE_NAME> t0 where t0.fs_release_to<9223372036854775807 and t0.fs_valid_to<9223372036854775807
Die 9223372036854775807 ist eine Konstante? Oder welches Time-Format ist das?
Da ich die Daten alle nicht mehr brauche und komplett neu importieren werde, könnte ich auch initial per Script via FS die Datensätze im Arbeits- und Freigabestand einmal komplett löschen, damit wäre die Datenquelle aus Sicht des Clients leer. Wäre das ein einfacher (und tendenziell zuverlässiger) Weg, um danach per SQL die Tabelle zu putzen?
Und noch eine generelle Frage: Sollte ich nach einer DB-Änderung den Server (und die Clients?) neu starten, oder den Server sowieso runterfahren vorher?
Grüsse
Michael
0 -
Author: thmarx - 7/25/2013 9:03
Hallo Michael,
hast du für dein Problem schon ein Lösung gefunden?
Ja bei 9223372036854775807 handelt es sich um einen interne Konstante.
Viele Grüße
Thorsten
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
9 Kommentare