Presentation is loading. Please wait.

Presentation is loading. Please wait.

SQL Coding Best Practices for Developers

Similar presentations


Presentation on theme: "SQL Coding Best Practices for Developers"— Presentation transcript:

1 SQL Coding Best Practices for Developers
Platform: DB2 for Linux, UNIX, and Windows SQL Coding Best Practices for Developers Phil Gunning Principal Consultant, Gunning Technology Solutions, LLC Session: G2 May 23, 2005 12:30 – 1:40

2 Outline Best Practices Classes of Predicates Predicate Best Practices
Index SARGable Range Delimiting Data SARGable Predicate Best Practices Local, Order By, Join Predicates Restricting Results Restrict before joining Selectivity DB2 Catalog Queries/Explain NOTES:

3 Outline Index Design DB2 Visual Explain/db2exfmt/Design Advisor
Local, Order By, Join predicates Include Columns Uniqueness DB2 Visual Explain/db2exfmt/Design Advisor Monitor and Evaluate Summary NOTES:

4 Best Practices 1. Use Range Delimiting and Index SARGable Predicates wherever possible 2. Understand DB2 predicate rules 3. Specify most restrictive predicates first 4. Select only columns that are needed 5. Adhere to proper index design techniques 6. Understand inputs to the Optimizer 7. Developers and DBAs collaborate to design proper indexes 8. Evaluate all SQL using Visual Explain/db2exfmt 9. Use Design Advisor to tune SQL/SQL Workloads 10. Consistently monitor and review application performance NOTES:

5 Relational Data Services
Application Relational Data Services Residual predicates COST Data Management Services Data SARGable predicates Range Delimiting Index SARGable NOTES: Before we dig into the details, lets review the DB2 components involved in query execution. The above diagram illustrates the types of DB2 predicates and the DB2 components where they are evaluated. Relational Data Services (RDS) – receives requests from applications and performs operations such as joins, grouping, aggregation, and math. RDS includes the optimizer which generates access paths, and catalog services which manage the metadata describing DB2 objects as well as statistics. Data Management Services (DMS) – DMS controls the data structures for tables, large objects and indexes. It performs update, delete, insert operations on these objects. Index Manager – The index manager processes range delimiting and index SARGable predicates. Predicates that can be processed by the index manager are the least costly to process. Index Manager Data

6 Classes of Predicates Range Delimiting Index SARGable Data SARGable
Predicates that can use an index for a search argument Resolved by Index Manager Data SARGable NOTES:

7 Predicate Example Index
For the following predicate rule examples, assume that an index has been created on Col A, Col B, and Col C Asc as follows: ACCT_INDX: Col A Col B Col C NOTES: This slide describes the columns and index created for the predicate rule examples on subsequent slides.

8 Predicates Range Delimiting Used to bracket an index scan
Uses start and stop predicates Evaluated by the Index Manager NOTES: Range delimiting predicates are used as start, stop or start-stop predicates for index access. Start-stop predicates are similar to matching index access from DB2 for z/OS.

9 Range Delimiting Example
Col A = 3 and Col B = 6 and Col C = 8 In this case the equality predicates on all the columns of the index can be applied as start-stop keys and they are all range delimiting NOTES: Range delimiting predicates are used to bracket an index scan. They provide start and stop key values for an index search or match (start-stop). And they are evaluated by the Index Manager.

10 Predicates Index SARGable Are not used to bracket an index scan
Can be evaluated from the index if one is chosen Evaluated by the Index Manager NOTES: Index SARGable predicates can be evaluated from the index if one is defined. Index SARGable predicates can be used in conjunction with range-delimiting predicates to provide index-only access. They also provide for Index Scans where there is no matching column but other columns in the index can be evaluated. Index scans can provide good performance for tables that are well indexed, and when dealing with large tables. Since index entries are usually much smaller than data rows, scans usually go against only a subset of the data. Also, indexes tend to be better cached in the buffer pool versus tables.

11 Index SARGable Example
Col A = 9 and Col C = 4 Col A can be used as a range delimiting (start-stop) predicate. Col C can be used as an Index SARGable predicate, it cannot be used as a range delimiting since there is no predicate on Col B. Starting with columns in the index, from left to right, the first inequality predicate stops the column matching. NOTES: As previously noted, In all of the predicate examples we are working with composite index that has been created on COLA, COLB, COLC in ASC order.

12 Predicates Data SARGable
Cannot be evaluated by the Index Manager Evaluated by Data Management Services Require the access of individual rows from the base table NOTES:

13 Data SARGable Example Col A = 3 and Col B <= 6 and Col D = 9
Col A is used as a start-stop predicate, Col B is used as a stop predicate, and Col D which is not present in the index is applied as a Data SARGable predicate during the FETCH from the table NOTES: Data SARGable (SARGable stands for predicates that can be used as Search arguments) predicates cannot be evaluated by the Index Manager. Are evaluated by Data Management Services and require the access of individual rows from the base table.

14 Predicates Residual Predicates
Cannot be evaluated by the Index Manager Cannot be evaluated by Data Management Services Require IO beyond accessing the base table Predicates such as those using quantified sub-queries (ANY, ALL, SOME, or IN), LONG VARCHAR, or LOB data which is stored separately from the table Are evaluated by Relational Data Services and are the most expensive type of predicates NOTES:

15 Residual Predicate Example
Col B = 4 and UDF with external action(Col D) In this case the leading Col A does not have a predicate. Col B can only be used as an Index SARGable predicate (where the whole index is scanned). Col D involves a user defined function which will be applied as a residual predicate NOTES: Residual predicates are applied by Relational Data Services and at the highest level in the engine. Residual predicates should be avoided in high volume OLTP applications where response time is key. Think of residual as “what’s leftover after most processing”. If you follow rules for UDFs without external action they can be indexable as follows: predicate specification is present in the CREATE FUNCTION statement the UDF is invoked in a WHERE clause being compared (syntactically) in the same way as specified in the predicate specification there is no negation (NOT operator)

16 RULE#1 Use Range Delimiting and Index SARGable predicates whenever possible NOTES:

17 Query Rewrite The DB2 for Linux, UNIX and Windows optimizer contains significant query rewrite capability Still important to write predicates following the local, order by, join rule Query rewrite will take care of most transformations that need to be made However, if predicates are missing or indexes are not available to support the access paths, your SQL will not be able to take advantage of query rewrite NOTES:

18 Query Rewrite The DB2 for Linux, UNIX and Windows optimizer contains significant query rewrite capability Still important to write predicates following the local, order by, join rule Query rewrite will take care of most transformations that need to be made However, if predicates are missing or indexes are not available to support the access paths, your SQL will not be able to take advantage of query rewrite NOTES:

19 Index Review An index is a data structure that contains column values and a pointer to the table data Primary key – Unique Index If a primary key is defined, DB2 automatically creates a unique index to enforce the PK constraint Secondary Index Created to support access to frequently referenced columns Indexes provide efficient access (in terms of CPU and IO) to columns found in the table Just like an index entry in a book, an index in a database enables rapid lookup of associated table entries

20 Index Characteristics
Index entries are usually much smaller (subset) of all table columns Can fit more index entries on a page Allows for more efficient use of buffer pool Separate index buffer pool Enables often used index pages to remain in the buffer pool longer More logical IO than physical IO NOTES: Every IO consists of a logical IO and may also include a physical IO. Logical IO requests are issued and if page found in the buffer pool then no physical IO is needed…but if not found in the buffer pool then a physical IO request is issued and the appropriate index page(s) are brought into the buffer pool.

21 A Word About Index Structures
B+ -tree used to store index entries Provides for a tree structure that is balanced to a constant depth from the root to the leaf blocks along every branch Usually more efficient (less costly) than a table scan NOTES:

22 NOTES: In the above example, index entries are stored using a B+-tree structure. The ROOT level is the first level and it is always level 0. The root points to intermediate levels or nodes, Level 1 in the above example. Intermediate entries contain pointers to the highest key value in the next lower level, level 2 in our example. Level 2 contains pointers to the actual table rows, and are known as leaf nodes. Only leaf nodes point to table data (value, RID). The number of levels in the index can impact performance. Indexes with 4 levels or more do not perform as well as those with fewer as they require more logical and physical IO. We will see later how the REORGCHK utility may recommend a REORG of an index with more than 3 levels in the index.

23 NOTES: In the Index-Only example, the database only has to read the ROOT node, then the Intermediate node to fo find the correct leaf node entry, then a probe of the Leaf node to obtain the values from the index. In this example two Logical IOs are required: 1 to the Intermediate node and 1 to the Leaf node. Since the index is probably well cached in the buffer pool, physical IO is probably not required.

24 NOTES: DB2 accesses the root node (which in all likelihood is already cached in the buffer pool) and then reads the intermediate node to obtain the pointer to the leaf node that contains the RIDS of the containing start range. This leaf node may contain all RIDS in the range or DB2 may have to read the adjacent leaf nodes to obtain all RIDS. If all the columns are not contained within the index, once all RIDS are obtained, DB2 goes to the table extents that hold the rows and retrieves the data. Base Table

25 Select deptnumb, deptname from db2admin.org
Where deptnumb < 20 NOTES: This slide is a Visual Explain of the above SQL. It depicts an IXSCAN of the XXYY index on the DB2ADMIN.ORG table. Note that the index contains the following columns in the following order: DEPTNAME, DEPTNUMB

26 Range Delimiting Example
NOTES: This slide is a drilldown of the ISCAN operator from the visual explain from the previous slide. The predicate on DEPTNUMB is used as a Start predicate as indicated. This gives the index manager a starting point for the index scan. The index manager finds all key values where DEPTNUMB < 20 and then retrieves other columns via an index scan. If all columns exist in the index, then index only access can be achieved.

27 NOTES: When an index is used, only the qualified rows of a table are accessed. However, with a table scan as shown above, all rows are accessed. This includes rows that were deleted, but not yet removed via a reorg. In the above example, there is an index on the Account table but as we can see it is not used.

28 Created this index and ran this SQL
Table Scan Example Created this index and ran this SQL CREATE INDEX "DB2ADMIN". "YYZZ" ON "DB2ADMIN"."ORG" ("DEPTNUMB" ASC, "DEPTNAME" ASC, "DIVISION" ASC) Select deptnumb, deptname from db2admin.org Where deptnumb =20 and deptname like 'b%' or division = 'midwest' and manager = 88 or location like 'bo%' NOTES: This slide depicts a table scan given the index available and SQL statement. It was used to generate the Visual Explain table operator in the next slide.

29 Table Scan Example NOTES: Even though there was an index on this table, the optimizer determined that it would be cheaper to access the base table. This is because the manager column was not indexed. CREATE INDEX "DB2ADMIN"."YYZZ" ON "DB2ADMIN"."ORG" ("DEPTNUMB" ASC, "DEPTNAME" ASC, "DIVISION" ASC) PCTFREE 10 CLUSTER MINPCTUSED 10 ALLOW REVERSE SCANS;

30 Table Scan Rules of Thumb
If > 20-25% of the rows will be read, good likelihood of table scan If 0.5 – 20% of the rows are read, likely index access but this can vary depending on numerous factors Exact formulas used are complex and not very useful for practical purposes NOTES:

31 Rule #2 Understand and apply DB2 predicate rules NOTES:

32 WITH DEPT_MGR AS ( SELECT DEPTNO, DEPTNAME, EMPNO, LASTNAME, FIRSTNME, PHONENO FROM DEPARTMENT D, EMPLOYEE E WHERE D.MGRNO=E.EMPNO AND E.JOB='MANAGER' ), DEPT_NO_MGR AS ( SELECT DEPTNO, DEPTNAME, MGRNO AS EMPNO FROM DEPARTMENT EXCEPT ALL SELECT DEPTNO, DEPTNAME, EMPNO FROM DEPT_MGR ), MGR_NO_DEPT (DEPTNO, EMPNO, LASTNAME, FIRSTNME, PHONENO) AS ( SELECT WORKDEPT, EMPNO, LASTNAME, FIRSTNME, PHONENO FROM EMPLOYEE WHERE JOB='MANAGER' EXCEPT ALL SELECT DEPTNO,EMPNO, LASTNAME, FIRSTNME, PHONENO FROM DEPT_MGR ) FROM DEPT_MGR UNION ALL SELECT DEPTNO, DEPTNAME, EMPNO, CAST(NULL AS VARCHAR(15)) AS LASTNAME, CAST(NULL AS VARCHAR(12)) AS FIRSTNME, CAST(NULL AS CHAR(4)) AS PHONENO FROM DEPT_NO_MGR UNION ALL SELECT DEPTNO, CAST(NULL AS VARCHAR(29)) AS DEPTNAME, EMPNO, LASTNAME, FIRSTNME, PHONENO FROM MGR_NO_DEPT ORDER BY 4

33 A More “Complicated” Example
NOTES: Explain of the previous query using a common table expression. Note table scans, nested loops and hash joins. No index access. Cost of about 300 timerons.

34 Table Scan Example NOTES:

35 Created Two Indexes CREATE INDEX "DB2ADMIN"."AABB" ON "DB2ADMIN"."DEPARTMENT" ("DEPTNO" ASC, "DEPTNAME" ASC, "MGRNO" ASC) PCTFREE 10 CLUSTER MINPCTUSED 10 ALLOW REVERSE SCANS; CREATE INDEX "DB2ADMIN"."CCDD" ON "DB2ADMIN"."EMPLOYEE" ("EMPNO" ASC, "FIRSTNME" ASC, "MIDINIT" ASC, "LASTNAME" ASC, "WORKDEPT" ASC, "PHONENO" ASC) PCTFREE 10 MINPCTUSED 10 NOTES:

36 Index Scan on AABB index
Index Scan Example Index Scan on AABB index NOTES:

37 Index Scan of entire index then fetch from table
Full Index Scan Index Scan of entire index then fetch from table

38 Index on: DEPTNAME,DEPTNO MGRNO
NOTES: DB2 can start scanning at the left most leaf node and scan successive leaf nodes. If all the columns are not contained within the index, once all RIDS are obtained, DB2 goes to the table extents that hold the rows and retrieves the data. Index scans may be more beneficial than a table scan for large tables versus small tables….but it is up to the optimizer to determine! RIDS Base Table

39 Selectivity Catalog Queries
SELECT INDNAME, NPAGES, CARD, FIRSTKEYCARD AS FIRSTK, FIRST2KEYCARD AS F2KEY, FIRST3KEYCARD AS F3KEY, FIRST4KEYCARD AS F4KEY, FULLKEYCARD AS FULLKEY, NLEAF, NLEVELS AS NLEV, CLUSTERRATIO AS CR, CLUSTERFACTOR AS CF, UNIQUERULE AS U, T.COLCOUNT AS TBCOL, I.COLCOUNT AS IXCOL FROM SYSCAT.TABLES T, SYSCAT.INDEXES I WHERE T.TABSCHEMA = I.TABSCHEMA AND T.TABSCHEMA = ‘PGUNNING' AND T.TABNAME = I.TABNAME AND CARD > ORDER BY CARD DESC, 1; NOTES: This query displays key index statistics for you to assess the adequacy of existing indexes currently defined in your database for the schema specified.

40 NLEVELS > 3 NOTES: This slide contains a bad example of the column used as the first column in the index. In this case FIRSTKEYCARD for Index PS_ITEM has 3 distinct values, and our CARD is Note that two indexes have NLEVELS more than 5, and one has NLEVELS more than 4. Since response time tends to degrade when indexes have more than 4 levels, REORGCHK should be run on this index and also the columns used in the index should be reevaluated.

41 XBOOKING1 Selectivity = Number of Distinct Values / CARD
1229/ = .003 Meets our rule for selectivity < .10 NOTES: Compute the selectivity of an index predicate when evaluating what columns should be in your indexes and which ones shouldn’t be. We’ll see how we can also get this value from DB2 Visual Explain. FIRSTKEYCARD from SYSCAT.INDEXES indicates the number of distinct values in the index for the first column in the index. Since the first column in an index is used extensively, it should have high (good) selectivity. High selectivity means that it will only cause a small number of rows to be returned. The lowed the number for selectivity the better. This may be a confusing oxy moron as we normally don’t view high as meaning selective. Many times one index is selected by the optimizer as a driving index that it tends to use for access to joined-to tables. That’s why multiple indexes with the same column as the first column in the index are usually redundant and can cause path problems. XBOOKING2 Selectivity = Number of Distinct Values / CARD 111217/ = .285 Does not meet our rule for selectivity < .10

42 Data Specification Specify the most restrictive predicates first
Select only those columns needed Use business sense when developing reports for end users They should not be so voluminous that the average end user will not be able to use them anyway Haven’t we all seen these monster reports that consume lots of CPU and IO and never get looked at? NOTES:

43 Restriction Restrict before you join Example:
“Select * from acct, dept where acct.nbr = dept.acct_id and acct.loc = 5” In this example, acct.loc = 5 is a restrictive expression It will be applied before the join thus the number of rows joined decreases With just the join expression, the number of rows increase as many rows in dept might match the ones in acct NOTES:

44 Fast Retrieval OPTIMIZE FOR N ROWS CLAUSE
Can guide the optimizer to use an access path to quickly return N Rows Also effects the size of the number of rows blocked in the communications buffer Useful when the number of rows you want is significantly less than total number of rows that could be returned Can slow performance if most of the rows are going to be processed NOTES:

45 Fetch First FETCH FIRST N ROWS ONLY CLAUSE FOR FETCH ONLY CLAUSE
Used to restrict fetching to only N rows regardless of number of rows that there may have been in the result set if not specified FOR FETCH ONLY CLAUSE Use when no updates are planned Query can take advantage of row blocking Only S locks taken on rows retrieved Improved concurrency NOTES: This clause also specifies how many rows are blocked in the communication buffer. If used with OPTIMIZE FOR N ROWS, the lower of the two values is used to determine the size of the communication buffer.

46 Rule #3 & 4 Specify most restrictive predicates first
Select only those columns needed NOTES: The specification of additional columns that are not needed could cause an otherwise indexable access to become non-indexable or data SARGable. Keep this in mind.

47 Selectivity Selectivity of an index column indicates the number of rows that will satisfy the predicate condition Formula: Selectivity = number of distinct values / number of rows in the table Selectivity of predicates should be < .10, that is will return less than 10% of the table rows to the requesting application or to the intermediate result set if more than a two-way join NOTES: The relationship between a predicate and the number of rows it chooses exemplifies the concept of selectivity. A predicate's selectivity is the ratio of the number of rows satisfying the WHERE clause to the total number of rows in the table.

48 Index Design Indexes should be created on local, order by, join predicates and foreign keys Primary key unique index created by default Many times the primary key will be used by the optimizer as the driving index due to uniqueness and selectivity Frequently accessed columns with good selectivity Avoid Redundant Indexes as they are typically not used or offer additional unnecessary choices to the optimizer Number of Indexes Determined by business rules OLTP 3 indexes Fewer indexes offer fewer choices to the optimizer Mixed (ERP/CRM/SCM) 3-5 indexes DW 5 or more NOTES: Indexes should be created as part of the physical design process on Local, order by, join predicates and foreign keys. This is also known as “the Bonnie Baker” method. Local predicates can give be used for index-only access where appropriate. Order by predicates can eliminate a sort. Join predicates can eliminate a Cartesian product, and provide good join filtering…Foreign keys aid joins since child tables are frequently queried along with the parent table.

49 Rule#5 Adhere to proper index design techniques NOTES:

50 DB2 Optimizer What inputs does the Optimizer consider/analyze during statement optimization? Important to know as some of these inputs can cause suboptimal access paths if not current RUNSTATS not current Buffer pool changes Configuration parameter changes NOTES:

51 Buffer pool size (npages)
To determine how much of the buffer pool may be available for tables/indexes involved. SORTHEAP DB CFG parameter To determine if a piped sort can be used. LOCKLIST To determine amount of memory available for storing locks for this access plan. CPU Speed Speed of CPUs available. PREFETCHSIZE To determine I/O costs. Value of INTRA_PARALLEL DBM CFG Parameter To determine if parallelism may be used. Type of table space and number of containers To determine I/O costs and degree of I/O parallelism. SHEAPTHRES Determine maximum amount of shared SORTHEAP available. DISK Speed To estimate I/O costs. NOTES:

52 Degree of clustering To determine effectiveness of prefetching and to determine how clustered data is. Indexes Available To determine if index access cost. DFT_DEGREE Default degree of parallelism. AVG_APPLS To determine amount of buffer pool space available for a query. MAXLOCKS Percent of LOCKLIST used by a single application before lock escalation occurs. LOCKLIST Size of memory area reserved for locks. DFT_QUERYOPT The default optimization class to be used. STMTHEAP Size can effect amount of optimization conducted. COMM_BANDWITH Used for partitioned databases. MAX_QUERYDEGREE Maximum number of subagents to be used if intra_parallel enabled.

53 REOPT Bind Option Can be used to enable query reoptimization for dynamic and static SQL that have host variables, parameter markers or special registers Can set the REOPT option to one of three values None – No reoptimization will take place, the default behavior Once – the access plan will use real values the first time and the plan will be cached in the package cache Always – the access path will always be compiled and reoptimized using the values of the parameter markers, host variables, or special registers known at each execution time NOTES:

54 Lock Wait Mode Application can specify individual lock wait mode strategy Take one of the following actions when it cannot obtain a lock: Return and SQLCODE or SQLSTATE Wait indefinitely for a lock Wait a specified amount of time for a lock Use value of locktimeout DB CFG parameter SET CURRENT LOCK TIMEOUT statement Specifies number of seconds to wait for a lock Applies to row, table, index key, and MDC block locks NOTES: Uses new CURRENT LOCK TIMEOUT SPECIAL REGISTER.

55 KEEP UPDATE LOCKS A lock type can be specified for queries that perform updates Allows FOR UPDATE cursors to take advantage of row blocking RR or RS can be used when querying a read only results table Allows positioned cursor updates to succeed NOTES:

56 Rule#6 Understand inputs to the DB2 Optimizer NOTES:

57 DB2 Visual Explain Use it as part of testing and development process
Developers can use any type of DB2 explain or other SQL Analysis tool but it must be integrated into the development process DBAs also use all types of explain in support of application development testing and in fixing production problems Evaluate all SQL using Visual Explain/db2exfmt or some type of explain tool Monitor on a recurring basis NOTES: Throughout this presentation we have looked at and discussed various visual explain examples. Developers can develop good performing SQL for production implementation by following these methods.

58 Rule #7 Developers and DBAs collaborate to develop applications that perform when implemented in production NOTES:

59 Design Advisor DBAs work with developers using Design Advisor to evaluate individual SQL statements and workloads to identify possible index solutions, clustering indexes, MDC indexes, and MQT recommendations DBAs use the package cache option to look for high cost SQL in the package cache Best used as part of physical design process but use is ongoing NOTES: Design Advisor (formerly known as index advisor) is a valuable tool for DBAs to use in conjunction with developers to develop top performing SQL and workloads. It has been greatly enhanced in V8.2 and can recommend the following: MQTs MDC indexes Clustering index Allow reverse scan option on indexes Read in the contents of package cache Can identify unused indexes* (use with caution on individual SQL statements as it doesn’t consider the entire workload)

60 db2advis -d gunprd -I wildsortsql.txt > wildsqlixadvout.txt
execution started at timestamp found [1] SQL statements from the input file Calculating initial cost (without recommmended indexes) [ ] timerons Initial set of proposed indexes is ready. Found maximum set of [1] recommended indexes Cost of workload with all indexes included [ ] timerons total disk space needed for initial set [ ] MB total disk space constrained to [ ] MB 1 indexes in current solution [ ] timerons (without indexes) [ ] timerons (with current solution) [%99.69] improvement Trying variations of the solution set.-- -- execution finished at timestamp -- LIST OF RECOMMENDED INDEXES -- =========================== -- index[1], MB CREATE INDEX WIZ1 ON "PUSER "."T_FILE" ("FILE_STATUS_NUM" DESC) ; -- ===========================-- Design Advisor tool is finished. NOTES: This was arrived at by analyzing the package cache and finding a high cost sort statement. It was input to Design Advisor with the above results. In V8.2, SQL from the package cache can be input directly to Design Advisor.

61 Rule #8 Evaluate all SQL using Visual Explain/db2exfmt or some type of explain tool Use Design Advisor to tune SQL statements and workloads NOTES:

62 RUNSTATS RUNSTATS should be run on a regular schedule
After a reorg, change in prefetchsize, static SQL change, growth in data What is a regular schedule? Nightly or Weekly depending on many things Data changes by 10% or more Indexes changed or added Use SAMPLING in V8.1+, and the WITH DISTRIBUTION clause If simple and straight forward queries and no skewed data then don’t use WITH DISTRIBUTION In database with all dynamic SQL like most ERP, CRM, SCM packages today, RUNSTATS may be needed nightly if data changes as noted above Most shops that get consistent performance schedule RUNSTATS either nightly or weekly NOTES:

63 Monitoring If you don’t know how performance was, you can’t tell why it is suddenly bad Application developers can monitor the performance of applications under their control by: Monitoring service levels Periodic explains in Production Checking with end users/help desk Querying the performance repository DBAs should implement and maintain a continuous monitoring program using snapshots, snapshot repository, and event monitors when needed NOTES:

64 Monitoring Compute performance metrics on an hourly/daily basis and track and evaluate over time With such a system established, you will be able to answer such questions as “What was this SQL running like yesterday, last week, and last month?” Were there any database problems today? Why has this query suddenly gone from running in 30 seconds to 30 hrs? NOTES:

65 Rule#10 Implement a monitoring solution that provides both real-time and historical performance data Build canned reports to identify top 10 SQL statements, in terms of User CPU, System CPU, rows read, sorts, and sort time Implement a “closed loop” system where problems are tracked until they are resolved NOTES:

66 Questions? NOTES:

67 SQL Coding Best Practices for Developers Session: G2
THANK YOU! Phil Gunning Gunning Technology Solutions, LLC NOTES:


Download ppt "SQL Coding Best Practices for Developers"

Similar presentations


Ads by Google