Použití Egdbhealth v návrhu systému

DannyKrouk_ps

<\/HEAD>

Úvod<\/a><\/li>Informační cíle pro návrh systému<\/a><\/li>Zdroje a využití stroje<\/a><\/li>Stroj<\/a><\/li>Využití<\/a><\/li>Procesor<\/a><\/li>Paměť<\/a><\/li>Úložiště<\/a><\/li>Inventář dat a výměna dat<\/a><\/li>Počty záznamů a úložiště podle ObjectClass<\/a><\/li>Verzování, archivace a stav replikace<\/a><\/li>Úvahy o návrhu distribuovaných dat<\/a><\/li>Verzovaná data a replikace Geodatabáze<\\/a><\\/li>Archivace dat a výměna dat<\\/a><\\/li>Velikost příloh a mobilní synchronizace<\\/a><\\/li>Shrnutí<\\/a><\\/li><\\/ul><\\/H2>

Poznámka: Tento blogový příspěvek je třetí v sérii tří plánovaných příspěvků o egdbhealth. První popisoval nástroj, jak jej nainstalovat a jak jej spustit. Druhý v sérii se zabýval tím, jak nástroj použít k hodnocení stavu Enterprise Geodatabáze (eGDB); jeho primárním účelem. Tento článek se zabývá použitím egdbhealth v kontextu návrhu systému.<\ /SPAN><\ /BLOCKQUOTE>

Úvod<\ /H2>Egdbhealth je nástroj pro reportování různých charakteristik Enterprise Geodatabází (eGDBes). Primárním účelem nástroje je vyhodnotit „stav“ eGDBes. Výstup však může být také použit v kontextu návrhu systému. Tento článek se zabývá případem použití návrhu systému.<\ /P><\ /P>Pro informace o instalaci a spuštění nástroje prosím odkažte na první blogový příspěvek v této sérii „Co je Egdbhealth?“<\ /P><\ /P>Informační cíle pro návrh systému<\ /H2>Praxe návrhu systémů Esri se zaměřuje na plánování hardwarových, softwarových a síťových charakteristik pro budoucí stav systémů na základě nových nebo měnících se požadavků.<\ /P><\ /P>Současný stav existujícího systému nemusí nutně silně souviset s budoucím systémem, který má jiné požadavky. Nicméně v závislosti na cílech návrhu mohou být informace o současném systému relevantní.<\ /P><\ /P>Například v případě plánované migrace z on-premises systému na cloudovou platformu by bylo velmi užitečné popsat současný systém tak, aby mohl být věrně zobrazen na cloudové platformě. Nebo požadavky vedoucí k návrhu mohou indikovat potřebu výměny (replikace, přesunu, synchronizace, transformace, kopírování atd.) velkých částí Geodatabáze do jiného úložiště. V takovém případě může být inventář obsahu Geodatabáze užitečný k určení důležitých detailů o povaze a množství dat, která by měla být vyměněna, a optimálních způsobech, jak tato výměna dat proběhne.<\ /P><\ /P>Takže na vysoké úrovni jsou to především popisné informace z egdbhealth, nikoli hodnotící informace, které jsou relevantní pro návrh systému.<\ /P><\ /P>Tento článek diskutuje příklady pro eGDB založenou na SQL Serveru. Principy jsou však stejné i pro eGDBes založené na Oracle a PostgreSQL.<\ /P><\ /P>Zdroje stroje a využití<\ /H2>Pro případy návrhu systému, kde se platforma stroje eGDB změní, může být užitečné pochopit současné zdroje stroje podporující eGDB a jejich míru využití. Například pokud migrujete eGDB na cloudovou platformu, počet procesorových jader, které má systém on-premises, má určitou relevanci k počtu jader, která můžete nasadit v cloudu.<\ /P><\ /P>Stroj<\ /H3>HTML metadata soubor vytvořený egdbhealth poskytne informace o zdrojích platformy stroje, na kterém běží RDBMS.<\ /P><\ /P>V níže uvedeném příkladu běží instance SQL Serveru na stroji s jedním procesorem, který nabízí 8 logických procesorových jader.<\ /P><\ /P>< P > < \ / P > < P > Tyto informace ze SQL Serveru nechávají některé údaje nejasné. Například SQL Server není schopen hlásit, zda jsou logická jádra výsledkem hyperthreadingu. Pokud ano, pak by fyzická jádra byla polovinou logických jader (4 fyzická jádra). A právě počet fyzických jader je nejvíce užitečný pro plánování kapacity při návrhu systému. Takže tyto informace jsou dobré, ale ne dokonalé.< \ / P > < P > HTML také hlásí fyzickou paměť na stroji (16GiB) a minimální a maximální paměť nakonfigurovanou pro instanci SQL Serveru (0 a 3GB). Zde vidíme, že konfigurace instance SQL Serveru je velmi relevantní pro pochopení relevantních paměťových zdrojů pro plánování kapacity. I když má stroj 16GiB paměti, tato instance SQL Serveru (a eGDB kterou podporuje) nemá přístup ke všem těmto prostředkům.< \ / P > < P > < \ / P > < H3 id = "toc-hId-1751530674" > Využití < \ / H3 > < P > Charakteristiky stroje a konfigurace instance nabízejí neúplný pohled na míru využití zdrojů stroje a jaké zdroje jsou skutečně potřeba pro aktuální pracovní zatížení.< \ / P > < P > Můžeme si být jisti, že SQL Server nepoužívá více než 3GB paměti. Ale používá ji důkladně? A co procesorové zdroje; jsou vytížené nebo nečinné?< \ / P > < P > < \ / P > < P > Většina informací o využití se objevuje v Expert Excel souboru, protože jsou relativně proměnlivé.< \ / P > < P > < \ / P > < H4 id = "toc-hId--997139792" > Procesor < \ / H4 > < P > V případě SQL Serveru existuje hodnocení v Expert Excel souboru nazvané „ProcessorUtil“ (využití procesoru; kategorie je „Instance“). Poskytuje vzorek nedávného minutového využití procesoru SQL Serverem na stroji. V tomto případě vidíme, že během vzorkovacího období SQL Server téměř nevyužívá celkové procesorové zdroje stroje, na kterém běží.< \ / P > < P > < \ / P > < P > < IMG __jive_id = "443793" alt = "Využití procesoru" 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 > Z toho usuzujeme, že pokud je toto období typické, stávající stroj má mnohem více procesorových zdrojů než potřebuje. Pokud je vše ostatní stejné, budoucí návrh systému může specifikovat méně procesorových jader k podpoře pracovního zatížení eGDB. Samozřejmě aby toto usuzování mělo nějakou integritu, musíte nástroj spustit během typických a/nebo špičkových pracovních období.< \ / P >< P >< \ / hodnocení, CpuByDb (kategorie Instance), které uvádí, které databáze v instanci spotřebovávají nejvíce procesorových zdrojů.  Takže v případě, že instance měla významné využití procesoru, lze tyto informace použít k určení, zda toto využití procesoru souvisí s eGDB zájmu nebo s nějakou jinou zátěží ve stejné instanci SQL Serveru.<\/P><\/P><\/P><\/P>Paměť<\/H4>V případě SQL Serveru existuje několik hodnocení, která poskytují přehled o využití paměti uvnitř instance.  Většina z nich je v kategorii Instance v souboru Expert Excel.<\/P><\/P>MemoryByDb umožňuje vidět množství paměti (v tomto případě řádky dat na rozdíl od SQL příkazů nebo jiné spotřeby paměti) používané každou databází.<\/P><\/P><\/P><\/P>V tomto případě vidíme, že eGDB „GIS“ je hlavním spotřebitelem paměti v instanci SQL Serveru.  Zdá se tedy rozumné pochopit, že eGDB může využít většinu ze 3GB paměti instance.  Ale je to příliš mnoho nebo málo pro dobrý výkon a zdraví systému?<\/P><\/P>Hodnocení MemoryMetrics informuje o několika metrikách paměti, které mohou naznačit, jak velmi je paměť instance žádaná.  V tomto případě vidíme varování, která naznačují, že stávající dostupná paměť instance může být pro zátěž příliš nízká.  Takže nevíme, zda je 16GiB paměti stroje příliš mnoho nebo málo.  Ale máme důvod věřit, že 3GB paměti instance je příliš málo.<\/P><\/P><\/P><\/P>V souboru Expert Excel je několik dalších hodnocení paměti.  Vyžaduje to zkušenosti a úsudek integrovat tyto poznatky do informovaného úsudku o skutečných potřebách paměti systému.   V tomto případě, jako v mnoha jiných, jsou závěry neúplné.  Ale jsou lepší než nic.<\/P><\/P>Úložiště<\/H4>SQL Server neposkytuje úplné informace o místním úložišti na stroji, na kterém běží.  Nicméně poskytuje informace o velikosti souborů, ve kterých je eGDB uložena.  Většina těchto informací je dostupná v kategorii „Database“ v souboru Expert Excel.<\/P><\/P>List FileSpace hodnotící soubory, ve kterých je eGDB uložena.  V tomto příkladu vidíme, že existuje jeden datový soubor („ROWS“) o velikosti asi 6GB a jeden transakční logový soubor („LOG“), který v minulosti využil asi 650MB.  Také můžete vidět maximální limity souborů stanovené DBA, pravděpodobně jako indikaci maximální očekávané kapacity úložiště pro eGDB.<\/P><\/P><\/P><\/P>Tato data jsou dobrým ukazatelem množství úložiště potřebného pro scénář „lift and shift“, kdy bude celá eGDB přesunuta na jinou platformu.<\/P><\/P>Inventář dat a výměna dat<\/H2>Dalším případem návrhu systému je potřeba výměny dat eGDB s jiným úložištěm, možná jinou Geodatabase v jiném datovém centru.  V těchto případech může být relevantní stanovit velikost úložiště a další charakteristiky dat, která budou vyměňována, na rozdíl od velikosti úložiště celé eGDB.<\/P><\/P>Počty záznamů a úložiště podle ObjectClass<\/H3>Pokud znáte identitu ObjectClasses k výměně, existují informace v souboru Content Excel k hlášení velikosti úložiště a počtu záznamů těchto položek. <\/P><\/P>V kategorii Storage je list nazvaný „ObjClass“ (ObjectClasses).  Podává podrobné zprávy o tabulkách, ze kterých se různé eGDB ObjectClasses skládají, počet řádků, které obsahují, a množství úložiště přiděleného každému z nich. <\/P><\/P>V níže uvedeném příkladu jsou tři ObjectClasses zájmu (filtrovány v prvním sloupci): BUILDINGS_NV, COUNTRIES a SSFITTING.  BUILDINGS_NV má asi 4 400 záznamů a spotřebovává něco přes 1,25MB prostoru.  COUNTRIES je verzována s 249 záznamy v základní tabulce, 66 přidáními a 5 smazáními (sloupec TableName uvádí názvy tabulek „A“ a „D“ pro verzované ObjectClasses).<\/P><\/P><\/P><\/P>Tímto způsobem můžeme stanovit počty záznamů a přibližné charakteristiky úložiště ObjectClasses zájmu v eGDB.  Současně také vidíme, které ObjectClasses jsou registrovány jako verzované.  To je kritická informace pro stanovení rozsahu možností dostupných pro výměnu dat.<\/P><\/P>Verzování, archivace a stav replikace<\/H3>Ve stejném souboru Context Excel poskytuje ObjClassOverview (kategorie Inventory) přehled o stavech verzování, archivace a replikace všech ObjectClasses v eGDB.  To poskytuje pohodlnější mechanismus pro plánování rozsahu mechanismů výměny dat vhodných pro různé ObjectClasses.<\/P><\/P><\/P><\/P>Úvahy o návrhu distribuovaných dat<\/H4>Dokumentace ArcGIS označuje tuto tematickou oblast jako „distributed data“ a nabízí obecné pokyny ohledně různých strategií používaných k přesunu dat: http:\/desktop.arcgis.com/en/arcmap/latest/manage-data/geodatabases/understanding-distributed-data.htm<\/<A> <\/<SPAN>.<\/< P > <\/< P > < H5 id = "toc-hId--1499952541"> Verzovaná data a replikace Geodatabase <\/< H5 > < P > Pokud objektová třída není již registrována jako verzovaná , může být vhodné či nevhodné tak učinit za účelem využití Geodatabase Replication . & nbsp ; Toto se týká způsobu aktualizace dat . & nbsp ; Většina dat registrovaných jako verzovaných se aktualizuje „transakčně“, což znamená , že pouze malý procentní podíl celkových záznamů se mění v daném okamžiku . & nbsp ; Tento druh aktualizace je kompatibilní jak s verzováním , tak s Geodatabase Replication . & nbsp ; Jiná data se aktualizují metodami jako „truncate and add“, „delete and replace“ nebo „copy and paste“. & nbsp ; V těchto případech se většina záznamů aktualizuje fyzicky (i když většina hodnot záznamů může být stejná , fyzické záznamy byly nahrazeny). & nbsp ; Tento druh aktualizace není zvlášť vhodný pro Geodatabase Replication . & nbsp ; Informace v egdbhealth vám mohou říct o stavu verzování a replikace ObjectClasses . & nbsp ; Ale neví , jak jsou tyto ObjectClasses skutečně aktualizovány . & nbsp ; Doufejme , že ty , které jsou registrovány jako verzované , jsou transakčně aktualizovány a proto vhodnými kandidáty pro Geodatabase Replication . <\/< P > <\/< P > < H5 id = "toc-hId-242857794"> Archivace dat a výměna dat <\/< P > Pokud má objektová třída povolenou archivaci , mohou existovat další úvahy . & nbsp ; Například pokud plánovaná výměna dat může zvýšit rychlost aktualizací , může to způsobit nežádoucí růst množství archivních informací . & nbsp ; <\/< P > <\/< P > < P > Pro verzované objektové třídy s povolenou archivací jsou archivní informace uloženy v samostatné tabulce „history“. & nbsp ; Velikost této tabulky neovlivňuje výkon dotazování na verzovaná data . & nbsp ; V tomto případě hlavní návrhovou otázkou je , zda je praktické uchovávat a používat všechny archivní informace . & nbsp ; V mnoha případech to bude možné . & nbsp ; Ale rozhodnutí vyžaduje znalost stavu archivace objektové třídy a plánované rychlosti aktualizací . <\/< P > <\/< P > < P > V případě neverzovaných objektových tříd s povolenou archivací (a branch-verzovaných objektových tříd) jsou archivní informace v hlavní tabulce . & nbsp ; Rychlý růst archivních informací tak může změnit potřeby ladění výkonu objektových tříd a/nebo eGDB . & nbsp ; Egdbhealth nemůže znát budoucí potřeby aktualizací dat . & nbsp ; Může však hlásit historické vzory aktualizací neverzovaných , archivací povolených objektových tříd . & nbsp ; Soubor Context Excel obsahuje list „NvArchEditDatesSql“, který obsahuje SQL příkazy pro každou neverzovanou , archivací povolenou objektovou třídu v eGDB . & nbsp ; Tyto příkazy nejsou spouštěny automaticky , protože jsou náročné na zdroje a neposkytují informace relevantní za všech okolností . <\/< P > <\/< P > < P >< IMG __jive_id = "443800" alt = "Další SQL příkazy , které můžete spustit " class = "image-9 jive-image j-img-original " src = "https:\/ \/ us.v-cdn.net \/ 6038851 \/ uploads \/ legacyfs \/ online \/ 443800_Additional_SQL_statements_you_can_run.png " \/ > \/><\/P>

<\/P>

V tomto případě návrhu systému však může být stanovení rychlosti, jakou se záznamy hromadily v průběhu času, velmi důležité pro plánování strategie výměny dat.  Použijte SQL klienta, jako je SQL Server Management Studio, k provedení dotazů na příslušné ObjectClasses, abyste získali představu o rychlosti aktualizace dat.  V tomto příkladu vidíme vzorec aktualizací záznamů, kde je typická aktualizace malá (1 záznam), ale byla alespoň jedna příležitost, kdy došlo k velké aktualizaci vzhledem k velikosti ObjectClass (289 záznamů 8. dubna 2018):<\/P>

<\/P>

<\/P>

<\/P>

Velikost příloh a mobilní synchronizace<\/H5>Další případ návrhu, který souvisí s distribuovanými daty, je sběr dat v terénu a přílohy.  Collector for ArcGIS využívá efektivní mechanismy podobné Geodatabase Replication pro synchronizaci „delt“ mezi klientem a serverem.  Schopnost sbírat velké množství dat v přílohách (například obrázky) a často omezené síťové podmínky, za kterých lze data synchronizovat, mohou vyvolat problémy v návrhu systému.<\/P><\/P>Soubor Expert Excel obsahuje hodnocení „LargeAttachments“, které automaticky upozorní na případy pravděpodobného zájmu.  V níže uvedeném příkladu nebyly překročeny prahové hodnoty, takže nebylo negativní hodnocení:<\/P><\/P><\/P><\/P>Nicméně může být stále užitečné vědět něco o povaze existujících příloh.  Soubor Context Excel obsahuje list „AttachmentSizeSql“ („Inventory“ kategorie), který obsahuje několik SQL příkazů pro každý ObjectClass, který má přílohy. <\/P><\/P><\/P><\/P>Spuštění těchto SQL příkazů v klientovi jako SQL Server Management Studio vám umožní statisticky charakterizovat přílohy různými způsoby: agregované statistiky, top 100 podle velikosti a percentilové rozdělení. <\/P><\/P><\/P><\/P>S těmito statistikami můžete pochopit nejen celkové množství informací, ale také zda je to způsobeno velkým počtem malých příloh nebo malým počtem velkých příloh.  Velké přílohy mohou představovat větší riziko při synchronizaci přes špatné síťové podmínky a mohou vás vést k doporučení, aby sběr dat probíhal v režimu offline a synchronizace se prováděla pouze za specifických síťových podmínek.<\/P><\/P>Zvážení velikosti příloh vás také může přimět k nabídce doporučení ohledně toho, zda a jak by bylo praktické řešit obousměrnou synchronizaci (na rozdíl od jednosměrné).  Zatímco uživatelé v terénu mohou mít dostatečné síťové podmínky pro nahrávání jednotlivě sbíraných příloh, obousměrná synchronizace by znamenala, že všechny přílohy shromážděné ostatními jednotlivci (v oblasti synchronizace) by musely být staženy.  V některých případech by to mohlo být mnohonásobně více informací než množství potřebné k nahrání.<\/P><\/P>Shrnutí<\/H2>Jako návrhář GIS systémů není praktické mít hluboké znalosti ve všech technologických oblastech týkajících se systému.  Z tohoto důvodu má vaše porozumění výstupům egdbhealth a tomu, co s nimi můžete dělat, své limity.  Cílem tohoto článku je identifikovat některé z nejběžnějších případů použití výstupů egdbhealth pro návrh systému.  Hlavní oblasti zájmu jsou (1) dimenzování strojů / využití zdrojů a (2) charakteristiky dat relevantní pro výměnu dat.  Následování příkladů v tomto článku a jejich zobecnění pro databáze Oracle a PostgreSQL vám umožní získat užitečné informace z nástroje egdbhealth pro vaši návrhářskou práci.<\/P><\/P>Doufám, že vám to pomůže, neváhejte zde položit své otázky: https:\/\/community.esri.com\/thread\/231451-arcgis-architecture-series-tools-of-an-architect<\/SPAN><\/A><\/SPAN><\/P> <\/SPAN><\/P>Poznámka:<\EM> Výše uvedený obsah jsou doporučení, která obvykle zlepší výkon v mnoha scénářích. Nicméně v některých případech nemusí tato doporučení přinést lepší výsledky výkonu, v takovém případě může být potřeba další testování výkonu a úpravy konfigurace systému.<\EM>