Identifying Performance Problems in a Multitenant Environment

Size: px

Start display at page:

Download "Identifying Performance Problems in a Multitenant Environment"

Clementine Porter
5 years ago
Views:

1 Identifying Performance Problems in a Multitenant Environment Christian antognini.ch/blog BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENEVA HAMBURG COPENHAGEN LAUSANNE MUNICH STUTTGART VIENNA ZURICH

@ChrisAntognini Senior principal consultant, trainer and

com Focus: get the most out of database engines Logical and

performance management Author of Troubleshooting Oracle

2 @ChrisAntognini Senior principal consultant, trainer and partner at Trivadis Focus: get the most out of database engines Logical and physical database design Query optimizer Application performance management Author of Troubleshooting Oracle Performance (Apress, 2008/14) OakTable Network, Oracle ACE Director

3 Agenda 1. Introduction 2. SQL Trace 3. Dynamic Performance Views 4. AWR 5. Enterprise Manager

4 Introduction

5 Objective of a Performance Analysis Discover the most time-consuming SQL statements or PL/SQL code invocations For each of those time-consuming statements, gather additional information that can help in understanding the problem Execution plan Runtime statistics like the number of processed rows Resource usage profile

6 Basic Questions that Require Answers Is the problem reproducible at will? Yes: everything is much easier than if you can t! SQL Trace For irreproducible problems, is it possible to wait till the problem occurs again? Yes: a real-time analysis has to be carried out Dynamic performance views No: a repository holding historical performance statistics is required AWR

7 Disclaimer I m neither covering basic information about Multitenant, SQL trace, V$ views nor AWR I consider that you know the Multitenant architecture how to use SQL trace, V$ views and AWR This presentation only covers the differences introduced by Multitenant

8 SQL Trace

9 Enabling/Disabling SQL Trace No difference compared to non-multitenant There is also no specific support for Multitenant E.g. no cross container enable/disable The components for which SQL trace was enabled are visible in the root through CDB_ENABLED_TRACES

10 Trace Files Location All PDBs plugged in a given CDB write trace data to the same directory SELECT value FROM v$diag_info WHERE name = 'Diag Trace' Giving selective OS access to that directory is challenging Full access can lead to security issues _TRACE_FILES_PUBLIC can t be set at the PDB level As of 12.2, V$ views like V$DIAG_TRACE_FILE and V$DIAG_TRACE_FILE_CONTENTS can be used instead

11 Trace Files A trace file can contain information about several containers Especially for trace files related to background processes (e.g. PX), whenever possible use TRACEFILE_IDENTIFIER The container and the service that generated the trace data are identified *** SESSION ID:( ) T23:27: :00 *** CLIENT ID:() T23:27: :00 *** SERVICE NAME:(pdb122) T23:27: :00 *** MODULE NAME:(SQL*Plus) T23:27: :00 *** ACTION NAME:() T23:27: :00 *** CLIENT DRIVER:(SQL*PLUS) T23:27: :00 *** CONTAINER ID:(3) T23:27: :

12 TRCSESS It doesn t provide a parameter to select trace data of a specific container A possible workaround is to use the service name trcsess [output=<output file name >] [session=<session ID>] [clientid=<clientid>] [service=<service name>] [action=<action name>] [module=<module name>] <trace file names>

13 TKPROF As of 12.2, it provides the parameter PDBTRACE It s unrelated to Multitenant! It can be used to process a trace file without requiring direct access to the OS where it s stored Trace files can be read through V$ views E.g. V$DIAG_TRACE_FILE and V$DIAG_TRACE_FILE_CONTENTS

14 Dynamic Performance Views

15 CON_ID Identifier present in all V$ views It s value is either 0: instance-level information 1: root container n: id of the container

16 Instance-level Views Some views provide only instance-level statistics CON_ID = 0 E.g. V$OSSTAT V$SGA V$ASH_INFO

17 Instance-level and PDB-level Views Some statistics are provided by level-specific views One view provides cumulative statistics at the instance level (CON_ID = 0) Another view provides statistics at the PDB level E.g. V$(CON_)SYS_TIME_MODEL V$(CON_)SYSSTAT V$(CON_)SYSTEM_WAIT_CLASS, V$(CON_)SYSTEM_EVENT V$(CON_)SYSMETRIC (V$CON views about metrics as of 12.2)

18 Generic Views Some views show different data depending from where they re queried Root: all data PDB: only PDB-relevant data E.g. V$SQL, V$SQL_PLAN_STATISTICS_ALL V$FILESTAT V$SESSION, V$PROCESS CON_ID = 0 is used for background processes

19 Make Queries Compatible with Multitenant CON_ID might need to be added Because of level-specific views, to make queries work at both the instance level and the PDB level, PDB-level views should be used Is it always sensible to do so? Different queries might be better Be very careful in mixing data coming from different levels

20 ASH Reports As of 12.2, when a report is created at the PDB level, the data location can be specified Specify the location of AWR Data ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AWR_ROOT - Use AWR data from root (default) AWR_PDB - Use AWR data from PDB No major difference between these two reports

21 AWR

22 PDB Level Snapshots In 12.1 snapshots are only created at the root level As of 12.2 they can be created at both the root level and the PDB level By default only root-level snapshots are taken Two new sets of views are available: AWR_PDB and AWR_ROOT

23 Enable PDB Level Snapshots Set AWR_PDB_AUTOFLUSH_ENABLED = TRUE Set the snapshot interval dbms_workload_repository.modify_snapshot_settings(interval=>30) In case a CDB has many PDB, set AWR_SNAPSHOT_TIME_OFFSET Note that every container has its own snapshot ids

24 AWR Reports (1) Reports created at the root level are superior As of 12.2, when a report is created at the PDB level, the data location can be specified Specify the location of AWR Data ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AWR_ROOT - Use AWR data from root (default) AWR_PDB - Use AWR data from PDB No major difference between these two reports

25 AWR Reports (2) As of 12.2, when executed at the PDB level, less information is provided (there are less differences in 12.1) PDB level Root level

26 AWR Reports (3) A number of tables also provide the PDB name E.g. SQL ordered by

27 Creating a PDB from a Non-CDB In 12.1, after such an operation, AWR data is no longer accessible But it consumes space Refer to bug# If needed, export the data before the operation takes place

28 Enterprise Manager

29 Multitenant Support In general, the Multitenant support in the performance-related pages is weak 2+ years old tweet

30 Multitenant Support in 13.3 For a number of functionalities Not feasible to focus on a PDB Access to the CDB is required Performance Home The load of a PDB is visible in the Services and PDBs tabs Top Activity PDB name added to some lists No PDB filter in ASH Report

31 Support for PDB Level Snapshots

32 Summary SQL trace No PDB-level trace directory Workflow almost identical V$ views provide expected statistics AWR If possible create reports at the root level Consolidation <> easy Weak Multitenant support in EM

33 Questions and Answers Christian Antognini Senior Principal

Oracle Database 18c New Performance Features

Oracle Database 18c New Performance Features Christian Antognini @ChrisAntognini antognini.ch/blog BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENEVA HAMBURG COPENHAGEN LAUSANNE MUNICH STUTTGART