exploring oracle database performance tuning best practices for dbas and developers

Download Exploring Oracle Database Performance Tuning Best Practices for DBAs and Developers

Post on 21-Feb-2017

479 views

Category:

Documents

7 download

Embed Size (px)

TRANSCRIPT

  • Exploring Oracle Database Performance Tuning Best Practices for

    DBAs and Developers

  • 38 years old

    * Married + 3

    * 15 years AS a dba, consultant, instructor, architect.

    * CEO @ DBcs ltd.

    * Was cto @ johnbryce israel

    * Oracle certified professional

    * Microsoft sql server certified professional

    Aaron@dbcs.co.il

    www.dbcs.co.il

    About Me :

  • Agenda

    Oracle Database Architecture Overview

    The connection between SQL tuning & Instance tuning

    The connection between database & operating system

    Common bottlenecks - Drill down

    How do you identify the source of the problem?

    Focusing on benchmark issues: physical IO, logical reads, shared pool, buffer cache

    Solutions: where do you start and what order to work?

    Introduction to SQL and Application Tuning

    The Oracle Optimizer:

    Rule Based Optimization (overview)

    Cost Based Optimization

    The Different Modes of the Cost Based Optimizer

    Execution Plans

    Data Access Methods

    Indexes Types, Classifications, Advantages & Disadvantages

    Sort Usage Guidelines

    When and What to Tune?

    Clustering factor

    Data Types are Important

    Integrity Constrains are Important

    Reasons for Inefficient SQL Performance

    Using Bind Variables

    Restructuring SQL Statements

    Shared SQL and Cursors

    Advanced SQL and Application Topics

  • "You have to be constantlyevolving and in some cases

    DBAs/Programmers dont do that becausethey know how they did it

    years ago and they want tokeep doing it that way..."

  • Quote from Thomas Kyte's book

    if you want a 10 step guide to tuning a query, buy a piece of software. You are not needed in this process, anyone can put a query in, get a query out and run it to see if it is faster. There are tons of these tools on the market. They work using rules (heuristics) and can tune maybe 1% of the problem queries out there. They APPEAR to be able to tune a much larger percent but that is only because the people using these tools never look at the outcome -- hence they continue to make the same basic mistakes over and over and over.

    If you want to really be able to tune the other 99% of the queries out there, knowledge of lots of stuff -- physical storage mechanisms, access paths, how the optimizer works -that's the only way.....Think about it for a moment. If there were a 10 step or even 1,000,000 step process by which any query can be tuned (or even X% of queries for that matter), we would write a program to do it. Oh don't get me wrong, there are many programs that actually try to do this - Oracle Enterprise Manager with its tuning pack, SQL Navigator and others. What they do is primarily recommend indexing schemes to tune a query, suggest materialized views, offer to add hints to the query to try other access plans. They show you different query plans for the same statement and allow you to pick one. They offer "rules of thumb" (what I generally call ROT since the acronym and the word is maps to are so appropriate for each other) SQL optimizations - which if they were universally applicable - the optimizer would do it as a matter of fact. In fact, the cost based optimizer does that already - it rewrites our queries all of the time. These tuning tools use a very limited set of rules that sometimes can suggest that index or set of indexes you really should have thought of during your design.

  • Oracle Database Architecture Overview

  • Oracle Database Architecture Overview

  • Oracle Database Memory Structures: Overview

    Backgroundprocess

    Serverprocess

    Serverprocess

    SGA

    Redo log buffer

    Database buffercache

    Java pool Streams pool

    Shared pool Large pool

    AggregatedPGA

  • Database Buffer Cache

    Is a part of the SGA

    Holds copies of data blocks that are read from data files

    Is shared by all concurrent processes

    Database writer process

    Databasebuffercache

    SGA

    Data files

    DBWn

    Serverprocess

  • Redo Log Buffer

    Is a circular buffer in the SGA (based on the number of CPUs)

    Contains redo entries that have the information to redo changes made by operations, such as DML and DDL

    Log writer process

    Redo logbuffer

    SGA

    Redo log files

    LGWR

    Serverprocess

  • SGA

    Shared Pool

    Is part of the SGA

    Contains:

    Library cache

    Shared parts of SQL andPL/SQL statements

    Data dictionary cache

    Result cache:

    SQL queries

    PL/SQL functions

    Control structures

    Locks

    Library cache

    Datadictionary

    cache(row cache)

    Control structures

    Resultcache

    Serverprocess

    Shared pool

  • Processing a DML Statement: Example

    Database

    Data files

    Control files

    Redolog files

    Userprocess

    Shared pool

    Redo logbuffer

    Serverprocess 3

    51 Library cache

    24

    Databasebuffer cache

    DBWnSGA

    2

  • COMMIT Processing: Example

    Database

    Data files

    Control files

    Redolog files

    Userprocess

    SGA

    Shared pool

    Redo logbuffer

    Serverprocess 1

    3Library cache

    Databasebuffer cache

    DBWn

    2LGWR

    SGA

  • Program Global Area (PGA)

    PGA is a memory area that contains:

    Session information

    Cursor information

    SQL execution work areas:

    Sort area

    Hash join area

    Bitmap merge area

    Bitmap create area

    Work area size influences SQL performance.

    Work areas can be automatically or manually managed.

    StackSpace

    User Global Area (UGA)

    UserSession

    Data

    CursorStatus

    SQLArea

    Serverprocess

  • Background Process Roles

    PMON SMON ARCnDBWn LGWRCKPT

    Databasebuffercache

    Shared poolSGARedo log

    buffer

    MMON CJQ0 QMNnRCBG MMAN

  • SGA

    Javapool

    Fixed SGA

    Redo log buffer

    Databasebuffer cache

    Automatic Shared Memory Management

    Which size to choose?

    Large poolShared pool

    Streamspool

    SGA_TARGET + STATISTICS_LEVEL

    Automatically tuned SGA components

  • Automated SQL Execution Memory Management

    Backgroundprocess

    Serverprocess

    Serverprocess

    PGA_AGGREGATE_TARGET

    Which size to choose?

    AggregatedPGA

  • Automatic Memory Management

    Sizing of each memory component is vital for SQL execution performance.

    It is difficult to manually size each component.

    Automatic memory management automates memory allocation of each SGA component and aggregated PGA.

    Buffe

    r cache

    Larg

    e p

    ool

    Share

    d p

    ool

    Java p

    ool

    Stre

    am

    s p

    ool

    Priv

    ate

    SQ

    L a

    reas

    Oth

    er S

    GA

    Untu

    nab

    leP

    GA

    Fre

    e

    MEMORY_TARGET +STATISTICS_LEVEL

    MMAN

  • The connection between SQL tuning & Instance

    tuning

  • Database tuning is the process of tuning the actual database, which

    encompasses the allocated memory, disk usage, CPU, I/O, and underlying

    database processes.

    Tuning a database also involves the management and manipulation of the

    database structure itself, such as the design and layout of tables and indexes.

    Additionally, database tuning often involves the modification of the database

    architecture in order to optimize the use of the hardware resources available.

    There are many other considerations when tuning a database, but these tasks

    are normally accomplished by the database administrator.

    The objective of database tuning is to ensure that the database has been

    designed in a way that best accommodates expected activity within the

    database.

    The connection between SQL tuning & Instance

    tuning

  • SQL tuning is the process of tuning the SQL statements that access

    the database.

    These SQL statements include database queries and transactional

    operations such as inserts, updates, and deletes.

    The objective of SQL statement tuning is to formulate statements

    that most effectively access the database in its current state, taking

    advantage of database and system resources and indexes.

    The connection between SQL tuning & Instance

    tuning

  • Both database tuning and SQL statement tuning must be performed to achieve

    optimal results when accessing the database.

    A poorly tuned database may very well render wasted effort in SQL tuning, and

    vice versa.

    Ideally, it is best to first tune the database, and then ensure that indexes exist

    where needed, and then tune the SQL code.

    The connection between SQL tuning & Instance

    tuning

  • The connection between database & operating

    system

  • Question: We are in the process of adopting Oracle and we have many choices of operating system platforms. Which OS is best for Oracle and how to I compare operating system environments for Oracle databases?

    Answer: That's a very common question. Oracle dominates the database world in part because it runs on over 60 platforms, everything from a Mainframe to a Mac.

    Oracle chose Solaris as their preferred OS in 2005, and later decided to work on their own Linux distro, making a Oracle Linux OS that is custom-tailored to the needs of a typical database. Oracle leverages on the

Recommended

View more >