A Million Row UPDATE Does Not Go Through the Pipeline: Whose Record Is a Bulk Data Fix?

Ask an organisation to describe its change process and you usually hear: a request is opened in a ticketing system, approved, goes through the pipeline and runs automatically. It is a good process and most of the time it really works that way. Then comes a question: "Does a three million row data fix go through that path too?" A pause. Then this answer: "The DBA does that under control." This article is about the gap inside that sentence.

The Riskiest Work, the Least Recorded Work

The pipeline was built to carry schema changes and application releases: adding a column, creating an index, updating a procedure. These are small, repeatable, testable jobs. A bulk data fix is a different animal: millions of records written wrongly because of a campaign error, a column left inconsistent after a migration.

These jobs are usually done like this: the DBA connects with their own account, updates in pieces with a loop, schedules it if needed and writes the result in their own notes. Most of the time it is done correctly and carefully. But three questions stay open:

• Where is the reason for this job written down?
• Who approved it?
• How will we know the command that ran is the command that was approved?

The "We Do Not Want Prevention" Sentence

For this kind of work most organisations make a conscious decision: blocking mode is off for this operation. The DBA knows what they are doing, and a block that cuts the job off halfway in the wrong place can cause a bigger problem. The decision is right. But it also says that the highest risk operation is the least controlled one, and the compensating control remains "an experienced DBA and a log".

A log is not evidence. A tool like DAM sees the operation: when, which account, how many statements. But it does not know why the operation was done, who allowed it, or whether the text that ran differs from the text that was approved.

Recording, Not Blocking

The fix is not to switch blocking on. It is to let the DBA do the job and record the decision and evidence. The bulk job becomes a request:

• The reason is written. Why is this fix being made, who asked for it.
• The risk band is set. The rule catalogue flags UPDATE and DELETE without WHERE, TRUNCATE and destructive statements; in the default installation an UPDATE or DELETE without WHERE also blocks the request from being saved. The band follows the worst finding; nothing is averaged.
• The rollback plan is produced before execution. If the "rollback required" rule is on for the server, the job cannot run without a plan. The rule is the organisation's decision; when it is off the Governance Setup Check screen shows a warning. "We have a backup" is not a plan.
• The job can be tried first in an isolated sandbox. Run it, see the result, roll it back.
• It can be scheduled. Let it run at 02:00 so nobody has to sit next to it.
• The affected row count is recorded. The answer to "how many rows were updated" is a record, not an estimate.

The DBA still does the job. But the decision, the reason and the result of the work sit in one place.

What DAM Sees and What It Does Not

Database activity monitoring of course sees the bulk job: that it started and ended, the account, the time. What it does not see is context. When an auditor asks "how many bulk data fixes were done last year and which were approved", DAM gives the number but not the approval. Combining the two layers, DAM watching and governance keeping the decision, closes the gap.

Two Reports, Two Questions

Most organisations do not know how much of their bulk correction work is systematic change and how much is done by hand. The distinction matters because manual data correction is a sign that a process is not working.

• Manual data modifications report: requests that change data with direct DML or a procedure call. You see the ratio of manual corrections to systematic changes.
• Data modification frequency report: how often INSERT, UPDATE, DELETE and MERGE ran on which table, and the last run date.

If a table receives ten manual data fixes a month, the problem is not the DBA but the application writing to that table. The report makes that visible.

The Limits

• The product does not block a connection the DBA makes with their own account. A bulk job is on record only if it runs through a request. Catching the unrecorded route needs database activity monitoring and SIEM; an organisation that picks the request as its single channel defines any access outside it as an alarm.
• A request can hold hundreds of statements; if the DBA wants to run them in pieces they design the script's loop themselves. The product runs the text and does not judge the correctness of the loop logic.

What Is Gained

It looks like a burden for the DBA. But once the first bulk job is on record as a request, this happens:

• If something goes wrong at 02:00, the question "who approved it, which text, where is the rollback plan" is answered on one page. The DBA is not blamed; the record speaks.
• A year later, when the auditor asks, there is no need to hunt for the answer.
• Repeated corrections to the same table become visible and the root cause gets looked for.

Frequently Asked Questions

How is a bulk data fix recorded if it does not go through the CI/CD pipeline?

The bulk job becomes a request: the reason, risk band, approval, digest of the text that ran and affected row count sit in one record. The DBA still does the job; blocking is not switched on, the decision and evidence are recorded.

Can a bulk job run without a rollback plan?

Not if the "rollback required" rule is on for the server. The rule is off by default and is the organisation's decision; when it is off the Governance Setup Check screen shows a warning.

How do I measure how often data is fixed by hand?

The "manual data modifications" and "data modification frequency" reports show how often direct DML ran on which table. Frequent repeat corrections suggest a root cause in the application writing to that table.