Gebruik van Egdbhealth in Systeemontwerp

DannyKrouk_ps

<\/HEAD>

Inleiding<\/a><\/li>Informatie Doelstellingen voor Systeemontwerp<\/a><\/li>Machinebronnen en Gebruik<\/a><\/li>De Machine<\/a><\/li>Het Gebruik<\/a><\/li>Processor<\/a><\/li>Geheugen<\/a><\/li>Opslag<\/a><\/li>Data Inventaris en Data-uitwisseling<\/a><\/li>Record Aantallen en Opslag per ObjectClass<\/a><\/li>Versiebeheer, Archivering en Replicatiestatus<\/a><\/li>Overwegingen voor Gedistribueerd Dataontwerp<\/a><\/li>Geverifieerde Data en Geodatabase Replicatie<\\/a><\\/li><\\li style=\"list-style-type:disc; margin-left:100px; margin-bottom:1px;\">Archivering van Data en Data-uitwisseling<\\/a><\\/li><\\li style=\"list-style-type:disc; margin-left:100px; margin-bottom:1px;\">Bijlagegrootte en Mobiele Synchronisatie<\\/a><\\/li><\\li style=\"list-style-type:disc; margin-left:25px; margin-bottom:1px;\">Samenvatting<\\/a><\\/li><\\ul><\\H2>

Opmerking: Deze blogpost is de derde in de serie van drie geplande berichten over egdbhealth. De eerste introduceerde het gereedschap, hoe het te installeren en hoe het uit te voeren. De tweede in de serie behandelde hoe het gereedschap te gebruiken om de gezondheid van een Enterprise Geodatabase te evalueren; het primaire doel. Dit artikel behandelt het gebruik van egdbhealth in een systeemontwerpcontext.<\\/SPAN><\\/BLOCKQUOTE>

Inleiding<\\H2>Egdbhealth is een hulpmiddel voor rapportage over verschillende kenmerken van Enterprise Geodatabases (eGDBes). Het primaire doel van het gereedschap is om de "gezondheid" van eGDBes te evalueren. Echter, de output kan ook worden gebruikt in een systeemontwerpcontext. Dit artikel behandelt de systeemontwerp-gebruikscasus.<\\P><\\P>Voor informatie over het installeren en uitvoeren van het gereedschap, zie alstublieft de eerste blogpost in deze serie "Wat is Egdbhealth?"<\\SPAN><\\P><\\P>Informatie Doelstellingen voor Systeemontwerp<\\H2>De Esri systeemontwerppraktijk richt zich op het plannen van hardware-, software- en netwerkkenmerken voor de toekomstige staat van systemen op basis van nieuwe of veranderende vereisten.<\\P><\\P>De huidige gezondheid van een bestaand systeem zal niet noodzakelijkerwijs een sterke relatie hebben met een toekomstig systeem dat andere vereisten heeft. Echter, afhankelijk van de ontwerpdoelstellingen kan informatie over het huidige systeem relevant zijn.<\\P><\\P>Bijvoorbeeld, in het geval van een geplande migratie van een on-premises systeem naar een cloudplatform, zou het zeer nuttig zijn om het huidige systeem zo te beschrijven dat het getrouw kan worden weergegeven op een cloudplatform. Of, vereisten die een ontwerp aansturen kunnen aangeven dat er behoefte is om grote delen van een Geodatabase uit te wisselen (repliceren, verplaatsen, synchroniseren, transformeren, kopiëren, enz.) naar een andere opslagplaats. In dat geval kan een inventaris van de inhoud van de Geodatabase nuttig zijn om belangrijke details vast te stellen over de aard en hoeveelheid data die uitgewisseld moet worden en de optimale manieren waarop die data-uitwisseling kan plaatsvinden.<\\P><\\P>Dus, op hoog niveau is het voornamelijk de beschrijvende informatie uit egdbhealth, in plaats van de evaluatieve informatie, die relevant is voor systeemontwerp.<\\P><\\P>Dit artikel bespreekt voorbeelden voor een SQL Server ondersteunde eGDB. Echter, de principes zijn hetzelfde voor eGDBes die worden ondersteund door Oracle en PostgreSQL.<\\P><\\P>Machinebronnen en Gebruik<\\H2>Voor systeemontwerpsituaties waarbij het eGDB-machineplatform zal veranderen, kan het nuttig zijn om de huidige machinebronnen die de eGDB ondersteunen en hun mate van gebruik te begrijpen. Bijvoorbeeld, als u een eGDB migreert naar een cloudplatform, heeft het aantal processorkernen dat het systeem on-premises heeft enige relevantie voor het aantal dat u mogelijk op de cloud inzet.<\\P><\\P>De Machine<\\H3>Het HTML-metadata bestand geproduceerd door egdbhealth zal resource-informatie geven over het machineplatform waarop de RDBMS draait.<\\P><\\P>In het onderstaande voorbeeld draait de SQL Server instantie op een machine met één processor die 8 logische processorkernen presenteert.<\\P><\\P></ P >< P >< \/ P > < P > Deze informatie vanuit SQL Server laat enkele zaken onduidelijk. Bijvoorbeeld, SQL Server kan niet rapporteren of de logische kernen het resultaat zijn van hyperthreading. Als dat zo is, dan zouden de fysieke kernen de helft zijn van de logische kernen (4 fysieke kernen). En het is het aantal fysieke kernen dat het meest bruikbaar is voor capaciteitsplanning in systeemontwerp. Dus deze informatie is goed maar onvolmaakt.< \/ P > < P >< \/ P > < P > De HTML rapporteert ook het fysieke geheugen op de machine (16GiB) en het minimum en maximum geheugen geconfigureerd voor de SQL Server instantie (0 en 3GB). Hier zien we dat de configuratie van de SQL Server instantie vrij relevant is om de relevante geheugenbronnen voor capaciteitsplanning te begrijpen. Hoewel de machine 16GiB geheugen heeft, heeft deze SQL Server instantie (en de eGDB die hij ondersteunt) geen toegang tot al dat geheugen.< \/ P > < P >< \/ P > < H3 id=\"toc-hId-1751530674\">Het Gebruik< \/ H3 > < P > De kenmerken van de machine en de configuratie van de instantie bieden onvolledig inzicht in hoeverre de machinebronnen worden gebruikt en welke bronnen echt nodig zijn voor de huidige werklast.< \/ P > < P > We kunnen zeker zijn dat SQL Server niet meer dan 3GB geheugen gebruikt. Maar gebruikt hij dit grondig? En wat betreft de processorbronnen; zijn ze druk of idle?< \/ P > < P >< \/ P > < P > Veel van de gebruiksinformatie verschijnt in het Expert Excel-bestand omdat deze relatief vluchtig is.< \/ P > < P >< \/ P > < H4 id=\"toc-hId--997139792\">Processor< \/ H4 > < P > In het geval van SQL Server is er een evaluatie in het Expert Excel-bestand genaamd "ProcessorUtil" (Processorgebruik; categorie is "Instance"). Het geeft een steekproef weer van recent per minuut processorgebruik door SQL Server op de machine. In dit geval zien we dat SQL Server gedurende deze meetperiode bijna geen gebruik maakt van alle processormiddelen van de machine waarop hij draait.< \/ P > < P >< \/ P > < P >< IMG __jive_id=\"443793\" alt=\"Processor gebruik\" class=\"image-2 jive-image j-img-original\" src=\"https:\ /us.v-cdn.net /6038851/uploads /legacyfs /online /443793_processor_utilization.png \" \/></ P >< P >< \/ P > < P > Hieruit concluderen we dat als deze periode typisch is, de bestaande machine veel meer processormiddelen heeft dan nodig is. Als alles gelijk blijft, kan het toekomstige systeemontwerp minder processorkernen specificeren om de eGDB werklast te ondersteunen. Natuurlijk moet u om deze conclusie betrouwbaar te maken, het gereedschap uitvoeren tijdens typische en/of piekbelastingperioden.< \/ P > < P >< \/ P > < P > Er is nog een evaluatie, CpuByDb (Instance-categorie), die rapporteert welke databases in de instantie de meeste processorbronnen verbruiken.  Dus, in het geval dat de instantie een significante processorbelasting had, kan deze informatie worden gebruikt om te bepalen of die processorbelasting gerelateerd was aan de eGDB van belang of aan een andere workload in dezelfde SQL Server-instantie.<\/P><\/P><\/P><\/P>Geheugen<\/H4>In het geval van SQL Server zijn er verschillende evaluaties die inzicht geven in het geheugengebruik binnen de instantie.  De meeste hiervan bevinden zich in de Instance-categorie van het Expert Excel-bestand.<\/P><\/P>MemoryByDb stelt u in staat om de hoeveelheid geheugen te zien (in dit geval rijen data in plaats van SQL-instructies of ander geheugengebruik) die door elke database wordt gebruikt.<\/P><\/P><\/P><\/P>In dit geval zien we dat de 1GIS7 eGDB de primaire geheugengebruiker is in de SQL Server-instantie.  Het lijkt dus redelijk om te begrijpen dat de eGDB het grootste deel van de 3GB instantiegeheugen kan gebruiken.  Maar is dat te veel of niet genoeg voor goede prestaties en systeembalans? <\/P><\/P>De MemoryMetrics-evaluatie rapporteert over verschillende geheugenstatistieken die aanwijzingen kunnen geven over hoe gevraagd het instantiegeheugen is.  In dit geval zien we waarschuwingen die suggereren dat het bestaande beschikbare geheugen voor de instantie mogelijk te laag is voor de workload.  Dus weten we niet of 16GiB machinegeheugen te veel of te weinig is.  Maar we hebben reden om aan te nemen dat 3GB instantiegeheugen te weinig is.<\/P><\/P><\/P><\/P>Er zijn verschillende andere geheugenevaluaties in het Expert Excel-bestand.  Het vergt ervaring en oordeel om deze observaties te integreren tot een geïnformeerd oordeel over de werkelijke geheugennoden van het systeem.   In dit geval, zoals in veel gevallen, zijn de afleidingen die men kan maken onvolledig.  Maar ze zijn beter dan niets.<\/P><\/P>Opslag<\/H4>SQL Server biedt geen volledige informatie over de lokale opslag op de machine waarop het draait.  Het biedt echter wel informatie over de grootte van de bestanden waarin de eGDB is opgeslagen.  Veel van deze informatie is beschikbaar in de Database-categorie van het Expert Excel-bestand.<\/P><\/P>Het FileSpace-evaluatieblad rapporteert over de bestanden waarin de eGDB is opgeslagen.  In dit voorbeeld zien we dat er een enkel data bestand (ROWS) is van ongeveer 6GB en een enkel transactielogbestand (LOG) dat in het verleden ongeveer 650MB heeft gebruikt.  U kunt ook de maximale bestandslimieten zien die door de DBA zijn vastgesteld, vermoedelijk als indicatie van de maximaal verwachte opslag voor de eGDB.<\/P><\/P><\/P><\/P>Deze gegevens zijn goede indicaties van de hoeveelheid opslag die nodig zou zijn voor een lift and shift-scenario waarbij de gehele eGDB naar een ander platform moet worden verplaatst.<\/P><\/P>Data-inventaris en Data-uitwisseling<\/H2>Een ander systeemontwerpcasus is dat eGDB-gegevens moeten worden uitgewisseld met een andere repository, misschien een andere Geodatabase in een ander datacenter.  In deze gevallen kan het relevant zijn om de opslaggrootte en andere kenmerken van de gegevens die zullen worden uitgewisseld vast te stellen, in plaats van de opslaggrootte van de gehele eGDB.<\/P><\/P>Recordaantallen en Opslag per ObjectClass<\/H3>Als u weet welke ObjectClasses worden uitgewisseld, is er informatie in het Content Excel-bestand om te rapporteren over opslaggrootte en recordaantallen van die items. <\/P><\/P>In de Storage-categorie is er een blad genaamd ObjClass (ObjectClasses).  Het rapporteert, in aanzienlijke details, over de tabellen waaruit verschillende eGDB ObjectClasses bestaan, het aantal rijen dat ze bevatten en hoeveel opslagruimte aan elk ervan is toegewezen. <\/P><\/P>In het onderstaande voorbeeld zijn er drie ObjectClasses van belang (gefilterd in de eerste kolom): BUILDINGS_NV, COUNTRIES en SSFITTING.  BUILDINGS_NV heeft ongeveer 4.400 records en gebruikt iets meer dan 1,25MB ruimte.  COUNTRIES is versioned, met 249 records in de basistabel, 66 toevoegingen en 5 verwijderingen (de TableName-kolom geeft de A en D tabelnamen aan voor versioned ObjectClasses).<\/P><\/P><\/P><\/P>Zo kunnen we het aantal records en geschatte opslagkenmerken vaststellen van ObjectClasses van belang in de eGDB.  Tegelijkertijd kunnen we ook zien welke ObjectClasses geregistreerd zijn als versioned.  Dit is cruciale informatie om het scala aan beschikbare opties voor data-uitwisseling vast te stellen.<\/P><\/P>Versioning, Archivering en Replicatiestatus<\/H3>In hetzelfde Context Excel-bestand geeft het ObjClassOverview (Inventory-categorie) een overzicht van versioning-, archivering- en replicatiestatussen van alle ObjectClasses in de eGDB.  Dit biedt een handigere manier om het scala aan data-uitwisselingsmechanismen te plannen die geschikt zouden zijn voor verschillende ObjectClasses.<\/P><\/P>

Overwegingen bij gedistribueerd dataontwerp
De ArcGIS-documentatie verwijst naar dit themagebied als distributed data en biedt algemene richtlijnen over verschillende strategieën die kunnen worden gebruikt om data te verplaatsen: http:\/\desktop.arcgis.com\en\arcmap\latest\manage-data\geodatabases\understanding-distributed-data.htm.

Versioned Data en Geodatabase Replicatie
Als een ObjectClass nog niet geregistreerd is als versioned kan het wel of niet passend zijn om dit te doen met het oog op gebruik van Geodatabase Replicatie.  Dit heeft betrekking op hoe data wordt bijgewerkt.  De meeste data die geregistreerd zijn als versioned worden transactioneel bijgewerkt, wat betekent dat slechts een klein percentage van alle records op enig moment wordt gewijzigd.  Dit soort bijwerken is compatibel met zowel versioning als Geodatabase Replicatie.  Andere data wordt bijgewerkt met methoden zoals truncate and add, delete and replace of copy and paste.  In deze gevallen worden de meeste records fysiek bijgewerkt (zelfs als het merendeel van recordwaarden hetzelfde blijft, zijn fysieke records vervangen).  Dat soort bijwerken is niet bijzonder geschikt voor Geodatabase Replicatie.  De informatie in egdbhealth kan u vertellen over versioning- en replicatiestatussen van ObjectClasses.  Maar weet niet hoe deze ObjectClasses daadwerkelijk worden bijgewerkt.  Hopelijk worden degenen die geregistreerd zijn als versioned transactioneel bijgewerkt en zijn daarom geschikte kandidaten voor Geodatabase Replicatie.


Archiveren van Data en Data-uitwisseling
Als een ObjectClass archivering ingeschakeld heeft, kunnen er extra overwegingen zijn.  Bijvoorbeeld als geplande data-uitwisseling mogelijk het updatepercentage verhoogt, kan dit leiden tot ongewenste groei van archiefinformatie.


Voor versioned ObjectClasses met archivering wordt archiefinformatie opgeslagen in een aparte history-tabel.  De grootte van deze tabel beïnvloedt niet de queryprestaties van versiegegevens.  De belangrijkste ontwerpvraag hier is of het praktisch is om alle archiefinformatie te bewaren en gebruiken.  In veel gevallen zal dat zo zijn.  Maar deze bepaling vereist kennis over archiveringsstatus en geplande updatefrequentie.


Voor niet-versioned ObjectClasses met archivering (en branch-versioned ObjectClasses) bevindt archiefinformatie zich in hoofdtabel.  Snelle groei hiervan kan prestatieafstemming vereisen voor ObjectClasses en/of eGDB.  Egdbhealth kan toekomstige updatebehoeften niet voorspellen maar wel historische updatepatronen rapporteren voor niet-versioned, archive-enabled ObjectClasses.  Het Context Excel-bestand bevat een blad "NvArchEditDatesSql" met SQL-instructies voor elke niet-versioned, archive-enabled ObjectClass in eGDB.  Deze instructies worden niet automatisch uitgevoerd omdat ze resource-intensieve queries zijn die niet altijd relevant zijn.


<\/P><\/P>In dit systeemontwerpcasus kan het echter zeer relevant zijn om het tempo te bepalen waarmee records in de loop van de tijd zijn verzameld voor het plannen van een data-uitwisselingsstrategie.  Gebruik een SQL-client zoals SQL Server Management Studio om de queries voor de betreffende ObjectClasses uit te voeren om een idee te krijgen van het tempo van data-updates.  In dit voorbeeld zien we een patroon voor recordupdates waarbij de typische update klein is (1 record), maar er was ten minste één gelegenheid waarbij er een grote update was in verhouding tot de grootte van de ObjectClass (289 records op 8 april 2018):<\/P><\/P><\/P><\/P>Bijlagegrootte en mobiele synchronisatie<\/H5>Een andere ontwerpcasus die betrekking heeft op gedistribueerde data is veldgebaseerde dataverzameling en bijlagen.  Collector for ArcGIS maakt gebruik van efficiënte mechanismen die vergelijkbaar zijn met Geodatabase Replication om "deltas" tussen client en server te synchroniseren.  Echter, het vermogen om grote hoeveelheden data in bijlagen (zoals afbeeldingen) te verzamelen en de vaak beperkte netwerkcondities waarin de data gesynchroniseerd kan worden, kunnen systeemontwerpkwesties oproepen.<\/P><\/P>Het Expert Excel-bestand heeft een evaluatie "LargeAttachments" die automatisch gevallen van mogelijke zorg onder uw aandacht zal brengen.  In het onderstaande voorbeeld werden de drempelwaarden niet overschreden, dus was er geen negatieve evaluatie:<\/P><\/P><\/P><\/P>Het kan echter nog steeds nuttig zijn iets te weten over de aard van de bestaande bijlagen.  Het Context Excel-bestand bevat een blad "AttachmentSizeSql" (categorie "Inventory") dat verschillende SQL-instructies bevat voor elke ObjectClass die bijlagen heeft. <\/P><\/P><\/P><\/P>Het uitvoeren van deze SQL-instructies in een client zoals SQL Server Management Studio stelt u in staat om statistisch de bijlagen op verschillende manieren te karakteriseren: geaggregeerde statistieken, top 100 op grootte, en percentielverdeling. <\/P><\/P><\/P><\/P>Met deze statistieken kunt u niet alleen de totale hoeveelheid informatie begrijpen, maar ook of dit komt door een groot aantal kleine bijlagen of een klein aantal grote bijlagen.  Grote bijlagen kunnen een groter risico vormen voor synchronisatie over slechte netwerkcondities en kunnen u ertoe brengen aan te bevelen dat dataverzameling in een losgekoppelde modus werkt en synchronisatie alleen onder specifieke netwerkcondities plaatsvindt.<\/P><\/P>Overwegingen over bijlagegrootte kunnen u ook doen aanbevelingen geven over of en hoe het praktisch zou zijn om tweerichtingssynchronisatie af te handelen (in tegenstelling tot eenrichtingsverkeer).  Hoewel veldgebruikers mogelijk voldoende netwerkomstandigheden hebben om de bijlagen die ze individueel verzamelen te uploaden, zou tweerichtingssynchronisatie betekenen dat alle bijlagen verzameld door andere personen (in het synchronisatiegebied) gedownload moeten worden.  In sommige gevallen kan dit vele malen meer informatie zijn dan wat geüpload moet worden.<\/P><\/P>Samenvatting<\/H2>Als ontwerper van GIS-systemen is het niet praktisch dat u diepgaande expertise hebt in alle technologiegebieden die betrekking hebben op het systeem.  Om deze reden heeft uw begrip van egdbhealth-uitvoer en wat u ermee kunt doen beperkingen.  Het doel van dit artikel is enkele van de meest voorkomende gebruikssituaties voor egdbhealth-uitvoer voor systeemontwerp te identificeren.  De belangrijkste interessegebieden zijn (1) machinegrootte / resourcegebruik en (2) datakenmerken relevant voor data-uitwisseling.  Het volgen van de voorbeelden in dit artikel, en generaliseren daarvan voor de Oracle- en PostgreSQL-databases, stelt u in staat nuttige informatie uit de egdbhealth-tool te halen voor uw ontwerpwerk.<\/P><\/P>Ik hoop dat u dit nuttig vindt, aarzel niet om hier uw vragen te plaatsen: https:\/\/community.esri.com\/thread\/231451-arcgis-architecture-series-tools-of-an-architect<\/SPAN><\/A><\/SPAN><\/P> <\/SPAN><\/P>Opmerking:<\EM> De hierboven gepresenteerde inhoud zijn aanbevelingen die doorgaans de prestaties voor veel scenario's zullen verbeteren. In sommige gevallen kunnen deze aanbevelingen echter geen betere prestatie-resultaten opleveren, in welk geval aanvullende prestatietests en systeemconfiguratie-aanpassingen nodig kunnen zijn.<\EM>