 | |
#31
 
| |||
| |||
|
Re: Streams advice -
05-23-2008
, 12:41 PM
|
DA Morgan says... Geoff Muldoon wrote: Frank van Bortel says... Geoff Muldoon wrote: We are particularly looking at Asynchronous Change Data Capture because it "can be configured to have minimal performance impact on the source database", so I presume you refer to overheads at the staging database and overall server resource levels, rather than within the source databases. Maybe overheads of the subscriber databases too? No - source. Hopefully, things have improved with 10G; 9.2.0.4 was simply a disaster. Performance within the source? Thought that the only real additional overhead there would be the requirement to bump to supplemental rather than standard logging. Does the log mining process affect performance within the source database process? Log Miner is very resource intensive. Don't be surprised if it eats a substantial percentage of your server's capabilities. Thanks for the heads up on that. Might look for our prototype at running the Streams staging instance on separate hardware to isolate resource contention from the OLTP source systems. Do Redo Transport Services chew much resources on the source systems or, if significant, is that mainly in the staging area as well? I'm assuming that Log Miner runs in the model we're considering (Asynchronous Autolog Mode) on the staging server post log transportation, rather than on the source servers. TIA Geoff M |
Miner is doing a large amount of work reading log files, analyzing their
content, and reconstructing the transactions.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
#32
| |||
| |||
|
|
DA Morgan says... Geoff Muldoon wrote: Frank van Bortel says... Geoff Muldoon wrote: We are particularly looking at Asynchronous Change Data Capture because it "can be configured to have minimal performance impact on the source database", so I presume you refer to overheads at the staging database and overall server resource levels, rather than within the source databases. Maybe overheads of the subscriber databases too? No - source. Hopefully, things have improved with 10G; 9.2.0.4 was simply a disaster. Performance within the source? Thought that the only real additional overhead there would be the requirement to bump to supplemental rather than standard logging. Does the log mining process affect performance within the source database process? Log Miner is very resource intensive. Don't be surprised if it eats a substantial percentage of your server's capabilities. Thanks for the heads up on that. Might look for our prototype at running the Streams staging instance on separate hardware to isolate resource contention from the OLTP source systems. Do Redo Transport Services chew much resources on the source systems or, if significant, is that mainly in the staging area as well? I'm assuming that Log Miner runs in the model we're considering (Asynchronous Autolog Mode) on the staging server post log transportation, rather than on the source servers. TIA Geoff M |
Miner is doing a large amount of work reading log files, analyzing their
content, and reconstructing the transactions.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
#33
| |||
| |||
|
|
DA Morgan says... Geoff Muldoon wrote: Frank van Bortel says... Geoff Muldoon wrote: We are particularly looking at Asynchronous Change Data Capture because it "can be configured to have minimal performance impact on the source database", so I presume you refer to overheads at the staging database and overall server resource levels, rather than within the source databases. Maybe overheads of the subscriber databases too? No - source. Hopefully, things have improved with 10G; 9.2.0.4 was simply a disaster. Performance within the source? Thought that the only real additional overhead there would be the requirement to bump to supplemental rather than standard logging. Does the log mining process affect performance within the source database process? Log Miner is very resource intensive. Don't be surprised if it eats a substantial percentage of your server's capabilities. Thanks for the heads up on that. Might look for our prototype at running the Streams staging instance on separate hardware to isolate resource contention from the OLTP source systems. Do Redo Transport Services chew much resources on the source systems or, if significant, is that mainly in the staging area as well? I'm assuming that Log Miner runs in the model we're considering (Asynchronous Autolog Mode) on the staging server post log transportation, rather than on the source servers. TIA Geoff M |
Miner is doing a large amount of work reading log files, analyzing their
content, and reconstructing the transactions.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
 |
« 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.