Yes I believe you can do that. The SQL Apply used to maintain the logical standby doesn't require that all the tables be in the same tablespace as the primary like a physical standby. I'm not sure how the SQL Apply and the online reorg will play together however. It's very likely that all this activity on the logical standby will cause it to slow do to such a degree that the apply service will fall way behind. I think it would be best to suspend the apply service (ALTER DATABASE STOP LOGICAL STANDBY APPLY), do the reorg then restart the apply service (ALTER DATABASE START LOGICAL STANDBY APPLY). Have them both going at the same time could be interesting. Read up on the DATABASE GUARD setting. Be prepared to test this a few times. Ric Van Dyke Hotsos Enterprises Cell 248-705-0624 ----------------------- Hotsos Symposium March 4-8, 2007. Be there. ________________________________ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of qihua wu Sent: Tuesday, June 27, 2006 9:50 PM To: oracle-l@xxxxxxxxxxxxx Subject: Is it possible to reorganize tables for logical standby while maintain the synchronization? Our production database is of version 9.2 but still using DMT because it is upgraded from 8174. And we want to move the table to a LMT tablespace, althougth we can use some oracle package to convert DMT to LMT, but it's not perfect as TOM pointed. We can reorg these tables while the database is online, but the performance will be adversely effected. So is it possible to create a logical standy based on the production database, and then reorg the logical standby, after the reorg is done, then switch the role of the standby to primary database? As far as I know, the logical standy use sql appying instead of redo applying, so the transaction should be able to applied to logical standby while the reorg is under going. ________________________________ Sneak preview the all-new Yahoo.com <http://us.rd.yahoo.com/evt=40762/*http:/www.yahoo.com/preview> . It's not radically different. Just radically better.