I had a lot of parsing and some long parse time also .
If you're on 8.1.5.x with timed_statistics=true than
it's normal, it's a bug .
timed_statistics=true on 8.1.5.x prevents Oracle from
sharing cursors, so you parse like crazy.
Are you on 8.1.5.x ?
- Linda Hagedorn <Linda_at_pets.com> a écrit : > This
is from a .trc tkprof file. I cannot imagine
> why a parse would take
> 115 or 131 seconds. Does anyone have any ideas? I
> have several of these.
>
>
> Any information or referral is appreciated. Thanks,
> Linda
>
>
> UPDATE BV_PRICED_ITEMS_TABLE SET ITEM_STATE=21
> WHERE ORDER_NUMBER = :b1
> call count cpu elapsed disk
> query current
> rows
> ------- ------ -------- ---------- ----------
> ---------- ----------
> ----------
> Parse 1 0.00 115.72 0
> 0 0
> 0
> Execute 1 0.00 0.00 0
> 7 4
> 0
> Fetch 0 0.00 0.00 0
> 0 0
> 0
> ------- ------ -------- ---------- ----------
> ---------- ----------
> ----------
> total 2 0.00 115.72 0
> 7 4
> 0
>
>
> begin
>
PKG_CSR.CSR_SEARCH_ORDERS(IN_ORDER_NO=>:V001,IN_ORDER_DATE=>:V002,
>
>
IN_EMAIL_ADDRESS=>:V003,IN_PHONE_NO=>:V004,IN_ZIP_CODE=>:V005,IN_SHIP_NAME=
>
>
>:V006,IN_CARD_NAME=>:V007,IN_CARD_NUMBER=>:V008,ORDER_NUMBER=>:R001C001,
>
>
USER_ID=>:R001C002,ORDER_DATE_FMT=>:R001C003,CANCEL_FLAG=>:R001C004,
>
>
ORDER_STATUS=>:R001C005,BILL_NAME=>:R001C006,SHIP_NAME=>:R001C007,SHIP_ADDR=
>
>
>:R001C008,SHIP_CITY=>:R001C009,SHIP_STATE=>:R001C010,SHIP_ZIP=>:R001C011)
> ;end;
> call count cpu elapsed disk
> query current
> rows
> ------- ------ -------- ---------- ----------
> ---------- ----------
> ----------
> Parse 4 0.00 0.00 0
> 0 0
> 0
> Execute 4 0.02 131.38 0
> 0 0
> 4
> Fetch 0 0.00 0.00 0
> 0 0
> 0
> ------- ------ -------- ---------- ----------
> ---------- ----------
> ----------
> total 8 0.02 131.38 0
> 0 0
> 4
>
> Misses in library cache during parse: 0
> Optimizer goal: CHOOSE
> Parsing user id: 41
>
> ****
> SELECT BV_MAIN_INVOICE_TABLE.ORDER_NUMBER From
> BV_MAIN_INVOICE_TABLE WHERE
> BV_MAIN_INVOICE_TABLE.ORDER_NUMBER ='01008204'
> AND BV_MAIN_INVOICE_TABLE.APPDEF2 IS NULL ORDER BY
> order_number DESC
>
> call count cpu elapsed disk
> query current
> rows
> ------- ------ -------- ---------- ----------
> ---------- ----------
> ----------
> Parse 2 0.01 131.34 0
> 0 0
> 0
> Execute 2 0.00 0.00 0
> 0 0
> 0
> Fetch 4 0.00 0.00 0
> 10 0
> 2
> ------- ------ -------- ---------- ----------
> ---------- ----------
> ----------
> total 8 0.01 131.34 0
> 10 0
> 2
>
>
>
> --
> Author: Linda Hagedorn
> INET: Linda_at_pets.com
>
> Fat City Network Services -- (858) 538-5051 FAX:
> (858) 538-5051
> San Diego, California -- Public Internet
> access / Mailing Lists
>
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from). You may
> also send the HELP command for other information
> (like subscribing).
Stephane Paquette
DBA Oracle
stephane_paquette_at_yahoo.com
spaquette_at_houra.fr
(33) 01 53 93 06 50
Received on Thu Aug 17 2000 - 02:56:27 CDT
