Oracle
 sql >> Datenbank >  >> RDS >> Oracle

Verwenden von LogMiner, um aktuelle Änderungen zu finden

Es kann vorkommen, dass es notwendig ist, die jüngsten Änderungen an der Datenbank zu untersuchen und zu melden, was geändert wurde, wann und von wem. Für solche Aufgaben steht seit Jahren das DBMS_LOGMNR-Paket von Oracle zur Verfügung, dessen Aufrufe jedoch nicht vollständig abgedeckt sind. Herkömmliche Verfahren verwenden die ADD_LOGFILE()-Prozedur, um Log Miner für die Verwendung mit einem einfachen Aufruf der START_LOGMNR-Prozedur vorzubereiten. Dadurch wird das Dienstprogramm mit dem aktuellen SCN als Ausgangspunkt gestartet. Es gibt eine andere Möglichkeit, Log Miner zu starten, indem Sie einen gültigen Start-SCN auswählen und diesen dem START_LOGMNR()-Aufruf zur Verfügung stellen. In diesem Artikel erfahren Sie, wie dies bewerkstelligt werden kann, und zeigen dabei mögliche Problembereiche bei PGA-Zuweisungen auf.

Betrachtet man ein „Plain Vanilla“-Skript zum Starten von Log Miner, werden die üblichen Prozeduraufrufe durchgeführt, die Log Miner mit dem aktuellen SCN starten:

---- run_logmnr.sql---- Protokolldateien hinzufügen und DBMS_LOGMNR einstellen, um-- Archivprotokolle kontinuierlich zu minen--Zeilengröße 200 setzen trimspool auf Seitengröße 0---- Vorhandene Protokolldateien hinzufügen---- Standby-Protokolldateien weglassen- -select 'exec dbms_logmnr.add_logfile('''||member||''')'from v$logfilewhere type <> 'STANDBY'and member in (select min(member) from v$logfile group by group#)spool /tmp/add_logfiles.sql/spool off@/tmp/add_logfiles---- Logmnr im kontinuierlichen Mining-Modus starten--exec dbms_logmnr.start_logmnr(options => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.CONTINUOUS_MINE + DBMS_LOGMNR.COMMITTED_DATA_ONLY)

Beachten Sie, dass alle verfügbaren Redo-Protokolle vor dem Start von Log Miner hinzugefügt werden. Eine andere Methode existiert, die einen Start-SCN an den start_logmnr-Aufruf liefert, solange die Datenbank im ARCHIVELOG-Modus läuft:

BEGIN DBMS_LOGMNR.START_LOGMNR( startScn => , endScn => , OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY + DBMS_LOGMNR.CONTINUOUS_MINE);END;/

Interessanterweise ist der End-SCN nicht erforderlich, um eine Log Miner-Sitzung zu starten. Die Datenbank muss sich im ARCHIVELOG-Modus befinden, damit die Option CONTINUOUS_MINE angegeben werden kann, da Log Miner während der Ausführung automatisch jede verfügbare archivierte Protokolldatei hinzufügt. Mit dieser Methode kann eine bestimmte SCN verwendet werden, um eine Suche zu starten; Angabe der End-SCN-Suche in Klammern, sodass nur eine begrenzte Teilmenge von Daten an die V$LOGMNR_CONTENTS-Ansicht zurückgegeben wird, und einen Haltepunkt für die Suche bereitstellt, sodass eine Abfrage der Ansicht beendet werden kann.

Es ist eine einfache Aufgabe, den Fortschritt von Log Miner zu überwachen, indem Sie das Datenbank-Alarmprotokoll überprüfen, wenn mit „LOGMINER“ gekennzeichnete Einträge registriert werden. Ein vollständiger Eintrag enthält eine BEGIN- und eine END-Zeile, wie unten gezeigt:

Mo 7. Okt 12:48:22 2019LOGMINER:Mining-Logdatei für Sitzung -2147482111 Thread 1 Sequenz 9776 beenden, /oracle/archive/awcis/awcis_0000009776_0001_1008544071.arcMo 7. Okt 12:48:22 2019LOGMINER:Mining-Logdatei für Sitzung beginnen - 2147482111 Thread 1 Sequence 9777, /oracle/archive/awcis/awcis_000097777_0001_100854071.ARCMON OCT 07 12:48:36 2019LogMiner:End Mining Logfile für Session -214748211 Thread. :48:36 2019LOGMINER:Mining-Protokolldatei für Sitzung -2147482111 Thread 1, Sequenz 9778, /oracle/archive/awcis/awcis_0000009778_0001_1008544071.arcMon Oct 07 12:48:49 2019LOGMINER:Mining-Protokolldatei für Sitzung -2147482111 Thread 81, Sequenz /117 beenden /117 oracle/archive/awcis/awcis_0000009778_0001_1008544071.arcMon Oct 07 12:48:49 2019LOGMINER:Mining-Protokolldatei für Sitzung -2147482111, Thread 1, Sequenz 9779, /oracle/archive/awcis/awcis_0000009779_0001_10081.54 beginnen1.54 

Für lokale Oracle-Sitzungen sind die Zahlen positive ganze Zahlen; für Remote-Sitzungen, die von Dienstprogrammen wie Perl, Python, C/C++ oder anderen Sprachen initiiert werden, werden negative Ganzzahlen angezeigt (die oben gezeigten Einträge wurden von einem Python-Skript initiiert). Protokolldateinamen durchlaufen sowohl die Online-Redo-Protokolle als auch die verfügbaren archivierten Kopien.

Das Starten von Log Miner auf diese Weise kann auch Fehler wie „fehlende Protokolldatei“ auslösen, wenn der ausgewählte Start-SCN oder SCN-Bereich nicht mehr im Redo-Stream verfügbar ist. Lang andauernde Abfragen können auf solche Fehler stoßen. Wenn der SCN in Bezug auf die verfügbaren Protokolldateien außerhalb des Bereichs liegt, startet Log Miner außerdem nicht und gibt Folgendes aus:

FEHLER in Zeile 1:ORA-01292:Für die aktuelle LogMiner-Sitzung wurde keine Protokolldatei angegebenORA-06512:in "SYS.DBMS_LOGMNR", Zeile 58ORA-06512:in Zeile 2

Um solche Fehler zu beseitigen, bietet die Auswahl von FIRST_CHANGE# aus der V$LOG-Ansicht gültige Ausgangspunkte für eine Log Miner-Sitzung; Die Verwendung einer ähnlichen Abfrage für V$ARCHIVED_LOG gibt alle verfügbaren Start-SCNs für die archivierten Redo-Kopien zurück.

Dies ist nicht die einzige Komplikation bei der Verwendung von Log Miner auf diese Weise. Je nachdem, wie viele Informationen zurückgegeben werden sollen, kann der Logmminer-Prozess große Mengen an PGA-Speicher zuweisen, was bei einem kleinen pga_aggregate_limit den folgenden Fehler auslösen kann:

ORA-04036:Der von der Instanz verwendete PGA-Speicher überschreitet PGA_AGGREGATE_LIMIT

glücklicherweise ist dies kein schwerwiegender Fehler. Da PGA-Ressourcen nicht mehr benötigt werden, kann der Speicher zur anderweitigen Verwendung an die Datenbank zurückgegeben werden. Es kann jedoch etwas länger dauern als gewünscht, diesen Speicher wieder in den Speicherpool freizugeben. Eine Option besteht darin, pga_aggregate_limit höher als die Summe der Log Miner-Sitzungen festzulegen, wodurch das Auftreten des Fehlers verhindert werden kann. Woher wissen Sie, welcher Speicher diesen Sitzungen zugewiesen ist? Eine Ansicht, V$PROCESS_MEMORY_DETAIL, ist in der Datenbank verfügbar. Wenn Sie jedoch versuchen, diese Ansicht ohne Vorbereitung abzufragen, wird zurückgegeben:

keine Zeilen ausgewählt.

Dies ist ein relativ kleines Problem, aber es erfordert die Verwendung des oradebug-Dienstprogramms. Die folgenden Schritte laden Daten in V$PROCESS_MEMORY_DETAIL:

---- Aktuelle Sitzungskennung setzen-- oradebug setmypid---- PID des gewünschten Prozesses verwenden-- Speicherdaten ausgeben---- Dies füllt V$PROCESS_MEMORY_DETAIL--oradebug pga_detail_get - --- Fragen Sie die Ansicht ab, um die gewünschten Daten zu erhalten--wählen Sie * From v$process_memory_detail;---- Um die Ansicht wieder mit neueren Daten zu füllen-- führen Sie einfach die oradebug pga_detail_get-- Anweisung aus--oradebug pga_detail_get    

Ein Skript zum Ausführen dieser Aktionen wird unten gezeigt:

---- Einrichten der Umgebung für oradebug-Aufrufe--oradebug setmypidset echo off trimspool onset verify offundefine p_1undefine p_2undefine s1undefine s2variable p1 numbervariable p2 numbercolumn sys_date new_value sysdt noprintselect to_char(sysdate, 'RRRRMMDDHH24MISS') sys_date from dual;-- -- Prozess-ID der Sitzung  abrufen - Spalte pid neuer_Wert p_1PID aus v$Prozess auswählen, wobei Adresse in (paddr aus v$Sitzung auswählen, wobei Benutzername ='' und sid =(max(sid) auswählen) aus v$session where username =''));begin :p1 :=&p_1;end;/---- Speichere Prozessdetails in v$process_memory_detail--oradebug dump pga_detail_get &p_1spool &p_1._pga_stats_&sysdt..log--- - Abrufen von Sitzungsinformationen für --COLUMN alme HEADING "Allocated MB" FORMAT 99999D9COLUMN usme HEADING "Used MB" FORMAT 99999D9COLUMN frme HEADING "Freeable MB" FORMAT 99999D9COLUMN mame HEADING "Max MB" FORMAT 99999D9COLUMN Benutzername FORMAT a25COLUMN Programm FORMAT a22COLUMN sid FORMAT a5COLUMN spid FORMAT a8column 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 =''ORDER BY pga_max_mem,logon_time;---- Ruhezustand 30 Sekunden---- Sitzungsinformationen erneut abrufen--exec dbms_lock.sleep(30) Spalte sid new_value 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 =''ORDER BY pga_max_mem,logon_time;exec dbms_lock.sleep(10)select max(sid) sid from v$session where username ='';---- Informationen zum Prozessspeicher abrufen--COLUMN category HEADING "Category"COLUMN zugeteilt HEADING "Zugewiesene Bytes"COLUMN used HEADING "Verwendete Bytes"COLUMN max_allocated HEADING "Max zugeteilte Bytes"SELECT pid, category, zugewiesen, verwendet, 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, category, zugewiesen, verwendet, max_allocatedFROM v$process_memoryWHERE pid in (PID FROM v$process WÄHLEN WO addr in (paddr FROM v$session auswählen WHERE sid =&&s1));exec dbms_lock.sleep(10)PID aus v$process auswählen whe re addr in (wählen Sie paddr aus v$session wo Benutzername ='' und sid =(wählen Sie max(sid) aus v$session wo Benutzername =''));---- Speichern Sie den ersten Durchgang von pga stats--CREATE TABLE tab1 ASSELECT pid, category, name, heap_name, bytes, algorithm_count, heap_descriptor, parent_heap_descriptorFROM v$process_memory_detailWHERE pid =&p_1AND category ='Other';---- Holen Sie sich den zweiten Durchgang von pga stats--oradebug dump pga_detail_get &p_1exec dbms_lock.sleep(120)---- Speichern Sie den zweiten Durchgang von PGA-Statistiken--CREATE TABLE tab2 ASSELECT pid, category, name, heap_name, bytes, algorithm_count, heap_descriptor, parent_heap_descriptorFROM v$process_memory_detailWHERE pid =&p_1AND category ='Other'; ---- Abschlußberichte starten---- PGA Heap Info--COLUMN category HEADING "Category" COLUMN name HEADING "Name" COLUMN heap_name HEADING "Heap name" COLUMN q1 HEADING "Memory 1st" Format 999.999.999.999 COLUMN q2 HEADING "Memory 2nd "Format 999.999.999,9 99COLUMN diff HEADING "Difference" Format 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 diffFROM 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 heap_name HEADING "heap name"COLUMN name HEADING "Type"COLUMN Zuweisungszahl HEADING "Count"COLUMN bytes HEADING "Sum"COLUMN avg HEADING "Average" FORMAT 99999D99SELECT pid, heap_name, name, Zuteilungszahl, Bytes, Bytes/Zuteilungszahl avgFROM tab2WHERE heap_name like 'Logminer%';spool offdrop table tab1 purge;drop table tab2 purge;

Speichern Sie diesen Code als Skript und bearbeiten Sie den Text, um die Zeichenfolgen durch das Benutzerkonto zu ersetzen, auf dem Log Miner ausgeführt wird. Das Skript zielt speziell auf den Logminer-Speicher ab, damit dieser auf Zunahmen überwacht werden kann. Es kann auch modifiziert werden, um nach anderen problematischen Speicherbereichen zu suchen. Kommentieren Sie die „drop table“-Befehle, um tab1 und tab2 für weitere Recherchen aufzubewahren, falls gewünscht, da andere Speicherbereiche von Interesse sein könnten. Überprüfen Sie auch den Oracle-Support auf bekannte PGA-bezogene Probleme. Solche Berichte enthalten wahrscheinlich Abfragen zur Untersuchung bestimmter Problembereiche mit V$PROCESS_MEMORY_DETAIL. Der Zweckmäßigkeit halber können diese zusätzlichen Abfragen dem oben gezeigten Code hinzugefügt werden, um über alle verdächtigen Bereiche des Prozessspeichers zu berichten. Diese Daten werden dazu beitragen, die Notwendigkeit zu beweisen, spezifische einmalige Patches auf die Datenbank anzuwenden.

Log Miner kann ein sehr nützliches Werkzeug sein, um aktuelle und relativ neue vergangene Aktionen in der Datenbank zu untersuchen. Es kann erforderlich sein, PGA-Zuweisungen zu überwachen, während Log Miner-Sitzungen aktiv sind, damit vorbeugende Maßnahmen wie das Erhöhen von pga_aggregate_limit ausgeführt werden können und Sitzungen nicht abrupt beendet werden. „Vorgewarnt ist gewappnet“, wie das Sprichwort sagt, und auch wenn DBAs keine vier Arme haben, zu wissen, was vor ihnen liegen könnte, ist immer Wissen wert.

Alle Artikel von David Fitzjarrell anzeigen