V$DIAG_ALERT_EXT – Neuigkeiten in Oracle Database 12c Release 2

25. August 2017 Aus Von Markus Flechtner

Vor etwas mehr als 3 Jahren habe ich bereits über V$DIAG_ALERT_EXT geschrieben. Mit dem aktuellen Release 12.2 der Oracle Datenbank gibt es einige Neuigkeiten zu diesem Thema.

Der erste wichtige Punkt ist: es gibt V$DIAG_ALERT_EXT jetzt offiziell. Die View ist dokumentiert.

Der zweite Punkt betrifft Instanzen mit einer Container-Datenbank.

Auch in Oracle 12.1 war die Spalte CON_ID Bestandteil der View V$DIAG_ALERT_EXT. Der Wert war aber immer 0. In Oracle 12.2 wird aber die jeweilige Container-ID eingetragen und wenn man aus einer PDB heraus die View abfragt, dann werden nur Meldungen zu dieser PDB angezeigt.

Ich habe ein kleines Skript, mit dem ich mir die Einträge in V$DIAG_ALERT_EXT anzeigen lasse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

oracle@hometest:~/ [TEST] cat view_alert.sql
SET echo off
SET linesize 140
SET pagesize 0
SET verify off
SET feedback off
 
PROMPT ... showing alert.log entries FOR the LAST &1 minutes:
PROMPT =====================================================
SELECT
to_char(originating_timestamp,'YYYY-MON-DD HH24:MI:SS,FF3')||': '
||container_name||': '||substr(message_text,1,60)
FROM v$diag_alert_ext
WHERE ORIGINATING_TIMESTAMP > sysdate-&1/1440
ORDER BY originating_timestamp;
 
pause
 
SET echo ON
SET feedback ON
SET verify ON

Direkt nach dem Start der Instanz sieht die Ausgabe wie folgt aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

SQL> SHOW con_id
1
SQL> @view_alert 3
SQL> SET echo off
... showing alert.log entries FOR the LAST 3 minutes:
=====================================================
2017-AUG-25 13:24:58,751: CDB$ROOT: Starting ORACLE instance (normal) (OS id: 4108)
[..]
 
2017-AUG-25 13:25:08,728: CDB$ROOT: Patch Id: 25811364
2017-AUG-25 13:25:08,728: CDB$ROOT: Patch Description: OJVM RELEASE UPDATE: 12.2.0.1.170718 (258
2017-AUG-25 13:25:08,728: CDB$ROOT: Patch Apply TIME: 2017-07-18T20:27:04+02:00
2017-AUG-25 13:25:08,728: CDB$ROOT: Bugs Fixed: 25811105,25890046,26023042
2017-AUG-25 13:25:08,728: CDB$ROOT: ===========================================================
2017-AUG-25 13:25:08,885: PDB02: Opening pdb WITH no Resource Manager plan active
2017-AUG-25 13:25:08,888: PDB01: Opening pdb WITH no Resource Manager plan active
2017-AUG-25 13:25:08,956: CDB$ROOT: Pluggable DATABASE PDB02 opened READ WRITE
2017-AUG-25 13:25:08,986: CDB$ROOT: Pluggable DATABASE PDB01 opened READ WRITE
2017-AUG-25 13:25:09,084: PDB03: Opening pdb WITH no Resource Manager plan active
2017-AUG-25 13:25:09,143: CDB$ROOT: Pluggable DATABASE PDB03 opened READ WRITE
2017-AUG-25 13:25:09,526: CDB$ROOT: Starting background process CJQ0
2017-AUG-25 13:25:09,560: CDB$ROOT: CJQ0 started WITH pid=46, OS id=4419
2017-AUG-25 13:25:09,560: CDB$ROOT: Completed: ALTER DATABASE OPEN
2017-AUG-25 13:25:09,582: CDB$ROOT: db_recovery_file_dest_size OF 20000 MB IS 17.87% used. This
2017-AUG-25 13:25:09,582: CDB$ROOT: user-specified LIMIT ON the amount OF SPACE that will be USE
2017-AUG-25 13:25:09,582: CDB$ROOT: DATABASE FOR recovery-related files, AND does NOT reflect th
2017-AUG-25 13:25:09,582: CDB$ROOT: SPACE available IN the underlying filesystem OR ASM diskgrou

Man sieht, dass es Einträge zu mehreren Containern gibt.

Wie sieht es nun aus, wenn ich V$DIAG_ALERT_EXT in einer PDB verwende:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SQL> ALTER SESSION SET container=PDB02;
SESSION altered.
 
SQL> ALTER DATABASE datafile '/u01/oradata/TEST/PDB02/users01.dbf' resize 20M;
DATABASE altered.
 
SQL> @view_alert 3
SQL> SET echo off
... showing alert.log entries FOR the LAST 3 minutes:
=====================================================
2017-AUG-25 13:28:31,854: PDB02: ALTER DATABASE datafile '/u01/oradata/TEST/PDB02/users01.
2017-AUG-25 13:28:31,906: PDB02: Resize operation completed for file# 187, old size 5120K, ne
2017-AUG-25 13:28:31,906: PDB02: Completed: alter database datafile '/u01/oradata/TEST/PDB
 
SQL> SET feedback ON
SQL> SET verify ON

Es werden also nur Einträge zur jeweils aktuellen PDB angezeigt.
Man kann also über V$DIAG_ALERT_EXT den PDB-Administratoren einen (eingeschränkten) Zugriff auf die alert.log-Daten geben.

Eine weitere Neuerung ist, dass man via SQL auf die Trace-Dateien zugreifen kann. Dazu gibt es neue V$-Views:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

SQL> DESC V$DIAG_TRACE_FILE
 Name					   NULL?    TYPE
 ----------------------------------------- -------- ----------------------------
 ADR_HOME					    VARCHAR2(444)
 TRACE_FILENAME 				    VARCHAR2(68)
 CHANGE_TIME					    TIMESTAMP(3) WITH TIME ZONE
 MODIFY_TIME					    TIMESTAMP(3) WITH TIME ZONE
 CON_ID 					    NUMBER
 
 SQL> DESC V$DIAG_TRACE_FILE_CONTENTS
 Name					   NULL?    TYPE
 ----------------------------------------- -------- ----------------------------
 ADR_HOME					    VARCHAR2(444)
 TRACE_FILENAME 				    VARCHAR2(68)
 RECORD_LEVEL					    NUMBER
 PARENT_LEVEL					    NUMBER
 RECORD_TYPE					    NUMBER
 TIMESTAMP					    TIMESTAMP(3) WITH TIME ZONE
 PAYLOAD					    VARCHAR2(4000)
 SECTION_ID					    NUMBER
 SECTION_NAME					    VARCHAR2(64)
 COMPONENT_NAME 				    VARCHAR2(64)
 OPERATION_NAME 				    VARCHAR2(64)
 FILE_NAME					    VARCHAR2(64)
 FUNCTION_NAME					    VARCHAR2(64)
 LINE_NUMBER					    NUMBER
 THREAD_ID					    VARCHAR2(64)
 SESSION_ID					    NUMBER
 SERIAL#					    NUMBER
 CON_UID					    NUMBER
 CONTAINER_NAME 				    VARCHAR2(30)
 CON_ID 					    NUMBER
1
2
3
4
5
6
7
8
9

SQL> SELECT TRACE_FILENAME FROM V$DIAG_TRACE_FILE;
TEST_ora_3239.trc
TEST_svcb_3274.trc
TEST_gen0_3254.trc
TEST_tt02_3336.trc
[..]
TEST_lg00_2825.trc
TEST_lg00_3286.trc
TEST_gen0_4147.trc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

SQL> SELECT substr(payload,1,80) FROM V$DIAG_TRACE_FILE_CONTENTS
  2  WHERE trace_filename='TEST_lgwr_2821.trc'
  3  ORDER BY line_number;
Trace file /u00/app/oracle/diag/rdbms/TEST/TEST/trace/TEST_lgwr_2821.tr
Oracle DATABASE 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
Build label:	RDBMS_12.2.0.1.0_LINUX.X64_170125
ORACLE_HOME:	/u00/app/oracle/product/12.2.0.1
System name:	Linux
Node name:	testserver.markusba.net
Release:	3.10.0-514.10.2.el7.x86_64
Version:	#1 SMP Thu Mar 2 11:35:29 PST 2017
Machine:	x86_64
Instance name: TEST
Redo thread mounted BY this instance: 0 
Oracle process NUMBER: 20
Unix process pid: 2821, image: oracle@testserver.markusba.net (LGWR)
 
[..]
 
*** 2017-08-24T22:01:23.028421+02:00 (CDB$ROOT(1))
Adaptive scalable LGWR disabling workers
*** 2017-08-24T22:01:43.880455+02:00 (CDB$ROOT(1))
kcrfw_slave_adaptive_updatemode: single->scalable redorate=687659 switch=116545
*** 2017-08-24T22:01:43.881176+02:00 (CDB$ROOT(1))
Adaptive scalable LGWR enabling workers
*** 2017-08-24T22:06:33.569439+02:00 (CDB$ROOT(1))
Waking up the heartbeat redo informer process
 
34 ROWS selected.

Für Optimizer-Traces etc. gibt es weiterhin noch die neue V$-View V$DIAG_APP_TRACE_FILE

1
2
3
4
5
6
7
8
9
10

SQL> DESC V$DIAG_APP_TRACE_FILE
 Name					   NULL?    TYPE
 ----------------------------------------- -------- ----------------------------
 ADR_HOME					    VARCHAR2(444)
 TRACE_FILENAME 				    VARCHAR2(68)
 CHANGE_TIME					    TIMESTAMP(3) WITH TIME ZONE
 MODIFY_TIME					    TIMESTAMP(3) WITH TIME ZONE
 SQL_TRACE					    VARCHAR2(1)
 OPTIMIZER_TRACE				    VARCHAR2(1)
 CON_ID 					    NUMBER

Leider gibt es dazu keine passende V$-View mit der man sich den Inhalt der Dateien anschauen kann.

MOS-Notes

  • Selects from v$diag_alert_ext Run Slowly with Large Alert Logs (Doc ID 1684140.1)

Links:

Werbung (Amazon-Partner-Link)

Kategorie12cR2 DB-Administration