DB2 UDB Application Tuning 101: The Nuts and Bolts –  Draft Version   Brad Clevinger of  EDS IBM Certified Solutions Exper...
AGENDA <ul><li>Application Tuning Basics  </li></ul><ul><li>Access Path Basics </li></ul><ul><li>Problematic SQL </li></ul...
Abstract Restatement <ul><li>Application Tuning is a critical activity for the DBAs and  </li></ul><ul><li>Developers. Thi...
<ul><li>Application Tuning Basics </li></ul><ul><li>To know that we know what we know, and to know that we do not know wha...
DB2 Optimizer Basics <ul><li>A C Program that calculates the most efficient access plan for a piece of SQL. </li></ul><ul>...
Basic DB2 SQL Processing
<ul><li>Access Path Basics </li></ul><ul><li>All men by nature desire to know.  </li></ul><ul><li>----  Aristotle   </li><...
EXPLAIN PLAN  Access Path Basics <ul><li>METHOD for JOINs </li></ul><ul><ul><li>0 First outer table access or not used </l...
EXPLAIN PLAN Access Path Basics - Continue <ul><li>ACCESSTYPE </li></ul><ul><ul><li>I  Matching Index Scan  </li></ul></ul...
<ul><li>Problematic SQL </li></ul><ul><li>Light tomorrow with today!  </li></ul><ul><li>----- Elizabeth Barrett Browning  ...
Problematic SQL  <ul><li>Inefficient SQL </li></ul><ul><li>Long Run Times </li></ul><ul><li>User Complaints </li></ul><ul>...
Bottlenecks – Summary Level <ul><li>What/Where Performance-related Variables that might cause Bottlenecks? </li></ul><ul><...
Potential Bottleneck Performance Concerns  (Your Martha Stewart Worry List) <ul><li>Architecture </li></ul><ul><ul><li>CPU...
Performance Concerns - Continued  <ul><li>SQL Query </li></ul><ul><ul><li>Appropriate Joins Path – NL vs. MS vs. HJ </li><...
Performance Concerns - Continued   <ul><li>Application Issues </li></ul><ul><ul><li>Poorly written SQL </li></ul></ul><ul>...
Where to Look for It in Existing Programs <ul><li>AUTHID or SECONDARY AUTHID .PLAN_TABLE </li></ul><ul><li>JES2 Logs </li>...
Identifying the Usual Suspects <ul><li>Starting Point </li></ul><ul><li>Find Plans/Packages with Full Tablespace Scans </l...
CSI – Detective questions (Who Do I Vote off the Island or adjust their personalities (tune the SQL))  <ul><li>DNA of SQL ...
<ul><li>1 second is an eternity in DB2 . </li></ul>
<ul><li>“ Sweat the Small Stuff”   </li></ul><ul><li>–  with apologies to Stephen Covey </li></ul>
Myth vs. Reality <ul><li>Myth: “Small Tables Don’t Need Indexes” </li></ul><ul><li>Reality: Though a tablespace scan may s...
SORTs can be a cancer lurking in your CPUs .
SORT Notes <ul><li>AGREGATE FUNCTIONs </li></ul><ul><li>DB2 Optimizer will use SORT Avoidance is possible to prevent sorti...
<ul><li>The primary goal of Application Tuning is to reduce Disk I/O. </li></ul>
<ul><li>Electrons move faster than disk heads. </li></ul>
<ul><li>DB2 UDB Traces </li></ul><ul><li>All truths are easy to understand once they are discovered; the point is to disco...
DB2 Traces <ul><li>DB2 Produces internal SMF Records </li></ul><ul><li>SMF 100 Type Records are Accounting </li></ul><ul><...
DB2 Tracing Panel
SMF 102 Records <ul><li>Class 1 (Elapsed time) Class 2 (In-DB2 time) Class 3 (Wait times) Class 7 (Package level In-DB2) C...
 
Trace Commands <ul><li>START TRACE – starts one or more type of traces </li></ul><ul><li>DISPLAY TRACE – displays trace op...
DB2PM Reports <ul><li>DB2PM Short Report </li></ul><ul><ul><li>DB2 Response Time </li></ul></ul><ul><ul><li>Resources Used...
<ul><li>DB2PM Long Report </li></ul><ul><li>Class 1 Elapse Time   </li></ul><ul><ul><li>Time before the first SQL statemen...
<ul><li>Synchronous I/O Suspension Time  – This is total application wait time for DB2 synchronous I/Os. If the number of ...
<ul><li>Not-Accounted-For DB2 Time  – This is accounting class 2 time that is not part of class 2 CPU or class 3 suspensio...
<ul><li>Benchmarking </li></ul><ul><li>There art two cardinal sins from which all others spring: </li></ul><ul><li>  Impat...
Application Benchmarking <ul><ul><li>What are the Organization Goals? </li></ul></ul><ul><ul><li>Why, Who, What & How Meas...
Tuning Solutions   <ul><li>Normalization is good but causes many JOINs </li></ul><ul><li>Review Cardinality of Data Values...
Session Title:  DB2 UDB Application Tuning 101: The Nuts and Bolts  Session: D Brad Clevinger   EDS [email_address]
Upcoming SlideShare
Loading in …5
×

Click here for a copy of this presentation.

233
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
233
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Discuss generic items. Questions during the presentation A Little of everything – Technical, Philosophy, War Stories and Humor Use analogies and metaphors when I speak Tuning is Organization problem more than Technical problem Solutions are often small for big problem. Effective QA is lacking Development Org
  • Not a perfect process. Things get overlooked NASA Story
  • This section I review the basics at a summary level. Books –IBM Redbooks, Craig Mullins Book
  • Optimizer is IBM most complicated piece of software IBM has dedicated staff at Silicon Valley Labs supporting the Optimizer and problems. Mathematical Models for costing I/O, Buffer Pool Use and Sorts, etc…. Finds lowest cost Access Path. Joins cause problems Ph ds are smart Hint overrides Human are not Optimized – Home Depot example.
  • Stage 1 Processing vs. Stage 2 Filer out pages before the Buffer See Sherryl Larsens presentation of IBM Manuals
  • I review Access Paths at summary level. See your IBM Manuals for details the way the Server applies filters and result sets during the procesing. Understand the SQL Engine.
  • Code translation
  • Access Type R is a red Flag Watch for Matching Index and Mattch Cols is null. F&amp;F Story
  • Most SQL is not problematic. I/O , Accidental Cartesian,
  • Collect Feedback from everywhere and everybody Manage with a Tool – Excel or something. Time is a universal measurement everyone understands. Disk I/O Latency, Seek Time, Read Time, Buffer Transfer Time, etc,,,, may not be universally understood by all.
  • Besides the SQL itself, when executes the following areas can cause Bottlenecks. Areas of potential bottlenecks Out of your control sometimes
  • Out of Developer Control DB2 Trace ca give some answers Network Tracers for Distributed Apps 16/32 Timeout
  • Overhead of Applications Log DB2 Log
  • The IT is the R – Access Type, CPU process intensive operation (JOINS) Sequential Pre-fetch that might tie up the buffer.
  • Get list of plan with SQL with Full Tabblespace scan. This is at least a starting point.
  • High-level questions for each piece of SQL Clock Time is the primary driver. Time is the Universal can identify with.
  • Milli –seconds should be the time frame a SQL Query is resolved and rows returned. Online applications like ebay and bn have huge searches and they come back fast. Banking, Telecom, Insurance…etc… Batch 5 minutes job. Spend 100 hours fixing SQL with one new index.
  • Mr. Covey sold millions of books with his simple advice. Ancient religious and philosophical texts tell us the same thing. This doesn’t apply to DB2 though. Small things in DB2 can cause big problems. Little sorts, little sql can have huge cpu implications ove time if program is designed poorly. DB2 is rarely the problem, but design is. DB2 itself becomes the victim here and DBA must defend it. Rooting out poorly designed programs/SQL can become a politically destroying career move if PM Developers are sensitive to embarrassment. State Code Table
  • State Code Promotion tables can be black hole of CPU. 1 million Customer Accounts looking up State Code Promotions. DBA chose not put index on table. Disaster – Nested Loop Join turned into cpu monster. Absolute Pointer to a row. State Code vs. PRomotions
  • CPUs cycles are not free SORT POOL does have size limits
  • GROUP BY, ORDER BT, DISTINCT, UNION and JOINs
  • High-Level Statement – Some may disagree. Why: Disk I/O is a higher in time compared to other physical operations on a computer.
  • Information in Buffers can be accessed much faster than disk i/o. 1/100,000 thousands of a second Disk Latency – Seek Time, Read Time, Buffer Transfer Time, etc…
  • Before going to DB2 Trace Ask the following: Is tablesspace re-organized, extents? EDSM Pool, Check Bind PAramters Again. Second opinion on Explain Plan Baggage with Traces CA INsight and OMEGMON CPU spikes going on
  • 102 contain detailed performance information Baggage/Overhead associcated with these
  • Enable Trace elements
  • Short Report provides snapshot view
  • This helps identify whether the problem is related to DB2 or some &amp;quot;outside&amp;quot; cause.
  • Synchronous I/O Suspension Time If I/O time is greater than expected, check for I/O contention. A Synchronous read should take from 15-25 milliseconds, depending on the DASD device. If this value is longer, use RMF to check for DASD contention.
  • Kafka ‘s writings are the driest the world had seen in the 20 th Cenrtury. Modennist. Not exactly the Mark Twain touch-felly stuff. New programs to review co designed with DBA to insure new process is DB2 Friendly. I/O is Expensive.
  • Click here for a copy of this presentation.

    1. 1. DB2 UDB Application Tuning 101: The Nuts and Bolts – Draft Version Brad Clevinger of EDS IBM Certified Solutions Expert - DB2 UDB V7.1 Database Administration for OS/390 Oracle 9i & 8i Certified Database Administrator Colorado DB2 Users Group For Z/OS Technical Session D: March 17, 2005 Platform: DB2 UDB for z/OS
    2. 2. AGENDA <ul><li>Application Tuning Basics </li></ul><ul><li>Access Path Basics </li></ul><ul><li>Problematic SQL </li></ul><ul><li>DB2 UDB Traces </li></ul><ul><li>Benchmarking </li></ul>
    3. 3. Abstract Restatement <ul><li>Application Tuning is a critical activity for the DBAs and </li></ul><ul><li>Developers. This presentation reviews the how to, the steps </li></ul><ul><li>involved and the key items the DBA/Developer should look </li></ul><ul><li>for during Application Tuning process. </li></ul>
    4. 4. <ul><li>Application Tuning Basics </li></ul><ul><li>To know that we know what we know, and to know that we do not know what we do not know, that is true knowledge. ----- Copernicus </li></ul>
    5. 5. DB2 Optimizer Basics <ul><li>A C Program that calculates the most efficient access plan for a piece of SQL. </li></ul><ul><li>Parses, Rewrites, Optimizes SQL </li></ul><ul><li>Inputs: </li></ul><ul><ul><li>SQL </li></ul></ul><ul><ul><li>Machine Configuration – No. CPUs & Memory </li></ul></ul><ul><ul><li>DB2 Catalog Tables </li></ul></ul><ul><li>Outputs </li></ul><ul><ul><li>Access Plan for Plan/Package or Dynamic SQL </li></ul></ul>
    6. 6. Basic DB2 SQL Processing
    7. 7. <ul><li>Access Path Basics </li></ul><ul><li>All men by nature desire to know. </li></ul><ul><li>---- Aristotle </li></ul>
    8. 8. EXPLAIN PLAN Access Path Basics <ul><li>METHOD for JOINs </li></ul><ul><ul><li>0 First outer table access or not used </li></ul></ul><ul><ul><li>1 Nested Loop Join </li></ul></ul><ul><ul><li>2 Merge Scan </li></ul></ul><ul><ul><li>3 SORTs to support ORDER BY, GROUP BY, DISTINCT & UNION </li></ul></ul><ul><ul><li>4 Hybrid Join </li></ul></ul>
    9. 9. EXPLAIN PLAN Access Path Basics - Continue <ul><li>ACCESSTYPE </li></ul><ul><ul><li>I Matching Index Scan </li></ul></ul><ul><ul><li>I1 One-fetch Index scan </li></ul></ul><ul><ul><li>N Matching Index Scan for each IN-list value </li></ul></ul><ul><ul><li>R Table space Scan </li></ul></ul><ul><ul><li>M Multiple index scan </li></ul></ul><ul><ul><li>MX Matching Index Scan RID List </li></ul></ul><ul><ul><li>MI Intersection of RID Lists due to ANDed predicates </li></ul></ul><ul><ul><li>MU Union of RID lists, due to ORed predicates </li></ul></ul><ul><ul><li>Blank not used or clustering index for INSERTs or no index for UPDATEs or </li></ul></ul><ul><ul><li>DELETEs WHERE CURRENT OF; or not applicable . </li></ul></ul><ul><li>MATCHCOLS – Indicates number of key columns matched for I, I1, N, & MX. </li></ul>
    10. 10. <ul><li>Problematic SQL </li></ul><ul><li>Light tomorrow with today! </li></ul><ul><li>----- Elizabeth Barrett Browning </li></ul>
    11. 11. Problematic SQL <ul><li>Inefficient SQL </li></ul><ul><li>Long Run Times </li></ul><ul><li>User Complaints </li></ul><ul><li>Production Support & Developer Staff Complaints/Concerns </li></ul><ul><li>High CPU </li></ul><ul><li>High IN DB2 Time </li></ul>
    12. 12. Bottlenecks – Summary Level <ul><li>What/Where Performance-related Variables that might cause Bottlenecks? </li></ul><ul><li>Machine Configuration </li></ul><ul><li>Network </li></ul><ul><li>Application </li></ul><ul><li>SQL Itself </li></ul><ul><li>Design </li></ul>
    13. 13. Potential Bottleneck Performance Concerns (Your Martha Stewart Worry List) <ul><li>Architecture </li></ul><ul><ul><li>CPU </li></ul></ul><ul><ul><li>I/O </li></ul></ul><ul><ul><li>Network </li></ul></ul><ul><ul><li>Concurrency </li></ul></ul><ul><li>Application </li></ul><ul><ul><li>Query </li></ul></ul><ul><ul><li>Logical Design </li></ul></ul><ul><ul><li>Physical Design </li></ul></ul><ul><li>Server(s) </li></ul><ul><ul><li>Configuration </li></ul></ul><ul><ul><li>Optimizer </li></ul></ul><ul><ul><li>Lock Management </li></ul></ul><ul><li>Concurrency </li></ul><ul><ul><li>Maintenance – Reorgs </li></ul></ul><ul><ul><li>Load/Unload </li></ul></ul><ul><ul><li>Index Creation </li></ul></ul><ul><ul><li>Batch Activity </li></ul></ul><ul><ul><li>TSO Users </li></ul></ul>
    14. 14. Performance Concerns - Continued <ul><li>SQL Query </li></ul><ul><ul><li>Appropriate Joins Path – NL vs. MS vs. HJ </li></ul></ul><ul><ul><li>Predicate Filtering </li></ul></ul><ul><ul><li>Parallelism </li></ul></ul><ul><li>Logical Design </li></ul><ul><ul><li>De-normalize from third to second normal form </li></ul></ul><ul><ul><li>Vertical/horizontal segmentation of infrequently referenced data </li></ul></ul><ul><li>Physical Design </li></ul><ul><ul><li>Too many/few indexes </li></ul></ul><ul><ul><li>Summary Data </li></ul></ul><ul><ul><li>Redundant Data </li></ul></ul><ul><ul><li>Partitioning </li></ul></ul>
    15. 15. Performance Concerns - Continued <ul><li>Application Issues </li></ul><ul><ul><li>Poorly written SQL </li></ul></ul><ul><ul><li>Repeatedly issues the same SQL </li></ul></ul><ul><ul><li>Cursor Use/Misuse </li></ul></ul><ul><ul><li>Batch Issues </li></ul></ul><ul><ul><li>Division of work between client and server </li></ul></ul><ul><li>Server Configuration </li></ul><ul><ul><li>Memory </li></ul></ul><ul><ul><li>Sort Pool </li></ul></ul><ul><ul><li>EDM </li></ul></ul><ul><ul><li>Optimizer </li></ul></ul>
    16. 16. Where to Look for It in Existing Programs <ul><li>AUTHID or SECONDARY AUTHID .PLAN_TABLE </li></ul><ul><li>JES2 Logs </li></ul><ul><li>CA7 Reports </li></ul><ul><li>DB2 monitoring tools </li></ul><ul><ul><li>OMEGAMON </li></ul></ul><ul><ul><li>CA INSIGHT </li></ul></ul><ul><ul><li>IBM TOOLS </li></ul></ul><ul><li>DB2 Log for Errors </li></ul>
    17. 17. Identifying the Usual Suspects <ul><li>Starting Point </li></ul><ul><li>Find Plans/Packages with Full Tablespace Scans </li></ul><ul><li>SELECT PROGNAME, QUERYNO, QBLOCKNO, METHOD, ACCESSTYPE,MATCHCOLS,ACCESSNAME, INDEXONLY, PREFETCH </li></ul><ul><li>FROM AUTHID.PLAN_TABLE </li></ul><ul><li>WHERE ACCESSTYPE = ‘R’; </li></ul><ul><li>Cross-check PROGRAM to list of Long Running Jobs Lists </li></ul>
    18. 18. CSI – Detective questions (Who Do I Vote off the Island or adjust their personalities (tune the SQL)) <ul><li>DNA of SQL </li></ul><ul><li>What tables is SQL accessing? </li></ul><ul><li>Why & What Business Condition(s)? </li></ul><ul><li>Frequency? </li></ul><ul><li>For Cursors, how many rows are being FETCHed? </li></ul><ul><li>SORTing needs? </li></ul><ul><li>Locking considerations? </li></ul><ul><li>Does this SQL Play Nice to its Neighbors? </li></ul><ul><li>CPU Bound? </li></ul><ul><li>I/O Bound? </li></ul>
    19. 19. <ul><li>1 second is an eternity in DB2 . </li></ul>
    20. 20. <ul><li>“ Sweat the Small Stuff” </li></ul><ul><li>– with apologies to Stephen Covey </li></ul>
    21. 21. Myth vs. Reality <ul><li>Myth: “Small Tables Don’t Need Indexes” </li></ul><ul><li>Reality: Though a tablespace scan may seem better, it still requires the CPU cycle through the pages. An index has an absolute pointer to the row(s) needed. Let the RID Pool be your friend. </li></ul><ul><li>Reality: Explain Plan quantifies cost of SQL. It does not measure frequency. </li></ul>
    22. 22. SORTs can be a cancer lurking in your CPUs .
    23. 23. SORT Notes <ul><li>AGREGATE FUNCTIONs </li></ul><ul><li>DB2 Optimizer will use SORT Avoidance is possible to prevent sorting of result set if index used because data is already sorted. </li></ul><ul><li>Sorts use CPU. </li></ul><ul><li>Small SORTs are no innocent </li></ul><ul><li>Is SORT Pool sized enough </li></ul><ul><li>Explain Plan don’t consider number of executions </li></ul><ul><li>Cluster Indexes are already SORTed. </li></ul>
    24. 24. <ul><li>The primary goal of Application Tuning is to reduce Disk I/O. </li></ul>
    25. 25. <ul><li>Electrons move faster than disk heads. </li></ul>
    26. 26. <ul><li>DB2 UDB Traces </li></ul><ul><li>All truths are easy to understand once they are discovered; the point is to discover them. ----- Galileo Galilei </li></ul>
    27. 27. DB2 Traces <ul><li>DB2 Produces internal SMF Records </li></ul><ul><li>SMF 100 Type Records are Accounting </li></ul><ul><li>SMF 102 Type Records are Performance </li></ul><ul><li>DB2PM is Performance Analysis Tool </li></ul><ul><li>Batch Reports DB2 Subsystem </li></ul><ul><li>Online Monitor GUI with snapshot live DB2 Subsystem </li></ul>
    28. 28. DB2 Tracing Panel
    29. 29. SMF 102 Records <ul><li>Class 1 (Elapsed time) Class 2 (In-DB2 time) Class 3 (Wait times) Class 7 (Package level In-DB2) Class 8 (Package level Wait) </li></ul>
    30. 31. Trace Commands <ul><li>START TRACE – starts one or more type of traces </li></ul><ul><li>DISPLAY TRACE – displays trace options in effect </li></ul><ul><li>STOP TRACE – Stops any trace </li></ul><ul><li>MODIFY TRACE – Change the IFCIDs on active trace </li></ul>
    31. 32. DB2PM Reports <ul><li>DB2PM Short Report </li></ul><ul><ul><li>DB2 Response Time </li></ul></ul><ul><ul><li>Resources Used – Processor and CPU </li></ul></ul><ul><ul><li>Lock Suspensions </li></ul></ul><ul><ul><li>Application Code Changes </li></ul></ul><ul><ul><li>Wait Times – Processor, I/O Wait or Lock Wait </li></ul></ul>
    32. 33. <ul><li>DB2PM Long Report </li></ul><ul><li>Class 1 Elapse Time </li></ul><ul><ul><li>Time before the first SQL statement. </li></ul></ul><ul><ul><li>DB2 create thread time. </li></ul></ul><ul><ul><li>Time after the DB2 terminate thread. </li></ul></ul><ul><li>Not-in-DB2 Time – This is the calculated difference between Class 1 and Class 2 elapse time. If time spent outside DB2 (but within the DB2 accounting interval) is lengthy, the problem will be found in the application, CICS, IMS, or the overall system, and not within DB2. </li></ul><ul><li>Lock/Latch Suspension Time – This value shows contention for DB2 resources. Check the &quot;Locking Summary&quot; section of this report for additional information, then proceed to the Locking Reports for help. </li></ul>
    33. 34. <ul><li>Synchronous I/O Suspension Time – This is total application wait time for DB2 synchronous I/Os. If the number of I/Os is high, check for: </li></ul><ul><ul><li>A change in access path. </li></ul></ul><ul><ul><li>Application code changes. </li></ul></ul><ul><ul><li>System-wide DB2 bufferpool problems. </li></ul></ul><ul><ul><li>RID pool failures. </li></ul></ul><ul><ul><li>System-wide EDM pool problems . </li></ul></ul><ul><li>Asynchronous Read Suspensions – This is the accumulated time for read I/O done under a thread other than this thread. It includes time for Sequential prefetch, List prefetch, Sequential detection or Synchronous read performed by another thread. The Rule-of-Thumb for Sequential prefetch or Sequential detection (asynchronous I/O) is 1 to 2 milliseconds per page. The Rule-of-Thumb for List prefetch is 3-4 milliseconds per page. Check &quot;Other Read I/O&quot; to locate value. </li></ul>
    34. 35. <ul><li>Not-Accounted-For DB2 Time – This is accounting class 2 time that is not part of class 2 CPU or class 3 suspensions, and is normally due to MVS paging, processor wait time or time spent waiting for parallel tasks to complete. Check the &quot;Not Account&quot; field for this value. </li></ul>
    35. 36. <ul><li>Benchmarking </li></ul><ul><li>There art two cardinal sins from which all others spring: </li></ul><ul><li> Impatience and Laziness. ----- Kafka (1883-1924) </li></ul>
    36. 37. Application Benchmarking <ul><ul><li>What are the Organization Goals? </li></ul></ul><ul><ul><li>Why, Who, What & How Measured </li></ul></ul><ul><ul><li>Proof that Application Executing Efficiently </li></ul></ul><ul><ul><ul><li>1,000,000 Customer Accounts Updated Nightly </li></ul></ul></ul><ul><ul><ul><li>20,000,000 Calls Processed Nightly </li></ul></ul></ul><ul><ul><li>Nightly Batch Jobs </li></ul></ul><ul><ul><li>Online Screens Response Time </li></ul></ul>
    37. 38. Tuning Solutions <ul><li>Normalization is good but causes many JOINs </li></ul><ul><li>Review Cardinality of Data Values </li></ul><ul><li>For all ACCESSTYPE ‘R’s, create index if possible if amount of rows is < 25 % being retrieved in Result Set </li></ul><ul><li>Small Tables with ACCESSTYPE ‘R’s is not always good. </li></ul><ul><li>Index-able Predicates reduce i/o </li></ul><ul><li>Use Clustering Indexes to reduce Sort and CPU Costs </li></ul><ul><li>Nested Loops for JOINs are not always innocent </li></ul><ul><li>Indexes, Indexes, Indexes </li></ul>
    38. 39. Session Title: DB2 UDB Application Tuning 101: The Nuts and Bolts Session: D Brad Clevinger EDS [email_address]
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×