Dla mojego klienta od czasu do czasu pracuję w jego aktywnej bazie danych, aby naprawić problem, który sam stworzył, lub w celu naprawienia złych danych, które utworzyły błędy mojego produktu. Podobnie jak w przypadku dostępu roota w systemie Unix, jest po prostu niebezpieczny. Jakich lekcji powinienem się nauczyć z wyprzedzeniem?
Jaka jest pierwsza rzecz, którą należy zrobić, aby zachować ostrożność podczas pracy na danych w czasie rzeczywistym?
Odpowiedzi:
Trzy rzeczy, których nauczyłem się na własnej skórze przez lata ...
Po pierwsze, jeśli aktualizujesz lub usuwasz dane na żywo, najpierw napisz zapytanie SELECT z klauzulą WHERE, której będziesz używać. Upewnij się, że działa. Upewnij się, że jest poprawny. Następnie dołącz instrukcję UPDATE / DELETE do znanej klauzuli roboczej WHERE.
Nigdy nie chcesz
DELETE FROM Customers
siedząc w analizatorze zapytań czekając, aż napiszesz klauzulę WHERE ... przypadkowo naciśniesz „wykonaj” i właśnie zabiłeś tabelę Customer. Ups.
Ponadto, w zależności od platformy, dowiedz się, jak szybko wykonać kopię zapasową tabeli. W SQL Server 2005
SELECT *
INTO CustomerBackup200810032034
FROM Customer
skopiuje każdy wiersz z całej tabeli Customer do nowej tabeli o nazwie CustomerBackup200810032034, którą można następnie usunąć po wykonaniu aktualizacji i upewnieniu się, że wszystko jest w porządku. Jeśli wydarzy się najgorsze, o wiele łatwiej będzie przywrócić brakujące dane z tej tabeli, niż spróbować przywrócić kopię zapasową z zeszłej nocy z dysku lub taśmy.
Na koniec uważaj na usuwanie kaskadowe, pozbywając się rzeczy, których nie zamierzałeś usuwać - sprawdź relacje tabel i kluczowe ograniczenia, zanim cokolwiek zmodyfikujesz.
BEGIN TRANSACTION;
W ten sposób możesz wycofać się po błędzie.
Najpierw zrób kopię zapasową: i tak powinno to być prawo numer 1 administrowania systemem
EDYCJA : uwzględniając to, co powiedzieli inni, upewnij się, że AKTUALIZACJE mają odpowiednie klauzule WHERE.
W idealnym przypadku zmiana działającej bazy danych nigdy nie powinna mieć miejsca (poza wstawkami INSERT i podstawową konserwacją). Zmiana struktury żywego DB jest szczególnie obarczona potencjalną złą karmą.
Wprowadź zmiany w kopii, a gdy będziesz zadowolony, zastosuj poprawkę do opublikowania.
Często zanim wykonam UPDATE lub DELETE, piszę równoważny SELECT.
NIGDY nie rób aktualizacji, chyba że jesteś w BEGIN TRAN t1 - nie w bazie danych deweloperów, nie w produkcji, nigdzie. NIGDY nie uruchamiaj COMMIT TRAN t1 poza komentarzem - zawsze pisz
--COMMIT TRAN t1
a następnie wybierz instrukcję, aby ją uruchomić. (Oczywiście dotyczy to tylko klientów zapytań GUI). Jeśli zrobisz te rzeczy, ich robienie stanie się drugą naturą i nie stracisz prawie żadnego czasu.
Właściwie mam makro "aktualizacji", które wpisuje to. Zawsze wklejam to, aby skonfigurować aktualizacje. Możesz zrobić podobny dla usuwania i wstawiania.
begin tran t1
update
set
where
rollback tran t1
--commit tran t1
Zawsze upewnij się, że Twoje UPDATE i DELETE mają odpowiednią klauzulę WHERE.
Odpowiadając na moje własne pytanie:
Pisząc oświadczenie o aktualizacji, napisz je poza kolejnością.
UPDATE [table-name]WHERE [conditions]SET [columns-and-values]Wybór wierszy, które chcesz zaktualizować, zanim powiesz, jakie wartości chcesz zmienić, jest o wiele bezpieczniejszy niż zrobienie tego w innej kolejności. Uniemożliwia update person set email = 'bob@bob.com'to siedzenie w oknie zapytania, gotowe do uruchomienia przez niewłaściwe naciśnięcie klawisza, gotowe zepsuć każdy wiersz tabeli.
Edycja: tak jak powiedzieli inni, napisz WHEREklauzulę dotyczącą usunięcia, zanim napiszesz DELETE.
Na przykład tworzę SQL w ten sposób
--Update P Set
--Select ID, Name as OldName,
Name='Jones'
From Person P
Where ID = 1000
Podświetlam tekst od końca do Select i uruchamiam ten SQL. Po sprawdzeniu, że pobiera rekord, który chcę zaktualizować, naciskam klawisz Shift-up, aby podświetlić instrukcję Update i ją uruchomić.
Zauważ, że użyłem aliasu. Nigdy nie aktualizuję wprost nazwy tabeli. Zawsze używam aliasu.
Jeśli robię to w połączeniu z transakcjami i wycofywaniem / zatwierdzaniem, jestem naprawdę, naprawdę bezpieczny.
Mój najlepszy sposób, aby zachować ostrożność z aktywną bazą danych? Nie dotykaj tego. :)
Kopie zapasowe mogą cofnąć szkody, które wyrządzasz w bazie danych, ale nadal istnieje prawdopodobieństwo, że w tym czasie wprowadzisz negatywne skutki uboczne.
Bez względu na to, jak solidny jest skrypt, z którym pracujesz, przeprowadź go przez cykl testowy. Nawet jeśli „cykl testowy” oznacza uruchamianie skryptu na własnej instancji bazy danych, upewnij się, że to robisz. O wiele lepiej jest wprowadzić usterki do lokalnego pudełka niż do środowiska produkcyjnego.
Kilka innych rzeczy, które uznałem za pomocne:
jeśli używasz MySQL, włącz Bezpieczne aktualizacje
Jeśli masz administratora DBA, poproś go o zrobienie tego.
Odkryłem, że te 3 rzeczy powstrzymały mnie przed wyrządzeniem poważnej krzywdy.
Cóż, to wszystko, o czym teraz myślę. Weź odważne fragmenty, a zobaczysz, co jest dla mnie nr 1. ;-)
Jeśli używasz Oracle lub innej bazy danych, która to obsługuje, sprawdź wprowadzone zmiany przed wykonaniem polecenia COMMIT.
Dane powinny być zawsze wdrażane na żywo za pomocą skryptów, które można ćwiczyć tyle razy, ile jest to wymagane, aby uzyskać je dobrze w środowisku deweloperskim. Kiedy istnieją zależne dane, aby skrypt działał poprawnie na dev, przygotuj go odpowiednio - nie możesz uciec od tego kroku, jeśli naprawdę chcesz być ostrożny.
Przed rozpoczęciem wykonaj kopię zapasową lub zrzuć bazę danych.
Różne kolory na środowisko: Ustawiliśmy naszego programistę PL \ SQL (IDE dla Oracle) tak, aby po zalogowaniu się do produkcyjnej bazy danych wszystkie okna były w kolorze jasnoczerwonym. Niektórzy posunęli się nawet do przypisania innego koloru dla deweloperów i testów.
Upewnij się, że podczas usuwania rekordów określono klauzulę Where.
zawsze najpierw testuj zapytania poza select w danych programistycznych, aby upewnić się, że mają one odpowiedni wpływ.
Jeśli aktualizuję bazę danych za pomocą skryptu, zawsze upewniam się, że na początku mojego skryptu umieszczam punkt przerwania lub dwa, na wypadek, gdyby przypadkowo trafiłem na polecenie uruchom / wykonaj.
Dodam do zaleceń robienia BEGIN TRAN przed AKTUALIZACJĄ, po prostu nie zapomnij wykonać polecenia COMMIT; możesz wyrządzić tyle samo szkód, jeśli pozostawisz niezatwierdzoną transakcję otwartą. Nie daj się rozproszyć telefonom, współpracownikom, obiadom itp., Gdy jesteś w trakcie aktualizacji, bo zobaczysz, że wszyscy inni są zamknięci, dopóki nie ZATWIERDZISZ lub ODWRÓCENIE.
Zawsze komentuję wszelkie destrukcyjne zapytania (wstawianie, aktualizowanie, usuwanie, upuszczanie, zmiana) podczas pisania zapytań adhoc w Query Analyzer. W ten sposób jedynym sposobem na ich uruchomienie jest zaznaczenie ich bez zaznaczania komentowanej części i naciśnięcie F5.
Myślę też, że dobrym pomysłem jest, jak już wspomniano, napisanie najpierw instrukcji Where z zaznaczeniem i upewnienie się, że zmieniasz właściwe dane.
Utwórz użytkownika tylko do odczytu (lub poproś o to administratora DBA) i używaj go tylko do przeglądania bazy danych. Dodaj odpowiednie uprawnienia do schematu, aby można było wyświetlić zawartość procedur składowanych / widoków / wyzwalaczy / itp. ale nie mają możliwości ich zmiany.