Managing databases tables
The Registry persists information, such as settings and structural metadata to a database. The only time you may need to directly modify this database without using the Registry User Interface is to possibly remove unwanted logging information. It is recommended to NOT modify database tables unless explicitly instructed to do so.
Logging Tables
Auditing and Logging in the Registry can produce large amounts of data, which is stored in the following 3 tables:
- registry_audit
- registry_logs (Fusion Registry 10 only)
- registry_logs_zip (Fusion Registry 10 only)
The table registry_audit stores Audit information for requests received directly to Registry Web Services (e.g. the Data Transformation Web Service) as well as calls directly to the GUI and any Web Services that are called as direct consequence of that (e.g. the front page of the Registry 'overview.html' calls subsequent Web Services ). The registry_logs and registry_logs_zip tables are used for storing logging information which is the information generated by the Registry logger. This information is usually output to the Apache Tomcat file "FusionRegistry.logs" but can also be stored in the database.
The information stored in these tables is not particularly visible to users of the Registry and is generally only accessible by using the "Activity" administration pages, where the information can be displayed in a modal like the following:
The information in these tables may relate to structural submission or simply a web service query. It is generally recommended to persist any requests which have a transaction ID against them as these are releated to structural submission, modification or deletion.
Removing Data from the Tables
It is permissable to delete the contents of the above tables whilst the Registry is running. If the data from these tables is removed the only effect is that requesting particular data from the activity pages may result in an error message stating that the data is unavailable.
It is recommended to preserve the data that has an associated transaction id. This allows the preservation of the information regarding who submitted or modified the structural metadata.
For the Audit table this can be achieved with:
DELETE FROM registry_audit WHERE tx_id IS NULL
and for the logging tables:
DELETE FROM registry_logs logs JOIN registry_logs_zip zip ON logs.log_uid = zip.log_uid WHERE logs.log_uid IN (SELECT log_uid FROM registry_logs WHERE tx_id IS NULL);