| |
|
|
In a perfect world you would not need this chapter. Alas, in real life, data corruption does happen. We will explain to you the available tools and procedures that should minimize the possibility of you losing your valuable data.
Each table in Alventis is made up of 2 or 3 physical files. If the table is called "Something", you'll find the following files in the directory where the Database is located:
The DAT file holds the table data, except that of BLOB fields (Memos and Graphics/Pictures). The IDX file holds the indices. The BLB file holds the BLOB data mentioned above. It is only present if the table contains at least one Memo or Graphic field, which is why some tables don't have a BLB file.
You may also find files with DBK/IBK/BBK extensions. These are backup files created when you change the table structure in Designer.
When it comes to Alventis data tables of the kind that you use in UniGrids and InfoViews, there's a whole second table that always accompanies the main data table. That second table contains the full-text index for the data table. It follows the same "pattern" as we have described above. It's name is always that of the data table with an ".idw" suffix. If we assume that "Something" table above was one of your data tables, it would then be accompanied by:
Alventis stores all kinds of information it needs in many other tables. These tables always have names that begin with "Ifxs", e.g., "IfxsTables". Such "system" tables will not have a second full-text index table.
Due to a power outage, a computer crash, or some other sinister event, one or more of the above-mentioned files comprising a table may get corrupted. Some minor corruption can be repaired using tools built into Alventis. Major corruption may not be fixable, so you'd have to restore affected tables from a backup. But let's not be overly pessimistic, so let's talk about repairs first.
To be able to click this button you must be in the right place (and preferably at the right time – more on that later). Specifically, you must be either in the Tables grid of a UniGrid with some table focused – or in the Database Explorer with some Database focused. When invoked from a UniGrid, the dialog box will offer you to verify and/or repair the selected table and all system tables belonging to the same Database. When invoked from the Database Explorer, all tables of the selected Database will be listed (both data and system ones).
For a table to be verified (or repaired), it must not be already open (neither by your copy of Alventis or Designer, nor by anybody else). If Alventis does not manage to open the table exclusively, verification is immediately abandoned. The Progress Log memo will display a message to that effect: Operation aborted: Table Something could not be opened exclusively
This in itself does not mean that there's something wrong with the table. It only states that the table is open by someone or something, so it cannot be checked. Which brings us to the question of when is the "right time" to verify/repair tables. It is obviously best to do so when relevant tables can be opened exclusively. Doing so right after you start Alventis may be a good idea. If Alventis re-opens tables on startup, you can either close the corresponding InfoViews manually or simply restart Alventis with the Shift key pressed so that Alventis does not re-open any forms (you do not need to clear Persistence data, just prevent Alventis from using it for this "verification" session). Once you are done with verify/repair operations, you can close Alventis – again holding down the Shift key. This way, the next time it will start and re-open whatever forms you had open – as usual. In a multi-user environment, you must make sure you are the only user accessing the data (not because something can "break" but simply to be able to open the tables exclusively).
The Table Doctor dialog is rather simple. On the left, the tables that will be verified/repaired are listed. On the right is the Progress Log that displays any output messages. Three buttons and a Status bar complete the picture. The Verify button starts verification of all listed tables. Tables that are successfully verified and given a clean bill of health are prefixed with "[OK]" in the list. Tables that could not be verified (typically because they were open) or that did get verified and were found to be defective remain unchanged. If you want to try once more (perhaps after persuading your colleagues to close the table of interest), you can simply click Verify again: only the tables that were not already found to be OK are re-verified. If not all tables are OK, it's a good idea to review the Progress Log to see what's wrong. If you see any messages other than the relatively innocent "could not be opened exclusively", it's time to do some repairs.
Clicking the Repair button launches the repair procedure for all tables not already found to be OK. The basic principle is quite similar to what we described above, except in this case, Alventis will attempt to repair any defects it finds. If you see some messages to the effect that repairs were performed and were successful, it's a very good idea to verify the tables once again (which is why the Repair procedure does not mark the affected tables "[OK]"). On rare occasions Alventis can be overly-optimistic and think it has repaired a table when it has improved it but didn't quite finish the job. If this happens, a second repair will often succeed in fixing the remaining problems. So, occasionally you may need to repeat the Verify/Repair/Verify/Repair cycle. If consecutive attempts to Repair a table produce the same unsatisfactory result, this means the problem is too serious, and Alventis does not and will not manage to fix it. Restoring the table from a backup is then the only solution, but we'll get to that shortly.
The above procedures were verifying and repairing table(s) of one Database. There are some system tables that are not part of any Database though. Alventis verifies them all on startup, every time it is launched. If a problem is found, Alventis will display the Table Doctor dialog on startup offering you an opportunity to repair the corrupted table(s). The procedure is exactly the same as we have described above. Ideally, you should go through the Verify/Repair cycle enough times, until all system tables are OK. If they aren't, closing the dialog in a less-than-perfect state will offer you a choice of closing Alventis (so that you could restore the relevant tables from a backup) or proceeding at your own risk. What is the risk? It's really impossible to tell. The worst that can happen is even worse data corruption leading to further data loss. You should most certainly avoid any data-modification operations (which is rather tricky). Basically, you should fix the problem as soon as possible.
A few notes and facts pertaining to table repairs are in order. A "broken" table may get repaired. This means that you went through the Verify/Repair procedure outlined above, re-verified the table, and that final verification stated the table is now "OK". You must understand though that this only means one thing: the structure of the table no longer has any visible defects. The problem is that nobody can guarantee that the data that was in the table is still intact and what it's supposed to be. For example, imagine your table contained in some string field the name "Smith". Imagine now that some data corruption resulted in one byte of that table changing, so the above field value became "Skith" or some such. The verification procedure will notice the problem, and the repair procedure will most likely clean-up the table structure, but it may not be able to figure out what letter was supposed to be in the 2nd position in that field value, so you might end up with a seemingly healthy table that now contains "Skith". If your data is mission-critical, you may want to, e.g., export it (perhaps from time to time) to text files so that you could perform textual comparisons. If you didn't understand this idea, don't worry about it. This is rather advanced topic that is beyond the scope of this Guide. Besides, data corruption is a fairly rare occurrence.
Index corruption. This paragraph is somewhat advanced, so feel free to skip it. The Repair procedure certainly does its best to repair both data and indices (whatever got corrupted). On rare occasions, the corruption is in the index file, and repairs fail to make any improvements. If you find yourself in that situation, the solution is simple for someone who is comfortable with file management. Close Alventis, delete the broken index file (affected TableName.idx), re-launch Alventis, and try to repair the table again. This time, Alventis should be able to simply rebuild the index from scratch (instead of trying in vain to repair the damage). This works because the index can be "derived" in its entirety from the data file.
When you have reasons (outlined above) to believe that a table may have a problem with its full-text index, all you have to do is rebuild the said index. To do so, select the table of interest in the Tables grid of a UniGrid, and click the Reindex Table button. You get a Proceed/Cancel type of prompt. If you proceed, Alventis will attempt to re-create the full-text index for the selected table. If reindexing fails, you will get a grim message to that effect. Failure almost always means the table could not be opened exclusively (even though the actual error message text may suggest otherwise). If you firmly believe that the relevant table is closed, trying again in several minutes (5 or so) often helps. You can also try closing and reopening Alventis, perhaps holding down the Shift key to prevent the possibility of the relevant table getting automatically reopened.
Technical notes (advanced material). The reindexing operation essentially recreates the entire full-text index from scratch (or more precisely, from the indexed data). This has some important implications. The reindexing process can be quite lengthy for large tables, especially if the tables have Memo fields. Around 1 minute per Megabyte of data file should not be too surprising, so you may want to launch reindexing of large tables at strategically-chosen times of the day. As we said earlier, the full-text index table (confusing but correct terminology: the full-text index is itself stored in a separate table), so, that full-text index table can be completely derived from the data that is being indexed. The full-text index table, as you may remember, is stored in a table that has a name of the type "Something.idw" with extensions dat/idx/blb (3 files). In case the full-text index ("idw") table gets corrupted, you can simply delete it and rebuild it from scratch. After all, this is what is automatically done after an InfoSet Import.
Backup. We have learned that data corruption may occasionally occur and that Alventis may be able to verify and often repair minor corruption. More importantly, we have hopefully learned that not all corruption can be repaired, and even seemingly successful repairs may result in you losing some data. Which brings us to the inevitable subject of backups.
Data backups are the only means of ensuring complete safety of your data. We are not writing a book about backups though, so we'll get straight to the technicalities.
What should be backed up. The very short answer is: data. Everything that looks like data. In the case of Alventis, this means: all files with the following extensions: dat, idx, blb. These files can be found in the following locations:
In addition to data, you may also want to backup your custom spelling dictionaries. These would include the files in the Spell subdirectory of the application directory: those with the adu extension. You may also backup Learning.adl and Spell.cfg, even though these 2 are less valuable.
It is of course a good idea to verify all the tables prior to backing them up. A sensible sequence would therefore go something like this: close Designer (if you have it and it was open) and Alventis; re-launch Alventis (so that it gets an opportunity to verify all system tables on startup); verify (and if necessary, repair) all tables of all databases; close Alventis once everything seems in order; perform the backup.
The following notes are rather technical and somewhat advanced, so you can safely ignore this section if you don't fully understand it. From our earlier discussion of repairs and reindexing it should be clear that the truly most important files are data table files (those in the Database directories), of which the dat and blb files are most important since this is where the actual data is stored. The idx file can be rebuilt, but it's obviously better to have a backup copy. The "idw" table is less important in a backup since it can be rebuilt, but it's best to back it up too (if space is not an issue). The system (Ifxs*) tables are for the most part quite important, so you should back them all up. They typically don't take too much space either.
It may be useful to list files you most likely would not want to back up (at least not more than once). The application executables (the files with the exe extension) need not be backed up since you can hopefully re-install the application if they ever got corrupted. Same goes for the User's Guide and the Spelling and Thesaurus dictionaries: files with adm and adt extensions in the Spell subdirectory. None of these files should ever change, so you may want to exclude them from your daily backup routine.
If you ever find yourself restoring data from a backup, you'd first want to make sure all copies of Alventis and/or Designer are closed (and the Server is shut down, if applicable). You would then restore the files you deem necessary (maybe all of them, maybe just one table – this would depend on the situation, so we can't offer you much guidance in this matter). Once this is done, it may be wise to launch Alventis, verify the affected tables, and possibly reindex them (unless you restored both the table and its full-text index).
In closing, we would like to once again remind you of the importance of making backups. Computers crash, hard drives die, power goes out, and in the resulting darkness you step on the CD-R with the only good backup. Make multiple backups of any data you would be sad to lose. On different types of media: other hard drives, diskettes, CD-Rs, Zip disks, Flash cards or drives, etc. Never overwrite your last good backup with a new one. Keep several sets of good backups and rotate them. E.g., if backing up to disks A, B, and C, do so in a round-robin fashion. It may sound tedious, and it probably is, but one day, it may save your data. |
