none
SCE Operations Database ist voll RRS feed

Antworten

  • Hi an alle,

    ja obiger Script hat gewirkt um die SCE DB von ca. 4400 MB auf ca. 1100 MB runter zu drücken.

    Wichtig: dauert eine ganze Weile - bei mir ca. 45 min. und mind. nochmals so viel HDD Platz wie die SCE DB groß ist.

    Obwohl Kevin Holmann nicht ganz sicher war, ob die MOM Scripte auch mit der SCE gehen, scheint es funktioniert zu haben - ohne Fehler.

    Danach Reindex aller Tabellen, DB und Log verkleinern und Serverneustart, weil das SCE vorher schon wg. voller DB klemmte. Danach war alles wieder in Sachen SCE OK.

     

     


    Oliver Richter
    • Als Antwort markiert Oliver Richter Freitag, 26. November 2010 11:12
    Freitag, 26. November 2010 11:12

Alle Antworten

  • Moin,

    du hast auch die Tipps unten in dem Blogpost schon durch, in dem die Haltezeit direkt per SQL-Kommando geändert wird? Das "Grooming" hast du danach abgewartet?

    Aufs Geratewohl irgendwelche Tabellen zu kürzen, dürfte schnell in einem echten Problem enden. Sowas würde ich nur auf Anweisung des MS-Support machen.

    Gruß, Nils

     


    Nils Kaczenski
    MVP Directory Services
    Hannover, Germany
    Mittwoch, 24. November 2010 15:14
  • Hi,

    Danke Nils. Die Tipps unten im Blogpost  - Haltezeit habe ich runter gesetzt, das Grooming abgewartet, zudem das Grooming per Hand 62 x angeschoben bringt alles nichts.

    Habe dann mal "Large Table query" gemacht um zu ermitteln siehe hier: http://blogs.technet.com/b/kevinholman/archive/2007/10/18/useful-operations-manager-2007-sql-queries.aspx

    Das ergab bei der MOM DB folgendes:

    tablename - reserved - row_count - data - index_size - unused - l1 - schemaname

     

    LocalizedText     3931904     4330656     3108192     822632      1080  1     dbo

    PublisherMessages 243856      4259597     242296      1360  200   0     dbo

    ManagementPack    204816      89    204704      16    96    1     dbo

    StateChangeEvent  67328 23729 44312 3544  19472 0     dbo

    KnowledgeArticle  63056 14444 62952 8     96    1     dbo

    Module      38872 23625 37528 1200  144   0     dbo

    Report      10640 75    10480 16    144   1     dbo

    ModuleType  9992  763   9744  88    160   0     dbo

    Monitor     4504  1502  4112  240   152   1     dbo

    MonitorType 4088  388   3896  72    120   0     dbo

    Rules 3256  8200  2744  416   96    1     dbo

    UIPageReference   2632  2699  2560  16    56    0     dbo

    Alert 2368  169   1608  192   568   1     dbo

    Views 2320  771   2200  16    104   0     dbo

    LinkedReport      2016  182   1856  32    128   1     dbo

    DataWarehouseDataset    1744  9     1704  32    8     0     dbo

    DataWarehouseScript     1504  34    1416  32    56    1     dbo

    StringResource    1360  4765  1344  16    0     0     dbo

    AlertHistory      1224  198   1016  160   48    1     dbo

    ImageEntity 1104  154   984   16    104   0     dbo

    Template    720   31    624   16    80    1     dbo

    DerivedManagedTypes     664   3220  216   336   112   0     dbo

    ReportResource    656   30    552   16    88    1     dbo

    UIPageSet   600   349   528   16    56    0     dbo

    MonitorOperationalState 600   2599  392   152   56    1     dbo

    UIDatatypeTransform     592   21    480   16    96    0     dbo

    MonitoringJobStatus     592   53    208   24    360   1     dbo

     

     

    Wenn ich das grob durchrechne, dann komme ich schon bei den ersten fünf Tabellen auf fast 4 GB (wenn data und index_size Werte in Byte sind)

    Die anderen Tabellen sind dann unter ferner liefen.

    Schaue ich mir die LocalizedText Tabelle dann mal an, stehen dort Einträge von Anfang 2009 und solche Dingen wie:

    +++++++++++

    Das Testpostfach wurde nicht initialisiert. Führen Sie 'new-TestCasConnectivityUser.ps1' aus, um sicherzustellen, dass das Testpostfach erstellt wird. Führen Sie anschließend 'Test-ActiveSyncConnectivity �ResetTestAccountCredentials' unter einem Systemkonto aus, um die Anmeldeinformationen dieses Benutzers für die Verwendung beim Testen der Clientzugriffsdienste zu speichern.
    Weitere Informationen:

     Postfachserver:MESS01-SRV

    [Microsoft.Exchange.Monitoring.CasHealthUserNotFoundException]: Der UserPrincipalName nicht in Active Directory gefunden. Weitere Fehlerinformationen: [System.Security.SecurityException]: Anmeldung fehlgeschlagen: unbekannter Benutzername oder falsches Kennwort.

    Response to rule: "{0EF8A63A-8592-07C5-FC81-3D5610A8A0DB}"

    ++++++++++++++

    Z.B. obiger Eintrag erscheint mehrere Hundert wenn nicht sogar tausende Male

    Oder auch dies zwei hier:

    ++++++++++++++++++++++

     

    Keine Überwachungsfehler. Die Überprüfung der erforderlichen Exchange-Dienste war erfolgreich.

    Response to rule: "{75B0616E-40DB-CE26-9B0A-D5C897F9BC69}"

    ++++++++++++++++++++++

    Exchange diagnostic cmdlet invocation succeeded.

     

    Response to rule: "{DC633AE8-205E-42CA-1EE4-06B1C5044EEF}"

    +++++++++++++++++++++++

     

    Tja wenn man nur wüßte, ob man diese Tabelle kürzen könnte. Scheint ja hier wirklich jede Menge alter Müll drinnen zu stehen. (Wobei diese Tabelle mit dieser hier: PublisherMessages bestimmt verknüpft ist.)

    Aber selbst wenn dem so ist,  es wird immer wieder neu in diese Tabelle rein geschreiben und vermutlich nie gelöscht. Das ist und bleibt dann wohl eine Zeitbombe.

    Jemand eine Idee zur Lösung? Danke!

     

     


    Oliver Richter
    Mittwoch, 24. November 2010 21:08
  • Moin,

    ich kenne mich mit SCOM nicht weiter aus, aber wenn du Einträge von 2009 in der DB hast, scheint mir das Grooming nicht zu funktionieren. Das soll doch genau für sowas sorgen.

    Gruß, Nils

     


    Nils Kaczenski
    MVP Directory Services
    Hannover, Germany
    Donnerstag, 25. November 2010 09:23
  • Hi Nils,

    da hast Du mich auf den richtigen Pfad geschickt. Bin hier fündig geworden:

    http://blogs.technet.com/b/kevinholman/archive/2008/10/13/does-your-opsdb-keep-growing-is-your-localizedtext-table-using-all-the-space.aspx

    Das lasse ich mal durchlaufen und sehe mir das danach mal an. Melde mich dann wieder...

     


    Oliver Richter
    Donnerstag, 25. November 2010 20:50
  • Hi an alle,

    ja obiger Script hat gewirkt um die SCE DB von ca. 4400 MB auf ca. 1100 MB runter zu drücken.

    Wichtig: dauert eine ganze Weile - bei mir ca. 45 min. und mind. nochmals so viel HDD Platz wie die SCE DB groß ist.

    Obwohl Kevin Holmann nicht ganz sicher war, ob die MOM Scripte auch mit der SCE gehen, scheint es funktioniert zu haben - ohne Fehler.

    Danach Reindex aller Tabellen, DB und Log verkleinern und Serverneustart, weil das SCE vorher schon wg. voller DB klemmte. Danach war alles wieder in Sachen SCE OK.

     

     


    Oliver Richter
    • Als Antwort markiert Oliver Richter Freitag, 26. November 2010 11:12
    Freitag, 26. November 2010 11:12
  • Sehr schön, danke für die Rückmeldung!

    Gruß, Nils

     


    Nils Kaczenski
    MVP Directory Services
    Hannover, Germany
    Freitag, 26. November 2010 12:49