RE: Export/Import with Physical Standby

From: D'Hooge Freek <>
Date: Fri, 2 Oct 2009 08:22:28 +0200
Message-ID: <>


I don't know what the normal redo generation is on your database or which transport mechanisme (lgwr async, lgwr sync or arch) you are using (and what your bandwidth / latency is on your replication network), but maybe it could be better to stop the redo sending (setting the log_archive_dest_state_n to deferred) while you are doing this operation to not slow down the primary. Afterwards you could backup the archivelogs into a compressed backupset and send it in bulk to the remote site. There you can restore and register them.


Freek D'Hooge
Oracle Database Administrator
tel. +32 (0)3 451 23 82

From: [] On Behalf Of David Barbour [] Sent: 02 October 2009 03:46
To: Allen, Brandon
Cc: Oracle-L Freelists
Subject: Re: Export/Import with Physical Standby

Lots of these:

You cannot move a table containing a LONG or LONG RAW column. (

I could export only the tables with long/long raw, but the bulk of the data is in tables with longs, so I don't gain that much in terms of time/simplicity.

Idea ... Good. Application ... Bad

However, I just have a bothersome feeling I'm missing something with my original approach.

On Thu, Oct 1, 2009 at 5:55 PM, Allen, Brandon <> wrote:

For more info:

Note that the ONLINE option is only for IOTs so DML will be blocked on regular tables, but I think you can still query from it during the move. Also, you’ll need to rebuild the indexes and gather stats afterwards. If you want to move it without interrupting DML, you can use online table redefinition:

nderstood as neither given nor endorsed by it.

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.-- Received on Fri Oct 02 2009 - 01:22:28 CDT

Original text of this message