Missing IN or OUT parameter to the Index: 1

Similar Questions

• How to deal with Missing IN or OUT parameter to the index: 2

  When I click on the query button Search I got this error message "error".
  Parameter IN or OUT to missing index: 2 ". Please show me the way which address them.
  
  Concerning
  KT

  Thank you all,

  I used the query with parameters for the search and when I removed view viewcriteria, this error message "missing IN or Out the setting to index::2. is never show again.but, If I used both bind variables and display the error message of query criteria in my opinion came every time.

  Concerning
  KT

• Error 'Missing IN or OUT parameter to the index' ODI

  Hello

  Im trying to load the data of several Oracle DB data sets for Oracle table and I get the following error:
  

  
  

  "ODI-1228: CAPEX (Export) has failed on the target of ORACLE DEV connection transit area."

  Caused by: java.sql.SQLException: parameter IN or OUT to missing index: 3 "

  This error pops up when loading the data from each data set temporary tables (C$ _0CAPEX...) C$ _4CAPEX) in a general temporary table (C$ _CAPEX). The LKM that im using is SQL to SQL

  

  I think the problem might be related to "target_code" generated by the ODI on this step,

  Insert into C$ _CAPEX

  (

  CUENTA, PERIODO, ANIO, STAGE, F_SOLICITANTE, PROYECTO0, VERSION, AFC, DATA

  )

  values

  (

  : ACCOUNT,: PERIODO, : SP2F. Anio,: STAGE,: F_SOLICITANTE,: PROYECTO0,: VERSION: AFC,: DATA

  )

  Please provide us with your valuable answers.

  Concerning

  Thank you KK and Tina Wang for your answers,

  I found that one of the variables ODI (SP2F. Anio) I was using on a filter had the same name of a (Anio) column of the target table. In view of the comment KK, I tried to pass this filter to the staging, but the problem persisted.

  Just in case anyone has the same problem that I changed the name of the ODI "Anio" variable to another name and now the flow runs without error.

  Concerning

• the size of the out parameter in the procedure

  Hi all:
  
  I have a procedure in a pl/sql package like this:
  create or replace procedure MyProc (PRM_STR in VHARCHAR2, PRM_OUTSTR OUT VARCHAR2) is
  V_TEST VARCHAR2 (100)
  Start
  +...+
  V_STR: = SUBSTR (PRM_STR, 22, 31);
  V_TEST: = TRIM (V_STR);
  PRM_OUTSTR: = V_TEST;
  EXCEPTION
  WHILE OTHERS THEN
  +....+
  myproc end;
  
  When I run it, it always gives me an exception: ORA-06502: PL/SQL: digital or value error: character string buffer too small.
  Then I debug him:
  V_TEST: = TRIM (V_STR)
  is OK.
  While PRM_OUTSTR: = V_TEST, it throws this exception.
  
  I was confused, the out parameter in the procedure has a size? How can I set it?
  
  Please help me!
  Thank you very much!

  You must declare the size of the variable you use in the call to the procedure to be big enough.

  The output parameter itself may not be declared with a size:

  for example

  Your appeal should be something like the following:

  declare
  v_prmstr varchar2(4000)  :=  'Your input value';
  v_prmoutstr varchar2(4000);
  begin
  myproc(v_prmstr,v_prmoutstr) ;
  end;
  

  v_prmoutstr must be reported to be large enough to contain the value returned by the parameter
  PRM_OUTSTR

  added example variable
  Published by: Keith Jamieson on August 11, 2011 13:32

• Return more than an OUT parameter of the stored procedure called in sql

  I searched for it, but maybe that I did a good job. I would return two parameters of a stored procedure that is called from an sql query. Something like
  

  select my_proc(in_param) from dual

  When the results of the query will return 2 columns. It is guaranteed in my design in order to return only a single record.
  
  Is this possible?
  
  The version of Oracle that I use is:

  Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi
  PL/SQL Release 10.2.0.2.0 - Production
  "CORE     10.2.0.2.0     Production"
  TNS for Linux: Version 10.2.0.2.0 - Production
  NLSRTL Version 10.2.0.2.0 - Production

  Is this possible?

  Laughing out loud
  You can not call a stored SQL procedure. Only functions can be called from SQL.

• Linked table filling out parameter is slow (2nd attempt)

  I have exactly the same problem as described in this thread archived: https://forums.oracle.com/thread/1096352.

  
  

  Can anyone tell why adding an OUT with the table binding parameter has such a negative effect on performance? We use Oracle.DataAccess v4.112.3.0.

  
  

  If I have to call the exactly the same stored procedure using OracleDataAdapter.Update (DataSet), it is 10 x faster than the use of the table binding.  And if I have to delete OUT parameter, then the binding table method is at least 5 times faster than OracleDataAdapter.Update (DataSet) in our case.

  
  

  Turns out that Oracle does not provide a way to set "fetch size" for the ExecuteNonQuery method with the table binding.  So when a stored procedure contains an OUT parameter (or function is the RETURN parameter), Oracle returns results of execution of each appellant separately.  This translates into a large number of General networks and slows down the process considerably.

  When you use Update() OracleDataAdapter with DataSet, the results of execution are sent in batches, resulting in fresh low networking overhead.

  Without THE params, there is no problem since nothing is sent to the appellant and to ExecuteNonQuery with table binding works faster than OracleDataAdapter.Update (DataSet).

• Syntax of APEX_PLSQL_JOB. SUBMIT_PROCESS with an OUT parameter

  Hi all
  I use APEX_PLSQL_JOB. SUBMIT_PROCESS and call a procedure that has both an and an OUT parameter.
  
  The parameter works very well; I can call my APEX procedure and pass it the: point APP_JOB as a parameter. The OUT parameter, that I can't make it work. I can call my procedure in a different block in SqlDeveloper and everything works, so I am sure that my code of procedure is correct. I can not get the OUT parameter returned by APEX.
  
  This is the code plsql I call APEX dynamic action:
  

  DECLARE
    l_sql      VARCHAR2(4000);
    l_instance VARCHAR2(30);
     l_job number;
    l_rows_processed number;
  
  BEGIN
  l_instance := :P9_INSTANCE;
    l_sql      := 'BEGIN update_tl_tables_1(:APP_JOB, :F103_ROWS_PROCESSED); END;';
    l_job      := APEX_PLSQL_JOB.SUBMIT_PROCESS( p_sql => l_sql, p_status => 'Background process submitted');
  
  l_rows_processed := :F103_ROWS_PROCESSED;
  insert into gse_lng_jobs (instance, job_id, rows_processed) values (l_instance, l_job, l_rows_processed);
  COMMIT;
  END;

  My procedure is created as:
  

  create or replace
  procedure UPDATE_TL_TABLES_1 (l_app_job IN number, l_rows_processed OUT number)
  IS......

  Again, this works very well for SqlDeveloper. Can someone suggest the correct plsql code? I tried this, use a page element, an element of system etc and not luck. I first tried just passing my procedure a local variable as l_rows_processed, but the procedure wouldn't even run, so I guess that the API needs a real element of APEX, but I'm running out of ideas here.
  
  Thanks in advance,
  John

  It won't work because the job has not yet running when you perform the insertion. So: F103_ROWS_PROCESSED does not contain something useful.

  Why don't you try make insertion as part of employment, for example

  l_sql: = ' BEGIN update_tl_tables_1 (: APP_JOB,: F103_ROWS_PROCESSED); insert into gse_lng_jobs (instance, job_id, rows_processed) values ("' | l_instance |") ', ' || l_job |',: F103_ROWS_PROCESSED); END;';

  .. .quelquechose like this.

• CVI 2013 SP1 - function calls repeated with pointer on a variable array parameter causes a shift of the index

  I have some functions will be pointers as parameter and CVI 2012 SP1, they work as before without problems but with CVI 2013 SP1 they are now incorrect.

  Here the description of what is happening - I found a cure, but a duty adopt the old code and I think it's clear that nobody don't "captures" all lines in a 'big old code' which are affected (maybe):

  I have functions

  'function_XYZ(int *p_paraArr) '.

  with 'p_paraArr' as pointers on a table (int).

  Suppose I have another function

  "fct_TOP (void)".

  where is a local array variable which is inizialized by

  "int TheArray [25] = {0};

  and inside of this "TOP"-function-body I call a function ".

  "function_XYZ (TheArray).

  There are no complains of the compiler (CVI 2012 or 2013) and the code works (but the CVI 2013 only once!).

  But if I put 'fct_TOP' loop I have a lag in the "TheArray' -memory.  (The loop surrounds the function "TOP"! "")

  This means that the result "TheArray" obtained from "function_XYZ (TheArray)" starts at index '1' not on the index '0' - as the first time that the function "function_XYZ (TheArray)" was performed. ".

  The solution is:

  I only replaced

  "function_XYZ (TheArray)" (<1>)

  by

  "function_XYZ (&(TheArray[0]))" (<2>)

  overall the program now works every time (in the whole loop)-the first time (in the loop).

  In the second version (<2>) everything is necessary to "work well":

  The '&' and parentheses "(...)", which contains the element that may be designated by the '& '.

  And I hope that you believe me: I've tested several times, it was only "little" change that solved the problem.

  So it seems that the ICB 2013 (SP1) is a kind of internal offset index by a repeated execution of the

  "function_XYZ (TheArray).

  but I don't know how or why but I see in debug mode by observing the expected against the values in the table received!

  At the first time the (implicit) internal index of 'TheArray' is '0', but the following times (during the execution of the loop) the internal index passes to '1' (seen in the debugger because that all the expected values were shiftet like that!).

  So there's an explicit index in the table ("function_XYZ (&(TheArray[0]))") necessary to make the first time of this clear code execution.

  There are some good improvements in 2013 CVI (SP1) and I like this environment more than the 2012 version - but:

  There are other "changes" also, in the compiler (or linker...?) that are more rigid than "in ancient times.

  The problem of this kind of error is always the 'old code '!

  It is expected of such behavior.

  The compiler/linker do not complain (a complaint would be good!) writing but he made this mistake (in a loop).

  By the way: my 'compilation Options' are set to 'Extended' (without change in the "..." ("- button - Options) and that all of the boxes, except the" OpenMP_support "-box are checked!"» So I think that I put the very rigid compiler - maybe there are some «...» ' - button - settings to get rid of this problem, but I have not found them/it.

  My request:

  -Check the stiffer compiler by the need of an explicit index

  - or switch to the 'old' behavior with "function_XYZ (TheArray)" always refers to implicit index '0' of the element "TheArray". "."

  Thank you for your messages, comments and suggestions.

  -As I wrote before - maybe it's the style of programming or error"self made"... maybe...
  .. But if I replace 'function_XYZ (TheArray)' by "function_XYZ (&(TheArray[0]))" and
  then it works... Why so and not, if bothe the same? ...

  But as long as I do not post sample code, nobody is going to accept - I accept it. So consider this post more as an allusion to the fact that of the LW/CVI 2012-2013 LW/CVI more changed than just the LW - GUI or certain features: the compiler changed its 'way to'... or almost.

  For this problem, I think that I will use the solution 'use no implicit and explicit pointers'.
  Who should be a good idea taking into account
      http://forums.NI.com/T5/LabWindows-CVI/fatal-run-time-error-dereference-of-out-of-bounds-pointer/TD-...

  mybe also only caused by wrong code... who knows... but for me it is a sufficient reason to act as I suggest above.

  Best regards,
  F.

• "The document is not valid. The index.xml file is missing.

  I suddenly can't open one of my docs of numbers. I get a msg "'name of the doc' document is not valid. The index.xml file is missing.  I literally had the open document this morning without problem, closed, tried to reopen and now I get this msg... all in the same session of the computer. It began not after an update or anything like that, right in the middle of a session of the computer.  You seem to affect all the docs of numbers.  I can't open an any of them now.  I am running OS X El Capitan Version 10.11 and numbers 09, Version 2.1.

  Hi jg,.

  The case usual this message, it is that the document has been opened in numbers version 3.xx, which converts it into a new file version that uses the file index.xml internal requested by Numbers ' 09.

  You have 3 numbers installed on your machine? This file has already been opened in this application?

  The file was saved to iCloud or opened by the iOS version numbers or numbers for iCloud?

  Recommended 'cure' is to open the file using the 3 numbers, then save as... or export to format Numbers ' 09. As a result, remember numbers to quit smoking (v3) - menu numbers > numbers to quit smoking; by clicking on the red light closed the file, but doesn't end numbers. So avoid open numbers files by double-clicking on the file itself.

  Instead, start Numbers ' 09 (v2.3) and open the file in the application.

  Kind regards

  Barry

• Error message: the index.xml file is missing.

  I am trying to open a 'Numbers' file, which is stored in Dropbox in the cloud.

  I know there are some discussions about this already on this support group but they all suggest to back up files in Time Machine. I use Dropbox for years with no problems, but today I tried to open a file of numbers in Dropbox and received the message: "the index.xml file is missing." I have 2 other computers and an iPhone 6 and the file opens on them perfectly so my problem is with a single computer.

  I tried pulling the file from Dropbox on the desktop of another computer and then send this file to me as an attachment. I opened this file on the computer sends me questions, drag the file on the desktop and when I tried to open the file, I got the same message.

  It's just strange that it will not be open on computers.

  Any advise?

  Thank you, Tony

  Hi Tony,.

  This is somethng that occurs when you try to open a file of 3 numbers to 2 digits ('09). Make sure that you leave 2 numbers and then try to open the file of numbers 3. That should do it.

  Quinn

• The index.xml file required is missing. Cannot open documents. 10.10.5 sys

  The index.xml file required is missing. Cannot open documents. 10.10.5 sys

  You have two versions of installed Pages, where the Pages ' 09 document format use it internal document index.xml, and all Pages v5 releases use a different document format that does not incorporate the index.xml file. If you have Pages ' 09 running without window, and double-click a v5 document Pages, you will get a Pages ' 09 dialog box indicating that the index.xml file is missing.

  Exit Pages ' 09 and then double click on the document to open correctly in your version of v5 Pages.

• The index.xml file is missing

  The index.xml file is missing - it appears when you try to open a Pages document

  Is - this information that I already posted a few minutes ago, help you solve this problem?

• Determine the index of the selected items in a ListBox?

  Hello

  I can't find a simple/direct method to determine the index of the selected item in a list box.

  I feel I'm missing something, but I can't seem to figure out who (if any) returns an index number if you use it with the recall of .onChange for a ListBox control.

  The following code implements that I need, but is not particularly efficient or elegant and can get confused if you introduce multiple lists to check.

  Any suggestions to reproduce this behavior, even with the best code would be appreciated.

  Thank you!

  var RES = ' palette {text: 'Example-list' properties: {resizable: true}-} ".

  NLP: Panel {orientation: 'row', preferredSize: [400 600]------}

  list1: ListBox {preferredSize: [400 550], properties: {multiselect: true, numberOfColumns:2, showHeaders:true, columnTitles: ["list 1", "item 0"]}}, \

  }}"

  var win = new Window (res)

  Win.Show)

  for (i = 0; i < 10; i ++) {}

  var line = win.pnl.list1.add ("point", "Same entry")

  row.subItems [0] .text = ' paragraph '+ i}.

  Win.PNL.List1.OnChange = function() {}

  var tempArray = new Array()

  for (i = 0; i < win.pnl.list1.items.length; i ++) {}

  If (win.pnl.list1.items [i] .selected == true) {tempArray.push (i)}

  }

  selectedRow = win.pnl.list1.items var [tempArray [0]] .text

  var selectedRowSubitem = win.pnl.list1.items [tempArray [0]] .subItems [0]

  Alert ("selection:" + tempArray + "\n posted content:" + selectedRow + "\t" + selectedRowSubitem)

  }

  .. .in the same time, that should be enough

  win.pnl.list1.onChange = function() {
       alert(this.selection.index); // for this to work set, multiselect:false
  }
  

  I guess you already tried and the result is 'undefined', the reason is that you have this property

  multiselect:true
  

  in this case, the selection returns an array

  this.selection[0].index;
  

  I'd give you the first selected item, even if you only have a single element selected, for all selected items to loop through all the elements in the selection table.

  not sure if the wonderful guide Peter explains this (explained in the Guide to the tools), but you should read it too, he has tons of info.

• Strange - Inserts first slowly, then quickly after the index drop and recreate

  Hello
  
  I have a chart with lines more 1,250,000,000 on Oracle 11.1.0.7, Linux. He had 4 global index, not partitioned. Insertions in this table have been very slow - lots of db file sequential reads, each taking an average of 0,009 second (from tkprof) - not bad, but the overall performance was wrong - so I fell & re-create the primary key index (3 columns in this index) and permanently other 3 index. As a result, total number of db file sequential reads decreased about 4 times (I was expecting that - now, there is only 1, not 4 index) but not only that - the avarage db file sequential read time fell just 0.0014 second!
  
  In further investigation, I found in the form of traces, that BEFORE the fall & recreate, each sequential reading of the db file has been reading completely different blocks ("random") and AFTER the fall & recreate, blocks accessed by db file sequential reads are almost successively ordered (which allows to obtain cached storage Bay, and I think it's why I get 0.0014 instead of 0.009)! My question is - HOW it HAPPENED? Why the index rebuild has helped so much? The index is fragmented? And perhaps helped PCTFREE 10%, which I've recreated the index with, and there is no index block is divided now (but will appear in the future)?
  
  Important notes - the result set that I insert is and has always ordered columns of table KP index. FILESYSTEMIO_OPTIONS parameter is set to SETALL is not OS cache (I presume), which makes my reading faster (because I have Direct IO).
  
  Here is an excerpt of the trace file (expected a single insert operation):
  
  -> > FRONT:
  WAITING #12: nam = 'db file sequential read' ela = 35089 file #= 15 block #= blocks 20534014 = 1 obj #= tim 64560 = 1294827907110090
  WAITING #12: nam = 'db file sequential read' ela = 6434 file #= 15 block #= blocks 61512424 = 1 obj #= tim 64560 = 1294827907116799
  WAITING #12: nam = 'db file sequential read' ela = 7961 file #= 15 block #= blocks 33775666 = 1 obj #= tim 64560 = 1294827907124874
  WAITING #12: nam = 'db file sequential read' ela = 16681 file #= 15 block #= blocks 60785827 = 1 obj #= tim 64560 = 1294827907143821
  WAITING #12: nam = 'db file sequential read' ela = 2380 file #= 15 block #= blocks 60785891 = 1 obj #= tim 64560 = 1294827907147000
  WAITING #12: nam = 'db file sequential read' ela = 4219 file #= 15 block #= blocks 33775730 = 1 obj #= tim 64560 = 1294827907151553
  WAITING #12: nam = 'db file sequential read' ela = 7218 file #= 15 block #= blocks 58351090 = 1 obj #= tim 64560 = 1294827907158922
  WAITING #12: nam = 'db file sequential read' ela = 6140 file #= 15 block #= blocks 20919908 = 1 obj #= tim 64560 = 1294827907165194
  WAITING #12: nam = ela 'db file sequential read' = 542 file #= 15 block #= blocks 60637720 = 1 obj #= tim 64560 = 1294827907165975
  WAITING #12: nam = 'db file sequential read' ela = 13736 file #= 15 block #= blocks 33350753 = 1 obj #= tim 64560 = 1294827907179807
  WAITING #12: nam = 'db file sequential read' ela = 57465 file #= 15 block #= blocks 59840995 = 1 obj #= tim 64560 = 1294827907237569
  WAITING #12: nam = 'db file sequential read' ela = file No. 20077 = 15 block #= blocks 11266833 = 1 obj #= tim 64560 = 1294827907257879
  WAITING #12: nam = 'db file sequential read' ela = 10642 file #= 15 block #= blocks 34506477 = 1 obj #= tim 64560 = 1294827907268867
  WAITING #12: nam = 'db file sequential read' ela = 5393 file #= 15 block #= blocks 20919972 = 1 obj #= tim 64560 = 1294827907275227
  WAITING #12: nam = 'db file sequential read' ela = 15308 file #= 15 block #= blocks 61602921 = 1 obj #= tim 64560 = 1294827907291203
  WAITING #12: nam = 'db file sequential read' ela = 11228 file #= 15 block #= blocks 34032720 = 1 obj #= tim 64560 = 1294827907303261
  WAITING #12: nam = 'db file sequential read' ela = 7885 file #= 15 block #= blocks 60785955 = 1 obj #= tim 64560 = 1294827907311867
  WAITING #12: nam = 'db file sequential read' ela = 6652 file #= 15 block #= blocks 19778448 = 1 obj #= tim 64560 = 1294827907319158
  WAITING #12: nam = 'db file sequential read' ela = 8735 file #= 15 block #= blocks 34634855 = 1 obj #= tim 64560 = 1294827907328770
  WAITING #12: nam = 'db file sequential read' ela = 14235 file #= 15 block #= blocks 61411940 = 1 obj #= tim 64560 = 1294827907343804
  WAITING #12: nam = 'db file sequential read' ela = 7173 file #= 15 block #= blocks 33350808 = 1 obj #= tim 64560 = 1294827907351214
  WAITING #12: nam = 'db file sequential read' ela = 8033 file #= 15 block #= blocks 60493866 = 1 obj #= tim 64560 = 1294827907359424
  WAITING #12: nam = 'db file sequential read' ela = 14654 file #= 15 block #= blocks 19004731 = 1 obj #= tim 64560 = 1294827907374257
  WAITING #12: nam = 'db file sequential read' ela = 6116 file #= 15 block #= blocks 34565376 = 1 obj #= tim 64560 = 1294827907380647
  WAITING #12: nam = 'db file sequential read' ela = 6203 file #= 15 block #= blocks 20920100 = 1 obj #= tim 64560 = 1294827907387054
  WAITING #12: nam = 'db file sequential read' ela = 50627 file #= 15 block #= blocks 61602985 = 1 obj #= tim 64560 = 1294827907437838
  WAITING #12: nam = 'db file sequential read' ela = 13752 file #= 15 block #= blocks 33351193 = 1 obj #= tim 64560 = 1294827907451875
  WAITING #12: nam = 'db file sequential read' ela = 6883 file #= 15 block #= blocks 58686059 = 1 obj #= tim 64560 = 1294827907459551
  WAITING #12: nam = 'db file sequential read' ela = file No. 13284 = 15 block #= blocks 19778511 = 1 obj #= tim 64560 = 1294827907473558
  WAITING #12: nam = 'db file sequential read' ela = 16678 file #= 15 block #= blocks 34226211 = 1 obj #= tim 64560 = 1294827907493010
  WAITING #12: nam = 'db file sequential read' ela = 9565 file #= 15 block #= blocks 61123267 = 1 obj #= tim 64560 = 1294827907507419
  WAITING #12: nam = 'db file sequential read' ela = 6893 file #= 15 block #= blocks 20920164 = 1 obj #= tim 64560 = 1294827907515073
  WAITING #12: nam = 'db file sequential read' ela = 9817 file #= 15 block #= blocks 61603049 = 1 obj #= tim 64560 = 1294827907525598
  WAITING #12: nam = 'db file sequential read' ela = 4691 file #= 15 block #= blocks 33351248 = 1 obj #= tim 64560 = 1294827907530960
  WAITING #12: nam = 'db file sequential read' ela = file No. 25983 = 15 block #= blocks 58351154 = 1 obj #= tim 64560 = 1294827907557661
  WAITING #12: nam = 'db file sequential read' ela = 7402 file #= 15 block #= blocks 5096358 = 1 obj #= tim 64560 = 1294827907565927
  WAITING #12: nam = 'db file sequential read' ela = 7964 file #= 15 block #= blocks 61603113 = 1 obj #= tim 64560 = 1294827907574570
  WAITING #12: nam = 'db file sequential read' ela = 32776 file #= 15 block #= blocks 33549538 = 1 obj #= tim 64560 = 1294827907608063
  WAITING #12: nam = 'db file sequential read' ela = 5674 file #= 15 block #= blocks 60493930 = 1 obj #= tim 64560 = 1294827907614596
  WAITING #12: nam = 'db file sequential read' ela = 9525 file #= 15 block #= blocks 61512488 = 1 obj #= tim 64560 = 1294827907625007
  WAITING #12: nam = 'db file sequential read' ela = 15729 file #= 15 block #= blocks 33549602 = 1 obj #= tim 64560 = 1294827907641538
  WAITING #12: nam = 'db file sequential read' ela = file No. 11510 = 15 block #= blocks 60902458 = 1 obj #= tim 64560 = 1294827907653819
  WAITING #12: nam = 'db file sequential read' ela = 26431 files #= 15 block #= blocks 59841058 = 1 obj #= tim 64560 = 1294827907680940
  WAITING #12: nam = 'db file sequential read' ela = 9196 file #= 15 block #= blocks 33350809 = 1 obj #= tim 64560 = 1294827907690434
  WAITING #12: nam = 'db file sequential read' ela = 7745 file #= 15 block #= blocks 60296291 = 1 obj #= tim 64560 = 1294827907698353
  WAITING #12: nam = 'db file sequential read' ela = 429 file #= 15 block #= blocks 61603177 = 1 obj #= tim 64560 = 1294827907698953
  WAITING #12: nam = 'db file sequential read' ela = 8459 file #= 15 block #= blocks 33351194 = 1 obj #= tim 64560 = 1294827907707695
  WAITING #12: nam = 'db file sequential read' ela = 25998 file #= 15 block #= blocks 49598412 = 1 obj #= tim 64560 = 1294827907733890
  
  2011-01-12 11:25:07.742
  WAITING #12: nam = 'db file sequential read' ela = 7988 file #= 15 block #= blocks 11357900 = 1 obj #= tim 64560 = 1294827907742683
  WAITING #12: nam = 'db file sequential read' ela = 10066 file #= 15 block #= blocks 61512552 = 1 obj #= tim 64560 = 1294827907753540
  WAITING #12: nam = 'db file sequential read' ela = 8400 file #= 15 block #= blocks 33775858 = 1 obj #= tim 64560 = 1294827907762668
  WAITING #12: nam = 'db file sequential read' ela = 11750 file #= 15 block #= blocks 60636761 = 1 obj #= tim 64560 = 1294827907774667
  WAITING #12: nam = 'db file sequential read' ela = 16933 file #= 15 block #= blocks 20533183 = 1 obj #= tim 64560 = 1294827907791839
  WAITING #12: nam = 'db file sequential read' ela = 8895 file #= 15 block #= blocks 61603241 = 1 obj #= tim 64560 = 1294827907801047
  WAITING #12: nam = 'db file sequential read' ela = file No. 12685 = 15 block #= blocks 33775922 = 1 obj #= tim 64560 = 1294827907813913
  WAITING #12: nam = 'db file sequential read' ela = file No. 12664 = 15 block #= blocks 60493994 = 1 obj #= tim 64560 = 1294827907827379
  WAITING #12: nam = 'db file sequential read' ela = 8271 file #= 15 block #= blocks 19372356 = 1 obj #= tim 64560 = 1294827907835881
  WAITING #12: nam = 'db file sequential read' ela = file No. 10825 = 15 block #= blocks 59338524 = 1 obj #= tim 64560 = 1294827907847439
  WAITING #12: nam = 'db file sequential read' ela = 13086 file #= 15 block #= blocks 49440992 = 1 obj #= tim 64793 = 1294827907862022
  WAITING #12: nam = 'db file sequential read' ela = file No. 16491 = 15 block #= blocks 32853984 = 1 obj #= tim 64793 = 1294827907879282
  WAITING #12: nam = 'db file sequential read' ela = 9349 file #= 15 block #= blocks 60133021 = 1 obj #= tim 64793 = 1294827907888849
  WAITING #12: nam = 'db file sequential read' ela = 5680 files #= 15 block #= blocks 20370585 = 1 obj #= tim 64793 = 1294827907895281
  WAITING #12: nam = 'db file sequential read' ela = 34021 file #= 15 block #= blocks 58183834 = 1 obj #= tim 64793 = 1294827907930014
  WAITING #12: nam = 'db file sequential read' ela = 8574 file #= 15 block #= blocks 32179028 = 1 obj #= tim 64793 = 1294827907938813
  WAITING #12: nam = 'db file sequential read' ela = file No. 10862 = 15 block #= blocks 49402735 = 1 obj #= tim 64793 = 1294827907949821
  WAITING #12: nam = 'db file sequential read' ela = 4501 file #= 15 block #= blocks 11270933 = 1 obj #= tim 64793 = 1294827907954533
  WAITING #12: nam = 'db file sequential read' ela = 9936 file #= 15 block #= blocks 61007523 = 1 obj #= tim 64793 = 1294827907964616
  WAITING #12: nam = 'db file sequential read' ela = 7631 file #= 15 block #= blocks 34399970 = 1 obj #= tim 64793 = 1294827907972457
  WAITING #12: nam = 'db file sequential read' ela = 6162 file #= 15 block #= blocks 60305187 = 1 obj #= tim 64793 = 1294827907978797
  WAITING #12: nam = 'db file sequential read' ela = 8555 file #= 15 block #= blocks 20912586 = 1 obj #= tim 64793 = 1294827907987532
  WAITING #12: nam = 'db file sequential read' ela = 9499 file #= 15 block #= blocks 61007587 = 1 obj #= tim 64793 = 1294827907997296
  WAITING #12: nam = 'db file sequential read' ela = 23690 file #= 15 block #= blocks 19769014 = 1 obj #= tim 64793 = 1294827908024105
  WAITING #12: nam = 'db file sequential read' ela = 7081 file #= 15 block #= blocks 61314072 = 1 obj #= tim 64793 = 1294827908031968
  WAITING #12: nam = 'db file sequential read' ela = 31727 file #= 15 block #= blocks 34026602 = 1 obj #= tim 64793 = 1294827908063914
  WAITING #12: nam = 'db file sequential read' ela = 4932 file #= 15 block #= blocks 60905313 = 1 obj #= tim 64793 = 1294827908069052
  WAITING #12: nam = 'db file sequential read' ela = 6616 file #= 15 block #= blocks 20912650 = 1 obj #= tim 64793 = 1294827908075835
  WAITING #12: nam = 'db file sequential read' ela = 8443 file #= 15 block #= blocks 33781968 = 1 obj #= tim 64793 = 1294827908084594
  WAITING #12: nam = 'db file sequential read' ela = 22291 file #= 15 block #= blocks 60641967 = 1 obj #= tim 64793 = 1294827908107052
  WAITING #12: nam = 'db file sequential read' ela = 6610 file #= 15 block #= blocks 18991774 = 1 obj #= tim 64793 = 1294827908113879
  WAITING #12: nam = 'db file sequential read' ela = 6493 file #= 15 block #= blocks 34622382 = 1 obj #= tim 64793 = 1294827908120535
  WAITING #12: nam = 'db file sequential read' ela = 5028 file #= 15 block #= blocks 20912714 = 1 obj #= tim 64793 = 1294827908125861
  WAITING #12: nam = 'db file sequential read' ela = file No. 11834 = 15 block #= blocks 61679845 = 1 obj #= tim 64793 = 1294827908137858
  WAITING #12: nam = 'db file sequential read' ela = 4261 file #= 15 block #= blocks 34498166 = 1 obj #= tim 64793 = 1294827908142305
  WAITING #12: nam = 'db file sequential read' ela = 19267 file #= 15 block #= blocks 60905377 = 1 obj #= tim 64793 = 1294827908161695
  WAITING #12: nam = 'db file sequential read' ela = file No. 14108 = 15 block #= blocks 19769078 = 1 obj #= tim 64793 = 1294827908176046
  WAITING #12: nam = 'db file sequential read' ela = 4128 file #= 15 block #= blocks 33781465 = 1 obj #= tim 64793 = 1294827908180396
  WAITING #12: nam = 'db file sequential read' ela = 9986 file #= 15 block #= blocks 61007651 = 1 obj #= tim 64793 = 1294827908190535
  WAITING #12: nam = 'db file sequential read' ela = 8907 file #= 15 block #= blocks 20912778 = 1 obj #= tim 64793 = 1294827908199614
  WAITING #12: nam = 'db file sequential read' ela = 12023 file #= 15 block #= blocks 34230838 = 1 obj #= tim 64793 = 1294827908211852
  WAITING #12: nam = 'db file sequential read' ela = 29837 file #= 15 block #= blocks 60905441 = 1 obj #= tim 64793 = 1294827908241853
  WAITING #12: nam = 'db file sequential read' ela = 5989 file #= 15 block #= blocks 60133085 = 1 obj #= tim 64793 = 1294827908248065
  WAITING #12: nam = 'db file sequential read' ela = 74172 file #= 15 block #= blocks 33357369 = 1 obj #= tim 64793 = 1294827908322391
  WAITING #12: nam = 'db file sequential read' ela = 5443 file #= 15 block #= blocks 60498917 = 1 obj #= tim 64793 = 1294827908328064
  WAITING #12: nam = 'db file sequential read' ela = 4645 file #= 15 block #= blocks 20912842 = 1 obj #= tim 64793 = 1294827908332912
  WAITING #12: nam = 'db file sequential read' ela = file No. 13595 = 15 block #= blocks 61679909 = 1 obj #= tim 64793 = 1294827908346618
  WAITING #12: nam = 'db file sequential read' ela = 9120 file #= 15 block #= blocks 58356376 = 1 obj #= tim 64793 = 1294827908355975
  WAITING #12: nam = 'db file sequential read' ela = 3186 file #= 15 block #= blocks 19385867 = 1 obj #= tim 64793 = 1294827908359374
  WAITING #12: nam = 'db file sequential read' ela = 5114 file #= 15 block #= blocks 61589533 = 1 obj #= tim 64793 = 1294827908364630
  WAITING #12: nam = 'db file sequential read' ela = 42263 file #= 15 block #= blocks 33356474 = 1 obj #= tim 64793 = 1294827908407045
  WAITING #12: nam = 'db file sequential read' ela = 10683 file #= 15 block #= blocks 58183898 = 1 obj #= tim 64793 = 1294827908417994
  WAITING #12: nam = 'db file sequential read' ela = file No. 10284 = 15 block #= blocks 20529486 = 1 obj #= tim 64793 = 1294827908429134
  WAITING #12: nam = 'db file sequential read' ela = file No. 12544 = 15 block #= blocks 60498981 = 1 obj #= tim 64793 = 1294827908441945
  WAITING #12: nam = 'db file sequential read' ela = 8311 file #= 15 block #= blocks 33191548 = 1 obj #= tim 64793 = 1294827908451011
  WAITING #12: nam = 'db file sequential read' ela = 4261 file #= 15 block #= blocks 59083610 = 1 obj #= tim 64793 = 1294827908455902
  WAITING #12: nam = 'db file sequential read' ela = 4653 file #= 15 block #= blocks 18991837 = 1 obj #= tim 64793 = 1294827908461264
  WAITING #12: nam = 'db file sequential read' ela = 4905 file #= 15 block #= blocks 34685472 = 1 obj #= tim 64793 = 1294827908466897
  WAITING #12: nam = 'db file sequential read' ela = file No. 12360 = 15 block #= blocks 61775403 = 1 obj #= tim 64793 = 1294827908480080
  WAITING #12: nam = 'db file sequential read' ela = 6956 file #= 15 block #= blocks 58921225 = 1 obj #= tim 64793 = 1294827908487704
  WAITING #12: nam = 'db file sequential read' ela = 6068 file #= 15 block #= blocks 19769142 = 1 obj #= tim 64793 = 1294827908494608
  WAITING #12: nam = 'db file sequential read' ela = 5249 file #= 15 block #= blocks 33781528 = 1 obj #= tim 64793 = 1294827908500666
  WAITING #12: nam = 'db file sequential read' ela = 6013 file #= 15 block #= blocks 60905505 = 1 obj #= tim 64793 = 1294827908507366
  WAITING #12: nam = 'db file sequential read' ela = 3014 file #= 15 block #= blocks 20912970 = 1 obj #= tim 64793 = 1294827908511019
  WAITING #12: nam = 'db file sequential read' ela = 3636 file #= 15 block #= blocks 33781591 = 1 obj #= tim 64793 = 1294827908515425
  WAITING #12: nam = 'db file sequential read' ela = file No. 12226 = 15 block #= blocks 58183962 = 1 obj #= tim 64793 = 1294827908528268
  WAITING #12: nam = 'db file sequential read' ela = 7635 file #= 15 block #= blocks 60499173 = 1 obj #= tim 64793 = 1294827908536613
  WAITING #12: nam = 'db file sequential read' ela = 7364 file #= 15 block #= blocks 11270996 = 1 obj #= tim 64793 = 1294827908544203
  WAITING #12: nam = 'db file sequential read' ela = 5452 file #= 15 block #= blocks 34622446 = 1 obj #= tim 64793 = 1294827908550475
  WAITING #12: nam = 'db file sequential read' ela = 9734 file #= 15 block #= blocks 20913034 = 1 obj #= tim 64793 = 1294827908561029
  WAITING #12: nam = 'db file sequential read' ela = 14077 file #= 15 block #= blocks 61679973 = 1 obj #= tim 64793 = 1294827908575440
  WAITING #12: nam = 'db file sequential read' ela = 9694 file #= 15 block #= blocks 34550681 = 1 obj #= tim 64793 = 1294827908585311
  WAITING #12: nam = 'db file sequential read' ela = 6753 file #= 15 block #= blocks 61007715 = 1 obj #= tim 64793 = 1294827908592228
  WAITING #12: nam = 'db file sequential read' ela = 12577 file #= 15 block #= blocks 19769206 = 1 obj #= tim 64793 = 1294827908604943
  WAITING #12: nam = 'db file sequential read' ela = file No. 609 = 15 block #= blocks 61589534 = 1 obj #= tim 64793 = 1294827908605735
  WAITING #12: nam = 'db file sequential read' ela = 6267 file #= 15 block #= blocks 33356538 = 1 obj #= tim 64793 = 1294827908612148
  WAITING #12: nam = 'db file sequential read' ela = 7876 file #= 15 block #= blocks 58184026 = 1 obj #= tim 64793 = 1294827908620164
  WAITING #12: nam = 'db file sequential read' ela = file No. 14058 = 15 block #= blocks 32767835 = 1 obj #= tim 80883 = 1294827908634546
  WAITING #12: nam = 'db file sequential read' ela = 9798 file #= 15 block #= blocks 58504373 = 1 obj #= tim 80883 = 1294827908644575
  WAITING #12: nam = 'db file sequential read' ela = 11081 file #= 15 block #= blocks 11118811 = 1 obj #= tim 80883 = 1294827908655908
  WAITING #12: nam = 'db file sequential read' ela = 6249 file #= 15 block #= blocks 58087798 = 1 obj #= tim 80883 = 1294827908662451
  WAITING #12: nam = 'db file sequential read' ela = 9513 file #= 15 block #= blocks 33331129 = 1 obj #= tim 80883 = 1294827908672904
  WAITING #12: nam = 'db file sequential read' ela = 4648 file #= 15 block #= blocks 60301818 = 1 obj #= tim 80883 = 1294827908677736
  WAITING #12: nam = 'db file sequential read' ela = 6147 file #= 15 block #= blocks 20523119 = 1 obj #= tim 80883 = 1294827908684075
  WAITING #12: nam = 'db file sequential read' ela = file No. 59531 = 15 block #= blocks 61016570 = 1 obj #= tim 80883 = 1294827908743795
  
  2011-01-12 11:25:08.752
  WAITING #12: nam = 'db file sequential read' ela = 8787 file #= 15 block #= blocks 33770842 = 1 obj #= tim 80883 = 1294827908752846
  WAITING #12: nam = 'db file sequential read' ela = 9858 file #= 15 block #= blocks 60895354 = 1 obj #= tim 80883 = 1294827908762960
  WAITING #12: nam = 'db file sequential read' ela = 11237 file #= 15 block #= blocks 19369506 = 1 obj #= tim 80883 = 1294827908775138
  WAITING #12: nam = 'db file sequential read' ela = 5838 file #= 15 block #= blocks 34229712 = 1 obj #= tim 80883 = 1294827908782100
  WAITING #12: nam = 'db file sequential read' ela = 6518 file #= 15 block #= blocks 61221772 = 1 obj #= tim 80883 = 1294827908789403
  WAITING #12: nam = 'db file sequential read' ela = 9946 file #= 15 block #= blocks 20523183 = 1 obj #= tim 80883 = 1294827908800089
  WAITING #12: nam = 'db file sequential read' ela = 16699 file #= 15 block #= blocks 61016634 = 1 obj #= tim 80883 = 1294827908817077
  WAITING #12: nam = 'db file sequential read' ela = file No. 15215 = 15 block #= blocks 33770900 = 1 obj #= tim 80883 = 1294827908832934
  WAITING #12: nam = 'db file sequential read' ela = 8403 file #= 15 block #= blocks 60895418 = 1 obj #= tim 80883 = 1294827908842317
  WAITING #12: nam = 'db file sequential read' ela = 8927 file #= 15 block #= blocks 18950791 = 1 obj #= tim 80883 = 1294827908852190
  WAITING #12: nam = 'db file sequential read' ela = 4382 files #= 15 block #= blocks 34493493 = 1 obj #= tim 80883 = 1294827908856821
  WAITING #12: nam = 'db file sequential read' ela = 9356 file #= 15 block #= blocks 61324964 = 1 obj #= tim 80883 = 1294827908866337
  WAITING #12: nam = 'db file sequential read' ela = 10575 file #= 15 block #= blocks 20883018 = 1 obj #= tim 80883 = 1294827908877102
  WAITING #12: nam = 'db file sequential read' ela = 16601 file #= 15 block #= blocks 60502307 = 1 obj #= tim 80883 = 1294827908893926
  WAITING #12: nam = 'db file sequential read' ela = 5236 file #= 15 block #= blocks 33331193 = 1 obj #= tim 80883 = 1294827908899387
  WAITING #12: nam = 'db file sequential read' ela = 9981 file #= 15 block #= blocks 59830076 = 1 obj #= tim 80883 = 1294827908910427
  WAITING #12: nam = 'db file sequential read' ela = 8100 file #= 15 block #= blocks 19767805 = 1 obj #= tim 80883 = 1294827908918751
  WAITING #12: nam = 'db file sequential read' ela = 12492 file #= 15 block #= blocks 67133332 = 1 obj #= tim 80883 = 1294827908931732
  WAITING #12: nam = 'db file sequential read' ela = 5876 file #= 15 block #= blocks 34229775 = 1 obj #= tim 80883 = 1294827908937859
  WAITING #12: nam = 'db file sequential read' ela = 8741 file #= 15 block #= blocks 61408244 = 1 obj #= tim 80883 = 1294827908948439
  WAITING #12: nam = 'db file sequential read' ela = 8477 file #= 15 block #= blocks 20523247 = 1 obj #= tim 80883 = 1294827908957099
  WAITING #12: nam = 'db file sequential read' ela = 7947 file #= 15 block #= blocks 61016698 = 1 obj #= tim 80883 = 1294827908965210
  WAITING #12: nam = 'db file sequential read' ela = 2384 file #= 15 block #= blocks 33331257 = 1 obj #= tim 80883 = 1294827908967773
  WAITING #12: nam = 'db file sequential read' ela = 3585 file #= 15 block #= blocks 59571985 = 1 obj #= tim 80883 = 1294827908971564
  WAITING #12: nam = 'db file sequential read' ela = 7753 file #= 15 block #= blocks 5099571 = 1 obj #= tim 80883 = 1294827908979647
  WAITING #12: nam = 'db file sequential read' ela = 8205 file #= 15 block #= blocks 61408308 = 1 obj #= tim 80883 = 1294827908988200
  WAITING #12: nam = 'db file sequential read' ela = 7745 file #= 15 block #= blocks 34229335 = 1 obj #= tim 80883 = 1294827908996129
  WAITING #12: nam = 'db file sequential read' ela = file No. 10942 = 15 block #= blocks 61325028 = 1 obj #= tim 80883 = 1294827909007244
  WAITING #12: nam = 'db file sequential read' ela = 6247 file #= 15 block #= blocks 20523311 = 1 obj #= tim 80883 = 1294827909013706
  WAITING #12: nam = 'db file sequential read' ela = file No. 16188 = 15 block #= blocks 60777362 = 1 obj #= tim 80883 = 1294827909030088
  WAITING #12: nam = 'db file sequential read' ela = file No. 16642 = 15 block #= blocks 33528224 = 1 obj #= tim 80883 = 1294827909046971
  WAITING #12: nam = 'db file sequential read' ela = file No. 10118 = 15 block #= blocks 60128498 = 1 obj #= tim 80883 = 1294827909057402
  WAITING #12: nam = 'db file sequential read' ela = file No. 10747 = 15 block #= blocks 802317 = 1 obj #= tim 64495 = 1294827909069165
  WAITING #12: nam = 'db file sequential read' ela = 4795 file number = 15 block #= blocks 33079541 = 1 obj #= tim 64560 = 1294827909074367
  WAITING #12: nam = 'db file sequential read' ela = 6822 file #= 15 block #= blocks 20913098 = 1 obj #= tim 64793 = 1294827909081436
  WAITING #12: nam = 'db file sequential read' ela = file No. 10932 = 15 block #= blocks 19369570 = 1 obj #= tim 80883 = 1294827909092607
  
  
  
  --> > AFTER:
  WAITING #23: nam = 'db file sequential read' ela = 16367 file #= 15 block #= blocks 70434065 = 1 obj #= tim 115059 = 1295342220878947
  WAITING #23: nam = 'db file sequential read' ela = 1141 file #= 15 block #= blocks 70434066 = 1 obj #= tim 115059 = 1295342220880549
  WAITING #23: nam = 'db file sequential read' ela = 456 file #= 15 block #= blocks 70434067 = 1 obj #= tim 115059 = 1295342220881615
  WAITING #23: nam = 'db file sequential read' ela = 689 file #= 15 block #= blocks 70434068 = 1 obj #= tim 115059 = 1295342220882617
  WAITING #23: nam = 'db file sequential read' ela = 495 file #= 15 block #= blocks 70434069 = 1 obj #= tim 115059 = 1295342220883482
  WAITING #23: nam = 'db file sequential read' ela = 419 file #= 15 block #= blocks 70434070 = 1 obj #= tim 115059 = 1295342220884195
  WAITING #23: nam = 'db file sequential read' ela = 149 file #= 15 block #= blocks 70434071 = 1 obj #= tim 115059 = 1295342220884629
  WAITING #23: nam = 'db file sequential read' ela = 161 file #= 15 block #= blocks 70434072 = 1 obj #= tim 115059 = 1295342220885085
  WAITING #23: nam = 'db file sequential read' ela = 146 file #= 15 block #= blocks 70434073 = 1 obj #= tim 115059 = 1295342220885533
  WAITING #23: nam = ela 'db file sequential read' = 188 file #= 15 block #= blocks 70434074 = 1 obj #= tim 115059 = 1295342220886026
  WAITING #23: nam = 'db file sequential read' ela = 181 file #= 15 block #= blocks 70434075 = 1 obj #= tim 115059 = 1295342220886498
  WAITING #23: nam = 'db file sequential read' ela = 303 file #= 15 block #= blocks 70434076 = 1 obj #= tim 115059 = 1295342220887082
  WAITING #23: nam = 'db file sequential read' ela = file No. 550 = 15 block #= blocks 70434077 = 1 obj #= tim 115059 = 1295342220887916
  WAITING #23: nam = 'db file sequential read' ela = 163 file #= 15 block #= blocks 70434078 = 1 obj #= tim 115059 = 1295342220888402
  WAITING #23: nam = 'db file sequential read' ela = 200 file #= 15 block #= blocks 70434079 = 1 obj #= tim 115059 = 1295342220888980
  WAITING #23: nam = 'db file sequential read' ela = 134 file #= 15 block #= blocks 70434080 = 1 obj #= tim 115059 = 1295342220889409
  WAITING #23: nam = 'db file sequential read' ela = 157 file #= 15 block #= blocks 70434081 = 1 obj #= tim 115059 = 1295342220889850
  WAITING #23: nam = 'db file sequential read' ela = 5112 file #= 15 block #= blocks 70434540 = 1 obj #= tim 115059 = 1295342220895272
  WAITING #23: nam = 'db file sequential read' ela = 276 file #= 15 block #= blocks 70434082 = 1 obj #= tim 115059 = 1295342220895640
  
  2011-01-18 10:17:00.898
  WAITING #23: nam = 'db file sequential read' ela = 2936 file #= 15 block #= blocks 70434084 = 1 obj #= tim 115059 = 1295342220898921
  WAITING #23: nam = 'db file sequential read' ela = 1843 file number = 15 block #= blocks 70434085 = 1 obj #= tim 115059 = 1295342220901233
  WAITING #23: nam = 'db file sequential read' ela = 452 file #= 15 block #= blocks 70434086 = 1 obj #= tim 115059 = 1295342220902050
  WAITING #23: nam = 'db file sequential read' ela = 686 file #= 15 block #= blocks 70434087 = 1 obj #= tim 115059 = 1295342220903031
  WAITING #23: nam = 'db file sequential read' ela = 1582 file #= 15 block #= blocks 70434088 = 1 obj #= tim 115059 = 1295342220904933
  WAITING #23: nam = 'db file sequential read' ela = 179 file #= 15 block #= blocks 70434089 = 1 obj #= tim 115059 = 1295342220905544
  WAITING #23: nam = 'db file sequential read' ela = 426 file #= 15 block #= blocks 70434090 = 1 obj #= tim 115059 = 1295342220906303
  WAITING #23: nam = 'db file sequential read' ela = 138 file #= 15 block #= blocks 70434091 = 1 obj #= tim 115059 = 1295342220906723
  WAITING #23: nam = 'db file sequential read' ela = 3004 file #= 15 block #= blocks 70434092 = 1 obj #= tim 115059 = 1295342220910053
  WAITING #23: nam = 'db file sequential read' ela = 331 file #= 15 block #= blocks 70434093 = 1 obj #= tim 115059 = 1295342220910765
  WAITING #23: nam = 'db file sequential read' ela = 148 file #= 15 block #= blocks 70434094 = 1 obj #= tim 115059 = 1295342220911236
  WAITING #23: nam = 'db file sequential read' ela = 296 file #= 15 block #= blocks 70434095 = 1 obj #= tim 115059 = 1295342220911836
  WAITING #23: nam = 'db file sequential read' ela = 441 file #= 15 block #= blocks 70434096 = 1 obj #= tim 115059 = 1295342220912581
  WAITING #23: nam = 'db file sequential read' ela = 157 file #= 15 block #= blocks 70434097 = 1 obj #= tim 115059 = 1295342220913038
  WAITING #23: nam = 'db file sequential read' ela = 281 file #= 15 block #= blocks 70434098 = 1 obj #= tim 115059 = 1295342220913603
  WAITING #23: nam = 'db file sequential read' ela = file No. 150 = 15 block #= blocks 70434099 = 1 obj #= tim 115059 = 1295342220914048
  WAITING #23: nam = 'db file sequential read' ela = 143 file #= 15 block #= blocks 70434100 = 1 obj #= tim 115059 = 1295342220914498
  WAITING #23: nam = 'db file sequential read' ela = 384 file #= 15 block #= blocks 70434101 = 1 obj #= tim 115059 = 1295342220916907
  WAITING #23: nam = 'db file sequential read' ela = file No. 164 = 15 block #= blocks 70434102 = 1 obj #= tim 115059 = 1295342220917458
  WAITING #23: nam = 'db file sequential read' ela = 218 file #= 15 block #= blocks 70434103 = 1 obj #= tim 115059 = 1295342220917962
  WAITING #23: nam = 'db file sequential read' ela = file No. 450 = 15 block #= blocks 70434104 = 1 obj #= tim 115059 = 1295342220918698
  WAITING #23: nam = 'db file sequential read' ela = file No. 164 = 15 block #= blocks 70434105 = 1 obj #= tim 115059 = 1295342220919159
  WAITING #23: nam = 'db file sequential read' ela = 136 file #= 15 block #= blocks 70434106 = 1 obj #= tim 115059 = 1295342220919598
  WAITING #23: nam = 'db file sequential read' ela = 143 file #= 15 block #= blocks 70434107 = 1 obj #= tim 115059 = 1295342220920041
  WAITING #23: nam = 'db file sequential read' ela = 3091 file #= 15 block #= blocks 70434108 = 1 obj #= tim 115059 = 1295342220925409

  user12196647 wrote:
  Hemant, Jonathan - thanks for the comprehensive replies. To summarize:

  It's the 11.1 (11.1.0.7) database on 64-bit Linux. No compression is used for everything, all the blocks are 16 k tablespaces are SAMS created with attributes EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO BIGFILE tablespaces (separate for tables and separate for the index tablespace). I do not have to rebuild the indexes of PK, but abandoned all indexes, and then recreated the KP (but it's okay - reconstruction is still that let down & create, isn't it?).

  Traces were made during the pl/sql loop forall was actually insert. Each pl/sql forall loop inserts 100 lines "at once" (we use fetch bulk collect limit 100), but the loading process inserts a few million records (pl/sql forall loop is closed :)). I stuck that part of traces - wait events for 100 (a set of) 'before' 100 'after' inserts and inserts. Wait for events to another inserts look exacly the same - always blocks 'random' in 'before the index recreate' inserts and inserts almost ordained blocks in "after the index recreate." The objects_ids were certainly indexes.

  I think that the explanation of Hemant is correct. The point is, my structure of the index is of (X, Y, DATE), where X and are 99% repeating at each loading data, values and DATE is increased by one for each data load. Because I'm always insert ordered by PK, for loading a new DATE, I visit each index leaf block, in order, as in the analysis of comprehensive index. Because I'm inserted in each block sheet in every load, I have many index block splits. Which caused my pads of sheets to be physically non-contiguous after awhile. Reconstruction has been my healing...

  You got your answer before I had time to finish a model of your data set - but I think you're description is fairly accurate.
  A few thoughts if:

  WAITING #12: nam = 'db file sequential read' ela = file No. 10747 = 15 block #= blocks 802317 = 1 obj #= tim 64495 = 1294827909069165
  WAITING #12: nam = 'db file sequential read' ela = 4795 file number = 15 block #= blocks 33079541 = 1 obj #= tim 64560 = 1294827909074367
  WAITING #12: nam = 'db file sequential read' ela = 6822 file #= 15 block #= blocks 20913098 = 1 obj #= tim 64793 = 1294827909081436
  WAITING #12: nam = 'db file sequential read' ela = file No. 10932 = 15 block #= blocks 19369570 = 1 obj #= tim 80883 = 1294827909092607

  Unless you missed a bit when your trace file copying, the index with the id of the object 64495 has not subject to drive the way readings which the other clues were. It would be nice to know why. There are two "obvious" possibilities - (a) it has been very well buffered or (b) there is an index where almost all the entries are zero, so it is rarely changed. Because it has the object id lowest of all indexes, it is possible that it is the primary key index (but I don't because I tend to create the primary key of a table before I create any index) and if this is correct your waste of time was not on the primary key index, and perhaps he tends to be very well buffered the nature of popular queries.

  Changes in performance when inserting millions of lines tend to be non-linear as the number of indexes grow.

  As you insert data in the primary key order draw you maximum benefits caching for insertions in the KP index. And since you insert a very large number of lines - the order of 0.5% - 1% of the current lines, in light of your comment 'millions' - you're likely to insert two or three lines in each block of the pharmacokinetics of the index (by the way it must compress on the first two columns)) allowing Oracle to optimize its work in several ways.

  But for the other clues you are probably very randomly jump to insert rows, and this led to two different effects:
  

  
  You must keep N times as many blocks in the buffer to get similar read benefits
  each insertion in the index non-PK blocks is likely to be a row insert - which maximise cancel it and redo overhead more undo and redo written
  each insertion in an index block finally requires the block to write on the disc - which means more i/o, which slows down the readings
  as you read blocks (and you have read several of them) you can force the Oracle to write and other index blocks that need to be reviewed to equal.
  

  It is perfectly possible that almost all of your performance gain comes to drop the three indexes, and only a relatively small fraction come to rebuild the primary key.

  One final thought of block shares. I think that you have found an advantage any readahead (non-Oracle) when the index blocks are classified physically, if you have a trade-off between how many times you rebuild to this advantage and to find a time during which you can afford the resources to rebuild. If you want the best compromise (a) don't forget the compression option - it seems appropriate, (b) consider the benefits of partitioning range date - it seems very appropriate in your case, and (c) by varying the PCTFREE when you rebuild the index you can assign the number of insert cycles before the effects of the splits of block of sheets have a significant impact on the randomness of the IO.

  I have an idea-if I changed the index structure to (DATE, X, Y) then I would always insert in block leaves more right side, I'd have 90-10 splits instead of 50 / 50 splits and leafs would be physically contiguous, so any necessary new buildings - am I right?

  You cannot change the order of index column until you check the use of the index. If the most important and most frequent queries are "select table where colx = X and coly = O and date_col between A and B", you must index this round way. (In fact, you can look at the possibility of using a range partiitoned index organized table for data).

  Concerning
  Jonathan Lewis

• is there a way to get the index of the html text field cursor position

  I'm working on a block of text as MC with 'insert text at position X' and 'Find and replace' can someone tell me how to find the index of an html text field cursor. Selection.getBeginIndex (), Selection.getEndIndex (), Selection.getCaretIndex () as far as I know these methods only work with text and not htmltext.
  What I'm trying to do, it's affecting different parts of the chain to the variables so that I can combine in order to restore my html string.

  ray1872:

  If I understand correctly, you want the corresponding position in the
  another index of the caret htmlText property (who, like you, has no on the)
  position in the plain text of the textfield content version).

  Here's how I'd do. It is perhaps easier or more effective
  way (using objects XML etc.), but I don't know it. You could conduct all
  your search string in plain text and then convert the result of
  the positions of html. I didn't build this to accept negative parameters
  for the parameter pos (for example, end of string towards the back), but the
  function could be adapted to do this also if necessary. The test data is
  not good html from a text field, but it does not really matter what he
  is as long as its formatting correctly. It separates only tags of
  content to allow apples to apples comparison.

  some test data
  var testStringXML = ""Hello I can't tell you hOE happy I mod.'; "
  var undecoratedString = Hello "I can't tell you how happy I am.";

  the conversion function
  function findDecoratedPosition(pos:Number,_xmlString:String,_test:Boolean):Number {}
  anything between '<' and="" '="">' should be excluded from the search in plain text.
  create a table of elements of array (n = 2), consisting of tag and then plain text
  requires xml/html properly put in the form
  var tempArr:Array = xmlString.split (')<>
  for (var aa = 0; aa
  tempArr [aa] is [aa] tempArr,.split(">").;
  }
  remove the first and last elements in the new array (they are empty)
  tempArr.pop ();
  tempArr.shift ();
  find the location of corresponding plaintext and calculate the position "decorated."
  var retPos:Number = 0;
  var posCount:Number = 0;
  for (var aa = 0; aa
  retPos += tempArr [aa] [0] .length + 2 + tempArr [aa] [1] .length;
  + 2 allows you to lack< and="">
  posCount += tempArr [aa] [1] .length;
  If (posCount > pos) {}
  return (retPos + (pos-posCount));
  }
  }
  out of range
  Returns - 1;

  }

  test code:
  for (var aa = 0; aa
  var altPos = findDecoratedPosition (aa, testStringXML);
  trace (undecoratedString.charAt (AA) +"position" + aa + "in clear corresponds to the position" + altPos + "in decorated version [" + testStringXML.charAt (altPos) + "" "]" ");

  }