 |
 |
 |
 | |||||||||
|
Awaryjne odzyskiwanie danych z bazy danych ORACLE | ||||||||||||
| ||||||||||||
| ||||||||||||
| ||||||||||||
| ||||||||||||
| ||||||||||||
| Skutki |
| ||||
| Co właściwie się stało ??? |
 |
|
Komunikaty programu "Server Manager" informujące o niepoprawnym stanie bazy to jeden z najczęściej spotykanych objawów uszkodzenia - awarii - bazy danych Oracle. Niestety, spotykane są jeszcze inne bardziej złożone. Każdorazowy brak możliwości połączenia się komputera klienta z serwisami serwera nie oznacza jednak awarii całego systemu bazodanowego. Najbardziej odpowiednim działaniem w takim przypadku jest kontrola uruchomienia odpowiednich serwisów BD Oracle. Kolejnym krokiem jest test poprawności działania elementów interfejsów sieciowych programem TNSPING. 10% zgłaszanych uszkodzeń BD polega na naprawie jedynie odpowiednich procedur dostępu do samych połączeń sieciowych związanych z działaniem samej sieci. W przypadku prawidłowych komunikatów informujących o uzyskaniu połączenia programu TNSPING należy skontrolować procedury uruchomienia bazy danych (odpowiednich skryptów uruchamiających). Posiadanie odpowiednich praw dostępu do bazy pozwoli nam łatwo uruchomić bazę ręcznie wydając polecenie ORASTART (odpowiednie dla każdego rodzaju systemu operacyjnego). Ścisłe śledzenie przebiegu działania tego polecenia pozwoli się przekonać o występujących problemach podczas samego procesu otwierania i montowania bazy. Wszelkie zauważone komunikaty są źródłem cennej informacji do podejmowania dalszych działań związanych z odzyskiwaniem BD. Pomimo niejednokrotnie "linijkowego" komunikatu o występującym błędzie należy bezwzględnie zapisać jego numer postaci ORA-?????. W przypadku stwierdzenia wystąpienia uszkodzenia w działaniu bazy danych należy wykonać kopię bezpieczeństwa: - plików przechowujący dane (najczęściej sporych rozmiarów pliki *.ORA, lub *.DBF), - plików startowych (ORA(sid).INI), - plików REDO-LOGS, - plików TRACE Tak zabezpieczone pliki mogą służyć
w każdej chwili do odtworzenia momentu wystąpienia awarii. Nawet w
przypadku wykonywania najmniejszych zmian w samej BD zachowanie
kopii bezpieczeństwa gwarantuje "bezpieczne" zachowanie tych danych
które dopiero "mogą" zostać utracone przez celowe lub nieświadome
działania użytkownika, który będzie próbował naprawić bazę danych
stosując dostępne mu środki i procedury naprawcze. Zdarza się często utracić cześć swoich danych poprzez nieświadome lub nie do końca świadome wykonanie poleceń języka SQL takich jak DROP TABLE lub TRUNCATE. Wynikiem takich działań jest utrata całości informacji na temat miejsca i sposobu przechowywania samych danych, natomiast dane te nie są fizycznie kasowane z nośników. Stopień odzyskania takich danych zależy w dużej mierze od tego czy miejsce skasowanej tabeli nie zostaną nadpisane następne dane. Dlatego tak ważną rzeczą jest wykonanie kopii zapasowej plików bazy danych bezpośrednio po zajściu zdarzenia. Odzyskiwalność tak utraconych informacji kształtuje się na poziomie 100%, dodatkowo jeżeli użytkownik/administrator posiada wiedzę nt. struktury skasowanego obiektu możliwe jest jego całkowite odtworzenie.
|
|
|
|
|
|
Copyright © 2005 Mathnoid Ltd.
Wszystkie znaki użyte na tej stronie są znakami towarowymi.
Wykorzystywanie ich w celach zarobkowych jest zastrzeżone. |
 |