Konzept zur Datenbanktrennung.

[Pro_RJ]

Hallo,
Ich hab die Aufgabe bekommen, aus einer großen FirebirdDatenbank 2 kleine Datenbanken zu machen.
Der Grund dafür ist, das in einer Tabelle sich in 2.5 Jahren etwar 95 Mio. Datensätze angesammelt haben.
Die Aufgabe besteht darin, alle Datensätze die älter als z.B. 30 Tage sind in eine 2. Datenbank auszulagern und sie aus der OrginalDB zu löschen.

Jetzt die Frage wie könnte man sowas einfach und PFLEGBAR realisieren?
Das Hauptproblem liegt darin, das diese ausgelagerten Daten auch für Auswertungen benötigt werden.
1.
Gibt es die möglichkeit in einem Select Statement zu sagen

SQL-Code:

Select 
DatenbankA.Feld_1,DatenbankA.Feld_2,DatenbankA.Feld_3,DatenbankA.Feld_4,
DatenbankB.Feld_1,DatenbankB.Feld_1,DatenbankB.Feld_1
from DatenbankA,DatenbankB
where .....

2.
Besteht die möglichkeit in einem Trigger zu sagen Kopiere Datensatz von DatenbankA nach DatenbankB?

3. Wie kann man das in den Anzeigen im Programm steuern. Das mal daten aus DatenbankA angezeigt werden und mal aus DatenbankB?

Ich hoffe ich konnte mein Vorhaben einigermaßen verständlich darlegen.
Eventuell hat ja jemand schon ein paar Erfahrungen mit einem solchen system bzw. einer solchen Umstellung.
Für Gedankenanstöße,Ideen,Tip wäre ich sehr dankbar.

[Elvis]

Das mag sich jetzt ziemlich blöd anhören, aber eigentlich sollte diese Maßnahme nicht notwendig sein.

Wenn du die DB abfragst, sollten die Felde, die zum Filtern nötig sind, indiziert sein.
Indizierte Suchen bedeuten, dass die Größe der Tabelle nur noch eine sehr, sehr kleine Rolle spielt.

Magst du vielleicht mal die Abfragen zeigen, die euch Sorgen machen? Und vllt auch die Table DDLs dazu?
Eigentlich sollten wir einen Weg findne können wie du alles in einer DB halten kannst, ohne dass es langsam wird.

[s.h.a.r.k]

den grund verstehe ich auch nicht ganz? du wirst dir schon nicht jedes mal die komplette datenbank per SELECT ausgeben lassen? sondern eben nur die letzten paar tage, oder? selbst wenn du dann die tabelle aufsplittest wird es ja dadurch nicht besser, da dann ja auch wieder die riesen datenmengen bekommst, in so fern dein SELECT nicht wirklich eingeschränkt ist.

eine datenbank selbst *muss* mit solchen großen datenmengen umgehen können.

interessant wäre es wirklich so wissen, was ihr damit bewecken wollt und eben dafür einen, ich sag mal salop, besseren weg finden.

[Pro_RJ]

ja das ist absolut richtig, ich selber bin auch kein Freund von einer solchen Aufteilung. Dafür hat man ja ein ein-Dateien-system.
Das Problem ist die DB ist ca 30gb groß.
Jede Datensicherung dauert dem Kunden zu lange. Er brauch für Backup/Restore mittlerweile über 10 Stunden.
Bei dieser Datenbankaufteilung geht es um das Handling der DatenbankDatei an sich und weniger und das Reduzieren der Daten.
Das Daten suchen an sich dauert ja auch nicht lange da in dieser Tabelle nur über den PrimärIndex gelesen wird.
Bei dem Auslagern geht es darum die Hauptdatenbank um ca 20-25 GB zu verkleinern. Sodas das sichern und Backup/Restore der HauptDB an sich schneller geht.

[mkinzler]

Ab FB2.5 sind Abfragen auf andere Datenbanken bedingt möglich. Du könntest also per SP Daten aus 2 DBs zusammenfügen.

[Pro_RJ]

Zitat:

Zitat von mkinzler

Ab FB2.5 sind Abfragen auf andere Datenbanken bedingt möglich. Du könntest also per SP Daten aus 2 DBs zusammenfügen.

Geht der Zugriff auf 2 DBs schon im FB 2.1 oder erst ab 2.5?
oder hättest du da einen anderen Lösungsansatz für mein Problem?

Es geht darum, die Datenbankgröße zu reduzieren.Und daten auszulagern, die nicht ständig benötigt werden.

[mkinzler]

Ab 2.5 heisst ab 2.5

[s.h.a.r.k]

mal ganz dumm gefragt? was kann daran 10 stunden lang dauern :gruebel:

[Pro_RJ]

Zitat:

Zitat von s.h.a.r.k

mal ganz dumm gefragt? was kann daran 10 stunden lang dauern :gruebel:

Keine ahnung was daran so lange dauert. Wir machen das Backup Restore über TIBBackupservice/TIBRestoreservice Komponenten. Das sind die die im BDS2006 Standardmäßig drinne sind. Was jetzt genau an dem Vorgang lange dauert weis ich leider nicht?Aber ich schaue mal ob ich genaue Zeiten bekomme

[s.h.a.r.k]

weil ich die zeiten für sehr unrealistisch erachten, außer die sichtern auf disketten und müssen eben sehr viele davon immer reinschieben :D

jedenfalls bevor du die datenbank teilst würde ich mir auf jeden fall mal gedanken drüber machen, wie du das bisherige problem angehen kannst, denn deine software umzubauen, wegen sowas? erachte ich als ein bisschen fehl am platz. ich baue an ein auto auch keinen fünften oder sechsten reifen hin, nur weil andere platt sind. ich hoffe du verstehst was ich damit meine. denn es kann nicht normal sein, dass man 10 stunden oder auch nur 2 für ein 30gb backup braucht. oder sehe ich das falsch? :gruebel: