Copies a database log file to another location, either on a one-off basis, or at regular intervals. There is no user interaction whatever, except possibly via the -ALERT command line option. All this program's command line options can be specified as settings in the [LOGCOPY] section of DP4.INI if you prefer.
| Command Tail | Description |
|---|---|
|
−ALERT command |
This option is only used if a non-zero value is specified for -INTERVAL, in which case it must be specified. command will be executed if the copy operation fails consecutively more than the number of times specified for the −ALLOW_FAILURES option. For example you might run a simple QAB program to alert the user that there is a problem with copying the log file, or you might generate an e-mail message to alert a techinal support team. LOGCOPY will execute this command line without adding any parameters to it, so you should include any parameters that may be needed, such as the name of the machine and database in the value given for command, which should therefore usually be given in quotes. If you wish to add information such as date and time to the command line then invoke a batch file to do this. |
|
−ALLOW_FAILURES n |
This option is only used if a non-zero value is specified for -INTERVAL, in which case it specifies the number of times the copy operation is allowed to fail before the command line given in the −ALERT option is eexecuted. If no value is specified for this option then the value is 2, which means that if the copying option fails continually that the "alert" command will be run on every third failure. |
|
−DB database_name |
Specifies the name of the database whose log file is to be copied. This option must be specified. |
|
−FROM_SERVER server_name |
Specifies the DP4 name of the server containing the database whose log file is to be copied. If not specified the default server for the installation is used. This option is only respected when DP4 is loaded in the "named connection" configuration. |
|
−INTERVAL n |
If this option is not specified, or is explicitly set to 0, then LOGCOPY will attempt to copy the log file once, and will then exit. The exit code will be 0 if the copy succeeded and 1 otherwise. If a non-zero value is specified for this option then LOGCOPY will attempt to copy the log file every n seconds, except that if the database timestamp is unchanged since the last successful copy (during the current LOGCOPY session), the copy operation will be skipped. |
|
−TO_PATH path_name |
Specifies the location on the destination server to which the database log file should be copied. This option must be specified. This might be a second hard drive, a network drive or a device such as a flash drive (USB stick). Note, that if a network drive is used, LOGCOPY must be run in an appropriate user account and not as part of the DP4 service. |
|
−TO_SERVER server_name |
Specifies the DP4 name of the server to which the log file is to be copied. If not specified the default server for the installation is used. This option is only respected when DP4 is loaded in the "named connection" configuration. |
LOGCOPY is intended to be used in combination with DYNABACK -COPY to provide additional data security in the event of a hard drive failure. Typically you will configure your system to run DYNABACK -COPY on a nightly basis. When the backup succeeds you will copy the database to a separate location, probably the same location as you use for storing the transaction logs copied by LOGCOPY. Then during the day you would copy the transaction log at regular intervals, for example every 10 minutes, to ensure that even in the event of a hard drive failure, you will lose very little data. For additional security you should choose to keep the regular transaction log on a separate hard drive from the data file for the database. The copy of the transaction log created by LOGCOPY is then a third line of defence against data loss which would be needed if the hard drive containing the data file, and the hard drive containing the regular transaction log both fail.
If you use LOGCOPY in the suggested manner, and are copying to a "solid state" device, which typically has the characteristic that it can only be written to a finite number of times, then you should choose the frequency of the copying to give the best compromise between data security and maximising the life time of the device. Copying too frequently, say every 30 seconds, will impact performance of DP4, and reduce the life time of the device.
LOGCOPY has been written because some customers were choosing to keep the transaction log on such devices. However, this is unwise, at least on Windows based computers, because the operating system is prone to reporting that the device has been removed when it has not. In addition the transaction log file is flushed very frequently, and this will shorten the life time of the device, and is typically quite slow compared with flushing a file on a regular hard drive.
LOGCOPY copies the log file alternately as dbname.lb1 and dbname.lb2. If the log file is successfully copied the previous copy of the log file will be erased. Therefore the location where the log file is to be copied must have space for at least two copies of the largest anticipated transaction log. Note that while the naming scheme is similar to that followed by dynaback there is no logical connection with it: it is almost certain that you will sometimes have a backup using "b1" file extensions, and a transaction log using the "lb2" file extension, or vice versa
There is no automated method of restoring the log files created by LOGCOPY. Typically, in the event of needing to recover a database after a hard drive failure, you will simply copy the various b1 or b2 database backup files to the corresponding "live" database filename (cb1 → dci, db1 → dat, ib1 → ind, pb1 → ptr), and the lb1 or lb2 to the log filename. To apply the log file use the −LOGONLY option of DBRESTOR