Get a free Dbvisit 30 day evaluation version.

Dbvisit Knowledge Base

Frequently Asked Dbvisit Technical Support Questions

Please contact

if your question has not been answered.

There is no issue with running both the hot backup and Dbvisit at the same time. There will be more logs generated during the backup but this is normal Oracle behaviour. So you do not have to disable Dbvisit during the backup time.

When I look at the alert log for the standby databases, I see the following message frequently:
Media Recovery Log /u01/oradata/standbyarchdest/arch_1_97.arc
ORA-00279 signalled during: ALTER DATABASE RECOVER LOGFILE /u01/oradata/st..

The ORA-279 is normal and expected behaviour. It is the message generated by Oracle to indicate that recovery of the standby database is taking place.

When creating a physical standby from a hot backup of the primary, is it necessary to backup the online redo log files on the primary?

No, when doing a hot backup you do not need to backup the redo logs as they could be in an inconsistent state. When creating a standby (from hot or cold), you do not need to have redo logs. The standby database can be created without redo logs.

The standby database is maintained as an exact copy of the production database, doesn't this mean the standby database may be a little stale because any current redo log file will not be copied across until it is rolled over?

Tthe standby database will always be a little behind the primary database. This is acceptable for most companies because the cost associated with ensuring there is no transactional loss is extremely high. With Dbvisit you can control the maximum time that your standby should be behind the primary database. For example, if the maximum time you want the standby database to be behind the primary is 5 minutes, then you schedule Dbvisit every 5 minutes. Dbvisit forces a log switch so that the current redo log is closed and copied over to the standby (Data Guard uses a similar method). So if your production system goes down and you activate the standby database, the maximum time that your standby database will be behind is 5 minutes. Oracle guarantees transactional integrity so your standby database will always have complete transactions (or no transactions).

Why does Dbvisit not run as a daemon (or a service on Windows)? What we have found for our application is that the site's IT people will often reboot a server and then not log back in. If our system was not configured as a service (or daemon), then it would not be restarted. So how does Dbvisit handle the situation whereby the standby server may be restarted and then not logged in?

Dbvisit does not run as a daemon but as an executable. This allows you to have more control over when the updates (redo logs) are transferred. For example if you wanted to have a snapshot of the database before a batch transaction begins (for rollback purposes), you can schedule Dbvisit as the first step in your batch processing.
Dbvisit has to be scheduled using a scheduler tool. For Windows the Windows Task Scheduling tool can be used (on Unix and Linux cron can be used). The Windows Task Scheduling tool allows you to schedule Dbvisit in the background so that no one needs to be logged on. So if the server was rebooted, the schedule would automatically start again even though no one has logged on.

How do we change the Dbvisit Oracle password?

You can change the password for the Dbvisit Oracle user using the standard Oracle command "alter user dbvisit identified by new_password";

You will then need to update the Dbvisit database configuration (DDC) file and change the password in that file. This is a text file and can be edited with any editor. The password variable is called DBPASSWD. This only needs to be done on the primary server. The DDC file will be located in your Dbvisit directory. It will start with the letters "dbv_", then the name of the database and end with the suffix .env. For example if your database is called PROD1, then the DDC file will be called: dbv_PROD1.env.

Dbvisit will synchronise the DDC file to the standby server (default). If SYNCH_DBVISIT_INSTALL=N is set in the DDC then Dbvisit will not synchronise automatically. You will have to synchronise manually with the command:
dbvisit -c database_name

Does changing the O/S Dbvisit user password cause any issues?

There are no issues with changing the O/S users password. This will not affect Dbvisit or SSH. Nothing needs to be done in Dbvisit to affect the changed O/S password.
If you are running Windows and updating the O/S users password, then you will have to supply the new password to the Bitvise WinSSHD cache.
Please see Resolution 2 - Password cache not set on how to set this.

Dbvisit has a command (dbvisit -r sequence# dbname) to start sending logs from a particular sequence# to the standby. Is there any command to start applying from a particular log sequence on the standby?

You do not have any control over applying a particular log sequence on the standby. This is because if a log file is already applied, you cannot apply it again. Similarly you cannot skip log files. For example if the last log sequence applied to the standby is 78, then you cannot apply 80. Oracle will only let you apply log 79. You also cannot apply 78 again, or any other log file previously applied. This is a requirement of Oracle standby database. Oracle needs to apply the changes in the correct order, and you cannot apply the same change twice otherwise the standby will not reflect production. Dbvisit cannot change this.

What is the Dbvisit Archive Management Module and how is it scheduled?

When you configure the Dbvisit Archive Management Module, it is automatically run as part of Dbvisit. The function of the Dbvisit Archive Management Module is to manage the space taken up by the archives log files on both primary and standby servers. It makes sure there is enough space in the archive log directory (on both primary and standby) so that Dbvisit can send and receive the archive log files. The Archive Management Module will start alerting if the archive log directory space runs out, and can delete old archive log files to clean up space automatically to ensure continued operation.

We are using the Dbvisit Archive Management Module. If I want to change the threshold percentage from 5% to some other value, can I directly edit the Dbvisit database configuration (DDC) file? Is there something else that needs to be done?

Yes, the Dbvisit database configuration (DDC)file can be directly edited (on the primary server ONLY), making it really easy to change the configuration. Nothing else needs to be done. The configuration file(s) will be automatically copied to the standby server(s). Any of the variables in the configuration file(s) can be changed at any time.

On the standby server Dbvisit will ALWAYS uncompress the log files first and then apply the log files. The LEAVE_COMPRESS_DEST variables determines what happens AFTER the log files have been uncompressed and applied to the standby database.
LEAVE_COMPRESS_DEST = No -> Means leave the log files in the uncompressed state AFTER they have been applied.
LEAVE_COMPRESS_DEST = Yes -> Means compress the log files again AFTER they have been applied.
We would suggest that you set LEAVE_COMPRESS_DEST = Yes, because this will save space. You only want to set this to N if you are backing up your log files on the standby and your backup software does not recognise compressed files.

Can the standby database be brought up automatically in the event of a disaster?

We think it might be not be desirable to bring up (activating) the standby automatically if it detects that the primary is no longer reachable. There could just be a temporary network issue. Activating the Standby Database is only part of the process of switching to the DR site in the event of a disaster. This is best done manually. Activating the standby database is done through a simple command. Please see the Dbvisit user manual for more details.

Dbvisit errors with return code 1547. What does this mean?

Return code 1547 indicates the following Oracle message:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below....
This is normal behaviour according to Oracle, more archive logs need to be applied. Please run Dbvisit again until the error clears.

How much is the archive log file compressed (in percentage) before transferring to DR site?

Dbvisit uses industry proven compression methods to compress the archive log file before transferring to the DR site. The compression method that Dbvisit will use depends on what compression method is installed on your server. This can be compress or gzip, etc. The Dbvisit internal compression method uses the zlib compression method.
It is very difficult to estimate in percentage how much an archive log file will be compressed. This really depends on the data contained within the archive log file. So each archive log file may be compressed differently in terms of percentages. Here is an example. These are 2 archive log files from the same database:

Archive log file 1)
-rw-r----- 1 oracle dba 27136 Nov 1 15:53 arch_1_1776.log (uncompressed)
-rw-r----- 1 oracle dba 7889 Nov 3 08:27 arch_1_1776.log.gz (compressed)

Archive log file 2)
-rw-r----- 1 oracle dba 75776 Nov 3 08:27 arch_1_1782.log (uncompressed)
-rw-r----- 1 oracle dba 13778 Nov 1 17:09 arch_1_1782.log.gz (compressed)

Archive log file 1 is compressed:
(1-(7889/27136))*100= 70%
and archive log 2 is compressed:
(1-(13778/75776))*100 = 81%

Our experience tells us that it is normal to get between 70%-80% compression, sometimes more. To determine how much compression you will get try compressing some of your archive log files using compress or gzip and seeing how much compression you are getting.
To use the internal Dbvisit compression utility use the command:
dbv_functions -g file_name
to compress a file and the command:
dbv_functions -u file_name
to uncompress a file. See dbv_functions -h for more help.