Jak zamezit nárůstu geoprocessingové historie v metadatech geodatabáze

[MartinKrál]

ArcGIS při každém spuštění geoprocessingového nástroje zapisuje informace o jeho běhu do části metadat „geoprocessingová historie“ třídy, nad kterou byl daný nástroj spuštěn (případně celého workspace). Například když z ArcGIS Pro spustíme nástroj Append nad určitou třídou, zapíše se informace do geoprocessingové historie této třídy/tabulky. Podobně když spustíme nástroj na tvorbu geodatabázové verze (což se týká celé geodatabáze), zapíše se informace o běhu do geoprocessingové historie workspace této geodatabáze.

Geoprocessingová historie se ukládá interně do systémové geodatabázové tabulky GDB_ITEMS a jejího pole Definition, kde jsou v XML uložená metadata daného geodatabázového objektu. Jestliže se geoprocessingové nástroje pouští často (například v pravidelně spouštěném python skriptu) může geoprocessingová historie třídy časem docela výrazně narůstat, a tím negativně ovlivňovat odezvu práce s geodatabází. Této situaci lze předejít nastavením na straně klientů ArcGIS a případně příliš objemnou historii geoprocessingu odmazat.

Jak vypnout ukládání historie do metadat geodatabáze?

V ArcGIS Pro (velmi podobně i v ArcMap) lze vypnout ukládání geoprocessingové historie odškrtnutím zápisu do metadat datové sady v nastavení geoprocessingu.

V případě, že jsou nad daty geodatabáze často spouštěny python skripty a hrozí kvůli tomu růst objemu historie, je potřeba vypnutí provést na úrovni samotného skriptu pomocí procedury arcpy.SetLogHistory(False)

Viz https://pro.arcgis.com/en/pro-app/latest/arcpy/functions/setloghistory.htm

Promazání geoprocessingové historie z metadat geodatabáze

Ověřit si velikost geoprocessingové historie můžete tak, že se podíváte přímo do tabulky GDB_ITEMS (pohledu GDB_ITEMS_VW u Oracle), do pole Documentation. Nejprve je vhodné zjistit, u kterých objektů geodatabáze a jak moc geoprocessingová historie narostla. SQL pro analýzu velikosti metadat pro jednotlivé databázové platformy (Oracle, SQL Server, PostgreSQL) je možné najít například na:

https://support.vertigis.com/hc/en-us/articles/4415911657746-Performance-Geoprocessing-Metadata-in-E...

kde tyto příkazy naleznou 20 největších geodatabázových objektů a zobrazí velikost jejich metadat.

Jako určitý základ arcpy skriptu, promazávajícího geoprocessingovou historii tříd prvků a workspace v metadatech, je možné použít python skript z článku Knowledge Base Esri.

Pozor! Skript maže i thumbnaily vrstev, které mohou taktéž zabírat hodně místa.

https://support.esri.com/en-us/knowledge-base/how-to-delete-geoprocessing-history-from-a-geodatabase...

Tento skript je se znalostí arcpy a pythonu možné dle libosti dále upravovat, aby například:

• nemazal thumbnaily (zakomentováním řádku tgt_item_md.deleteContent('THUMBNAIL') )
• ukládal metadata do XML souboru před jejich promazáním pomocí funkce saveAsXML,

https://pro.arcgis.com/en/pro-app/latest/arcpy/metadata/metadata-class.htm

• procházel a promazával i metadata tabulek a datasetů (nejen tříd prvků) procházením listu tabulek Arcpy.ListTables

https://pro.arcgis.com/en/pro-app/latest/arcpy/functions/listtables.htm

[JaroslavŠkrobák]

Dobrý den, díky za zajímavý článek a vhled do této tabulky v SDE.

V našem případě má tato tabulka 54 GB! Chtěl jsem napsat, je to moc nebo málo??? Ale když vidím, jak velké jsou ostatní tabulky, tak mi přijde, že je to až moc....

[TomasPokorny]

@JaroslavŠkrobák  fakt v GB? Výše popsané je problém, který jsme s @MartinKrál řešili v rámci technické podpory a v rámci pravidelného promazávání geoprocessingové historie nejen ve feature classes a datasets, ale i v tabulkách a workspace se odezva SDE hodně zlepšila.

[JaroslavŠkrobák]

Fakt GB! To je ono, roky každodenních aktualizací různých vrstev, ono se to nakupilo, takže promazávat.  @TomasPokorny , to je holt co, po čem jsi asi volal, téma "údržbové skripty nad ArcSDE (compress,reindexace & spol.), jaké, jak často, automatizace. Historie geoprocessingu v Enterprise DB s ArcSDE", je to tak?

[JaroslavŠkrobák]

Je tu někdo jiný, kdo víz zanedbává svoji SDE, než my? 😀 Stále je ve správě co objevovat a co hlídat, o co se starat.....

[TomasPokorny]

@JaroslavŠkrobák ano, to je přesně jedna část tématu údržba nad SDE. Řešíme skriptama pravidelné promazávání geoprocessingové historie za pomocí skriptů od @MartinKrál a potom ještě compress / rebuild indexes a analyze datasets.

[KamilNovák]

Nic spešl pro očistu neděláme, resp. u SDE Pasporty pravidelný denní Compress/Rebuild, u dalších SDE Compress/Rebuild "sem tam", geoprocesingovou historii neřešíme a lezou nám takováhle čísla:

Takže jsme asi v pohodě 🙂

[AdministrátorJihlava]

python skript proběhl, promazal feature classes a tabulky v SDE. Po zjištění velikostí položek v gdb_item to už hlásí daleko nižší čísla než před tím:

Ale když si vyjedu velikost tabulek v SDE, tak gdb_items se velikost nezměnila:

Ani místo na disku databázového stroje se nezměnilo, že by se uvolnily desítky GB místa.... Poradíte, co s tím? Není třeba pustit ještě nějaký geoprocessing, restartovat databázový stroj, službu Postgre, nad kterou nám to běží?

[TomasPokorny]

@JaroslavŠkrobák a nevypisuješ si v té druhé tabulce velikost dat a ne jenom velikost geoprocessingové historie?

[MartinKrál]

Dobrý den,

omluvám se za pozdější reakci (byl jsem minulý týden na dovolené)

@JaroslavŠkrobákzmenšení velikosti XML v jednom sloupci (a jen některých řádcích tabulky gdb_items) se na velikosti místa, která tabulka fyzicky zabírá, projevit vůbec nemusí.

54 GB  mi příjde už docela dost,  ale tam jde i o to, kolik objektů geodatabáze má, kolik dalších informací je u objektů v metadatech (například i ty uvedené Thumbnaily), a jak složitá struktura objektů v geodatabázi je (XML pole Definition)

Navíc přesně jak píše i @TomasPokorny , jde skutečně o to, jak velikost tabulky gdb_items (v Postgfresql?) zjištujěte. Resp. co těh 54 GB ve výsledku vašeho dotazu přesně znamená.

Zmenšení velikostí XML metadat s GP historií v poli Documentation se může v případě nabobtnalé GP historie projevit především tím, že při načítání informací o třídě (a jejích metadatech z Documentation pole) se na klienta přenáší menší XML, které se pak klientu i výrezně lépe parsuje. Tam jsou nejlepším ukazatelem ty selecty přímo na textovou velikost pole Documentation (třeba i sesumarizované přes celou gdb_items)

[AdministrátorJihlava]

Pro výpis těch položek v gdb_item používám tento dotaz:

select length(xmlserialize(Content gdb_items.documentation as varchar)) as length, name
from gdb_items
where documentation is not null
order by length desc
limit 20;

Pro výpis největších tabulek u nás v Postgre SDE zase toto:

SELECT
relname AS "relation",
pg_size_pretty (
pg_total_relation_size (C .oid)
) AS "total_size"
FROM
pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C .relnamespace)
WHERE
nspname NOT IN (
'pg_catalog',
'information_schema'
)
AND C .relkind <> 'i'
AND nspname !~ '^pg_toast'
ORDER BY
pg_total_relation_size (C .oid) DESC
LIMIT 20;

Takže z toho mi vyplývá, že dgb_items zabírá 54 GB. A tak si říkám, jestli tento case tomu má pomoct, aby to tolik nezabíralo nebo je to na jiné řešení.

V této databázi je cca 800 vrstev, tabulek a pohledů.

Thumbnaily nepoužíváme, ale nechal jsem je smazat s tímto údržbovým skriptem. Velikost pole documentation jsem asi zmenšil podle jednoho z těch obrázků. Byla tam úplně jiná čísla a vrstvy, které ty hodnoty měly daleko vyšší. Ale je teda otázka, jestli s tabulkou gdb_items je vůbec možné něco udělat, co se týče zmenšení. Je to 1/4 velikosti celé db.

[MartinKrál]

Mohl byste zkusit (jestli máte na test na stroji s DB dost místa), vytvořit create table as select kopii gdb_items

CREATE TABLE sde.gdb_items_test as select * from sde.gdb_items;

,a podívat se kolik tato kopie gdb_items_test  při použití  pg_table_size() zabírá oproti originálu?

Jestli tato kopie zabírá výrazně méně než originál, vyzkoušel bych v momentě, kdy by k db nikdo napřistupoval, (pozor na AGS služby)
VACUUM FULL  viz  https://www.postgresql.org/docs/current/sql-vacuum.html
resp.
VACUUM FULL VERBOSE sde.gdb_items;
A následně zkontrolovat velikost.

PS:+po testu nezapomenout kopii gdb_items_test smazat.

[JaroslavŠkrobák]

Kopie gdb_items zabírá 5 MB:

Originální tabulka opravdu 54 GB

Takže spustit tento příkaz - VACUUM FULL VERBOSE sde.gdb_items;

Pardon, co to znamená, když do db nebude nikdo přistupovat. Jasně, zastavím oba AGS, tím tam nebudou připojení z AGS, ale prosím, jak vysekat ty další?

[MartinKrál]

@JaroslavŠkrobáktřeba v arcpy pod sde uživatelem nastavit AcceptConnections na False a následně zavolat DisconnectUser "ALL"

https://pro.arcgis.com/en/pro-app/latest/arcpy/functions/acceptconnections.htm

https://pro.arcgis.com/en/pro-app/latest/arcpy/functions/disconnectuser.htm

Po provedení vakuování tabulky opět nezapomenout AcceptConnections nastavit na True

[JaroslavŠkrobák]

vše zabralo a výsledná velikost tabulky gdb_items.... 5496 kB ..... ja na čase zaplnit uvolněné místo něčím pěkným GISovým 😉

Děkuju moc za cané rady a další zkušenost

@MartinKrál, je něco dalšího, čemu byste se v SDE podíval na zoubek, aby se tam něco nekupilo, co by se pravidelně mělo provádět, co SDE potřebuje za údržbu?

[MartinKrál]

@JaroslavŠkrobákkrom takového toho klasického  základu

1.  pravidelný rebuild indexů (včetně systémových tabulek)
   https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/rebuild-indexes.htm
2.  pravidelný přepočet statistik (včetně systémových tabulek)
   https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/analyze-datasets.htm
3. v případě výskytu verzovaných dat v geodatabázi pravidelná komprese (jednou za čas optimálně plná komprese)
   https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/compress.htm
   https://desktop.arcgis.com/en/arcmap/latest/manage-data/gdbs-in-postgresql/geodatabase-compress-oper...

Ve Vašem případě, s db na postgresql,  bych se ještě podíval jak je to s pravidelným automatickým vakuováním tabulek. Defaultně by mělo být vakuování na úrovni celé db zapnuté, ale přijde mi trochu zvláštní, že by s pravidelným vakuováním mohla gdb_items až takhle moc narůst.  Asi by stálo za to podívat se zda jiné větší a často editované tabulky nejde VACUUM příkazem zmenšit, jak jsou dále nastavené parametry pro autovacuum
https://www.postgresql.org/docs/current/runtime-config-autovacuum.html
, a jestli případně v logách postgresql něco nananznačuje, že by s vakuováním byl v db problém.