Verbindung 2er Tabellen, zeitlich gesteuert (Archiv- + Tages-aktuelle Daten)

Werbung:
Ok bin ich grad dran :)

Wie lautet hier der richtige Kopier-Befehl unter Auftragseigenschaften -> Schritte -> Befehl?
Ich habe hier das gescripptet:

INSERT INTO [dbo].[ACOSA_Monitoring_Taeglich (-Archiv-)]
SELECT * FROM [dbo].[ACOSA_Monitoring_Taeglich (-Daily-)]
GO

Spaltenanzahl und -Eigenschaften identisch, aber hier wird ein Fehler bei der Analyse ausgegeben:
View or function 'dbo.ACOSA_Monitoring_Taeglich (-Archiv-)' is not updatable because the modification affects multiple base tables.

Beide Views wurden zu Testzwecken mit je 1 Tag kreiert (Tabelle Archiv: 20.07.2021 / Tabelle Daily: 21.07.2021).

LG Romero
 
Chuky666 schrieb:
Kann man auch machen. Ich hätte da aber bedenken in Hinblick auf Performance, Daten richtig abfragen usw usw usw, ist aber denke ich dennoch eine Lösung.
Zum Vergrößern anklicken....

Gerade wegen der Performance wird auch Partitioniert.
Die Daten verteilen sich auf mehrere Dateien und man kann die älteren Daten auf günstigeren, langsameren Disks speichern und die aktuellen Daten auf schnelleren.
Die Datenabfrage wird auch sauberer sein, da man nur eine Tabelle und keine zwei hat (und bei allen Abfragen bedenken muss!).
 
Dukel schrieb:
Gerade wegen der Performance wird auch Partitioniert.
Die Daten verteilen sich auf mehrere Dateien und man kann die älteren Daten auf günstigeren, langsameren Disks speichern und die aktuellen Daten auf schnelleren.
Die Datenabfrage wird auch sauberer sein, da man nur eine Tabelle und keine zwei hat (und bei allen Abfragen bedenken muss!).
Zum Vergrößern anklicken....

Ja wie gesagt kann man auch so machen. :)
Wir lagern Alt-Daten in eine extra Tabelle(bei uns liegt diese auf einer anderen Instanz) aus. Und auf dieser "Archiv" Tabelle fahren wir unsere Reports. Wir haben uns damals für diese Variante entschieden und fahren damit bis heute sehr gut. Archiv-Tabelle hat andere Indizes als die Ursprungstabelle, was man beim Inserten auch beachten sollte und ja es kommt auch auf die Datenmasse an usw.
Aber so hat jeder seinen Lösungsweg :)
 
@Chuky666

Das ist genau das, was wir auch machen wollen.
Daher finde ich deinen Ansatz mit den Aufträgen für unsere gesamten Abfragen sehr sehr gut. Nur mit der Übertragung (INSERT) gibt es Probleme. Liegt es am Coding?

Dennoch würde ich mir die Partitionierung im Gesamten gern mal anschauen (als Code), sofern möglich.
 
@Romero
per Kontextmenü kannst du einen neuen Job/Auftrag anlegen. Klicker dich da einfach mal durch und "spiele" bissl um dich damit vertraut zu machen.
upload_2021-8-3_15-29-32.png

zu deinem Insert:
INSERT INTO [dbo].[ACOSA_Monitoring_Taeglich (-Archiv-)]
SELECT * FROM [dbo].[ACOSA_Monitoring_Taeglich (-Daily-)]
GO
View or function 'dbo.ACOSA_Monitoring_Taeglich (-Archiv-)' is not updatable because the modification affects multiple base tables.

Warum willst du hier in eine View schreiben? Schreibe doch gleich in die richtige Tabelle. Des Weiteren fehlt auch die Einschränkung last 24h
 
Dukel schrieb:
Die Daten verteilen sich auf mehrere Dateien und man kann die älteren Daten auf günstigeren, langsameren Disks speichern und die aktuellen Daten auf schnelleren.
Die Datenabfrage wird auch sauberer sein, da man nur eine Tabelle und keine zwei hat (und bei allen Abfragen bedenken muss!).
Zum Vergrößern anklicken....

Jein. Auch bei nur einer Tabelle verteilen sich (bei PostgreSQL zumindest) die Daten auf bis zu je 2GB großen Dateien. Eine 100GB Tabelle ist also auf 50 Dateien verteilt.
Ja, man kann Partitionen mit weniger oft benötigten Daten auf langsameren Tablespaces auslagern.
Datenabfrage bezieht sich immer auf die Haupttabelle, man hat aber logisch gesehen mehrere einzellne, die Partitionen halt.
Anhand der WHERE-Condition kann aber via EXCLUSION CONSTRAINTS die Abfrage auf die Partitionen begrenzt werden, die Daten enthalten KÖNNTEN.

Beispiel, Partitionierung nach Monat. Dann hast Du in 10 Jahren 120 einzelne Partitionen. Bei einer Abfrage nach Daten aus dem Januar 2021 können von diesen also schon 119 ausgeschlossen werden - Exclusion Constraint.


Es gäbe in der PostgreSQL-Welt übrigens noch eine andere Lösung für Append-Only-Tabellen: ein BRIN-Index. BRIN steht für Block Range INdex und ist im Prinzip eine Partitionierung via Index und ohne wirkliche Partitionierung.

Führt hier aber wohl dann doch zu weit ...
 
Aktuell sind es ca. 1Mio an Daten. Die Version ist MS SQL Server Standard (64bit) - Version: 13.0.4001.0
Mir geht es hier nicht nur um die eine "Erstellung" sondern allgemein dieser Prozess. Da ich dieses Verfahren auf mehrere Tabellen und Views anwenden möchte, brauchte ich hier eine allgemeine Vorgehensweise.
Und da hat mir Chuki666 schon sehr sehr weitergeholfen.

Zusammengefasst folgende Vorgehensweise:
1. Erstellung einer Tabelle (CREATE TABLE) mit allen wichtigen Spalten, die die Tabelle beinhalten soll(t)e => ARCHIV-TABLE
2. Erstellung einer View-Abfrage (CREATE VIEW) mit den Zugriffen auf die verschiedenen Tabellen, wo ich dann weitere Selektierungen / Berechnungen durchführe mit Daten bis Datum X => TempARCHIV-VIEW
3. INSERT der View (TempARCHIV-VIEW) INTO der ARCHIV-TABLE
4. Erstellung einer weiteren View-Abfrage (CREATE VIEW) gemäß der TempARCHIV-VIEW aber für ein anderes Datum => DAILY-VIEW
5. Auftrag mit neuem Zeitplan für das automatische INSERT INTO erstellen
6. Daten aus der DAILY-VIEW werden in die TempARCHIV-VIEW geschrieben
 
Aktuell mit der einen Abfrage.
Keine Ahnung was die anderen Tabellen (so an die 60-70 Stück) alles so beinhalten.
Es sind ja "nur" Daten von etwa 3 Jahren...
 
Werbung:
Na noch nicht viel. Aber weil du sagtest, dass man das in einer MYSQL-Tabelle verarbeiten kann.
So riesig sind wir gar nicht aufgestellt, und da sind unsere Datenmengen entsprechend geringer, auch aufgrund der noch jungen Geschichte unserer Firma...
 
Zurück
Oben