schelinho
Goto Top

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!

Content-Key: 389928

Url: https://administrator.de/contentid/389928

Ausgedruckt am: 19.03.2024 um 06:03 Uhr

Mitglied: StefanKittel
StefanKittel 18.10.2018 um 09:28:47 Uhr
Goto Top
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
Mitglied: wiesi200
wiesi200 18.10.2018 um 09:43:10 Uhr
Goto Top
Hallo,

da kann man nicht's pauschal sagen.
Auch nicht zu den Performance Problemen.

Es kommt auf die Art der Daten / Art der Zugriffe Anwendung usw. an.
Am besten du erkundigst dich mal bei dem Hersteller.

Von wie vielen Datensätzen und DB Größe reden wir hier eigentlich?
Mitglied: it-frosch
it-frosch 18.10.2018 aktualisiert um 09:47:04 Uhr
Goto Top
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.

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
Mitglied: SeaStorm
SeaStorm 18.10.2018 um 10:08:25 Uhr
Goto Top
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.
Mitglied: Schelinho
Schelinho 18.10.2018 um 10:10:23 Uhr
Goto Top
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
Mitglied: Penny.Cilin
Penny.Cilin 18.10.2018 um 10:31:31 Uhr
Goto Top
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.
Mitglied: wiesi200
wiesi200 18.10.2018 um 10:43:46 Uhr
Goto Top
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

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?
Mitglied: Schelinho
Schelinho 18.10.2018 um 10:49:19 Uhr
Goto Top
Von den Abfragen her sind wir vom SW-Hersteller abhänging, da kann ich so einfach nichts ändern.
Wartungstasks sind eingerichtet.
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.
Aber ich werde mich mit dem Hersteller nochmal zusammen setzen, und das genauer abklären.
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)

danke
Mitglied: wiesi200
wiesi200 18.10.2018 um 11:52:14 Uhr
Goto Top
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.
Mitglied: VGem-e
VGem-e 18.10.2018 um 14:05:17 Uhr
Goto Top
Servus,

gibt es nicht wie früher noch die Möglichkeit, einen Task für eine DB-Reorganisation mit einzusetzen?

Gruß
Mitglied: wiesi200
wiesi200 18.10.2018 um 14:47:36 Uhr
Goto Top
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 eingerichtet
Mitglied: ukulele-7
ukulele-7 19.10.2018 um 09:43:00 Uhr
Goto Top
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.

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.
Mitglied: Schelinho
Schelinho 19.10.2018 um 10:13:08 Uhr
Goto Top
Naja, der Hersteller selbst kann eben nicht genau sagen, wie sich das System dann verhält, wenn die DBs größer werden, und da ist es wohl besser vorab eine Lösung zu implementieren, oder zumindest eine zu planen, und nicht erst wenn das Ding dann steht (zumindest bei den Anforderungen die ich hier habe, sprich ein Ausfall seeehr teuer ist)
Mitglied: Penny.Cilin
Penny.Cilin 19.10.2018 um 10:22:20 Uhr
Goto Top
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.
Mitglied: SeaStorm
SeaStorm 19.10.2018 um 10:22:22 Uhr
Goto Top
Dann soll der Hersteller das gefälligst testen...
Er kann doch die Software in einer Testumgebung mit Daten vollpumpen. Dann sieht er was passiert.
Mitglied: Schelinho
Schelinho 19.10.2018 um 10:32:18 Uhr
Goto Top
Ja, genau das wird aktuell gemacht.

Danke für eure Inputs.