Search This Blog

WhyORdba

Tuesday, September 6, 2011

How is SQL Statement Processed ?

What are the stages of SQL Statment Processing ?

Assume that connection to database is established and a SQL Statement is executed.

                          Description of Figure 7-3 follows
                            Source : http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/img/cncpt250.gif
  • SQL Statement Parsing
    • Application makes the call to parse the SQL Statement by issuing the statement.
      • This call opens a cursor which is also known as HANDLE for session specific private SQL   area that holds a parsed SQL Statement and other processing information.
        • Cursor and Private SQL area are in PGA.
    • During parsing SQL Statement is broken into pieces of data structure that can be processed by other routines. It performs the following checks.
      • Syntax Check
        • Check for the validity of the syntax.
        • If there is an error in the syntax check, SQL Statement fails and error is returned.
      • Semantic Check
        • After syntax check is passed it verifies whether the statement referring to tables (objects) and columns exist
        • Note : An object might exist in the database but the user executing the SQL might not have permissions to access/execute that object, semantic check will fail.
        • If there is an error in the semantic check, SQL Statement fails and error is returned.
      • Shared Pool Check
       Description of Figure 7-4 follows
                                           Source : http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/img/cncpt251.gif
        • Once SQL Statement passes above two checks (Syntax and Semantic) a hash value of every SQL Statement is generated.
        • Shared SQL area is searched for the same hash value.
          • Memory address and Hash value of the execution plan for the statement can differ.
        • During parsing based on the result of hash value check
          • It might go for either of the two parse operations
          • Hard Parse
            • Libary Cache and Data Dictionary Cache is accessed numerous times to check the data dictionary. 
              • During this process a latch (serialization device) is acquired on the object. so that their definition does not change.
                • LATCH CONTENTION increases statement execution time and decreases concurrency.
            • If existing code cannot be used a new executable version is created.
              • This is called Hard Parse or LIBRARY CACHE MISS
                • Library Cache Miss since it could not find/reuse the existing code in the shared pool.
            • For DDL there is always an Hard Parse.
          • Soft Parse
            • SQL Statement submitted in the shared pool and if it is reusable, results in Soft Parse or LIBRARY CACHE HIT.
            • Soft parses are generally preferred since it reduces the amount of latching and also it (the database) skips the optimization and row source generation step and goes straight to execution.
    • Optimization
      • This is the process where the most efficient path of execution of SQL Statement is selected based on the statistics collected.
      • There is at least one hard parse for every DML.
      • DDL is never optimized unless it uses DML as part of subquery
        • for example :
          • create table test as (query here...)
    • Row Source Generation
      • This is the process where optimizer passes on the optimal execution plan called the query plan. (Explain plan does help in getting the query plan)
      • Every step of the plan returns a row set which is used by next step.
      • Last step of the execution returns the result set.
    • Execution
      • In this step SQL engine executes each step.
        • If an execution plan is generated using EXPLAIN PLAN, it should be read from bottom up, since the execution of is in reverse order, one step at a time.
Reference or Source : Various : Oracle documentation, Internet, Personal experience.

Thursday, September 1, 2011

Difference between Delete, Truncate and Drop


What is the difference between Delete, Truncate and Drop ?
  • Delete is a DML statement
    • Truncate and Drop are DDL statements
  • Delete statement will fire a trigger.
    • Truncate and Drop will not fire the trigger
  • Delete requires rollback or commit to complete the transaction
    • Truncate and Drop do not require either rollback or commit
  • Delete will not reset the high water mark (reclaim extents)
    • Truncate will reset the high water mark and reclaim space (except first extent)
    • Drop will release space used by the object 
  • Delete and Truncate can only be used against a table.
    • Drop can be used against other object types too (for example views, procedure...)
  • Delete and Truncate will not remove (drop) the indexes or triggers associated with the table.
    • Drop will also remove (drop) all the indexes and triggers associated with the table.

Wednesday, August 31, 2011

Types of Oracle SQL Statements

There are six types of Oracle SQL Statements.

  1. Data Definition Language (DDL) Statements
  2. Data Manipulation Language (DML) Statements
  3. Transaction Control Statements
  4. Session Control Statements
  5. System Control Statements
  6. Embedded SQL Statements
What are Data Definition Language (DDL) Statements ?
  • DDL statements can neither be rolled back nor need to be committed.
    • DDL statements are auto-commit.
  • DDL statements create, alter, drop users, objects, database structure and database also.
    • for example
      • create
      • alter
      • drop
  • Assign or Remove privileges and roles
    • for example
      • grant
      • revoke
  • Turn auditing on or off
    • for example
      • audit
      • noaudit
  • Empty the table (delete all data from the data and reset high water mark)
    • for example
      • truncate
  • Comments for an objects
    • for example
      • comment
What are Data Manipulation Language (DML) Statements ?
  • DML statements can either be rolled back or commited.
    • If a DDL is issued immediately after DML all previous DML transactions are committed.
      • i.e. DDL issues a commit or is an auto-commit.
  • DML statements are used to query or manipulate data
    • Statement to query data
      • select
    • Statement to add data
      • insert
    • Statement to manipulate (change) data
      • update
    • Statement to insert data or update data based on condition
      • merge
    • Statement to delete data (not truncate)
      • delete
    • Statement to see execution plan for any of the above DML Statements
      • explain plan
    • Statement to lock of limit access to an object (table or view)
      • lock table
What are Transaction Control Statements ?
  • These statements help manage the changes made by DML statements
    • Make transaction changes permanent
      • commit
    • Remove (undo) transaction changes 
      • rollback
    • Set a save point to undo changes
      • savepoint
    • Set properties for a transaction
      • set transaction
What are Session Control Statements ?
  • Session Control Statements allow you to manage and control the properties of a user session.
    • Alter current session properties
      • alter session
      • for example
        • data format using
          • alter session set NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'
        • enable or disable SQL tracing
          • alter session set SQL_TRACE = TRUE;
          • alter session set SQL_TRACE = FALSE:
    • enable or disable roles for a current session
      • set role
        • for example
          • set role all except data_modify;
What are System Control Statements ?
  • System Control Statement are used to change the database instance properties
    • alter system
      • for example
        • Enables you to set system level parameters
          • alter system set sec_case_sensitive_logon=true;
        • Enables you to terminate a session
          • alter system kill session ",;
What are Embedded SQL Statements ?
  • Embedded SQL Statements use DDL, DML and Transaction Control Statements within a procedural language (viz : procedure, package, function....)
    • They enable you to
      • Define, allocate and release cursors
        • declare
        • open
        • close
      • Retrieve data from database
        • fetch
      • Specify a database and connect to it
        • declare database
        • connect
      • Assign variable names
        • declare statement
      • Initialize descriptors
        • describe
      • Specify how error and warning conditions are handled
        • whenever
      • Parse and run SQL statements
        • prepare
        • execute
        • execute immediate

Reference or Source : Various : Oracle documentation, Internet, Personal experience.


      Tuesday, August 30, 2011

      How to find Trace File associated with every session the database ?

      Following query will list the USER session and trace file Associated with each background session.

      set pages 10000
      set lines 180
      clear columns

      COLUMN PROGRAM FORMAT A40 WRAP HEADING 'SCHEMANAME TYPE|PROGRAM'
      COLUMN NAME FORMAT A30 WRAP HEADING 'USERNAME|OSUSER'
      COLUMN MACHINE FORMAT A20 WRAP HEADING 'MACHINE|TERMINAL'
      COLUMN INSTANCE FORMAT A15 WRAP HEADING 'INST_ID|INST_NAME'
      COLUMN SID FORMAT A10 WRAP HEADING 'SID|SERIAL#'
      COLUMN PID FORMAT A10 WRAP HEADING 'PID|SPID'
      COLUMN LOGON_TIME FORMAT A20 WRAP HEADING 'LOGON_TIME|STATUS'
      COLUMN TRACEFILE FORMAT A109 WRAP

      select
      rpad(rtrim(to_char(vses.SID)),10,' ') || rpad(rtrim(to_char(vses.SERIAL#)),10,' ') as SID,
      rpad(rtrim(to_char(vproc.PID)),10,' ') || rpad(rtrim(to_char(vproc.SPID)),10,' ') as PID,
      rpad(rtrim(vses.USERNAME),30,' ') || rpad(rtrim(vses.OSUSER),30,' ') as NAME,
      rpad(trim(vses.SCHEMANAME),25,' ') || ' ' || rpad(rtrim(vses.TYPE),14,' ') || rpad(rtrim(vses.PROGRAM),40,' ') as PROGRAM,
      rpad(rtrim(vses.MACHINE),20,' ') || rtrim(vses.TERMINAL) as MACHINE,
      rpad(rtrim(TO_CHAR(vses.LOGON_TIME,'DD-MON-YYYY HH24:MI:SS')),20,' ') || rpad(rtrim(vses.STATUS),10,' ') as LOGON_TIME,
      rpad(rtrim(to_char(vses.INST_ID)),15,' ') || rpad(rtrim(vinst.INSTANCE_NAME),15,' ') as INSTANCE,
      vproc.TRACEFILE,
      vproc.PGA_USED_MEM,
      vproc.PGA_FREEABLE_MEM,
      vproc.PGA_MAX_MEM
      from gv$session vses, gv$process vproc, gv$instance vinst
      where vses.PADDR=vproc.ADDR
      and vses.inst_id = vproc.inst_id
      and vses.inst_id = vinst.instance_number
      and vproc.background is null -- Uncomment this to get User Process only.
      -- and vproc.background = 1 -- Uncomment this to get Background Process only.
      order by vses.type,vses.status,vses.inst_id,vses.USERNAME
      /

      clear columns


      Following query will list the BACKGROUND session and trace file Associated with each user session.


      set pages 10000
      set lines 180
      clear columns

      COLUMN PROGRAM FORMAT A25 WRAP
      COLUMN OSUSER FORMAT A20 WRAP
      COLUMN TERMINAL FORMAT A20 WRAP
      COLUMN MACHINE FORMAT A20 WRAP
      COLUMN DESCRIPTION FORMAT A40 WRAP
      COLUMN TRACEID FORMAT A8 WRAP
      COLUMN TRACEFILE FORMAT A62 WRAP
      COLUMN PID FORMAT 999999 WRAP
      COLUMN SPID FORMAT A8 WRAP
      COLUMN LOGON_TIME FORMAT A20 WRAP
      COLUMN INST_ID FORMAT 999999
      COLUMN INSTANCE_NAME FORMAT A10 HEADING INST_NAME

      select
      vbgproc.NAME,
      vses.SID,
      vses.SERIAL#,
      vses.PROGRAM,
      vproc.PID,
      vproc.SPID,
      vses.OSUSER,
      vses.MACHINE,
      vses.TERMINAL,
      TO_CHAR(vses.LOGON_TIME,'DD-MON-YYYY HH24:MI:SS') LOGON_TIME,
      vses.INST_ID,
      vbgproc.DESCRIPTION,
      vproc.PGA_USED_MEM,
      vproc.PGA_FREEABLE_MEM,
      vproc.PGA_MAX_MEM,
      vproc.TRACEID,
      vproc.TRACEFILE,
      vinst.INSTANCE_NAME
      from gv$session vses, gv$process vproc, gv$bgprocess vbgproc, gv$instance vinst
      where vses.PADDR=vproc.ADDR
      and vses.PADDR=vbgproc.PADDR
      and vses.inst_id = vproc.inst_id
      and vses.inst_id = vbgproc.inst_id
      and vses.inst_id = vinst.instance_number
      and vproc.background = 1
      order by vses.inst_id,vbgproc.name
      /

      clear columns

      Thursday, July 31, 2008

      Calculate Background Process and User Process Memory Consumption for Oracle 10g R2 (10.2.0.3)

      Here is a very simple formula and observation on what is the memory consumption of Oracle Process and User Connections on Linux (SLES10) for Oracle 10.2.0.3

      SGA_TARGET is set to sga_target=3100 M (Approx
      3 Gb
      )

      USER DSIZ VSZ COMMAND COMMAND
      oracle 3219786 3319072 oracle ora_pmon_DB1
      oracle 3266114 3365400 oracle ora_dbw0_DB1
      oracle 3233590 3332876 oracle ora_lgwr_DB1
      oracle 3223238 3322524 oracle ora_ckpt_DB1
      oracle 3223326 3322612 oracle ora_smon_DB1
      oracle 3220182 3319468 oracle ora_reco_DB1
      oracle 3234162 3333448 oracle ora_arc0_DB1

      oracle 3219806 3319092 oracle oracleDB1 (LOCAL=NO)
      oracle 3218706 3317992 oracle oracleDB1 (LOCAL=NO)
      oracle 3218706 3317992 oracle oracleDB1 (LOCAL=NO)
      oracle 3218702 3317988 oracle oracleDB1 (LOCAL=NO)
      oracle 3219226 3318512 oracle oracleDB1 (LOCAL=NO)
      oracle 3219786 3319072 oracle oracleDB1 (LOCAL=NO)
      oracle 3218702 3317988 oracle oracleDB1 (LOCAL=NO)
      oracle 3219738 3319024 oracle oracleDB1 (LOCAL=NO)

      So, based on the above, it is approx.
      1 % of the SGA
      .

      Let me know if you disagree or if you have similar observations / calculations.
      Note : There are system parameter that will have an impact too.

      Wednesday, May 28, 2008

      Diagnostic Destination in 11g

      Introduced in 11g, DIAGNOSTIC_DEST initialization parameter can be used to set user, core, background dump destination. These had to be individually set or would default to $ORACLE_HOME/dbs.

      DIAGNOSTIC_DEST now contains all the ADR (Automatic Diagnostic Repository) files which includes alerts, trace, core dumps etc.

      It follows the following structure.

      {diagnostic_dest}/diag/rdbms/{dbname}/{instname}

      and breaks down further into

      {diagnostic_dest}/diag/rdbms/{dbname}/{instname}/alert
      {diagnostic_dest}/diag/rdbms/{dbname}/{instname}/incident
      {diagnostic_dest}/diag/rdbms/{dbname}/{instname}/trace
      and so on...


      Alert : Contains XML LOG (alert)
      Incident : Core dumps and other incident dumps
      Trace : Background (bdump) and alert_$ORACLE_SID.log