[Firebird] Datensätze in Backup-DB verschieben/spiegeln

[messie]

Moin,

ich habe eine ständig wachsende Datenbank und möchte aus Geschwindigkeitsgründen Datensätze in eine Backup-DB verschieben. Wenn ich das mit INSERT mache, bekomme ich für jedes Datum einen neuen Index. Das ist zu Fuß recht umständlich.

Ist es möglich, Daten en bloque unter Beibehaltung der Indices in eine andere Datenbank mit identischer Struktur zu verschieben? Die nicht verschobenen Indices wären zunächst frei und würden dann gefüllt falls der entsprechende Datensatz auch verschoben wird.

Für ein paar Stichworte wäre ich sehr dankbar.

Grüße, Messie

[mkinzler]

Die Größe einer Datenbank hat nicht unbedingt etwas mit der Performance zu tun.

Zitat:

Wenn ich das mit INSERT mache, bekomme ich für jedes Datum einen neuen Index. Das ist zu Fuß recht umständlich.

Meint Du eine neue ID. Das kommt auf das Insertstatement an bzw. den Trigger

Insert .. SELECT funktioniert m.W. nicht bei Crossdatenbank-Abfragen, würde aber gehen, wenn du diese nur in eine andere Tabelle verschieben willst.

[messie]

Zitat von mkinzler:

Die Größe einer Datenbank hat nicht unbedingt etwas mit der Performance zu tun.

Zitat:

Wenn ich das mit INSERT mache, bekomme ich für jedes Datum einen neuen Index. Das ist zu Fuß recht umständlich.

Meint Du eine neue ID. Das kommt auf das Insertstatement an bzw. den Trigger

Insert .. SELECT funktioniert m.W. nicht bei Crossdatenbank-Abfragen, würde aber gehen, wenn du diese nur in eine andere Tabelle verschieben willst.

Hallo Markus,

ja, ich meinte die neue ID. Die Backup-DB würde ich identisch mit der Original-DB aufbauen, also auch mit den Triggern.

Verstehe ich das richtig, dass dort ein Konstrukt

Code:

INSERT INTO <BackupDB1,BackupDB2,BackupDB3,...>
select <große Query die alle Datensätze zu einem Auftrag lädt>

reichen würde? Bekomme ich dann neue IDs?
Denn ich würde evtl. auch eine Abfrage einbauen wollen, die nach einer vorhandenen Auftrags-ID bzw. den IDs in den anderenTabellen sucht.


Grüße, Messie

[mkinzler]

Es kann nur eine Zieltabelle geben, diese kann mit der Quelltabelle übereinstimmen. Die Feldliste muss identisch sei (Anzahl/Reihenfolge der Typen)
Insert into <Ziel-Tabelle>(<Feldliste>) select <Feldliste> from <Quell-Tabelle>; Ob neue IDs vergeben werden hängt vom Trigger ab, wirkt er nur bei leerem PK Feld, dann werden die originären Ids verwendet; vergibt der Trigger aber grundsätzlich neue Werte dann nicht. In diesem Fall müsstest Du die Trigger vorher deaktiviren.

[messie]

Zitat von mkinzler:

Es kann nur eine Zieltabelle geben, diese kann mit der Quelltabelle übereinstimmen. Die Feldliste muss identisch sei (Anzahl/Reihenfolge der Typen)

Hallo Markus,

mir fehlt noch ein kleiner Baustein: Wie rufe ich zwei identische Tabellen in unterschiedlichen DB auf? Gibt es etwas wie Datenbank1.Tabelle1 und Datenbank2.Tabelle1?

Grüße, Messie

[mkinzler]

So einfach nicht, deshalb riet ich ja zu Tabellen statt Datenbanken. Seit FB 2.5 gibt es die Möglichkeit in PSQL Afragen auf andere Datenbanken abzusetzen; die möglichkeiten sind aber noch sehr bschränkt, es sind keine Joins o.ä. möglich, aber datenbankübergreifende Transaktionen.

SQL-Code:

execute block returns (<Felder von externer Datenbanktabelle>) as
begin
FOR EXECUTE STATEMENT 'select <Felder von externer Datenbanktabelle> from <externer Datenbanktabelle>'
ON EXTERNAL DATA SOURCE '<Host>:<externe Datenbank>' AS USER 'sysdba' PASSWORD 'masterkey'
INTO <Paramterliste>
DO SUSPEND;
end;

[Blup]

Zitat von messie:

Wenn ich das mit INSERT mache, bekomme ich für jedes Datum einen neuen Index. Das ist zu Fuß recht umständlich.

Ist es möglich, Daten en bloque unter Beibehaltung der Indices in eine andere Datenbank mit identischer Struktur zu verschieben? Die nicht verschobenen Indices wären zunächst frei und würden dann gefüllt falls der entsprechende Datensatz auch verschoben wird.

Für mich hört sich das nach einer ungünstigen Datenstruktur an, nach dem Motto für jeden Tag eine neue Tabelle.
Normalerweise hat man nur eine Tabelle und die Datensätze haben eine Spalte Datum.
Dann braucht sich die Datenstruktur auch nicht jeden Tag zu ändern.

Zum Thema:
Eine 1:1 Kopie der aktuellen Datenbank erstellen (z.B. als Shadow erstellen und dann abkoppeln) und als Archiv ablegen.
In der aktuellen Datenbank alle nicht benötigten Daten löschen.
Mehr Aufwand lohnt sich nicht.

[tsteinmaurer]

Eine andere Möglichkeit wäre das Ganze asynchron über eine uni-direktionale Replikation zu machen. Zum Beispiel: http://www.iblogmanager.com/download...hotstandby.htm

[himitsu]

Wenn du die Daten unbedingt aufteilen willst, dann gäbe es auch noch die Partitionierung von Tabellen.


Spiegeln verändert doch erstmal nichts an der Performance.
Man kann da bei vielen Zugriffen die Zugriffe auf unterschiedliche DB-Server verteilen und hat dann in der Masse mehr Leistung.
Bzw. man hat immer ein aktuelles Backup.

Wobei Backup: Wenn man in der einen DB ausversehn etwas ändert/löscht, dann ist es in der anderen DB praktisch auch gleich weg.
Es wäre also nur ein hochaktuelles Backup zum Abfangen eines Serverausfalls, wo man auch gleich auf das andere System umschalten könnte.

PS:
http://entwickler-forum.de/archive/i...p/t-40590.html
http://www.delphipraxis.net/162657-e...tenbanken.html
http://www.ibexpert.net/ibe_de/index...ecommendations

[mkinzler]

Zitat:

Wenn du die Daten unbedingt aufteilen willst, dann gäbe es auch noch die Partitionierung von Tabellen.

Das wird aber nicht von allen DBMS unterstützt, z.B. von dem es hier geht nicht.