when i do a count(*) an a 1.2GB table, just after an app finishes inserting
20 million records
i can see from iostat that, that disk is being read as well as written to
!!!
the only reason i can think of WRITES being performed while being READ is
the block cleanout is being performed by the
Could you please explain with an example .
Thanks in advance
Deepa
|+-
|| [EMAIL PROTECTED]|
|| ardier.com |
|| |
|| 17/10/2002 08:14 PM
That's sounds about right...
- Kirti
-Original Message-
Sent: Saturday, October 19, 2002 3:48 AM
To: Multiple recipients of list ORACLE-L
when i do a count(*) an a 1.2GB table, just after an app finishes inserting
20 million records
i can see from iostat that, that disk is being read
Here's Gaja response to clarify his role in 'fixing' OEM :
' ...that I am NOT a product manager. I am here to provide technical
direction for the product. I am very much open to receiving rants,
suggestions and ideas. Bugs should be filed using the normal channels. '
- Kirti
-Original
Deshpande, Kirti wrote:
That's sounds about right...
- Kirti
-Original Message-
Sent: Saturday, October 19, 2002 3:48 AM
To: Multiple recipients of list ORACLE-L
when i do a count(*) an a 1.2GB table, just after an app finishes inserting
20 million records
i can see from
Stephane,
The db version in question is 7.3.2. And as of 7.3 the init parameter,
delayed_logging_block_cleanouts, defaults to TRUE (for OPS and non-OPS).
From my understanding of the delayed block cleanout, when oracle commits a
transaction the blocks that it changed are not immediately marked
index blocks need to be cleaned out too...
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Saturday, October 19, 2002 7:43 AM
Deshpande, Kirti wrote:
That's sounds about right...
- Kirti
-Original Message-
Sent: Saturday,
Joshy,
Go to technet.oracle.com You will have to log in, if you don't have an
account, its free to create one.
Click on Downloads
Click on Oracle 8i (Under the Archived Products heading)
I believe it is the last one listed or at least somewhere near the bottom.
Dennis,
Thanks for the reply and congratulations but a little late. I have benn
well above that notch for many years. Testing a single test case is not
always conclusive. Certainly combing through countless documentation can
prove to be somewhat futile. It took me quite a while to find what I
Stephane:
INSERTs certainly associated with block cleanout. But the issue here
Rahul is doing a Direct load and this does not work as expected in earlier
versions (7.3 and below). They do not use ITLs as in the regular inserts
and there used be some bugs in 7.x versions were ITLs are not used in
Hi Diego,
After performing quite a few test you are 100% correct. I appreciate your
insight.
It is conclusive using IN is the best approach.
Rick
dcutrone
Rick,
It depends on your usage
If you use exists for checking any valid value from database like a trigger
in Oracle Forms for acceting valid values it just check the first value and
comes back very fast (much much faster than IN).
But in case if you want to retrieve all applicable
If I may add something it may be worth trying /*+ USE_HASH */ and /*+
USE_MERGE */after the select in the INNER query. Depends on a lot of
factors but it may be very efficient, especially if the inner query
returns many rows.
[EMAIL PROTECTED] wrote:
Hi Diego,
After performing quite a few
Friends :
I have a situation :
I need to import file wiht 29.000.000 lines and after it i would like to
create a index in background on unix.
Does anyone have some example off shell script that does it using nohup and
?
My idea is to call just one time and to run all operations, like that :
14 matches
Mail list logo
