Care este cel mai rău accident de date care ți sa întâmplat în producție?

Am încercat să reparăm un nod blocat pe un cluster Oracle.

Modulul de gestionare a stocării a avut probleme, așa că am făcut clic pe butonul de dezinstalare cu intenția de a reinstala și a copia configurația de la un alt nod.

Apare butonul de dezinstalare aplicat întregului grup, așa că a eliminat cu bucurie modulul de gestionare a stocării din toate nodurile din sistem.

Cauzând fiecare nod din clusterul de producție să se prăbușească. Și din moment ce nici unul dintre noduri nu avea un manager de stocare, nu ar veni!

Iată un fapt interesant despre copiile de rezervă ... cele mai vechi copii de siguranță se rotesc în afara site-ului și știți care sunt cele mai vechi fișiere dintr-o bază de date? Fișierele de configurare care au fost configurate la instalarea sistemului.

Așa că a trebuit ca oamenii din afara să trimită un curier cu acea bandă și câteva ore mai târziu am pus totul la loc și am alergat. Acum păstrăm copii locale ale fișierelor de instalare și de configurare!

update Customers set ModifyUser = 'Terrapin'

Am uitat clauza unde - destul de nevinovată, dar pe o masă cu 5000 de clienți, numele meu va fi pe fiecare înregistrare pentru un timp ...

Lecția învățată: utilizați comiterea tranzacțiilor și revocarea tranzacțiilor!

Tăiați tabelul T_DAT_STORE

T_DAT_STORE a fost tabelul de fapt al departamentului în care lucrez. Cred că am fost conectat la baza de date de dezvoltare. Din fericire, avem o copie de rezervă zilnică, care nu a fost folosită până în acea zi, iar datele au fost restaurate în șase ore.

De atunci am revizuit totul înainte de o trunchiere și periodic cer o restaurare de rezervă a tabelelor minore doar pentru a verifica dacă copia de rezervă se descurcă bine (Backupul nu este făcut de departamentul meu)

Un DBA junior a vrut să facă:

delete from [table] where [condition]

În schimb, au scris:

delete [table] where [condition]

Care este valabil T-Sql, dar ignoră în realitate cazul unde [condiția] este complet (cel puțin atunci a făcut-o pe MSSQL 2000/97 - am uitat de ce) și șterg întregul tabel.

A fost amuzant :-/

Cel mai rău scenariu pentru majoritatea oamenilor este pierderea datelor de producție, dar dacă nu execută copii de rezervă de noapte sau replică date pe un site DR, atunci merită tot ceea ce primesc!

@ Keith în T-SQL, nu este cuvântul cheie opțional pentru o DELETE? Ambele declarații fac exact același lucru ...

Cel mai rău lucru care mi sa întâmplat a fost că un server de producție consumă tot spațiul din HD. Am folosit SQL Server pentru a vedea fișierele bazei de date și pentru a vedea că jurnalul a fost de aproximativ 10 Gb, așa că am decis să fac ceea ce fac întotdeauna când vreau să trunchiez un fișier Log. Am făcut o Detașare a șterge fișierul jurnal și apoi atașați din nou. Ei bine, îmi dau seama că, dacă fișierul jurnal nu este aproape corect, această procedură nu funcționează. asa ca am sfarsit cu un fisier MDF si nici un fisier log. Din fericire, m-am dus la site-ul Microsoft primesc o modalitate de a restabili baza de date ca recuperare și de a trece la o altă bază de date.

Actualizarea tuturor rândurilor din tabelul de clienți, deoarece ați uitat să adăugați clauza de locație.

Așa am făcut: . Am actualizat coloana de parolă pentru toți utilizatorii într-un șir de șir pe care l-am scris pe consola. Cea mai rea parte a fost că am accesat serverul de producție și am verificat câteva întrebări când am făcut acest lucru. Seniorii mei au trebuit apoi să revină la o copie de rezervă veche și au trebuit să facă apeluri de la niște clienți cu adevărat nemulțumiți. Desigur, există un alt moment când am folosit declarația de ștergere, despre care nici nu vreau să vorbesc ;-)

Aproximativ 7 ani în urmă, generam un script de modificare pentru DB clientului după ce am lucrat târziu. Am schimbat numai procedurile stocate, dar când am generat SQL am avut "obiecte dependente de script" verificate. Am rulat-o pe mașina mea locală și toate păreau că funcționează bine. Am rulat-o pe serverul clientului și scenariul a reușit.

Apoi am încărcat site-ul Web și site-ul a fost gol. Pentru horror, setarea "obiecte dependente de script" a făcut un DROP TABLE pentru fiecare tabel pe care mi-au atins procedurile memorate.

Am sunat imediat pe conducătorul dev și șeful, lăsându-i să știe ce sa întâmplat și întrebându-se unde ar putea fi localizată cea mai recentă copie de siguranță a DB. Au fost conferențiate alte două discuri, iar concluzia la care am ajuns a fost că nici un sistem de backup nu a fost încă disponibil și nu au putut fi restaurate date. Clientul și-a pierdut conținutul întregului site web și am fost cauza principală. Rezultatul a fost un credit $ 5000 acordat clientului nostru.

Pentru mine a fost o lectie minunata, iar acum sunt super-prudenta in a rula scripturile de schimbare si de a sustine mai intai DB-urile. Sunt inca in aceeasi companie astazi si cand glumele vin despre backup-uri sau scripturi de baze de date, cineva aduce intotdeauna faimosul incident "DROP TABLE".

Am descoperit că nu înțelegeam fișierele Oracle redo log (terminologia - cu mult timp în urmă) și am pierdut datele de tranzacționare săptămânale, care trebuiau să fie re-introduse manual din bilete de hârtie.

Acolo a fost o căptușeală de argint - în weekend-ul pe care l-am petrecut, am învățat multe despre utilitatea ecranului meu de intrare comercială, care sa îmbunătățit dramatic după aceea.

Am făcut exact ceea ce ați sugerat. Am actualizat toate rândurile dintr-un tabel care conținea documente pentru clienți, deoarece am uitat să adaug "la sfârșitul ID = 5". Aceasta a fost o greșeală.

Dar eram inteligent și paranoic. Știam că o să-i dau o zi. Am emis o "tranzacție de început". Am dat o revizuire și apoi am verificat masa fiind OK.

Nu a fost.

Lecție învățată în producție: în ciuda faptului că ne place să folosim tabelele InnoDB în MySQL din multe motive ... să fiți siguri că nu ați reușit să găsiți unul dintre puținele tabele MyISAM care nu respectă tranzacțiile și nu vă puteți răsfoi din nou pe. Nu aveți încredere în MySQL în nicio situație și emiteți în mod obișnuit o "tranzacție de pornire" este un lucru bun. Chiar și în cel mai rău scenariu (ceea ce sa întâmplat aici) nu a făcut nimic rău și m-ar fi protejat pe mesele InnoDB.

A trebuit să restaurez masa dintr-o copie de rezervă. Din fericire avem o copie de rezervă pe timp de noapte, datele aproape că nu se schimbă, iar tabelul are câteva duzini de rânduri, deci era aproape instantaneu. Pentru referință, nimeni nu știa că avem în continuare mese non-InnoDB, am crezut că le-am convertit cu mult timp în urmă. Nimeni nu mi-a spus să mă uit la asta, nimeni nu știa că era acolo. Șeful meu ar fi făcut același lucru exact (dacă ar fi lovit intra prea devreme, înainte de a introduce clauza de unde prea).

Am crezut că lucram la testul DB (ceea ce nu a fost cazul aparent), așa că, când am terminat de testat, rulez un script pentru a reseta datele toate înapoi la datele de testare standard pe care le folosim. .. ouch!
Din fericire, acest lucru sa întâmplat într-o bază de date care avea copii de rezervă, așa că, după ce am inventat ceva greșit, am putea readuce cu ușurință baza de date originală.

Cu toate acestea, acest incident a învățat compania pe care am lucrat pentru a separa mediul de producție și de testare.

Odată am reușit să scriu un cursor de actualizare care nu a ieșit niciodată. Pe o tabelă de rânduri 2M +. Blocurile au escaladat și s-au majorat până când această cutie cu 16 nuclee, de 8 GB RAM (în 2002!), Sa împrăștiat cu adevărat la o oprire (a soiului albastru).

Cred că cea mai gravă greșeală a mea a fost

truncate table Customers
truncate table Transactions

I didnt a vedea ce server MSSQL am fost logat, am vrut să clar mi copia mea locală ... Familiar "Oh s ** t", atunci când a fost luând semnificativ mai mult de aproximativ o jumătate de secundă pentru a șterge, șeful meu a observat m-am dus vizibil alb, și a întrebat ce am făcut. Aproximativ o jumătate de oră mai târziu, monitorul nostru de site-uri a mers și a început să ne trimită prin e-mail, spunând că site-ul a fost în jos.

Lecții învățate? Nu mențineți niciodată o conexiune deschisă pentru a trăi DB mai mult decât este absolut necesar.

Numai până la ora 4 am restaurarea datelor din copiile de rezervă! Șeful meu mi-a păcat rău pentru mine și mi-a cumpărat cina ...

Lucrez pentru o mică companie de comerț electronic, sunt 2 dezvoltatori și un DBA, fiind unul dintre dezvoltatori. În mod obișnuit nu am obiceiul de a actualiza datele de producție în zbor, dacă avem proceduri stocate pe care le-am schimbat, le-am pus prin controlul sursei și am instalat o instalare de rutină oficial.

Ei bine, oricum un utilizator a venit la mine necesitând o actualizare făcută la baza noastră de date de contact, actualizarea lotului de facilități. Așa că am scris cererea în mediul nostru de testare, ceva de genul

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

Ceva de genul. A alergat în test, 3 rânduri actualizate. A copiat-o în clipboard, a lipit-o în serviciile terminalului de pe caseta noastră de producție, a rulat-o, a urmărit în groază, deoarece a durat 5 secunde pentru a executa și actualiza 100000 de rânduri. Într-un fel, am copiat prima linie și nu cea de-a doua și nu acordă atenție, deoarece CTRL + V , CTRL + E 'd.

DBA, un domn grec vechi, probabil cel mai proastă persoană pe care l-am întâlnit nu a fost încântat. Din fericire am avut o copie de rezervă și nu a rupt nici o pagină, din fericire că acest câmp este doar pentru scopuri de afișare (și facturare/expediere).

Lecția învățată a fost să acordați atenție copiilor și lipirilor, probabil și altora.

Nu-mi amintesc toate instrucțiunile sql care au ieșit din control, dar am o lecție învățată - o faci într-o tranzacție dacă poți (feriți-vă de fișierele mari de jurnale!).

În producție, dacă puteți, continuați modul vechi:

1. Utilizați o fereastră de întreținere
2. Backup
3. Efectuați modificarea
4. verifică
5. restaurați dacă ceva nu a mers prost

Destul de necorespunzător, dar, în general, funcționează și chiar este posibil să dai această procedură altcuiva să o conducă în timpul turei de noapte, în timp ce îți primești somnul bine meritat :-)

Ceva cu efect de:

actualizați e-mail set processTime = null, sentTime = null

pe o bază de date de buletine informative de producție, redistribuind fiecare e-mail din baza de date.