In some circumstances, it may not be practical to create text back-up files every day using either the back-up facilities built in to HansaWorld Enterprise or specialist back-up software. If the database is very large and/or 24-hour access is required, it may not be convenient to slow the speed of operation or to prevent users logging in altogether while back-up files are created. In this situation you can use the database duplication feature to create copies of the database file (the “HANSA.HDB” file) automatically.
Remember that you will no longer be able to use an old “HANSA.HDB” file if you have updated the version of your HansaWorld Enterprise application.
Therefore, while database duplication can play an important role in your back-up routine, you must still create a text back-up when you are about to update to a new version, and if you want to create an archive copy of your database that you want to be able to read in the future. Updating is described below on page 122. You can of course use a script to move the duplicate database to another machine, rename it “HANSA.HDB”, start the command line server application and create a text back-up. To create a true back-up, the script should also move the other contents of the folder containing your HansaWorld Enterprise application, especially the “Attach” folder.
If you are using journaling (described below on page 107), you must do so in combination with the database duplication feature.
The database duplication feature will create a copy of your database and store it in the folder containing your HansaWorld Enterprise application. This process will result in the following files being created—
i. While the first copy is being created, the file will be named
iv. When the second copy is complete, the file will be renamed
“HANSA.HDB.COPY”. The previous “HANSA.HDB.COPY” will be renamed “HANSA.HDB.OLD”. If there already is a
“HANSA.HDB.OLD”, it will be deleted.
There will therefore be a maximum of two entire copies and one partial copy in the folder at any one time. To be safe, make sure there is always enough disk space for three copies of the database. If there is insufficient disk space to make a copy, a notification mail will be sent to the Postmaster’s Mailbox.
The Postmaster is specified in the Mail and Conference Settings setting in the E-mail and Conferences module.
Follow these steps to configure the database duplication feature —
1. Select ‘Technics’ using the [Module] button in the Master Control panel or the Ctrl-0 (zero) (Windows and Linux) or -0 (Mac OS X) keyboard shortcut. Then, click the [Settings] button in the Master Control panel or use the Ctrl-S or -S keyboard shortcut.
2. Double-click ‘Timed Operations’. The following window appears—
3. Enter in the Database Copy field the time when you want the database to be copied. Use the 24-hour clock, and place a colon (:) between the hour and the minute. If you would like the database to be copied twice a day, enter the second time in the Second Database Copy field (this must be later than the first copy time).
If you are also using the Backup option to create a daily text back-up, make sure the text back-up is created at a different time to the copy.
They should not be created at the same time.
4. If two copies a day are not enough, use the Continuous Database Copy feature. Check the Activate box and enter the number of minutes between copies. This is the number of minutes between the moment the last copy finished and the beginning of the next copy.
5. Click the [Save] button in the Button Bar to save the changes. If you activated the Continuous Database Copy feature, the first copy will begin immediately.
Any records that you save while a copy is being made will be saved in the database and in the copy.
By default, the database copy speed is set to approximately 1.25 Mb per second (4.5 Gb per hour). The speed is limited to ensure that the system remains usable while the database is being copied. You can change the default, but bear in mind that increasing the copy speed will make the system less responsive for the users, while reducing it may mean it will take too long to copy the database. A possible guideline is to set the copy speed to one third of the copy speed when no users are logged in.
To change the database copy speed, open the Optional Features setting in the System module and go to the ‘Performance’ card—
The database duplication feature creates a duplicate database by copying one section of the database at a time. Each section is known as a “buffer”. In this example, we have specified a buffer size (size of each copied section) of 262144 bytes (256k) and a delay of 15000 microseconds between the end of one buffer and the beginning of the next. This will give a copy speed of about 16.7 Mb per second (58.6 Gb per hour). To calculate the copy speed, divide the buffer size in Mb (0.256 in this example) by the delay in seconds (0.015).
In this case, the result will be a theoretical maximum of 17.07 Mb per second, which you should then reduce to allow for the time to copy the buffer (this time will be hardware dependent).
Journaling
A busy system where many users are constantly saving large numbers of records can cause problems for a up strategy that relies on a text back-up file being created once a day and/or on copying the database twice a day.
The volume of new records means that the text back-up file or database copy quickly becomes out-of-date. If you need to revert to a back-up, it will be difficult and time-consuming if not impossible to recreate the records entered since the text back-up or database copy was made. The journaling feature is designed to address this problem. If you are using this feature, every new record and every modification will be saved in the database and in a separate journal file. If you need to revert to an older copy of the database, you will be able to “apply” the journal. “Applying” the journal means importing the recent new records and modifications to the older copy of the database from the journal file. This will be much faster and more complete than recreating the recent records manually, or extracting them from the damaged database.
You must use the journal feature together with the database duplication feature described above on page 103. If your database becomes damaged, you should revert to the most recent (undamaged) duplicate and apply the journal.
It is not possible to revert to a text back-up and apply the journal. Therefore, if you are using journaling, you must make sure you are duplicating the database regularly. The text back-up will play a much less important role in your back-up strategy.
The journal file will grow in size very quickly, especially if you import large amounts of data while journaling is running. Therefore, you must take special care to monitor the level of free hard disk on the server if you are using this feature.
Starting Journaling
1. You can start the journal feature using one of two methods—
i. Launch the command line application on the server by typing—
./HansaWorld --start-journaling &
Starts the HansaWorld Enterprise server application and marks the database as journaled. A new folder named
“journal” will be created in the folder containing the HansaWorld Enterprise server application, and a journal file named “J0000001.HJN” will be created in that folder.
If you are using the service application (Windows) or a GUI single-user application, you will need to place the --start-journaling parameter in a “parameters.txt” file before launching the application, as described above on page 36. After starting the service or the application, remove the parameter from the “parameters.txt” file.
ii. If the server is already running and you don’t want to restart it, log in from a client, change to the System module and open the Journaling setting—
Click the [Start Journaling] button. A new folder named “journal”
will be created in the folder containing the HansaWorld Enterprise server application, and a journal file named “J0000001.HJN” will be created in that folder.
You can also use the Journaling setting to start journaling in a single-user system.
2. Referring to the ‘Database Duplication’ section described above on page 103, establish a regular database duplication routine. If you need to revert to an old database, you must do so to one that was created after you started journaling. You cannot revert to a text back-up.
3. Log on from clients in the usual way and begin work. Every change will be saved in the database and in the “J0000001.HJN” file.
4. The next time you launch the command line or service application on the server, do so in the usual way (i.e. there is no need to use the --start-journaling parameter again). A message will be shown in the Terminal (Mac OS X and Linux) and in the log file as a reminder that journaling is in operation. You can also monitor this from a client by referring to the Journaling setting.