SocrateCloud‎ > ‎3. Tips&tricks‎ > ‎

4. Arhivare audit

Asa cum probabil toti administratorii de sistem SocrateCloud/SocrateOpen deja stiu, tabela de audit AD_ChangeLog este cea mai mare tabela din sistem.
In unele cazuri marimea ei (inclusiv a indecsilor asociati) ajunge la 70% din baza de date (in functie de cat de mult audit este activat).

Pentru a micsora incarcarea pe procesele de backup, incepand cu versiunea 14.03, SocrateCloud pune la dispozitie o structura de date pentru arhivarea acestui audit.
Noua tabela se numeste AD_ChangeLog_History.

In aplicatie a fost modificata fereastra Info inregistrare pentru a citi date din cele doua tabele (prin consolidarea/union informatiilor filtrate pe inregistrarea selectata). 
  • Inregistrarile din zona curenta de audit (AD_ChangeLog) sunt editabile (pentru a putea marca eventuale customizari).
  • Cele din istoric/arhiva (AD_ChangeLog_History) sunt read-only.

Nu exista un proces automat de mutare a inregistrarilor din AD_ChangeLog in AD_ChangeLog_History. 
Operatiunea trebuie gestionata de catre DBA folosind scripturi Oracle.
Este obligatoriu ca in tabela AD_ChangeLog sa se pastreze toate customizarile (doar aici se va uita procesul Repune customizari rulat dupa migrare).
Ca urmare, la mutarea datelor din AD_ChangeLog in AD_ChangeLog_History NU se muta inregistrarile cu IsCustomization = 'Y' acestea, indiferent de data marcarii, raman in AD_ChangeLog.

Dupa mutarea intiala a datelor istorice se poate relua procesul la 3-6 luni in functie de rata de crestere a tabelei.

Pentru a micsora incarcarea pe procesele de backup se poate consideara aceasta tabela "read-only" ....... respectiv actualizabila la 3-6 luni
Cateva idei utile (dar nu exhaustive):
  • mutare AD_ChangeLog_History pe un sistem de stocare mai lent/ieftin (implica si schimbarea tablespace-ului tabelei)
  • excluderea tabelei AD_ChangeLog_History din dump-ul zilnic
  • modificarea scriptului de backup Oracle (cu RMAN) pentru a nu salva tablespace-urile read-only






Comments