Developer day v2

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |
Performance Optimization
User Group Performance Tuning Day
Oracle Confidential – Internal/Restricted/Highly Restricted
Vivek Sharma
Technologist – Core Technology & Cloud
Asia Pacific
Blog : viveklsharma.wordpress.com
Twitter : @vivek_oracle

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 2
The Technical Observations & Views here are my own
and not necessarily those of Oracle or its affiliates.
These are purely based on my understanding,
learning and resolution of various customer issues.
Disclaimer

Agenda for the Day
• Database Concepts for Performance
• Locks & Latches
• Cursor Concepts & Sharing of Cursors
• Parsing and Optimization
• Indexes – Some Myths and Misconceptions
• Oracle Optimizer – Important Statistics
• Discussions (In-between Sessions & Breaks)

Before We Start…
• What is the fastest way to Query a Row ?
• What is Bind Variable Peeking ?
• What is the relationship between Parent Cursor & Child Cursor ?
Answer to SOME of these during the DAY
• What is the difference between Redo & Undo ?
• What is IniTrans & MaxTrans ?
• How many of you believe that db file scattered read can also be seen with Index Scans ?
• How many of you believe that db file sequential read can also be seen with Full Scans ?
• What is the difference between Memory_Target & SGA_Target ?
• Which is better ? Index Scans or Full Scans ?
• To read 100% of the rows, Full Scans or Index Scans ?

Performance – Four Root Causes (Most Common)
• Database is not being Used as it was Designed to be Used
– DB Architect / Developers are Not-Aware of Database features
– Application is as-is portable on all available Databases
• Application Architecture / Code Design is Sub-Optimal
– Solution Architect / DB Architect / Developers are not Database savvy
– Developers use Shortcut Route to implement a solution
• There is a Sub-Optimal algorithm in the Database
– It could be a BUG causing issues
– A feature improves a bottleneck but causes a side-effect
• Human Error
– Human tend to forget things under pressure (18c – Autonomous Database  )

Why Concept ?
• Database Architecture
– Memory Structures
– Background / Server Processes
• Database Objects
• SQL & PL/SQL
• Database Tools & Features
• Optimizer & Critical Inputs to Optimizer
• New Features / Features Deprecated

At High Level (In the order of priority)
• Know your Database
• Know your Development Tool
• Know your Data
• Know your Application
• Know your Developers 
A Mantra for a Successful Development Project
“Don’t treat Database as a Black Box”

Architecture (Just Enough Diagram)
User or
App Server
Oracle
Server
Process
Network
Or Local
Shared Pool
Log
Buffer
Buffer Cache
Shared Global Area - SGA
LGWR
DBWR
Disk Reads
Redo Logs
Commits / Rollbacks

Redo & Undo
• Redo
– Replay a Transaction
– Flushed from SGA to On-Disk Logs
• Undo
– Opposite of Redo
– Put back the Data – as it was
– Critical for Read Consistency
Not an Overhead, but Generate as minimal as possible

Maintaining Concurrency
Seq 1 (User 1)
Seq 2 (User 2)
Seq 3 (User 1)
Seq 4 (User 2)
update stocks set qty = qty - 100 where prod_id = ‘A’;
update stocks set qty = qty - 10 where prod_id = ‘B’;
update stocks set qty = qty - 75 where prod_id = ‘B’;
update stocks set qty = qty - 50 where prod_id = ‘A’;
Success
Success
Locked
Deadlock
Readers do not block Readers / Writers
Writers do not block Readers / Writers
Writer block Writers ONLY at ROW level

Maintaining Concurrency (contd..)
• Locks
– Application Enforced
 Row Level Lock (TX Contention)
 Ora-00060 (Deadlock)
– Oracle Enforced
 ITL (Lock Mode 6)
 Bitmap (Lock Mode 4)
 Duplicate Unique / Primary Key (Lock Mode 4)
 TM Contention
Except for ITL, others are Application Issue
itl.sql

Question Time
• Is Initrans a Block Level or a Table Level Parameter ?
• What is the default value of Initrans for a Table ?
• What is the default value of Initrans for an Index ?
• Maximum number of Transaction an Oracle Block can accommodate ?
itl.sql
Database Block Size 8192
Variable Header 48 Bytes
ITL 24 Bytes
8192 – 48 8144
50% of 8144 4072
4072/24 169

ITL Allocation Process Diagram

• Table Level Lock
• Primary Cause
– Update to a Primary Key (A Bad Idea)
– Un-indexed Foreign Keys
User 1
(11:57:50) Updates
update emp set empno=:b1, ename=:b2,
ename=:b3, job=:b4,
mgr=:b5, hiredate=:b6,
sal=:b7, comm=:b8,
deptno=:b9
where rowid=:rowid;
User 2
(11:57:51) Updates
update dept set deptno=:b1,
dname=:b2,
loc=:b3
where rowid=:rowid;
TM Contention

• Delete’s are cascaded to Child Table
User 1
(11:57:50) Deletes
delete from dept where deptno=10;
User 2
(11:57:51) Deletes
delete from dept where deptno=20;
What is “On Delete Cascade” Constraint ?
• User 2 Waits for “TM Contention”
• Primary Cause
– Deleting a Primary Key
– Un-indexed Foreign Keys
Idea is not to create Indexes on all the Foreign Keys
Know your Application / Know your Queries

TM Contention
• Table Level Lock
• Primary Cause
– Update to a Primary Key (A Bad Idea)
– Unindexed Foreign Keys
• Tools that UPDATE every column
• Solution (Quantify Pros & Cons)
– Update only Relevant Columns (No Primary Keys)
– Index Foreign Keys
Another example of “Know your Development Tool”

The Shared Pool
• Objective – to read as much as from Memory
• Stores Parsed version of SQL’s / PL/SQL’s
• Split into various components
– Library Cache, Dictionary Cache and many more…
• LRU Algorithm
• Protected by Latches / Mutexes (Mutual Exclusive Locks)
• Contention : Frequent Allocation / De-Allocation of Memory
• Contention : Frequent Loading of Cursors
Sharing of SQL’s key to effective Shared Pool Utilization
Maintain Coding Standards

Query Processing
Syntax / Semantics Checks
Sharable Parent Cursor
Available ?
Execute
Store Parent Cursor in Library Cache
Query Transformation / Execution
Plans
Store child Cursor in Library Cache
Sharable Child Cursor
Available ?
N
N
Y
Y
Soft Parse
Hard Parse

Sharing of SQL’s / Effective Memory Utilization
• Literals v/s Bind Variables
select empno, ename, sal from emp where empno=7369;
select empno, ename, sal from emp where empno=:b1;
Problem
mpc.sql
select sql_id, sql_text, executions, version_count, sharable_mem, force_matching_signature, plan_hash_value from v$sqlarea
where sql_text like 'select empno, ename, sal from emp where empno%';
SQL_ID SQL_TEXT EXECUTIONS VERSION_COUNT SHARABLE_MEM FORCE_MATCHING_SIGNATURE PLAN_HASH_VALUE
------------- ---------------------------------- ---------- ------------- ------------ ------------------------ ---------------
dyqfcpyqwd9zk select empno, ename, sal from emp 3 1 27554 7320676830101929156 2949544139
where empno=:b1
gzbpcx3suxjk3 select empno, ename, sal from emp 1 1 23419 5733699794739066958 2949544139
where empno=7902
0h7y2gqzrxubu select empno, ename, sal from emp 1 1 23419 5733699794739066958 2949544139
where empno=7369
5ptzb4hqxb1wv select empno, ename, sal from emp 1 1 23419 5733699794739066958 2949544139
where empno=7521

Coding Standard (Multiple Parent Cursors)
Parent
(select
ename from
emp where
empno=:b1)
Child
Parent
(select
dname from
dept where
deptno=:b2)
Child
Parent
(SELECT
ENAME
FROM EMP
WHERE
EMPNO=:B1)
Child
Parent
(select
ename from
emp e where
empno=:b1)
Child
A Parent requires at least one Child Cursor
Obvious Problem

Coding Standard (Multiple Child Cursors)
Child 0
(Schema X)
Child 1
(Schema Y)
Child 2
(Schema X
OICA=10)
Child 3
(Schema X
different bind
length)
Parent
(select * from emp where
ename=:b1)
Obvious – but a problem Problem
My Blog “Authorization Check Failed ! Multiple Child Cursors..” Dec 2013
mcc.sql

Bind Graduation
Bind Name Bind Length Graduate to Child Number
:b1 10 32 1
:b1 30 32 1
:b1 40 128 2
:b1 80 128 2
:b1 140 2000 3
:b1 2040 4000 4
select empno, ename, sal from emp where empno=:b1;
Identify cause of Multiple Child Cursors
v$sql_shared_cursor
Pre 12c

Sharing of SQL
• Why ?
– For Performance Reason
– Scalability
– Effective Resource Utilization (Memory / CPU)
•
• How ?
– Implement Bind (only when required)
– Maintain Coding Standard
test_bind.sql

Production Downtime (real life example)
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 24222 18-Apr-14 11:30:27 401 74.5
End Snap: 24223 18-Apr-14 12:30:16 783 86.0
Elapsed: 59.81 (mins)
DB Time: 1,133.51 (mins)
Cache Sizes
~~~~~~~~~~~ Begin End
---------- ----------
Buffer Cache: 23,552M 23,552M Std Block Size: 8K
Shared Pool Size: 12,288M 12,288M Log Buffer: 15,112K
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 859,548.86 25,693.53
Logical reads: 154,690.90 4,624.00
Block changes: 3,634.57 108.64
Physical reads: 1,515.71 45.31
Physical writes: 296.98 8.88
User calls: 2,817.43 84.22
Parses: 2,842.89 84.98
Hard parses: 156.49 4.68
Sorts: 664.11 19.85
Logons: 0.97 0.03
Executes: 6,454.01 192.92
Transactions: 33.45
19 Active
5.5%

Production Downtime (real life example)
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file sequential read 4,874,348 35,300 7 51.9 User I/O
CPU time 22,056 32.4
ARCH wait on SENDREQ 2,787 13,399 4808 19.7 Network
gc cr block busy 238,851 2,833 12 4.2 Cluster
gcs log flush sync 1,017,044 2,672 3 3.9 Other
-------------------------------------------------------------
Instance Activity Stats DB/Inst: IIMSP/IIMSP2 Snaps: 24222-24223
Statistic Total per Second per Trans
-------------------------------- ------------------ -------------- -------------
parse count (failures) 357,665 99.7 3.0
parse count (hard) 561,605 156.5 4.7
parse count (total) 10,202,613 2,842.9 85.0
64% Failures
Fix High Hard Parse Failures = Unwanted Work
Fix Hard Parses

Client /
Application
Handle
Server Process
Memory
Private SQL Area
SGA
Library Cache
Shared SQL Area
Cursor Concepts
• Private SQL Area
– Parsed SQL Statement
– Session Specific Information
• Shared SQL Area
– Parsed SQL Statement
– Execution Plan
PGA
SGA
scc.sql
Locks

Session Cached Cursors
• Avoids Soft Parse – Better Concurrency
• Maintains Direct Address to the Memory Object
• Locks the Object to avoid flushing out
• Reduces the Contention on Library Cache Latches & Locks & Mutexes
• Cursors are cached after
– 3 Executions within a Session or
– 2 Executions within a Session, if already Hard Parsed by other Session
• Defaults to 50
– Refrain from setting to a very high value
– Monitor parse count (total), parse count (hard), session cache cursor hits

The Buffer Cache
• Objective – to read as much as from Memory
• Caches Data Blocks to eliminate Disk I/O’s
• Blocks are either Dirty or Clean
• LRU Algorithm, Mid Point Insertion & Touch Count (TCH)
• Protected by Latches to maintain LRU and TCH
• Contention : Unwanted I/O’s
• Contention : High Concurrency on a Block
Logical Reads are Faster than Disk Reads
Logical Reads consume CPU
Effective Utilization of Cache – Optimizing I/O’s

Question time…
• Outer Query
select get_dname(deptno) deptno, ename, sal
from emp where deptno in (10,20);
• Query in GET_DNAME function
select dname from dept where deptno=:b1;
test_scalar.sql
Blog on “Cache Buffers Chains Latch Contention…” May 2010
Scalar Subqueries, DETERMINISTIC, RESULT_CACHE
• Assuming, 200 rows are fetched by Outer Query
What would be the total number of executions of the Function ?

Readers do not block Readers / Writers
Writers do not block Readers / Writers
Writer block Writers ONLY at ROW level
Data Layer v/s Cache Layer
Readers MUST block Writers
Single Writer MUST block All Operations
• For Data Layer – Protected by Locks & Enqueues
• For Cache Layer (Raw Memory) – Protected by Latches & Mutexes

Oracle Waits (to name a few)
• db file sequential read
• db file scattered read
• read by other session
• direct path read
• Latch / Mutexes
Eliminating Waits critical for Response Sensitive Application
Single Block Reads
Multi Block Reads
Block Level Contention
Bypass Cache / Smart Scans
Concurrency

Row Migration
row_migration.sql
Higher Value means Impact of Migrated Rows, Chained Rows, >255 Columns
• Impact due to Additional HOP (Additional I/O)
• Impact Index Scans
Index
Block
Table
Block
Index
Block
Table
Block
Table
Blockv/s
Check for table fetch continued row

Question
In terms of performance –
Is there any difference between these queries ?
select a1, a10 from a where rowid=:rowid;
Additional LIO’s due to Intra-Block Chaining
Table A
Rows 10000
Blocks 100
Columns 300
Intra_block.sql
I/O’s (300 Columns) I/O’s (600 Columns)
1 to 45 = 7 I/O’s 1 to 90 = 7 I/O’s
46 to 300 = 8 I/O’s 91 to 345 = 8 I/O’s
346 onwards = 9 I/O’s

Which Query is better ?
Ensure Rewrite is functionally Correct
Don’t Rely on Optimizer Transformation
• Table T1 with Billions of Rows and an Index on C4
• Table T2 with Millions of Rows and Index T2_IDX(A,B)
select t1.c1, t1.c2,
(select t2.c3 from t2
where t2.a = t1.a
and t2.b = t1.b) c3
from t1
Where t1.c4='AIOUG'
(select func(t2,a,b)
from dual) c3
from t1
where t1.c4='AIOUG'
t2.c3
from t1,
t2
where t1.c4='AIOUG'
and t1.a = t2.a
and t1.b = t2.b
(+)
(+)
• Assuming the Predicate on T1 fetches only 1 Row
• Assuming the Predicate on T1 fetches 100,000 Rows
qt_scalar.sql

Explain Plan - Bind Variables Trap
ep.sql
Use Run Time Plan, using dbms_xplan.display_cursor
• Bind with Explain Plan has two problems
– Bind Variables are declared as VARCHAR2 (Default Behavior)
– Plan Generation does not peek into Bind Variable
• Plan, may or may not match (Not Reliable)
• AUTOTRACE has similar problem

Bind Peeking
• Introduced in 9i
• Hard Parse, as if Bind is a Literal
• Appropriate plan based on Bind Value
• 9i & 10g, Hard Parse Bind Value Wins
• 11g – Adaptive Cursor Sharing
• Plan Upgraded, post subsequent execution
• Bad Query Performance, at least Once
bp.sql
How do you take care of a High Performance Application ?
Solution : Use Bind, only when required. BIND_AWARE hint.

Indexes not being Used (Real Life Example)
INST_ID SQL_ID SQL_TEXT EXECUTIONS BUFFER_GETS
-------- ------------- ---------------------------------------- ---------- -----------
1 1kfxns3m02pu3 select distinct TXT_ADDRESS_LINE_1 , TXT 28 1213546962
_ADDRESS_LINE_2 , TXT_APARTMENT , TXT_ST
REET , TXT_CITYDISTRICT , TXT_AREAVILLAG
E , TXT_STATE , NUM_PINCODE from genmst_
location a, Risk_headers b where a.NUM_L
OCATION_CD = b.location_code and a.num_l
ocation_cd = (SELECT location_code FROM
risk_headers WHERE reference_num = :"SYS
_B_0" AND reference_date = TO_DATE (:"SY
S_B_1", :"SYS_B_2") and POLICY_RISK_SERI
AL = :"SYS_B_3")
Enter value for table: RISK_HEADERS
OWNER NUM_ROWS BLOCKS
---------- ---------- ----------
INS 14844896 846555
select distinct TXT_ADDRESS_LINE_1, TXT_ADDRESS_LINE_2, TXT_APARTMENT, TXT_STREET ,
TXT_CITYDISTRICT , TXT_AREAVILLAGE , TXT_STATE , NUM_PINCODE
From genmst_location a,
Risk_headers b
where to_a.NUM_LOCATION_CD = b.location_code
and a.num_location_cd = (SELECT location_code FROM INS.risk_headers
WHERE reference_num = '201412200014630’
AND reference_date = TO_DATE('20/12/2014','DD/MM/YYYY’)
and POLICY_RISK_SERIAL = 1)

--------------------------------------------------------------
| Id | Operation | Name |
--------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | HASH UNIQUE | |
| 2 | NESTED LOOPS | |
| 3 | TABLE ACCESS BY INDEX ROWID | GENMST_LOCATION |
|* 4 | INDEX UNIQUE SCAN | PK_GENMST_LOCATION |
| 5 | TABLE ACCESS BY INDEX ROWID| RISK_HEADERS |
|* 6 | INDEX UNIQUE SCAN | PK_RISK_HEADERS |
|* 7 | TABLE ACCESS FULL | RISK_HEADERS |
--------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("A"."NUM_LOCATION_CD"=TO_NUMBER())
6 - access("REFERENCE_NUM"=TO_NUMBER(:SYS_B_0) AND
"REFERENCE_DATE"=TO_DATE(:SYS_B_1,:SYS_B_2) AND
"POLICY_RISK_SERIAL"=:SYS_B_3)
7 - filter("A"."NUM_LOCATION_CD"=TO_NUMBER("B"."LOCATION_CODE"))
Risk_headers b
where to_a.NUM_LOCATION_CD = b.location_code

Risk_headers b
where to_char(to_a.NUM_LOCATION_CD) = b.location_code
Datatype Mismatch – Should be taken care during Design Phase

Select the Best Index
1. SELECT C FROM T1 WHERE A=:B1;
2. SELECT C, D FROM T1 WHERE A=:B1 AND B=:B2;
a. Index on (A)
b. Index on (B,A)
c. Index on (A,B)
Both the Queries
Only 2nd Query
Both the Queries
pc.sql
What will be the Impact of Index C on 1st Query ?
SQL Performance Analyzer – Proactive Performance Analysis

Select the Best Index
1. SELECT * FROM T1 WHERE OBJECT_ID=100;
2. SELECT * FROM T1 WHERE TEMPORARY=‘Y’ AND OBJECT_ID=100;
3. SELECT * FROM T1 WHERE TEMPORARY=‘Y’;
a. Index on (OBJECT_ID)
b. Index on (OBJECT_ID, TEMPORARY)
c. Index on (TEMPORARY, OBJECT_ID)
SKIP SCAN requires a Low Cardinality Column as a Leading Column
Num_Rows 90410
Object_id Num_Distinct => 90410
Temporary Num_Distinct => 2

Index Myths & Misconceptions
I have to come across a scenerio where Index Rebuild actually Resolved Performance Issues
• Index Rebuild – To make it more Efficient or Small
– Not always True
– In case the Index is Shrinked, it can introduce Block Level Contention
– Index tend to get into their Original Shape (Pre-Rebuild)
– Improving CF of an Index may Impact CF of another Index
– Statistics : branch node splits / leaf node splits & leaf node 90-10 splits
– Exception : Rebuilding an Index to convert from Reverse to NoReverse or vice versa
ir.sql

Understanding Block Split (50-50)
• 50-50 Split caused by
– Updates / Inserts of a Non-Largest Value into a Leaf Block
Update table set value=‘GOA’ where value=‘BAA’; OR insert into table values (‘GOA’)
AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
EAZ
LMN
OAK
ODL
KAY
AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
EAZ
LMN
OAK
ODL
KAY

AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
EAZ
LMN
OAK
ODL
KAY
AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
EAZ
LMN
OAK
ODL
KAY
DELETE INSERT

AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
EAZ
LMN
OAK
ODL
KAY
AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
EAZ
LMN
OAK
ODL
KAY
DELETE

AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
EAZ
LMN
OAK
ODL
KAY
AAA
AAC
AAD
BAA
BCC
CAB
CDA
CDE
CEA
CEB
DAA
DAD
DAY
FAA
EAN
OAK
ODL
KAY
DELETE
EAZ
GOA
LMN
INSERT

– Monotonically Increasing Value (Date-Time/Sequences)
insert into table values (32);
1
2
3
4
5
6
8
9
11
12
14
15
16
18
19
20
21
22
23
24
25
27
28
29
30
1
2
3
4
5
6
8
9
11
12
14
15
16
18
19
20
21
22
23
24
25
27
28
29
30
INSERT

– Monotonically Increasing Value (Date-Time/Sequences)
insert into table values (32);
1
2
3
4
5
6
8
9
11
12
14
15
16
18
19
20
21
22
23
24
25
27
28
29
30
1
2
3
4
5
6
8
9
11
12
14
15
16
18
19
20
21
22
23
24
25
27
28
29
30
32
New Block Allocated
Inserted

Indexing Guidelines
Guideline Reasoning
Create as many, but try to keep the number minimum. Indexes increase Performance, but also consume
disk space and processing resources.
Test First to determine Quantifiable Benefits Same as above. Also, an Index to optimize one
query can impact other queries.
Use the correct type of Index Correct Index usage maximizes performance
Use Btree Indexes in OLTP Btree Indexes are suitable for OLTP as the data is
frequently updated
Use Bitmap Indexes in Data warehouse environments Bitmap Indexes are suitable for Data warehouses
as the data is rarely manipulated
Check for the Column Ordering based on Application /
Query pattern
Avoid Redundant Indexes
Don’t Rebuild Indexes unless you have a solid reason Rebuilding can cause concurrency issues
Monitor your Indexes and drop indexes that aren’t used Doing this frees up space and improves DML
Before Dropping an index, consider marking them Invisible This allows you to better determine if there are
any performance impact before you drop these.

• Requirement – Sales Tax Report
• Join Financial Year Table to Invoices Table
• DB Version 8174 v/s Now
52
Previous
Year
Finance
Table
(20 GB)
Current
Year
Finance
Table
(5 GB)
Invoices
Table
(100 GB)
Invoices
Table
(100 GB)
UNION ALL
Issue :
UAT – 5 Minutes
Prod – 60+ Minutes
2 Scans of 100 GB
Optimizer Evolution…(An Example)

Modification - Rewritten for a Single Scan of Invoices
53
Now, optimizer does it for us by way of a Query Transformation
Join Factorization
Previous
Year
Finance
Table
(20 GB)
Current
Year
Finance
Table
(5 GB)
Invoices
Table
(100 GB)
UNION ALL
Benefit : < 1 Minute
Optimizer Evolution…(An Example)

Developer day v2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Developer day v2

Similar to Developer day v2 (20)

More from AiougVizagChapter

More from AiougVizagChapter (7)

Recently uploaded

Recently uploaded (20)

Developer day v2