Transfer log and archivefile hang.

[Adoer73]

Currently I'm trying to test synchronize between Primary and Standby Server.
I'm using Windows 2000 and Oracle 10g. I have Installed Dbvisit Standby, configure, create standby database.

But when I type command : Dbvisit Standby [Oracle_SID] on Primary Server, the process will come up, but never end, it;s look like hang, I think it should close the window form after log and archive file are transfered to standby server.

Here's the log process :

C:\>DBVISIT IBS

"================================================= ============
Dbvisit Standby Database Technology (5.2.24.3817) (pid 3120)
dbvisit.exe started on dbone: Tue Apr 6 10:44:00 2010
================================================== ===========

Performing Oracle Checkpoint.
Waiting 3 seconds for checkpoint completion...
Checking Dbvisit configurational differences between dbone and dbtwo...
No Dbvisit configurational differences found between dbone and dbtwo.

Log file(s) for IBS will be transferred from dbone to dbtwo...
Transferring IBST61861947879305.ARC.gz to host dbtwo:IBST61861947879305.ARC.gz
201004061044 - 1 Log transfer to dbtwo for IBS completed.
Last sequence was 79305.

Starting Dbvisit Archive Management Module (AMM)...
Dbvisit Archive Management Module (AMM)
(Number to keep: 10) (Days to keep: 7) (Diskspace full threshold: 80%)
Archive log dir: D:\oracle\oradata\IBS\archive
Total number of archive files : 3213

[Stop here and not close form window]...

Help me please, ASAP.

[Arjen Visser]

Hi,
Thanks for asking the question.

Once Dbvisit Standby has transferred the log files to the standby database, Dbvisit Standby will start managing the archive log files to see whether they can be removed or not. This is the Dbvisit Standby Archive Management Module (AMM).

Since you have 3213 archive log files, Dbvisit Standby has a lot of files to process. For each file Dbvisit Standby will check its repository to see if this file has been transferred or not to the standby database. Only if Dbvisit Standby has a transferred the archive log file, will it be allowed to remove the archive log file. Because this is a new installation, most of the archive log files will not be found in the Dbvisit Standby repository, so Dbvisit Standby will not be able to remove the archive log file.
This is why the process is taking so long, but it is not hanging.

We suggest that you change the default setting initially so that Dbvisit Standby no longer checks if the archive file exists in the repository before removing it.

Please update the Dbvisit Standby Database Configuration (DDC) file called dbv_IBS.env and set:
AMM_CHECK_TRANSFERRED=No
(The DDC file can be edited with any editor).

Then run Dbvisit Standby again on the primary server.
Once Dbvisit Standby has been running successfully for a few days and the archive log files are at a manageable size, you can turn this back to AMM_CHECK_TRANSFERRED=Yes

[Adoer73]

Originally Posted by Arjen Visser

Hi,
Thanks for asking the question.

Once Dbvisit Standby has transferred the log files to the standby database, Dbvisit Standby will start managing the archive log files to see whether they can be removed or not. This is the Dbvisit Standby Archive Management Module (AMM).

Since you have 3213 archive log files, Dbvisit Standby has a lot of files to process. For each file Dbvisit Standby will check its repository to see if this file has been transferred or not to the standby database. Only if Dbvisit Standby has a transferred the archive log file, will it be allowed to remove the archive log file. Because this is a new installation, most of the archive log files will not be found in the Dbvisit Standby repository, so Dbvisit Standby will not be able to remove the archive log file.
This is why the process is taking so long, but it is not hanging.

We suggest that you change the default setting initially so that Dbvisit Standby no longer checks if the archive file exists in the repository before removing it.

Please update the Dbvisit Standby Database Configuration (DDC) file called dbv_IBS.env and set:
AMM_CHECK_TRANSFERRED=No
(The DDC file can be edited with any editor).

Then run Dbvisit Standby again on the primary server.
Once Dbvisit Standby has been running successfully for a few days and the archive log files are at a manageable size, you can turn this back to AMM_CHECK_TRANSFERRED=Yes

Dear Arjen,

Thank's for the reply.

Yes, I agree with you that the process is not hanging.
But my real problem next is why Dbvisit Standby read and verify all archive files not only from current Instant (IBS) but also check and read from other Database Instant, in total is 3213, for additional info that I have three Database Instant on Primary Database Server, these are IBS, INTEGRA and WEB.
I use only IBS Instant for this testing Primary and standby database. It caused by Dbvisit Standby Demo version has a limitation only for single Instant.

On Dbvisit Standby Trace file (TEMP directory), we can see that Dbvisit Standby, read and verify all archive not just only from IBS Instant.

My Question is, How can I set the parameter in order to Dbvisit Standby only for IBS Instant, remember the trace files generated by Dbvisit Standby is quite large and takes a long time. For the info these database instants are under 'D:\Oracle\Oradata' folder.

Here's the log process that shown on screen, after I Uninstall Dbvisit Standby and recreate New Primary and Standby Database.

C:\Program Files\Dbvisit>dbvisit -R ibs
================================================== ===========
Dbvisit Standby Database Technology (5.2.24.3817) (pid 3812)
dbvisit.exe started on dbone: Wed Apr 7 13:56:10 2010
================================================== ===========

Performing Oracle Checkpoint.
Waiting 3 seconds for checkpoint completion...
Resynch option given. Dbvisit installation will be copied to dbtwo...
Transferring dbv_functions.exe to host dbtwo:dbv_functions.exe
Transferring dbvisit.exe to host dbtwo:dbvisit.exe
Transferring dbvisit_setup.exe to host dbtwo:dbvisit_setup.exe
Transferring dbv_oraStartStop.exe to host dbtwo:dbv_oraStartStop.exe
Transferring dbv_ibs.env to host dbtwo:dbv_ibs.env
Transferring dbv_ORACLE_SID.env to host dbtwo:dbv_ORACLE_SID.env
Contacting Standby Database IBS on dbtwo...
Last standby sequence obtained (79326).

Log file(s) for IBS will be transferred from dbone to dbtwo...
Transferring IBST61861947879326.ARC.gz to host dbtwo:IBST61861947879326.ARC.gz
Transferring IBST61861947879327.ARC.gz to host dbtwo:IBST61861947879327.ARC.gz
201004071356 - 2 Log transfers to dbtwo for IBS completed.
Last sequence was 79327.

Starting Dbvisit Archive Management Module (AMM)...
Dbvisit Archive Management Module (AMM)
(Number to keep: 0) (Days to keep: 7) (Diskspace full threshold: 80%)
Archive log dir: D:\oracle\oradata\IBS\archive
Total number of archive files : 170
Number of files deleted : 0
Current Disk percent full : 68%
Archive log dir: d:\oracle\oradata --> Suspect caused take so long and the trace file is large. How can I set this parameter?
Total number of archive files : 1600
Number of files deleted : 0
Current Disk percent full : 68%

================================================== ===========
dbvisit.exe ended on dbone: Wed Apr 7 14:01:17 2010
================================================== ===========

Thank in Advance
Adoer

[Arjen Visser]

Hi Adoer,
Thanks for your reply.

>It caused by Dbvisit Standby Demo version has a limitation only for single Instant.
There is no limitation with the Dbvisit Standby demo version. You can run Dbvisit Standby for as many instances as you like on the same server.

>Archive log dir: d:\oracle\oradata --> Suspect caused take so long and the trace file is large. How can I set this parameter?
Dbvisit Standby picks up the archive log destination from the log_archive_dest_n parameter in Oracle. So this may mean that d:\oracle\oradata is one of your log archive destinations, which is generally considered not a good idea.

To check your log archive destinations please run:
SQL>show parameter log_archive_dest

Your log archive destination should always be specific to your database, and should not be a generic location common to multiple databases.

So D:\oracle\oraarch\IBS\ is a good log archive destination, but D:\oracle\oraarch\ or d:\oracle\oradata is not.
Also it is not recommended to mix Oracle datafiles with Oracle archive log files in the same location. You could accidentally delete one of your Oracle datafiles instead of an Oracle archive log file.

Solutions:

1. Change your database so d:\oracle\oradata is no longer one of your archive log destinations, OR
2. Edit your DDC file and change AMM_PROCESS_MULTIPLE_ARCH_DEST=No. Dbvisit Standby will then only process the first log archive destination which in your case is D:\oracle\oraarch\IBS\.

Regards, Arjen

[Adoer73]

After check and keep checking, I have found the setting parameter to discard Dbvisit Standby checking all archives in Primary Server (If we have multi Database Instat).

The setting is AMM_PROCESS_MULTIPLE_ARCH_DEST, this must be set to No, default is Yes

You just edit file dbv_[Your ORACLE_SID].env, then search text AMM_PROCESS_MULTIPLE_ARCH_DEST, change the value into No.

Ok, solve my problem, thank you so much Arjen for your help. and next if I met a problem, I'll ask you again..

Thank You.

Adoer

CASE CLOSED

[oneonesip]

Originally Posted by Adoer73

After check and keep checking, I have found the setting parameter to discard Dbvisit Standby checking all archives in Primary Server (If we have multi Database Instat).

The setting is AMM_PROCESS_MULTIPLE_ARCH_DEST, jasa seo this must be set to No, default is Yes

You just edit file dbv_[Your ORACLE_SID].env, rumah dijual then search text AMM_PROCESS_MULTIPLE_ARCH_DEST, change the value into No.

Ok, solve my problem, thank you so much Arjen for your help. and next if I met a problem, I'll ask you again..

Thank You.

Adoer

CASE CLOSED

Gread @Adoer, it work perfectly