Dotaz: Smazání velkého monžství dat z Oracle DB

[majales]

Zdravím,
Provozujeme velkou Oracle DB a nahromadily se nám tam od uživatelů desítky GB, možná i stovky GB irelevantních dat. Rád bych zredukoval DB tak aby se zmenšila pravidelná měsíční záloha, která už přesahuje rozumnou velikost. Někde jsem se dočetl, že se masivní delete operace v Oracle DB provádějí s NOLOGGING. Poradili byste jak postupovat v případě výmazu ne celých řádků, ale pouze blobů, kde jsou data uložena? Jedná se o Oracle 10g v archivelog módu. Díky za každý tip.

Odpovědi

[majales]

Kolega bez mého vědomí sám část dat v blobech přepsal daty s nulovou velikostí, což se samosebou na velikosti fullbackupu neprojeví. Předpokládám, že tyto operace by se měly nejprve rollbacknout a pak smazat s NOLOGGING option. Je to tak?

[Max]

Mně by zajímalo, k čemu máte archivní logy? To děláte vždy dump databáze a pak zálohujete redo logy, abyste se mohli vrátit do jakéhokoli času, a tak stále dokola?
Jinak já teď řeším něco podobného. Mám asi 4TiB db, celé je to closed řešení od jedné firmy a nyní mi řekli, že jedna z tabulek má 2TiB, že jsou tam jen logy aplikáče, že to můžeme klidně mazat, proč to prý neděláme. Mno, to byla od nich další třešnička, protože podobných skrytých blbostí, o kterých nám neřekli, bylo celkem dost a některé si vyžádaly i neplánované odstávky.
Osobně dělám dump jednou týdně a zálohu redo logů. Ale nakonec budu přecházet na standby řešení tak, jako to máme i u jiných db, jelikož server se z "nice to have" přesunul do čáry "když to chvilku nepoběží, tak bude průser".
Zdar Max

[majales]

Vychází to z původní instalace, která byla rozlezlá na celkem 8 fyzických mašin, z toho byly 4 fyzické stroje určeny pro oracle. Byly to dva Oracle RAC clustery s tím že ten druhý byl Standby toho prvního. Na zálohu tam byla pásková knihovna. Celé se to zredukovalo na dvě virtuání mašiny, jedna pro Oracle DB a druhá pro Oracle HTTP s tím, že výhledově bych rád zprovoznil alespoň Standby DB na virtuálu na jiné fyzickém mašině. Původní zálohovací skripty jsem neměnil, takže zůstal každodenní skript na backup archivelogů a týdenní na increment a měsíční na FULL backup. Dostal jsem se k tomu asi rok a něco před přechodem z původní instalace na ten virtuál s minimálními znalostmi co se týče oracle, takže teď řeším ex post jak se s tím popasovat..

[jekub]

dump jednou týdně a zálohu redo logů

Není to zbytečné?

[Tomáš]

Zrovna jsem toto asi před 1 měsícem řešil. Je potřeba si uvědomit, že jedno veliké mazání DELETE FROM ... , které by bylo jako jedna veliká transakce, může zhavarovat na nedostatku místa v undo segmentu (dokud neuděláte commit, tak stále musíte mít někde zálohu pro případ rollback).

Dále je potřeba si uvědomit, že smazané místo zůstává zabrané v segmentu do okamžiku, dokud neuděláte alter table shrink space cascade nebo alter table modify lob ... pro LOB. Netuším jak to vypadá při zálohování, zda se zálohují i prázdné ale zabrané bloky. V případě LOBu pak záleží i na tom, kam se LOBy sypou zda přímo do řádku, nebo LOB segmentu (viz fráze enable storage in row při vytváření tabulky)

Já jsem skončil u mazání po časových úsecích v nočním okně. Už to běží 14 dní a ještě dalších 14 dní poběží. Každou noc se zvládnou odmazat tak 2-3 časové úseky.

Pak bude následovat zmíněné alter table modify lob (mylob) store as secure file compress high které jednak sesype ementál tabulky a LOB segmentu do kompaktní formy, a jednak dojde ke kompresi dat LOBu. Přesný příkaz bude pro sesypání tabulky/LOBu do kompaktnější formy závisí na tom zda se Váš LOB umísťuje převážně do řádku nebo do separátního LOB segementu. Kam LOBY převážně tečou zjistíte pokud se podíváte na velikost LOB segmentu. Z této části mám největší obavu, protože tabulka bude po celou dobu sesypání exklusivně zamknutá a já jen doufám, že se vejdu s časem běhu do víkendového okna.

[Ivan2]

Obavam se, ze na to co delas "alter table modify lob (mylob) store as secure file compress high" je potreba extra linece na "Advanced compression". :(

[Ivan2]

na NOLOGGING moc nespolehej, ten se uplatni pouze za urcitych pripadech a tech podminek je docela dost.

Pokud si muzes dovolit downtime tak pouzij CTAS, "create table as select" s naslednym rename, a drop table.

shrink lob na 10g verzi bych moc nedoporucoval.

[majales]

Zdravím.. A kdybych si mohl dovolit downtime, tak jak by to šlo udělat?

[krocan]

...tak pouzij CTAS, "create table as select" s naslednym rename, a drop table.

[alkoholik]

Jasne, ser se s tim rucne, kdyz ti Oracle pripravil nastroj.

[alkoholik]

Sorry, 10g

[jekub]

takhle narychlo, pokud blob tvoří vetšinu dat tabulky

create table as select (bez blobu) nolog
alter table add blob
alter table nolog
recyclebin=off
drop table
rename table
alter table log

nebo podobné variace na toto téma.

[majales]

No musím to promyslet... to mazání má být opravdu selektivní, tzn. identifikují se bloby s "bordelem" a přepíší se nulovou velikostí...

[jekub]

Tak jeste jede tip

add column
update
drop column
rename column

[FrantaS]

Je to již mnoho let a verzí Oracle zpět, ale podobnou věc jsem vyřešil tak, že jsem mazal v kurzoru. Tam jsem zadával podmínky. Pokud jde nějak identifikovat postupně řádky třeba za určité dny apod, pak je lze s dalšími podmínkami updatovat v cyklu a nakonec cyklu dát commit. Takto lze podle velikosti rollbacku v jednom cyklu updatovat třeba 100.000 záznamů. Výmaz 2 mil. záznamů mi neprošel, protože se to nevešlo do rollbacku, ale takto to šlo velmi rychle.

[rich]

Jednou z moznosti by mohlo byt dotycnou tabulku rozdelit na partitions (viz. table online redefinition. jinak teda partitioning vyzaduje licenci), kde klicem pro partitioning by byl nejaky casovy sloupec (interval partitioning). Smazani starych udaju je pak jen drop/exchange partition...