From oracle-l-bounce@freelists.org Thu Feb 26 10:30:33 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i1QGUXV31704 for ; Thu, 26 Feb 2004 10:30:33 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i1QGUXo31699 for ; Thu, 26 Feb 2004 10:30:33 -0600 Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id BBE71397978; Thu, 26 Feb 2004 11:30:17 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 26 Feb 2004 11:29:03 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from web13426.mail.yahoo.com (web13426.mail.yahoo.com [216.136.175.157]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id F14B7396BCB for ; Thu, 26 Feb 2004 11:20:07 -0500 (EST) Message-ID: <20040226162302.68577.qmail@web13426.mail.yahoo.com> Received: from [12.111.59.169] by web13426.mail.yahoo.com via HTTP; Thu, 26 Feb 2004 08:23:02 PST Date: Thu, 26 Feb 2004 08:23:02 -0800 (PST) From: Paul Baumgartel Subject: Re: how to get parse and execution number for a sql To: oracle-l@freelists.org In-Reply-To: <216701c3fc19$39cb42b0$73f823d5@porgand> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2098 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: treegarden@yahoo.com Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l This doesn't sound right to me, in fact it sounds backwards. If an incoming SQL statement is found in the library cache, then that is evidence that it is syntactically and semantically correct. The soft parsing is required to resolve names, etc. within the context of the issuing session's privilege domain; this may lead to the creation of a new child cursor. Paul Baumgartel --- Tanel_Põder wrote: > Yes, parse_calls shows any parse calls. A parse is always a parse. > You can't > avoid parsing when you issue a SQL statement to be executed. Syntax > and > semantics check is always done. Only after that if Oracle finds out > that > required statement is already parsed against the correct objects, > correct > bind variable types and with correct session parameters, then it can > skip > the rest of parsing and use the already parsed statement. > > You can use session statistics parse count (total) and parse count > (hard) to > find out whether a parse was soft or hard... __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------