Related Topics and Links:

Repositories and Projects

Backups and Database Maintenance: Protecting Your Data

Since each database may contain a large amount of valuable information that would be difficult to re-create, it is essential to make sure that you are diligent about storing adequate backups and performing the necessary maintenance activities to keep the database operating smoothly. The necessary procedures vary depending on the type of database.

Enterprise Database Maintenance

When you choose to store analysis information in an enterprise database, a database administrator must perform backups and database maintenance activities using the data management tools that are packaged with and/or designed for the database platform (e.g., SQL Server Enterprise Manager for SQL Server). Each individual organization typically establishes its own procedures for protecting the data stored in the Oracle or SQL Server databases. As a convenience for users who wish to explore the possibilities of an enterprise database implementation without making a large investment of time and resources, instructions on how to perform the minimum database maintenance recommendations are posted on the ReliaSoft website:

See https://www.reliasoft.com/using-sql-enterprise-databases for SQL Server.

See https://www.reliasoft.com/using-oracle-enterprise-databases for Oracle.

Standard Database Maintenance

When you choose to store analysis information in a standard database, it will be subject to the same limitations and vulnerabilities as any other file that uses the Microsoft Access® database file format. For example, the maximum file size is ~ 2GB, maximum number of concurrent users is 255, etc. In addition, some specific database vulnerabilities are discussed in a Microsoft publication at http://support.microsoft.com/kb/283849/EN-US/. As this publication states:

"Microsoft Jet, the database engine that is used in Microsoft Access, is a file sharing database system. When Microsoft Jet is used in a multi-user environment, multiple client processes are using file read, write, and locking operations on a shared database. Because multiple client processes are reading and writing to the same database and because Jet does not use a transaction log (as do the more advanced database systems, such as SQL Server), it is not possible to reliably prevent any and all database corruption." [emphasis added]

Although our developers have made every effort to reduce or eliminate the possibility that the software will induce a database error, there is no way to absolutely prevent corruption that might be caused by other factors, such as faulty network hardware, an unexpected "crash" on your computer or a network interruption. Therefore, this section provides some recommendations for standard precautions that all users can take to protect the data in their standard databases from this type of corruption and reduce the impact of the data loss if corruption is unavoidable.

  1. Create backups regularly. As with any resource that contains a large amount of valuable information that would be difficult to re-create, it is essential to make sure that you are diligent about creating and storing backup files. There are a number of ways this can be accomplished:

  2. Compact and repair regularly. Using the "Compact and Repair" feature will help to reduce the size of the database file and help to protect against problems with the operation of the database. If you have the database open and it is not currently in use by another user, you can initiate the process by at any time by choosing File > Manage Repository > Compact and Repair.

  3. Do not store the database in a shared network location if you suspect that your network connection and/or hardware may be unreliable. According to Microsoft, faulty network hardware is one of the main reasons why a file that uses the Microsoft Access database file format may become corrupted. As the Microsoft publication at http://support.microsoft.com/kb/283849/EN-US/ states:

"The cause can be one or more links in the hardware chain between the computer that the database resides on and the computer that has the database open. This list includes, but is not limited to, network interface cards, network cabling, routers, and hubs.

Hardware-based corruption is typically indicated by .mdb files that cannot be restored through the use of compacting, repairing, or Jetcomp. Hardware corruption will typically recur until the responsible hardware is repaired or replaced." [emphasis added]

If you have experienced this type of corruption for a standard database file, it is recommended that you take steps to correct the network problem or refrain from accessing database files over the network. In such cases, you may choose to use an enterprise database instead (i.e., Oracle or SQL Server), which would be less vulnerable to network interruptions. Alternatively, you could keep multiple analysis projects together in a single shared standard database file but ask users to export the analysis to a separate "working" database on their own computers when there is a need to make substantial modifications. Users could then import the data back into the shared database after the modifications have been completed.

  1. Do not allow the file size of the database to grow too large. Performance will be affected by the size of the database and the number of simultaneous users. Therefore, it is important for users to monitor the sizes of their database files and take steps to export the data into several smaller and more manageable files if they become too large. Please be aware of the following factors, which can lead to very large database files:

If you try to open a standard database via the software and receive a message that says "Unable to open the database," this is an indication that the database file may have become corrupted. Please contact Technical Support and provide as much information as possible about exactly what you were doing when the corruption occurred. Whenever possible, please provide a copy of the corrupted file. In some cases, we may be able to provide assistance with salvaging some or all of the affected data. However, in many cases, the best recourse may be to restore the latest backup from before the corruption occurred.

 

© 1992-2019. HBM Prenscia Inc. ALL RIGHTS RESERVED.

E-mail Link