I was swapping tables on a live production server,* and accidentally removed all rows on the production table rather than the auxiliary one. With autocommit on. I immediately confessed to my boss, and luckily, there was a backup.
However, I never did what I saw other people do at another job (more than once), which was to run a delete on a live production table intentionally, but unintentionally leave off the "where" clause. And commit without thinking.
I'm not aware of anything I've screwed up that had a dollar figure attached.
You didn't remove rows, you had an unscheduled test of your restore procedures.
I've done something similar before, forgot to disable autocommit in DataGrip and ran an UPDATE without a where clause - thankfully we take weekly full backups, nightly incrementals and archive log segments so I shut down the database, performed a point-in-time-restore and the damage was undone.
This was actually a good teaching moment, said database is used as a holding area for incoming data from hospitals before we load it into our billing system so our EDI team has limited write permissions on the database - it's much harder for them to run a "oops, time to grab a backup" query but it was a nice anecdote to use when telling them to run everything in a transaction if they're running anything other than SELECT statements.
Comments
I was swapping tables on a live production server,* and accidentally removed all rows on the production table rather than the auxiliary one. With autocommit on. I immediately confessed to my boss, and luckily, there was a backup.
However, I never did what I saw other people do at another job (more than once), which was to run a delete on a live production table intentionally, but unintentionally leave off the "where" clause. And commit without thinking.
I'm not aware of anything I've screwed up that had a dollar figure attached.
*I am not and never have been a sysadmin per se.
You didn't remove rows, you had an unscheduled test of your restore procedures.
I've done something similar before, forgot to disable autocommit in DataGrip and ran an UPDATE without a where clause - thankfully we take weekly full backups, nightly incrementals and archive log segments so I shut down the database, performed a point-in-time-restore and the damage was undone.
This was actually a good teaching moment, said database is used as a holding area for incoming data from hospitals before we load it into our billing system so our EDI team has limited write permissions on the database - it's much harder for them to run a "oops, time to grab a backup" query but it was a nice anecdote to use when telling them to run everything in a transaction if they're running anything other than SELECT statements.