Archivdaten

[Babsi]

Hallo zusammen,

auch wenn es schon ende Februar ist, ein frohes Neues.

In unserer Firma haben wir von Access-Backends auf SQL Server umgestellt, alles migrierte, die ganzen Anwendungen laufen.

Nun ist es bisher so gewesen, dass wir Daten, die täglich kommen, irgendwann archivieren. Je nachdem, wie ich sie brauche, können diese Daten dann eingebunden werden.
Das ist sicherlich auch weiterhin nötig, vielleicht nicht so oft wie mit Access-BE aber eben auch, irgendwann wird die Tabelle zu voll und das Suchen dauert zu lange.

Und nun meine eigentliche Frage, lege ich diese Tabellen, wegen meiner mit einem eigenen Schema in die selbe Datenbank, wie alle anderen Tabellen auch oder erstelle ich eine neue Datenbank?
Hat jemand Erfahrungen bzw. wie habt ihr das umgesetzt?

Grüße, Babsi

 

[Walter]

Von welchen Datenmengen reden wir da? Ein richtiger Datenbankserver wie SQL-Server kann eigentlich eine absurd hohe Menge an Daten in Sekundenbruchteilen durchsuchen...

 

[t-sql]

Dazu hätte ich erstmal ein paar Fragen: 1. was heißt Tabelle zu voll? Sprechen wir hier von Millionen von Datensätzen oder nur von ein paar tausend? 2. Sind Indizes richtig gesetzt bzw. überhaupt gesetzt? 3. ab welchem Datum soll denn archiviert werden? Falls es eine Archivtabelle oder mehrere geben soll, legst du für diese erstmal eine eigene Filegroup an um die Bewegungsdaten von den Archivdaten zu trennen. Ein eigenes Schema ist durchaus auch sinnvoll. Eine eigene Archivdatenbank ergibt keinen Sinn weil du aus deiner Anwendung erstmal keinen Zugriff hast.

 

[ukulele]

SQL Express oder Standard? Express kann ja nur Datenbanken bis 10 GB.

 

[Babsi]

Hallo Walter,

da kommen schon monatlich ca. 100.000.000 DS zusammen.

 

[Babsi]

Hallo t-sql,
ja, Millionen. Indizees sind gesetzt.
Danke für folgende Anwtort

Eine eigene Archivdatenbank ergibt keinen Sinn weil du aus deiner Anwendung erstmal keinen Zugriff hast

 

[Babsi]

Moin ukulele,

nein ist Standart.

 

[Babsi]

Hallo t-sql,
und auf die Daten der FileGroup kann ich dann aus aus Anwendungen auch zugreifen?
Ich lese mich gerade in Filegroups ein...

Diese Eigenschaft bezieht sich auf eine DataFileCollection-Auflistung, die alle Datendateien enthält, die zur Datenbank gehören. Eine Dateigruppe wird prinzipiell verwendet, um Dateien zu gruppieren, die zur Speicherung eines Datenbankobjekts genutzt werden. Ein Grund für die Verteilung eines Datenbankobjekts über mehrere Dateien ist die Verbesserung der Leistung

Dann kann ich doch genauso gut eine Tabelle in einem eigenem Schema anlegen und sagen, das ist die Archivtabelle, wofür eine FileGroup?
Deswegen?

...Grund für die Verteilung eines Datenbankobjekts über mehrere Dateien ist die Verbesserung der Leistung

Ich weiß ja nicht ob das für eine einzeölen Tabelle Sinn machen würde?!

Grüße, Babsi

 

[Dukel]

Mit der Konfiguration über die Filetable (nennt sich Partitionierung Create partitioned tables and indexes - SQL Server, Azure SQL Database, Azure SQL Managed Instance) ist das ganze transparent.
Du musst die Daten nicht über verschiedene Tabellen umziehen (was passiert, wenn z.B. einen Spalte dazu kommt, dann darfst du das in der Archiv Tabelle nicht vergessen).

Du kannst z.B. unterschiedliche (schnelle) Disk Typen verwenden. SSD's für Aktive daten, SATA HDD für Archiv Daten.
EDIT:
Weitere Spannende Informationen hierzu: Partitionierung hat NICHTS mit Performance Tuning zu tun!

 

[MDDaniel]

Partitionen werden von der Standard-Edition nicht unterstützt. Filegroups, bei denen einzelne Tabellen in unterschiedlichen Files sind, werden unterstützt. Dazu sind dann unterschiedliche Tabellen notwendig.
@Babsi
Welchen Vorteil siehst du darin verschiedene Schemas zu verwenden? Das in MSSQL mehr ein Sicherheitsaspekt oder übersehe ich da was?

 

[Babsi]

Hallo Dukel,
und das ganze wegen einer einizigen Tabelle? Oh man...Ich versuche da erst mal rein zu kommen...
Danke

Du kannst z.B. unterschiedliche (schnelle) Disk Typen verwenden. SSD's für Aktive daten, SATA HDD für Archiv Daten.
EDIT:

Das wird bei uns bestimmt nicht passieren

 

[Babsi]

Welchen Vorteil siehst du darin verschiedene Schemas zu verwenden?

Einfach nur, dss diese eine Tabelle dann eben schema Archive hätte

 

[Babsi]

Mit der Konfiguration über die Filetable (nennt sich Partitionierung Create partitioned tables and indexes - SQL Server, Azure SQL Database, Azure SQL Managed Instance) ist das ganze transparent.
Du musst die Daten nicht über verschiedene Tabellen umziehen (was passiert, wenn z.B. einen Spalte dazu kommt, dann darfst du das in der Archiv Tabelle nicht vergessen).

Du kannst z.B. unterschiedliche (schnelle) Disk Typen verwenden. SSD's für Aktive daten, SATA HDD für Archiv Daten.
EDIT:
Weitere Spannende Informationen hierzu: Partitionierung hat NICHTS mit Performance Tuning zu tun!

Danke für die Links

 

[MDDaniel]

Nur so ein Gedankenspiel
Ein Vorschlag wäre es die Daten in eine Archivdatenbank in der selben SQL Instanz auszulagern.
Über eine View oder Funktion in der Produktivdatenbank kannst du die Daten dann zusammenspannen und gemeinsam abfragen.
Hätte den Charme, dass du die Archivdatenbank aufgliedern kannst wie du willst und mit dem Backup unabhängig bist.
Kannst deine Tabellen täglich , wöchentlich, ... jährlich halten. Das Thema "separates Schema" würde ich mir dabei sparen.
Und das Thema Performance durch unterschiedliche Festplatten kannst auch einfacher abwickeln.
Cross-Database Querys funktionieren normalerweise.

Gibt aber sicher noch andere Wege.

 

[Babsi]

Nur so ein Gedankenspiel
Ein Vorschlag wäre es die Daten in eine Archivdatenbank in der selben SQL Instanz auszulagern.
Über eine View oder Funktion in der Produktivdatenbank kannst du die Daten dann zusammenspannen und gemeinsam abfragen.
Hätte den Charme, dass du die Archivdatenbank aufgliedern kannst wie du willst und mit dem Backup unabhängig bist.
Kannst deine Tabellen täglich , wöchentlich, ... jährlich halten. Das Thema "separates Schema" würde ich mir dabei sparen.
Und das Thema Performance durch unterschiedliche Festplatten kannst auch einfacher abwickeln.
Cross-Database Querys funktionieren normalerweise.

Gibt aber sicher noch andere Wege.

MDDaniel, vielen Dank an deinen Vorschlag
So in der Art hatte ich es gedacht...Trotzdem ist das mit den Partitionen interessant und man sollte es mal gehört haben und in etwas wissen wie es funktioniert.