| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Problem with understanding Optimization methods.
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Bambi,=20
Yes it is expected behaviour, but only when it is guaranteed that no = rows will be missed because of unindexed null entries. I wanted to point out that RBO is too "dumb" to realize that even though = it ordered by column A which could be null, the column B in composite = index was not null, thus causing every row to be indexed and RBO didn't = use the index.
Tanel.
Tanel,=20
Wouldn't this be expected behaviour when both columns of the table = were indexed?
Bambi.
-----Original Message-----
From: Tanel Poder [mailto:tanel.poder.003_at_mail.ee]
Sent: Wednesday, January 07, 2004 3:30 PM
To: Multiple recipients of list ORACLE-L
Subject: Fw: Problem with understanding Optimization methods.
(I suspect my last post didn't go through - sorry for long repost = again)
No, but there's an order by clause on COL3 and apparently an index = as well, so RBO thinks it's cheaper to read keys+rows in order using = index full scan than reading all rows and sorting them. Note that = optimizer needs to know that all table's rows have corresponding entries = in indexes well, in order to order full table using an index (for the = reason that indexes do not index rows where all relevant column values = are NULLs). An example follows:
SQL> create table t (a number, b number);
Table created.
SQL> create index i on t(a);
Index created.
SQL> select * from t order by a;
Execution Plan
0 SELECT STATEMENT Optimizer=3DCHOOSE
1 0 SORT (ORDER BY)
2 1 TABLE ACCESS (FULL) OF 'T'
SQL> alter table t modify a not null;
Table altered.
SQL> select * from t order by a;
Execution Plan
0 SELECT STATEMENT Optimizer=3DCHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T'
2 1 INDEX (FULL SCAN) OF 'I' (NON-UNIQUE)
When I added a not null constraint, RBO knows, that every table row = will be in the index and can use it for sorting.
SQL> alter table t modify a null;
Column A can be null again.
Table altered.
SQL> drop index i;
Index dropped.
Lets create a composite index on both columns.
SQL> create index i on t(a,b);
Index created.
SQL> select * from t order by a;
Execution Plan
0 SELECT STATEMENT Optimizer=3DCHOOSE
1 0 SORT (ORDER BY)
2 1 TABLE ACCESS (FULL) OF 'T'
And set one of the columns not null (now all entries will be = indexed, since at least one field of index entries will have a value)
SQL> alter table t modify b not null;
Table altered.
SQL> select * from t order by a;
Execution Plan
0 SELECT STATEMENT Optimizer=3DCHOOSE
1 0 SORT (ORDER BY)
2 1 TABLE ACCESS (FULL) OF 'T'
Hm, no change?
SQL> analyze table t compute statistics;
Table analyzed.
SQL> select * from t order by a;
Execution Plan
0 SELECT STATEMENT Optimizer=3DCHOOSE (Cost=3D2 Card=3D1 = Bytes=3D26)
1 0 INDEX (FULL SCAN) OF 'I' (NON-UNIQUE) (Cost=3D1 Card=3D1 = Bytes
=3D26)
Rule based optimizer was too dumb to take into account a NOT NULL = constraint of another field of a composite index. So, here's one reason = for upgrading to CBO :)
Tanel.
> Actually from what is given I'd expect the optimizer to select a =
full table scan in anycase, there's no where clause.
>=20
>=20
>=20
>=20
> likely that you haven't configured your CBO properly. Here is =
something you can try:
>=20
>=20
>=20
>=20
>=20
> then the table one and will be much more likely to select full =
index scan over the full table scan.
> When you're really, really bored, you can read Practical Oracle 8i =
- Building Efficient Databases,
> it has a few pages about the parameters above. Read the Gospel of =
Jonathan and enjoy.
>=20
>=20
>=20
> > SELECT STATEMENT Optimizer Mode=3DCHOOSE
> > SORT ORDER BY
> > TABLE ACCESS FULL TABLENAME -- Very slow =
and takes
> > hours!
> >=20
> > When adding the hint /*+RULE*/ for example I get
> > SELECT STATEMENT Optimizer Mode=3DHint:RULE
> > TABLE ACCESS BY INDEX ROWID TABLENAME
> > INDEX FULL SCAN =
TABLE_INDEX --
> > Much faster!!!
> >=20
> > Have I given enough info that anyone can explain why the CHOOSE =
mode insists
> > on doing a TABLE ACCESS FULL?
> > Is there anything I can do to improve performance? Please =
remember that this
> > query comes from a Data Warehouse tool and hence does not appear =
to accept
> > hints.
> >=20
> > Any help will be much appreciated!
> > Denham
> > =20
> > --=20
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --=20
> > Author: Denham Eva
> > INET: EVAD_at_TFMC.co.za
> >=20
> > 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: ListGuru_at_fatcity.com (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).
> >=20
>=20
> San Diego, California -- Mailing list and web hosting =
services
> =
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (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).
> --=20
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --=20
> Author: Goulet, Dick
> INET: DGoulet_at_vicr.com
>=20
> 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: ListGuru_at_fatcity.com (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).
>
------=_NextPart_000_2405_01C3D5EF.2714A3F0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; =charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#e0e0e0> <DIV><FONT face=3DArial size=3D2>Bambi, </FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Yes it is expected behaviour, but only =when it is=20
column B in composite index was not null, thus causing every row to =
be=20
indexed and RBO didn't use the index.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Tanel.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20
size=3D2>-----Original Message-----<BR><B>From:</B> Tanel Poder=20 [mailto:tanel.poder.003_at_mail.ee]<BR><B>Sent:</B> Wednesday, January = 07, 2004=20
3:30 PM<BR><B>To:</B> Multiple recipients of list=20 ORACLE-L<BR><B>Subject:</B> Fw: Problem with understanding = Optimization=20
methods.<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(I suspect my last post didn't go =
through -=20
sorry for long repost again)</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>No, but there's an order by clause = on COL3 and=20
apparently an index as well, so RBO thinks it's cheaper to read = keys+rows in=20
order using index full scan than reading all rows and sorting them. = Note=20
that optimizer needs to know that all table's rows have = corresponding=20
entries in indexes well, in order to order full table using an index = (for=20
the reason that indexes do not index rows where all relevant column = values=20
are NULLs). An example follows:</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3D"Courier New" size=3D2>SQL> <STRONG>create = table t (a=20
number, b number);</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Table created.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> <STRONG>create =
index i on=20
t(a);</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Index created.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> select * from t =
order by=20
a;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Execution=20
=
Plan<BR>----------------------------------------------------------<BR>&nb=sp; =20
0 SELECT STATEMENT=20
Optimizer=3DCHOOSE<BR> 1 0 =
SORT=20
(ORDER BY)<BR> 2 =
1 =20
TABLE ACCESS (FULL) OF 'T'</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> <STRONG>alter table =
t modify a=20
not null;</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Table altered.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> select * from t =
order by=20
a;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Execution=20
=
Plan<BR>----------------------------------------------------------<BR>&nb=sp; =20
0 SELECT STATEMENT=20
Optimizer=3DCHOOSE<BR> 1 0 =
TABLE=20
ACCESS (BY INDEX ROWID) OF 'T'<BR> 2 =20
1 INDEX (FULL SCAN) OF 'I' =
(NON-UNIQUE)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><EM>When I added a not null =
constraint, RBO=20
knows, that every table row will be in the index and can use it for=20
sorting.</EM></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> alter table t =
modify a=20
null;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><EM>Column A can be null=20
again.</EM></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Table altered.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> drop index =
i;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Index dropped.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><EM>Lets create a composite =
index on both=20
columns.</EM></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> <STRONG>create =
index i on=20
t(a,b);</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Index created.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> select * from t =
order by=20
a;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Execution=20
=
Plan<BR>----------------------------------------------------------<BR>&nb=sp; =20
0 SELECT STATEMENT=20
Optimizer=3DCHOOSE<BR> 1 0 =
SORT=20
(ORDER BY)<BR> 2 =
1 =20
TABLE ACCESS (FULL) OF 'T'</FONT></DIV> <DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><EM>And set one of the columns not = null (now=20
all entries will be indexed, since at least one field of index = entries will=20
have a value)</EM></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> <STRONG>alter table =
t modify b=20
not null;</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Table altered.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> select * from t =
order by=20
a;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Execution=20
=
Plan<BR>----------------------------------------------------------<BR>&nb=sp; =20
0 SELECT STATEMENT=20
Optimizer=3DCHOOSE<BR> 1 0 =
SORT=20
(ORDER BY)<BR> 2 =
1 =20
TABLE ACCESS (FULL) OF 'T'</FONT></DIV> <DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><EM>Hm, no = change?</EM></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV> <DIV><FONT face=3D"Courier New" size=3D2>SQL> <STRONG>analyze = table t compute=20
statistics;</STRONG></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Table =
analyzed.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>SQL> select * from t =
order by=20
a;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Execution=20
=
Plan<BR>----------------------------------------------------------<BR>&nb=sp; =20
0 SELECT STATEMENT Optimizer=3DCHOOSE = (Cost=3D2=20
Card=3D1 Bytes=3D26)<BR> 1 = 0 INDEX=20
(FULL SCAN) OF 'I' (NON-UNIQUE) (Cost=3D1 Card=3D1=20
Bytes<BR> =20
=3D26)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><EM>Rule based optimizer was too =
dumb to take=20
into account a NOT NULL constraint of another field of a = composite=20
index. So, here's one reason for upgrading to CBO = :)</EM></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Tanel.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>----- Original Message ----- =
</FONT>
<DIV><FONT face=3DArial size=3D2>From: "Goulet, Dick" <</FONT><A=20 href=3D"mailto:DGoulet_at_vicr.com"><FONT face=3DArial=20 size=3D2>DGoulet_at_vicr.com</FONT></A><FONT face=3DArial = size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: "Multiple recipients of list =
ORACLE-L"=20
<</FONT><A href=3D"mailto:ORACLE-L_at_fatcity.com"><FONT =
face=3DArial=20
size=3D2>ORACLE-L_at_fatcity.com</FONT></A><FONT face=3DArial=20
size=3D2>></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Sent: Wednesday, January 07, 2004 =
4:04=20
PM</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Subject: RE: Problem with =
understanding=20
Optimization methods.</FONT></DIV></DIV> <DIV><FONT face=3DArial><BR><FONT size=3D2></FONT></FONT></DIV><FONT = face=3DArial=20
size=3D2>> Actually from what is given I'd expect the optimizer = to select a=20
full table scan in anycase, there's no where clause.<BR>> = <BR>> Dick=20
Goulet<BR>> Senior Oracle DBA<BR>> Oracle Certified 8i = DBA<BR>>=20
<BR>> -----Original Message-----<BR>> Sent: Wednesday, January = 07,=20
2004 1:09 AM<BR>> To: Multiple recipients of list = ORACLE-L<BR>>=20
<BR>> <BR>> You can find out by employing the event = 10053, lev=20
8. Looking from afar, however, it seems more<BR>> likely = that you=20
haven't configured your CBO properly. Here is something you can = try:<BR>>=20
<BR>> Execute the following commands:<BR>> <BR>> alter = session set=20
optimizer_index_caching=3D40; <BR>> alter session set=20 optimizer_index_cost_adj=3D25;<BR>> <BR>> <BR>> <BR>> = After=20
that, retry the query. If I'm correct, optimizer will now know = that=20
index I/O is much cheaper<BR>> then the table one and will be = much more=20
likely to select full index scan over the full table scan.<BR>> = When=20
you're really, really bored, you can read Practical Oracle 8i - = Building=20
Efficient Databases,<BR>> it has a few pages about the parameters =
above. Read the Gospel of Jonathan and enjoy.<BR>> <BR>> =
<BR>> <BR>> On 2004.01.07 00:29, Denham Eva wrote:<BR>> = > Hello=20
Listers,<BR>> > <BR>> > A normal sql query from a data = warehouse=20
tool called Sagent. <BR>> > SELECT COL1, COL2, COL3<BR>> = > FROM=20
TABLE<BR>> > ORDER BY 3;<BR>> > <BR>> > The table = has=20
approximately 2 mil records.<BR>> > table has 22 = indexes.<BR>> >=20
<BR>> > The database is set up optimizer CHOOSE.<BR>> > = I run=20
DBMS_Stats.Gather_Schema_Stats('SchemaName') regularly.<BR>> > = OS is=20
Win2k<BR>> > ORACLE 81741<BR>> > <BR>> > OK, when = doing a=20
explain plan on the above sql, I get the following...<BR>> > =
SELECT=20
STATEMENT Optimizer Mode=3DCHOOSE<BR>> =
> SORT=20
ORDER BY<BR>> =
> =20
TABLE ACCESS=20
=
FULL &nb=
sp; =20
TABLENAME -- Very slow and takes<BR>> > = hours!<BR>>=20
> <BR>> > When adding the hint /*+RULE*/ for example I = get<BR>>=20
> SELECT STATEMENT Optimizer Mode=3DHint:RULE<BR>>=20
> TABLE ACCESS BY INDEX=20
=
ROWID &n=
bsp; =20
TABLENAME<BR>> > =
INDEX FULL=20
=
SCAN &nb=
sp; &nbs=
p; =20
TABLE_INDEX --<BR>> > Much faster!!!<BR>> > = <BR>> >=20
Have I given enough info that anyone can explain why the CHOOSE mode =
insists<BR>> > on doing a TABLE ACCESS FULL?<BR>> > Is = there=20
anything I can do to improve performance? Please remember that = this<BR>>=20
> query comes from a Data Warehouse tool and hence does not = appear to=20
accept<BR>> > hints.<BR>> > <BR>> > Any help will = be much=20
appreciated!<BR>> > Denham<BR>> > <BR>> > -- =
<BR>> > Please see the official ORACLE-L FAQ: </FONT><A=20 href=3D"http://www.orafaq.net"><FONT face=3DArial=20 size=3D2>http://www.orafaq.net</FONT></A><BR><FONT face=3DArial = size=3D2>> >=20
</FONT><A href=3D"http://www.fatcity.com"><FONT face=3DArial=20 size=3D2>http://www.fatcity.com</FONT></A><BR><FONT face=3DArial = size=3D2>> San=20
Diego, California -- = Mailing list=20
and web hosting services<BR>>=20
=
---------------------------------------------------------------------<BR>=>=20
To REMOVE yourself from this mailing list, send an E-Mail = message<BR>>=20
to: </FONT><A href=3D"mailto:ListGuru_at_fatcity.com"><FONT = face=3DArial=20
size=3D2>ListGuru_at_fatcity.com</FONT></A><FONT face=3DArial size=3D2> = (note EXACT=20
spelling of 'ListGuru') and in<BR>> the message BODY, include a = line=20
containing: UNSUB ORACLE-L<BR>> (or the name of mailing list you = want to=20
be removed from). You may<BR>> also send the HELP command = for other=20
information (like subscribing).<BR>> -- <BR>> Please see the = official=20
ORACLE-L FAQ: </FONT><A href=3D"http://www.orafaq.net"><FONT = face=3DArial=20
size=3D2>http://www.orafaq.net</FONT></A><BR><FONT face=3DArial = size=3D2>> --=20
<BR>> Author: Goulet, Dick<BR>> INET: </FONT><A=20 href=3D"mailto:DGoulet_at_vicr.com"><FONT face=3DArial=20 size=3D2>DGoulet_at_vicr.com</FONT></A><BR><FONT face=3DArial = size=3D2>> <BR>>=20
Fat City Network Services -- 858-538-5051 = </FONT><A=20
href=3D"http://www.fatcity.com"><FONT face=3DArial=20 size=3D2>http://www.fatcity.com</FONT></A><BR><FONT face=3DArial = size=3D2>> San=20
Diego, California -- = Mailing list=20
and web hosting services<BR>>=20
=
---------------------------------------------------------------------<BR>=>=20
To REMOVE yourself from this mailing list, send an E-Mail = message<BR>>=20
to: </FONT><A href=3D"mailto:ListGuru_at_fatcity.com"><FONT = face=3DArial=20
size=3D2>ListGuru_at_fatcity.com</FONT></A><FONT face=3DArial size=3D2> = (note EXACT=20
spelling of 'ListGuru') and in<BR>> the message BODY, include a = line=20
containing: UNSUB ORACLE-L<BR>> (or the name of mailing list you = want to=20
be removed from). You may<BR>> also send the HELP command = for other=20
information (like subscribing).<BR>>=20 </FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_2405_01C3D5EF.2714A3F0--
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder INET: tanel.poder.003_at_mail.ee 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: ListGuru_at_fatcity.com (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).Received on Thu Jan 08 2004 - 05:54:25 CST
 |
 |