Come controllare l'attività del database senza problemi di prestazioni e scalabilità?

Question

Ho bisogno di controllare tutta l'attività del database indipendentemente dal fatto che provenga dall'applicazione o da qualcuno che emette SQL tramite altri mezzi.Pertanto il controllo deve essere effettuato a livello di database.Il database in questione è Oracle.Ho cercato di farlo tramite Trigger e anche tramite qualcosa chiamato Fine Grained Auditing fornito da Oracle.In entrambi i casi, abbiamo attivato il controllo su tabelle e colonne specifiche.Tuttavia, abbiamo scoperto che le prestazioni sono davvero pessime quando utilizziamo uno di questi metodi.

Poiché il controllo è un must assoluto a causa delle normative relative alla privacy dei dati, mi chiedo quale sia il modo migliore per farlo senza un significativo degrado delle prestazioni.Se qualcuno ha esperienza specifica su Oracle con questo, sarà utile, ma in caso contrario andranno bene anche le pratiche generali relative al controllo delle attività del database.

Answer 1

Non sono sicuro che si tratti di un approccio abbastanza maturo per un sistema di produzione, ma ho avuto un bel po 'di successo con il monitoraggio del traffico del database utilizzando uno sniffer di traffico di rete.

Invia i dati grezzi tra l'applicazione e il database su un'altra macchina e decodifica e analizzali lì.

Ho usato PostgreSQL e decodificando il traffico e trasformandolo in un flusso di operazioni di database che potevano essere registrate era relativamente semplice.Immagino che funzionerà su qualsiasi database in cui il formato dei pacchetti è documentato.

Il punto principale era che non comportava alcun carico aggiuntivo sul database stesso.

Inoltre, è stato un monitoraggio passivo, ha registrato tutte le attività, ma non è riuscito a bloccare alcuna operazione, quindi potrebbe non essere proprio quello che stai cercando.

Answer 2

Non è necessario "rotolare il proprio".Basta attivare il controllo:

1. Impostare il parametro del database AUDIT_TRAIL = DB.
2. Avvia l'istanza.
3. Accedi con SQLPlus.
4. Inserisci la dichiarazione

   audit all;

   Ciò attiva il controllo per molte operazioni DDL critiche, ma DML e alcune altre istruzioni DDL non vengono ancora controllate.
5. Per abilitare il controllo su queste altre attività, prova affermazioni come queste:

   audit alter table; -- DDL audit
   audit select table, update table, insert table, delete table; -- DML audit

Nota:Tutta l'attività "come sysdba" viene SEMPRE controllata sul sistema operativo.In Windows, ciò significa il registro eventi di Windows.In UNIX, solitamente è $ORACLE_HOME/rdbms/audit.

Dai un'occhiata a Capitolo sull'audit di Oracle 10g R2 del riferimento SQL del database.

L'audit trail del database può essere visualizzato nella vista SYS.DBA_AUDIT_TRAIL.

Va sottolineato che l'auditing interno di Oracle sarà per definizione ad alte prestazioni.È progettato per essere esattamente questo ed è molto difficile immaginare qualcos'altro che possa competere con lui in termini di prestazioni.Inoltre, esiste un elevato grado di controllo "a grana fine" dell'auditing Oracle.Puoi ottenerlo con la precisione che desideri.Infine, la tabella SYS.AUD$ insieme ai suoi indici può essere spostata in uno spazio tabella separato per evitare di riempire lo spazio tabella SYSTEM.

Cordiali saluti, opus

Answer 3

Se desideri registrare copie di record modificati su un sistema di destinazione, puoi farlo con Golden Gate Software e non incorrere in molto in termini di drenaggio delle risorse lato sorgente.Inoltre non è necessario apportare alcuna modifica al database di origine per implementare questa soluzione.

Golden Gate cancella i registri di ripetizione delle transazioni che fanno riferimento a un elenco di tabelle a cui sei interessato.Queste modifiche vengono scritte in un "File di traccia" e possono essere applicate a uno schema diverso sullo stesso database oppure inviate a un sistema di destinazione e applicate lì (ideale per ridurre il carico sul sistema di origine).

Una volta inviato il file di traccia al sistema di destinazione, ci sono alcune modifiche alla configurazione che puoi impostare un'opzione per eseguire il controllo e, se necessario, puoi richiamare 2 funzioni Golden Gate per ottenere informazioni sulla transazione:

1) Impostare il parametro di replica INSERTALLRECORDS per inserire un nuovo record nella tabella di destinazione per ogni operazione di modifica apportata alla tabella di origine.Attenzione, questo può consumare molto spazio, ma se hai bisogno di un audit completo probabilmente è previsto.

2) Se non hai già CHANGED_BY_USERID e CHANGED_DATE allegati ai tuoi record, puoi utilizzare le funzioni Golden Gate sul lato di destinazione per ottenere queste informazioni per la transazione corrente.Scopri le seguenti funzioni nella Guida di riferimento GG:GGHEADER ("UserId") GGHEADER ("timestamp")

Quindi no, non è gratuito (richiede la licenza tramite Oracle) e richiederà un certo sforzo per avviarlo, ma probabilmente molto meno impegno/costo rispetto all'implementazione e al mantenimento di una soluzione personalizzata che si sviluppa da soli, e hai l'ulteriore vantaggio di spedire i dati a un sistema remoto in modo da poter garantire un impatto minimo sul database di origine.

Answer 4

se si utilizza Oracle, esiste una funzionalità chiamata CDC (Capture data change) che è una soluzione più efficiente in termini di prestazioni per i requisiti di tipo di controllo.