 | |
Oracle Auto Commit during transaction.
comp.databases.oracle.misc comp.databases.oracle.misc
 |
| | Thread Tools | Display Modes |
#21
 
| |||
| |||
|
Re: Oracle Auto Commit during transaction. -
03-17-2008
, 07:39 AM
|
I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. |
EXPLAIN PLAN can give you estimates on how much of a resource load
this update will be, therefore I would use it BEFORE running the
update to see where your problems might lie and what you need to do to
fix them.
Your two offerings may not be the ONLY places this update could fail.
David Fitzjarrell
#22
| |||
| |||
|
|
I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. |
is your undo, and how much are you using? What errors are you
seeing? How exactly are you updating? Mark and David both have valid
points, we need a lot more information even to convince us that undo
is your issue. If you are only doing thousands, I suspect you would
have concurrency issues if you are seeing problems. But you might be
doing the fetch across commits mistake if you are getting ORA-1555.
There are proper ways to commit every x records, but they require more
work than most people will put out, and when it comes down to it, it
is basically splitting up the logical unit of work into pieces.
jg
--
@home.com is bogus.
http://www.popsci.com/how-it-works/a...s-how-it-works
#23
| |||
| |||
|
|
I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. |
is your undo, and how much are you using? What errors are you
seeing? How exactly are you updating? Mark and David both have valid
points, we need a lot more information even to convince us that undo
is your issue. If you are only doing thousands, I suspect you would
have concurrency issues if you are seeing problems. But you might be
doing the fetch across commits mistake if you are getting ORA-1555.
There are proper ways to commit every x records, but they require more
work than most people will put out, and when it comes down to it, it
is basically splitting up the logical unit of work into pieces.
jg
--
@home.com is bogus.
http://www.popsci.com/how-it-works/a...s-how-it-works
#24
| |||
| |||
|
|
I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. |
is your undo, and how much are you using? What errors are you
seeing? How exactly are you updating? Mark and David both have valid
points, we need a lot more information even to convince us that undo
is your issue. If you are only doing thousands, I suspect you would
have concurrency issues if you are seeing problems. But you might be
doing the fetch across commits mistake if you are getting ORA-1555.
There are proper ways to commit every x records, but they require more
work than most people will put out, and when it comes down to it, it
is basically splitting up the logical unit of work into pieces.
jg
--
@home.com is bogus.
http://www.popsci.com/how-it-works/a...s-how-it-works
#25
| |||
| |||
|
|
I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. |
is your undo, and how much are you using? What errors are you
seeing? How exactly are you updating? Mark and David both have valid
points, we need a lot more information even to convince us that undo
is your issue. If you are only doing thousands, I suspect you would
have concurrency issues if you are seeing problems. But you might be
doing the fetch across commits mistake if you are getting ORA-1555.
There are proper ways to commit every x records, but they require more
work than most people will put out, and when it comes down to it, it
is basically splitting up the logical unit of work into pieces.
jg
--
@home.com is bogus.
http://www.popsci.com/how-it-works/a...s-how-it-works
#26
| |||
| |||
|
|
On Mar 16, 7:47*pm, PowerOne <salazar.wi... (AT) gmail (DOT) com> wrote: I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. But you said thousands. *That's not generally very massive. *How big is your undo, and how much are you using? *What errors are you seeing? *How exactly are you updating? *Mark and David both have valid points, we need a lot more information even to convince us that undo is your issue. *If you are only doing thousands, I suspect you would have concurrency issues if you are seeing problems. *But you might be doing the fetch across commits mistake if you are getting ORA-1555. There are proper ways to commit every x records, but they require more work than most people will put out, and when it comes down to it, it is basically splitting up the logical unit of work into pieces. jg -- @home.com is bogus.http://www.popsci.com/how-it-works/a...ci-presents-ho... |
application one transaction may be several units of work. A logical
unit of work is all the object changes that need to either all happen
together or not happen at all. Multiple units of work can be grouped
together and submitted as a single transaction or you can perform each
unit as a transaction. From an application point of view performing
the task as multiple transactions each of which is a complete logical
unit of work may be a requirement for scalability.
IMHO -- Mark D Powell --
#27
| |||
| |||
|
|
On Mar 16, 7:47*pm, PowerOne <salazar.wi... (AT) gmail (DOT) com> wrote: I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. But you said thousands. *That's not generally very massive. *How big is your undo, and how much are you using? *What errors are you seeing? *How exactly are you updating? *Mark and David both have valid points, we need a lot more information even to convince us that undo is your issue. *If you are only doing thousands, I suspect you would have concurrency issues if you are seeing problems. *But you might be doing the fetch across commits mistake if you are getting ORA-1555. There are proper ways to commit every x records, but they require more work than most people will put out, and when it comes down to it, it is basically splitting up the logical unit of work into pieces. jg -- @home.com is bogus.http://www.popsci.com/how-it-works/a...ci-presents-ho... |
application one transaction may be several units of work. A logical
unit of work is all the object changes that need to either all happen
together or not happen at all. Multiple units of work can be grouped
together and submitted as a single transaction or you can perform each
unit as a transaction. From an application point of view performing
the task as multiple transactions each of which is a complete logical
unit of work may be a requirement for scalability.
IMHO -- Mark D Powell --
#28
| |||
| |||
|
|
On Mar 16, 7:47*pm, PowerOne <salazar.wi... (AT) gmail (DOT) com> wrote: I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. But you said thousands. *That's not generally very massive. *How big is your undo, and how much are you using? *What errors are you seeing? *How exactly are you updating? *Mark and David both have valid points, we need a lot more information even to convince us that undo is your issue. *If you are only doing thousands, I suspect you would have concurrency issues if you are seeing problems. *But you might be doing the fetch across commits mistake if you are getting ORA-1555. There are proper ways to commit every x records, but they require more work than most people will put out, and when it comes down to it, it is basically splitting up the logical unit of work into pieces. jg -- @home.com is bogus.http://www.popsci.com/how-it-works/a...ci-presents-ho... |
application one transaction may be several units of work. A logical
unit of work is all the object changes that need to either all happen
together or not happen at all. Multiple units of work can be grouped
together and submitted as a single transaction or you can perform each
unit as a transaction. From an application point of view performing
the task as multiple transactions each of which is a complete logical
unit of work may be a requirement for scalability.
IMHO -- Mark D Powell --
#29
| |||
| |||
|
|
On Mar 16, 7:47*pm, PowerOne <salazar.wi... (AT) gmail (DOT) com> wrote: I need a massive update. So the only way to avoid error and the update is to increase the UNDO tablespace size or update one by one record. Thank you. But you said thousands. *That's not generally very massive. *How big is your undo, and how much are you using? *What errors are you seeing? *How exactly are you updating? *Mark and David both have valid points, we need a lot more information even to convince us that undo is your issue. *If you are only doing thousands, I suspect you would have concurrency issues if you are seeing problems. *But you might be doing the fetch across commits mistake if you are getting ORA-1555. There are proper ways to commit every x records, but they require more work than most people will put out, and when it comes down to it, it is basically splitting up the logical unit of work into pieces. jg -- @home.com is bogus.http://www.popsci.com/how-it-works/a...ci-presents-ho... |
application one transaction may be several units of work. A logical
unit of work is all the object changes that need to either all happen
together or not happen at all. Multiple units of work can be grouped
together and submitted as a single transaction or you can perform each
unit as a transaction. From an application point of view performing
the task as multiple transactions each of which is a complete logical
unit of work may be a requirement for scalability.
IMHO -- Mark D Powell --
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.