Jak promazávat velké množství záznamů v agendě Provedené změny
Tento návod poradí jak postupovat v případě, kdy je v databázi velké množství záznamů provedených změn a chceme je odstranit z důvodu zmenšení velikosti záloh databáze. Tím dosáhneme i urychlení zálohování.
Větší počet záznamů vzniká v tabulce provedených změn obvykle kvůli nějaké automatické akci, která pravidelně aktualizuje hodnoty na objektech, nad kterými je zapnuté sledování změn.
Velký počet záznamů (miliony) v agendě Provedené změny může mít za následek zvětšení velikosti databáze o GB a tím prodlužování doby zálohování. Při velkém množství je proto vhodné zvážit promazání historických záznamů o provedených změnách.
Odstranění většího počtu záznamů přímo z agendy Provedené změny je pro více jak 1000 záznamů nevhodné provádět uživatelsky, a to z důvodu časové náročnosti dané akce.
Proto byla do systému doplněna možnost provedení odstranění záznamů za zvolené omezení (stáří záznamů, třída a uživatel, který zápis vytvořil) pomocí naplánované úlohy automatizační serveru.
Před konfigurací naplánované úlohy typu “Promazání záznamů z agendy Provedené změny“ je ale nejprve vhodné ověřit, zda je odstranění záznamů provedených změn vůbec vhodné řešit, případně jakých záznamů je mnoho.
1. Zjištění počtu záznamů z agendy Provedené změny
Pro zjištění celkového počtu záznamů v agendě Provedené změny a zjištění, pro jaké třídy je nejvíce záznamů, vznikla nová funkce Analýza počtu záznamů v agendě provedené změny, která se spouští z agendy Firemní údaje na záložce Technické nástroje.
Po spuštění funkce ABRA Gen zjistí přibližný počet záznamů a odhadne, jak dlouho bude akce trvat.
Zjištění celkového počtu záznamů je pro počet záznamů větší jak 1 mil. náročná akce a doporučujeme ji spustit mimo produkční dobu, aby nedošlo k ovlivnění výkonu.
Výsledek zjištění je otevřen ve webovém prohlížeči a obsahuje následující informace:
- celkový počet záznamů
- celkový počet záznamů dle roku vzniku záznamu
- celkový počet záznamů dle třídy zdrojového objektu
- celkový počet záznamů dle jednotlivých roků a tříd TOP 10
Všechny údaje jsou zobrazeny jak formou vizualizace, tak i tabulkou se zjištěnými počty viz obrázek.
Rozhodnutí o odstranění provedených změn musí provádět znalá obsluha. Např. sledování změn v účetním deníku je třeba ponechat minimálně po dobu určenou zákonem.
Velikost zabraného místa uloženými záznamy lze určit přibližně vynásobením počtu záznamů * 0,5 kB.
2. Přesné zjištění velikosti dat z agendy Provedené změny (tabulka DataChangesLogs)
Zjištění na databázovém serveru:
Pro MSSQL se provede zjištění následovně:
Pomocí aplikace Management Studio - kontextová volba na dané databázi Reports - Standard reports - Disk Usage by Top Tables.
Ve výsledném reportu vidíme přímo celkový počet záznamů a využité místo v databázovém souboru.
Z celkového počtu záznamů a velikosti obsazeného místa lze odvodit, kolik by bylo možné ušetřit místa odmazáním určitého počtu záznamů.
Nyní, pokud se rozhodneme záznamy odstranit, pokračujeme nastavením naplánované úlohy na jejich promazání.
3. Naplánovaná úloha typu Promazání záznamů z agendy Provedené změny
Při nastavování třídy Business objektů a stáří záznamů určených pro smazání v parametrech úlohy je potřeba brát ohled na povinnost podle platné legislativy uchovávat opravy některých typů záznamů (např. účetní záznamy, daňové doklady, záznamy pro účely uchovávání mzdových listů apod.).
Spuštění promazávání doporučujeme nastavit na neprodukční dobu, obvykle tedy v nočních hodinách. Protože záznamů může být tolik, že by se je nepodařilo odstranit během jedné noci (během několika hodin), má úloha možnost stanovit její maximální dobu trvání.
Úlohu tedy nastavíme např. na spouštění jednou denně od 2:00 s maximální dobou odmazávání na 180 min.
Promazávání by mělo být nastaveno tak, aby nekolidovalo s jinou náročnou akcí, např. se zálohováním nebo uzávěrkami.
Nastavíme, jak staré záznamy mají být mazány, pro jaké třídy a případně od kterých uživatelů.
Tímto máme úlohu nastavenou a systém nám bude pravidelně spouštět promazávání starých záznamů. Promazání velké historie může dle počtu záznamů trvat i desítky dní, tato akce je náročná na všechny zdroje serveru.
Na databázi MSSQL a Oracle v případě provozu v režimu s používáním transakčních logů je nutné počítat s odpovídajícím nárůstem těchto logů a mít dostatek volného místa a zajištění následného odzálohování těchto logů.
Odstranění záznamů na žádné z databázových platforem nevede k okamžitému odpovídajícímu snížení velikosti databáze. Důvodem je vznik fragmentace datových stránek odmazáváním jen některých záznamů. Představit si celý problém fragmentace při odebírání záznamů z tabulek si lze zjednodušeně vysvětlit na příkladu odebírání karet pacientů z fyzické kartotéky, kdy i přes částečné vyprázdnění karet pacientů z šuplíku s pacienty začínající na písmeno A nelze tento šuplík celý zrušit, dokud v něm zbývají ještě nějaké záznamy.
Na databázi MSSQL dojde díky vzniklé větší fragmentaci indexů dokonce k zvětšení velikosti databáze. Je třeba s tímto nečekaným efektem počítat a připravit odpovídající volné místo.
Na vznik větší fragmentace je třeba upozornit správce databáze a domluvit, aby nedocházelo k souběhu akce údržby databáze (údržby index viz doporučení pro MSSQL MSSQL/Microsoft SQL Server)).
4. Dosažení zmenšení zálohy databáze po odstranění záznamů
Finálního dosažení zmenšení velikosti zálohy databáze dosáhneme provedením údržby databáze.
Například snížením počtu stránek po obnově o 253080, což odpovídá zmenšení databáze o 3,8 GB (253080 * 16kB / 1024 / 1024 = GB), před obnovou Data pages: 1378536, average fill: 68%, po obnově Data pages: 1125456, average fill: 84%.
Na databázi MSSQL dosáhneme obdobného spuštěním akce údržby indexů viz. Údržba databáze a Doporučení pro MSSQL MSSQL/Microsoft SQL Server.
Upozornění pro MSSQL:
Pokud nebylo doposud řešeno spouštění údržby indexů, je třeba počítat s dalším nárůstem velikosti databáze, a to o velikost jedné největší tabulky (údržba typu REBUILD potřebuje volné místo, aby znovu sestavila celou tabulku). Vzniklé zvětšení databáze nedoporučujeme redukovat pomocí funkce Shrink, protože může vést k snížení výkonu díky opětovné fragmentaci, a také je dobré mít rezervované místo na případné opakované provedení akce REBUILD největší tabulky databáze.
Je třeba počítat, že akce typu REBUILD nelze spustit v režimu ONLINE na STANDARD edici SQL serveru. Spuštění této akce je opět nutné naplánovat na čas mimo produkční dobu, protože může blokovat fungování systému až na několik hodin.
V případě, že se chystáte odstranit velké množství záznamů, je lepší akci promazávání nastavit na menší dobu běhu, a poté provádět průběžně údržbu pomocí reorganizace indexů. Tím lze dosáhnout nepřetržitého provozu během údržby.