For instance: Upgrading all rows from the customer table since you didn't remember to include the where clause.

  1. That which was it like, recognizing it and confirming it for your colleagues or clients?
  2. What were the training learned?

I believe my worst mistake was

truncate table Customers
truncate table Transactions

I did not see what MSSQL server I had been drenched into, I needed to obvious my local copy out...The familiar "OH s**t" if this was taking considerably more than about 50 % another to remove, my boss observed I went visibily whitened, and requested things i just did. About 50 % a mintue later, our website monitor went nuts and began contacting us saying the website was lower.

Lesson learned? Never have a connection available to live DB more than absolutly needed.

Was just up till 4am rebuilding the information in the backup copies too! My boss felt sorry for me personally, and bought me dinner...

A junior DBA designed to do:

delete from [table] where [condition]

Rather they typed:

delete [table] where [condition]

That is valid T-Sql but essentially ignores the where [condition] bit completely (a minimum of it did in those days on MSSQL 2000/97 - I forget which) and baby wipes the whole table.

Which was fun :-/

Sometimes for any small e-commerce company, there's 2 designers along with a DBA, me being among the designers. I am normally not within the practice of upgrading production data quickly, when we have saved methods we have transformed we place them through source control and also have an formally deployment routine setup.

Well anyways a person found me requiring an update completed to our contact database, batch upgrading a lot of facilities. And So I authored the query within our test atmosphere, something similar to

update facilities set address1 = '123 Fake Street'
    where facilityid in (1, 2, 3)

Something of that nature. Went it in test, 3 rows up-to-date. Replicated it to clipboard, copied and pasted it in terminal services on our production sql box, went it, viewed in horror because it required 5 seconds to complete and up-to-date 100000 rows. In some way I replicated the very first line and never the 2nd, and wasn't having to pay attention when i Control + V, Control + E'd.

My DBA, a mature Greek gentleman, most likely the grumpiest person I have met wasn't thrilled. Fortunately we'd a backup, also it did not break any pages, fortunately that area is just really for display reasons (and billing/shipping).

Lesson learned was give consideration as to the you are copying and pasting, most likely many others too.

I remember when i handled to create an upgrading cursor that never left. On the 2M+ row table. The locks just increased and increased until this 16-core, 8GB RAM (in 2002!) box really ground to some halt (from the blue screen of death variety).

About many years ago, I had been producing a big change script for any client's DB we have spent late. I'd only transformed saved methods however when I produced the SQL I'd "script dependent objects" checked. I went it on my small local machine and all sorts of made an appearance to be effective. I went it around the client's server and also the script been successful.

I Quickly loaded the site and also the site was empty. To my horror, the "script dependent objects" setting did a DROP TABLE for each table that my saved methods touched.

I immediately known as charge dev and boss allowing them to understand what happened and asking in which the latest backup from the DB might be situated. 2 other devs were conferenced in and also the conclusion we found was that no backup system being in position with no data might be restored. The customer lost all of their website's content and that i was the real cause. The end result would be a $5000 credit provided to our client.

For me personally it had been an excellent lesson, and now i'm super-careful about running any change scripts, and copying DBs first. I am still with similar company today, and whenever the jokes show up about backup copies or database scripts someone always raises the famous "DROP TABLE" incident.

Something towards the effect of:

update email set processedTime=null,sentTime=null

on the production e-newsletter database, resending every email within the database.