4/13/2020
Department of Computer and Information Science,
School of Science, IUPUI
Dale Roberts, Lecturer
Computer Science, IUPUI
E-mail: droberts@cs.iupui.edu
Dale Roberts
1
Oracle Data Dictionary
Data Dictionary: stores all information that is used to manage the objects in the database.
Nomenclature:
USER_% objects you own
ALL_%
DBA_% objects you own, have been granted access to, or public all objects in database.
Road Map Tables:
DICTIONARY (DICT) - describes the Oracle data dictionary tables.
select table_name, comments from DICT where table_name like ‘USER_%’;
Dale Roberts
8-2
Oracle Data Dictionary
• Tables about Database Objects:
– USER_CATALOG (CAT) - tables, views, synonyms, sequences
– USER_OBJECTS (OBJ) - clusters, links, functions, indexes, packages, procedures, sequences, synonyms, tables, triggers, views
– USER_TABLES (TABS)
– USER_TAB_COLUMNS (COLS)
– USER_VIEWS
– USER_SYNONYMS (SYN)
– USER_SEQUENCES (SEQ)
• Constraints:
– USER_CONSTRAINTS
– USER_CONS_COLUMNS
– EXCEPTIONS
• Comments:
– USER_TAB_COMMENTS
– USER_COL_COMMENTS
• Indexes:
– USER_INDEXES (IND)
– USER_IND_COLUMNS
• Clusters:
– USER_CLUSTERS (CLU)
– USER_CLU_COLUMNS
Dale Roberts
8-3
Oracle Data Dictionary
• Links, Snapshots:
– USER_DB_LINKS
– USER_SNAPSHOTS
– USER_SNAPSHOT_LOGS
• Procedures:
– USER_TRIGGERS
– USER_SOURCE
– USER_ERRORS
– USER_OBJECT_SIZE
– USER_ARGUMENTS
• Space Allocation:
– USER_TABLESPACES
– USER_SEGMENTS
– USER_EXTENTS
– USER_FREE_SPACE
•
User Tables:
– USER_USERS
– USER_RESOURCE_LIMITS
– USER_TAB_PRIVS
– USER_SYS_PRIVS
•
Roles:
– USER_ROLE_PRIVS
– ROLE_TAB_PRIVS - DBA privilege required
– ROLE_SYS_PRIVS - DBA privilege required
– ROLE_ROLE_PRIVS - DBA privilege required
Dale Roberts
8-4
Oracle Data Dictionary
• Auditing: (only if auditing turned on by DBA)
– USER_AUDIT_OBJECT
– USER_AUDIT_SESSION
– USER_AUDIT_STATEMENT
– USER_OBJ_AUDIT_OPTS
• Dynamic Tables: (DBA ONLY)
– V$ACCESS - locks currently held on objects
– V$FILESTAT - file read/write statistics
– V$LOCK - non-DDL locks and resources
– V$PROCESS - currently active processes
– V$SESSION - currently active sessions
– V$SGA - size of each component in the SGA (System Global Area)
– V$SYSSTAT - current statistics on entire database
– V$TRANSACTION- info about transactions.
•
Chained Rows:
– Create table CHAINED_ROWS from $ORA_HOME/rdbms/admin/utlchain.sql
– Analyze a table like this: analyze LEDGER list chained rows into CHAINED_ROWS;
• Plan Table:
– Create table PLAN_TABLE from $ORA_HOME/rdbms/admin/utlxplan.sql
– Analyze a query like this: explain plan set Statement_id = ‘A’ for select ...;
Dale Roberts
8-5
Good Design Has a Human Touch
•
– What data is to be captured?
– How should the data be processed?
– How should the data be reported?
Dale Roberts
8-6
Performance and Design
•
– Relax normalization rules by using meaningful keys, pp. 609-612
– Put redundant data into 3NF tables, pp. 612-614
– More memory, p. 614
– Combining smaller tables,
“Kitchen Junk Drawer” approach, p. 615
– Computation Table, p. 616
– Snapshots, Chapter 23
Dale Roberts
8-7
SQL Tuning
•
– Improve response time of interactive programs.
– Improve batch throughput.
– To ensure scalability of applications (load v. perf.)
– Reduce system load for other uses besides DB.
– Avoid hardware upgrades.
•
– Well-tuned applications deliver good performance as number of users or data volume increases.
– Applications which have a linear degradation pattern degrade predictably, usually they are problems responsive to hardware upgrades.
– Exponential degradation patterns are more serious. They tend to be problems that creep up over time, starting benign and unrecognized, later becoming huge problems.
– Bottlenecks are performance problems which are abrupt, like
“hitting a brick wall”. Usually no warning, and no hardware solution.
Dale Roberts
8-8
SQL Tuning
•
– “The Oracle optimizer will tune my statements for me automatically.”
– “I’m not a SQL programmer, I’m a ... VB/PowerBuilder/C++/Java programmer.”
– “I’ll write the SQL, someone else (
DBA
) can tune it for me later.”
– “I’ll tune it later”
– “We can’t afford to tune it”
•
– Early is least costly & better.
– Changing SQL/table designs in the design phase means that no applications need to be re-written.
– Tuning SQL performance when SQL is first written usually means lower testing costs.
– In production systems, testing SQL can sometimes be difficult... change control, production system availability, extra time to deal with larger data volumes.
– Tune SQL early as possible to be most effective and economical.
Dale Roberts
8-9
SQL Tuning
SQL Tuning Process
Prepare for Tuning: gather statistics
Finished
Gather Data:
Explain plan
SQL_TRACE and tk_prof
Yes
SQL
Optimized?
No
Tune the SQL:
Reword SQL
Use Hints
Add or change indexes or clusters
Alter table structure(s)
Dale Roberts
8-10
SQL Tuning
•
– Full Table Scan - gets data from row 1 to high water mark
– Row ID - gets data by physical location. Quickest way to get a row.
– Index Lookup - matches up key value with Row ID
– Hash Key Lookup - computes a Row ID with a mathematical formula applied to key value.
•
– Sort Merge Join
• sorts each table’s key columns
• merges data together
• does not use indexes
– Nested Loops Join
• full table scan used on smaller table
• key values of 1st table joined with the larger table’s index
– Hash Join
• hash key is built for larger table, constructs index on the fly
• smaller table is then fully scanned
• data from smaller table is joined with the hash key index.
Dale Roberts
8-11
SQL Tuning
•
– Rule Based Optimizer
• older optimizer, used since first versions of Oracle.
• set of rules which rank access paths.
• always picks an index over doing full table scan.
– Cost Based Optimizer
• new in Oracle 7.
• takes advantage of database statistics to pick optimal access path.
• To collect table statistics:
ANALYZE TABLE tablename CALCULATE STATISTICS;
•
– RULE, picks only rule based optimizer.
– CHOOSE, picks cost based optimizer if any table in query has been analyzed.
– ALL_ROWS, picks the cost based optimizer and finds an execution plan which is best for the entire query. Good for batch reporting.
– FIRST_ROWS, pick the cost based optimizer and finds an execution plan which is best for the first row. Good for interactive applications .
Dale Roberts
8-12
SQL Tuning
• How to set the optimizer goal:
– Change the database configuration file (init.ora).
OPTIMIZER_MODE=FIRST_ROWS
– Change settings for your session in SQL*Plus.
ALTER SESSION SET OPTIMIZER_GOAL=RULE;
– “Influence” the optimizer with “hints”.
• Example, use rule based optimizer:
SELECT /*+ RULE */ *
FROM EMPLOYEE
WHERE SALARY > 100000;
• Example, use full table scan: select /*+ FULL(E) FULL(D) */ e.employee_id, e.surname, e.firstname
from employee e, department d where d.location=‘Indianapolis’ and d.dept_id = e.dept_id;
• Example, recommend an index: select /*+ index(E, emp_dept_idx) */ e.employee_id, e.surname, e.firstname
from employee e, department d where d.location=‘Indianapolis’ and d.dept_id = e.dept_id;
Dale Roberts
8-13
SQL Tuning
•
– EXPLAIN PLAN, shows the execution plan.
– SQL_TRACE, generates a trace file containing SQL executed by your session and resources used.
– tkprof, formats SQL_TRACE output.
– AUTOTRACE, SQL*Plus command to show exuction plans and statistics in your SQL*Plus session.
– 3rd Party Tools. Numerous GUI tools to quickly show this information, usually expensive.
Dale Roberts
8-14
SQL Tuning
EXPLAIN PLAN
Executing: explain plan for select /*+RULE */ e.surname, e.firstname, e.date_of_birth
from employee e, customers c where e.surname=c.contact_surname
and e.firstname=c.contact_firstname
and e.date_of_birth=c.date_of_birth
order by e.surname, e.firstname;
Formatting Plan Table in a Query: select rtrim(lpad(‘ ‘,2*level)|| rtrim(operation)||‘ ‘|| rtrim(options)||‘ ‘|| object_name) as query_plan from plan_table connect by prior id=parent_id start with id=0;
Execution Plan Query: query_plan
----------------------------------------
SELECT STATEMENT
SORT ORDER BY
NETED LOOPS
TABLE ACCESS FULL CUSTOMERS
TABLE ACCESS BY ROWID EMPLOYEES
INDEX RANGE SCAN EMP_BOTH_IDX
Dale Roberts
8-15
4/13/2020
Dale Roberts
16