RE: Urgent: Need Oradim.exe for version 8.1.6
Thanx Jared, I have got the file, multiple times :-) Thanx for taking care to zipping it and sending it again, as the .exe one was quarantined by the email server. Its working now. Regards Naveen > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2003 6:09 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: Urgent: Need Oradim.exe for version 8.1.6 > > > Crud! > > Sorry, replied twice to the list when I shouldn't have. > > D'oh! > > Jared > > > > > > "Naveen Nahata" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 06/11/2003 07:24 AM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L > <[EMAIL PROTECTED]> > cc: > Subject:Urgent: Need Oradim.exe for version 8.1.6 > > > I need the Oradim.exe for version 8.1.6 as its got corrupted. > > Can someone please zip it and send it to me? > > Regards > Naveen > > > -Original Message- > > From: Mark Richard [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 11, 2003 9:15 AM > > To: Multiple recipients of list ORACLE-L > > Subject: Re: sql query optimization > > > > > > > > Hi, > > > > From what you have said the cost of distinct and the function call > > shouldn't be a big deal. I did wonder if you can use > > to_number with an > > appropriate mask to avoid the function call but it's > probably not even > > worth bothering. > > > > Simplifying the connect by sub-query will hopefully provide > > the boost you > > need. The concatenated index relates to my uncertainty about > > how Oracle > > can use them for recursive SQL. I did a simple test - creating the > > following indexes: > > > > 1) Unique index on child > > 2) Non-unique index on parent > > 3) Unique index on parent, child > > 4) Unique index on child, parent > > > > The table only had a handful of rows but Oracle chose to use > > index 1 and > > index 3 for the query instead of index 2. On a table of > > significant volume > > (I used to work on very large recursive SQL statements at > one point) I > > would suggest testing the indexing combinations to see what > > Oracle likes - > > then remove the rest. Also, the requirements are different > if you are > > traversing the tree in both directions - you seem to only be > > going down the > > tree. > > > > Good luck. > > > > > > > > > > > > > > Guang Mei > > > > > > <[EMAIL PROTECTED]>To: > > Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > > > Sent by: cc: > > > > > > [EMAIL PROTECTED]Subject: Re: > > sql query optimization > > > > .com > > > > > > > > > > > > > > > > > > 11/06/2003 12:34 > > > > > > Please respond to > > > > > > ORACLE-L > > > > > > > > > > > > > > > > > > > > > > > > > > I just looked: > > > > [EMAIL PROTECTED]> select count(*) from arc where arctype in > > (299,300); > > > > COUNT(*) > > -- > > 56932 > > > > This is about 27% of the total rows, so I will test to move > > them into a > > new table tomorrow and this should help. I did test each part > > separatley > > and timed them and I found that the sub-query is probably the > > bottle-neck > > because > > "start ... connect by ..." requires walk the whole index to get all > > possible nodes > > (expensive). I can create this new table. > > > > > > > 2) Consider a concatenated index (perhaps termid, parenttermid or > > > parenttermid,termid - too early for my brain to remember > > without trying) > > > > > > > I don't know why concatenated index would help here, for > which part in > > where clause it would? > > > > > > > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>
Re: Urgent: Need Oradim.exe for version 8.1.6
Crud! Sorry, replied twice to the list when I shouldn't have. D'oh! Jared "Naveen Nahata" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/11/2003 07:24 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject:Urgent: Need Oradim.exe for version 8.1.6 I need the Oradim.exe for version 8.1.6 as its got corrupted. Can someone please zip it and send it to me? Regards Naveen > -Original Message- > From: Mark Richard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 11, 2003 9:15 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: sql query optimization > > > > Hi, > > From what you have said the cost of distinct and the function call > shouldn't be a big deal. I did wonder if you can use > to_number with an > appropriate mask to avoid the function call but it's probably not even > worth bothering. > > Simplifying the connect by sub-query will hopefully provide > the boost you > need. The concatenated index relates to my uncertainty about > how Oracle > can use them for recursive SQL. I did a simple test - creating the > following indexes: > > 1) Unique index on child > 2) Non-unique index on parent > 3) Unique index on parent, child > 4) Unique index on child, parent > > The table only had a handful of rows but Oracle chose to use > index 1 and > index 3 for the query instead of index 2. On a table of > significant volume > (I used to work on very large recursive SQL statements at one point) I > would suggest testing the indexing combinations to see what > Oracle likes - > then remove the rest. Also, the requirements are different if you are > traversing the tree in both directions - you seem to only be > going down the > tree. > > Good luck. > > > > > > > Guang Mei > > > <[EMAIL PROTECTED]>To: > Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > Sent by: cc: > > > [EMAIL PROTECTED]Subject: Re: > sql query optimization > > .com > > > > > > > > > 11/06/2003 12:34 > > > Please respond to > > > ORACLE-L > > > > > > > > > > > > > I just looked: > > [EMAIL PROTECTED]> select count(*) from arc where arctype in > (299,300); > > COUNT(*) > -- > 56932 > > This is about 27% of the total rows, so I will test to move > them into a > new table tomorrow and this should help. I did test each part > separatley > and timed them and I found that the sub-query is probably the > bottle-neck > because > "start ... connect by ..." requires walk the whole index to get all > possible nodes > (expensive). I can create this new table. > > > > 2) Consider a concatenated index (perhaps termid, parenttermid or > > parenttermid,termid - too early for my brain to remember > without trying) > > > > I don't know why concatenated index would help here, for which part in > where clause it would? > > > > << > >> >Privileged/Confidential information may be contained in > this message. > If you are not the addressee indicated in this message >(or responsible for delivery of the message to such person), > you may not copy or deliver this message to anyone. > In such case, you should destroy this message and kindly > notify the sender >by reply e-mail or by telephone on (61 3) 9612-6999. >Please advise immediately if you or your employer does not > consent to > Internet e-mail for messages of this kind. > Opinions, conclusions and other information in this message > that do not relate to the official business of > Transurban City Link Ltd > shall be understood as neither given nor endorsed by it. > <<<>>> > >> > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Mark Richard > 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). > DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defec
Re: Urgent: Need Oradim.exe for version 8.1.6
Oops, here it is again, zipped this time. I realized after sending the last one your email may filter out exe files. And then I realized I sent it to the list instead of you. Jared "Naveen Nahata" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/11/2003 07:24 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject:Urgent: Need Oradim.exe for version 8.1.6 I need the Oradim.exe for version 8.1.6 as its got corrupted. Can someone please zip it and send it to me? Regards Naveen > -Original Message- > From: Mark Richard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 11, 2003 9:15 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: sql query optimization > > > > Hi, > > From what you have said the cost of distinct and the function call > shouldn't be a big deal. I did wonder if you can use > to_number with an > appropriate mask to avoid the function call but it's probably not even > worth bothering. > > Simplifying the connect by sub-query will hopefully provide > the boost you > need. The concatenated index relates to my uncertainty about > how Oracle > can use them for recursive SQL. I did a simple test - creating the > following indexes: > > 1) Unique index on child > 2) Non-unique index on parent > 3) Unique index on parent, child > 4) Unique index on child, parent > > The table only had a handful of rows but Oracle chose to use > index 1 and > index 3 for the query instead of index 2. On a table of > significant volume > (I used to work on very large recursive SQL statements at one point) I > would suggest testing the indexing combinations to see what > Oracle likes - > then remove the rest. Also, the requirements are different if you are > traversing the tree in both directions - you seem to only be > going down the > tree. > > Good luck. > > > > > > > Guang Mei > > > <[EMAIL PROTECTED]>To: > Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > Sent by: cc: > > > [EMAIL PROTECTED]Subject: Re: > sql query optimization > > .com > > > > > > > > > 11/06/2003 12:34 > > > Please respond to > > > ORACLE-L > > > > > > > > > > > > > I just looked: > > [EMAIL PROTECTED]> select count(*) from arc where arctype in > (299,300); > > COUNT(*) > -- > 56932 > > This is about 27% of the total rows, so I will test to move > them into a > new table tomorrow and this should help. I did test each part > separatley > and timed them and I found that the sub-query is probably the > bottle-neck > because > "start ... connect by ..." requires walk the whole index to get all > possible nodes > (expensive). I can create this new table. > > > > 2) Consider a concatenated index (perhaps termid, parenttermid or > > parenttermid,termid - too early for my brain to remember > without trying) > > > > I don't know why concatenated index would help here, for which part in > where clause it would? > > > > << > >> >Privileged/Confidential information may be contained in > this message. > If you are not the addressee indicated in this message >(or responsible for delivery of the message to such person), > you may not copy or deliver this message to anyone. > In such case, you should destroy this message and kindly > notify the sender >by reply e-mail or by telephone on (61 3) 9612-6999. >Please advise immediately if you or your employer does not > consent to > Internet e-mail for messages of this kind. > Opinions, conclusions and other information in this message > that do not relate to the official business of > Transurban City Link Ltd > shall be understood as neither given nor endorsed by it. > <<<>>> > >> > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Mark Richard > 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). > DISCLAIMER: This message (including attachment if any
Re: Urgent: Need Oradim.exe for version 8.1.6
Here si oradim for 8.1..6.3 if you still need it. Jared "Naveen Nahata" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/11/2003 07:24 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject:Urgent: Need Oradim.exe for version 8.1.6 I need the Oradim.exe for version 8.1.6 as its got corrupted. Can someone please zip it and send it to me? Regards Naveen > -Original Message- > From: Mark Richard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 11, 2003 9:15 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: sql query optimization > > > > Hi, > > From what you have said the cost of distinct and the function call > shouldn't be a big deal. I did wonder if you can use > to_number with an > appropriate mask to avoid the function call but it's probably not even > worth bothering. > > Simplifying the connect by sub-query will hopefully provide > the boost you > need. The concatenated index relates to my uncertainty about > how Oracle > can use them for recursive SQL. I did a simple test - creating the > following indexes: > > 1) Unique index on child > 2) Non-unique index on parent > 3) Unique index on parent, child > 4) Unique index on child, parent > > The table only had a handful of rows but Oracle chose to use > index 1 and > index 3 for the query instead of index 2. On a table of > significant volume > (I used to work on very large recursive SQL statements at one point) I > would suggest testing the indexing combinations to see what > Oracle likes - > then remove the rest. Also, the requirements are different if you are > traversing the tree in both directions - you seem to only be > going down the > tree. > > Good luck. > > > > > > > Guang Mei > > > <[EMAIL PROTECTED]>To: > Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > Sent by: cc: > > > [EMAIL PROTECTED]Subject: Re: > sql query optimization > > .com > > > > > > > > > 11/06/2003 12:34 > > > Please respond to > > > ORACLE-L > > > > > > > > > > > > > I just looked: > > [EMAIL PROTECTED]> select count(*) from arc where arctype in > (299,300); > > COUNT(*) > -- > 56932 > > This is about 27% of the total rows, so I will test to move > them into a > new table tomorrow and this should help. I did test each part > separatley > and timed them and I found that the sub-query is probably the > bottle-neck > because > "start ... connect by ..." requires walk the whole index to get all > possible nodes > (expensive). I can create this new table. > > > > 2) Consider a concatenated index (perhaps termid, parenttermid or > > parenttermid,termid - too early for my brain to remember > without trying) > > > > I don't know why concatenated index would help here, for which part in > where clause it would? > > > > << > >> >Privileged/Confidential information may be contained in > this message. > If you are not the addressee indicated in this message >(or responsible for delivery of the message to such person), > you may not copy or deliver this message to anyone. > In such case, you should destroy this message and kindly > notify the sender >by reply e-mail or by telephone on (61 3) 9612-6999. >Please advise immediately if you or your employer does not > consent to > Internet e-mail for messages of this kind. > Opinions, conclusions and other information in this message > that do not relate to the official business of > Transurban City Link Ltd > shall be understood as neither given nor endorsed by it. > <<<>>> > >> > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Mark Richard > 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). > DISCLAIMER: This message (including attachment if any) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consul
RE: Urgent: Need Oradim.exe for version 8.1.6
O/S ? 32 bit or 64 bit?? John -Original Message- Sent: 11 June 2003 15:25 To: Multiple recipients of list ORACLE-L I need the Oradim.exe for version 8.1.6 as its got corrupted. Can someone please zip it and send it to me? Regards Naveen > -Original Message- > From: Mark Richard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 11, 2003 9:15 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: sql query optimization > > > > Hi, > > From what you have said the cost of distinct and the function call > shouldn't be a big deal. I did wonder if you can use > to_number with an > appropriate mask to avoid the function call but it's probably not even > worth bothering. > > Simplifying the connect by sub-query will hopefully provide > the boost you > need. The concatenated index relates to my uncertainty about > how Oracle > can use them for recursive SQL. I did a simple test - creating the > following indexes: > > 1) Unique index on child > 2) Non-unique index on parent > 3) Unique index on parent, child > 4) Unique index on child, parent > > The table only had a handful of rows but Oracle chose to use > index 1 and > index 3 for the query instead of index 2. On a table of > significant volume > (I used to work on very large recursive SQL statements at one point) I > would suggest testing the indexing combinations to see what > Oracle likes - > then remove the rest. Also, the requirements are different if you are > traversing the tree in both directions - you seem to only be > going down the > tree. > > Good luck. > > > > > > > Guang Mei > > > <[EMAIL PROTECTED]>To: > Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > Sent by: cc: > > > [EMAIL PROTECTED]Subject: Re: > sql query optimization > > .com > > > > > > > > > 11/06/2003 12:34 > > > Please respond to > > > ORACLE-L > > > > > > > > > > > > > I just looked: > > [EMAIL PROTECTED]> select count(*) from arc where arctype in > (299,300); > > COUNT(*) > -- > 56932 > > This is about 27% of the total rows, so I will test to move > them into a > new table tomorrow and this should help. I did test each part > separatley > and timed them and I found that the sub-query is probably the > bottle-neck > because > "start ... connect by ..." requires walk the whole index to get all > possible nodes > (expensive). I can create this new table. > > > > 2) Consider a concatenated index (perhaps termid, parenttermid or > > parenttermid,termid - too early for my brain to remember > without trying) > > > > I don't know why concatenated index would help here, for which part in > where clause it would? > > > > << > >> >Privileged/Confidential information may be contained in > this message. > If you are not the addressee indicated in this message >(or responsible for delivery of the message to such person), > you may not copy or deliver this message to anyone. > In such case, you should destroy this message and kindly > notify the sender >by reply e-mail or by telephone on (61 3) 9612-6999. >Please advise immediately if you or your employer does not > consent to > Internet e-mail for messages of this kind. > Opinions, conclusions and other information in this message > t
