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 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
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 Consulting Private Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or
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) is confidential and may be privileged. Before opening attachments please check them for viruses and defects. MindTree Consulting Private Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this
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 defects. MindTree Consulting Private Limited (MindTree) will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any
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? 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
