Before you start
When both switches are on, dbtempo can show which session held a lock while other statements waited, and which transactions stayed open. Both are off by default, because each one reads your database every few seconds.
- Recording needs a plan with connected collection. See Pricing for the plans that include incident diagnosis.
- The dbtempo agent (the CLI daemon) must run on a host that can reach the database. See Install the CLI.
- The engine must be PostgreSQL, MySQL 5.6 or later, or MariaDB 10.6 or later. Older MariaDB answers "not supported".
- Point the database address at the primary server. A replica or standby cannot show the primary's sessions, and dbtempo refuses it.
Give the database user the permissions it needs
The samplers read other sessions' activity, which a plain read-only user cannot see. Run the statement for your engine as an administrator.
-- PostgreSQL
GRANT pg_read_all_stats TO <user>;
-- MySQL and MariaDB
GRANT PROCESS ON *.* TO '<user>'@'<host>';
GRANT SELECT ON performance_schema.* TO '<user>'@'<host>';On MySQL and MariaDB the lock sampler also needs performance_schema itself switched on. If a permission is missing, dbtempo shows the statement that grants it. See Create a least-privilege database user for the rest of the user.
Turn the switches on
- Open the database's dialog. In the project, open the database and choose the Connection tab, then the Permissions section.
- Turn on Record lock waits. The text under the switch says what is read and how often. Read it before you turn it on: the switch is your consent to it.
- Turn on Record long transactions. This is a separate switch with its own text. It stores more than the lock switch, as the next section lists. Turn on only the one you want.
What each switch stores
| Recorded | What is kept | What is not kept |
|---|---|---|
| Lock waits | Which statement blocked which, with every literal value replaced by a ?. | Literal values. A statement that cannot be made safe is dropped and the lock is kept. |
| Long transactions | How long it was open, how long it sat idle inside, the application name, the database login name, which kinds of locks it holds (counts only), and the query text with every value removed. | Values, and the advisory lock number (a one-way tag is kept instead). |
| Connections | How many are open, how many are busy and how many are new. On MySQL and MariaDB, how many attempts failed. When the server refuses dbtempo's own connection, the time and the error code. | Anything per session. |
With the agent, values are removed on your host before anything is uploaded. Data is kept for 14 days.
Check what is being recorded
Every incident lists what was collected, for each source, with a state: Collecting, Switched off, Unreachable, Missing permission, Not reporting, Not supported, or Needs server setup. If you use an AI assistant, get_coverage gives the same answer for a database right now, with the reason and the statement that grants a missing permission. See Connect an AI assistant to dbtempo.
The agent checks every few seconds, and faster while a wait is open. Very short waits can be missed; a wait of about 10 seconds or more is reliably seen. Recording never changes anything on your database.
Next
Read an incident explains the screen you will use when something stalls.