Greetings I took 10046 Level 12 trace of all the Problem Processes, we see nothing that can cause this. I don't see any SQL, Package/proc accessing huge amount of data in the tkprofd output. The MAx number of rows touched is around 100k (10519) Sicne these connections are always there, I wouldn't know if I have missed the real issue, But I did trace 5 sessions and none of them have any thing thats noticable We submitted all the 10046 Level 12 trace files to SR, they came back with nothing. thats why I am looking for ideas to where to look and ways to reproduce the issues. BN On 9/19/07, Alvaro Jose Fernandez <alvaro.fernandez@xxxxxxxxx> wrote: > > Hello Bn, > > > > Problem: > > > > One process at a time goes upto 715 MB > > anothher process starts goes up to 715 MB > > another process start goes upto 715 MB > > . . . . . . > > > > Until system Crashes > > > > We Backeduout the code, we are back to normal. > > > > We have almost simialr load in one of our DEV server (4X4), We tried same > code, we are not able to reproduce the issue. > > > > similar load? well, but the generated plan for the query (in the package), > is the same in DEV as in prod? > > > > Only other option for us is to disable PGA and go for manual memory > allocation by define sort_* values > > > > We have an SR open, we gave all the dumps oralce asked before we backed > out the code in prod. > > Now oracle wants HEAP dumps, but managment doesn't want this faulty code > in prod until we fix the issue. > > > > The same code works fine in DEV. Server. > > > > , yeah, but, does it generate the same optimizer plan in both db's? > > > > Any Ideas and suggestions are appreciated > > > > put the plan in Prod here (look in v$sql_plan and v$sql_plan_statistics, > for the "hash" value of the problematic query (if it is localized in 1 > query) > > > > Regards > > BN > > > > > > -- > Regards & Thanks > BN > -- Regards & Thanks BN