Kscope19 - Understanding the basics of SQL processing

24/06/2019
1
a good background in ...
1
2

24/06/2019
2
... SQL processing, aka
... successful application development
3
4

24/06/2019
3
Copyright © 2018, Oracle and/or its affiliates. All rights reserved.
Connor McDonald
6
5
6

24/06/2019
4
7
8
7
8

24/06/2019
5
Getting in touch is easy...
connor-mcdonald.com
https://linktr.ee/connor
10https://asktom.oracle.com
9
10

24/06/2019
6
1
https://asktom.oracle.com/officehours
200 hours free access so far
12
11
12

24/06/2019
7
assumptions
1. You roughly know databases (tables and columns)
2. You can write a SQL statement
before we begin
13
14

24/06/2019
8
recommended reading
docs.oracle.com
15
16

24/06/2019
9
its free !
Concepts guide
http://bit.ly/oraconcepts
17
18

24/06/2019
10
better than lots of current people
Application Developers guide
http://bit.ly/oradevdoc
19
20

24/06/2019
11
better than lots of current people
SQL is like any language
22
21
22

24/06/2019
12
compile it
23
on the fly
run it
24
23
24

24/06/2019
13
get | store results
25
for successful applications...
26
25
26

24/06/2019
14
compile it ... fast
27
run it ... fast
28
27
28

24/06/2019
15
get | store results ... fast
29
that's it!
30
29
30

24/06/2019
16
this session
31
compile
execute
store/fetch results
32
31
32

24/06/2019
17
before we begin ...
some controversy to start
33
34

24/06/2019
18
here's the problem...
35
... it's us
35
36

24/06/2019
19
a small digression
a little bit of history on servers ...
37
38

24/06/2019
20
(not too) long ago
39
40

24/06/2019
21
FSB = "front side bus"
41
any access to ... anything
41
42

24/06/2019
22
CPU capped
43
44

24/06/2019
23
hypertransport
45
46

24/06/2019
24
memory access direct from CPU
47
47
48

24/06/2019
25
~2007
"why do I care?"
49
50

24/06/2019
26
you can't blame the server (anymore)
51
if you can't get that performance ...
51
52

24/06/2019
27
... it's you
53
54

24/06/2019
29
all have their place...
57
58

24/06/2019
30
"The sooner your company admits that you are not
Google, the sooner you can get down to some real work"
- Ted Dziuba
59
so what's holding you back ?
59
60

24/06/2019
31
It all comes down to...
too much work or ...
61
62

24/06/2019
32
... not being able to do work
63
PART #1
64
compiling SQL
63
64

24/06/2019
33
... how to avoid work when processing SQL
terminology
66
65
66

24/06/2019
34
cursors
declare
cursor C(p number) is
select * from DEPT
where DEPTNO = p;
begin
for rec in C loop
…
end loop;
end;
select *
from EMPLOYEE
where EMPNO > 1234;
delete from MY_TABLE;
drop table MY_TABLE;
begin
MY_PROCEDURE(1,2,3);
end;
all of them !
67
68

24/06/2019
35
3 phases
open
process
close
gimme some memory
do some stuff using that memory,
maybe access other memory
here's your memory back
70
69
70

24/06/2019
36
memory access = controlled access
a quick primer on (database) memory
71
72

24/06/2019
37
74
metaphor
73
74

24/06/2019
40
79
limited resource
lots of people want it
concurrent access causes problems
it's a complex system
79
80

24/06/2019
41
81
same with memory
SGA
81
82

24/06/2019
42
SGA
protected by
SGA
protected by
1) get latch
83
84

24/06/2019
43
SGA
protected by
2) access memory
SGA
protected by
3) release latch
85
86

24/06/2019
44
latch contention
SGA
protected by
someone must wait ...
87
88

24/06/2019
45
active wait
spinning
can I have the latch ?
90
89
90

24/06/2019
47
latch contention....
hurts CPU...
94
93
94

24/06/2019
48
hurts concurrency
YOU
95
96

24/06/2019
49
GET
NOTHING
97
98

24/06/2019
50
DONE
its importance to Oracle
99
100

24/06/2019
51
early Oracle
2000 times !
(_spin_count)
102
101
102

24/06/2019
52
Zzzzzzzzzz....
nowadays...
yield
mutex
posting
Good reading: http://andreynikolaev.wordpress.com/
CAS
103
104

24/06/2019
53
"Errrr.... weren't we talking SQL?"
to run a SQL statement
105
106

24/06/2019
54
Syntax
Validity
Optimization
Rowsourcing
Execution
(Fetch)
SQL> select *
2 frmo emp;
frmo emp
*
ERROR at line 2:
ORA-00923: FROM keyword not found where expected
107
Syntax
Validity
Optimization
Rowsourcing
Execution
(Fetch)
SQL> select empnoo
2 from emp;
select empnoo
*
ERROR at line 1:
ORA-00904: invalid column name
107
108

24/06/2019
55
Syntax
Validity
Optimization
Rowsourcing
Execution
(Fetch)
PLAN
-------------------------------------
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID EMP
INDEX RANGE SCAN EMP_PK
EMP_PK EMP
Syntax
Validity
Optimization
Rowsourcing
Execution
(Fetch)
109
110

24/06/2019
56
Syntax
Validity
Optimization
Rowsourcing
Execution
(Fetch)
111
Syntax
Validity
Optimization
Rowsourcing
Execution
(Fetch)
111
112

24/06/2019
57
lots of preliminaries
parsing
114
"compile"
113
114

24/06/2019
58
lots of memory access
115
lots of latching !
116
115
116

24/06/2019
59
impossible to avoid ?
library cache
117
118

24/06/2019
60
previously executed statements
119
parse statement
already in library cache ?
reuse optimizer info
reuse row source info
select * from emp where empno = 123
syntactically, semantics OK
119
120

24/06/2019
61
select surname, firstname from emp where empno = 123
select * from dept where deptno = 4567
select * from customer where locality = 17
select prno from property where reference = 'X123G'
select * from customer where locality = 256
select * from organisation where officer = 'OFF876'
select offender from crimes where crno = 247462
Two full parses avoided
library
cache
select * from dept where dname = 'SALES'
probability of reuse low ?
121
122

24/06/2019
62
some queries are “nearly the same”
123
binding
parse this...
now run it with ? = 123
now run it with ? = 456
select surname, firstname from emp where empno = ?
123
124

24/06/2019
63
select * from dept where deptno = ?
select * from customer where locality = ?
select prno from property where reference = ?
select * from customer where locality = ?
select * from organisation where officer = ?
select offender from crimes where crno = ?
Five full parses avoided
library
cache
demo
ParseDemo
ParseDemoBind
125
126

24/06/2019
64
"performance still looks ok"
let's make it real
ParseDemo2 nn
ParseDemo2Bind nn
127
128

24/06/2019
65
much more serious
select pk from parse_demo where pk = 17
129
130

24/06/2019
66
building SQL by concatenation
you'll get hacked
131
132

24/06/2019
67
select ename
from emp
where empno = 6543
select ename
from emp
where empno = 6543
and 1=0
union all
select table_name
from all_tables
where table_name like '%SECURITY%'
select ename
from emp
where empno = 6543
and 1=0
union all
select username
from app_security
where ...
134
133
134

24/06/2019
69
it takes 5 minutes to hack you
for fast, secure SQL ...
137
138

24/06/2019
70
... always bind user input
while we are talking binding
139
140

24/06/2019
71
parse statement
already in library cache ?
reuse optimizer info
reuse row source info
select * from emp where empno = 123
syntactically, semantics OK
Yes!
Yes!
???
???
still some parsing to do
142
141
142

24/06/2019
72
Syntax
Validity
Optimization
Rowsourcing
Execution
(Fetch)
Hard
Parse
Soft
Parse
foundnot found
in lib cache
scott@mydb> select *
2 from EMP
3 where EMPNO = :b1
mike@mydb> select *
2 from EMP
3 where EMPNO = :b1
SQL> desc mike.emp
Name Null? Type
----------------- -------- ------------
EMPNO NOT NULL NUMBER(4)
ENAME VARCHAR2(10)
JOB VARCHAR2(9)
143
144

24/06/2019
73
(even soft) parsing =
memory access =
latching
can we do better ?
145
146

24/06/2019
74
recall
open
process
close
gimme some memory
do some stuff using that memory,
probably access other memory
here's your memory back
148
147
148

24/06/2019
75
your SQL is always shareable
library cache
select *
from emp
your cursor points to it
library cache
select *
from emp
cursor
150
149
150

24/06/2019
76
close cursor = lose pointer
library cache
select *
from emp
cursor
next time we parse
soft parse
151
152

24/06/2019
77
impossible to avoid ?
153
what if we don't close the cursor
153
154

24/06/2019
78
emplist(String[] args) {
if "first time I'm using this" {
else
"reset the pointer, re-execute"
}
library cache
select *
from emp
cursor 1
select *
from dept
cursor 2
select *
from emp
where ...
cursor 3
pstmt_all_emp =
con.prepareStatement("select * from emp");
don’t close the cursorhang on to the memoryremember what cursors we’ve usedreuse whenever possibledon’t exhaust memorydon’t allow invalid cursor reuse
155
156

24/06/2019
79
sounds complicated ...
a free solution exists
157
158

24/06/2019
80
plsql
create procedure MY_PROC is
begin
select empno, ename, ...
into …
from emp
where empno = my_plsql_variable
...
end;
159
160

24/06/2019
81
static SQL in stored PLSQL
automatically uses bind variables
hold’s cursors open
(even if you close)
better cursor caching
161
162

24/06/2019
82
procedure MY_PROC is
cursor c_emp is
select * from emp;
begin
open c_emp;
fetch c_emp
into …;
close c_emp;
end;
select * from emp
procedure MY_PROC is
begin
select *
into …
from dept
where …
end;
select * from dept …
164
PART #2
get | store results
we'll come back to running SQL
163
164

24/06/2019
83
165
start with reading data
166
165
166

24/06/2019
84
querying data
data is stored in blocks | pages
167
168

24/06/2019
85
to read data, you read blocks...
SQL> select *
2 from EMP
3 where ...
/u01/my_data1.dat
memory
169
170

24/06/2019
86
but (database) memory access is complex
171
SQL> select *
2 from EMP
3 where …
SQL> update EMP
2 set …
3 where …
SQL> select *
2 from EMP
3 where …
SQL> insert into
2 EMP
3 values (…)
SQL> select *
2 from CUSTOMER
3 /
SQL> select max(EMP)
2 from DEPT
SQL> delete
2 from DEPT
3 /
171
172

24/06/2019
87
we have to latch !
• Get latch
• Search along list of blocks in memory
• Read block
• Extract row of interest
• Release latch
• Give row back to client
"fetch a row"
174
173
174

24/06/2019
88
lots of rows
lots of latching
175
176

24/06/2019
89
typical program
rs = stmt.executeQuery("...");
while(rs.next()) {
v1 = rs.getInt(1);
v2 = rs.getString(2);
...
}
• Get latch
• Walk along list
• Get block
• Extract single row
• Release latch
• Give row back to client
• Get latch (again)
• Walk along list (again)
• Get block (again)
• Release latch (again)
• Give row back to client (again)
Row #1
Row #2
• Get latch (again)
• Walk along list (again)
• Get block (again)
• Release latch (again)
• Give row back to client (again)
Row #3
178
177
178

24/06/2019
90
a better strategy.... “pinning”
"fetch a row"
• Get latch
• Walk along list
• Get block
• Pin the block
• Release latch
• Give row 1 back to client
• Give row 2 back to client
…
• Give row n to client
• Get latch
• Walk along list
• Remove my pin on the block
• Release latch
“and .. I’ll will need
several rows from
this block”
179
180

24/06/2019
91
how do you say
“I may want many rows” ?
responsibility of the client
181
182

24/06/2019
92
183
FetchDemo nn
focus on blocks
184
183
184

24/06/2019
93
focus on roundtrips
185
all that data goes somewhere
186
185
186

24/06/2019
94
SQL> declare
. . .
9 begin
10 open c;
11 loop
12 fetch c
13 into r;
14 exit when c%notfound;
. . .
19 /
Elapsed: 00:01:11.72
SQL> declare
. . .
9 begin
10 open c;
11
12 fetch c
13 bulk collect
14 into r;
15
. . .
19 /
Elapsed: 00:00:08.93
187
188

24/06/2019
95
SQL> select * from v$mystats
2 where name like '%pga%'
3 /
NAME VALUE
------------------------------ ----------
session pga memory 501534672
session pga memory max 501534672
500m of memory !
189
190

24/06/2019
96
law of diminishing returns
pin rows on a block (8k)
192
191
192

24/06/2019
97
SQL> declare
. . .
9 begin
10 open c;
11 loop
12 fetch c
13 bulk collect
14 into r limit 100;
15 exit when c%notfound;
. . .
19 /
Elapsed: 00:00:08.17
NAME VALUE
------------------------------ ----------
session pga memory 625912
session pga memory max 625912
SQL> declare
. . .
9 begin
10 for i in c loop
12 ...
16 end loop;
17 end;
18 /
Elapsed: 00:00:08.21
193
194

24/06/2019
98
PART #2(a)
storing data
the same rules apply
196
195
196

24/06/2019
99
think blocks not rows
197
when appropriate
commit when it makes sense to
198
197
198

24/06/2019
100
demo
199
InsertDemo3
InsertDemo4 nn
200
PART #3
running SQL
199
200

24/06/2019
101
so you've written your SQL ...
201
202
PreparedStatement stmt =
conn.prepareStatement(
"select count(*)
from vehicles
where make = ?
and model = ?");
stmt.setString(1, "HONDA");
stmt.setString(2, "ACCORD");
stmt.execute();
201
202

24/06/2019
102
203
1) what is the real query
204
203
204

24/06/2019
103
205
?
206
SQL> set autotrace traceonly stat
SQL> select *
2 from LOOKS_SO_INNOCENT
3 where CREATED > sysdate
Statistics
------------------------------------------
651 recursive calls
0 db block gets
253243 consistent gets
24 physical reads
205
206

24/06/2019
104
207
SQL> variable c clob
SQL> begin
2 dbms_utility.expand_sql_text
3 ( 'select * from LOOKS_SO_INNOCENT '||
4 'where created > sysdate',:c);
5 end;
6 /
PL/SQL procedure successfully completed.
SQL> print c
208
SQL> create or replace
2 view LOOKS_SO_INNOCENT as
3 select
4 o.owner,
5 o.created,
6 s.bytes,
7 s.tablespace_name
8 from
9 dba_segments s,
10 all_objects o
11 where o.owner = s.owner
12 and o.object_name = s.segment_name;
View created.
207
208

24/06/2019
105
209
SELECT "A1"."OWNER" "OWNER",
"A1"."NAME" "NAME",
"A1"."CREATED" "CREATED",
"A1"."BYTES" "BYTES",
"A1"."TABLESPACE_NAME" "TABLESPACE_NAME"
FROM (SELECT "A2"."OWNER" "OWNER",
"A2"."OBJECT_NAME" "NAME",
"A2"."CREATED" "CREATED",
"A3"."BYTES" "BYTES",
"A3"."TABLESPACE_NAME" "TABLESPACE_NAME" FROM (SELECT "A4"
."OWNER" "OWNER",
"A4"."SEGMENT_NAME" "SEGMENT_NAME",
"A4"."PARTITION_NAME" "PARTITION_NAME",
"A4"."SEGMENT_TYPE" "SEGMENT_TYPE",
"A4"."SEGMENT_SUBTYPE" "SEGMENT_SUBTYPE",
"A4"."TABLESPACE_NAME" "TABLESPACE_NAME",
"A4"."HEADER_FILE" "HEADER_FILE",
"A4"."HEADER_BLOCK" "HEADER_BLOCK",
DECODE(BITAND("A4"."SEGMENT_FLAGS",131072),131072,
"A4"."BLOCKS",DECODE(BITAND("A4"."SEGMENT_FLAGS",1),1,
"SYS"."DBMS_SPACE_ADMIN"."SEGMENT_NUMBER_BLOCKS"("A4"."TABLESPACE_ID",
"A4"."RELATIVE_FNO",
"A4"."HEADER_BLOCK",
"A4"."SEGMENT_TYPE_ID",
"A4"."BUFFER_POOL_ID",
"A4"."SEGMENT_FLAGS",
"A4"."SEGMENT_OBJD",
"A4"."BLOCKS"),
"A4"."BLOCKS"))*"A4"."BLOCKSIZE" "BYTES",
DECODE(BITAND("A4"."SEGMENT_FLAGS",131072),131072,
"A4"."BLOCKS",DECODE(BITAND("A4"."SEGMENT_FLAGS",1),1,
"SYS"."DBMS_SPACE_ADMIN"."SEGMENT_NUMBER_BLOCKS"("A4"."TABLESPACE_ID",
210
"A4"."BLOCKS"),
"A4"."BLOCKS")) "BLOCKS",DECODE(BITAND("A4"."SEGMENT_FLAGS",131072),131072,
"A4"."EXTENTS",DECODE(BITAND("A4"."SEGMENT_FLAGS",1),1,
"SYS"."DBMS_SPACE_ADMIN"."SEGMENT_NUMBER_EXTENTS"("A4"."TABLESPACE_ID",
"A4"."EXTENTS"),
"A4"."EXTENTS")) "EXTENTS",
"A4"."INITIAL_EXTENT" "INITIAL_EXTENT",
"A4"."NEXT_EXTENT" "NEXT_EXTENT",
"A4"."MIN_EXTENTS" "MIN_EXTENTS",
"A4"."MAX_EXTENTS" "MAX_EXTENTS",
"A4"."MAX_SIZE" "MAX_SIZE",
"A4"."RETENTION" "RETENTION",
"A4"."MINRETENTION" "MINRETENTION",
"A4"."PCT_INCREASE" "PCT_INCREASE",
"A4"."FREELISTS" "FREELISTS",
"A4"."FREELIST_GROUPS" "FREELIST_GROUPS",
"A4"."RELATIVE_FNO" "RELATIVE_FNO",
DECODE("A4"."BUFFER_POOL_ID",1,'KEEP',2,'RECYCLE','DEFAULT') "BUFFER_POOL",
DECODE("A4"."FLASH_CACHE",1,'KEEP',2,
'NONE','DEFAULT')
"FLASH_CACHE",DECODE("A4"."CELL_FLASH_CACHE",1,'KEEP',2,'NONE','DEFAULT')
"CELL_FLASH_CACHE"
FROM ( (SELECT NVL("A199"."NAME",'SYS') "OWNER",
"A198"."NAME" "SEGMENT_NAME",
209
210

24/06/2019
106
211
"A198"."SUBNAME" "PARTITION_NAME",
"A196"."OBJECT_TYPE" "SEGMENT_TYPE",
"A195"."TYPE#" "SEGMENT_TYPE_ID",DECODE(BIT
AND("A195"."SPARE1",2097408),2097152,'SECUREFILE',256,'ASSM','MSSM') "SEGMENT_SUBTYPE",
"A197"."TS#" "TABLESPACE_ID",
"A197"."NAME" "TABLESPACE_NAME",
"A197"."BLOCKSIZE" "BLOCKSIZE",
"A194"."FILE#" "HEADER_FILE",
"A195"."BLOCK#" "HEADER_BLOCK",
"A195"."BLOCKS"*"A197"."BLOCKSIZE" "BYTES",
"A195"."BLOCKS" "BLOCKS",
"A195"."EXTENTS" "EXTENTS",
"A195"."INIEXTS"*"A197"."BLOCKSIZE" "INITIAL_EXTENT",
"A195"."EXTSIZE"*"A197"."BLOCKSIZE" "NEXT_EXTENT",
"A195"."MINEXTS" "MIN_EXTENTS",
"A195"."MAXEXTS" "MAX_EXTENTS",DECODE(BITAND("A195"."SPARE1",4194304),4194304,
"A195"."BITMAPRANGES",NULL) "MAX_SIZE",TO_CHAR(DECODE(
BITAND("A195"."SPARE1",2097152),2097152,
DECODE("A195"."LISTS",0,'NONE',1,'AUTO',2,'MIN',3,'MAX',4,'DEFAULT','INVALID'),NULL))
"RETENTION",DECODE(BITAND("A195"."SPARE1",2097152),2097152,
"A195"."GROUPS",NULL) "MINRETENTION",DECODE(BITAND("A197"."FLAGS",3),1,TO_NUMBER(NULL),
"A195"."EXTPCT") "PCT_INCREASE",DECODE(BITAND("A197"."FLAGS",32),32,
TO_NUMBER(NULL),DECODE("A195"."LISTS",0,1,
"A195"."LISTS"))
"FREELISTS",DECODE(BITAND("A197"."FLAGS",32),32,TO_NUMBER(NULL),DECODE("A195"."GROUPS",0,1,
"A195"."GROUPS")) "FREELIST_GROUPS",
"A195"."FILE#" "RELATIVE_FNO",BITAND("A195"."CACHEHINT",3) "BUFFER_POOL_ID",
BITAND("A195"."CACHEHINT",12)/4 "FLASH_CACHE",BITAND("A195"."CACHEHINT",48)/16 "CELL_FLASH_CACHE",
NVL("A195"."SPARE1",0)
"SEGMENT_FLAGS",DECODE(BITAND("A195"."SPARE1",1),1,
"A195"."HWMINCR",
"A198"."DATAOBJ#") "SEGMENT_OBJD" FROM "SYS"."USER$" "A199",
"SYS"."OBJ$" "A198",
"SYS"."TS$" "A197", ( (SELECT
212
DECODE(BITAND("A209"."PROPERTY",8192),8192,'NESTED TABLE','TABLE') "OBJECT_TYPE",
2 "OBJECT_TYPE_ID",5 "SEGMENT_TYPE_ID",
"A209"."OBJ#" "OBJECT_ID",
"A209"."TS#" "TS_NUMBER" FROM "SYS"."TAB$" "A209" WHERE BITAND("A209"."PROPERTY",1024)=0) UNI
ON ALL (SELECT 'TABLE PARTITION' "OBJECT_TYPE",19 "OBJECT_TYPE_ID",5 "SEGMENT_TYPE_ID",
"A208"."TS#" "TS_NUMBER" FROM "SYS"."TABPART$" "A208") UNION ALL
(SELECT 'CLUSTER' "OBJECT_TYPE",3 "OBJECT_TYPE_ID",5 "SEGMENT_TYPE_ID",
"A207"."TS#" "TS_NUMBER" FROM "SYS"."CLU$" "A207") UNION ALL
(SELECT DECODE("A206"."TYPE#",8,'LOBINDEX','INDEX') "OBJECT_TYPE",1 "OBJECT_TYPE_ID",6
"SEGMENT_TYPE_ID",
"A206"."TS#" "TS_NUMBER" FROM "SYS"."IND$" "A206" WHERE "A206"."TYPE#"=1 OR
"A206"."TYPE#"=2 OR
"A206"."TYPE#"=3 OR
"A206"."TYPE#"=4 OR
"A206"."TYPE#"=6 OR
"A206"."TYPE#"=7 OR
"A206"."TYPE#"=8 OR
"A206"."TYPE#"=9) UNION ALL
(SELECT 'INDEX PARTITION'
"OBJECT_TYPE",20 "OBJECT_TYPE_ID",6 "SEGMENT_TYPE_ID",
211
212

24/06/2019
107
213
"A205"."TS#" "TS_NUMBER" FROM "SYS"."INDPART$" "A205") UNION ALL
(SELECT 'LOBSEGMENT' "OBJECT_TYPE",21 "OBJECT_TYPE_ID",8 "SEGMENT_TYPE_ID",
"A204"."LOBJ#" "OBJECT_ID",
"A204"."TS#" "TS_NUMBER" FROM "SYS"."LOB$" "A204" WHERE BITAND("A204"."PROPERTY",64)=0 OR
BITAND("A204"."PROPERTY",128)=128) UNION ALL
(SELECT 'TABLE SUBPARTITION' "OBJECT_TYPE",34 "OBJECT_TYPE_ID",5 "SEGMENT_TYPE_ID",
"A203"."TS#" "TS_NUMBER" FROM "SYS"."TABSUBPART$" "A203") UNION ALL
(SELECT 'INDEX SUBPARTITION' "OBJECT_TYPE",35 "OBJECT_TYPE_ID",6 "SEGMENT_TYPE_ID",
"A202"."TS#" "TS_NUMBER" FROM "SYS"."INDSUBPART$" "A202") UNION ALL
(SELECT DECODE("A201"."FRAGTYPE$",'P','LOB PARTITION','LOB SUBPARTITION')
"OBJECT_TYPE",DECODE("A201"."FRAGTYPE$",'P',40,41) "OBJECT_TYPE_ID",8 "SEGMENT_TYPE_ID",
"A201"."FRAGOBJ#" "OBJECT_ID",
"A201"."TS#" "TS_NUMBER" FROM "SYS"."LOBFRAG$" "A201")) "A196",
"SYS"."SEG$" "A195",
"SYS"."FILE$" "A194" WHERE "A195"."FILE#"="A196"."HEADER_FILE" AND
"A195"."BLOCK#"="A196"."HEADER_BLOCK" AND
"A195"."TS#"="A196"."TS_NUMBER" AND
"A195"."TS#"="A197"."TS#" AND
"A198"."OBJ#"="A196"."OBJECT_ID" AND
"A198"."OWNER#"="A199"."USER#"(+) AND
"A195"."TYPE#"="A196"."SEGMENT_TYPE_ID" AND
"A198"."TYPE#"="A196"."OBJECT_TYPE_ID" AND
"A195"."TS#"="A194"."TS#" AND
21 ...
214
more ...
pages !
213
214

24/06/2019
108
215
back to our problem SQL
"select count(*)
from vehicles
where make = ?
and model = ?");
216
2) is it sensible/correct ?
215
216

24/06/2019
109
217
SQL> select ...
2 from EMP e,
3 DEPT d
4 where e.JOB = 'SALES'
5 and d.LOC = 'NORTH';
6 and d.DEPTNO = e.DEPTNO
218
SQL> select REGION, min(AMOUNT)
2 from EMP e,
3 SALES_TRANSACTIONS s
4 where e.JOB = 'SALES'
5 and s.EMPNO = e.EMPNO
6 and s.REGION = 'CA'
7 and s.TAX_AMT > 10
8 or s.SUBSIDY > 0
9 group by REGION
7 and s.TAX_AMT > 10
8 or s.SUBSIDY > 0
9 group by REGION
(
)
217
218

24/06/2019
110
219
SQL> select *
2 from sales
3 where region in
4 ( select region
5 from promoted_locations
6 where campaign = 'BLACK FRIDAY');
SQL> desc PROMOTED_LOCATIONS
Name Null? Type
------------------------ -------- -------------
ID NOT NULL NUMBER
CAMPAIGN NOT NULL VARCHAR2(128)
PROMOTED_REGION NOT NULL VARCHAR2(24)
...
220
3) the execution plan
219
220

24/06/2019
111
optimizer got it wrong...
221
or
222
221
222

24/06/2019
112
... it cannot run better
223
legitimate response
------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |
------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1| 5|
| 1 | SORT AGGREGATE | | 1| 5|
| 2 | TABLE ACCESS BY INDEX ROWID | VEHICLES | 20K| 687K|
| 3 | INDEX RANGE SCAN | MAKE_IX | 45K| 592K|
------------------------------------------------------------------
224
"select count(*)
from vehicles
where make = ?
and model = ?");
223
224

24/06/2019
113
225
now what ?
226
for human beings ...
225
226

24/06/2019
114
227
... cardinality is everything
228
227
228

24/06/2019
115
230
same with the optimizer
229
230

24/06/2019
116
understanding cardinality and cost crucial
summary
231
232

24/06/2019
117
avoid parsing costs
for high frequency SQL
use binding and don't get hacked !
233
234

24/06/2019
118
using PLSQL is golden
SQL - the features
235
236

24/06/2019
119
Thanks for coming!
connor-mcdonald.com
https://linktr.ee/connor
237
238

Kscope19 - Understanding the basics of SQL processing

Recommended

Recommended

More Related Content

Similar to Kscope19 - Understanding the basics of SQL processing

Similar to Kscope19 - Understanding the basics of SQL processing (20)

More from Connor McDonald

More from Connor McDonald (20)

Recently uploaded

Recently uploaded (20)

Kscope19 - Understanding the basics of SQL processing