2. Who Are We?
 DBSophic was founded in 2007 as a startup
company funded by “Van Leer Ventures” and
“Shaked Ventures”
 Currently employs 10 people
 Specializes in database performance
optimization solutions
 Technology experts:
 Ami Levin, SQL Server MVP
 Ray Maor, Oracle expert DBA and .NET Developer
 Yaakov Davis, UI expert and .NET Developer

3. Why a Performance Tuning Tool?
 Performance tuning consisted:
 Most of my consulting
 Numerous questions in the forums
 Many of my students’ inquiries
 Probably the most challenging task for DBAs,
even for expert tuners…
 Thousands of objects
 Megabytes of code
 One of the highest resource consumer of IT staff
 Current solutions are inherently limited

4. “Qure” in a Nutshell
 Collects server and database metadata
 Collects schema, objects and server side code
 Scans and analyzes actual data
 Collects batches from pre-recorded trace file
 Analyzes all of the above offline and Generates
recommendations
 Benchmarks batches before and after applying
recommendations
 Automatic application of recommendations

5. #1 – Prepare a Trace File
 RPC: Completed / SQL: Batch Completed
 Data Columns:
• Text Data • Row Counts • Host Name
• Duration • Event Class • SPID
• CPU • App. Name • Is System
• Reads • Database Name • NT User Name
• Writes • Login Name • Error
 Ideally, should cover all database operations
 Templates available for SQL 2005 / 2008
 Minimal basic filters included

6. #2 - Restore a Copy of the DB
 Hardware should be ASAP to production
 Analysis is a READ ONLY operation
 Data scan may consume significant resources
 Can be performed at off-hours on production
 Benchmark is not a READ ONLY operation…

7. What is a “Qure Analysis”?
 A one time process of collecting information and
generating recommendations for a single DB
 All information is stored in a SQL Compact DB
 Each file contains one analysis (+ benchmarks)
 Multiple files - independent of Qure installation
 An analysis is the basis for a license as well

8. Phase 1 – Schema Analysis
 Retrieve instance and database metadata
 Retrieve full schema - table and column
 Very similar to SQL Server internal representation
 Including supporting objects – Keys, Constraints etc.
 Retrieve existing indexes and statistics
 Retrieve server side programming objects
 Views, Procedures, Functions, Triggers etc.
 AOTA is done with T-SQL queries and SMO…

9. Phase 2 – Trace Analysis
 Each batch is fully parsed using ANTLR
 ANother Tool for Language Recognition

10. Phase 2 – Trace Analysis
 Parameters and constants are removed and
batches actually become “Batch Templates”.
 SELECT * FROM T WHERE Col1 = 5
 SELECT * FROM T WHERE Col1 = @P
 SELECT * FROM T WHERE Col1 = fn(x)
 Each executable query is called “Batch instance”
 Batches are fully broken down into the finest
grain detail and stored internally as parsed object
trees

11. Phase 3 – Data Analysis
 All data is scanned and aggregated including
more information than the default statistical
histograms
 String lengths
 Min and Max values
 NULL distributions
 Cardinality
 Precision usage
 This is the most resource consuming phase
 Can be explicitly overridden to use only sampling.

12. Recommendations - Schema
 Redundant objects
 Duplicates and un-trusted objects
 Missing objects
 Primary keys, Constraints, DRI
 Potential design anomalies
 Schema abuse issues
 Data type issues, Unused columns
 Many more…

13. Recommendations - Indexes
 Phase 1 – Static index analysis
 Phase 2 – Index by query
 Phase 3 – Index by objects
 Phase 4 – Heuristic index analysis
 Phase 5 – Index merging & compacting
 Phase 6 – Validation & fine tuning in benchmark

14. Heuristic index analysis???
SELECT Col1, Col2 SELECT Col3
FROM T FROM T
WHERE COl4 < 5 WHERE Col4 = 2
AND
Col1 > 4
Col4 (Col1, Col2) Col4, Col1 (Col3)
Col4, Col1 (Col2, Col3)

15. Recommendations - Rewrites
 Compilation issues rewrites
 Recompilations
 Parameterizations
 Enable index usage rewrites
 Explicit/implicit conversions and functions
 Syntax processing optimizations
 Coding techniques (JOIN vs. EXISTS, DISTINCT)
 UDF to inline code
 Cursor options
 OR to UNION queries

16. Recommendations – Misc.
 Maintenance
 Fragmentations
 Errors
 Update statistics
 General issues
 Hints / SELECT * / Partial identifier Usage
 NOCOUNT settings
 Saved procedure options

17. Benchmark
 Three distinct cycles:
 Baseline – Execute all batches and record performance
 Apply and validate recommendations
 Measure performance of all batches
 May take quite a long time…
 Queries run serially
 Uses cold cache
 Can shorten duration by executing fewer batch
instances

18. Enough Theory…

19. “Qure” Limitations
 Case sensitive databases
 Cross database queries
 CLR and OLE automation objects
 XML and clustered indexes
 Partitioning
 Parsing limitations (~95%)
 Quoted identifiers
 Database compatibility level < 9 (SQL 2005)
 Dynamic queries in server objects

20. Thank you…