Gurus, Sorry, forgot to mention one very important fact - this error doesn't occur always - sometimes (but rarely) it's succeeds as well.
Thanks, Charu -----Original Message----- Sent: Thursday, November 21, 2002 2:22 PM To: '[EMAIL PROTECTED]' (Distributed transaction) Gurus, Desperately need some ideas to solve this one. Following is the sequence of events as it happens: 1. Front-end application (VC++) queries from a view V. V fetches data from a remote database RD via a database link. 2. Front-end inserts a row in a local table LT. 3. The Insert trigger on this table queries view V to take a final stock. 4a. If conditions match, the trigger inserts in remote table RT on RD. NO PROBLEM in condition. 4b. If conditions don't match, the front-end application tries to insert another row in LT. The trigger starts again and tries to insert row in RT. At this point we SEEM to get the error. We can't get anybody to debug the front-end application. We tried setting SQL_TRACE TRUE, and the only thing made clear was that the trigger didn't go beyond trying to insert into RT. We tried replicating the whole scenario by executing each and every statement that the front-end fires through SQL*Plus as a script, and it doesn't give any error. I realize that I have given only a fraction of the whole information, but what is the best way to debug this situation? Are there any do's don'ts in distributed transactions which our code may not be following? Thanks in advance, Charu -----Original Message----- Waleed Sent: Wednesday, November 20, 2002 11:33 PM To: Multiple recipients of list ORACLE-L EMC has now hardware striping. The smallest stripe size is one track (1MB). Regards, Waleed -----Original Message----- Sent: Wednesday, November 20, 2002 5:54 PM To: Multiple recipients of list ORACLE-L A number of papers recommend a stripe size of 1 M (even for EMC) for volumes containing data files. I also have the following email from Eyal Aronoff of Quest dated Nov 2000. A number of the white papers are more recent. ============================================================ The reasons for a larger stripe size on a non-RAID 5 device are: 1) Sequential reads are faster if you can take advantege of the read ahead built into the disk caching 2) If a 64K read does not start on the first block of the stripe, two "spindled" are locked for the duration of the read However, lately we have been testing some EMC gear and it looks like EMC have optimized both of those for smaller strip size too. The bottom line - I no longer have an opinion one way or another. The undelying technology just changes too rapidly. Eyal ============================================================ Your opinions/comments as far as a "best" practice in setting stripe sizes would be greatly appreciated. Thanks, Ethan -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Post, Ethan 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.com -- Author: Khedr, Waleed 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 any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Charu Joshi 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).
