http://www.rittmanmead.com/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/ Delivered Intelligence Wed, 17 Mar 2010 13:47:41 -0400 http://wordpress.org/?v=2.8.4 hourly 1 http://www.rittmanmead.com/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/comment-page-1/#comment-626 Rittman Mead Consulting » OWB11g, DML Error Logging and Data Rules Thu, 31 Jan 2008 17:02:19 +0000 http://www.rittmanmead.com/wp2/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/#comment-626 [...] wrote about DML Error Logging in a blog post last year and in this article for Oracle Magazine. One of the drawbacks in the 10gR2 implementation of DML [...] [...] wrote about DML Error Logging in a blog post last year and in this article for Oracle Magazine. One of the drawbacks in the 10gR2 implementation of DML [...]

]]> http://www.rittmanmead.com/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/comment-page-1/#comment-625 David Aldridge Tue, 06 Dec 2005 22:04:00 +0000 http://www.rittmanmead.com/wp2/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/#comment-625 These reverse engineering articles are pretty tricky stuff, i find. I didn't realise how much work and thought they require before I started on them myself. Good job Mark: have you had a look through trace files for the differences between the scenarios? I always find them illuminating. These reverse engineering articles are pretty tricky stuff, i find. I didn’t realise how much work and thought they require before I started on them myself.
Good job Mark: have you had a look through trace files for the differences between the scenarios? I always find them illuminating.

]]> http://www.rittmanmead.com/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/comment-page-1/#comment-624 Mark Mon, 05 Dec 2005 21:44:00 +0000 http://www.rittmanmead.com/wp2/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/#comment-624 Hi Jaromir Good to hear from you! Thanks for the heads up on the number of exception rows issue - I kind of expected that this might be an issue, thanks for the test case. I don't know why the comments were rejected - they all got through and I uploaded one of them this morning. I've got an issue with the software used to run my site, this probably sounds like it playing up again. Thanks for persevering though. all the best Mark Hi Jaromir
Good to hear from you!
Thanks for the heads up on the number of exception rows issue – I kind of expected that this might be an issue, thanks for the test case.
I don’t know why the comments were rejected – they all got through and I uploaded one of them this morning. I’ve got an issue with the software used to run my site, this probably sounds like it playing up again. Thanks for persevering though.
all the best
Mark

]]> http://www.rittmanmead.com/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/comment-page-1/#comment-623 Jaromir D.B. Nemec Sun, 04 Dec 2005 22:10:00 +0000 http://www.rittmanmead.com/wp2/2005/12/04/performance-issues-with-dml-error-logging-and-conventional-path-inserts/#comment-623 Hi Mark, nice to see you on such low level of BI:) A small addendum: a care should be taken if the number of exceptional rows is not very low, i.e. if a non trivial number of rows is written in the err$ table. See test case below comparing the LOG ERRORS feature with a self implemented check on a 200k rows table with 100k exceptions. (Note the difference in recursive calls - one per exception row - and db block gets statistics; in addition to redo size). Yes, I know exceptions *should* be rare, but this could be a negative feedback, you have a really bad data and you get a really slow running job. Regard, Jaromir -- table src has 200k rows; the half of then is not valid and is written in the err$ table -- process high number of exceptions is relatively expensive Hi Mark,
nice to see you on such low level of BI:)
A small addendum: a care should be taken if the number of exceptional rows is not very low, i.e. if a non trivial number of rows is written in the err$ table. See test case below comparing the LOG ERRORS feature with a self implemented check on a 200k rows table with 100k exceptions. (Note the difference in recursive calls – one per exception row – and db block gets statistics; in addition to redo size).
Yes, I know exceptions *should* be rare, but this could be a negative feedback, you have a really bad data and you get a really slow running job.
Regard,
Jaromir
– table src has 200k rows; the half of then is not valid and is written in the err$ table
– process high number of exceptions is relatively expensive

]]>