4
MS SQL Server 2005 - Datenbankdateien Verschieben, Blob-Elemente in die DB?
Hi,
ich habe auf einem Windows Server 2003 Standard einen MS SQL Server 2005 laufen. Auf grund von Sicherungsmechanismen würde ich gern die Dateien der einzelnen Datenbanken und auch der Masterdatenbank aus dem Default-Verzeichnis auf eine andere Partition verschieben. Leider sehe ich im Programm selber keine Möglichkeit dazu.
Kann mir da wer einen Hinweis geben?
Dann würde ich gern noch wissen wie die allgemeine Praxis zum einstellen von großen Dateien in die Datenbank aussieht. Mal angenommen ihr wölltet Videos oder Audios, also Blob Elemente ablegen. Kommt der SQL Server damit überhaupt klar oder sollte man das aus Preformance gründen nicht machen oder was auch immer noch dagegen spicht?
mfg
ich habe auf einem Windows Server 2003 Standard einen MS SQL Server 2005 laufen. Auf grund von Sicherungsmechanismen würde ich gern die Dateien der einzelnen Datenbanken und auch der Masterdatenbank aus dem Default-Verzeichnis auf eine andere Partition verschieben. Leider sehe ich im Programm selber keine Möglichkeit dazu.
Kann mir da wer einen Hinweis geben?
Dann würde ich gern noch wissen wie die allgemeine Praxis zum einstellen von großen Dateien in die Datenbank aussieht. Mal angenommen ihr wölltet Videos oder Audios, also Blob Elemente ablegen. Kommt der SQL Server damit überhaupt klar oder sollte man das aus Preformance gründen nicht machen oder was auch immer noch dagegen spicht?
mfg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 104027
Url: https://administrator.de/contentid/104027
Ausgedruckt am: 22.11.2024 um 20:11 Uhr
4 Kommentare
Neuester Kommentar
Hi Albert,
zumindest beim Verschieben der Datenbankdateien kann ich weiter helfen (wie ich hoffe):
http://support.microsoft.com/kb/224071
Zu den Blob-Elementen sollte sich besser jemand äußern, der sich damit auskennt
Gruß, Eicky
zumindest beim Verschieben der Datenbankdateien kann ich weiter helfen (wie ich hoffe):
http://support.microsoft.com/kb/224071
Zu den Blob-Elementen sollte sich besser jemand äußern, der sich damit auskennt
Gruß, Eicky
Moin ooAlbert,
Ist nicht gerade eine Frage, auf die sich eine klare und lehrbuchhafte Antwort geben lässt.
Unter der Voraussetzung, dass Du/Dein Unternehmen überhaupt den Leidensdruck hat
--> dann ist die Speicherung von großen Datenklumpen in einer Datenbank nicht langsamer oder anfälliger als die in einem "normalen" Filesystem.
Performanzprobleme sind nicht zu befürchten - anders als bei VARCHAR oder LONGVARCHAR-Datentypen wird bei LOBs ja in der Datensatz-Struktur nur ein Pointer auf einen Speicherblock/ein Datensegment gespeichert.
Und dieser Pointer ist ja nur ein paar Byte lang (irgendwer mag das auch genau wissen, ob das nun 16 oder 32 oder 64 Byte sind - letzten Endes geht es jedenfalls im Rauschen unter).
Tabellen mit LOB-Feldern sind also bei den "normalen" Datenoperationen Suchen, Einfügen, Löschen oder dem SELECT-Zugriff nicht spürbar anders im Verhalten.
Eigentlich.
Allerdings ist vorher zu klären, ob denn auch die (fachlichen) Anforderungen mit einer Speicherung als BLOB befriedigt werden können.
Du solltest also vorher prüfen oder mit allen Betroffenen in den Fachabteilungen diskutieren, ob
Aus der Aussage "es geht um Videos/Audios" lasst sich keine eindeutige Empfehlung ableiten.
Außer: Selbst derjenige, der den "Herr der Ringe" in der Datenbank gefunden und die erforderlichen Zugriffsrechte hat, kann ihn mit normalen SQL-Befehlen nicht anschauen.
Und - ebenso banal - Performance wird in der Konsequenz NICHT das Speichern und Verwalten der BLOBs kosten, sondern der Traffic/die Netzwerklast, wenn diese Monsterdateien zum Client und zurück transportiert werden.
Grüße
Biber
Dann würde ich gern noch wissen wie die allgemeine Praxis zum einstellen von großen Dateien in die Datenbank aussieht. Mal angenommen ihr wölltet Videos oder Audios, also Blob Elemente ablegen. Kommt der SQL Server damit überhaupt klar oder sollte man das aus Preformance gründen nicht machen oder was auch immer noch dagegen spicht?
Ist nicht gerade eine Frage, auf die sich eine klare und lehrbuchhafte Antwort geben lässt.
Unter der Voraussetzung, dass Du/Dein Unternehmen überhaupt den Leidensdruck hat
- BLOB-Elemente wie Videos/Audios/Binaries zentral strukturiert und wiederauffindbar zu speichern
- und nur einem dafür autorisierten Benutzerkreis zugänglich zu machen
--> dann ist die Speicherung von großen Datenklumpen in einer Datenbank nicht langsamer oder anfälliger als die in einem "normalen" Filesystem.
Performanzprobleme sind nicht zu befürchten - anders als bei VARCHAR oder LONGVARCHAR-Datentypen wird bei LOBs ja in der Datensatz-Struktur nur ein Pointer auf einen Speicherblock/ein Datensegment gespeichert.
Und dieser Pointer ist ja nur ein paar Byte lang (irgendwer mag das auch genau wissen, ob das nun 16 oder 32 oder 64 Byte sind - letzten Endes geht es jedenfalls im Rauschen unter).
Tabellen mit LOB-Feldern sind also bei den "normalen" Datenoperationen Suchen, Einfügen, Löschen oder dem SELECT-Zugriff nicht spürbar anders im Verhalten.
Eigentlich.
Allerdings ist vorher zu klären, ob denn auch die (fachlichen) Anforderungen mit einer Speicherung als BLOB befriedigt werden können.
- In LOB-Feldern sind keine SQL-üblichen Suchoperationen möglich
- zur "Versionsverwaltung" von Dateien sind LOB nicht ohne weiteres die erste Wahl
- eine Verwaltung von Dateien mit einer Datenbank stellt Dich und Deine UserInnen vor ein Dilemma: eigentlich sind diese Dateien nur einmal zentral in der DB vorhanden/gespeichert.. Andererseits könnten sie eigentlich nur sinnvoll lokal erstellt/bearbeitet/geändert werden.
- Und letzter Punkt führt leicht dazu, dass Du dann doch wieder ein "Referenz"-Dokument in der Datenbank hast und 3x soviele "Arbeitskopien" lokal bei den BenutzerInnen auf der Platte oder auf Fileservern.
Du solltest also vorher prüfen oder mit allen Betroffenen in den Fachabteilungen diskutieren, ob
- ein CMS oder ein Dokumentenverwaltungssystem
- oder ein Versionsverwaltungssystem wie CVS oder SVN
- oder eine Verzeichnisstruktur auf einem Fileserver
- oder eben eine Speicherung als BLOB in der Datenbank
Aus der Aussage "es geht um Videos/Audios" lasst sich keine eindeutige Empfehlung ableiten.
Außer: Selbst derjenige, der den "Herr der Ringe" in der Datenbank gefunden und die erforderlichen Zugriffsrechte hat, kann ihn mit normalen SQL-Befehlen nicht anschauen.
Und - ebenso banal - Performance wird in der Konsequenz NICHT das Speichern und Verwalten der BLOBs kosten, sondern der Traffic/die Netzwerklast, wenn diese Monsterdateien zum Client und zurück transportiert werden.
Grüße
Biber
Hi,
im konkreten geht es um Lehrvideos(10min-60min, das sind dann WMV, AVI und Mpeg Dateien und momentan sind die alle auf einem normalen Filesystem abgelegt. Nur da wir den Sharepoint (WSS) einsetzen und deshalb auch den SQL Server haben wurde gefragt ob das Sinn macht, die Dokumente im Sharepoint sind ja auch alle in der Datenbank auch wenn die viel kleiner sind aber dafür zahlenmäßig um einiges mehr
Ich hab es zwar noch nicht ausprobiert aber ich denke der Sharepoint wird solche Mediendateien ohne murren hochladen.
Suchbarkeit oä. würde dann, wie jetzt auch, durch die Inhaltstypen und andere Metainformationen hergestellt werden.
Und bearbeitet werden die nicht, bzw. würde das dann einfach herausgeladen vom Sharepoint und wieder hereingeladen, durch die Datenmenge sicher auch ohne Versionierung.
im konkreten geht es um Lehrvideos(10min-60min, das sind dann WMV, AVI und Mpeg Dateien und momentan sind die alle auf einem normalen Filesystem abgelegt. Nur da wir den Sharepoint (WSS) einsetzen und deshalb auch den SQL Server haben wurde gefragt ob das Sinn macht, die Dokumente im Sharepoint sind ja auch alle in der Datenbank auch wenn die viel kleiner sind aber dafür zahlenmäßig um einiges mehr
Ich hab es zwar noch nicht ausprobiert aber ich denke der Sharepoint wird solche Mediendateien ohne murren hochladen.
Suchbarkeit oä. würde dann, wie jetzt auch, durch die Inhaltstypen und andere Metainformationen hergestellt werden.
Und bearbeitet werden die nicht, bzw. würde das dann einfach herausgeladen vom Sharepoint und wieder hereingeladen, durch die Datenmenge sicher auch ohne Versionierung.
Moin ooAlbert,
dann wären doch Deine beiden Vorklärungs-Teilfragen beantwortet - die erste mit einem "Siehe unter Detach/Attach" und die zweite mit einem wortreichen "Spricht nix dagegen."
Dann fehlt doch nur ein kleiner grüner Haken an diesem Beitrag, oder?
Grüße
Biber
dann wären doch Deine beiden Vorklärungs-Teilfragen beantwortet - die erste mit einem "Siehe unter Detach/Attach" und die zweite mit einem wortreichen "Spricht nix dagegen."
Dann fehlt doch nur ein kleiner grüner Haken an diesem Beitrag, oder?
Grüße
Biber
