Potrebbero esserci occasioni in cui è necessario indagare sulle modifiche recenti al database e segnalare cosa è stato modificato, quando e da chi. Per anni il pacchetto DBMS_LOGMNR di Oracle è disponibile per tali attività, ma le sue invocazioni non sono state completamente coperte. I metodi convenzionali utilizzano la procedura ADD_LOGFILE() per preparare Log Miner per l'uso con una chiamata di base alla procedura START_LOGMNR. Questo avvia l'utilità con l'SCN corrente come punto di partenza. C'è un altro modo per avviare Log Miner, selezionando un SCN iniziale valido e fornendolo alla chiamata START_LOGMNR(). In questo articolo, vedrai come questo può essere fatto e, nel processo, rivelerai una possibile area di preoccupazione con le allocazioni PGA.
Osservando uno script "plain vanilla" per avviare Log Miner, vengono effettuate le solite chiamate di procedura che avviano Log Miner con l'SCN corrente:
---- run_logmnr.sql---- Aggiungi file di registro e imposta DBMS_LOGMNR su-- mina continuamente i log di archivio--imposta la dimensione della linea 200 trimspool sulla dimensione della pagina 0---- Aggiungi i file di registro esistenti---- Ometti i file di registro in standby- -select 'exec dbms_logmnr.add_logfile('''||member||''')'from v$logfiledove digita <> 'STANDBY'e membro in (select min(member) from v$logfile group by group#)spool /tmp/add_logfiles.sql/spool off@/tmp/add_logfiles---- Avvia logmnr in modalità miniera continua--exec dbms_logmnr.start_logmnr(options => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.CONTINUOUS_MINE + DBMS_LOGMNR.COMMITTED_DATA_ONLY) Tieni presente che tutti i registri di ripristino disponibili vengono aggiunti prima di avviare Log Miner. Esiste un altro metodo che fornisce un SCN iniziale alla chiamata start_logmnr, purché il database sia in esecuzione in modalità ARCHIVELOG:
BEGIN DBMS_LOGMNR.START_LOGMNR( startScn =>, endScn => , OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY + DBMS_LOGMNR.CONTINUOUS_MINE);END;/
È interessante notare che l'SCN finale non è necessario per avviare una sessione di Log Miner. Il database deve essere in modalità ARCHIVELOG in modo che l'opzione CONTINUOUS_MINE possa essere specificata perché Log Miner aggiungerà automaticamente ogni file di registro archiviato disponibile durante l'esecuzione. L'utilizzo di questo metodo consente di utilizzare un SCN specifico per avviare qualsiasi ricerca; specificando la ricerca tra parentesi SCN finali in modo che solo un sottoinsieme limitato di dati venga restituito alla vista V$LOGMNR_CONTENTS e fornisca un punto di arresto per la ricerca, in modo che una query della vista possa terminare.
È un compito semplice monitorare lo stato di avanzamento di Log Miner controllando il registro degli avvisi del database poiché le voci contrassegnate con "LOGMINER" sono registrate. Una voce completa includerà una riga BEGIN e una END, come mostrato di seguito:
Mon Oct 07 12:48:22 2019LOGMINER:Fine del file di log di mining per la sessione -2147482111 thread 1 sequenza 9776, /oracle/archive/awcis/awcis_0000009776_0001_1008544071.arcMon Oct 07 12:48:22 2019LOGMINER:Inizio del file di log di mining per la sessione 2147482111 thread 1 sequence 9777, /oracle/archive/awcis/awcis_0000009777_0001_1008544071.arcMon Oct 07 12:48:36 2019LOGMINER:End mining logfile for session -2147482111 thread 1 sequence 9777, /oracle/archive/awcis/awcis_0000009777_0001_1008544071.arcMon Oct 07 12 :48:36 2019LOGMINER:inizio del file di log di mining per la sessione -2147482111 thread 1 sequenza 9778, /oracle/archive/awcis/awcis_0000009778_0001_1008544071.arcMon ott 07 12:48:49 2019LOGMINER:fine del file di log di mining per la sessione -2147444071.arcMon ott 07 12:48:49 2019LOGMINER:fine del file di log di mining per la sessione -214744407182111 oracle/archive/awcis/awcis_0000009778_0001_1008544071.arcMon Oct 07 12:48:49 2019LOGMINER:inizio del file di log di mining per la sessione -2147482111 thread 1 sequenza 9779, /oracle/archive/awcis/awcis_0000009779_0001_1079_08541.107Per le sessioni Oracle locali i numeri sono numeri interi positivi; per le sessioni remote, avviate da utilità come Perl, Python, C/C++ o altri linguaggi verranno visualizzati interi negativi (le voci mostrate sopra sono state avviate da uno script Python). I nomi dei file di registro scorreranno sia i registri di ripristino online che le copie archiviate disponibili.
L'avvio di Log Miner in questo modo può anche generare errori come "file di registro mancante" quando l'intervallo SCN o SCN iniziale selezionato non è più disponibile nel flusso di ripristino. Le query di lunga durata possono riscontrare tali errori. Inoltre, se l'SCN è fuori portata rispetto ai file di registro disponibili, Log Miner non si avvia, generando:
ERRORE alla riga 1:ORA-01292:nessun file di registro è stato specificato per la sessione LogMiner correnteORA-06512:a "SYS.DBMS_LOGMNR", riga 58ORA-06512:alla riga 2Per aiutare ad eliminare tali errori, selezionare FIRST_CHANGE# dalla vista V$LOG fornirà validi punti di partenza per una sessione di Log Miner; l'utilizzo di una query simile su V$ARCHIVED_LOG restituirà tutti gli SCN iniziali disponibili per le copie di ripristino archiviate.
Questa non è l'unica complicazione nell'utilizzo di Log Miner in questo modo. A seconda della quantità di informazioni da restituire, il processo Logmminer può allocare grandi quantità di memoria PGA che, se pga_aggregate_limit è piccolo, genera il seguente errore:
ORA-04036:la memoria PGA utilizzata dall'istanza supera PGA_AGGREGATE_LIMITfortunatamente questo non è un errore fatale. Poiché le risorse PGA non sono più necessarie, la memoria può essere rilasciata nel database per l'uso altrove. Tuttavia, potrebbe essere necessario un po' più di tempo del previsto per riportare la memoria nel pool di memoria. Un'opzione consiste nell'impostare pga_aggregate_limit su un valore superiore alla somma delle sessioni di Log Miner che può impedire il verificarsi dell'errore. Come fai a sapere quale memoria è allocata a quelle sessioni? Una vista, V$PROCESS_MEMORY_DETAIL, è disponibile nel database. Ma il tentativo di interrogare questa vista senza alcuna preparazione restituirà:
nessuna riga selezionata.Questo è un problema relativamente minore, ma richiede l'uso dell'utilità oradebug. I seguenti passaggi caricheranno i dati in V$PROCESS_MEMORY_DETAIL:
---- Imposta l'identificatore di sessione corrente-- oradebug setmypid---- Usando il PID del processo desiderato-- scarica i dati di memoria---- Questo popola V$PROCESS_MEMORY_DETAIL--oradebug pga_detail_get- --- Interroga la vista per ottenere i dati desiderati--select * From v$process_memory_detail;---- Per ripopolare la vista con dati più recenti-- esegui semplicemente l'oradebug pga_detail_get-- statement--oradebug pga_detail_get Di seguito viene mostrato uno script per eseguire queste azioni:
---- Configurare l'ambiente per le chiamate di oradebug--oradebug setmypidset echo off trimspool onset verifica difundefine p_1undefine p_2undefine s1undefine s2variable p1 numbervariable p2 numbercolumn sys_date new_value sysdt noprintselect to_char(sysdate, 'RRRRMMDDHH24MISS') sys_date from dual;-- -- Ottieni l'id del processo della sessione--column pid new_value p_1select pid da v$process dove addr in (seleziona paddr da v$session dove username =' ' e sid =(select max(sid) From v$session where username =' '));begin :p1 :=&p_1;end;/---- Scarica i dettagli del processo in v$process_memory_detail--oradebug dump pga_detail_get &p_1spool &p_1._pga_stats_&sysdt..log--- - Ottieni informazioni sulla sessione per --COLUMN alme INTESTAZIONE "MB allocati" FORMATO 99999D9COLUMN usme INTESTAZIONE "MB usati" FORMATO 99999D9COLUMN frme INTESTAZIONE "MB liberabili" FORMATO 99999D9COLUMN mame INTESTAZIONE "MB Max" FORMATO 99999D9COLONNA username FORMATO a25COLUMN programma FORMAT a22COLUMN sid FORMAT a5COLUMN spid FORMAT a8colonna pid_remote format a12SET LINESIZE 300SELECT s.username, SUBSTR(s.sid,1,5) sid, p.spid, logon_time, SUBSTR(s.program,1,22) program , s.process pid_remote, s.status, ROUND(pga_used_mem/1024/1024) usme, ROUND(pga_alloc_mem/1024/1024) alme, ROUND(pga_freeable_mem/1024/1024) frme, ROUND(pga_max_mem/1024/1024) mameFROM v$session s, v$process pWHERE p.addr=s.paddrAND s.username =' 'ORDINA PER pga_max_mem,logon_time;---- Sospensione 30 secondi---- Ottieni di nuovo le informazioni sulla sessione--exec dbms_lock.sleep(30) colonna sid nuovo_valore s1 noprintSELECT s.username, SUBSTR(s.sid,1,5) sid, p.spid, logon_time, SUBSTR(s.program,1,22) program , s.process pid_remote, s.status, ROUND( pga_used_mem/1024/1024) usme, ROUND(pga_alloc_mem/1024/1024) alme, ROUND(pga_freeable_mem/1024/1024) frme, ROUND(pga_max_mem/1024/1024) mameFROM v$session s,v$process pWHERE p.addr=s.paddrAND s.username =' 'ORDINA PER pga_max_mem,logon_time;exec dbms_lock.sleep(10)select max(sid) sid da v$session dove username =' ';---- Ottieni informazioni sulla memoria di processo--Categoria COLONNA INTESTAZIONE "Categoria" COLONNA allocata INTESTAZIONE "Byte allocati" COLONNA utilizzata INTESTAZIONE "Byte utilizzati" COLONNA max_allocati INTESTAZIONE "Numero massimo di byte allocati"SELECT pid, categoria, allocato, usato, max_allocatedFROM v$process_memoryWHERE pid in (SELECT pid FROM v$process WHERE addr in (select paddr FROM v$session WHERE sid =&&s1));exec dbms_lock.sleep(10)SELECT pid, categoria, allocato, usato, max_allocatedFROM v$process_memoryWHERE pid in (SELECT pid FROM v$process WHERE addr in (seleziona paddr FROM v$session WHERE sid =&&s1));exec dbms_lock.sleep(10)select pid from v$process whe re addr in (seleziona paddr da v$session dove username =' ' e sid =(seleziona max(sid) da v$session dove username =' '));---- Salva il primo passaggio di pga stats--CREATE TABLE tab1 ASSELECT pid, categoria, nome, heap_name, byte, allocation_count, heap_descriptor, parent_heap_descriptorFROM v$process_memory_detailWHERE pid =&p_1AND category ='Altro';---- Ottieni il secondo passaggio di pga stats--oradebug dump pga_detail_get &p_1exec dbms_lock.sleep(120)---- Salva il secondo passaggio di pga stats--CREATE TABLE tab2 ASSELECT pid, categoria, nome, nome_heap, byte, conteggio_allocazione, descrittore_heap, descrittore_heap_parentE DA v$process_memory_detailWHERE pid =&p_1AND categoria ='Altro'; ---- Inizio rapporti finali---- Info heap PGA--Categoria COLONNA INTESTAZIONE "Categoria"Nome COLONNA INTESTAZIONE "Nome"COLONNA nome_heap INTESTAZIONE "Nome heap"COLONNA q1 INTESTAZIONE "Memoria 1a" Formato 999,999,999,999COLONNA q2 INTESTAZIONE "Memoria 2a " Formato 999.999.999,9 99COLUMN diff INTESTAZIONE "Differenza" Formato S999.999.999.999SET LINES 150SELECT tab2.pid, tab2.category, tab2.name, tab2.heap_name, tab1.bytes q1, tab2.bytes q2, tab2.bytes-tab1.bytes diffDA tab1, tab2WHERE tab1.category =tab2.categoryAND tab1.name =tab2.nameAND tab1.heap_name =tab2.heap_nameand tab1.pid =tab2.pidAND tab1.bytes <> tab2.bytesORDER BY 1, 7 DESC;---- Logminer PGA info- -COLUMN nome_heap INTESTAZIONE "nome heap" nome COLONNA INTESTAZIONE "Tipo" COLONNA conteggio_allocazione INTESTAZIONE "Conteggio" COLONNA byte INTESTAZIONE "Somma" COLONNA avg INTESTAZIONE "Media" FORMATO 99999D99SELECT pid, nome_heap, nome, conteggio_allocazione, byte, byte/conteggio_allocazione avgDA tab2WHERE nome_heap come 'Logminer%';spool offdrop table tab1 purge; drop table tab2 purge; Salva questo codice come script e modifica il testo per sostituire le stringhe
con l'account utente che esegue Log Miner. Lo script prende di mira specificamente la memoria di Logminer in modo che possa essere monitorato per aumenti. Può anche essere modificato per cercare altre aree di memoria problematiche. Commenta i comandi "tabella di trascinamento" per preservare tab1 e tab2 per ulteriori ricerche, se lo si desidera poiché altre aree di memoria potrebbero essere di interesse. Controlla anche il supporto Oracle per problemi noti relativi a PGA. Tali rapporti avranno probabilmente query da utilizzare per esaminare aree problematiche specifiche utilizzando V$PROCESS_MEMORY_DETAIL. Per convenienza, queste query aggiuntive possono essere aggiunte al codice mostrato sopra per segnalare tutte le aree sospette della memoria di processo. Questi dati saranno fondamentali per dimostrare la necessità di applicare patch specifiche una tantum al database. Log Miner può essere uno strumento molto utile per indagare sulle azioni passate attuali e relativamente recenti nel database. Potrebbe essere necessario monitorare le allocazioni PGA mentre le sessioni di Log Miner sono attive in modo da poter eseguire azioni preventive come l'aumento di pga_aggregate_limit e le sessioni non verranno terminate bruscamente. "Preavvisato è salvato", come si suol dire, e anche se i DBA non hanno quattro braccia, sapere cosa potrebbe aspettarsi è sempre una conoscenza che vale la pena avere.
Vedi tutti gli articoli di David Fitzjarrell
