Database Performance and Tuning for developers (RAC issues and examples)

Download Database Performance and Tuning  for developers (RAC issues and examples)

Post on 23-Feb-2016

49 views

Category:

Documents

0 download

Embed Size (px)

DESCRIPTION

Database Performance and Tuning for developers (RAC issues and examples). WLCG Service Reliability Workshop 26 November 2007 Miguel Anjo , CERN-Physics Databases team. Outline. Motivation Basics (what you should knew before start developing an application with Oracle backend) - PowerPoint PPT Presentation

TRANSCRIPT

Slide 1

Database Performance and Tuning for developers(RAC issues and examples)WLCG Service Reliability Workshop26 November 2007Miguel Anjo, CERN-Physics Databases team

CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/itCERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it1OutlineMotivationBasics (what you should knew before start developing an application with Oracle backend)Oracle way of executing a query, cursorsConstraints (PK, FK, NN, unique)Bind variablesTransaction definition

OptimizationsExecution PlanOracle RAC architectureConnection managementViews, materialized viewsPartitioningWay Oracle uses indexesIndex Organized TablesIndex function based, reversed, bitmapComposite indexes (FTS example)Analytical functionsPL/SQL - advantages of useSequences (VOMS problem)Inserts vs updates (Phedex example)Hints and plan stability (SAM example)

ConclusionsReferenceDatabase Performance and Tuning for developers - 2CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it2Motivation (1/4)Applications must scale to many usersMany performance problems are not seen in small environmentsVery good performance can be achieved by good application coding practice

Try to make the application performant from the beginning BasicsIf too slow later Optimization (tunning)CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it3Motivation (2/4) FTS exampleDatabase Performance and Tuning for developers - 4

CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it4Motivation (3/4)Sources of performance problems

Using too many resources, such as CPU or disk I/OPotential cause of poor response time (SQL statement takes too long to execute)Waiting for others holding a single resource, such as a lockPotential cause of poor scalability (adding more CPU doesnt allow to run more concurrent users)Causes contention for the resource

Want to avoid these from the beginning!CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it5Motivation (4/4)Tuning Cost/BenefitTimeDesignDevelopmentImplementationProductionTaking a look at tuning cost and benefit over time from application design till full production use Tuning cost increases in timeCost Tuning benefit decreases in timeBenefitCERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it6Basics Oracle way of executingselect FILEID from CNS_FILE_REPLICA where SFN=:B0Hard parse check syntax, tables, Optimization finds best way to get data (stats, indexes)Soft parse check access rightsBind change variables with valuesExecute go to index, get rowid, go to tableFetch (selects) send rows through network to application

Cursors queries in memory there is a maximum number per session

Database Performance and Tuning for developers - 7CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it7Basics ConstraintsPK Primary keyUnique, indexed, not nullFK Foreign keyReference to PK, should be always indexedUx Unique keyUnique, indexedNN Not nullIndexes do not include NULL valuesReference: http://www.ixora.com.au/tips/not_null.htm

Database Performance and Tuning for developers - 8

CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it8Basics Bind variables (1/2)Key to application performanceNo bindselect FILEID from CNS_FILE_REPLICA where SFN=23434Hard parse, optimization and all the restVery CPU intensive, latches/locksBindselect FILEID from CNS_FILE_REPLICA where SFN=:B1Soft parse and all the restFastUSE BIND VARIABLES - 100x faster, friendly to othersReference: http://www.akadia.com/services/ora_bind_variables.htmlDatabase Performance and Tuning for developers - 9CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it9

Basics Bind variables (2/2)Big brother is watching you!

For complex single time queries might be better not to use bind variables, as it hides the current value to the optimizerDatabase Performance and Tuning for developers - 10CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/itBind variables peeking problem10Basics Transactions (1/3)What if the database crashes in middle of several updates?

Transaction is a unit of work that can be either saved to the database (COMMIT) or discarded (ROLLBACK).

Objective: Read consistency, preview changes before save, group logical related SQL

Start: Any SQL operationEnd: COMMIT, ROLLBACK, DDL operation (CREATE TABLE,...)

Changes (UPDATE, DELETE, INSERT) are invisible to other users until end of transaction

Changed rows are locked to other users

If others try to change locked rows, they wait until end of other transaction (READ COMMITTED mode)Get error if try to change locked rows (SERIALIZABLE mode)

If crashes, rollbacks.CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it11Basics Transactions (2/3)User LCG_FTS_PROD1SELECT status FROM t_file WHERE file_id = :B1; (status = ready)

SELECT status FROM t_file WHERE file_id = :B1; (status = ready)

SELECT status FROM t_file WHERE file_id = :B1; (status = done)

User LCG_FTS_PROD2

UPDATE t_file SET status = Transfering WHERE file_id = :B1;

SELECT status FROM t_file WHERE file_id = :B1; (status = Transfering)

UPDATE t_file SET status = Done WHERE file_id = :B1;

COMMIT;

CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it12Basics Transactions (3/3)User LCG_FTS_PROD1

UPDATE t_file SET status = Done WHERE file_id = :B1; wait whats going on? damn1 row updated (aleluia!)

User LCG_FTS_PROD2UPDATE t_file SET status = Transfering WHERE file_id = :B1;1 row updated

COMMIT;

CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it13Optimizations (1/2)Optimize just up to achieve the application needs

Check what are the needsThis graph should take max 3 seconds to appearProfile, where time is spent,Optimize up to the needs,Set as a baseline,Write tests that check if this baseline is not met

Use the database features (Oracle is not MySQL)Or else you can try to use Coral for generic applications

Involve your experiment DBA or PhyDB DBAs in the loop

Database Performance and Tuning for developers - 14CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it14Optimizations (2/2)The steps for Tuning/Optimization

Identify what is slow: an application step is often thousands of lines of code -> intuition, code instrument, profilingUnderstand what happens in this step, (execution plan)Modify application / data so that it is better, sometimes it can be as simple asAdding an indexRemoving an indexChanging the definition of an indexChange the syntax of the select statementCERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it15Execution plan (1/3)Series of steps that Oracle will perform to execute the SQL statementGenerated by the optimizerDescribes steps with meaningful operators - Access Paths

Table Access FullAccess by Index RowIDIndex ScansIndex Unique ScanIndex Range ScanIndex Skip ScansFull ScansFast Full Index ScansIndex JoinsBitmap JoinsHash ScansJoinsNested LoopsHash JoinsSortMerge JoinsCartesian JoinsOuter Joins

CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/it16Execution plan (2/3)EXPLAIN PLANSQL command that allows to find out what is the execution plan before the SQL statement runs

SQL> EXPLAIN PLAN FOR SELECT file_state FROM lcg_fts_prod.t_file WHERE file_id = :B1;

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);-------------------------------------------------------| Id | Operation | Name |-------------------------------------------------------| 0 | SELECT STATEMENT | || 1 | TABLE ACCESS BY INDEX ROWID| T_FILE ||* 2 | INDEX UNIQUE SCAN | FILE_FILE_ID_PK |-------------------------------------------------------

Predicate Information (identified by operation id):---------------------------------------------------

2 - access("FILE_ID"=TO_NUMBER(:B1))

Use a tool (e.g. Benthic Golden - Ctrl-P)CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/itNeed to put code to select explain plan17Execution plan (3/3)The real one - from SQL*Plus SQL> set autotrace traceonlySQL> var :b1 number;SQL> exec :b1 := 3423SQL> SELECT file_state FROM lcg_fts_prod.t_file WHERE file_id = :B1;-----------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |-----------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 11 | 1 (0)| 00:00:01 || 1 | TABLE ACCESS BY INDEX ROWID| T_FILE | 1 | 11 | 1 (0)| 00:00:01 ||* 2 | INDEX UNIQUE SCAN | FILE_FILE_ID_PK | 1 | | 0 (0)| 00:00:01 |-----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("FILE_ID=TO_NUMBER(:B1))

Statistics---------------------------------------------------------- 1 recursive calls 0 db block gets 1 consistent gets 1 physical reads 0 redo size 279 bytes sent via SQL*Net to client 385 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 0 rows processed

CERN - IT DepartmentCH-1211 Genve 23Switzerlandwww.cern.ch/itMaybe join with previous slide18Oracle RAC architectureDatabase Performance and Tuning for developers - 19

CERN - IT DepartmentCH-1211 Genve 23Sw

Recommended

View more >