Stats collection issue on 11.2

Hello all,
we have a oracle 11.2.0.3 enterprise edition database has auto optimizer stats collection is enabled
but does not collect any stats, I tried to disable and enable the task with same result,
database is been up for a month now,
no rows listed in DBA_AUTOTASK_CLIENT_HISTORY, DBA_AUTOTASK_schedule,DBA_AUTOTASK_TASK
statistics_level is set to typical,
is there anything else I could check,
Any help is appreciated,
Thanks,
Red

rred wrote:
Hello all,
we have a oracle 11.2.0.3 enterprise edition database has auto optimizer stats collection is enabled
but does not collect any stats, I tried to disable and enable the task with same result,
database is been up for a month now,
no rows listed in DBA_AUTOTASK_CLIENT_HISTORY, DBA_AUTOTASK_schedule,DBA_AUTOTASK_TASK
statistics_level is set to typical,
is there anything else I could check,
Any help is appreciated,
Thanks,
Red
SQL> show parameter queue
NAME TYPE VALUE
job_queue_processes integer 1000
SQL> select job_name from dba_scheduler_jobs;
JOB_NAME
XMLDB_NFS_CLEANUP_JOB
SM$CLEAN_AUTO_SPLIT_MERGE
RSE$CLEAN_RECOVERABLE_SCRIPT
FGR$AUTOPURGE_JOB
BSLN_MAINTAIN_STATS_JOB
DRA_REEVALUATE_OPEN_FAILURES
HM_CREATE_OFFLINE_DICTIONARY
ORA$AUTOTASK_CLEAN
FILE_WATCHER
PURGE_LOG
MGMT_STATS_CONFIG_JOB
JOB_NAME
MGMT_CONFIG_JOB
RLM$SCHDNEGACTION
RLM$EVTCLEANUP
POSPAY_CHECK_JOB
15 rows selected.
SQL>

Similar Messages

Auto optimizer stats collection enabled, but not running and not showing up

I enabled auto optimizer stats collection days ago, but it never ran. DB version is 11gr2, OS is redhat 5. It shows enabled in dba_autotask_client, but not in autotask_task. Please help on this issue.
SQL> select client_name, status from dba_autotask_client;
CLIENT_NAME STATUS
auto optimizer stats collection ENABLED
auto space advisor DISABLED
sql tuning advisor ENABLED
SQL> select task_name, status, to_char(last_good_date, 'YYYY-MM-DD HH24:MI:SS') last_good_date, last_good_duration
from dba_autotask_task
where client_name = 'auto optimizer stats collection'; 2 3
no rows selected
SQL> select program_action, number_of_arguments, enabled
from dba_scheduler_programs
where owner = 'SYS'
and program_name = 'GATHER_STATS_PROG'; 2 3 4
PROGRAM_ACTION NUMBER_OF_ARGUMENTS ENABL
dbms_stats.gather_database_stats_job_proc 0 TRUE
SQL> select w.window_name, c.autotask_status, c.optimizer_stats, w.repeat_interval, w.enabled
-- , w.duration, w.last_start_date, w.next_start_date
2 from dba_autotask_window_clients c , dba_scheduler_windows w
3 4 where c.window_name = w.window_name
5 order by last_start_date desc;
WINDOW_NAME AUTOTASK OPTIMIZE REPEAT_INTERVAL ENABL
MONDAY_WINDOW ENABLED ENABLED freq=daily;byday=MON;byhour=22;byminute=0; bysecond=0 TRUE
SUNDAY_WINDOW ENABLED ENABLED freq=daily;byday=SUN;byhour=6;byminute=0; bysecond=0 TRUE
SATURDAY_WINDOW ENABLED ENABLED freq=daily;byday=SAT;byhour=6;byminute=0; bysecond=0 TRUE
FRIDAY_WINDOW ENABLED ENABLED freq=daily;byday=FRI;byhour=22;byminute=0; bysecond=0 TRUE
THURSDAY_WINDOW ENABLED ENABLED freq=daily;byday=THU;byhour=22;byminute=0; bysecond=0 TRUE
WEDNESDAY_WINDOW ENABLED ENABLED freq=daily;byday=WED;byhour=22;byminute=0; bysecond=0 TRUE
TUESDAY_WINDOW ENABLED ENABLED freq=daily;byday=TUE;byhour=22;byminute=0; bysecond=0 TRUE
7 rows selected.
SQL>

SQL> select max(last_analyzed) from all_tables where owner='ARAD';
MAX(LAST_
26-SEP-12

Stats collection running long in 11g

Oracle11.2.0.1
Sun Solaris.
Stats collection running long for almost 12 hours from 6PM to 6AM daily and stats collection autotask is getting STOPPED after the window duration.
DBA_TABLES.last_analyzed is not getting updated after 2AM in the morning. I believe it is scanning some big tables, but not able to pin point the table/index.
And we've some a bunch of 100GB tables in the DB. Is there a way to find out which table it's gathering stats between 2AM and 6AM and not getting completed?
Thanks for your time!

moreajays wrote:
Hi,
I would suggest to find out those tables with huge Table & last_analyzed is Null , these tables would be possible tables responsible for long run.
Only AWR ot other SQL Hist stats tables can help you to get details.
To fix this issue you should run stats gathering manually in day time (not in maintenance window) either with auto stats or with little estimate_percent (10 or 5)
After getting first successful analyze (manually) , maintenance stats will pick up new incremental stats thereafter
Ajay,
I don't think that your statement that after the gathering the statistics manually, it would be next done incrmentally is correct. The incremental statistics are introduced only for partitioned tables AFAIK. Can you post a link from the documentation that your mentioned behavior exists?
Aman....

Regarding stats collection in oracle 11g.

Just a general question, while doing stats collection weather system takes the backup of current statistics. i think we can specify stattab. but weather it takes stats backup before over writing?
I got this requirement as a part of upgrade, i have already gone through export_schema_stats and import_schema stats already. Just trying all other possible options only...
Regards
DBA.

DBA wrote:
Just a general question, while doing stats collection weather system takes the backup of current statistics. i think we can specify stattab. but weather it takes stats backup before over writing?
backup to where exactly?

10g Automatic Stats Collection -- AUTO ( METHOD_OPT)

I have implememted Oracle 10g Auto Stats collection feature. To generate new stats on 10g optimizer I deleted the schema stats and then scheduled the DBMS_SCHEDULER to collect stats in AUTO method_opt.
I see that the new 10g optimizer is collecting stats differently in different databases eben through they have the same data.
For exampl I see that it collected Histograms on 10 columns in one table in one environment but it generatd histograms only on 9 columns in another env.
I am concerned that the stats difference will result in the execution plan getting changed across different instances.
Can someone please clarify the cause of the same. How can I make sure tha the 10g optimizer is collecting stats uniformly across different envs.
Thank You

You wrote:
"I am concerned that the stats difference will result in the execution plan getting changed across different instances."
and you should be concerned.
I would recommend not collecting stats the way you are but rather to use a nuanced approach where you collect only when they are stale or only when you know that changes have rendered old statistics invalid.

Auto Stats Collection on function based indexes

In 10g does AUTO Stats Collection job in the default weeknight / weekend window collect stats on "function based indexes".
Thank You
Message was edited by:
user449511
I got the reply in another similar post posted by me some time earlier.
Thank You
Message was edited by:
user449511

SELECT job_name, comments
FROM dba_scheduler_jobs;Then refine your search using the columns in the view.

Comments on "Auto" Stats collection practice in 10g

We going to implement auto stat collection practice in our production env. Can someone on this forum comment on the results / experiences ? As per Tom Kytes he is sceptical on going with this practice because it uses AUTO method_opt option which actually can result in different stats being collected based on column usage and data distribution.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:52288431326913.
Thank You

Hi
Can someone on this forum comment on the results / experiences ?As for any "automatic feature" it works fine in many situations but not always. You have to test it to know if in your situation it is usable or not. IMHO it makes sense to give it a try...
can result in different stats being collected based on column usage
and data distribution.This is the purpose of AUTO. So, no news here.
HTH
Chris

Has any seen collection issues after 11g database upgrade?

We do have an SR open.
Just wondering if anyone else has experienced collection issues after upgrading the db to 11g? Our technical folks are hoping it is something else but for the past few weeks we have seen random issues stemming from collections. We run a full collections 5 nights a week. There are material transactions occurring during the two plus hours of collections. This seems to be randomly skewing on hand snapshots in collections as well as missing supply i.e. work orders. Only impacts a fraction of the records in material transactions and they are different every night.
Reason I believe it has to do with transactions during collections is one collection run out of the five is generally pretty good...Sunday evening for there is very limited transactions taking place on this evening.
Thanks in advance

Answer to above question not required now as:
Having read the 24th December update of note 761570.1 - 'Database Preparation Guidelines for an Oracle E-Business Suite Release 12.1.1 Upgrade' I have decided to upgrade the database to 11.2.0.x by following the Path C option.
Unfortunately as the 11.2.0.x upgrade isn't covered by MWIZ yet I will have to follow the manual steps.

'auto optimizer stats collection' in em12cr3

During installation of EM 12cR3 the OUI noted to 'disable stats gathering job', and indicated it would disable for me.
After installation I look at dba_auto_task and see that 'auto optimizer stats collection' is enabled.
The install docs Overview of the EM Prerequisite Kit also say to disable this for the install and upgrade.
What is not clear to me is: "is this only for the install/upgrade? should the collection be enabled after the install is complete?"

Hi Sherrie,
auto optimizer stats needs to be disable only during install and upgrade of 12c cloud control
Once its done you can enable the auto optimizer stats collection at Repos DB level
Regards,
Rahul

Runtime increased after stats collection

Hi,
Below is my SQL query
SELECT   wos.*,
               t.wo_status,
               t.wo_type
          FROM cscrpt_transactions t,
               (SELECT DISTINCT sb.sub_acct_no_sbb,
                                sb.vip_flg_sbb,
                                sb.res_name_sbb,
                                sb.home_phone_sbb,
                                sb.delq_1cyc_sbb,
                                sb.delq_2cyc_sbb,
                                sb.delq_3cyc_sbb,
                                sb.delq_4cyc_sbb,
                                sb.delq_5cyc_sbb,
                                sb.delq_stat_sbb,
                                sb.delq_amt_sbb,
                                sb.ls_pay_dte_sbb,
                                sb.ls_pay_amt_sbb,
                                sb.misc_sbb,
                                hb.misc_hse,
                                TRUNC(SYSDATE) - sb.start_delq_dte_sbb days_delq,
                                sb.prom_pays_days_sbb,
                                sb.start_delq_dte_sbb,
                                sb.prom_pays_dte_sbb,
                                ca.category_name,
                                ct.wo_key,
                                cc.customer_id
                           FROM sbb_base sb,
                                hse_base hb,
                                cscrpt_customers cc,
                                cscrpt_transactions ct,
                                cscrpt_categories ca
                          WHERE sb.ext_stat_sbb = ' '
                            AND sb.prin_sbb <> 3000
                            AND sb.prin_sbb <> 3100
                            AND sb.delq_stat_sbb NOT IN ('C', 'E', 'Z', 'W')
                            AND sb.delq_amt_sbb > 10.00
                            AND (   sb.delq_2cyc_sbb > 0.00
                                 OR sb.delq_3cyc_sbb > 0.00
                                 OR sb.delq_4cyc_sbb > 0.00
                                 OR sb.delq_5cyc_sbb > 0.00)
                            AND sb.sub_acct_no_sbb = hb.sub_acct_no_hse
                            AND sb.sub_acct_no_sbb = cc.csg_account_no
                            AND cc.customer_id = ct.customer_id
                            AND ct.category_id = ca.category_id) wos
         WHERE wos.wo_key = t.wo_key
           AND t.wo_key = (SELECT MAX(tr.wo_key)
                             FROM cscrpt_transactions tr
                            WHERE tr.customer_id = wos.customer_id)
      ORDER BY wos.start_delq_dte_sbb DESC,
               wos.delq_2cyc_sbb;Stats for the base tables of the views used
(v)sbb_base – 24,791,659 rows, stats 12/28/07
(v)hse_base – 25,270,280 rows, stats 12/28/07
(v)cscrpt_customers – 20,418,167 rows, stats 10/10/04
(v)cscrpt_transactions – same as for customers
(t)cscrpt_categories – 14,524 rows, stats 10/10/04(v)-View, (t)-table. Rowcount and last date when stats were collected.
Below is the execution plan:
4286 rows selected.
Elapsed: 01:02:39.07
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=236008 Card=1 Bytes=
          386)
   1    0   SORT (ORDER BY) (Cost=236001 Card=1 Bytes=386)
   2    1     FILTER
   3    2       FILTER
   4    3         NESTED LOOPS (OUTER)
   5    4           HASH JOIN (Cost=235998 Card=1 Bytes=365)
   6    5             VIEW (Cost=198149 Card=987557 Bytes=335769380)
   7    6               SORT (UNIQUE) (Cost=198149 Card=987557 Bytes=2
          24175439)
   8    7                 FILTER
   9    8                   HASH JOIN (Cost=181816 Card=987557 Bytes=2
          24175439)
10    9                     TABLE ACCESS (FULL) OF 'CSCRPT_CATEGORIE
          S' (Cost=6 Card=6803 Bytes=292529)
11    9                     FILTER
12   11                       HASH JOIN (OUTER)
13   12                         HASH JOIN (Cost=163701 Card=894900 B
          ytes=145868700)
14   13                           HASH JOIN (Cost=129012 Card=360796
           Bytes=49429052)
15   14                             HASH JOIN (Cost=68118 Card=32221
          6 Bytes=35121544)
16   15                               TABLE ACCESS (FULL) OF 'CSCRPT
          CUSTOMERSTAB' (Cost=9302 Card=317965 Bytes=6677265)
17   15                               TABLE ACCESS (FULL) OF 'SBB_BA
          SE_TAB' (Cost=55749 Card=2397901 Bytes=211015288)
18   14                             TABLE ACCESS (FULL) OF 'HSE_BASE
          _TAB' (Cost=48688 Card=23936080 Bytes=670210240)
19   13                           TABLE ACCESS (FULL) OF 'CSCRPT_TRA
          NSACTIONS_TAB' (Cost=17313 Card=35912894 Bytes=933735244)
20   12                         VIEW OF 'CSCRPT_CUSTOMERS_ALL_VW' (C
          ost=9302 Card=15978119 Bytes=335540499)
21   20                           TABLE ACCESS (FULL) OF 'CSCRPT_CUS
          TOMERS_TAB' (Cost=9302 Card=15978119 Bytes=335540499)
22    8                   COUNT (STOPKEY)
23   22                     TABLE ACCESS (BY INDEX ROWID) OF 'ACCOUN
          T_TYPE_SPA' (Cost=2 Card=1 Bytes=18)
24   23                       INDEX (RANGE SCAN) OF 'ACCOUNT_TYPE_SP
          A_UK01_I' (UNIQUE) (Cost=2 Card=1)
25    5             TABLE ACCESS (FULL) OF 'CSCRPT_TRANSACTIONS_TAB'
           (Cost=17313 Card=35912894 Bytes=897822350)
26    4           VIEW PUSHED PREDICATE OF 'CSCRPT_CUSTOMERS_ALL_VW'
           (Cost=1 Card=1 Bytes=21)
27   26             TABLE ACCESS (BY INDEX ROWID) OF 'CSCRPT_CUSTOME
          RS_TAB' (Cost=2 Card=1 Bytes=21)
28   27               INDEX (UNIQUE SCAN) OF 'CSCRPT_CUSTOMERS_PK' (
          UNIQUE) (Cost=2 Card=1)
29    2       SORT (AGGREGATE)
30   29         FILTER
31   30           NESTED LOOPS (OUTER)
32   31             TABLE ACCESS (BY INDEX ROWID) OF 'CSCRPT_TRANSAC
          TIONS_TAB' (Cost=5 Card=5 Bytes=110)
33   32               INDEX (RANGE SCAN) OF 'CSCRPT_TRANSACTIONS_N3'
           (NON-UNIQUE) (Cost=3 Card=5)
34   31             VIEW PUSHED PREDICATE OF 'CSCRPT_CUSTOMERS_ALL_V
          W' (Cost=1 Card=1 Bytes=21)
35   34               FILTER
36   35                 TABLE ACCESS (BY INDEX ROWID) OF 'CSCRPT_CUS
          TOMERS_TAB' (Cost=2 Card=1 Bytes=21)
37   36                   INDEX (UNIQUE SCAN) OF 'CSCRPT_CUSTOMERS_P
          K' (UNIQUE) (Cost=2 Card=1)
Statistics
       4519 recursive calls
          2 db block gets
   64793132 consistent gets
    2936560 physical reads
          0 redo size
     536683 bytes sent via SQL*Net to client
       2920 bytes received via SQL*Net from client
        287 SQL*Net roundtrips to/from client
         78 sorts (memory)
          0 sorts (disk)
       4286 rows processedI am in the process of getting stats for the ones which were collected in 2004.
I am thinking as the plan shows some FTS steps for those views (base tables for which stats were collected in 2004) and as there are indexes on those tables, the plan might change after stats collection.
I appreciate your inputs in this.
Thanks
Rajiv
Message was edited by:
RajivTx
Message was edited by:
RajivTx

I am trying the INDEX hint
INDEX(table [index]) Forces an index scan of the specified table using the specified index(s). If a list of indexes is specified, the optimizer chooses the one with the lowest cost. If no index is specified then the optimizer chooses the available index for the table with the lowest cost.
I am confused whether I need to use the above hint or
/*+ hint(view_name.table_in_view) */
as I have views in the FROM clause.
Thanks
Rajiv

Is 11g auto stats collection automatic on? where can I find this job?

Is 11g auto stats collection automatic on?
I manually created a 11g database, but I did not see auto stats collection job. where can I find this job? or how could I verify this is on?
Thank you.

Found in Automated Maintenance Tasks.

Stats collection

Hi,
I am using oracle 9i. when I ran refresh for some tables , I found that statistics collection was also running for those tables simultaneously and query performance is poor. however , last_analyzed column in user_tables was updated.
Could you please let me know whether refresh skips stats collection if both are running in parlell ?
Thanks!

Please define your terms so we can help you.
1. What does refresh mean? Is this a DML statement, Streams? SQL*Loader? DataPump?
Surely you don't expect that we can help you by guessing?
2. What is your version number ... 9i is not a version number.
SELECT * FROM v$version;3. If both what are running in parallel?
Please provide clarity so someone can help you.

Auto optimizer stats collection interval

Hi,
I have a question about "auto optimizer stats collection" in 11gR2.
I see on the history, 1 execution of "auto optimizer stats collection" on Monday, Tuesday, Wenesday, Thursday and Friday and 5 executions on Saturday and Sunday.
I find the duration of each window (4 hours on Mon, Tue, Wen, Thu and Friday, 20 hours on Sat and Sun) and start date (22 hour Mon, Tue, Wen, Thur and Friday and 6h on Sat and Sun), but i don't find the interval between executions or frenquency of execution for each window.
Someone can tell me, if is it possible to change this and where ?
Regards,

Thank's for all reply, but it's not the answer of my question.
I know how disable/enable automatic task, i know to add/delete window, etc ... but where can i configure the frequency or interval of the "auto optimizer stats collection" task.
I try to explain what i want to know.
By defaut, on window Mon, Tue, Wen, Thu and Fri, the task start at 22:00 and run once, the window duration is 4 hours. Why one run ?
On window Sat and Sun, the task start à 6:00 and run 5 times ( 6:00, 10:00, 14:00, 18:00 and 22:00), the window duration is 20 hours. Why 5 runs ? or why 4 hours between 2 runs ?
Regards

Performance degrades after stats collection

Oracle 11gR2 OEL 5
We have several very large tables (40 million rows and up) and recently we gathered stats on the tables and it degraded our performance. It started doing full table scans instead of using the indexes. The same queries are fine in other environments. Only difference is the stats gathering. Logically, the performance should be better after stats collection. But instead it is poor.
I ran the 10053 trace on the query and I see that the cardinality and cost is way high in the poorly performing environment. As a test, I restored the old stats in the environment and it put everything back to normal - the query runs fast again. Note that the restored stats were gathered over a year ago. Should we not gather stats regularly on very large tables?
Thanks.

I will have to look more into the GATHER_STATS job.
In the meantime, here is the query with both the good and bad explain plans.
I'm sure you can see the difference in cost and cardinality
Good (Original) Query Explain Plan
SELECT DL.LCODE , DL.CNUM , DR.DNAME , STPL.FSTE
FROM DL , DR_LK , DR , STPL
WHERE ( DL.LCODE = DR_LK.LCODE )
AND ( DL.CNUM = DR_LK.CNUM )
AND ( CCDT_LK.DBTR_ID = DR.DBTR_ID )
AND ( DL.LCODE = STPL.LCODE )
AND ( DL.CNUM = STPL.CNUM )
AND ( ( DL.DT_ID = :dt_id )
AND ( DL.DT_TPE = :dt_tpe )
AND ( DR_LK.RLTP = '80' )
AND ( STPL.IND = 'T' ) )
============
Plan Table
============
-----------------------------------------------------------------+-----------------------------------+
| Id | Operation                        | Name                  | Rows | Bytes | Cost | Time      |
-----------------------------------------------------------------+-----------------------------------+
| 0   | SELECT STATEMENT                 |                       |       |       |    12 |           |
| 1   | NESTED LOOPS                    |                       |       |       |       |           |
| 2   |   NESTED LOOPS                   |                       |   16K | 2210K |    12 | 00:00:01 |
| 3   |    NESTED LOOPS                  |                       |     1 |   102 |     9 | 00:00:01 |
| 4   |     NESTED LOOPS                 |                       |     1 |    65 |     7 | 00:00:01 |
| 5   |      TABLE ACCESS BY INDEX ROWID | CDL                  |     1 |    32 |     4 | 00:00:01 |
| 6   |       INDEX RANGE SCAN           | XI1_CDL             |     1 |       |     3 | 00:00:01 |
| 7   |      TABLE ACCESS BY INDEX ROWID | CDR_LK              |     2 |    48 |     3 | 00:00:01 |
| 8   |       INDEX RANGE SCAN           | PKEY_21               |     1 |       |     2 | 00:00:01 |
| 9   |     TABLE ACCESS BY INDEX ROWID | CDR                 |     1 |    21 |     2 | 00:00:01 |
| 10 |      INDEX UNIQUE SCAN           | CDR_4398287791      |     1 |       |     1 | 00:00:01 |
| 11 |    INDEX RANGE SCAN              | XIE1_C_PL         |     1 |       |     2 | 00:00:01 |
| 12 |   TABLE ACCESS BY INDEX ROWID    | C_PL              | 2568K |   77M |     3 | 00:00:01 |
-----------------------------------------------------------------+-----------------------------------+
The bad (after gathering stats) Query Explain Plan
============
Plan Table
============
------------------------------------------------------------------+-----------------------------------+
| Id | Operation                         | Name                  | Rows | Bytes | Cost | Time      |
------------------------------------------------------------------+-----------------------------------+
| 0   | SELECT STATEMENT                  |                       |       |       |   58K |           |
| 1   | NESTED LOOPS                     |                       |       |       |       |           |
| 2   |   NESTED LOOPS                    |                       |   30G | 5864G |   58K | 00:10:17 |
| 3   |    HASH JOIN                      |                       |   11K | 1253K |   16K | 00:03:06 |
| 4   |     NESTED LOOPS                  |                       |       |       |       |           |
| 5   |      NESTED LOOPS                 |                       |   11K | 890K |     7 | 00:00:01 |
| 6   |       TABLE ACCESS BY INDEX ROWID | CL              |     1 |    42 |     4 | 00:00:01 |
| 7   |        INDEX RANGE SCAN           | XI1_CL               |     1 |       |     3 | 00:00:01 |
| 8   |       INDEX RANGE SCAN            | PKEY_31               |     1 |       |     2 | 00:00:01 |
| 9   |      TABLE ACCESS BY INDEX ROWID | C_LK              | 3432K | 115M |     3 | 00:00:01 |
| 10 |     TABLE ACCESS FULL             | CDR                 | 3614K | 115M |   16K | 00:03:06 |
| 11 |    INDEX RANGE SCAN               | XI1_C_PL         |     1 |       |     2 | 00:00:01 |
| 12 |   TABLE ACCESS BY INDEX ROWID     | C_PL              | 3465K |   88M |     3 | 00:00:01 |
------------------------------------------------------------------+-----------------------------------+

New sessions every time an sql statement is issued

Hi, I have a problem with using oraoledb (v 10.1.0) with VB6 accessing an Oracle database 9i (v 9.2.0.6). Every time an sql statement is issued in the client side, a new session is started in the server side (seen in Enterprise Manager). I don´'t know why. Is an oraoledb parameter or a database parameter? How can I avoid this? The big problem behind this behaviour is controling row locking. If I issue a "select field from table where conditions for update nowait(or wait n)", this creates a lock that belongs to a session. If a few sentences after I issue an "update the-same-table set the-same-field = value where the-same-condition" as this one creates a new session, an ORA-00054 is raised telling the row(s) is blocked.
any idea?
thanks

I'm a DBA and I encountered the same problem with a system developed for our company. We reported that to the company that developed the application and they sey then close the conections, but they remain in the database.
Could anyone find a solution for this? I believe is a problem in the VB code, but I do not know anything from VB.
thanks,
Lisandro

Stats collection issue on 11.2

Similar Messages

Maybe you are looking for