SQL Server RAM Pro Datenbank begrenzen

[LangerSN 10]

Hallo zusammen,

kann ich den RAM Pro Datenbank auf einem SQL Server begrenzen oder kann ich dies tatsächlich nur für den kompletten SQL Server konfigurieren?

 

Danke für Eure Antworten.

[Nobbyaushb 1.471]

Moin,

 

meines Wissens für den Server komplett.

 

Über welche SQL-Version mit welchem SP und auf welchem OS reden wir?

 

;)

[Dukel 454]

Genauer gesagt du kannst den RAM pro Instanz begrenzen.

Was hast du denn für ein Problem, dass du den Ram begrenzen willst?

 

Evtl. hilft der Ressource governor weiter. Mit diesem kann man die Ressourcen granularer verwalten.

[NilsK 2.934]

Moin,

 

bevor man hier irgendwelche Ansätze bespricht, die schnell in die Irre führen, sollten wir erst mal das Problem und die Anforderungen klären. Daher schließe ich mich der Frage an:

 

 

Was hast du denn für ein Problem, dass du den Ram begrenzen willst?

 

Gruß, Nils

[MDD 12]

Moin,

 

Genauer gesagt du kannst den RAM pro Instanz begrenzen.

Was hast du denn für ein Problem, dass du den Ram begrenzen willst?

 

Evtl. hilft der Ressource governor weiter. Mit diesem kann man die Ressourcen granularer verwalten.

 

Kleine Nebenbemerkung: Der Ressource governor steht nur bei den Editionen Enterprise, Developer und Evaluation zur Verfügung.

 

Aber wir warten alle weiter auf die Erklärung nach dem "Warum".

MDD

[LangerSN 10]

Guten Morgen zusammen,

jetzt kommt endlich das warum.

 

Es gibt Überlegungen gescannte Dokumente (Bilder) direkt in der Datenbank abzulegen. Hier geht es um Mengen >500.000 pro Monat.

 

Die Anwendungsentwickler sehen Ihre Vorteile darin das es einfach ist mit den Bildern direkt in der Datenbank zu arbeiten. Der Systemintegrator sieht die Ressource Plattenplatz und RAM im SQL als kritisch.

 

Meine Überlegung war ob man für so eine bestimmte Bilddatenbank nur eine begrenzte Größe von RAM zur Verfügung stellen kann.

 

Bei einem Bildaufkommen von monatlich 50GB und derzeit 64GB RAM stelle ich mir gerade die Frage wie man es lösen kann das der RAM nicht nur von den Bildern eingenommen wird. 

 

Haben die Anwendungsentwickler Möglichkeiten die Bilder aus dem RAM schneller wieder frei zu geben?

 

SQL Version ist derzeit zwar 2008 R2 kann aber auch SQL 2014 oder zukünftige berücksichtigt werden.

 

Danke für Eure Meinungen.

[OliverHu 19]

Moin!

 

Ohne jetzt detaillierter hier einzusteigen, würde ich dir bei dem von dir geschätzten Aufkommen unbedingt abraten, die Bilder in der DB zu speichern. Mal am Rande: Nach einem Jahr wird die DB 600GB groß sein. Wie willst du diese im Fehlerfall mal zeitnah wiederherstellen (auch nach 3, 4 Jahren)?

 

Frage, wenn du das unbedingt so machen willst:

Kann man die Bilder eventuell stark komprimieren, bevor die in der DB landen (Resize, dpi reduzieren etc.)?

 

Wie kommst du zu der Annahme, dass die Bilder im RAM gespeichert werden?! :shock:

 

Ich würde die Dokumente auf das Filesystem auslagern. Flexibler und kostengünstiger wäre das allemal.

 

Bitte korrigiert mich, wenn ich falsch liege...

bearbeitet 29. Oktober 2015 von OliverHu

[LangerSN 10]

Meine Empfehlung war ebenfalls die Dokumente ins Filesystem zu legen.

 

Weiterhin habe ich darüber nachgedacht die Bilder nach einem Monat aus der Datenbank auszukippen und im Filesystem ablegen. Die Entwickler wollen die Bilder ggf. für den Abrechnungsmonat in der Datenbank belassen.

 

Über die Sicherung der Datenbank habe ich mir auch schon Sorgen gemacht wenn es auf lange Sicht so bleiben soll.

 

Für mich als Systemintegrator spricht vielen dagegen.

 

Der SQL verwaltet seinen RAM doch so ziemlich alleine. Warum sollten die Bilder nicht im RAM sein wenn Sie mit in der Datenbank abgelegt sind. DPI Zahlen der Bilder liegen bei 200 bzw. 300 da Sie für Interpretation benötigt werden.

[Sunny61 806]

Filestream wurde noch nicht genannt. Dabei werden/können Dateien im Dateisystem abgelegt werden, Verweise liegen in einer Tabelle in der Datenbank. Bei einer Datenbanksicherung werden allerdings die Filestreamdaten gleich mitgesichert.

 

Wenn auf dem Server sonst nichts anderes läuft, würde ich nicht versuchen hier tätig zu werden.

[monstermania 53]

@LangerSN

Ich komme aus dem DMS-Bereich. Von daher kann ich Dir bzw. euren Entwicklern nur sagen, dass die führenden DMS-Systeme Ihre Dokumente nicht innerhalb der SQL-Datenbank speichern. In der Datenbank werden nur die Indexinformationen und ggf. der Volltext zum Dokument abgelegt. Die Dokumente liegen dann je nach Anbieter im direkt Filesystem oder in Containerdateien.

Ich versuche mir gerade eine Langzeitarchivierung bei einer Datenbanklösung vorzustellen (50 GB/Monat = 600 GB/Jahr * 10 Jahre = Sportlich :D )

[Dukel 454]

@LangerSN

Ich komme aus dem DMS-Bereich. Von daher kann ich Dir bzw. euren Entwicklern nur sagen, dass die führenden DMS-Systeme Ihre Dokumente nicht innerhalb der SQL-Datenbank speichern. In der Datenbank werden nur die Indexinformationen und ggf. der Volltext zum Dokument abgelegt. Die Dokumente liegen dann je nach Anbieter im direkt Filesystem oder in Containerdateien.

Ich versuche mir gerade eine Langzeitarchivierung bei einer Datenbanklösung vorzustellen (50 GB/Monat = 600 GB/Jahr * 10 Jahre = Sportlich :D )

 

SharePoint speichert die Dokumente in der Datenbank.

 

Wegen der Langzeitarchivierung: Es macht doch keinen Unterschied ob die 600GB im Jahr von der DB kommen oder vom Filesystem. Archiviert werden muss es eh.

[OliverHu 19]

SharePoint speichert die Dokumente in der Datenbank.

 

Je nachdem, wie man SharePoint nutzt, würde ich auch hier die Dokumente auslagern, bspw. mit AvePoint DocAve.

 

 

Wegen der Langzeitarchivierung: Es macht doch keinen Unterschied ob die 600GB im Jahr von der DB kommen oder vom Filesystem. Archiviert werden muss es eh.

 

Für mich schon.

[monstermania 53]

SharePoint speichert die Dokumente in der Datenbank.

 

Wegen der Langzeitarchivierung: Es macht doch keinen Unterschied ob die 600GB im Jahr von der DB kommen oder vom Filesystem. Archiviert werden muss es eh.

Sorry,

aber ich hatte von "führenden Produkten" im DMS-Bereich gesprochen. Und dazu gehört SharePoint m.E. nicht! :D

 

Und, es macht schon einen Unterschied, ob die zu sichernden Daten im Filesystem oder direkt in der db liegen. Bei "führenden" DMS-Systemen kann man nämlich z.B. Jahresarchive anlegen und das System so konfigurieren, dass an den Daten des Vorjahresarchivs keine Änderung mehr möglich sind. Dann braucht man die Vorjahresdaten nicht jedes Mal mit zu sichern.  

Das heißt also im konkreten Fall, dass Du die 600 GB/Jahr nur einmalig auf ein Langzeitbackup gesichert werden müssen.

 

Auch können alte Archive, die wenig nachgefragt werden einfach auf ein entsprechendes SAN im Unternehmen verschoben werden (z.B. SAN mit preisgünstigen NL-SAS Platten). Während die Datenbanken auf dem schnellen db SAN liegt.

[NilsK 2.934]

Moin,

 

selbstverständlich gehören solche Daten nicht direkt in die Datenbank. Unter anderem wegen des RAM-Bedarfs ...

 

Man wird Bilder nicht aufgrund der Bilddaten sortieren oder filtern oder danach suchen. Also: Metadaten in die DB, Bilddaten ins Dateisystem.

 

Und selbst wenn: Stell dir vor, die DB hat so einen hohen RAM-Bedarf. Wohin soll es führen, wenn du ihr dann das RAM nicht gibst? Wenn innerhalb einer Stunde 1000 Autos über eine Straße müssen, ist es auch keine gute Idee, die Straße auf 500 Autos zu begrenzen ...

 

Gruß, Nils