<\/HEAD>
Speicher<\/H4>Im Fall von SQL Server gibt es mehrere Bewertungen, die Einblick in die Speichernutzung innerhalb der Instanz geben. Die meisten davon befinden sich in der Instanzkategorie der Expert Excel-Datei.<\/P><\/P>MemoryByDb ermöglicht es Ihnen, die Menge an Speicher (in diesem Fall Datenzeilen im Gegensatz zu SQL-Anweisungen oder anderem Speicherverbrauch) zu sehen, die von jeder Datenbank verwendet wird.<\/P><\/P>
<\/P><\/P>In diesem Fall sehen wir, dass die 1GIS7 eGDB der Hauptspeicherverbraucher in der SQL Server-Instanz ist. Es erscheint also vernünftig zu verstehen, dass die eGDB den Großteil des 3GB Instanzspeichers nutzen kann. Aber ist das zu viel oder nicht genug für gute Leistung und Systemgesundheit?<\/P><\/P>Die MemoryMetrics-Bewertung berichtet über mehrere Speichermetriken, die Hinweise darauf geben können, wie stark der Instanzspeicher nachgefragt wird. In diesem Fall sehen wir Warnungen, die darauf hindeuten, dass der vorhandene verfügbare Speicher in der Instanz für die Arbeitslast möglicherweise zu gering ist. Daher wissen wir nicht, ob 16GiB Maschinenspeicher zu viel oder zu wenig sind. Aber wir haben Grund zu der Annahme, dass 3GB Instanzspeicher zu wenig sind.<\/P><\/P>
<\/P><\/P>Es gibt mehrere weitere Speicherbewertungen in der Expert Excel-Datei. Es erfordert Erfahrung und Urteilsvermögen, diese Beobachtungen in ein fundiertes Urteil über den tatsächlichen Speicherbedarf des Systems zu integrieren. In diesem Fall, wie in vielen Fällen, sind die Schlussfolgerungen unvollständig. Aber sie sind besser als nichts.<\/P><\/P>Speicherplatz<\/H4>SQL Server liefert keine vollständigen Informationen über den lokalen Speicher auf dem Rechner, auf dem er läuft. Allerdings liefert er Informationen über die Größe der Dateien, in denen die eGDB gespeichert ist. Ein Großteil dieser Informationen ist in der Kategorie Database der Expert Excel-Datei verfügbar.<\/P><\/P>Das FileSpace-Bewertungsblatt berichtet über die Dateien, in denen die eGDB gespeichert ist. In diesem Beispiel sehen wir, dass es eine einzelne Datendatei (ROWS) gibt, die etwa 6GB groß ist und eine einzelne Transaktionsprotokolldatei (LOG), die in der Vergangenheit etwa 650MB genutzt hat. Sie können auch die vom DBA festgelegten maximalen Dateigrößen sehen, vermutlich als Hinweis auf den maximal erwarteten Speicherplatz für die eGDB.<\/P><\/P>
<\/P><\/P>Diese Daten sind gute Indikatoren für den benötigten Speicherplatz bei einem lift and shift-Szenario, bei dem die gesamte eGDB auf eine andere Plattform verschoben werden muss.<\/P><\/P>Dateninventar und Datenaustausch<\/H2>Ein weiterer Systemdesign-Fall ist, dass eGDB-Daten mit einem anderen Repository ausgetauscht werden müssen, vielleicht einer anderen Geodatabase in einem anderen Rechenzentrum. In diesen Fällen kann es relevant sein, die Speichergröße und andere Eigenschaften der auszutauschenden Daten festzustellen, im Gegensatz zur Speichergröße der gesamten eGDB.<\/P><\/P>Datensatzanzahlen und Speicher nach ObjectClass<\/H3>Wenn Sie die Identität der auszutauschenden ObjectClasses kennen, gibt es Informationen in der Content Excel-Datei zur Berichterstattung über Speichergröße und Datensatzanzahlen dieser Elemente. <\/P><\/P>In der Kategorie Storage gibt es ein Blatt namens ObjClass (ObjectClasses). Es berichtet sehr detailliert über die Tabellen, aus denen verschiedene eGDB ObjectClasses bestehen, wie viele Zeilen sie enthalten und wie viel Speicherplatz ihnen zugewiesen ist. <\/P><\/P>Im folgenden Beispiel gibt es drei ObjectClasses von Interesse (gefiltert in der ersten Spalte): BUILDINGS_NV, COUNTRIES und SSFITTING. BUILDINGS_NV hat etwa 4.400 Datensätze und verbraucht etwas mehr als 1,25MB Speicherplatz. COUNTRIES ist versioniert mit 249 Datensätzen in der Basistabelle, 66 Hinzufügungen und 5 Löschungen (die Spalte TableName nennt die A- und D-Tabellennamen für versionierte ObjectClasses).<\/P><\/P>
<\/P><\/P>So können wir die Datensatzanzahlen und ungefähren Speichereigenschaften von ObjectClasses von Interesse in der eGDB feststellen. Gleichzeitig können wir auch sehen, welche ObjectClasses als versioniert registriert sind. Dies ist kritische Information zur Festlegung des verfügbaren Spektrum an Optionen für den Datenaustausch.<\/P><\/P>Versionierung, Archivierung und Replikationsstatus<\/H3>In derselben Context Excel-Datei bietet das ObjClassOverview-Blatt (Inventarkategorie) einen Überblick über den Versionierungs-, Archivierungs- und Replikationsstatus aller ObjectClasses in der eGDB. Dies bietet einen bequemeren Mechanismus zur Planung des Spektrums an Datenübertragungsmechanismen, die für verschiedene ObjectClasses geeignet wären.<\/P><\/P>
Überlegungen zum verteilten Datenentwurf
Die ArcGIS-Dokumentation bezeichnet diesen thematischen Bereich als verteilt gespeicherte Daten und bietet allgemeine Richtlinien zu den verschiedenen Strategien an, mit denen Daten bewegt werden können:
http:\/\desktop.arcgis.com\en\arcmap\latest\manage-data\geodatabases\understanding-distributed-data.htm.
Versionierte Daten und Geodatabase-Replikation
Wenn eine ObjectClass noch nicht als versioniert registriert ist, kann es angemessen oder nicht angemessen sein, dies für Zwecke der Nutzung von Geodatabase Replication zu tun. Dies hängt davon ab, wie die Daten aktualisiert werden. Die meisten als versioniert registrierten Daten werden transaktional aktualisiert, was bedeutet, dass nur ein kleiner Prozentsatz der Gesamtdatensätze zu einem gegebenen Zeitpunkt geändert wird. Diese Art von Aktualisierung ist sowohl mit Versionierung als auch mit Geodatabase Replication kompatibel. Andere Daten werden mit Methoden wie truncate and add (abschneiden und hinzufügen), delete and replace (löschen und ersetzen) oder copy and paste aktualisiert. In diesen Fällen werden die meisten Datensätze physisch aktualisiert (auch wenn die Mehrheit der Werte gleich bleibt, wurden physisch neue Datensätze eingesetzt). Diese Art von Aktualisierung eignet sich nicht besonders gut für Geodatabase Replication. Die Informationen in egdbhealth können Ihnen Auskunft über den Versionierungs- und Replikationsstatus von ObjectClasses geben. Aber sie wissen nicht, wie diese ObjectClasses tatsächlich aktualisiert werden. Hoffentlich sind diejenigen als versioniert registrierten transaktional aktualisiert und daher geeignete Kandidaten für Geodatabase Replication.
Archivierung von Daten und Datenaustausch
Wenn eine ObjectClass Archivierung aktiviert hat, kann es zusätzliche Überlegungen geben. Zum Beispiel könnte ein geplanter Datenaustausch dazu führen, dass sich das Volumen an Archivinformationen auf unerwünschte Weise erhöht.
Für versionierte ObjectClasses mit aktivierter Archivierung werden Archivinformationen in einer separaten History-Tabelle gespeichert. Die Größe dieser Tabelle beeinflusst nicht die Abfrageleistung der versionierten Daten. Hierbei besteht das Hauptdesignproblem darin festzustellen, ob es praktikabel ist alle Archivinformationen dauerhaft zu speichern und zu nutzen. In vielen Fällen wird dies so sein. Aber diese Entscheidung erfordert Kenntnis des Archivierungsstatus der ObjectClass sowie der geplanten Aktualisierungsrate.
Im Fall von nicht-versionierten ObjectClasses mit aktivierter Archivierung (und branch-versionierten ObjectClasses) befinden sich Archivinformationen in der Haupttabelle. Daher kann ein schnelles Wachstum an Archivinformationen Auswirkungen auf das Performance-Tuning von ObjectClasses und/oder eGDB haben. Egdbhealth kann zukünftige Aktualisierungsbedarfe nicht kennen. Es kann jedoch historische Muster von Aktualisierungen bei nicht-versionierten archivierten ObjectClasses berichten. Die Context Excel-Datei enthält ein Blatt namens NvArchEditDatesSql mit SQL-Anweisungen für jede nicht-versionierte archivierte ObjectClass in der eGDB. Diese Anweisungen werden nicht automatisch ausgeführt da sie ressourcenintensive Abfragen sind und nicht unter allen Umständen relevante Informationen liefern.
\/><\/P>
<\/P>
In diesem Systemdesign-Fall kann es jedoch sehr relevant sein, die Rate zu ermitteln, mit der Datensätze im Laufe der Zeit angesammelt wurden, um eine Strategie für den Datenaustausch zu planen. Verwenden Sie einen SQL-Client wie SQL Server Management Studio, um die Abfragen für die betreffenden ObjectClasses auszuführen und ein Gefühl für die Rate der Datenaktualisierung zu bekommen. In diesem Beispiel sehen wir ein Muster für Datensatzaktualisierungen, bei dem die typische Aktualisierung klein ist (1 Datensatz), aber es gab mindestens einen Fall, in dem eine große Aktualisierung im Verhältnis zur Größe der ObjectClass stattfand (289 Datensätze am 8. April 2018):<\/P>
<\/P>
<\/P>
<\/P>
Anhangsgröße und mobile Synchronisation<\/H5>Ein weiterer Designfall, der sich auf verteilte Daten bezieht, ist die feldbasierte Datenerfassung und Anhänge. Collector for ArcGIS verwendet effiziente Mechanismen, die ähnlich wie Geodatabase Replication funktionieren, um "Deltas" zwischen Client und Server zu synchronisieren. Allerdings kann die Fähigkeit, große Mengen an Daten in Anhängen (wie Bilder) zu sammeln, sowie die oft begrenzten Netzwerkbedingungen, unter denen die Daten synchronisiert werden können, Systemdesign-Probleme aufwerfen.<\/P><\/P>Die Expert Excel-Datei enthält eine Bewertung "LargeAttachments", die automatisch Fälle von wahrscheinlichen Bedenken hervorhebt. Im folgenden Beispiel wurden die Schwellenwerte nicht überschritten, daher gab es keine negative Bewertung:<\/P><\/P>
<\/P><\/P>Es kann jedoch dennoch nützlich sein, etwas über die Art der vorhandenen Anhänge zu wissen. Die Context Excel-Datei enthält ein Blatt "AttachmentSizeSql" (Kategorie "Inventory"), das mehrere SQL-Anweisungen für jede ObjectClass enthält, die Anhänge hat. <\/P><\/P>
<\/P><\/P>Das Ausführen dieser SQL-Anweisungen in einem Client wie SQL Server Management Studio ermöglicht es Ihnen, die Anhänge auf verschiedene Weise statistisch zu charakterisieren: aggregierte Statistiken, Top 100 nach Größe und Perzentilverteilung. <\/P><\/P>
<\/P><\/P>Mit diesen Statistiken können Sie nicht nur die Gesamtmenge an Informationen verstehen, sondern auch feststellen, ob diese auf eine große Anzahl kleiner Anhänge oder eine kleine Anzahl großer Anhänge zurückzuführen ist. Große Anhänge könnten ein größeres Risiko bei der Synchronisation über schlechte Netzwerkbedingungen darstellen und könnten Sie dazu veranlassen, eine Empfehlung auszusprechen, dass die Datenerfassung im Offline-Modus erfolgen soll und die Synchronisation nur unter bestimmten Netzwerkbedingungen stattfinden darf.<\/P><\/P>Überlegungen zur Anhangsgröße könnten Sie auch dazu führen, Empfehlungen darüber abzugeben, ob und wie es praktisch wäre, eine bidirektionale Synchronisation (im Gegensatz zur unidirektionalen) zu handhaben. Während feldbasierte Benutzer möglicherweise ausreichende Netzwerkbedingungen haben, um die von ihnen einzeln gesammelten Anhänge hochzuladen, würde eine bidirektionale Synchronisation bedeuten, dass alle von anderen Personen (im Synchronisationsbereich) gesammelten Anhänge heruntergeladen werden müssten. In einigen Fällen könnte dies ein Vielfaches der Menge an Informationen sein, die hochgeladen werden müssten.<\/P><\/P>Zusammenfassung<\/H2>Als Designer von GIS-Systemen ist es nicht praktikabel für Sie, in allen Technologiegebieten des Systems tiefgreifende Expertise zu besitzen. Aus diesem Grund sind Ihr Verständnis der egdbhealth-Ausgaben und dessen Nutzungsmöglichkeiten begrenzt. Der Zweck dieses Artikels ist es, einige der häufigsten Anwendungsfälle für egdbhealth-Ausgaben im Systemdesign aufzuzeigen. Die Hauptinteressensgebiete sind (1) Maschinenbemessung / Ressourcennutzung und (2) datenbezogene Merkmale relevant für den Datenaustausch. Das Befolgen der Beispiele in diesem Artikel und deren Verallgemeinerung auf Oracle- und PostgreSQL-Datenbanken ermöglicht es Ihnen, nützliche Informationen aus dem egdbhealth-Tool für Ihre Designarbeit zu gewinnen.<\/P><\/P>Ich hoffe, Sie finden dies hilfreich. Zögern Sie nicht, Ihre Fragen hier zu stellen: https:\/\/community.esri.com\/thread\/231451-arcgis-architecture-series-tools-of-an-architect<\/SPAN><\/A><\/SPAN><\/P> <\/SPAN><\/P>Hinweis:<\/_EM> Die oben dargestellten Inhalte sind Empfehlungen, die typischerweise die Leistung in vielen Szenarien verbessern. In einigen Fällen können diese Empfehlungen jedoch keine besseren Leistungsergebnisse liefern. In solchen Fällen sind zusätzliche Leistungstests und Systemkonfigurationsänderungen erforderlich.<\/_EM>
