What is the purpose of each Jahia database table? Can I remove data from tables to save space in my database?
Question
Please do not attempt to alter the tables content without the validation by Jahia support team.
The customer has several database tables added by Jahia and some of them considerably increase in size with time.
A better understanding of the purpose of such tables is required and if Jahia allows mechanisms to periodically or manually remove data from them.
Answer
Table |
Description |
Option to Purge Items |
|
---|---|---|---|
|
Row represents a content change event entry |
||
|
Test only |
|
|
|
Used in module external-provider to configure an external data provider. Maps a valid internal UUID to org.jahia.services.content.impl.external.ExternalData ID |
From Jahia Support Tools -> JCR Providers -> JCR Broswer -> Actions (remove) |
|
|
Used in module external-provider to configure an external data provider. Row represents the key of an external data provider. This list of keys with the respective mount points and the data source class used in the mapping can be found under Administration Mode -> System Components -> External Provider Management |
|
|
|
This table keeps a full log of all operations made on Jahia so it can be replayed using a remote publication feature |
||
|
Row represents a cnd file mapped to a filename so they are accessible for all nodes on a cluster. Recommended articles: How to make a change in definition when content already exists |
|
|
|
Table containing blob data for Quartz triggers. |
|
|
|
Table containing Quartz calendars. |
|
|
|
Table containing Quartz cron triggers configured in Jahia. |
|
|
|
Table shows relevant information about Quartz Jobs which are not currently finished. Successfull executions are automatically removed from this table. Useful to verify the status of long running Quartz jobs for troubleshooting. |
|
|
|
Display implementation details about Quartz jobs. |
|
|
|
Table containing details about Quartz job listeners. |
|
|
|
Table containing internal Quartz locks. |
|
|
|
Table indicating paused Quartz trigger groups. |
|
|
|
Table containing the state of Quartz Schedulers in Jahia. |
|
|
|
Table listing Quartz simple triggers. |
|
|
|
Table containing details about Quartz trigger listeners. Quartz Scheduler Tutorials - TriggerListeners and JobListeners |
|
|
|
Table containing all Quartz triggers. Jahia Jobs are usually of type CRON. |
|
|
|
The |
|
|
|
Collects information about tasks that is used by BAM engine to build charts and dashboards. |
|
|
|
The |
|
|
|
The |
No |
|
|
Entity contains information about contextual information mapped to ksession. This is an internal part of RuntimeManager and can be considered optional when RuntimeManager is not used. |
|
|
|
The |
|
|
|
The |
|
|
|
The |
|
|
|
Join table between the task entity and the organizationalentity for relationships. |
|
|
|
The |
|
|
|
Join table between the task entity and the organizational entity for relationships. |
|
|
|
The |
|
|
|
The Although all foreign keys are not nullable, they will be set to 0 if they are not being used. In Jahia's context is used for publications/reviews tasks. |
|
|
|
This table contains more information about which nodes were actually executed inside each process instance. Whenever a node instance is entered from one of its incomming connections or is exited through one of its outgoing connections, that information is stored in this table. |
|
|
|
Join that describes and qualifies which email_header entities are part of a notification. |
|
|
|
The |
|
|
|
Join table that describes which business administrators will be notified by a notification. |
|
|
|
Join table that describes which recipients entities will be received a notification. |
|
|
|
The In Jahia's context represents the Users and Groups allowed to participate in publications tasks. |
|
|
|
Join table that describes which organizationalentity entities are the excluded owners of a particular task. |
|
|
|
Join table that describes which organizationalentity entities are potential owners of a particular task. In Jahia's context indicates which Users or Groups can change the status of a publication. |
|
|
|
Join table that describes which organizationalentity entities are notification recipients for a particular task. |
|
|
|
Join table that describes which organizationalentity entities are task stakeholders of a particular task. |
|
|
|
Join table that describes which organizationalentity entities are business administrators of a particular task. |
|
|
|
The |
|
|
|
This table contains the basic log information about a process instance. |
|
|
|
Join table that describes which organizationalentity entities are potential owners if a reassignment happens as part of an escalation. |
|
|
|
The |
|
|
|
The |
|
|
|
The |
|
|
|
The |
|
|
|
This table contains information about changes in task instances. Operations such as claim, start, stop etc are stored here to provide a timeline view of events that happened to the given task. |
|
|
|
This table contains information about changes in variable instances. The defaul is to only generate log entries when (after) a variable changes. It's also possible to log entries before the variable (value) changes. |
|
|
|
The |
|
|
|
Used in Jahia Cluster Discovery Service. Row represents a cluster node, member of a custer named cluster_name, and provides information about address and port used. Cluster nodes and channels can be found under Jahia Support Tools -> Cluster View |
||
|
The database data store stores data in a relational database. All content is stored in one table, the unique key of the table is the hash code of the content. |
||
|
Jackrabbit table referencing JCR binaries in default workspace. |
|
|
|
Jackrabbit table referencing JCR bundles data in default workspace. |
|
|
|
Jackrabbit table referencing JCR names in default workspace. |
|
|
|
Jackrabbit table referencing JCR references in default workspace. |
|
|
|
Row represents an entry in Jackrabbit filesystem. Recommended articles: |
|
|
|
Represents the global revision of the cluster. Should match individual cluster member entries in jr_j_local_revisions table to ensure a complete synchronization of the cluster. |
|
|
|
This table tracks the revisions that have to be processed by each node in the cluster. Note! This table might grow very quickly if you don't keep a coherence among cluster nodes IDs, which translates to journal_id, since it depends on the value of jr_j_local_revisions which coordinates the local revision of the cluster member. |
Is there a clean-up process for Journal entries in database for a Jahia cluster? |
|
|
Row represents the revision_id for a given cluster node member, represented by the column journal_id. |
|
|
|
Jackrabbit table. Row represents a lock in node for a given Journal_id. Lock is set in the node of a cluster member when the Journal is created and released when the Journal is commited. |
|
|
|
Jackrabbit table referencing JCR binaries in live workspace. |
|
|
|
Jackrabbit table referencing JCR bundles data in live workspace. |
|
|
|
Jackrabbit table referencing JCR names in live workspace. |
|
|
|
Jackrabbit table referencing JCR references in live workspace. |
|
|
|
Jackrabbit table used for JCR versioning. |
|
|
|
Jackrabbit table used for JCR versioning. |
|
|
|
Jackrabbit table used for JCR versioning. |
|
|
|
Jackrabbit table used for JCR versioning. |
|