ORACLE archivne logy (2)

Kluvanek Martin kluvanek na tesnet.cz
Pátek Říjen 17 10:16:26 CEST 2003


Honza Pazdziora wrote:
> On Fri, Oct 17, 2003 at 09:39:28AM +0200, Kluvanek Martin wrote:
> 
>>>Jinak [NO]LOGGING neni vlastnost tablespacu, nybrz segmentu v nem 
>>>ulozenych. Tablespace ma vetsinu vlastnosti jen jako DEFAULT pro v nem 
>>>nove vytvarene objekty (MIN_EXTENTS, MAX_EXTENTS, INITIAL_EXTENT, 
>>>NEXT_EXTENT, PCT_INCREASE - priklady dalsich takovych vlastnosti).
>>
>>Chapem, ale ja som
>>1)vytvoril novy tablespace s NOLOGGING
>>2)DROPol tabulku ktoru som nechcel logovat
>>3)vytvoril tabulku a index s odkazom na pouzitie noveho tablespace s 
>>NOLOGGING
>>(v browseri vidim, ze v tablespace MSENOLOGGING su objekty moja tabulka a 
>>index..)
> 
> 
> Je uplne jedno, v jakem jsou tablespace, dulezite je, jaky je ten
> parametr u toho konkretniho objektu. Nastaveni LOGGING/NOLOGGING pouze
> urcuje default pro ty objekty, ktere samy nereknou.
> 
> 
>>>Oracle vubec nedovoli vytvorit permenantni segment (muzete tam vytvaret 
>>>pouze temporary segmenty, ktere Oracle implicitne vytvari kdyz potrebuje 
>>>tridit (ORDER BY, GROUP BY, vyroba indexu) a tridena data se nevejdou do 
>>>SORT AREA).
>>
>>Cize z toho mi nic nieje platne, ja potrebujem nieco co bude prermanent ale 
>>absolutne vsetko NOLOGGING
>>Na manipulaciu s datami v tabulke sa kazdych 10s otvara nova session a 
>>navyse k nim potrebuju pristupovat ine sesions...
> 
> 
> Prijde mi, ze by bylo mozna vhodne rict, proc to vlastne cele delate.
> Oracle je jako RDBMS postaven tak, aby byl schopen zajistit
> konzistenci dat. Tedy pokud z te tabulky delate delete, tak system
> musi zajistit, ze pokud dojde k vypadku jeste predtim, nez udelate
> commit, bude schopen se vratit do predchoziho stavu. Ze Vy ta data
> kazdych 10 sekund mazete a v podstate Vas nezajima, jaka tam jsou,
> protoze za 10 sekund uz nebudou aktualni, zase nezajima Oracle. :-)
Hmmm, uznavam, ze to nieje moc bezne a korektne vyusitie, ale na druhu stranu 
neviem, preco by ORA musel otrocky logovat vsetko i to co evidentne nechcem.
Uz tak mam dost divny pocit, ze ORA loguje(1.krat) vsetky data ktore pritecu do 
nejakej predavacej tabulky (sem mi cpe data aplikacia[cez ODBC?], ktora nevie 
predat data inym sposobom),
ja tie data z tabulky spracovamam do archivu (tam sa vlastne loguju znovu 
2.krat) a mazem z predavacej tabulky ("bufferu")(3.krat log). Potom z toku dat 
rekonstruujem aktualny stav (pretoze ten archiv je opravdu mastny) (tu sa to 
loguje 4.krat) a este tie spracovane data predavam inemu systemu (5.krat log).
K tomu vsetkemu sa mi loguju zmeny stavu funkcnosti vsetkych komponent systemu 
(kazdych 10s) takze vysledok je, ze mam 1GB archivnych logov denne (a to vacsinu 
tvori zrejme to generovanie kazdych 10s)

> 
> Do redo logu jdou vsechny operace z rollback / undo segmentu. Takze
> pokud se chcete vyhnout narustani redo logu, mel byste hledat takove
> operace, ktere nebudou zapisovat rollback informaci. Misto delete tedy
> nejlepe truncate, misto insert pak nejaky insert /*+append*/ nebo tak.
> Tedy veci, ktere DML dokazi udelat nikoli manipulaci s jednotlivymi
> zaznamy v tabulce, ale manipulaci s matainformaci (posun HWM).
Suhlas, to bude asi jedina moznost.




-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz



Další informace o konferenci Test