none
E2K10: Single Item Store RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hi Community,

    wir planen gerade ein Upgrade unseres E2K3EE auf einen E2K10. Hier habe ich bezgl. des Server Sizing einen interessanten Einwand hinsichtlich der in E2K3 integrierten "Single Item Store" Logistik gehört, fand aber bislang keine Bestätigung für die Aussage, dass es dieses Single Item Store im E2K10 nicht mehr gibt.

    Wenn ich das Feature in E2K3 richtig verstanden habe, dann würde dies in einem E2K10 das Anwachsen der Datenbank eklatant beschleunigen. Wenn zB ein User an alle anderen User, welche ihr Postfach in der selben Storage Group haben, eine E-Mail mit einem 10 MB Anhang schickt, habe ich den Anhang so oft gespeichert, wie ich Postfächer habe (bei 100 Postfächern habe ich ~1GB Platz verschleudert). Der E2K3 hat(te) (afair) den Anhang nur einmal gespeichert und diesen erst dann aus der Datenbank gelöscht, wenn der letzte Verweis zu dem Objekt gelöscht wurde.

    Wenn ich diesen kollegialen Einwand so wie beschrieben auch richtig verstanden habe, wäre das doch ein signifikanter Nachteil des neuen Speicherkonzepts gegenüber dem alten. Die Frage wäre demnach, ob ich das neue wie alte Konzept jetzt richtig interpretiert habe?

    Thx & Bye Tom

    Dienstag, 20. November 2012 11:51
    |

Alle Antworten

  • Discussion
    Anmelden
    1
    Anmelden

    Moin,

    wir planen gerade ein Upgrade unseres E2K3EE auf einen E2K10. Hier habe ich bezgl. des Server Sizing einen interessanten Einwand hinsichtlich der in E2K3 integrierten "Single Item Store" Logistik gehört, fand aber bislang keine Bestätigung für die Aussage, dass es dieses Single Item Store im E2K10 nicht mehr gibt.

    das ist korrekt. Der Single Instance Store (so heißt er korrekt) wurde mit Exchange 2007 runtergefahren und mit Exchange 2010 abgeschafft.

    Wenn ich das Feature in E2K3 richtig verstanden habe, dann würde dies in einem E2K10 das Anwachsen der Datenbank eklatant beschleunigen.

    Nicht unbedingt, da MSFT in diesem Zusammenhang die Datenbank-Struktur deutlich verbessert und eine bessere Komprimierung der Daten eingeführt hat.

    Der Mehraufwand des SIS wurde durch eine bessere Komprimierung, die aber weniger Aufwand braucht, ersetzt.

    Wenn zB ein User an alle anderen User, welche ihr Postfach in der selben Storage Group haben, eine E-Mail mit einem 10 MB Anhang schickt, habe ich den Anhang so oft gespeichert, wie ich Postfächer habe (bei 100 Postfächern habe ich ~1GB Platz verschleudert).

    Ja, logisch gesehen. Physisch aber nicht, da das Attachment komprimiert wird.

    Über den tatsächlichen Zuwachs kann man nur spekulieren.

    MSFT sagt ca. 10 Mehr-Bedarf voraus.

    Dafür sparst Du aber z.B. die STM-Datei

    Und aus Erfahrung kann ich sagen, dass der SIS leider auch immer wieder Probleme machte. Wenn nämlich in Deinem Szenario die eine Original-Version defekt ist, ist die Mail bei allen 100 Leuten verloren und führt noch dazu zu lustigen Outlook-Effekten.

    Wenn ich diesen kollegialen Einwand so wie beschrieben auch richtig verstanden habe, wäre das doch ein signifikanter Nachteil des neuen Speicherkonzepts gegenüber dem alten. Die Frage wäre demnach, ob ich das neue wie alte Konzept jetzt richtig interpretiert habe?

    Du hast es richtig verstanden, aber es definitiv kein Nachteil.

    Du solltest auch nicht vergessen, dass Festplatten- und Backup-Speicher im Vergleich zu 2003 nur noch einen Bruchteil kosten.

    Und für ein stabileres System, das deutlich schneller ist und mit größeren Postfächern zurechtkommt, verzichte ich gerne auf die Krücke SIS.

    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Dienstag, 20. November 2012 12:30
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Du hast es richtig verstanden, aber es definitiv kein Nachteil.

    Du solltest auch nicht vergessen, dass Festplatten- und Backup-Speicher im Vergleich zu 2003 nur noch einen Bruchteil kosten.

    Und für ein stabileres System, das deutlich schneller ist und mit größeren Postfächern zurechtkommt, verzichte ich gerne auf die Krücke SIS.

    Grüße aus Berlin schickt Robert
    MVP Exchange Server

    Servus,

    okay, soweit so gut. Danke auch für den richtigen Begriff 'Instance', dieser ist mir abgegangen, denn mit 'Item' bin ich irgendwie immer wieder auf Backup und Recovery gestolpert ;-)

    Der Einwand mit dem korrupten Anhang bei der SIS und den damit verbundenen Folgen ist natürlich berechtigt, wobei das bei uns noch nicht vorgekommen ist. Aber bei der Komprimierung der Daten habe ich so meine Zweifel. Es werden ja idR selten unkomprimierte Daten verschickt, entweder sind sie bereits verzippt oder es werden JPGs versendet, welche auf ihre Art ja bereits einen hohen Kompressionsfaktor aufweisen. Aus Sicht von Microsoft mag sich ja eine Excel-Tabelle oder ein Word-Dokument noch signifikant komprimieren lassen aber viele Dinge unterliegen bereits diversen Kompressionsverfahren.

    Kann Microsoft zB eine via E-Mail versendete ZIP-Datei noch im nennenswerten Umfang komprimieren? Oder bin ich da zu sehr auf die einzelnen Dateien fixiert?

    Gut und was die Preise des Datenspeichers angeht, da habe ich meine eigene Meinung. Mag sein, dass ein TB heute nicht mehr viel Geld kostet aber es macht zB einen Unterschied ob ich einen Filesystem-Check (chkdsk) über ein 200 GB großes Volume laufen lassen muss oder über ein 2 TB großes Volume. Auch das Handling einer großen Datenbank (unsere hat derzeit ca. 250GB) zB bei einem Restore macht sich bemerkbar. Wir mussten kürzlich, um ein einzelnes Postfach wiederherzustellen, eine Restore-Domäne mit eigenen Exchange hochziehen, und die gesamte dort die gesamte Datenbank wiederherstellen, weil wir die Recvery-Storage-Group nicht verwenden konnten. (Ich weiß nicht mehr warum aber es hatte afaik was mit den öffentlichen Ordnern zu tun). Das hat mit 250 GB schon keinen Spaß mehr gemacht...

    Aber gut, auch hier gilt, es ist wie es ist. Machen wir das beste daraus... ;-)

    Thx & Bye Tom

    Dienstag, 20. November 2012 14:35
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Am 20.11.2012 schrieb Thomas Pronto Wildgruber:
    Hi,

    Der Einwand mit dem korrupten Anhang bei der SIS und den damit verbundenen Folgen ist natürlich berechtigt, wobei das bei uns noch nicht vorgekommen ist.

    Das behauptet aber jeder von sich, bevor es ihm passiert. ;)

    Aber bei der Komprimierung der Daten habe ich so meine Zweifel. Es werden ja idR selten unkomprimierte Daten verschickt, entweder sind sie bereits verzippt oder es werden JPGs versendet, welche auf ihre Art ja bereits einen hohen Kompressionsfaktor aufweisen. Aus Sicht von Microsoft mag sich ja eine Excel-Tabelle oder ein Word-Dokument noch signifikant komprimieren lassen aber viele Dinge unterliegen bereits diversen Kompressionsverfahren.

    Wenns dich beruhigt, ja die Komprimierung ersetzt nicht 100% die SIS, aber
    es ist auch keine Verdopplung der bereits bestehenden Daten zu erwarten. Ich
    habe neulich 2 Exchange 2003 Datenbanken von je ca. 80GB migriert und in
    Exchange 2010 kamen je ca. 100GB bei raus. Da das aber zusätzlich noch vom
    Content und der vorher existierenden STruktur abhängt, ist das jetzt
    wirklich nur ein Richtwert. Im Allgemeinen gilt tatsächlich Speicher ist
    drastisch billiger geworden.

    Kann Microsoft zB eine via E-Mail versendete ZIP-Datei noch im nennenswerten Umfang komprimieren? Oder bin ich da zu sehr auf die einzelnen Dateien fixiert?

    Nein, bereits komprimierte Daten können logischerweise nicht mehr sinnvoll
    komprimiert werden.

    Gut und was die Preise des Datenspeichers angeht, da habe ich meine eigene Meinung. Mag sein, dass ein TB heute nicht mehr viel Geld kostet aber es macht zB einen Unterschied ob ich einen Filesystem-Check (chkdsk) über ein 200 GB großes Volume laufen lassen muss oder über ein 2 TB großes Volume.

    Ja, aber was hat das mit Exchange zu tun? Auch mit Exchange 2010 zwingt dich
    niemand, 2TB große Datenbanken zu erstellen.

    Auch das Handling einer großen Datenbank (unsere hat derzeit ca. 250GB) zB bei einem Restore macht sich bemerkbar. Wir mussten kürzlich, um ein einzelnes Postfach wiederherzustellen, eine Restore-Domäne mit eigenen Exchange hochziehen, und die gesamte dort die gesamte Datenbank wiederherstellen, weil wir die Recvery-Storage-Group nicht verwenden konnten. (Ich weiß nicht mehr warum aber es hatte afaik was mit den öffentlichen Ordnern zu tun). Das hat mit 250 GB schon keinen Spaß mehr gemacht...

    Dann ist ja gut, dass Exchange 2010 mit dem Recovery insgesamt viel besser
    klarkommt als das "Gepfriemel" mit Exchange 2003. ;)

    Aber gut, auch hier gilt, es ist wie es ist. Machen wir das beste daraus... ;-)

    Genau.

    Bye
    Norbert

    Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?

    Dienstag, 20. November 2012 15:24
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Ergänzend zu Norbert:

    Der Einwand mit dem korrupten Anhang bei der SIS und den damit verbundenen Folgen ist natürlich berechtigt, wobei das bei uns noch nicht vorgekommen ist.

    Bei mir schon öfter. Das Problem ist ja, das die meisten das nicht direkt bemerken. Das Element ist halt bei allen weg.

    Kann Microsoft zB eine via E-Mail versendete ZIP-Datei noch im nennenswerten Umfang komprimieren? Oder bin ich da zu sehr auf die einzelnen Dateien fixiert?

    MSFT hat die Datenbank-Struktur nicht offengelegt, daher können wir keine verbindlichen Aussagen zu den Inhalten machen.

    Aus Erfahrung kann ich das von Norbert bestätigen: Der Zuwachs ist geringer, als man erwartet.

    Gut und was die Preise des Datenspeichers angeht, da habe ich meine eigene Meinung. Mag sein, dass ein TB heute nicht mehr viel Geld kostet aber es macht zB einen Unterschied ob ich einen Filesystem-Check (chkdsk) über ein 200 GB großes Volume laufen lassen muss oder über ein 2 TB großes Volume.

    Mein letzter Filesystem-Check war zu Windows 2003-Zeiten.

    Aber wie Norbert schon schreibt: Es zwingt Dich ja niemand, große Datenbanken zu nehmen.

    Die Größe einer DB wird i.d.R. durch die Sicherung und die Laufwerke bestimmt. Nur dass Du bei Exchange 2010 eventuel eines mehr brauchst. Aber die Summe aller Laufwerke kostet heute nur noch einen Bruchteil der damaligen Laufwerke.

    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Dienstag, 20. November 2012 15:36
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Aber wie Norbert schon schreibt: Es zwingt Dich ja niemand, große Datenbanken zu nehmen.
    Grüße aus Berlin schickt Robert
    MVP Exchange Server

    Servus,

    okay, dass ist ein Argument. Wir hatten damals alles in einer Datenbank wegen SIS. Das funktioniert afaik nur innerhalb einer DB. Da SIS jetzt kein Thema mehr ist, könnte man ja das Unternehmen sinnvoll in mehrere DBs strukturieren...

    Das ist ein Punkt der sich jetzt aus der Erkenntnis so ergeben hat. Gut darüber gesprochen zu haben ;-)

    Thx & Bye Tom

    Dienstag, 20. November 2012 16:01
    |
  • Discussion
    Anmelden
    1
    Anmelden

    Hi Thomas,

    ...und zum Abschluss noch ein paar Fakten zur Kompremierung verschiedener Typen und SIS:
    http://blogs.technet.com/b/exchange/archive/2010/02/22/dude-where-s-my-single-instance.aspx

    Viele Grüße
    Christian

    Dienstag, 20. November 2012 16:25
    |
    Moderator