Loading the documentation…

When a table is busy

A table is busy while a load, a history run, a schema change or an OPTIMIZE uses it. A change to the table's structure or settings then has to wait its turn, and so does a run you start by hand. This page describes what you see and what you can do. To see who uses a table right now, read ETL locks.

Which changes wait for a table

A schema change needs the whole table to itself. When the table is busy, DataMind first waits up to 10 seconds: if the table frees up meanwhile, the change simply runs. What happens after that depends on the change:

Change	When the table stays busy
Saving table settings in the popup (General, Settings), Columns in the Lake and the Warehouse, creating, editing or deleting indexes, saving row-level security, Truncate, dropping a table, and removing deleted rows permanently	The change is not applied, and Table is busy offers Run when free.
Converting a view, inserting or uploading rows, saving a dictionary's queries, changing a transformation's source system, adding tables to a Mind, duplicating or retraining a Mind	The change is not applied, and Table is busy offers only Cancel. Make the change again once the table is free.
Saving a batch edit, deploying, deleting, and changing a role's table permissions	DataMind tries once, without waiting. A batch edit, and a deploy or delete of several tables, report the busy table on its own result line and go on with the others; a role permission change counts it as failed in its summary.

A Mind operation that covers several tables waits for all of them at once, and is refused as a whole when one of them stays busy; nothing is changed. Comment, personal data (PII) and permission group edits need the table only in shared mode: Dimension and periodic Fact loads never block them, only work that takes the whole table does. ETL locks lists what each kind of work takes.

Read the Table is busy dialog

The dialog is titled Table is busy and names the table under Table. Its text says what uses the table:

ETL running on this table (job #<id>, started <HH:mm>).: a load uses it.
Another schema change is running on this table (<change>, started <HH:mm>).: another person's change, or an OPTIMIZE, uses it.
This table is still being released by job #<id>.: a run has ended, and its last statements are finishing.
A queued schema change (job #<id>) runs first on this table.: a queued change is ahead in the line.

When the change can be queued, the dialog adds "Run when free" queues the change: new loads of this table wait behind it, and it runs once. The offer is valid until <HH:mm>. The offer lasts 15 minutes. When it cannot be queued, the dialog reads Run the change again once the table is free. and offers only Cancel. Pressing Enter does not confirm either way.

Queue a change with Run when free

In Table is busy, click Run when free.
Read the toast Schema change queued: It runs when "<table>" is free.
Read the dialog, now titled Schema change queued: "It runs once the table is free. You can close this dialog; you will be told how it ended." It shows Change (for example Columns, Truncate or Row-level security), Table, Status, Job (a job #<id> link that opens the change's run) and Waiting, the reason it waits.
Click Close. The change stays queued.

Status reads Queued, waiting for the table, Running, Applied, Failed or Cancelled. A change that has waited more than 10 minutes gets a Long wait badge.

The popup clears the edits that were queued; they show again once the change is applied. Edits that were not sent yet, for example index deletions you made behind a queued index change, stay unsaved, and your next save sends only those.

While DataMind stays open in your browser, a toast tells you how the change ended:

Schema change applied: <change> on "<table>" ran once the table was free. Open popups of that table, the Lake and Warehouse trees and the Editor's table list refresh.
Queued schema change failed: <change> on "<table>", with the error.
Queued schema change cancelled: <change> on "<table>", with the reason, when someone else cancelled it, aborted its run or released it from the Locks view.

Cancel a queued change

In the Schema change queued dialog, click Cancel queued change. After you have closed the dialog, stop the change's run in the runs table instead; see Monitor and fix a run.

You see The schema change has been cancelled, or The schema change already ended <status> if it ended first. A change that is already running cannot be cancelled: The queued schema change is already running and cannot be cancelled. If you click Cancel in Table is busy after a lost connection, and the change turns out to be queued already, the dialog shows the queued change instead of dropping it.

Queuing a change and cancelling your own queued changes needs Create/Edit Lake Objects, Create/Edit Warehouse Objects or Create/Edit WriteBack Objects. A person with Manage ETL Locks can also cancel someone else's queued change, through a builder Mind's Cancel queued schema change.

How a queued change runs

It runs as the person who queued it, with that person's permissions at the moment it runs.
It runs once. It cannot be restarted from the runs table; to try again, make the change again.
While it waits, new loads of that table wait behind it.
Data loaded before it runs is affected by it: a queued Truncate also empties what was loaded meanwhile.
A truncate of one source system's partitions waits for the loads of every source system of that table.
If it fails, it shows as a Failed run of the table's workflow, and that workflow's failure alerts go out. A cancelled change alerts nobody.
If the server applying it stops in the middle, it ends Failed with Interrupted while applying the schema change (<cause>); it may be partly applied. Check the table and run the change again.
A table that belongs to no workflow cannot queue a change: "<table>" belongs to no workflow, so the change cannot be queued; run it again when the table is free.

The run has the run scope Schema change and one step of the type Schema change. See Job runs.

Run a table by hand while it is busy

A run you start by hand does not fail when the table is in use, for example while the workflow is loading it. It waits its turn instead:

A transformation run, from Execute Now on the transformation's Execution tab or Run transformation on the table's Transformations tab.
A Dimension's history run for one source system.
Synchronize on a Lake table or a Writeback table. In the Lake, the button is still greyed out while the table's own sync or workflow run is live, as Run, stop and troubleshoot loads describes; the load queues when something else, such as a schema change, holds the table.

The run appears at once as Pending, with a Queued chip; hover the chip to read why it waits. It starts by itself when the table is free, in the order the runs arrived. The chip shows in the transformation's Run Log, in Transformation Runs on the table's Settings tab, and in the Sync Log of Lake and Writeback tables.

To drop a queued run, click its stop icon, which reads Cancel. The confirmation is the same as for a running run, for example Abort Transformation Run.

One case is still refused: a test run of a transformation while another test of the same transformation runs, with Test is already running for transformation: <name>. Both would use the same work tables.

Questions, answered

Why did my change open Table is busy instead of saving?

A load or another change used the table for longer than the 10 seconds DataMind waited. Your change was not applied. Click Run when free to queue it, or Cancel and make it again later.

What happens to loads while my change is queued?

New loads of that table wait behind your change, and it runs as soon as the loads that already started end. Loads that started before it finish first.

Can I close the popup after Run when free?

Yes. The change stays queued and runs on the server. While DataMind stays open in your browser, a toast tells you how it ended; the run also shows in the runs table with the run scope Schema change.

Why does the dialog offer only Cancel?

The change cannot be queued. Either it is a kind of change that does not queue, such as inserting rows or converting a view, or the table belongs to no workflow. Make the change again once the table is free.

The offer expired. What now?

Run when free is valid for 15 minutes. After that, queuing is refused with Schema change request <id> expired at <time>; run the change again. Make the change again; if the table is still busy, a new offer appears.

Can I restart a queued schema change that failed?

No. It runs once, and a restart is refused with Job #<id> is a queued schema change and cannot be restarted; run the change again. Check the error, then make the change again.

Whose permissions does a queued change use?

The permissions of the person who queued it, as they are when it runs. If that person loses the permission meanwhile, the change fails.

Why is my manual run Pending with a Queued chip?

Another run, often the workflow's own load, or a schema change uses the same table. Your run starts by itself when the table is free. Hover the chip for the reason, or click Cancel on the row to drop the run.

Will a queued Truncate remove data loaded after I queued it?

Yes. The truncate runs when the table is free, so it also empties the rows that loads added while it waited.