Hallo,
ärgerlicherweise bin ich der Empfehlung im Setup gefolgt und habe als Datenbank MS SQL 2005 Express gewählt, jetzt haben wir die 4 GB Speichergrenze erreicht.
Ich beabsichtige den Umstieg von MS SQL 2005 auf Postgresql. Wie kann ich die vorhandenen Daten am besten migrieren. Gibt es hierfür eine gute Anleitung oder sogar gute Freewaretools?
Die Auswahl in der Knowledgebase ist ja zu dem Thema recht spärlich…
Schönen Dank und viele Grüße
Nikos
Hi Nikolaos,
„ärgerlicherweise“ ist relativ.
Diese Entscheidung hat dir ja schließlich Zeit gespart: PostgreSQL ist kein „zero-Administration“ Datenbanksystem, da wird man sich dann zum Beispiel mit Wartungsplänen („vacuum is your best friend“) etc. auseinandersetzten müssen, damit die Sache performant läuft.
Meine Empfehlung:
Überleg dir ernsthaft, entweder einfach einen SQL Server zu kaufen, bevor du dir eine Migration (und die Suche der Lösung etwaiger Folgeprobleme) „antust“. Gibt’s ab 700,- EUR, hängt von den benötigten Lizenzen ab, aber wenn du bislang mit SQLExpress ausgekommen bist, kann das ja nicht so wild sein. Oder aber gehe alternativ auf die SQL Express 2008 Edition: dort ist die Grenze 10GB! 
Ich würde mich also fragen: „Was ist mein Business, wie wichtig ist CRM für mein Unternehmen und womit verdient mein Unternehmen eigtl. sein Geld?“ - und dann würde ich den SQL Server „upgraden“ und mich wieder dem Geldverdienen zuwenden. 
Gruß
Alex
Hallo!
SQL Server 2008 Express R2 hat eine Grenze von 10 GB
Frage ist halt ob dein cRM den schon unterstützt.
Vielen Dank für die schnellen Antworten. Mit dem SQL Server 2008 wird das Problem leider nur aufgeschoben, nicht aufgehoben 
Der Gedanke ist schon richtig, aber die 700 EUR wären aus derzeitiger Sicht rausgeschmissenes Geld, die Gründe hierfür kann ich leider an dieser Stelle nicht näher erläutern, die sind aber gewichtig…
Hi,
ich kann deine (wirtschaftlichen) Überlegung so natürlich nicht nachvollziehen, das ist dir bestimmt klar. 
(Solltest dir halt mal überlegen, wieviele Stunden du in die Migration investieren kannst, bis das Projekt die Firma teurer kommt, als 700,-. Dabei die Zeit etwaiger anderer cRM-Benutzer mitrechnen, die ja innerhalb des Zeitfensters der konkreten Migration keine Datensätze mehr auf MSSQL bearbeiten dürfen.)
Ich weiß ja nicht, wie lange du schon den cRM einsetzt, aber durch ein Update auf SQL Express 2008 würdest du mit sehr wenig Aufwand genau „nochmal soviel Zeit“ gewinnen (lineares Wachstum der Datenbank vorausgesetzt, ggf. sogar mehr Zeit, wenn Wachstum langsamer, weil die Stammdaten ja schon drin sind und wenn jetzt „nur noch“ Bewegungsdaten durch Aktivitäten dazukommen, kann ich aber nicht beurteilen).
Vielleicht konnte deine Firma bis dahin dann auch 700,- EUR ansparen. <SCHERZ! SCNR!>
Ansonsten: (bereits der zweite Treffer sieht recht viel versprechend aus, habe aber keine Erfahrung damit)
Gruß
Alex
PS: Ich geh mal davon aus, dass eingebettete Dokumente deine Datenbank fett machen: evtl. kannst du die Solution auch anders gestalten, so dass ihr riesige Dokumente (Scans, Bilder o.ä.) per Dateiverweis einbindet und nicht eingebettet, ggf. auch über eine ganz andere (speziell dafür konzipierte) Ansicht. (Nachteil: wenn man die Datenbank mit einem Notebook o.ä. repliziert, fehlen diese Dokument-Dateien dort natürlich. Aber da du das mit SQL Express derzeit aber sowieso nicht kannst ist es bei Euch wohl irrelevant. Wäre übrigens ein weiterer Pluspunkt für die Vollversion.)
Hallo Alex,
ja, das ist soweit klar;) Ohne die Hintergründe kann man es tatsächlich nicht nachvollziehen, aber es ist halt so…
Ich habe das Update auf SQL Express 2008 durchgeführt, die fehlermeldung, „42000 Speicherplatz für das ‚dbo.Activities‘.‚PK-Activities‘-Objekt… da die Dateigruppe ‚PRIMARY‘ voll ist…“ bleibt uns weiterhin treu:(
Viele Grüße
Nikos
Hi,
schau mal im Enterprise Manager in den Eigenschaften der Datenbank bei „Dateien“ in der Liste in der Spalte „Anfangsgröße“ und „Automatische Vergrößerung“ nach, wie groß die .mdf und die .ldf aktuell sind, und ob da evtl. ein max. Vergrößerungslimit eingestellt ist. Wenn ja, dann dieses hoch-setzen bzw. auf „unbeschränkt“ stellen.
Desweiteren kannste dann mal per Rechtsklick > Tasks > Verkleinern die Datenbank und die Dateien versuchen zu verkleinern.
Ich geh davon aus, dass du regelmäßig Sicherungen fährst, die das Transaktionsprotokoll (LDF) in die Datenbank dann einpflegen, so dass die LDF auch nicht gigantisch groß sein sollte. Sonst wäre das noch eine (wichtige) Baustelle.
Gruß
Alex
Hallo,
ich frage mich gerade, wie diese Datenbankgröße zustande kommt. Ist das tatsächlich die Größe der Zeilendaten (Eigenschaften der Datenbank - Dateien) oder ist es inklusive der Größe des Transaktionsprotokolls? Sollte es das Transaktionsprotokoll sein, empfiehlt es sich, dieses auch mal abzuschneiden oder je nach Backupkonzept den Wiederherstellungsmodus auf „einfach“ zu stellen. Aber: Das Transaktionskonzept wird nicht mit gezählt bei der Einschränkung der DB-Größe.
In Activities können auch Dokumente gespeichert werden - allerdings werden diese direkt in der Datenbank abgelegt und „verbraten“ dann auch ordentlich Platz.
Hier kann es durchaus sinnvoll sein, eine Anpassung vorzunehmen: Die Dokumente werden im Dateisystem abgelegt und als Dateiverweise in der Solution hinterlegt. Somit wird nur der Pfad zum Dokument abgelegt und die Datenbank wächst nicht so schnell.
Wir haben beispielsweise einen Kunden mit 2500 Belegen im Monat wovon ca. ein Drittel in Form von PDFs auch als Datensatzverweise abgespeichert werden. Dessen Datenbank hat aktuell ~2000 MB.
Ein Umstieg auf Postgresql ist nicht empfehlenswert - vielleicht 0,1% unserer Kunden nutzen PostgreSQL - die Umstellung ist auch nicht ohne, besonders wenn Automatismen weiterhin funktionieren sollen wie gehabt.
Wenn auf Zeit gespielt werden soll, geht auch folgendes:
Gruss,
Hallo!
Ein Wechsel auf ein neues Datenbanksystem ist sicherlich immer schwierig, insbesondere bei Microsoft, die sich leider nicht ganz an SQL-Standards halten.
Trotzdem muss ich hier glaube ich einige Sachen zu PostgreSQL klarstellen.
PG ist mittlerweile durchaus als „0 Administration DB“ zu bezeichnen.
Spätestens seit der Einführung von Autovacuum und anderen Automatismen muss man meiner Ansicht nach nicht mehr viel machen.
Ausserdem ist die Datenbankgröße bei PG laut Homepage unlimitiert[/b].]
Hallo NIKI,
falls das Thema noch aktuell ist.
Ich habe den Umstieg von MSSQL Server 2005 Express auf PostgreSQL 8 aus selbigem Grund (DB größe), damals mit dem Tool „ESF Database Migration Toolkit“ erledigt. Hat super funktionert. Das Programm kostet leider ein bisschen was, aber immer noch günstiger als die dauerhaften Lizenzkosten von Microsoft wenn man über die 10Gb Grenze bei der MSSQL Server 2008 Express R2 kommt.
Hier der Link zur Homepage:
[url=http://www.easyfrom.net/de/download/
Aktuell][/url] nutzen wir Combit v6.007 mit Postgres 9.x mit 16GB DB-größe
Gruß
Michael
Hallo, da ich gerade diesen Thread gefunden habe möchte ich eine ähnliche Fragen hinten anhängen. Momemtan trage ich mich auch mit dem Gedanken die 2005er Express Edition vom SQL Server zu verlassen und eventuell auf PostgreSQL umzustellen. Unser Problem ist allerdings etwas anders, hier geht es um die Grenze der Bytes per Row, die trotz Verwendung der von Mircosoft empfohlener Datentypen teilweise überschritten wird und so ein Speichern nicht möglich ist. Dazu bieten ja die Vollversionen auch keine Lösung, PostgreSQL schon da dort die Grenze 1,6TB und die maximale Spaltenbreite mit 250-1600 Spalten angegeben ist. Alles andere was Postgre bietet und wir brauchen, würde auch die Vollversion vom MS SQL Server bieten. Seht ihr ansonsten Hinderungsgründe es mit Postgre zu versuchen ?
