-
Notifications
You must be signed in to change notification settings - Fork 17
/
xplan_ash.sql
14576 lines (13949 loc) · 793 KB
/
xplan_ash.sql
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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
-- Store current SQL*Plus environment
-- This requires at least a 10.2 SQL*Plus version to work
store set .xplan_settings replace
set echo off verify off termout off timing off define "&" concat "." null "" trimspool on
-- If you need to debug, uncomment the following line
-- set echo on verify on termout on
set doc off
doc
-- ----------------------------------------------------------------------------------------------
--
-- Script: xplan_ash.sql
--
-- Version: 4.24
-- March 2018
--
-- Author: Randolf Geist
-- http://oracle-randolf.blogspot.com
--
-- Description: Single SQL statement execution analysis using ASH (from 10.2 on)
--
-- Furthermore a free-standing SQL wrapper over DBMS_XPLAN. Provides access to the
-- DBMS_XPLAN.DISPLAY_CURSOR / DISPLAY_AWR pipelined function for a given SQL_ID and CHILD_NUMBER (PLAN_HASH_VALUE for DISPLAY_AWR)
--
-- This is a tool for an extended analysis of the data provided by the
-- Runtime Profile (aka. Rowsource Statistics enabled via
-- SQL_TRACE = TRUE, STATISTICS_LEVEL = ALL or GATHER_PLAN_STATISTICS hint)
-- and reported via the ALLSTATS/MEMSTATS/IOSTATS formatting option of
-- DBMS_XPLAN.DISPLAY_CURSOR
--
-- In addition ASH data can be reported for the following purposes:
--
-- 1. Show general information about SQL execution activity
-- 2. Provide activity information per SQL plan line id (11g+)
-- 3. Show distribution of work between Parallel Workers / Query Coordinator / RAC Nodes based on ASH data
--
-- The ASH data options make this a kind of "real time" monitoring tool. Unfortunately the
-- free ASH implementations (and 10g versions) lack the correlation to the SQL plan line id, hence information on plan line level is only
-- possible with the original ASH implementation from 11g onwards
--
-- Note that this script supports in principle other ASH sources - everything can be configured below (S-ASH is now also supported)
--
-- A second configuration set is provided that is based on DBA_HIST_ACTIVE_SESS_HISTORY for running analysis on historic ASH data
-- Although the sample frequency of 10 seconds limits the significance of the analysis it might be much better than nothing at all
--
-- !! The (built-in) ASH reporting requires at least Enterprise Edition plus the Diagnostic Pack license !!
--
-- Versions: This utility will work from version 10.2 and later
-- The ASH based information on plan line level is only available from 11g on (10g has ASH but no relation to SQL execution instances or SQL plan lines)
--
-- Tested with database versions 10.2.0.4, 10.2.0.5, 11.1.0.7, 11.2.0.1, 11.2.0.2 and 11.2.0.3, 11.2.0.4, 12.1.0.1, 12.1.0.2
--
-- Tested with SQL*Plus / client versions 10.2.0.4, 11.1.0.7, 11.2.0.1, 11.2.0.2, 12.1.0.1 including InstantClient 11.2.0.1
--
-- Required: The same access as DBMS_XPLAN.DISPLAY_CURSOR (DISPLAY_AWR) requires. See the documentation
-- of the DBMS_XPLAN package for your Oracle version for more information
--
-- !! The ASH reporting requires at least Enterprise Edition plus the Diagnostic Pack license !!
--
-- In addition the script directly queries
-- 1) (G)V$SESSION
-- 2) GV$SQL_PLAN / GV$SQL_PLAN_STATISTICS_ALL (DBA_HIST_SQL_PLAN)
-- 3) GV$SQL
-- 4) GV$SQL_MONITOR / optionally GV$SQL_PLAN_MONITOR
-- 5) GV$ACTIVE_SESSION_HISTORY (DBA_HIST_ACTIVE_SESS_HISTORY)
-- 6) V$DATABASE
-- 7) GV$SQLSTATS (DBA_HIST_SQLTEXT, SASH_SQLTXT)
-- 8) GV$ASH_INFO (fallback to GV$ACTIVE_SESSION_HISTORY if unavailable)
--
-- Note: This script writes two files during execution (.xplan_ash_temp and .xplan_ash_settings), hence it requires write access to the current working directory
--
-- If you see some error messages similar to the following during execution:
--
-- SP2-0103: Nothing in SQL buffer to run.
--
-- SP2-0110: Cannot create save file ".xplan_ash_temp"
--
-- plan_operations as
-- *
-- ERROR at line 14:
-- ORA-00933: SQL command not properly ended
--
-- plan_operations as
-- *
-- ERROR at line 2:
-- ORA-00900: invalid SQL statement
--
-- then you cannot write to your current working directory
--
-- Credits: Based on the original XPLAN implementation by Adrian Billington (http://www.oracle-developer.net/utilities.php
-- resp. http://www.oracle-developer.net/content/utilities/xplan.zip)
-- and inspired by Kyle Hailey's TCF query (http://dboptimizer.com/2011/09/20/display_cursor/)
--
-- Features: A lot of information about a single SQL execution from Active Session History (and Real-Time SQL Monitoring if available and requested)
-- See below for a more detailed description of the information sections based on ASH / SQL Monitoring
--
-- Furthermore additional columns on execution plan line level, injected into the DBMS_XPLAN.DISPLAY* output
--
-- There are two sources for the additional columns on execution plan line level: Extended Rowsource Statistics and Active Session History/Real-Time SQL Monitoring
--
-- Extended Rowsource Statistics:
--
-- In addition to the PID (The PARENT_ID) and ORD (The order of execution, note that this doesn't account for the special cases so it might be wrong)
-- columns added by Adrian's wrapper the following additional execution plan columns over ALLSTATS are available (see column configuration where it can be customized which to show):
--
-- A_TIME_SELF : The time taken by the operation itself - this is the operation's cumulative time minus the direct descendants operation's cumulative time
-- LIO_SELF : The LIOs done by the operation itself - this is the operation's cumulative LIOs minus the direct descendants operation's cumulative LIOs
-- READS_SELF : The reads performed the operation itself - this is the operation's cumulative reads minus the direct descendants operation's cumulative reads
-- WRITES_SELF : The writes performed the operation itself - this is the operation's cumulative writes minus the direct descendants operation's cumulative writes
-- A_TIME_SELF_GRAPH : A graphical representation of A_TIME_SELF relative to the total A_TIME
-- LIO_SELF_GRAPH : A graphical representation of LIO_SELF relative to the total LIO
-- READS_SELF_GRAPH : A graphical representation of READS_SELF relative to the total READS
-- WRITES_SELF_GRAPH : A graphical representation of WRITES_SELF relative to the total WRITES
-- LIO_RATIO : Ratio of LIOs per row generated by the row source - the higher this ratio the more likely there could be a more efficient way to generate those rows (be aware of aggregation steps though)
-- TCF_GRAPH : Each "+"/"-" sign represents one order of magnitude based on ratio between E_ROWS_TIMES_START and A-ROWS. Note that this will be misleading with Parallel Execution (see E_ROWS_TIMES_START)
-- E_ROWS_TIMES_START : The E_ROWS multiplied by STARTS - this is useful for understanding the actual cardinality estimate for related combine child operations getting executed multiple times. Note that this will be misleading with Parallel Execution
--
-- For the special Rowsource Statistics mode 3 ("_rowsource_statistics_sampfreq" = 3) where only actual cardinalities are measured, XPLAN_ASH from version 3.0 on supports a special FORMAT option "AROWS".
-- This adds a column "A-Rows" (similar to what DISPLAY_CURSOR does when using the *STATS formatting option) since DISPLAY_CURSOR doesn't support this mode properly
-- - it doesn't show the A-Rows in that case although the columns are populated in GV$SQL_PLAN_STATISTICS_ALL
-- Note that you usually want to use "AROWS LAST" similar to "ALLSTATS LAST" if you want to see the actual cardinalities of the last execution
--
-- More information including demos can be found online at http://oracle-randolf.blogspot.com/2011/12/extended-displaycursor-with-rowsource.html
--
-- Active Session History:
--
-- The following information is available based on ASH data (from 11g on). Note that this can be configured in two ways:
-- - The "options" determine what information will be queried / shown in general (see below for more details)
-- - The column configuration can be used to customize exactly which columns to show as part the execution plan output (if available)
--
-- Act : Indicates the most recent active plan lines according to ASH (only applicable if the statement is currently executing)
-- Start : The second this the plan line was active for the first time
-- Dur(T) : Show the number of seconds the plan line is/was active (first sample to last sample)
-- Dur(A) : Show the number of seconds the plan line is/was active (active samples)
-- Time Active Graph : Show a graphical representation of the activity timeline of the plan line
-- Parallel Distribution ASH : Show the Top N processes names along with the number of samples found per SQL plan line id. A trailing "..." indicates that there are more than N processes found (only applicable when Parallel Execution detected). The leading number (for example "5:...") shows the unique number of processes (five in this case) found in the ASH samples for this plan line
-- Parallel Execution Skew ASH : Indicator of data distribution skew - the bigger this graph the more relevant the skew of this execution plan line is to the overall execution time (only applicable when Parallel Execution detected)
-- Avg Act Sess Graph (T) ASH : Show the Average Active Sessions per execution plan line (based on first sample to sample time). This allows to detect temporal skew and data distribution skew, but you need to look at all plan lines that are active at the same time to see if there is skew or not (only applicable when Parallel Execution detected, hidden by default from 4.0 on)
-- Avg Act Sess Graph (A) ASH : Show the Average Active Sessions per execution plan line (based on active samples). This allows to detect temporal skew and data distribution skew, but you need to look at all plan lines that are active at the same time to see if there is skew or not (only applicable when Parallel Execution detected, hidden by default from 4.0 on)
-- Med Act Sess Graph ASH : Show the Median Active Sessions per execution plan line (based on active samples). This allows to detect temporal skew and data distribution skew, but you need to look at all plan lines that are active at the same time to see if there is skew or not (only applicable when Parallel Execution detected, hidden by default from 4.0 on)
-- Activity Graph ASH : Show a graphical representation (CPU + Other activity) of the number of samples against that SQL plan line id relative to the total number of samples
-- Top N Activity ASH : Show the Top N activities (waits or ON CPU) from ASH for that SQL plan line id. A trailing "..." indicates that there are more than N activities found
--
-- The default value for N is 5, but can be changed in the configuration section below, for both "Parallel Distribution ASH" and the "Top N Activity ASH".
-- You can also configure the width of the ASH graphs and the character used for the "Graphs" and "Act" column
--
-- Since version 4.0 Real-Time SQL Monitoring info will be added on execution plan line level if available and requested (see the ASH options below)
--
-- The following columns are available:
--
-- Execs : The number of times this execution plan line was started
-- A-Rows : The actual number of rows generated by this execution plan line
-- PGA : Max. PGA usage of this execution plan operation if applicable, in (K,M,G,E)bytes
-- Temp : Max. Temp usage of this execution plan operation if applicable, in (K,M,G,E)bytes
-- ReadB : Physical I/O read volume of this execution plan operation if applicable, in (K,M,G,E)bytes
-- WriteB : Physical I/O write volume of this execution plan operation if applicable, in (K,M,G,E)bytes
-- CellO% : The Cell Offload Percentage of this operation if applicable
--
-- Row distribution for Parallel Execution
--
-- The column "Parallel Distribution ASH" will have also the Rowcount per Parallel Execution Server added if monitoring info gets used and is available.
-- The Rowcount is added in square brackets to the process, after the number of samples in paranthesis, something like this:
--
-- P012(44)[183K]
--
-- This means process P012 was sampled 44 times for this execution plan line and produced 183K rows according to Real-Time SQL Monitoring
--
-- Note that this information is crucial in understanding Data Distribution Skew and not available from the official Real-Time SQL Monitoring report up to 11.2
-- 12c SQL Monitoring allows to extract this information via the report
--
-- If Real-Time SQL Monitoring information is available (and requested) this column will now show process and rows information even for those processes that are not sampled in ASH
-- In such a case these processes will show up with a sample count of 0 and the leading number indicating the number of processes sampled for this plan line can be less than the processes shown
-- since it refers to ASH sample data, not Real-Time SQL Monitoring
--
-- So this can look like this for example:
--
-- 0:P007(0)[666K],P000(0)[0],P001(0)[0],P002(0)[0],P003(0)[0],...
--
-- Which means that for this plan line no processes were found in the ASH samples, but Real-Time SQL Monitoring information is available - and the processes will be sorted by sample count descending, rows descending
-- Since in above example no ASH samples are found, the processes are effectively sorted by rows descending
--
-- If you find this output messy and want to return to previous behaviour (show only processes from ASH samples) by setting the configuration switch "show_monitor_rowcount" to anything else than the default of "YES"
--
-- Usage: @xplan_ash.sql 1[sql_id|sid=<nnn>[@<inst_id>]] 2[SQL_EXEC_START] 3[SQL_EXEC_ID (SQL_EXEC_END for pre-11g)] 4[*AUTO*|CURR|HIST|MIXED] 5[ON|*OFF*] 6[MONITOR|*ASH*] 7[[*ASH*|LIMITED_ASH][,][*DISTRIB*][,][*MONITOR*][,][*TIMELINE*]|[NONE]] 8[cursor_child_number (plan_hash_value for the historic ASH)] 9[DBMS_XPLAN_format_option] 10[comma_sep_column_list_to_show/hide]
--
-- Parameter 1+8:
--
-- Specify the SQL_ID to be analyzed
--
-- If the SQL_ID is omitted the previously executed SQL_ID and CHILD_NUMBER/PLAN_HASH_VALUE of the current session will be used
--
-- This will be taken either from GV$SESSION (when according to Parameter 7 no ASH should be used) or from Real-Time SQL Monitoring/ASH according to Parameter 6
--
-- Specify a CHILD_NUMBER when referring to CURRent ASH (Parameter 4), specify a PLAN_HASH_VALUE when using the MIXED/HISToric ASH configuration
--
-- Note that when using the ASH functionality (Parameter 7) you usually don't need to specify this parameter:
--
-- If the SQL_ID is specified but the CHILD_NUMBER / PLAN_HASH_VALUE (Parameter 8) is omitted then
-- - If the ASH options are disabled then CHILD_NUMBER 0 is assumed
-- - If ASH / Real-Time SQL Monitoring should be queried, the corresponding CHILD_NUMBER / PLAN_HASH_VALUE will be looked up based on the remaining options specified
--
-- This means that the CHILD_NUMBER should only be specified when using the Rowsource Statistics mode only without ASH
--
-- If instead of a SQL_ID SID=<nnn>[@<inst_id>] is specified as first argument, the most recently executed SQL_ID of the corresponding SID will be taken from either:
-- - Active Session History or Real-Time SQL Monitoring (see Parameter 6 below) when ASH functionality should be used (Parameter 7)
-- - GV$SESSION when ASH functionality should not be used (NONE as Parameter 7)
--
-- Optionally the SID's instance can be specified for RAC
--
-- Note that the SID needs to be either a Query Coordinator's SID for Parallel Execution or a normal, serial session
-- SIDs of Parallel Execution Servers won't work
--
-- This version does not support processing multiple child cursors like DISPLAY_CURSOR / AWR is capable of
-- when passing NULL as CHILD_NUMBER / PLAN_HASH_VALUE to DISPLAY_CURSOR / AWR. Hence a CHILD_NUMBER / PLAN_HASH_VALUE is mandatory, either
-- implicitly generated (see above) or explicitly passed
--
-- RAC: A note to RAC users below 11.2.0.2: If the current instance was *not* involved in executing the SQL, and the execution plan should be displayed from the Shared Pool (CURR option), in best case the execution plan cannot be found
-- In worst case an incorrect plan will be associated from the local instance Shared Pool (You could have the same SQL_ID / CHILD_NUMBER with different plans in different RAC instances).
-- Therefore you need to be careful with cross-instance / remote-instance executions in RAC
-- Why? The tool relies on DBMS_XPLAN.DISPLAY_CURSOR for showing the execution plan from the Shared Pool - but DISPLAY_CURSOR is limited to the local Shared Pool
--
-- From 11.2.0.2 on a workaround is implemented that can "remotely" execute DBMS_XPLAN.DISPLAY_CURSOR on the RAC instance where the correct plan should be in the Library Cache
--
-- Parameter 2+3:
--
-- For 11g+:
-- SQL_EXEC_START: This is required if you're looking for a specific execution instance of a statement in ASH instead of the most recent. It is a date in format "YYYY-MM-DD-HH24:MI:SS" (date mask can be changed in the configuration section, and optional date masks are now supported, see "dm_opt1"/"dm_opt2" configuration parameter)
-- SQL_EXEC_ID : Also required for the same purpose (defaults to 16777216 if omitted and SQL_EXEC_START is specified, this default can be changed in the configuration section)
--
-- Note that since version 4.0 XPLAN_ASH tries different optional date masks if the default mask doesn't work, this is just to simplify copy&pasting of dates
-- The list of optional date masks can be found in the configuration parameter "dm_opt1/dm_opt2". Feel free to add your favorite date masks there
--
-- Furthermore since version 4.0, if SQL_EXEC_START was specified but SQL_EXEC_ID is left blank and version is 11g+, then a default SQL_EXEC_ID of 16777216 will be used
-- This default SQL_EXEC_ID can be changed - if you have a RAC environment with multiple instances this might make sense to change (configuration parameter "default_sql_exec_id")
--
-- If these two are omitted and the SID and previous session execution cases don't apply then the last execution is searched in either GV$SQL_MONITOR (MONITOR) or GV$ACTIVE_SESSION_HISTORY (the default ASH option, see Parameter 6)
-- The latter option is required if no Tuning Pack license is available, the former option can be used to make sure that the script finds the same latest execution instance as the Real-Time SQL Monitoring
--
-- This information is used as filter on SQL_EXEC_START and SQL_EXEC_ID in ASH. Together with the SQL_ID it uniquely identifies an execution instance of that SQL
--
-- For 10.2:
-- SQL_EXEC_START: This is always mandatory and determines the start samples in ASH. It is a date in format "YYYY-MM-DD-HH24:MI:SS" (date mask can be changed in the configuration section)
-- SQL_EXEC_END : This is always mandatory and determines the end samples in ASH. It is a date in format "YYYY-MM-DD-HH24:MI:SS" (date mask can be changed in the configuration section)
--
-- For 10.2 these two are mandatory since an exact SQL execution instance cannot be identified in pre-11g ASH data
--
-- See above for SQL_EXEC_START - version 4.0 tries the same optional date masks at SQL_EXEC_END in case of 10g
--
-- Note that from version 3.0 on by default XPLAN_ASH searches for the earliest / latest sample of the identified SQL_ID within the given SQL_EXEC_START / SQL_EXEC_END time period
-- This means you can be lazy and specify a "rough range" of time where you believe the SQL_ID was active and XPLAN_ASH will automatically determine the exact range
-- However, since there is no concept of distinguishing different executions the range identified automatically by XPLAN_ASH might cover multiple executions of the same SQL_ID
--
-- This behaviour can be controlled via the configuration switch "find_min_sample_10g", see the configuration section below
-- When setting that switch != YES the pre-3.0 behaviour will be used that uses the exact given SQL_EXEC_START / SQL_EXEC_END for further processing
--
-- Parameter 4:
--
-- This determines the configuration set to use. The default is AUTO, which means that the script automatically chooses either CURR (V$ACTIVE_SESSION_HISTORY / V$SQL_PLAN) or HIST (DBA_HIST_ACTIVE_SESS_HISTORY / DBA_HIST_SQL_PLAN).
--
-- AUTO at present only works if an SQL_EXEC_START (Parameter 2) is specified. If SQL_EXEC_START is left blank, AUTO means search in CURR for the last execution.
--
-- If SQL_EXEC_START is specified AUTO determines the earliest sample in V$ACTIVE_SESSION_HISTORY and uses either CURR or HIST.
--
-- Other options include:
--
-- Specify CURR if the current ASH from GV$ACTIVE_SESSION_HISTORY should be used or the historic information from DBA_HIST_ACTIVE_SESS_HISTORY (HIST)
--
-- This also means that the CURRent configuration will use the Library Cache to get the plan (DBMS_XPLAN.DISPLAY_CURSOR), but the HIST configuration will use DBMS_XPLAN.DISPLAY_AWR to obtain the execution plan
--
-- There is also a configuration for taking the plan from AWR (DBMS_XPLAN.DISPLAY_AWR) but taking the sample data from current ASH (GV$ACTIVE_SESSION_HISTORY): MIXED
--
-- Note that you can abbreviate this option (e.g. a or A for AUTO, cu for CURR etc.)
--
-- Parameter 5:
--
-- Allows to enable/disable the EXPERIMENTAL stuff (see below for a detailed description)
-- Default is don't show EXPERIMENTAL (OFF), specify ON to have it shown
--
-- Note that you can abbreviate this option (e.g. y for YES)
--
-- Parameter 6:
--
-- For 11g+:
-- MONITOR or ASH: Determines where to search for the last execution. By default the script uses ASH.
--
-- This is only applicable if no SQL_EXEC_START / SQL_EXEC_ID is specified, or no SQL_ID at all (or a SID is specified in Parameter 1 and ASH should be used according to Parameter 7, see next argument)
--
-- Note that the scripts queries both GV$SQL_MONITOR and GV$ACTIVE_SESSION_HISTORY to determine the last execution if no SQL_EXEC_START / SQL_EXEC_ID was specified
--
-- !! If you don't have a Tuning Pack license but haven't disabled it in the CONTROL_MANAGEMENT_PACK_ACCESS parameter this query might show up as a Tuning Pack feature usage !!
--
-- Note that you can abbreviate this option (e.g. m for MONITOR)
--
-- Parameter 7:
--
-- The next argument allows specifying if ASH activity, Parallel Distribution and/or Activity Timeline information as well as Real-Time SQL Monitoring info on execution plan line level should be displayed:
--
-- [[*ASH*|LIMITED_ASH][,][*DISTRIB*][,][*MONITOR*][,][*TIMELINE*]|[NONE]]
--
-- Use the LIMITED_ASH option to avoid long running XPLAN_ASH queries when analyzing long running statements - usually only required when the session lacks the ALTER SESSION privilege
-- This will avoid the two sections that take most of the time, see below
--
-- Note that you can abbreviate this option (e.g. a,d,t for ASH,DISTRIB,TIMELINE)
--
-- The following sections of the output will always be shown if any of options ASH, DISTRIB or TIMELINE is specified:
-- - SQL statement execution ASH Summary
-- - SQL statement execution ASH Summary per Instance (if Cross Instance Parallel Execution is detected)
-- - Activity on execution plan line level (Enterprise Edition + Diagnostics Pack + 11g+)
--
-- ASH specific output:
-- - Summary of this session's other activity
-- - Other activity details
-- - Global ASH Summary for concurrent activity ==> skipped in case of the LIMITED_ASH option
-- - Concurrent activity Summary (not this execution) ==> skipped in case of the LIMITED_ASH option
-- - Concurrent activity top SQL_IDs ==> skipped in case of the LIMITED_ASH option
-- - Concurrent activity I/O Summary based on ASH (only if Experimental mode enabled and 11.2+, enabled by default from 11.2.0.3 on) ==> skipped in case of the LIMITED_ASH option
-- - Concurrent activity I/O Summary per Instance based on ASH (only if Experimental mode enabled and 11.2+, enabled by default from 11.2.0.3 on) ==> skipped in case of the LIMITED_ASH option
-- - SQL Statement I/O Summary based on ASH (only if Experimental mode enabled and 11.2+, enabled by default from 11.2.0.3 on)
-- - SQL Statement I/O Summary per Instance based on ASH (only if Cross Instance Parallel Execution is detected and Experimental mode enabled and 11.2+, enabled by default from 11.2.0.3 on)
-- - Activity Class Summary
-- - Activity Class Summary per Instance (if Cross Instance Parallel Execution is detected)
-- - Activity Summary
-- - Activity Summary per Instance (if Cross Instance Parallel Execution is detected)
--
-- DISTRIB specific output:
-- - Information on Parallel Degree based on ASH (only if execution plan is available)
-- - Parallel Worker activity overview based on ASH (only if Parallel Execution is detected)
-- - Activity Timeline based on ASH (both DISTRIB or TIMELINE)
--
-- TIMELINE specific output:
-- - Activity Timeline based on ASH (both DISTRIB or TIMELINE)
--
-- MONITOR specific output:
-- - Real-Time SQL Monitoring Execution Summary
-- - Actual bind values from Real-Time SQL Monitoring
--
-- The options specified also determine the additional columns available on execution plan line level:
--
-- ASH : Show "Act", "Activity Graph ASH" and "Top N Activity ASH" columns per SQL plan line id (default)
--
-- DISTRIB : Show Parallel Distribution info based on ASH: Top N Parallel Processes, Parallel Distribution Graph and Average/Median Active Sessions Graphs per SQL plan line id
--
-- TIMELINE : Show the Start Active, Duration and Time Active Graph columns based on ASH data (default)
--
-- MONITOR : Show the "Execs", "A-Rows", "CellO%", "PGA", "TEMP", "ReadB", "WriteB" (the latter four in bytes) columns. These are taken from Real-Time SQL Monitoring info if available
--
-- NONE : Do nothing of above (for example if you only want the Rowsource Statistics information)
--
-- Note that Parameter 10 allows finer control over which columns should be shown on execution plan line level
--
-- Parameter 9:
--
-- The default formatting option for the call to DBMS_XPLAN.DISPLAY_CURSOR / AWR is TYPICAL +OUTLINE +ALIAS +PEEKED_BINDS
--
-- For the special Rowsource Statistics mode 3 ("_rowsource_statistics_sampfreq" = 3) where only actual cardinalities are measured, XPLAN_ASH from version 3.0 on supports a special FORMAT option:
--
-- AROWS
--
-- This adds a column "A-Rows" (similar to what DISPLAY_CURSOR does when using the *STATS formatting option) since DISPLAY_CURSOR doesn't support this mode properly
-- - it doesn't show the A-Rows in that case although the columns are populated in GV$SQL_PLAN_STATISTICS_ALL
--
-- Note that you usually want to use "AROWS LAST" similar to "ALLSTATS LAST" if you want to see the actual cardinalities of the last execution.
--
-- Parameter 10:
--
-- Defines the column list to show on execution plan line level. Use a comma-separated list of columns with no whitespace inbetween.
-- The available list of columns can be found below in the configuration section.
--
-- Alternatively you can also specify which columns *not* to show by using a minus sign in front of the column names
--
-- Since version 4.0 there is a new option to the column list parameter: Column names can be preceded with a + sign, which means that these columns will be shown
-- in addition to the default column list, for example "+MAS_GRF" would show the median active sessions column in addition to the default columns on execution plan line level
--
-- The default is to show all columns that are configured in the configuration sections of the script (by default all columns except "average active sessions (active)" and "median active sessions")
--
-- Note: You need a veeery wide terminal setting for this if you want to make use of all available columns on execution plan line level (e.g. format option ALLSTATS ALL), something like linesize 800 should suffice
--
-- Some ideas how you can handle these long lines:
--
-- - If you're on Windows the CMD.EXE does a good job - just set the "Width" in "Screen Buffer Size" under "Properties" to 800 and you should be fine. The columnar selection of CMD.EXE is also helpful for tracking
-- the long lines, for example if you are on the right hand side of the execution plan output and want to see which operations belong to that, just highlight the line and while highlighting move to the left
--
-- So the easiest way to handle the long lines is to use SQLPLUS.EXE from a Windows client under CMD.EXE to connect to the target database and run XPLAN_ASH
--
-- - PuTTy and most other terminal emulators don't offer horizontal scrolling, so under Unix/Linux things are bit more complicated
--
-- - Again under Windows you could use Cygwin (32bit) and run the "Bash shell" under the CMD.EXE interface, so you can follow above "Properties" settings and you should be fine.
-- You could use then command line SSH instead of PuTTy to benefit from that interface on remote SSH sessions
--
-- - "Terminator" (https://code.google.com/p/jessies/wiki/Terminator) is one of the few terminal emulators that offers horizontal scrolling. Since it offers some other cool features and is free, why not give it a try?
--
-- - If you need to handle long lines when using a terminal emulator/interface not capable of horizontal scrolling, you can make use of the following tips:
--
-- - Since version 4 of XPLAN_ASH you can spool the output to a file using the SQLPLUS SPOOL command. Starting with version 4.1 XPLAN_ASH itself does a SET TRIMSPOOL ON, in version 4.0(1) you should do that yourself, although not required
-- The spooled file can the be transferred to a machine where you can handle long lines, or be opened with some text editor capable of handling long lines on the target machine
--
-- - If the Unix LESS command is available - use LESS -S to handle long lines. You can use the cursor keys to scroll to left / right in that mode
--
-- - You could also do some fancy Unix stuff, for example copy the SQLPLUS terminal output via TEE to a file, and open the file using LESS -S +F in another session.
-- Running LESS in that mode allows switching between scroll right/left mode using cursor keys and tailing the file via Control+C / Shift+F
--
-- This tool is free but comes with no warranty at all - use at your own risk
--
-- The official blog post for version 1.0 of the tool can be found here:
--
-- http://oracle-randolf.blogspot.com/2012/08/parallel-execution-analysis-using-ash.html
--
-- It contains a complete description along with the command line reference, notes and examples
--
-- The official blog post for version 2.0 of the tool can be found here:
--
-- http://oracle-randolf.blogspot.com/2012/10/new-version-of-xplanash-utility.html
--
-- It explains all the new sections and features of 2.0
--
-- The official blog post for version 3.0 of the tool can be found here:
--
-- http://oracle-randolf.blogspot.com/2013/05/new-version-of-xplanash-tool-video.html
--
-- It includes links to a multi-part video tutorial explaining version 3.0
--
-- The official blog post for version 4.0 of the tool can be found here:
--
-- http://oracle-randolf.blogspot.com/2013/12/new-version-of-xplanash-utility.html
--
-- It includes a link to a video tutorial explaining the new features of version 4.0
--
-- You can find all related posts following this link:
-- http://oracle-randolf.blogspot.com/search/label/XPLAN_ASH
--
-- The latest version can be downloaded here:
-- https://github.com/randolfgeist/oracle_scripts/raw/master/xplan_ash.sql
--
-- Experimental: There is a global switch _EXPERIMENTAL at the beginning of the configuration section below.
-- By default this is disabled because the stuff shown could be called "unreliable" and potentially "misleading" information.
--
-- From version 3.0 on this can be now controlled via an additional command line parameter specifying one of (ON, TRUE, YES) should do the job of enabling it
--
-- If you enable it (either by setting the configuration switch to an empty string or via command line), the I/O figures from the ASH data (only from 11.2+ on)
-- will be shown at various places of the report. Note that this data is unreliable and usually falls short of
-- the actual activity (I've never seen it reporting more than the actual activities). Since sometimes unreliable
-- figures can be much better than nothing at all you can enable it that in cases where you want for example get an
-- idea if the I/O was in the range of MBs or GBs - this is something you should be able to tell from the ASH data.
--
-- Note that from version 11.2.0.3 on the I/O figures are shown by default since it looks like the data got more reliable with that release
-- You'll still see missing data for short running queries but for longer running queries the data seems to be pretty accurate
--
-- Likewise the average and median wait times from ASH will be shown at different places of the report if experimental is turned on.
-- Note that these sampled wait times tend to emphasize longer lasting wait events, so you need to be aware of that this never corresponds to
-- to the true aggregated values you would see from tracing - the aggregated sampled wait times always will show (much) higher averages etc.
-- Doing statistical analysis based on such sampled wait times is sometimes called "Bad ASH math", but again, if you know what you are doing
-- and keep telling yourself what you're looking at, there might be cases where this information could be useful, for example, if you see that
-- hundreds or thousands of those waits were sampled with a typical wait time of 0.5 secs where you expect a typical wait time of 0.005 secs.
-- This might be a good indication that something was broken or went wrong and could be worth further investigation.
--
-- Change Log:
--
-- 4.24: March 2018
-- - Just a few minor fixes when dealing with DBA_HIST_ACTIVE_SESS_HISTORY based data
--
-- 4.23: June 2016
-- - Finally corrected the very old and wrong description of "wait times" in the script comments, where it was talking about "in-flight" wait events but that is not correct
-- ASH performs a "fix-up" of the last 255 samples or so and updates them to the time waited, so these wait events are not "in-flight"
--
-- - Removed some of the clean up code added in 4.22 to the beginning of the script, because it doesn't really help much but spooled script output always contained these error messages about non-existent column definitions being cleared
--
-- - The "Concurrent I/O" sections will now also be skipped in LIMITED_ASH mode
--
-- - Some more fixes to the I/O figures in the "Activity Timeline based on ASH" - the spreading introduced in 4.22 needed some further refinement (see 4.22 change log for more details)
--
--
-- 4.22: November 2015
-- - Fixed a funny bug that in 12c they have forgotton to add the DELTA_READ_MEM_BYTES to DBA_HIST_ACTIVE_SESS_HISTORY, so in HIST mode with 12c prior XPLAN_ASH versions could error out with invalid column name
--
-- - Change the way the I/O figures are treated in the "Activity Timeline based on ASH". Now the I/O per second is spread over the (previous) samples covered by DELTA_TIME
-- This should give a smoother representation of the I/O performed and much closer to what you see in Real-Time SQL Monitoring reports
-- The difference to prior versions is only visible in cases where a session wasn't sampled for quite a while and hence has a DELTA_TIME spanning multiple previous sample points
-- This also means that the I/O related columns in the "Activity Timeline based on ASH" now show only the PER SECOND values, no longer to the totals like prior versions
--
-- - Added a SET NULL "" in the configuration and initialization section for SQL*Plus environments that use a non-default SET NULL setting
-- This screwed up some internal switches so that XPLAN_ASH for example thought it's running in a S-ASH repository
--
-- - Added a note to the end of the output if no execution plan could be found and falling back to retrieving plan operation details from ASH. Also added the note to use MIXED or HIST ASH source option
-- if no execution plan could be found in CURR mode, so execution plan has been purged from Shared Pool in the meanwhile
--
-- - Cloned the "cleanup" section from the end to the beginning of the script to ensure no current SQL*Plus environment settings influence the script execution
-- This is particularly relevant if the script execution gets cancelled before the final cleanup section is reached or some other, previous scripts left a mess behind
--
-- 4.21: January 2015
-- - Forgot to address a minor issue where the SET_COUNT determined per DFO_TREE (either one or two slave sets) is incorrect in the special case of DFO trees having only S->P distributions (pre-12c style)
-- Previous versions used a SET_COUNT of 2 in such a case which is incorrect, since there is only one slave set. 12c changes this behaviour with the new PX SELECTOR operator and requires again two sets.
--
-- - For RAC Cross Instance Parallel Execution specific output some formatting and readability was improved (more linebreaks etc.)
--
-- - Minor SQL issue fixed in "SQL statement execution ASH Summary" that prevented execution in 10.2 (ORA-32035)
--
-- - The NO_STATEMENT_QUEUING hint prevented the "OPTIMIZER_FEATURES_ENABLE" hint from being recognized, therefore some queries failed in 11.2.0.1 again with ORA-03113. Fixed
--
-- - "ON CPU" now distinguishes between "ON CPU INMEMORY" and "ON CPU" for inmemory scans
--
-- 4.2: December 2014
-- - New sections "Concurrent activity I/O Summary based on ASH" and "Concurrent activity I/O Summary per Instance based on ASH" to see the I/O activity summary for concurrent activity
--
-- - Bug fixed: When using MONITOR as source for searching for the most recent SQL_ID executed by a given SID due to some filtering on date no SQL_ID was found. This is now fixed
--
-- - Bug fixed: In RAC GV$ASH_INFO should be used to determine available samples
--
-- - The "Parallel Execution Skew ASH" indicator is now weighted - so far any activity level per plan line and sample below the actual DOP counted as one, and the same if the activity level was above
-- The sum of the "ones" was then set relative to the total number of samples the plan line was active to determine the "skewness" indicator
--
-- Now the actual difference between the activity level and the actual DOP is calculated and compared to the number of total samples active times the actual DOP
-- This should give a better picture of the actual impact the skew has on the overall execution
--
-- - Most queries now use a NO_STATEMENT_QUEUING hint for environments where AUTO DOP is enabled and the XPLAN_ASH queries could get queued otherwise
--
-- - The physical I/O bytes on execution plan line level taken from "Real-Time SQL Monitoring" has now the more appropriate heading "ReadB" and "WriteB", I never liked the former misleading "Reads"/"Writes" heading
--
-- - Many averages and medians now also have accompanying minimum and maximum values shown. This isn't as good as having histograms but gives a better idea of the range of values,
-- and how outliers might influence the averages and deserve further investigations
--
-- 4.1: June 2014
-- - GV$SQL_MONITOR and GV$SQL_PLAN_MONITOR can now be customized in the settings as table names in case you want to use your own custom monitoring repository that copies data
-- from GV$SQL_MONITOR and GV$SQL_PLAN_MONITOR in order to keep/persist monitoring data. The tables need to have at least those columns that are used by XPLAN_ASH from the original views
--
-- - The "Activity Timeline based on ASH" for RAC Cross Instance Parallel Execution shows an additional line break for the GLOBAL summary
--
-- - Fixed various bugs related to some figures when analyzing Cross Instance RAC Parallel Execution
--
-- - The new "GLOBAL" aggregation level for Cross Instance RAC Parallel Execution (see version 4.0 change log below) is now also shown in the "Information on Parallel Degree based on ASH" section
--
-- - The "Parallel Distribution ASH" column on execution plan line level now can show process information taken from Real-Time SQL Monitoring for those processes that are not found in ASH samples
-- This effectively means that with monitoring information available for every plan line every involved process will now be shown along with its ASH sample count and rows produced
-- So some processes will show up now with a sample count of 0.
-- The idea behind this is to provide more information about row distribution even for those lines/processes that are not covered in the ASH samples
-- Previously the rowcount produced was only shown for those processes covered in ASH samples
-- See above section "Row distribution for Parallel Execution" for more details
--
-- The new behaviour is default - if you find the output messy you can return to previous behaviour (show only rowcounts for processes found in ASH samples) by setting the new configuration switch
-- "show_monitor_rowcount" to any other value than the default of "YES"
--
-- - The "Real-Time SQL Monitoring" information on execution plan line level now includes the read and write request information ("ReadReq", "WriteReq")
--
-- - The I/O figures based on ASH now include the new "DELTA_READ_MEM_BYTES" information that was added in 12c. This applies to the following sections:
-- - SQL Statement I/O Summary based on ASH
-- - Parallel Worker activity overview based on ASH
-- - Activity Timeline based on ASH
--
-- The "Read Mem Bytes" seems to correspond to the "logical read bytes from cache" statistics, so any direct path reads are not covered by this value
--
-- - Added some more verbose description above in the "Note" sections how to handle long lines. XPLAN_ASH now does a SET TRIMSPOOL ON if you want to spool the output to a file
--
-- - Whenever the output referred to DFOs this was changed to "DFO TREE", which is the correct term
--
-- - The "Parallel Worker activity overview based on ASH" section now shows a blank line between the sections which should make this section more readable
--
-- - Adaptive plans are now supported by XPLAN_ASH
--
-- Note they don't work well with previous versions, the formatting of the inactive lines breaks and the overall information can
-- be misleading if you don't add manually the "ADAPTIVE" formatting option
--
-- If XPLAN_ASH detects an adaptive plan, it will always force the ADAPTIVE formatting option
-- This also means that Adaptive plans for the time being won't work with SASH as SASH doesn't collect the OTHER_XML column from GV$SQL_PLAN
-- You could manually add that column to SASH_SQLPLANS and add the column to the "sash_pkg.get_sqlplans" procedure - this is a CLOB column, but INSERT / SELECT should work I think
-- The view SASH_PLAN_TABLE needs also to be modified to select the OTHER_XML column instead of a dummy NULL
--
-- Although this output is less readable than the "faked" output that shows only the plan operations that are actually in use,
-- it is the only simple way how ASH/MONITOR data can be related to execution plan lines, as these hold the information with the actual plan line
-- not the one that is made up by DBMS_XPLAN.DISPLAY* based on the DISPLAY_MAP information in the OTHER_XML column
--
-- Hence I decided for the time being to use the same approach as 12c Real-Time SQL Monitoring and always show the full/adaptive shape of the plan
--
-- Another challenge for XPLAN_ASH with adaptive plans is the possibly changing PLAN_HASH_VALUE during execution
--
-- XPLAN_ASH extracts the PLAN_HASH_VALUE from ASH/MONITOR when trying to get the plan from DBA_HIST_SQL_PLAN
--
-- Hence XPLAN_ASH now needs to take care to extract the most recent PLAN_HASH_VALUE, previously it didn't matter as it wasn't supposed to change during execution
-- This seems to work based on my tests, but it's something to keep in mind
--
-- - The new "gather stats on load" 12c feature implies for INSERT...SELECT statements that the cursor will immediately be invalidated/removed from the Library Cache
-- after (successful) execution. So now such INSERT...SELECT behave like CTAS which also gets removed immediately. This is a pity as you won't be able to pick up
-- the plan from the Library Cache after the execution completes using XPLAN_ASH (or any other tool using DBMS_XPLAN.DISPLAY*).
--
-- Although V$SQL_PLAN_MONITOR might keep plan for some time after the execution, it can't be used as input to DBMS_XPLAN.DISPLAY*, hence this isn't a viable workaround
-- In principle however this isn't a good thing as the SQL and plan information might be missing from AWR / STATSPACK reports due to the immediate invalidation/removal
--
-- At the time being the only viable workaround known to me for this is to prevent the "gather stats on load" feature either via parameter "_optimizer_gather_stats_on_load"
-- or hint "no_gather_optimizer_statistics", or via using pre-12c optimizer feature settings which implicitly disables the feature
-- which is of course not really a good workaround as the feature itself might be rather desirable
--
--
-- 4.01: March 2014
-- - More info for RAC Cross Instance Parallel Execution: Many sections now show a GLOBAL aggregate info in addition to instance-specific data
--
-- - The Parallel Execution Server Set detection and ASSUMED_DEGREE info now makes use of the undocumented PX_STEP_ID and PX_STEPS_ARG info (bit mask part of the PX_FLAGS column)
-- on 11.2.0.2+
--
-- - Since version 4.0 added from 11.2.0.2 on the PX *MAX* DOP in the "SQL statement execution ASH Summary" based on new PX_FLAGS column of ASH
-- it makes sense to add a PX *MIN* DOP in the summary to see at one glance if different DOPs were used or not
--
-- - The "Active DOPs" column in the "Activity Timeline based on ASH" was extended/modified: The number in parantheses is no longer the simple count of samples
-- but the Average Active Sessions (AAS) per DFO / bucket. From 11.2.0.2 it now shows also the DOP of the DFO in brackets, so the output could look now like this:
--
-- 1[16] (14.5)
--
-- which means DFO 1 at a DOP of 16 had an AAS value of 14.5 for this time bucket. If there are multiple DFOs active in the time bucket, they are separated by commas:
--
--
-- 1[16] (3.5),2[4] (1.5)
--
-- which means DFO 1 at a DOP of 16 had an AAS value of 3.5 and DFO 2 at a DOP of 4 had an AAS value of 1.5 for this time bucket
--
-- - The "Real-Time SQL Monitoring Execution Summary" section now shows a PX *MIN* DOP information, too, based on the monitoring information.
-- Note that from version 11.2 on there is a column PX_MAXDOP, but no PX_MINDOP column. So from version 11.2 on for PX_MAXDOP the column value will be used.
-- For pre-11.2 versions the PX_MAXDOP is calculated using an analytic function on the monitoring data
-- In the same way the PX_MINDOP information is now calculated in all versions that support monitoring
--
-- Please note that both PX_MAXDOP and PX_MINDOP can be unreliable in 11.1 when the execution plan consists of multiple DFOs
-- I just realized that my wording might be misleading - "DFOs" are probably better called "DFO trees" - so please consider "DFO trees" whenever reading "DFOs" here
--
-- 4.0: December 2013
-- - New MIN/MAX figures when showing I/O related analysis. Useful if you want to see peak throughput information (e.g. Exadata)
--
-- - Determining the start time of the script execution was changed. The previous implementation lead to misleading results when the execution of the initialization steps
-- took extraordinarily long
--
-- - The version specific code switches were actually not working correctly with version 12. This is fixed now
--
-- - The different DISTRIB* parameters are all now deprecated. There is a common handling of the Parallel Distribution Graph based on the former DISTRIB_TIM option
-- The Graph now is turned into a simple "indicator" that hopefully gives a reasonable indication how much that execution plan line is affected by skew of any kind
-- Note that this now includes temporal skew - you no longer need to check the Average/Median Active Sessions on execution plan line level for that
--
-- For the same reason the column on execution plan line level is now called "Parallel Execution Skew ASH" instead of "Parallel Distribution Graph ASH"
--
-- - The command line parameters were reordered: All ASH related parameters come now first, all Rowsource Statistics related come last
--
-- - The default formatting for DBMS_XPLAN was changed to "TYPICAL +OUTLINE +ALIAS +PEEKED_BINDS"
--
-- - The default date formatting mask was changed to have no spaces so that the date literals can be typed at the command line without the need to add double quotes around
--
-- - New ASH sections for activities of the current session that are not related to the SQL_ID analyzed but happen during first sample to last sample of the given SQL_ID
-- - Summary of this session's other activity
-- - Other activity details
-- This should cover recursive SQL activity (typically issued by user-defined PL/SQL functions called as part of SQL execution, but could also be SYS recursive stuff)
-- But could also be caused by multiple open cursors of the session, executing/fetching from one or the other
--
-- - New "Top N SQL_IDs" ASH section for concurrent activity
--
-- This section shows the SQL text (if available) along with some more details about the top N SQL_IDs found (according to sample count)
--
-- The N can be configured in the configuration section: "topn_sqlid"
--
-- This section requires to query either GV$SQLSTATS resp. DBA_HIST_SQLTEXT to obtain the SQL text
--
-- - The Median Active Sessions is now available in addition to the Average (Mean) Active Sessions indicator
-- If these two differ significantly then you should carefully check the analysis as it might indicate that the Mean is misleading
-- Note that there are still cases where both don't clearly indicate a problem with Parallel Execution Skew
--
-- Median usually shows the "typical" active sessions and therefore is often more useful than the arithmetic Mean
--
-- - There are new columns available in the ASH sections that report the percentage of Ys in the following columns of ASH data (only available from 11g on):
-- IS_SQLID_CURRENT Only available from 11.2 on. Can be used as an additional indicator how much activity was caused by some action not related to the current SQL_ID. See also new "other activity" sections
--
-- IN_CONNECTION_MGMT These columns can be used as some kind of TIME_MODEL information, however they don't need to add up to 100%
-- IN_PARSE Each of them could theoretically reach 100%
-- IN_HARD_PARSE
-- IN_SQL_EXECUTION
-- IN_PLSQL_EXECUTION
-- IN_PLSQL_RPC
-- IN_PLSQL_COMPILATION
-- IN_JAVA_EXECUTION
-- IN_BIND
-- IN_CURSOR_CLOSE
-- IN_SEQUENCE_LOAD This column is only available from 11.2 on
--
-- - The "Information on Parallel Degree based on ASH" section now tries to group the processes by DFO and SET_ID (from 11g on if execution plan is available)
-- Since the SET_ID information is not directly available from ASH data it is a rather obscure way of determining the sets and therefore can be wrong.
-- If XPLAN_ASH identifies more than two sets in the ASH data (which isn't possible) those samples will show up in the *NULL* SET_ID section.
--
-- Furthermore if ASH samples do not contain a relation an execution plan line ID, they will be shown as separate group with NULL DFO / SET_ID
--
-- This feature can be disabled via the switch "show_px_sets" in the configuration section
--
-- - Some columns that have been added, particularly the MEDIAN Active Sessions related info, is hidden since it only adds value at some places
--
-- If you want to have them shown, you can change the configuration switch "show_median" to blank "", the default is "NO" and is used as a NOPRINT column formatting
--
-- - The default column shown on execution plan line level are no longer "all columns" for the same reason -
-- the average active sessions (active), average active sessions (total) and median active sessions columns are not shown by default
--
-- The reason for that is that the new logic to calculate the "Parallel Distribution Graph ASH" should now cover all "skew" cases, data distribution and temporal skew
-- Hence these columns should no longer be required to troubleshoot temporal skew (which was their main purpose in the past)
--
-- There is therefore a new option to the column list parameter: column names can be preceded with a + sign, which means that these columns will be shown
-- in addition to the default column list, for example "+MAS_GRF" would show the median active sessions column in addition to the default columns on execution plan line level
--
-- - For some parameters abbreviations are now supported, for example instead of typing HIST at the ASH SOURCE parameter, just "h" is sufficient
--
-- This appplies to Parameters 4 (ASH SOURCE), 5 (Experimental), 6 (Search last exec) and 7 (ASH Options)
--
-- - The ASH Source parameter now supports an AUTO option. This automatically deteremines whether to use the current ASH or historic ASH configuration
-- Note that this only works when Parameter 2 (SQL_EXEC_START) is explicitly specified, otherwise AUTO is the same as CURR, so the last execution
-- will be searched by default using the CURRent ASH configuration set. The default can be changed in the script configuration using the "default_ash" parameter
-- (if you for example have added another configuration set that should be used by default), and when explicitly specifying a configuration set
-- then the AUTO selection doesn't apply.
--
-- AUTO queries GV$ASH_INFO (available from 11.2 on) or the local V$ACTIVE_SESSION_HISTORY (more costly) for the oldest sample available and compares that to the SQL_EXEC_START specified
--
-- - Finally Real-Time SQL Monitoring info on execution plan line level is now supported. There are seven new columns that are taken from the monitoring info:
--
-- Execs (number of executions of that plan line), A-Rows (Actual output rows, cardinality), CellO% (Cell Offload Percentage if applicable) PGA, TEMP, Reads and Writes. The latter four are in bytes
--
-- The column "Parallel Distribution ASH" will have also the Rowcount per Parallel Execution Server added if monitoring info gets used and is available.
-- The Rowcount is added in square brackets to the process, after the number of samples in paranthesis, something like this:
--
-- P012(44)[183K]
--
-- This means process P012 was sampled 44 times for this execution plan line and produced 183K rows according to Real-Time SQL Monitoring
--
-- Note that this information is crucial in understanding Data Distribution Skew and not available from the official Real-Time SQL Monitoring report up to 11.2
-- 12c SQL Monitoring allows to extract this information via the report
--
-- Whether monitoring info will be shown depends obviously on the version (from 11g on) and availability of such information.
-- Furthermore this can be controlled via the ASH options - the MONITOR keyword enables this features
-- Finally as usual the columns shown on execution plan line level can be configured via the columns configuration
--
-- - XPLAN_ASH now tries different optional date masks for SQL_EXEC_START / END if the default mask doesn't work, this is just to simplify copy&pasting of dates
-- The list of optional date masks can be found in the configuration parameters "dm_opt1" and "dm_opt2". Feel free to add your favorite date masks there
--
-- - If SQL_EXEC_START was specified but SQL_EXEC_ID is left blank and version is 11g+, then a default SQL_EXEC_ID of 16777216 will be used
-- This default SQL_EXEC_ID can be changed - if you have a RAC environment with multiple instances this might make sense to change (configuration parameter "default_sql_exec_id")
--
-- - The queries now make use of the (up to 11.2 undocumented, from 12c on documented) LATERAL views - this is to get rid of the inefficient range joins that could cause some of the
-- queries to run for minutes if larger time frames are observed
-- The downside of this is that it now makes use of (yet another) undocumented feature
--
-- The script automatically detects if the session lacks the ALTER SESSION privilege and falls back to a different code path.
-- This is because LATERAL views require to enable an undocumented event.
-- This code path is now optimized, too, and no longer uses the inefficient joins used in version 3.
-- It uses now a MERGE JOIN that performs an efficient index-like lookup into the second row source.
-- It performs probably worse than the LATERAL view variant but should still be much more efficient than before
--
-- - There is a new option LIMITED_ASH that skips the two ASH related sections that can take very long when analyzing long running queries
-- When the LATERAL query variant can be used (ALTER SESSION privilege) this is usually not required
--
-- - A "Real-Time SQL Monitoring Execution Summary" section was added that shows a summary similar to the header of the official reports
--
-- This shows only up if that information is requested, available and version 11g+
--
-- - Another new section has been added: "Actual bind values from Real-Time SQL Monitoring"
-- This only available if:
--
-- * Real-Time SQL Monitoring info is available
-- * Real-Time SQL Monitoring info requested (ASH options includes MONITOR)
-- * 11.2+
--
-- These are the bind variable values used for this particular execution - not to confuse with the "Peeked Binds" that are shown by DBMS_XPLAN and are those bind variables values
-- the optimizer peeked at / saw when generating the execution plan
--
-- - In 11g the wait event "PX Deq Credit: send blkd" was turned into an "idle" wait event, which isn't entirely true. But for consistency purposes from version 4.0
-- in 10g this wait event is handled as "idle" event, too. This can be configured using the "ignore_PX_credit_blkd_10g" configuration switch
--
-- - In the special case of executing the same SQL_ID multiple times and having multiple of these executions active in turns (e.g. fetching from multiple open cursors by the same session)
-- the implementation now correctly distinguishes between these different executions - these other executions should now show up in the "Other" activity sections
-- This is only possible from 11g on with the help of SQL_EXEC_START / SQL_EXEC_ID
--
-- - The calculation of the so called "virtual timeline" is now simplified and gives more consistent results for sample frequencies > 1s (e.g. DBA_HIST_ACTIVE_SESS_HISTORY)
-- With the prior implementation it could happen that for example a spurious "last bucket" with no related activity showed up in the "Activity Timeline"
--
-- - There was an inconsistency with how the different sample times in RAC environments were handled which could lead to incorrect results for some of the measures.
-- This was only relevant with sample frequencies > 1s (e.g. DBA_HIST_ACTIVE_SESS_HISTORY). This is now fixed and handled consistently.
--
-- - In the SQL Execution Summary there are four new columns related to PX SEND / RECEIVE activity - only available from 11g on with Diagnostics Pack license.
-- The idea of these columns is to give an idea how much database time and CPU time went into the overhead of re-distributing the data with Parallel Execution
-- When having many joins and re-distributions the overhead can become significant. Note that in the special case of applying CPU intensive expressions / functions
-- to the columns/expressions used for re-distributing the evaluation of those expressions/functions will take place at the corresponding PX SEND operation (except for BROADCAST distributions).
-- This means that you'll very likely end up with a lot of CPU activity shown with these PX SEND operations, but this isn't really overhead, as serial execution
-- would have to evaluate the same CPU intensive expressions as part of serial operation
--
-- These columns are called
-- "PX SEND/RECEIVE COUNT" The number of samples related to PX SEND/RECEIVE operations
-- "PX SEND/RECEIVE PERCENT" The same as percentage of the total number of samples
-- "PX SEND/RECEIVE CPU COUNT" The number of samples related to PX SEND/RECEIVE operations that were on CPU
-- "PX SEND/RECEIVE CPU PERCENT" The same as percentage of the total number of *CPU* samples
--
-- - There are now two columns "PX WORKER COUNT" and "PX WORKER UNIQUE COUNT": The first (PX WORKER COUNT) is the number of different Parallel Execution Server (Pxxx) processes found in the ASH samples
-- The second one (PX WORKER UNIQUE COUNT) combines the process identifier (Pxxx) with the SESSION_ID and SESSION_SERIAL# - if DFOs are started multiple times, the PX Servers are re-acquired / re-initialized each time
-- This can be seen from getting different SESSION identifiers for the same Pxxx processes, and allows getting an idea about the frequency of those re-acquisitions
-- For DFOs started only once, PX WORKER UNIQUE COUNT should be equal to the PX WORKER COUNT
--
-- The columns PROCESS COUNT and PROCESS UNIQUE COUNT are pretty much the same, but may include the Query Coordinator process, hence they are not called PX WORKER only
--
-- - The columns DURATION_SECS_T / DURATION_T / DURATION_SECS / DURATION / AVERAGE_AS_T / AVERAGE_AS now have more meaningful headings
-- "DURATION SECS TOTAL"
-- "DURATION TOTAL"
-- "DURATION SECS ACTIVE"
-- "DURATION ACTIVE"
-- "AVERAGE AS TOTAL"
-- "AVERAGE AS ACTIVE"
--
-- - From 11g on the TOP_LEVEL_SQL_ID will be shown at different places: In the "SQL Execution Summary", the "Other activities details" and the "Concurrent activity top SQL_IDs"
--
-- - For those interested the Standard Deviation for the Average Active Sessions calculation is also shown as STDDEV_AS at various places
--
-- - From 11.2.0.2 on the PX *MAX* DOP will be shown in the "SQL statement execution ASH Summary" as found in the new PX_FLAGS column of ASH
--
-- - If Parallel Execution is detected and an execution plan can be found the "Activity Timeline based on ASH" shows an additional "Active DFO(s)" column
-- so that you can follow the activity of DFOs - in particular helpful for parallel execution plans with multiple DFOs
--
-- - The internal queries are now by default all set to "quiet" mode so that the output of XPLAN_ASH can be spooled to a file
-- You will still see some spurious blank lines but the output is much more useful than in previous releases
-- Use the settings "debug_internalp" and "debug_internalf" to control the output of the internal queries for debugging
--
--
-- 3.01: May 2013
-- - Some column widths increased and cosmetics changed for some recently renamed headers
--
-- 3.0: March 2013
-- - The "Active" plan lines indicator sometimes was missing for still running statements (same problem as for the "ACTIVE"/"INACTIVE" indicator fixed in 2.02)
-- - The PGA/TEMP figures (available from 11.2 on) in the "Activity Timeline" are now "smoothened" for Parallel Execution using some artificially generated rows
-- (based on the new DELTA_TIME column) for missing samples of PX Workers
-- - All byte related numbers are now formatted using KiB/MiB etc. (base of 2) rather than to the base of 10, so 1M bytes correspond now to 1048576 bytes etc.
-- - Average Active Sessions calculations are now based on MIN(SAMPLE_TIME) instead of SQL_EXEC_START for those cases where execution start is prior to first ASH sample
-- - The "Activity Timeline" query now uses a common approach for historic and current ASH data, also an inconsistency how data was grouped by buckets was addressed
-- These changes were required due to the introduction of the artificial PGA/TEMP rows as mentioned above
-- - The "SQL statement execution ASH Summary" now includes the MACHINE (from 11.2 on) and (Coordinator) session / instance identified
-- - The Graphs used for Extended Rowsource Statistics (A-Time Self Graph, LIO Self Graph, Reads Self Graph and Writes Self Graph) also scale now relative to the MAXimum
-- rather than the total which makes the graph hopefully a bit more useful (can be configured via "ext_rowsource_graphs_maxrel" in configuration section)
-- - Initial support for S-ASH (tested with version 2.3, but this requires some minor modifications to the current S-ASH 2.3 version, modifications can be provided on request)
-- The script automatically detects if it is executed in the S-ASH repository owner by checking for a configured target in the SASH_TARGET table
-- - The Extended Rowsource Statistics now get also pulled from the correct (remote) node in case of RAC and 11.2.0.2+
-- - Improved "Average Active Sessions" calculation - the graph is now scaled if AAS is larger than the defined size
-- - Improved "Parallel Distribution Graph" calculation, new option DISTRIB_TIM hopefully now reflects properly the relevance of skewed work distribution per execution plan line
-- - From 11.2 on MAX PGA/TEMP usage on different summary levels (Global/Instance/Concurrent activity)
-- - Improved "Time Active Graph" calculation on DFO and execution plan line level
-- - New "Average Active Sessions Graph" on execution plan line level that should make it more obvious which execution plan lines are affected by Parallel Execution distribution skew
-- This should now also allow to identify temporal skew where only a few Parallel Workers are active at the same time but at the end do a similar amount of work
-- - Experimental stuff can be controlled via the command line
-- - The graphs now consistently indicate CPU, non-CPU and general activity, and a corresponding legend was added to the header output
-- - The good, old Rowsource statistics have been polished to have now percentages shown, too
-- - The "Ord" column on execution plan line level (Order of execution) by default will not be shown when Parallel Execution gets detected.
-- This is because it will be wrong in many cases except for the most trivial Parallel Execution execution plans.
-- I haven't found the time yet to come up with a more sensible implementation that:
-- - Covers the special cases (the "Ord" column can also be wrong for serial execution if these special cases apply)
-- - Covers the case of Parallel Execution where the order of execution usually doesn't correspond to the serial execution order
-- Hint: Follow the TQ entries in increasing order
--
-- I've decided to keep it for serial execution as it is correct there for the majority of cases (but watch out for those special cases)
-- Hiding it when Parallel Execution is detected can be controlled via the configuration switch "no_ord_on_px"
--
-- - The logic how the script gathers information if no SQL_ID is specified as first argument is now more consistent when using the ASH based options. Instead of getting the SQL_ID information from GV$SESSION
-- for the current or explicitly given SID, it queries now either Active Session History (ASH option) or Real-Time SQL Monitoring (MONITOR option) for the last SQL_ID mentioned there
-- for that session.
-- This probably makes more sense as it automatically selects those queries that are available from ASH/MONITORing and hence worth to analyze rather than taking strictly the most recent execution
-- from GV$SESSION.
-- It also means that the ASH/MONITOR parameter acts now consistently for all possible inputs for the first parameter (SQL_ID, SID, nothing at all).
-- Prior to this change that ASH/MONITOR option was only relevant when specifying a SQL_ID without SQL_EXEC_START / SQL_EXEC_ID
--
-- Note that if no ASH options are selected (specifying NONE at the ASH,DISTRIB,TIMELINE default parameter) then the SQL_ID related information is still taken from GV$SESSION
--
-- - There are now two Average Active Sessions figures, AVERAGE_AS and AVERAGE_AS_T.
-- AVERAGE_AS is the Average Active Sessions across all ASH samples where there was at least one sample
-- AVERAGE_AS_T is the Average Active Sessions across the time the corresponding part was active (from first sample to last sample on statement level, instance level, DFO level, execution plan line level)
-- If AVERAGE_AS_T is significantly lower than AVERAGE_AS this means that the affected part was idle for a significant amount of time during execution
-- AVERAGE_AS_T should never be higher than AVERAGE_AS
--
-- - Likewise there is now also a DURATION_SECS and DURATION_SECS_T
-- DURATION_SECS is the number of seconds actually active
-- DURATION_SECS_T is the number of seconds from first sample (SQL_EXEC_START) to last sample
-- If there is a significant difference then there was some idle time in between
--
-- - The DURATION_SECS and DURATION_SECS_T are now also displayed as INTERVAL for better human readability in case of long running queries
--
-- - For the special Rowsource Statistics mode 3 ("_rowsource_statistics_sampfreq" = 3) where only actual cardinalities are measured, XPLAN_ASH from version 3.0 on supports a special FORMAT option "AROWS".
-- This adds a column "A-Rows" (similar to what DISPLAY_CURSOR does when using the *STATS formatting option) since DISPLAY_CURSOR doesn't support this mode properly
-- - it doesn't show the A-Rows in that case although the columns are populated in GV$SQL_PLAN_STATISTICS_ALL
-- Note that you usually want to use "AROWS LAST" similar to "ALLSTATS LAST" if you want to see the actual cardinalities of the last execution
--
-- 2.03: January 2013
-- - The Activity Graph in "Parallel Worker Activity" now differentiates between "CPU" and "Other" activity
-- Furthermore it is scaled now relative to the MAXimum count rather than relative to total activity so that differences in sample count show up more clearly
-- - The "Top N Activity ASH" Activity Graph on execution plan line level is now also relative to the MAX activity, no longer relative to the total activity, for the same reason
-- - Some inconsistencies in ASHs SQL_EXEC_START column addressed - It no longer uses simply the MIN SQL_EXEC_START found but the most occurring one among the set identified
-- There were some inconsistent entries encountered in 11.2.0.x ASH data
--
-- 2.02: October 2012
-- - Running the script on 10g is more sensitive how the session information is populated in the ASH data
-- Therefore the query to define the session predicates was modified
-- - The INACTIVE / ACTIVE indicator in the "Global ASH summary" was sometimes incorrectly showing "INACTIVE" status although the statement was still running
--
-- 2.01: October 2012
-- - The NONE option did not populate a substitution variable properly that is required from 11.2.0.2 on
-- for running the DBMS_XPLAN function on the target node via the GV$() function
--
-- 2.0: October 2012
-- - Access check
-- - Conditional compilation for different database versions
-- - Additional activity summary (when enabling "experimenal" including average and median wait times)
-- - Concurrent activity information (what is going on at the same time as this SQL statement executes)
-- - Experimental stuff: Additional I/O summary
-- - More pretty printing
-- - Experimental stuff: I/O added to Average Active Session Graph (renamed to Activity Timeline)
-- - Top Execution Plan Lines and Top Activities added to Activity Timeline
-- - Activity Timeline is now also shown for serial execution when TIMELINE option is specified
-- - From 11.2.0.2 on: We get the ACTUAL DOP from the undocumented PX_FLAGS column added to ASH
-- - All relevant XPLAN_ASH queries are now decorated so it should be easy to identify them in the Library Cache
-- - More samples are now covered and a kind of "read consistency" across queries on ASH is introduced
-- - From 11.2.0.2 on: Executions plans are now pulled from the remote RAC instance Library Cache if necessary
-- - Separate Parallel Worker activity overview
-- - Limited support for Oracle 10.2 ASH
--
-- 1.0: August 2012
-- Initial release
--
-- Ideas: - Include GV$SESSION_LONGOPS information
-- - Show breakdown of objects accessed based on ASHs CURRENT_OBJ# information
--
#
---------------------------------------------------------------------------------
-- Clean up SQL*Plus environment, prevents side effects of current environment --
---------------------------------------------------------------------------------
undefine _EXPERIMENTAL
undefine duplicator
undefine dist_sample_count
undefine default_fo
undefine default_source
undefine default_operation
undefine default_ash
undefine prev_sql_id
undefine prev_cn
undefine prev_sql_exec_start
undefine prev_sql_exec_id
undefine last_exec_start
undefine last_exec_id
undefine last_exec_second_id
undefine last
undefine child_ad
undefine slave_count
undefine topnp
undefine topnw
undefine topnl
undefine topna
undefine pgs
undefine aas
undefine wgs
undefine si
undefine cn
undefine fo
undefine so
undefine ls
undefine li
undefine op
undefine ah
undefine co
undefine gc
undefine gc2
undefine gc3
undefine sid_sql_id
undefine sid_child_no
undefine sid_sql_exec_start
undefine sid_sql_exec_id
undefine _IF_ORA11_OR_HIGHER
undefine _IF_LOWER_THAN_ORA11
undefine _IF_ORA112_OR_HIGHER
undefine _IF_LOWER_THAN_ORA112
undefine _IF_ORA11202_OR_HIGHER
undefine _IF_LOWER_THAN_ORA11202
undefine _IF_ORA11203_OR_HIGHER
undefine _IF_LOWER_THAN_ORA11203
undefine _IF_ORA12_OR_HIGHER
undefine _IF_ORA12_READ_MEM
undefine _IF_ORA_NO_READ_MEM
undefine _IF_LOWER_THAN_ORA12
undefine _IF_ORA12102_OR_HIGHER
undefine _IF_LOWER_THAN_ORA12102
undefine _IF_ORA11202_OR_HIGHERP
undefine _IF_ORA112_OR_HIGHERP
undefine _IF_ORA11_OR_HIGHERP
undefine _IF_ORA12_OR_HIGHERP
undefine _IF_ORA12_READ_MEMP
undefine _IF_CROSS_INSTANCE
undefine _IS_CROSS_INSTANCE
undefine _IS_SINGL_INSTANCE
undefine _SQL_EXEC2
undefine plan_table_name
undefine las
undefine active_ind
undefine ic
undefine dm
undefine all_cols
undefine default_cols
undefine curr_global_ash
undefine curr_inst_id
undefine curr_plan_table
undefine curr_plan_table_stats
undefine curr_second_id
undefine curr_second_id_monitor
undefine curr_sample_freq
undefine curr_plan_function
undefine curr_par_fil