I am trying to create a standby data guard using Active Duplication of database.
I run this on a primary:
RMAN> connect target sys/password@DB1; RMAN> connect auxiliary sys/password@DB2; RMAN> duplicate target database for standby from active database 2> dorecover 3> spfile 4> set "db_unique_name"="ProdDB" 5> set "fal_client"="DB2" 6> set "fal_server"="DB1" 7> set "standby_file_management"="AUTO" 8> set "log_archive_config"="DG_CONFIG=(DB1,DB3)" 9> set "log_archive_dest_2"="service=DB1 LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=DB1" 10> nofilenamecheck;
Everything processes fine, however, the auxiliary database is very remote, the network connection is poor, and the database to be duplicated is massive. So it takes about 15-20 days to transfer the whole database. However, the network drops about once every 48 hours or so. It only lasts a few minutes, but it's enough that it causes the DUPLICATE command to error out. What I have been doing is starting the whole process anew every time.
Is there any way to restart a DUPLICATE DATABASE so that it picks up from where it left off instead of having to restart every time? DB version is 11r2.
Duplicate should just pick up from where it left off.
I've just tested this and duplicate works as it should and picks up where it left off.
However my test database is small and the issue you have might be due to the size of your database and the time it's taking to do the duplicate. It also might be the fact that by the time you run duplicate from active database again, the primary database has moved on so it can't just pick up from where it left off and has to start again.
You might be better off taking a backup to tape/disk and doing the duplicate from that backup. If you always use the same backup pieces for your restore then duplicate should pick up from where it left off. You can then recover the database using the archivelogs although you will need all the archivelogs from when the backup was taken.
It's no ideal as you have a large database AND a slow network, but you can only try what you try. On a separate note, assuming you run maximum performance you might might find that network latency issues means your standby runs far behind your primary. I think with your setup maximum availability and max protection are non-starters.
Hope that makes sense.
Because you duplicate from active database and not from an rman backup the process will start all over again.
If you can ship a disk backup to the remote location it should be possible to build the standby in a shorter period of time.
You will need all redo generated from the moment the backup started on the standby as well but this can be copied in batches and after a disconnect it can be restarted.