MS SQL DB-Daten archivieren?
Hallo zusammen!
Ich habe eine Anwendung, welche MSSQL (SQL Server 2014 SP2) nutzt.
Auf der DB-Instanz laufen diverse Datenbanken. Eine davon wächst stetig an, wodurch es irgendwann wohl zu Performance-Problemen kommen kann..
Jetzt stellt sich mir die Frage, was denn "Best Practice" für die Archivierung von solchen Daten ist?
Eine zusätzliche Datenbank zB "Archiv" erstellen? Habe da diverse Beiträge/posts in Foren finden können, aber nichts Konkretes..
Die Daten sollten natürlich über die Anwendung, wenn konkret danach gesucht/gefiltert wird weiterhin verfügbar bleiben..
Vielen Dank im Voraus für eure Tips/Beiträge!
Ich habe eine Anwendung, welche MSSQL (SQL Server 2014 SP2) nutzt.
Auf der DB-Instanz laufen diverse Datenbanken. Eine davon wächst stetig an, wodurch es irgendwann wohl zu Performance-Problemen kommen kann..
Jetzt stellt sich mir die Frage, was denn "Best Practice" für die Archivierung von solchen Daten ist?
Eine zusätzliche Datenbank zB "Archiv" erstellen? Habe da diverse Beiträge/posts in Foren finden können, aber nichts Konkretes..
Die Daten sollten natürlich über die Anwendung, wenn konkret danach gesucht/gefiltert wird weiterhin verfügbar bleiben..
Vielen Dank im Voraus für eure Tips/Beiträge!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 389928
Url: https://administrator.de/contentid/389928
Ausgedruckt am: 24.11.2024 um 18:11 Uhr
16 Kommentare
Neuester Kommentar
Moin,
Archivierung heist aber leider, dass die Daten in der Software nicht mehr verfügbar sind.
Auch ist es in den meisten DBs sehr schwierig zu entscheiden was denn weg kann.
Problem sind die Verbindungen zwischen den verschiedenen Datensätzen.
Eigentlich kann man so etwas nur aus der Anwendung heraus durchführen.
Die weiß wie die Daten zusammengehören und was weg kann.
Stefan
Archivierung heist aber leider, dass die Daten in der Software nicht mehr verfügbar sind.
Auch ist es in den meisten DBs sehr schwierig zu entscheiden was denn weg kann.
Problem sind die Verbindungen zwischen den verschiedenen Datensätzen.
Eigentlich kann man so etwas nur aus der Anwendung heraus durchführen.
Die weiß wie die Daten zusammengehören und was weg kann.
Stefan
Hallo Schelinho,
unabhängig von deiner Frage nach der Archivierung würde ich erst einmal den Grund für das Wachstum ergründen.
Ist es das Log, was du DB wachsen lässt oder gibt es wirklich einzelne Tabellen die immer größer werden?
Das mit dem Log kannst du im Managmentstudio prüfen (Backuptyp - Simple u.s.w. - wieviel Platz in der Transaktionslog freigeben werden kann).
Speicherplatz pro Tabelle einer DB kannst du mit dieser Procedure auswerten:
Quelle: https://www.fractalcenter.de/2010/08/grose-aller-tabellen-ermitteln-mssq ...
Mit exec Groesse_aller_Tabellen_einer_DB aufrufen.
Als Archiv könntest du Datensätze vor einem bestimmten Zeitstempel in eine neue DB übertragen und, falls mit deiner App möglich, eine Archivversion den Usern bereitstellen. So machen wir das bei uns.
Grüße vom it-frosch
unabhängig von deiner Frage nach der Archivierung würde ich erst einmal den Grund für das Wachstum ergründen.
Ist es das Log, was du DB wachsen lässt oder gibt es wirklich einzelne Tabellen die immer größer werden?
Das mit dem Log kannst du im Managmentstudio prüfen (Backuptyp - Simple u.s.w. - wieviel Platz in der Transaktionslog freigeben werden kann).
Speicherplatz pro Tabelle einer DB kannst du mit dieser Procedure auswerten:
Quelle: https://www.fractalcenter.de/2010/08/grose-aller-tabellen-ermitteln-mssq ...
Mit exec Groesse_aller_Tabellen_einer_DB aufrufen.
CREATE PROCEDURE [dbo].[Groesse_aller_Tabellen_einer_DB]
AS
BEGIN
SET NOCOUNT ON;
declare @RowCount int, @tablename VARCHAR(100)
declare @Tables table (
PK int IDENTITY(1,1),
tablename VARCHAR(100),
processed BIT
)
INSERT INTO @Tables (tablename)
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' and TABLE_NAME NOT LIKE 'dt%' ORDER BY TABLE_NAME asc
declare @Space TABLE (
name VARCHAR(100), rows nVARCHAR(100), reserved VARCHAR(100), data VARCHAR(100), index_size VARCHAR(100), UNUSED VARCHAR(100)
)
SELECT TOP 1 @tablename = tablename FROM @Tables WHERE processed IS NULL
SET @RowCount = 1
WHILE (@RowCount != 0)
BEGIN
insert INTO @Space exec sp_spaceused @tablename
UPDATE @Tables set processed = 1 WHERE tablename = @tablename
SELECT TOP 1 @tablename = tablename FROM @Tables WHERE processed IS NULL
SET @RowCount = @@RowCount
END
UPDATE @Space set data = replace(data, ' KB', '')
UPDATE @Space set data = convert(int, data)/1000
UPDATE @Space set data = data + ' MB'
UPDATE @Space set reserved = replace(reserved, ' KB', '')
UPDATE @Space set reserved = convert(int, reserved)/1000
UPDATE @Space set reserved = reserved + ' MB'
SELECT * FROM @Space ORDER BY CONVERT(INT, REPLACE(data, ' MB', '')) DESC
END
Als Archiv könntest du Datensätze vor einem bestimmten Zeitstempel in eine neue DB übertragen und, falls mit deiner App möglich, eine Archivversion den Usern bereitstellen. So machen wir das bei uns.
Grüße vom it-frosch
Hi
Grundsätzlich wird MSSQL nicht langsamer, weil da mehr Daten in der Tabelle sind. Sofern die Queries nicht Murks, die Felder korrekt erstellt und die Indexe richtig sind, passiert da an der Performance garnix.
Eine Archivierung muss aus der Applikation erfolgen, da nur diese die Abhängigkeiten der Daten kennt und im Zweifelsfall auf das Archiv zugreifen kann.
Grundsätzlich wird MSSQL nicht langsamer, weil da mehr Daten in der Tabelle sind. Sofern die Queries nicht Murks, die Felder korrekt erstellt und die Indexe richtig sind, passiert da an der Performance garnix.
Eine Archivierung muss aus der Applikation erfolgen, da nur diese die Abhängigkeiten der Daten kennt und im Zweifelsfall auf das Archiv zugreifen kann.
Hallo,
was genau ist mit Performance Problemen gemeint? Das ist eine sehr schwammige Aussage.
Ist damit evtl. die Rückmeldung / Antwort einens oder mehrere Queries gemeint?
Ist die Anwendung träge, wenn ja wie äußert sich dies?
Evtl. gibt es Optimierungsbedarf bei den Queries. Hatte vor längerer Zeit den Fall, daß aufgrund der Queries die Antwortzeiten das Problem war. Selbst Microsoft, welche wir eingeschaltet hatten, konnten uns damals nicht weiter helfen. Erst ein Datenbankentwickler (Freelancer) hat uns geholfen, das Problem zu lösen.
Diese Aktion hat uns damals mehrere Tage beschäftigt. Wobei die Grundvoraussetzungen eigentlich gut waren. Es wurde damals ein Cluster aufgesetzt, mit entsprechender Netzwerkanbindung.
Gruss Penny.
was genau ist mit Performance Problemen gemeint? Das ist eine sehr schwammige Aussage.
Ist damit evtl. die Rückmeldung / Antwort einens oder mehrere Queries gemeint?
Ist die Anwendung träge, wenn ja wie äußert sich dies?
Evtl. gibt es Optimierungsbedarf bei den Queries. Hatte vor längerer Zeit den Fall, daß aufgrund der Queries die Antwortzeiten das Problem war. Selbst Microsoft, welche wir eingeschaltet hatten, konnten uns damals nicht weiter helfen. Erst ein Datenbankentwickler (Freelancer) hat uns geholfen, das Problem zu lösen.
Diese Aktion hat uns damals mehrere Tage beschäftigt. Wobei die Grundvoraussetzungen eigentlich gut waren. Es wurde damals ein Cluster aufgesetzt, mit entsprechender Netzwerkanbindung.
Gruss Penny.
Zitat von @Schelinho:
Hallo!
Vielen Dank für die Antworten!
Also die Datenbank, die es eigentlich betrifft ist aktuell um die 10GB groß.
Eine der größten Tabellen in der DB enthält über 10 Millionen Datensätze
Hallo!
Vielen Dank für die Antworten!
Also die Datenbank, die es eigentlich betrifft ist aktuell um die 10GB groß.
Eine der größten Tabellen in der DB enthält über 10 Millionen Datensätze
Find ich jetzt ansich nicht sonderlich spannend. Wenn's zu Problemen kommt dann hast du Probleme mit dem Index oder Schlechte Abfragen.
Aber das ist alles eh schon erwähnt worden.
Hast du Wartungstask eingerichtet die entsprechend den Index optimieren?
Zitat von @Schelinho:
Mich hat grundsätzlich interessiert, ob es da sonst "Standard-Vorgangsweisen" gibt, die man einsetzen kann um Daten zu archivieren (ohne zusätzliche externe Software für diesen Zweck)
Nö, entweder ist das überhaupt nicht notwendig, die Software flasch programmiert bzw. falsch ausgewählt, oder direkt in der Software Enthalten.Mich hat grundsätzlich interessiert, ob es da sonst "Standard-Vorgangsweisen" gibt, die man einsetzen kann um Daten zu archivieren (ohne zusätzliche externe Software für diesen Zweck)
Zitat von @VGem-e:
Servus,
gibt es nicht wie früher noch die Möglichkeit, einen Task für eine DB-Reorganisation mit einzusetzen?
Er schreibt, Wartungstask's sind eingerichtetServus,
gibt es nicht wie früher noch die Möglichkeit, einen Task für eine DB-Reorganisation mit einzusetzen?
Zitat von @Schelinho:
Noch gibt es ja keine Performance-Probleme, doch es kann in Zukunft dazu kommen, wenn sich die jeweiligen DBs immer mehr vergrößern, und das werden sie in den nächsten Monaten tun.
Deine Schlussfolgerung ist nicht korrekt. 10 Mio Datensätze sind nicht viel und 10 GB auch nicht. Wenn die Aplikation das so vorsieht muss man erstmal davon ausgehen das sie auch damit umgehen kann. Die DB kann das sowieso.Noch gibt es ja keine Performance-Probleme, doch es kann in Zukunft dazu kommen, wenn sich die jeweiligen DBs immer mehr vergrößern, und das werden sie in den nächsten Monaten tun.
Sofern du kein SQL Express einsetzt ist hier nicht mit Problemen zu rechnen. Der Hersteller der Anwendung ist aber ein guter Ansprechpartner wenn es wirklich Probleme gibt und es um die Dimensionierung der DB-Hardware geht.
Moment, der Hersteller kann nicht nicht genau sagen, wie sich das System dann verhält, wenn die DBs größer werden?
Sorry, das ist doch Murks. Mit welchen DB-Größen bzw. mit welchen/wievielen Datensätzen arbeitet der Hersteller denn?
Fragt den Hersteller bis welche Größe / Menge an Datensätzen er den Betrieb gewährleisten kann. Was macht Ihr, wenn die Datenbank 30 GiB groß ist und 100 Millionen Datensätze enthält?
Gruss Penny.
Sorry, das ist doch Murks. Mit welchen DB-Größen bzw. mit welchen/wievielen Datensätzen arbeitet der Hersteller denn?
Fragt den Hersteller bis welche Größe / Menge an Datensätzen er den Betrieb gewährleisten kann. Was macht Ihr, wenn die Datenbank 30 GiB groß ist und 100 Millionen Datensätze enthält?
Gruss Penny.