Zeilensatz mit CLR und GZIP komprimieren

8

Ich möchte eine große Tabelle komprimieren, die historische Daten enthält, die selten oder überhaupt nicht gelesen werden. Ich habe zuerst versucht, die eingebauten Kompressionen zu verwenden ( row , page , column stored , column-stored archive ), aber keiner von ihnen kann die Werte außerhalb der Zeile komprimieren ( varchar(max) , nvarchar(max) ) und Schließlich versuchen, CLR Lösung zu verwenden.

Die Komprimierung des SQL Server-Rowset-Beispiels komprimiert den gesamten Zeilensatz, der von einem gegebenen zurückgegeben wird Abfrage mit benutzerdefiniertem% ​​co_de% type.

Zum Beispiel:

%Vor%

Es funktioniert, aber ich habe die folgenden Probleme festgestellt:

  • Wenn ich versuche, einen großen Ergebniszeilensatz zu komprimieren, erhalte ich den folgenden Fehler :

      

    Meldung 0, Ebene 11, Status 0, Zeile 0 Ein schwerwiegender Fehler ist aufgetreten   aktueller Befehl Die Ergebnisse, falls vorhanden, sollten verworfen werden.

    Auch die folgende Anweisung funktioniert:

    %Vor%

    aber diese sind nicht:

    %Vor%
  • Um einen Zeilensatz zu komprimieren, sollte CLR auf t-sql type abgebildet werden; Leider gilt dies nicht für alle SQL-Typen - CLR-Parameterdaten zuordnen ; Ich habe bereits die folgende Funktion erweitert, um mehr Typen zu behandeln, aber wie man mit Typen wie .net type beispielsweise umgeht:

    %Vor%

Hier ist der ganze Code geography :

%Vor%

und hier ist die Erstellung von SQL-Objekten:

%Vor%     
gotqn 22.01.2015, 09:48
quelle

2 Antworten

1

Wahrscheinlich ist es zu spät für die ursprüngliche Frage, aber dies könnte sich für andere als problematisch erweisen: In SQL Server 2016 gibt es Komprimierungs- und Dekomprimierungsfunktionen (siehe hier und hier ) Dies ist nützlich, wenn die Daten, die Sie archivieren möchten, große Werte in den Spalten [N]VARCHAR und VARBINARY enthalten.

Sie müssten dies in Ihrer Business-Logik-Ebene erstellen oder eine Vereinbarung in SQL Server erstellen, wobei Sie Ihre unkomprimierte Tabelle als Ansicht auf eine Sicherungstabelle replizieren (wo die komprimierten Werte sind) und die unkomprimierten Daten über% co_de ableiten % und mit DECOMPRESS triggert, die die Backing-Tabelle aktualisieren (so verhält sich die Ansicht wie die Originaltabelle für select / insert / update / delete abgesehen von den Leistungsunterschieden). Ein bisschen hacky, aber es würde funktionieren ...

Bei älteren SQL-Versionen könnten Sie wahrscheinlich auch eine CLR-Funktion schreiben, um den Job zu erledigen.

Diese Methode funktioniert natürlich nicht bei Datensätzen, die aus kleinen Feldern bestehen. Dieser Komprimierungsstil wird bei kleinen Werten nichts erreichen (er wird sie sogar vergrößern).

    
David Spillett 18.05.2016 11:19
quelle
0

Haben Sie stattdessen erwogen, eine neue 'Archiv' Datenbank zu erstellen (vielleicht auf ein einfaches Wiederherstellungsmodell gesetzt), wo Sie all Ihre alten Daten ablegen? Dies könnte leicht in Abfragen zugegriffen werden, so dass dort keine Probleme auftreten, z.

%Vor%

Wenn Sie die Datenbank erstellen, legen Sie sie auf eine andere Festplatte und behandeln Sie sie anders in Ihrer Sicherungsprozedur - vielleicht führen Sie die Archivierung einmal pro Woche durch, dann müssen Sie erst danach gesichert werden - und nachdem Sie gequetscht haben mit 7zip / rar fast auf Null.

Versuchen Sie nicht, die db mit NTFS-Komprimierung zu komprimieren, obwohl SQL Server es nicht unterstützt - fand das selbst heraus, sehr sehr späten Abend:)

    
Fredrik Johansson 29.01.2015 12:02
quelle

Tags und Links