Schnapp die Session Sessionhistorie mit Bordmitteln. DOAG Konferenz 2013 Jan Krüger TUI Infotec GmbH

Schnapp die Session Sessionorie mit Bordmitteln DOAG Konferenz 2013 Jan Krüger TUI Infotec GmbH

TUI InfoTec. Unsere Unternehmensstruktur. 54,90% 43,33% 100% 100% More than a smile 100% 83,5% 50% TUI InfoTec Unternehmenspräsentation

TUI InfoTec. Unsere Geschichte. IT-Abteilung der TUI Best Practice Award für die beste Lösung im deutschsprachigen Raum TUI InfoTec bietet seine Dienstleistungen auch außerhalb des TUI Konzerns an bis 1997 1997 2002 2006 2007 2011 Ausgründung als TUI InfoTec GmbH Sonata wird mit 50.1% Anteilseigner von TUI InfoTec TUI Travel PLC übernimmt 100% der Anteile von TUI InfoTec TUI InfoTec Unternehmenspräsentation

Unsere Rechenzentren. Ihre Daten bleiben sicher in Deutschland. 2 Standorte in Hannover, 350 Mitarbeiter Service Management, Service Desk & Data Center A Enterprise Operation Center & Data Center B TUI InfoTec Unternehmenspräsentation

TUI InfoTec: Mittelständische Struktur. Erfahrung mit internationalen Konzernen. Wir erbringen Services für unternehmenskritische Anwendungen für große Unternehmen. Aber: Mittelständische Strukturbedeutet für uns und unsere Kunden kurze Entscheidungswege Anpassungsfähigkeit an kundenspezifische Anforderungen ausgeprägte Kundenorientierung direkter Zugang zu allen Managementebenen TUI InfoTec Unternehmenspräsentation

Unsere Vision. We integrate your business into the future - with a smile! Wir bewirken, dass unsere Kunden in dieser Welt ihr Business beherrschen und ausbauen können. Wir schaffen Lösungen für unsere Kunden, in dem wir die richtigen Menschen und passenden Technologien zusammenführen. Wir sind stolz, mit Leidenschaft und Kompetenz die Zukunftsfähigkeit unserer Kunden zu sichern. TUI InfoTec Unternehmenspräsentation

Schnapp die Session Was ist das Problem? Erster Versuch: Nicht sehr praktisch Zweiter Versuch: So geht s nicht Dritter Versuch: Stabile Lösung Anwendungsbeispiele aus der Praxis DOAG 2013 Jan Krüger TUI Infotec GmbH

Das Problem Flüchtige Diagnoseinformation Probleme treten sporadisch auf Spezialistin fehlt, wenn Problem auftritt Die besten Analyseideen kommen einem erst hinterher Statspack zu geringe zeitliche Auflösung und zu stark aggregiert Verschiedene Tools am Markt Diagnostic Pack Foglight Seite 8

Erster Versuch Shellscript in Datei crontab gesteuerte Datensammlung * * * * */tui/ /scripts/memwatch.ksh NPMP 0 4 * * * find /tui/ /memwatch -mtime +15 -exec rm {} \\; cat memwatch.ksh DAY=`/bin/date '+%d'` echo `date` ++++++++++++ >> $DATADIR/pswatch.txt.$DAY /bin/ps -eo "user pid ppid pri nice vsz tty etime time args" >> $DATADIR/pswatch.txt.$DAY Seite 10

Erster Versuch Shellscript in Datei sqlplus -s "/ as sysdba" << EOFSQL >> $DATADIR/memwatch.txt.$DAY column terminal format a15 set linesize 460 pagesize 60 trimspool on SELECT (SELECT st.value FROM v\$sesstat st, v\$statname n WHERE st.statistic# = n.statistic# AND n.name = 'consistent gets' AND st.sid = s.sid) consgets, sid, s.serial#, s.username, STATUS, SERVER, SCHEMANAME, OSUSER, PROCESS, MACHINE, s.terminal, s.program, LOGON_TIME, TYPE, MODULE, ACTION, CLIENT_INFO, CLIENT_IDENTIFIER, event, s.sql_id, s.sql_child_number, s.prev_sql_id, s.prev_child_number, service_name, p.spid, p.pga_alloc_mem, p.pga_freeable_mem, p.pga_max_mem, p.pga_used_mem FROM v\$process p, v\$session s WHERE s.paddr = p.addr and TYPE!= 'BACKGROUND' order by consgets desc nulls last; EOFSQL Seite 11

Erster Versuch Shellscript in Datei echo `date` +++++++++++++++ >> $DATADIR/jobwatch.txt.$DAY sqlplus -s "/ as sysdba" << EOFSQL >> $DATADIR/jobwatch.txt.$DAY set linesize 120 pagesize 50 SELECT r.job, r.sid, s.program, j.what FROM (DBA_JOBS_RUNNING r INNER JOIN v\$session s ON r.sid = s.sid) LEFT OUTER JOIN DBA_JOBS j ON (r.job = j.job); EOFSQL Seite 12

Erster Versuch Nicht sehr praktisch in der Auswertung Seite 13

Zweiter Versuch INSERT SELECT CREATE TABLE SESHIST AS SELECT SYSTIMESTAMP TS, s.* from gv$session s where 1=2; crontab einmal die Minute INSERT INTO SESHIST SELECT SYSTIMESTAMP, s.* FROM gv$session s; crontab einmal am Tag um 4 Uhr DELETE FROM SESHIST where ts < SYSTIMESTAMP INTERVAL 14 DAY; COMMIT; Weitere Tabellen: dba_jobs_running gv$process Seite 15

Zweiter Versuch INSERT SELECT Seite 16

Zweiter Versuch INSERT SELECT Seite 17

Zweiter Versuch Fragmentierung der Tabelle 1 2 3 4 5 6 2 3 4 5 6 6 7 3 4 5 6 6 7 8 9 5 6 9 10 7 8 9 10 10 7 8 9 10 11 6 9 9 10 12 8 9 10 11 12 9 12 10 12 9 10 11 12 9 12 Seite 18

Dritter Versuch Partitioning mit Bordmitteln Am Montag: Am Dienstag: Am Montag kurz vor Mitternacht: INSERT INTO ses1 INSERT SELECT INTO ses1 SELECT truncate table ses2; snapid, s.* from gv$session snapid, s s.* from gv$session s DELETE from sessnaps INSERT INTO sessnaps where ts < systimestamp VALUES (snapid, day, ts); INTERVAL 8 DAY; ses 1 proc 1 job 1 ses 2 proc 2 job 2 ses 7 proc 7 job 7 ses snaps Seite 21

Dritter Versuch Partitioning mit Bordmitteln timestamp timestamp timestamp View ses UNION 1-7 View proc UNION 1-7 View job UNION 1-7 ses 1 proc 1 job 1 ses 2 proc 2 job 2 ses 7 proc 7 job 7 ses snaps Seite 22

Dritter Versuch Partitioning mit Bordmitteln timestamp timestamp timestamp Global temporary table myses Global temporary table myproc Global temporary table myjob timestamp timestamp timestamp View ses UNION ALL 1-7 View proc UNION ALL 1-7 View job UNION ALL 1-7 Seite 23

Sessionorie nutzen Arbeitskopie befüllen timestamp Global temporary table myses INSERT INTO myses SELECT * FROM ses WHERE ts BETWEEN TO_TIMESTAMP ('08.08.2013 14:25:00') AND TO_TIMESTAMP ('08.08.2013 15:10:00') ORDER BY ts; timestamp View ses UNION ALL 1-7 JOIN sessnaps ses 1 proc 1 job 1 ses 2 proc 2 job 2 ses 7 proc 7 job 7 ses snaps Seite 24

Blocking Locks Kleine Ursache schnell Vorbei Seite 26

Blocking Locks auch kleinere Störungen Seite 27

Blocking Locks Vorgehen myses mit fraglichem Zeitraum befüllen PROGRAM, MODULE, ACTION, OSUSER SQL aus v$sql Generelle WAIT Event Analyse oder über event like %TX% (enq: TX - row lock contention) BLOCKING_INSTANCE BLOCKING_SESSION FINAL_BLOCKING_INSTANCE FINAL_BLOCKING_SESSION sql_id ermitteln ROW_WAIT_OBJ# ROW_WAIT_BLOCK# ROW_WAIT_ROW# OBJECT_ID in dba_objects select * from table where DBMS_ROWID.ROWID_ BLOCK_NUMBER(rowid) = DBMS_ROWID.ROWID_ RELATIVE_FNO(rowid)= Seite 28

IO Subsystem in Gefahr Direct Path Read Seite 29

Direct path read Full table scan Seite 32

Nach upgrade 11.2 bevorzugt Full table scan direct path Seite 33

IO Subsystem in Gefahr Vorgehen myses mit fraglichem Zeitraum befüllen Auf event= direct path read analysieren (ohne STATE= WAITING ) sql_id ermitteln PROGRAM, MODULE, ACTION, OSUSER aus ses ROW_WAIT_OBJ# aus ses OBJECT_ID in dba_objects SQL aus v$sql Seite 34

PGA Verbrauch Out of memory PGA Verbrauch durch PL/SQL nicht begrenzt In Out-of-Memory-Situationen killt der Kernel Prozesse Beweise werden so vernichtet Seite 35

PGA usage Vorgehen myses und myproc mit fraglichem Zeitraum befüllen sql_id ermitteln SELECT p.ts, p.inst_id, p.addr, p.pga_alloc_mem, p.pga_max_mem, s.* FROM myproc p LEFT OUTER JOIN myses s ON (s.paddr = p.addr AND s.inst_id = p.inst_id AND s.snapid = p.snapid) WHERE pga_alloc_mem > 1024 * 1024 * 1024 ORDER BY p.ts, p.inst_id, pga_alloc_mem DESC SQL aus v$sql PROGRAM, MODULE, ACTION, OSUSER aus ses Seite 36

Long running Statements über sql_exec_start myses mit fraglichem Zeitraum befüllen sql_id ermitteln SELECT ts - sql_exec_start, program, sql_id, sql_child_number, s.* FROM myses s WHERE status = 'ACTIVE' AND TYPE!= 'BACKGROUND' AND sql_exec_start IS NOT NULL ORDER BY ts, inst_id, ts - sql_exec_start DESC SQL aus v$sql PROGRAM, MODULE, ACTION, OSUSER aus ses Seite 37

Long running Statements über statistische Häufung myses mit fraglichem Zeitraum befüllen sql_id ermitteln SELECT ts, inst_id, COUNT (*), sql_id, sql_child_number FROM myses s WHERE status = 'ACTIVE' AND TYPE!= 'BACKGROUND' HAVING COUNT (*) > 5 GROUP BY sql_id, inst_id, ts, sql_child_number ORDER BY ts, inst_id, COUNT (*) DESC SQL aus v$sql PROGRAM, MODULE, ACTION, OSUSER aus ses Seite 38

Anwendungsbeispiel Einbruch in den Transaktionen RAC1 DOAG 2013 Jan Krüger TUI Infotec GmbH 18.11.2013 Page 39

Sessionorie Nutzen Worauf warten die Sessions SELECT ts, inst_id, event, COUNT (*) FROM myses WHERE status = 'ACTIVE' AND state = 'WAITING' AND TYPE!= 'BACKGROUND' HAVING COUNT (*) > 3 GROUP BY ts, inst_id, event ORDER BY ts, inst_id, COUNT (*) DESC; Seite 40

Sessionorie nutzen Was machen die wartenden SELECT * FROM myses WHERE status = 'ACTIVE' AND state = 'WAITING' AND TYPE!= 'BACKGROUND' AND event = 'latch: cache buffers chains' ORDER BY ts, inst_id Seite 41

Worauf warten die Sessions? TOP Event / TOP Objekt TS INST_ID EVENT COUNT(*) 08.08.2013 14:50:01, 1 latch: cache buffers chains 300 08.08.2013 14:50:01, 1 gc buffer busy acquire 253 08.08.2013 14:50:01, 1 TCP Socket (KGAS) 8 08.08.2013 14:50:01, 1 PX Deq: Table Q Normal 8 08.08.2013 14:50:01, 1 PL/SQL lock timer 7 08.08.2013 14:50:01, 1 gc cr request 6 08.08.2013 14:50:01, 1 db file sequential read 6 08.08.2013 14:50:01, 1 PX Deq: Execute Reply 4 Seite 42

Interconnect busy? Global Cache Fusion Seite 43

Consistent Changes im gleichen Zeitraum Seite 44

Consistent Changes nicht sehr gut instrumentiert Aus der Doku von v$sysstat, v$sesstat: consistent changes Number of times a user process has applied rollback entries to perform a consistent read on the block. Work loads that produce a great deal of consistent changes can consume a great deal of resources. The value of this statistic should be small in relation to the "consistent gets" statistic. Seite 45

Statspack liefert einen Verdächtigen TOP buffer get statements SQL ordered by Gets CPU Elapsd Old Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- ---------- 48,318,176 16,319 2,960.9 2.4 318.70 651.94 1599842283 Module: RePriceRequest SELECT 'Y' FROM AR_AQT_CACHE AQ WHERE AQ.USER_DATA.TARGET_ID IN ( :B3, :B2 ) AND AQ.Q_NAME = :B1 AND NOT EXISTS (SELECT 1 FROM AQ$_AR_AQT_CACHE_H DQ WHERE DQ.MSGID = AQ.MSGID AND DQ.DEQUEUE_T IME IS NOT NULL ) Seite 46

Zeitreihenauswertung aus Statspack sql_id des fraglichen Statements SELECT snap_time, executions - LAG (executions) OVER (ORDER BY snap_id) execs, buffer_gets - LAG (buffer_gets) OVER (ORDER BY snap_id) bufgets, ROUND ( (buffer_gets - LAG (buffer_gets) OVER (ORDER BY snap_id)) / (executions - LAG (executions) OVER (ORDER BY snap_id))) getsperexec FROM perfstat.stats$sql_summary s JOIN perfstat.stats$snapshot USING (snap_id) WHERE sql_id IN ('du2nurwg75x8s') AND s.instance_number = 1 AND snap_id BETWEEN 115169 AND 115252 ORDER BY snap_id Seite 47

The missing link Ausführungen folgen dem Tagesverlauf Seite 48

The missing link Transaktionsprofil und SQL Ausführung Seite 49

The missing link Buffergets per second und cache fusion Seite 50

The missing link Mehr gets per exec durch consistent updates Seite 51

Fazit Sessionorie mit Bordmitteln Schnell installiert Resourcenschonend beim Datensammeln Stabil Abdeckung aller Lizenzversionen Liefert in der Praxis häufig Lösung oder zumindest wichtige Hinweise Seite 52

Vielen Dank für Ihre Aufmerksamkeit.