Striving for Optimal Performance
  • Home
  • Blog
    • Archive
    • Categories
  • Troubleshooting Oracle Performance
    • Description
    • Structure
    • Table of Contents
    • Forewords
    • Reviews
    • Downloadable Files
    • Addenda and Errata
  • Publications
  • Public Appearances
    • Past Public Appearances
  • Contact
  • Search
  • About

ITL Deadlocks (script)

May01
2013
1 Comment Written by Christian Antognini

A reader of this blog, VijayS, asked me to share the script I use to demo ITL deadlocks that I mentioned in this comment. Since other readers might be interested, here is the script.

SET TERMOUT ON FEEDBACK ON VERIFY OFF SCAN ON ECHO ON

@connect

SELECT * FROM v$version WHERE rownum = 1;

REM
REM cleanup
REM

DROP TABLE t PURGE;

PAUSE

REM
REM create a test table with three completely full data blocks
REM (default tablespace is expected to have 8KB blocks)
REM

CREATE TABLE t (n NUMBER, c VARCHAR2(4000)) PCTFREE 0;

INSERT INTO t SELECT rownum, rpad('*',2679,'*') FROM dual CONNECT BY level <= 9;
COMMIT;

SELECT dbms_rowid.rowid_block_number(rowid), n
FROM t
ORDER BY n;

PAUSE

REM
REM in this session modify two rows: one in the first block and one in the
REM third block
REM

SET SQLPROMPT " 1 > "

SELECT sid FROM v$session WHERE audsid = userenv('sessionid');

UPDATE t SET n=n*10 WHERE n IN (1,7);

PAUSE

REM
REM in another session (called session #2) modify two rows: one in the first
REM block and one in the second block
REM
REM @connect
REM SET SQLPROMPT " 2 > "
REM
REM SELECT sid FROM v$session WHERE audsid = userenv('sessionid');
REM UPDATE t SET n=n*10 WHERE n IN (2,5);
REM

PAUSE

REM
REM in another session (called session #3) try to modify one row per block;
REM since all ITL slots of the first block are taken, wait...
REM
REM @connect
REM SET SQLPROMPT " 3 > "
REM
REM SELECT sid FROM v$session WHERE audsid = userenv('sessionid');
REM UPDATE t SET n=n*10 WHERE n = 9;
REM UPDATE t SET n=n*10 WHERE n = 6;
REM UPDATE t SET n=n*10 WHERE n = 3;
REM

PAUSE

REM
REM in this session try to modify one row in the second block and, in addition,
REM in session #2, try to modify one row in the third block; since all ITL slots
REM of the second and third block are taken, wait..., deadlock...
REM

REM run "UPDATE t SET n=n*10 WHERE n = 8;" in session #2

UPDATE t SET n=n*10 WHERE n = 4;

Notice that:

  • the remarks contained in the script provide important information for understanding what the script does and, as a result, for being able to produce a ITL deadlock
  • to run the script three sessions are required (when running the script I copy/paste the commands from the output of the terminal running the script to the other two terminals)

To give you an example of what it looks like when you run it, here is a recording:

You do not have the latest version of Flash installed. Please visit this link to download it: http://www.adobe.com/products/flashplayer/

The deadlock graph generated by the run that I recorded is the following one. Notice that the rows waited on are set to “no row”.

                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00090013-00001b44        25     140     X             23     147           S
TX-0007001d-000019a9        23     147     X             25     140           S

session 140: DID 0001-0019-00000D23     session 147: DID 0001-0017-000004BC
session 147: DID 0001-0017-000004BC     session 140: DID 0001-0019-00000D23

Rows waited on:
  Session 140: no row
  Session 147: no row
Posted in 10gR2, 11gR1, 11gR2

Premature Optimization

Mar14
2013
4 Comments Written by Christian Antognini

Premature optimization, (probably) because of Donald Knuth’s famous line “premature optimization is the root of all evil,” (see Structured Programming with go to Statements) is, at the very least, a controversial topic. The misconception based on that particular quote is that a programmer, while writing code, should ignore optimization altogether. In my opinion this is wrong. To put the quote in context, let’s have a look to at the text that precedes and follows it:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

My take on Knuth’s paper is that programmers, when writing code, should not care about micro optimization that has local impact only. Instead, they should care about optimizations that have global impact, like the design of a system, the algorithms used to implement the required functionality, or in which layer (SQL, PL/SQL, application language) and with which features a specific processing should be performed. Local optimizations are deferred till a measurement tool points out that a specific part of the code is spending too much time executing. And, because the optimization is local, there is no impact on the overall design of the system.

Posted in TOP

Ad: CBO Days 2012 – Final Agenda

Nov28
2012
3 Comments Written by Christian Antognini

The 11th and 12th of December and, therefore, the CBO Days in Zurich are approaching. Given the high quality of the speakers that accepted my invitation and the number of people that decided to attend the event, in my opinion it will be a blast! By the way, if you are interested in attending the event, do not wait any longer. In fact, from the 80 available seats, 75 are taken.

Here is a preview of the agenda:

Tuesday 11th December

  • 09:00 – 09:10: Welcome and Introduction, Christian Antognini
  • 09:10 – 10:30: The History of the Oracle Optimizer, Maria Colgan
  • 10:30 – 11:00: Coffee break
  • 11:00 – 12:20: Query Transformations, Joze Senegacnik
  • 12:20 – 13:50: Lunch
  • 13:50 – 15:10: New strategies for Statistics in 11g, Jonathan Lewis
  • 15:10 – 15:40: Coffee break
  • 15:40 – 17:00: Understanding Parallel Execution, Randolf Geist
  • 17:00 – 19:00: Let’s meet over drinks

Wednesday 12th December

  • 09:00 – 10:20: The Evolution of Histograms, Jonathan Lewis
  • 10:20 – 10:50: Coffee break
  • 10:50 – 11:20: The Oracle Optimizer: Behind The Curtain, Mohamed Zait
  • 11:20 – 12.10: The Oracle Optimizer: An Insider Perspective (Part 1), Mohamed Zait
  • 12:10 – 13:40: Lunch
  • 13:40 – 15:00: The Oracle Optimizer: An Insider Perspective (Part 2), Mohamed Zait
  • 15:00 – 15:30: Coffee break
  • 15:30 – 16:50: How the Query Optimizer Learns from Its Mistakes, Christian Antognini

For further information about the event click here.

Posted in Query Optimizer, Speaking, Trivadis
← Older Entries

EvoLve theme by Theme4Press  •  Powered by WordPress Striving for Optimal Performance