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

Posts by Christian Antognini

Named Notation and SEM_MATCH Table Function

Jun13
2013
4 Comments Written by Christian Antognini

This is a short post about a strange behavior I discovered today…

The fact is that it is not really possible to use the named notation with the SEM_MATCH table function. In fact, even though the parameter’s names can be specified, the order of the parameters overrides the specification done with the named notation!?!

Here is an example:

  • With positional notation everything works as expected
SQL> SELECT count(*)
  2  FROM table(
  3    sem_match('SELECT * WHERE { GRAPH :gCH { ?s ?p ?o } }',
  4              sem_models('SEMDEMO_WORK'),
  5              NULL,
  6              sem_aliases(sem_alias(NULL,'http://www.semwebtech.org/mondial/10/meta#')),
  7              NULL
  8    )
  9  );

  COUNT(*)
----------
       601
  • The named notation seems to be supported… (notice that the parameters are specified in the same order as they are defined in the table function)
SQL> SELECT count(*)
  2  FROM table(
  3    sem_match(query     => 'SELECT * WHERE { GRAPH :gCH { ?s ?p ?o } }',
  4              models    => sem_models('SEMDEMO_WORK'),
  5              rulebases => NULL,
  6              aliases   => sem_aliases(sem_alias(NULL,'http://www.semwebtech.org/mondial/10/meta#')),
  7              filter    => NULL
  8    )
  9  );

  COUNT(*)
----------
       601
  • … but when the parameters are not specified in the same order as they are defined (the RULEBASES and ALIASES parameters were swapped), a PLS-00306 is raised!
SQL> SELECT count(*)
  2  FROM table(
  3    sem_match(query     => 'SELECT * WHERE { GRAPH :gCH { ?s ?p ?o } }',
  4              models    => sem_models('SEMDEMO_WORK'),
  5              aliases   => sem_aliases(sem_alias(NULL,'http://www.semwebtech.org/mondial/10/meta#')),
  6              rulebases => NULL,
  7              filter    => NULL
  8    )
  9  );

SELECT count(*)
*
ERROR at line 1:
ORA-06550: line 4, column 13:
PLS-00306: wrong number or types of arguments in call to 'ODCITABLEDESCRIBE'
ORA-06550: line 4, column 6:
PL/SQL: Statement ignored

As a result, even though using the named notation is better for readability, the order of the parameters cannot be changed! I’m puzzled.

Posted in 11gR2, Bug, RDF Semantic Graph

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
← Older Entries

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