Re: ** v$log.status
There is a pretty good explanation in this usenet thread: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8threadm=OoSWa.122%246d2.89%40newssvr22.news.prodigy.comrnum=1prev=/groups%3Fq%3Dv%2524log.status%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3DOoSWa.122%25246d2.89%2540newssvr22.news.prodigy.com%26rnum%3D1 Regards, Dave [EMAIL PROTECTED] wrote: Hi, In view v$log there is a column status. This changes from current (if the redo log is in use) to atcive then to inactive. Documentation says : # ACTIVE: The log is active but is not the current log. It is needed for crash recovery. It may be in use for block recovery. It might or might not be archived. # INACTIVE: The log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived. So if it is in 'ACTIVE' status : it means it is needed for crash/instance recovery? So what does it mean? That changes in this log are still not written to data files? What else? Is this related to delayed block cleanout etc or no connection? What factor affects how long it will be in ACTIVE state before going to INACTIVE? What can be changed to control how long it takes. Any trade off? Any detailed explanation on this will be greatly appreciated. You can mail me direct or to the list. Thank you. Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://us.rd.yahoo.com/evt=21608/*http://webhosting.yahoo.com/ps/sb/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: When does Oracle use 'Index Fast Scan'
One situation I can think of where a (non-fast) full index scan can be helpful is when the index contains all the columns needed for the query, the query requires all the rows of the table, and the query requires the results to be sorted according to the index. This way, fast full index scan may be slower because you need to sort the rows after retrieving the blocks, whereas the non-fast full index scan does not. Regards, Dave [EMAIL PROTECTED] wrote: I know when oracle uses a fast full scan. Its the full scan that does 1 I/O at a time. I rarely see oracle using it and when it does, it generally means my table(s) aren't properly analyzed. From: David Hau [EMAIL PROTECTED] Date: 2004/01/26 Mon PM 10:34:25 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: When does Oracle use 'Index Fast Scan' Correction: the Index Range Scan can be parallelized when it involves multiple partitions. - Dave David Hau wrote: I assume you're talking about the Fast Full Index Scan. This is used when the index contains all the columns necessary to answer the query. It's faster than a Full Table Scan because indexes are smaller than entire rows, so a Fast Full Index Scan will scan fewer blocks than a Full Table Scan. It's faster than an Index Range Scan firstly because Fast Full Index Scan scans the blocks in sequential order, whereas the Index Range Scan traverses the B-tree index structure in scanning the blocks, resulting in a random access I/O pattern which is slower. This is also why the Oracle documentation says that with a Fast Full Index Scan, the result is not sorted by the index key (because the result is not obtained by traversing the index structure.) Secondly, the better performance is also because the Fast Full Index Scan uses multiblock reads and is capable of parallel operation, whereas the Index Range Scan is capable of neither. Regards, Dave. [EMAIL PROTECTED] wrote: I have found that the vast majority of time that Oracle chooses this method, my statistics are stale and the query is sub-optimal. One time, Oracle changed from a 'range scan' to this type of scan with a FIRST_ROWS hint and this reduced performance. This is just a full scan of the index, one block at a time right? When would this ever be superior to a Fast Full Scan or a Range Scan? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: When does Oracle use 'Index Fast Scan'
This is where the access time of your disks (or SAN) makes a difference. If your disks have really fast access time, then a random-access pattern would not cause much performance degradation and so a range scan would not be slow at all, even though it's traversing the b-tree index structure. If you're only striping together disks with relatively slow access time (e.g. using a striped IDE disk array), then you have high throughput but not that fast an access time. In this case, fast full index scan would be much faster than an index range scan because the fast full scan reads the blocks sequentially and a sequential disk I/O requires only positioning the head once (assuming the disk is not fragmented). The rest of the time depends on the throughput. If you stripe together a large enough number of IDE disks, then your throughput is great but your access time is still the access time of a single IDE drive which is not that fast. This is assuming you need to do a physical I/O to obtain the blocks. Of course, if the blocks already reside in the buffer cache, then it's a different story. Regards, Dave [EMAIL PROTECTED] wrote: btw, in many cases range scan is faster than a fast full scan. Range scan recursively hits the nodes that are needed and skips the ones that are not. So it reads less blocks. So if you are looking for a 'range' or a specific value, range scan beats fast full scan most of the time. Less Logical and Physical I/Os. test it and hint your queries From: David Hau [EMAIL PROTECTED] Date: 2004/01/26 Mon PM 10:34:25 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: When does Oracle use 'Index Fast Scan' Correction: the Index Range Scan can be parallelized when it involves multiple partitions. - Dave David Hau wrote: I assume you're talking about the Fast Full Index Scan. This is used when the index contains all the columns necessary to answer the query. It's faster than a Full Table Scan because indexes are smaller than entire rows, so a Fast Full Index Scan will scan fewer blocks than a Full Table Scan. It's faster than an Index Range Scan firstly because Fast Full Index Scan scans the blocks in sequential order, whereas the Index Range Scan traverses the B-tree index structure in scanning the blocks, resulting in a random access I/O pattern which is slower. This is also why the Oracle documentation says that with a Fast Full Index Scan, the result is not sorted by the index key (because the result is not obtained by traversing the index structure.) Secondly, the better performance is also because the Fast Full Index Scan uses multiblock reads and is capable of parallel operation, whereas the Index Range Scan is capable of neither. Regards, Dave. [EMAIL PROTECTED] wrote: I have found that the vast majority of time that Oracle chooses this method, my statistics are stale and the query is sub-optimal. One time, Oracle changed from a 'range scan' to this type of scan with a FIRST_ROWS hint and this reduced performance. This is just a full scan of the index, one block at a time right? When would this ever be superior to a Fast Full Scan or a Range Scan? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: When does Oracle use 'Index Fast Scan'
This is where the access time of your disks (or SAN) makes a difference. If your disks have really fast access time, then a random-access pattern would not cause much performance degradation and so a range scan would not be slow at all, even though it's traversing the b-tree index structure. If you're only striping together disks with relatively slow access time (e.g. using a striped IDE disk array), then you have high throughput but not that fast an access time. In this case, fast full index scan would be much faster than an index range scan because the fast full scan reads the blocks sequentially and a sequential disk I/O requires only positioning the head once (assuming the disk is not fragmented). The rest of the time depends on the throughput. If you stripe together a large enough number of IDE disks, then your throughput is great but your access time is still the access time of a single IDE drive which is not that fast. This is assuming you need to do a physical I/O to obtain the blocks. Of course, if the blocks already reside in the buffer cache, then it's a different story. Regards, Dave [EMAIL PROTECTED] wrote: btw, in many cases range scan is faster than a fast full scan. Range scan recursively hits the nodes that are needed and skips the ones that are not. So it reads less blocks. So if you are looking for a 'range' or a specific value, range scan beats fast full scan most of the time. Less Logical and Physical I/Os. test it and hint your queries From: David Hau [EMAIL PROTECTED] Date: 2004/01/26 Mon PM 10:34:25 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: When does Oracle use 'Index Fast Scan' Correction: the Index Range Scan can be parallelized when it involves multiple partitions. - Dave David Hau wrote: I assume you're talking about the Fast Full Index Scan. This is used when the index contains all the columns necessary to answer the query. It's faster than a Full Table Scan because indexes are smaller than entire rows, so a Fast Full Index Scan will scan fewer blocks than a Full Table Scan. It's faster than an Index Range Scan firstly because Fast Full Index Scan scans the blocks in sequential order, whereas the Index Range Scan traverses the B-tree index structure in scanning the blocks, resulting in a random access I/O pattern which is slower. This is also why the Oracle documentation says that with a Fast Full Index Scan, the result is not sorted by the index key (because the result is not obtained by traversing the index structure.) Secondly, the better performance is also because the Fast Full Index Scan uses multiblock reads and is capable of parallel operation, whereas the Index Range Scan is capable of neither. Regards, Dave. [EMAIL PROTECTED] wrote: I have found that the vast majority of time that Oracle chooses this method, my statistics are stale and the query is sub-optimal. One time, Oracle changed from a 'range scan' to this type of scan with a FIRST_ROWS hint and this reduced performance. This is just a full scan of the index, one block at a time right? When would this ever be superior to a Fast Full Scan or a Range Scan? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: FW: pl/sql array processing?
If mypackage.function(i) is doing some DML operation on i, then the real
way to make it faster is to modify the signature of
mypackage.function(i) to take an array instead, and to do a forall ...
dml operation within mypackage.function(i).
forall is most useful when you want to minimize context switching
between the pl/sql and sql engines for an array. Using forall you'll be
switching context only once whereas using a regular for loop you'll be
switching context for every member of the array.
Regards,
Dave
[EMAIL PROTECTED] wrote:
Declare
type numTbl is table of number index by binary_integer;
refTblnumTbl;
i number;
str varchar2(30);
begin
refTbl (1) := 1;
refTbl (9) := 1;
refTbl(15) := 1;
refTbl(99) := 1;
forall i in refTbl.first..refTbllast
begin
dbms_output.put_line ('i=' || i);
str:= my_package.function(i);
end;
end;
/
Of course, it doesn't make sense because varchar2 variable string
will be lost after each iteration. May be an actual example that
makes sense
would motivate more people to respond.
On 01/27/2004 12:54:29 PM, Guang Mei wrote:
My following message did not seem to make it to oracle-l.freelists.
Let me
try it again.
Guang
-
Hi,
I have the folliwng pl/sql code for oracle 8173. I am wondering if
there is
a way to make it faster by not looping each array elements, but doing
some
kind of forall opration to my_package.function?
declare
type numTbl is table of number index by binary_integer;
refTbl numTbl;
i number;
str varchar2(30);
begin
refTbl (1) := 1;
refTbl (9) := 1;
refTbl(15) := 1;
refTbl(99) := 1;
i := refTbl.first;
while i is not null loop
dbms_output.put_line ('i=' || i);
str:= my_package.function(i);
i := refTbl.next(i);
end loop;
end;
/
TIA.
Guang
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Guang Mei
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: David Hau
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
Re: FW: pl/sql array processing?
forall should be used as follows:
forall index in lower_bound..upper_bound
sql statement;
Putting anything other than a sql statement (e.g. a pl/sql block) in a
forall statement defeats its purpose.
If you think about it, forall achieves its performance improvement by
binding arrays to the arguments of a sql statement, instead of binding
individual elements of the array to the sql statement. This is faster
because now the entire array is passed from the pl/sql engine to the sql
engine all in one shot, and so this minimizes context switching between
the pl/sql engine and the sql engine. This is analogous to the array
binding in OCI if you're familiar with OCI or Pro*C programming.
Putting anything other than a sql statement in a forall statement does
not achieve any benefit because you're not switching context to the sql
engine.
So Guang, I think what you should do is move the forall closest to where
you're doing the sql (DML) operation. If you're doing the DML within
mypackage.function(...) then pass the entire array into
mypackage.function(...) and then do the forall within mypackage.function.
Regards,
Dave
[EMAIL PROTECTED] wrote:
Sorry I did not make it clear that the number I used here (1, 9, 15,99) are
just examples, the actual element index is a varible and they are not
continuous. Yes, refTbl can be defined into a package. I guess what I am
asking is if there is a way in pl/sql to do something like
-- FORALL array element indexes (they are non-continuous)
call a package function (parameter: element index)
-- end for
without looping the array.
-- orginal code:
declare
type numTbl is table of number index by binary_integer;
refTblnumTbl;
i number;
str varchar2(30);
begin
refTbl (1) := 1;
refTbl (9) := 1;
refTbl(15) := 1;
refTbl(99) := 1;
i := refTbl.first;
while i is not null loop
dbms_output.put_line ('i=' || i);
str:= my_package.function(i);
i := refTbl.next(i);
end loop;
end;
/
Guang
-Original Message-
Mladen Gogala
Sent: Tuesday, January 27, 2004 2:29 PM
To: Multiple recipients of list ORACLE-L
On 01/27/2004 02:09:25 PM, Jesse, Rich wrote:
Couldn't the declarations be put into a package? We've done this in
order
to maintain values for the life of the session.
Yes, they could, I didn't see it in this example.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: David Hau
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
Re: When does Oracle use 'Index Fast Scan'
An index fast full scan and an index full scan both need to access all the blocks of an index. The only difference between them is that the index_ffs accesses the blocks in the order of the blocks (and uses multiblock read), whereas the index_fs accesses the blocks in the order of the b tree index. In terms of # logical I/Os, they are exactly the same. OTOH, an index range scan by definition is a _range_ scan, and need to access only a subset of the blocks of an index. Because of this, it'll have a lower # logical I/Os than an index_ffs. Regards, Dave [EMAIL PROTECTED] wrote: ive found that index_ffs typically incur higher logical I/Os that index range scans. so its not just access speeds. From: David Hau [EMAIL PROTECTED] Date: 2004/01/27 Tue AM 11:54:26 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: When does Oracle use 'Index Fast Scan' This is where the access time of your disks (or SAN) makes a difference. If your disks have really fast access time, then a random-access pattern would not cause much performance degradation and so a range scan would not be slow at all, even though it's traversing the b-tree index structure. If you're only striping together disks with relatively slow access time (e.g. using a striped IDE disk array), then you have high throughput but not that fast an access time. In this case, fast full index scan would be much faster than an index range scan because the fast full scan reads the blocks sequentially and a sequential disk I/O requires only positioning the head once (assuming the disk is not fragmented). The rest of the time depends on the throughput. If you stripe together a large enough number of IDE disks, then your throughput is great but your access time is still the access time of a single IDE drive which is not that fast. This is assuming you need to do a physical I/O to obtain the blocks. Of course, if the blocks already reside in the buffer cache, then it's a different story. Regards, Dave [EMAIL PROTECTED] wrote: btw, in many cases range scan is faster than a fast full scan. Range scan recursively hits the nodes that are needed and skips the ones that are not. So it reads less blocks. So if you are looking for a 'range' or a specific value, range scan beats fast full scan most of the time. Less Logical and Physical I/Os. test it and hint your queries From: David Hau [EMAIL PROTECTED] Date: 2004/01/26 Mon PM 10:34:25 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: When does Oracle use 'Index Fast Scan' Correction: the Index Range Scan can be parallelized when it involves multiple partitions. - Dave David Hau wrote: I assume you're talking about the Fast Full Index Scan. This is used when the index contains all the columns necessary to answer the query. It's faster than a Full Table Scan because indexes are smaller than entire rows, so a Fast Full Index Scan will scan fewer blocks than a Full Table Scan. It's faster than an Index Range Scan firstly because Fast Full Index Scan scans the blocks in sequential order, whereas the Index Range Scan traverses the B-tree index structure in scanning the blocks, resulting in a random access I/O pattern which is slower. This is also why the Oracle documentation says that with a Fast Full Index Scan, the result is not sorted by the index key (because the result is not obtained by traversing the index structure.) Secondly, the better performance is also because the Fast Full Index Scan uses multiblock reads and is capable of parallel operation, whereas the Index Range Scan is capable of neither. Regards, Dave. [EMAIL PROTECTED] wrote: I have found that the vast majority of time that Oracle chooses this method, my statistics are stale and the query is sub-optimal. One time, Oracle changed from a 'range scan' to this type of scan with a FIRST_ROWS hint and this reduced performance. This is just a full scan of the index, one block at a time right? When would this ever be superior to a Fast Full Scan or a Range Scan? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California
Re: When does Oracle use 'Index Fast Scan'
If you look up Logical I/O in the Master Glossary of the Oracle docs, it's defined as: A block read which may or may not be satisfied from the buffer cache. So a logical I/O is always a *block* read. It does not take into acount whether you're doing a multiblock read or not. One reason this is so is because the CBO does not know whether the block is already in the buffer cache or not. If it's already in the cache, then multiblock read is not an issue anymore. The init parameter db_file_multiblock_read_count is what makes the CBO favor fast full index scan over a non-fast scan like full index scan or index range scan. The LIO itself does not take into consideration the aspect of multiblock read. Regards, Dave [EMAIL PROTECTED] wrote: i thought an index_fs only read 1 block per i/o? same with an index range scan because they are using random access? - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Tuesday, January 27, 2004 5:29 PM An index fast full scan and an index full scan both need to access all the blocks of an index. The only difference between them is that the index_ffs accesses the blocks in the order of the blocks (and uses multiblock read), whereas the index_fs accesses the blocks in the order of the b tree index. In terms of # logical I/Os, they are exactly the same. OTOH, an index range scan by definition is a _range_ scan, and need to access only a subset of the blocks of an index. Because of this, it'll have a lower # logical I/Os than an index_ffs. Regards, Dave [EMAIL PROTECTED] wrote: ive found that index_ffs typically incur higher logical I/Os that index range scans. so its not just access speeds. From: David Hau [EMAIL PROTECTED] Date: 2004/01/27 Tue AM 11:54:26 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: When does Oracle use 'Index Fast Scan' This is where the access time of your disks (or SAN) makes a difference. If your disks have really fast access time, then a random-access pattern would not cause much performance degradation and so a range scan would not be slow at all, even though it's traversing the b-tree index structure. If you're only striping together disks with relatively slow access time (e.g. using a striped IDE disk array), then you have high throughput but not that fast an access time. In this case, fast full index scan would be much faster than an index range scan because the fast full scan reads the blocks sequentially and a sequential disk I/O requires only positioning the head once (assuming the disk is not fragmented). The rest of the time depends on the throughput. If you stripe together a large enough number of IDE disks, then your throughput is great but your access time is still the access time of a single IDE drive which is not that fast. This is assuming you need to do a physical I/O to obtain the blocks. Of course, if the blocks already reside in the buffer cache, then it's a different story. Regards, Dave [EMAIL PROTECTED] wrote: btw, in many cases range scan is faster than a fast full scan. Range scan recursively hits the nodes that are needed and skips the ones that are not. So it reads less blocks. So if you are looking for a 'range' or a specific value, range scan beats fast full scan most of the time. Less Logical and Physical I/Os. test it and hint your queries From: David Hau [EMAIL PROTECTED] Date: 2004/01/26 Mon PM 10:34:25 EST To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Subject: Re: When does Oracle use 'Index Fast Scan' Correction: the Index Range Scan can be parallelized when it involves multiple partitions. - Dave David Hau wrote: I assume you're talking about the Fast Full Index Scan. This is used when the index contains all the columns necessary to answer the query. It's faster than a Full Table Scan because indexes are smaller than entire rows, so a Fast Full Index Scan will scan fewer blocks than a Full Table Scan. It's faster than an Index Range Scan firstly because Fast Full Index Scan scans the blocks in sequential order, whereas the Index Range Scan traverses the B-tree index structure in scanning the blocks, resulting in a random access I/O pattern which is slower. This is also why the Oracle documentation says that with a Fast Full Index Scan, the result is not sorted by the index key (because the result is not obtained by traversing the index structure.) Secondly, the better performance is also because the Fast Full Index Scan uses multiblock reads and is capable of parallel operation, whereas the Index Range Scan is capable of neither. Regards, Dave. [EMAIL PROTECTED] wrote: I have found that the vast majority of time that Oracle chooses this method, my statistics are stale and the query is sub-optimal. One time, Oracle changed from
Re: using oracle 817 driver against oracle 92 database
As long as you're not using any 9.2 feature, you should be fine. IIRC, according to Oracle's upgrade policy, the client and the server are compatible within one major version. Even if upgrading to the 92 client is not an emergency, you should at least upgrade the 817 client to the latest patch level 8174 (or the latest minor patch level if it's a Windows client, i.e. 8.1.7.4.10 or something like that; check metalink for the latest.). Regards, Dave [EMAIL PROTECTED] wrote: Hi all: I just learned that our application team is using oracle 817 driver to connect to a oracle 92 application (via das and via websphere). Is anyone aware of any big problems with that setup? I am going to recommend to upgrade to oracle9, but I don't think this is an emergency. Am I wrong? thanks Gene __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: When does Oracle use 'Index Fast Scan'
I assume you're talking about the Fast Full Index Scan. This is used when the index contains all the columns necessary to answer the query. It's faster than a Full Table Scan because indexes are smaller than entire rows, so a Fast Full Index Scan will scan fewer blocks than a Full Table Scan. It's faster than an Index Range Scan firstly because Fast Full Index Scan scans the blocks in sequential order, whereas the Index Range Scan traverses the B-tree index structure in scanning the blocks, resulting in a random access I/O pattern which is slower. This is also why the Oracle documentation says that with a Fast Full Index Scan, the result is not sorted by the index key (because the result is not obtained by traversing the index structure.) Secondly, the better performance is also because the Fast Full Index Scan uses multiblock reads and is capable of parallel operation, whereas the Index Range Scan is capable of neither. Regards, Dave. [EMAIL PROTECTED] wrote: I have found that the vast majority of time that Oracle chooses this method, my statistics are stale and the query is sub-optimal. One time, Oracle changed from a 'range scan' to this type of scan with a FIRST_ROWS hint and this reduced performance. This is just a full scan of the index, one block at a time right? When would this ever be superior to a Fast Full Scan or a Range Scan? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: When does Oracle use 'Index Fast Scan'
Correction: the Index Range Scan can be parallelized when it involves multiple partitions. - Dave David Hau wrote: I assume you're talking about the Fast Full Index Scan. This is used when the index contains all the columns necessary to answer the query. It's faster than a Full Table Scan because indexes are smaller than entire rows, so a Fast Full Index Scan will scan fewer blocks than a Full Table Scan. It's faster than an Index Range Scan firstly because Fast Full Index Scan scans the blocks in sequential order, whereas the Index Range Scan traverses the B-tree index structure in scanning the blocks, resulting in a random access I/O pattern which is slower. This is also why the Oracle documentation says that with a Fast Full Index Scan, the result is not sorted by the index key (because the result is not obtained by traversing the index structure.) Secondly, the better performance is also because the Fast Full Index Scan uses multiblock reads and is capable of parallel operation, whereas the Index Range Scan is capable of neither. Regards, Dave. [EMAIL PROTECTED] wrote: I have found that the vast majority of time that Oracle chooses this method, my statistics are stale and the query is sub-optimal. One time, Oracle changed from a 'range scan' to this type of scan with a FIRST_ROWS hint and this reduced performance. This is just a full scan of the index, one block at a time right? When would this ever be superior to a Fast Full Scan or a Range Scan? -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: sql question
Bear in mind though that the original query will only count rows where b.award_number is not null whereas this new query will count all rows in the result set. Regards, Dave [EMAIL PROTECTED] wrote: Can you change it to this query: SELECT count(1) FROM RF_BALANCE_T b, rf_security_by_dceid s WHERE (s.award_number = 'ALL') OR (b.award_number = s.award_number AND s.project_number = 'ALL') OR (b.award_number = s.award_number AND b.project_number= s.project_number AND s.task_number = 'ALL') OR (b.award_number = s.award_number AND b.project_number= s.project_number AND b.task_number = s.task_number) eric - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Monday, January 12, 2004 3:04 PM David - Can you post the EXPLAIN PLAN for both? Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Monday, January 12, 2004 1:14 PM To: Multiple recipients of list ORACLE-L Hi List, I have following sql that runs in 1 sec: SELECT b.* FROM RF_BALANCE_T b, rf_security_by_dceid s WHERE (s.award_number = 'ALL') OR (b.award_number = s.award_number AND s.project_number = 'ALL') OR (b.award_number = s.award_number AND b.project_number= s.project_number AND s.task_number = 'ALL') OR (b.award_number = s.award_number AND b.project_number= s.project_number AND b.task_number = s.task_number) However, when I try to count above query as following, it hangs. Does someone have any ideas? SELECT count(b.award_number) FROM RF_BALANCE_T b, rf_security_by_dceid s WHERE (s.award_number = 'ALL') OR (b.award_number = s.award_number AND s.project_number = 'ALL') OR (b.award_number = s.award_number AND b.project_number= s.project_number AND s.task_number = 'ALL') OR (b.award_number = s.award_number AND b.project_number= s.project_number AND b.task_number = s.task_number) _ High-speed users-be more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-uspage=byoa/premST=1 -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Boyd INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: SQL CASE Statement
In 8i, CASE is supported in SQL but not PL/SQL. In 9i, it's supported on both. Workaround is to use dynamic SQL (execute immediate), or upgrade to 9i. Regards, Dave [EMAIL PROTECTED] wrote: Hi All, Any clues on why does a CASE block does not work in an INSERT-APPEND-SELECT statement called in a sql block in an UNIX script? If I replace the case block with a decode function then it works Whereas in a sql command prompt, both DECODE and CASE yields results. TIA for all ur hints. Thanks, Rajesh -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: connection pooling from an application server to oracle
From 9i on, application servers can actually make use of the connection pooling and session pooling features within OCI instead of implementing their own. An interesting concept is how the 9i OCI API separates the notion of session pooling from connection pooling. You can have multiple session pools and multiple connection pools at the same time in an environment. A session pool is a pool of user handles. A connection pool is a pool of server handles. A session pool on top of a single physical connection means you can multiplex multiple sessions on a single connection by switching in and out of different transaction contexts. What's neater is having a session pool on top of a connection pool. You can multiplex say 10 sessions on top of 5 physical connections. Each time you obtain a session, you specify which session pool and which connection pool you want to use. Also, I believe that the client can store a pointer to a transaction context on the server side. This means you don't need to tie a physical connection to a transaction. You can use a different physical connection for each step of a transaction simply by passing it the pointer to the transaction context corresponding to that transaction. I think the JDBC driver has connection pooling also, but not session pooling. OCCI might have both. But I haven't checked. BTW, connection pooling and session pooling are new features in the 9i OCI. The 8i OCI does not have these features. Regards, Dave [EMAIL PROTECTED] wrote: Mladen, Probably, something is very wrong with application design. With iPlanet, it looks like this: Application invokes bean, pumpkin or servlet which has something to do with oracle. The app server pooling mechanism will allocate one of the already established dedicated server connections, which will perform the work. When the same user executes another vegetable (EJB or servlet), he or she may do so within a different dedicated server connection. We have a situation in which a single user utilizes several dedicated server connections within a single logical screen. Usually application server is smart enough (we use Weblogic) to reuse same physical connection if any number of calls comes from any different places once all the calls are a single transaction. I can imagin single call to allocate more than one connection if more than one transaction contexts required for this call (although, smartest app servers and the best databases can optimize even this transaction can be suspended and then resumed after another transaction commits), but it must be some very special need - it is not common what I'm saying. Single logical screen probably cannot use connections at all: screen means control is on users side means transaction should not be opened means no connection assigned . So, it's probably not an architecture's fault, it's design issue. Regards Vadim -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: connection pooling from an application server to oracle
I agree that the implementation of a connection pool is dependent on the app server, which for various reasons, might choose not to use the connection pool inherent in the programming interface, whether it's OCI or JDBC. One reason may be that the app server already has its own connection pool before 9i and the developers feel it's not worth the risk to change their implementation to use the OCI connection pool. Another reason may be that their app server has to work with both 8i and 9i servers and if they use a feature only present in the 9i client, it most likely will not work properly with an 8i server. - Dave [EMAIL PROTECTED] wrote: I didn't reply to Vadim because I'm not a developer and I have no idea how appservers work. You say that as of 9i application servers can use OCCI multiplexing. Isn't that dependendent on a particular app server? I was talking about iPlanet 6.5 because that is the last version that I have some experience (however painful) with. I was under the impression that pooling is implemented differently in WebSphere (IBM) or WebLogic (BEA). This is a question, not a statement. When it comes to beasts like application servers, my knowledge is extremely shaky. On 2003.12.15 19:54, David Hau wrote: From 9i on, application servers can actually make use of the connection pooling and session pooling features within OCI instead of implementing their own. An interesting concept is how the 9i OCI API separates the notion of session pooling from connection pooling. You can have multiple session pools and multiple connection pools at the same time in an environment. A session pool is a pool of user handles. A connection pool is a pool of server handles. A session pool on top of a single physical connection means you can multiplex multiple sessions on a single connection by switching in and out of different transaction contexts. What's neater is having a session pool on top of a connection pool. You can multiplex say 10 sessions on top of 5 physical connections. Each time you obtain a session, you specify which session pool and which connection pool you want to use. Also, I believe that the client can store a pointer to a transaction context on the server side. This means you don't need to tie a physical connection to a transaction. You can use a different physical connection for each step of a transaction simply by passing it the pointer to the transaction context corresponding to that transaction. I think the JDBC driver has connection pooling also, but not session pooling. OCCI might have both. But I haven't checked. BTW, connection pooling and session pooling are new features in the 9i OCI. The 8i OCI does not have these features. Regards, Dave [EMAIL PROTECTED] wrote: Mladen, Probably, something is very wrong with application design. With iPlanet, it looks like this: Application invokes bean, pumpkin or servlet which has something to do with oracle. The app server pooling mechanism will allocate one of the already established dedicated server connections, which will perform the work. When the same user executes another vegetable (EJB or servlet), he or she may do so within a different dedicated server connection. We have a situation in which a single user utilizes several dedicated server connections within a single logical screen. Usually application server is smart enough (we use Weblogic) to reuse same physical connection if any number of calls comes from any different places once all the calls are a single transaction. I can imagin single call to allocate more than one connection if more than one transaction contexts required for this call (although, smartest app servers and the best databases can optimize even this transaction can be suspended and then resumed after another transaction commits), but it must be some very special need - it is not common what I'm saying. Single logical screen probably cannot use connections at all: screen means control is on users side means transaction should not be opened means no connection assigned . So, it's probably not an architecture's fault, it's design issue. Regards Vadim -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http
Re: Oracle's jdbc driver
The method you need is: OracleDatabaseMetaData.getDriverVersion() Write a small Java program to call this method, or take a look at Metalink note 94091.1 or 73629.1 for sample code to get JDBC driver version. Regards, Dave [EMAIL PROTECTED] wrote: Hi All How can I findout what is the version of the jdbc driver installed with oracle client install. Thanks and Regards B S Pradhan -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: Fedora (pink hat)
I had installed 9.2 on Fedora and created a new DB. Everything has been working fine so far. oemapp console, sqlplus and dbca all work fine. Haven't tried other tools. As Joe mentioned, puschitz.com is the place to go for installation instructions, which include downloading a couple of patches from metalink. Rgds, Dave [EMAIL PROTECTED] wrote: Hi, I have attempted to install 9.2 on Fedora. If you follow the www.puschitz.com instructions for RHAS 3, it installs. I haven't created a new DB yet, but have mostly been looking at the OEM tools. Which, by the way, only partialy work. At least I haven't gotten them to fully work yet. The management packs seem to have issues. -- Joe Frohne Rawson Oaks Consulting, Remote Oracle Admins http://www.rawsonoaks.com [EMAIL PROTECTED] or [EMAIL PROTECTED] Oak Creek, WI, USA Has anyone actually installed Oracle on Fedora? I don't want to be the first one. Mladen Gogala Oracle DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: passing an array variable from a .Net middle tier to a databse
You can't use a PL/SQL table in ODP.NET. ODP.NET currently does not support object type or collection type: http://forums.oracle.com/forums/thread.jsp?forum=146thread=211399tstart=0trange=15 Your best bet would be to use array binding i.e. bind an array to the OracleParameter object and set the ArrayBindCount in the OracleCommand object: http://download-west.oracle.com/docs/html/A96160_01/features.htm#1049674 HTH, Dave [EMAIL PROTECTED] wrote: Im sure on the DB side this is the same for Java and C/C++ also. The OO guys pass us an array. When I write my code, I need to define a PL/SQL table that maps exactly to the array correct? Our middle tier is having problem doing bulk inserts since its doing one at a time and I believe it closes the session each time. I also think there is an auto-commit on. I cant help with that... However, I want to pass it to a pl/sql table with some other variables then dynamically insert it into the database from package. This should clear up the bottleneck. is this doable? I cannot touch the middle tier or OO stuff. Strictly the database. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: Share Data between PostgreSQL and Oracle
or use a Java stored procedure on Oracle, accessing pgsql via JDBC. [EMAIL PROTECTED] wrote: xml? -Original Message- Sent: Wednesday, October 22, 2003 12:04 PM To: Multiple recipients of list ORACLE-L Oracle external procedures, accessing PostgreSQL would do the trick without flat files. On 10/22/2003 12:14:24 PM, David Wagoner wrote: Anyone have experience doing this? I would like to hear your tips and experiences. Here's our situation. We have an Oracle DB on Sun Solaris 8 and a PostgreSQL DB on Linux (RH 7.3) that we need to share data between, specifically from PostgreSQL to Oracle. I want to experiment with Oracle's Generic Connectivity via ODBC connection. The advantage here seems to be DB-to-DB connection, ability to use Oracle SQL and tools, etc. Limitations might be network performance. An alternative is to produce flat files from PostgreSQL, FTP them to Oracle server, and SQL*Load them into Oracle. Not a real-time solution, but load performance is usually very good with SQL*Loader. Thoughts? Best regards, David B. Wagoner Database Administrator Arsenal Digital Solutions Web: http://www.arsenaldigital.com ...OLE_Obj... The contents of this e-mail message may be privileged and/or confidential. If you are not the intended recipient, any review, dissemination, copying, distribution or other use of the contents of this message or any attachment by you is strictly prohibited. If you receive this communication in error, please notify us immediately by return e-mail or by telephone (919-466-6700), and please delete this message and all attachments from your system. Thank you. Mladen Gogala Oracle DBA Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: SAME and separating disk and index tablespaces
, Application Performance Management, Veritas Corporation E-mail : [EMAIL PROTECTED] Phone: (650)-527-3180 Website: http://www.veritas.com __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Dave Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: vikas kawatra INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). _ MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
Re: SAME and separating disk and index tablespaces
list you want to be removed from). You may also send the HELP command for other information (like subscribing). = Gaja Krishna Vaidyanatha Principal Technical Product Manager, Application Performance Management, Veritas Corporation E-mail : [EMAIL PROTECTED] Phone: (650)-527-3180 Website: http://www.veritas.com __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Dave Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: David Hau INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
