Zapomniane hasło do panelu admina TP Livebox. Jak się włamać.

Dziś rzecz z trochę innej beczki , ale bardzo przydatna. Masz Neozdradę z Telekompromitacji i zapomniałeś hasła do panelu administratora Liveboxa? Z jednej strony można zresetować urządzenie do ustawień fabrycznych, z drugiej strony później trzeba będzie wprowadzić dane do połączenia z internetem. A potrzebna nazwa użytkownika i hasło są... gdzieś.. na jakieś umowie z TP która jest .... gdzieś ....
Znany ból? Bez dostępu do panelu admina nie skonfigurujesz ustawień WIFI, nie dodasz nowych urządzeń jeśli jest włączona filtracja po MAC, nie zmienisz hasła do WIFI jeśli je również zapomniałeś...
Jest metoda na obejście problemu bez resetowania ustawień urządzenia, ale wymaga to nieco wysiłku. Wygląda na to , że w urządzeniu jest pozostawiona boczna furtka dla serwisantów (tak przypuszczam), i ten właśnie fakt wykorzystamy.

1. Sprawdź jaki adres IP ma Twój Livebox. Uruchom linię poleceń w Windowsie, lub konsolę w Linuksie.
W Windowsie wpisz "ipconfig" , w Linuksie "ifconfig". Odszukaj linię "Brama domyślna" przy swoim połączeniu z siecią.

2. Jeśli użytkujesz Windowsa  pobierz program PUTTY. W Linuksie nie jest to potrzebne , wszelkie niezbędne narzędzia masz w systemie.
3. Uruchom program putty i w "host name" wpisz adres bramy domyślnej który sprawdzałeś przed momentem. Koniecznie zmień "connection type" na "telnet"

W Linuksie w konsoli wpisz telnet 192.168.1.1 lub inny adres IP Twojego routera.

 4. Jako użytkownika podaj "root" a jako hasło "1234".  Powinieneś wtedy zobaczyć coś takiego:

5. Wpisz w konsoli  komendę "auth"

6. Wprowadź takie polecenie:

adduser twojastara -o -services http -permissions admin

oczywiście zamiast "twojastara" podajesz jakąś inną nazwę użytkownika, taką jaką chcesz mieć - byle bez spacji. To będzie użytkownik za pomocą którego dostaniesz się do panelu admina Liveboxa.
Po naciśnięciu [ENTER] zostaniesz poproszony o podanie hasła - podaj takie jakie chcesz, tylko tym razem go nie zapomnij :) To będzie hasło do panelu admina.

7. Właściwie to już wszystko gotowe, pozostaje jedynie zalogować się do Liveboxa.
 W pasku adresu przeglądarki podajesz adres IP swojego Liveboxa. Zostaniesz poproszony o login i hasło. Podajesz te które ustawiłeś przed momentem i masz pełen dostęp do wszystkiego.

Darmowy e-book o SQL I PL/SQL

Zamierzam wrzucić tutaj darmowego e-booka na temat SQL i PL/SQL. Coś na zasadach takich jak ten blog.  Byłoby krótko, szybko i na temat . Na firmowym profilu FB zrobiłbym forum na którym czytelnicy mogliby zadawać pytania i pomagałbym rozwiązywać ćwiczenia z takiej książki. Koncepcja jest taka , że e-książka byłaby za darmo i można by ją było powielać i rozpowszechniać w dowolnej ilości kopiach.  Co Wy na to? Jest na to zapotrzebowanie?

Słowniki przydatne przy programowaniu w PL/SQL

user_source - Kod źródłowy programów których jesteśmy właścicielami.
user_arguments - Argumenty naszych procedur i funkcji
user_procedures - Lista naszych procedur, funkcji, wyzwalaczy
user_dependencies - zależności pomiędzy naszymi obiektami (w tym programami pl sql wzajemnie, oraz programami pl sql a innymi obiektami bazodanowymi).
user_plsql_object_settings - W tym słowniku znajdziemy informacje na temat sposobu kompilacji (natywna/interpretowana) naszych programów.

Jeśli w miejsce przedrostka user_ damy all_ to zamiast informacji na temat tylko naszych obiektów, dostaniemy informacje na temat wszystkich obiektów do których mamy dostęp.

VPD : Virtual Private Database

W dużym skrócie, VPD umożliwia odgórne ustawienie filtrowania tabeli dla różnych użytkowników.  Najlepiej sprawdzić to na przykładzie. Dla mnie to przypomnienie tematu i notatka, ale może kogoś ten temat zainteresuje.
Założenie projektu:
W schemacie HR mamy tabelę EMPLOYEES z listą 107 pracowników. Każdy z pracowników ma swojego użytkownika bazodanowego. Chcemy by ci użytkownicy widzieli w tabeli tylko wiersze dotyczące ich kolegów z tego samego działu, ale by nie widzieli wierszy dotyczących pozostałych osób.  Nazwy użytkowników będą takie jak emaile w tabeli.
Sposób działania VPD w tym zastosowaniu będzie taki:

1. Użytkownik loguje się. Wyzwalacz pobiera numer departamentu w którym pracuje użytkownik o emailu takim jak nazwa logującego się właśnie użytkownika. Ustawia w zmiennej pakietowej specjalnego pakietu obsługującego VPD  numer departamentu przy użyciu procedury procedury z tego pakietu.
2. Kiedy użytkownik odwoła się do tabeli EMPLOYEES w schemacie HR,  do jego zapytania zostaną dodana w tle warunki zwrócone przez specjalną funkcję z tego samego pakietu.
3. Zapytanie użytkownika z dodanymi warunkami zostanie wykonane, a ograniczony wynik wyświetlony.

Potrzebujemy więc kilku rzeczy;
1. Wyzwalacza sprawdzającego numer departamentu danego pracownika.
2. Pakietu w którym znajdą się:
              -  zmienna przechowująca wartość owego numeru departamentu
              -  procedura ustawiająca wartość w w/w zmiennej , wywoływana przez wyzwalacz
              -  funkcja która będzie dodawała warunki do zapytań
3. Konfiguracja która powiąże zadawanie zapytań przez tego użytkownika z ograniczeniami  obsługiwanymi przez pakiet.


W pierwszej kolejności tworzymy więc pakiet:

Następnie wyzwalacz który będzie sprawdzał nazwę logującego się użytkownika i na tej podstawie będzie szukał numeru departamentu do którego przypisany jest pracownik o adresie email takim jak nazwa logującego się użytkownika.

Wyzwalacz znaleziony numer departamentu przekazuje do procedury ustaw_departament w pakiecie koledzy, która wstawia numer tego departamentu do zmiennej w pakiecie.
Został ostatni element, a mianowicie ogniwo które to wszystko ze sobą zwiąże.
Dodajemy politykę. Pierwsze  dwa parametry dotyczą obiektu którego polityka ma dotyczyć.  Schemat w którym znajduje się dany obiekt, oraz nazwa tego obiektu. Trzeci parametr to nazwa polityki. Jeden obiekt może mieć wiele polityk. Czwarty i piąty parametr dotyczą pakietu który zarządza dostępem a który przed momentem stworzyliśmy. Schemat w którym znajduje się owy pakiet, oraz nazwa funkcji która zwraca warunki do zapytań. Ostatni parametr to operacje których nasza polityka ma dotyczyć.

Sprawdzamy efekty. Tworzę sobie użytkownika o nazwie SKING (pracownik o employee_id=100).
Trzeba mu też nadać standardowy zestaw uprawnień , oraz uprawnienia do operacji na tabeli employees w schemacie użytkownika hr.

Teraz już tylko się loguję i sprawdzam czy działa:

Gdyby objawiły się jakoweś ORA-XXXX, sprawdź trace file, albowiem tam właśnie objawia się oświecenie zaprawdę powiadam Ci :)


PS. Pytanie roku na szkoleniu dzisiaj. Pytanie dotyczyło wyników znajdujących się w RESULT_CACHE , które w związku ze zmianą danych na podstawie których owe wyniki zostały wyliczone stają się INVALID , czyli nieprawidłowe:  "Ale po co trzymać tych inwalidów? Nie lepiej usunąć?"   : D
Thanks :) You made my day :) Już myślałem że po pobudce przy użyciu kosiarek pod blokiem o 6 rano (słownie: szóstej rano) i kilkukrotnym wyrwaniu ze snu przez kretynów bez tłumika nic tego dnia nie uratuje. A jednak :)
PS2. I jeszcze po serii dziwnych testów i obliczeń doszliśmy dziś do wniosku że Arabowie i Chińczycy mają ograniczoną wolność wypowiedzi w kolumnach typu varchar2 ze względu pochodzenie i język.  Nie pytajcie.... :)

Bufor result cache : optymalizacja SQL i PL/SQL

Uwaga: funkcjonalność ta jest dostępna dopiero od Oracle 11g!!!

Moim zdaniem jedna z lepszych funkcjonalności dodanych w tej wersji. Jeśli często zadajemy zapytania które zwracają nam ten sam wynik, ponieważ dane na podstawie których ten wynik jest wyliczany rzadko ulegają zmianom, możemy przy użyciu bufora RESULT CACHE wykorzystać wcześniejszy wynik.
Działa to w taki sposób, że wynik zapytania jest zapisywany do bufora, a jeśli ponownie zażądamy wyniku tego samego zapytania, wynik zostanie pobrany z RESULT CACHE. Domyślnie jednak funkcjonalność ta nie jest wykorzystywana.  Aby ją wykorzystać, musimy posłużyć się hintem optymalizatora kosztowego, lub ustawić taką opcję  jako domyślną dla sesji/systemu.  Jeśli ulegną zmianie dane na podstawie których został wyliczony wynik znajdujący się w RESULT CACHE, wynik taki zostaje oznaczony jako nieaktualny i zostanie przy kolejnym wywołaniu przeliczony ponownie.

Zwykły explain plan bez użycia RESULT_CACHE:

Plan z wykorzystaniem hinta:

Korzystając z pakietu dbms_result_cache możemy sprawdzić użycie bufora. Musimy jednak włączyć output, ponieważ to na niego zostanie wyrzucony raport:

Zamiast korzystać z hinta, możemy ustawić korzystanie z result seta jako domyślne dla systemu. Poniżej dwie opcje:

Opcja z FORCE ustawi korzystanie z result seta jako domyślne. To oznacza że wynik każdego zapytanie wyląduje w RESULT_SET. Czy jest to dobre rozwiązanie? Myślę że każdy powinien rozważyć to dla swojego przypadku. Należy pamiętać że w buforze obowiązuje kolejka LRU. W przypadku dużej rotacji, może się okazać że wynik zapytania jest z bufora wypychany zanim zostanie ponownie użyty, natomiast przez RESULT_SET przelatują wyniki rzadko zadawanych zapytań, które zapychają nam bufor.
Opcja MANUAL przywróci stan domyślny tj. aby wynik zapytania wylądował w RESULT SETcie trzeba będzie użyć hinta.

Istnieje też możliwość ustawienia domyślnego korzystania z RESULT SETa  dla pojedynczej sesji:

WYNIKI ZNAJDUJĄCE SIĘ W BUFORZE RESULT SET SĄ DOSTĘPNE POMIĘDZY SESJAMI (to akurat raczej dobra wiadomość :) ) !


RESULT SET możemy również wykorzystywać w PL SQL.

Rozchodzi się o tą linijkę : "result_cache relies_on(employees)" . Taki dopisek sprawi , że wyniki pochodzące z wywołania tej funkcji będą cache'owane w RESULT SETcie. Wynik ten zostanie wykorzystany przy ponownym wywołaniu tej funckji dla takich samych wartości parametrów.


Przetestujmy więc działanie tego:

Wywołałem funkcję którą zdeklarowałem wcześniej tak by jej wyniki były domyślnie cachowanie w RESULT SETcie i sprawdzam bufor:

Elegancko się zbuforowało :) Smacznego :)

Kompilacja kodu do postaci natywnej i kompilowanej [tuning pl sql]

Mamy dwa rodzaje kompilacji kodu PL SQL w Oracle. Program może zostać skompilowany do postaci natywnej lub interpretowanej.

Kompilacja do postaci interpretowanej : tak jest ustawione domyślnie. Kod programu ląduje w słowniku systemowym i jest interpretowany przed każdym wykonaniem. Program szybciej się kompiluje, ale wolniej uruchamia w porównaniu do postaci natywnej. Dobre do środowisk testowych, gdzie często przebudowujemy kod. Mało fajny na środowiskach produkcyjnych, zwłaszcza jeśli program będzie wywoływany często.

Kompilacja do postaci natywnej: to trzeba sobie ustawić (dla systemu , albo dla sesji). Kod programu jest kompilowany do kodu natywnego i przechowywany w tablespace SYSTEM. Nie musi być za każdym uruchomieniem interpretowany. Uruchamia się szybciej w porównaniu z postacią interpretowaną. Dobre do środowisk produkcyjnych.

Możemy włączyć typ kompilacji dla sesji lub dla systemu, jak widać to powyżej.  Dopiero od tej pory programy będą kompilowane do wybranej postaci. Wszystkie skompilowane do tej pory programy pozostają w postaci pierwotnej! Jeśli istniejące już programy chcemy mieć w postaci natywnej, to po ustawieniu trybu kompilacji na natywną należy je ponownie skompilować.

Włączyłem kompilację natywną dla sesji i skompilowałem procedurę. Zrekompilowałem też istniejący wcześniej wyzwalacz. Po wyświetleniu danych ze słownika widzimy że i nowa procedura i rekompilowany wyzwalacz są skompilowane do postaci natywnej. Pozostałe nadal są przechowywane w postaci interpretowanej.

Kompresja i deduplikacja w Oracle Secure Files

Uwaga! Własność ta jest dostępna dopiero od Oracle 11g!

Od wersji 11g wprowadzono nowe algorytmy przetwarzania i nowe sposoby przechowywania LOBów. Dzięki nim uzyskamy szybszy odczyt i zapis LOBów, a także mamy możliwość zmniejszenia ilości miejsca przez nie zajmowanych.

Domyślnie LOBy są przechowywane po staremu i dopiero my musimy powiedzieć że chcemy przechowywać loby jako Secure Files. Na powyższej ilustracji prezentuję jak stworzyć tabelkę z kolumną dostosowaną do przechowywania nowego formatu LOBów.

Istnieje też możliwość kompresji i deduplikacji danych (to ta linijka z alter table). Sztuczka polega na tym, że Oracle trzyma tylko jedną kopię tego samego LOBa, a nie jak wcześniej wiele kopii. Korzyść z włączenia deduplikacji wynika wprost z ilości duplikatów. Kompresja "HIGH" pozwala na oszczędzenie nawet 60-, 70% miejsca , w zależności od rodzaju danych.

LOBy tymczasowe

Cześć,
dziś chciałbym przedstawić Wam w żołnierskich słowach loby tymczasowe. Odróżnia je od zwykłych lobów fakt, że są przechowywane w tablespace tymczasowym , a nie normalnym z danymi. Można je fajnie wykorzystać do przetwarzania lobów, jeśli np. nie chcemy modyfikować loba bazowego, a potrzebujemy przepchnąć dalej loba po przetworzeniu w jakiś sposób.

Powyżej krótka prezentacja. Stworzyłem cloba tymczasowego, załadowałem do niego trochę danych. Sprawdziłem wielkość i wyświetliłem ją na ekranie. Teraz mógłbym przekazać takiego cloba tymczasowego do kolejnej procedury/ funkcji / czegokolwiek. Na koniec usunąłem cloba z tablespace tymczasowego. Nawet gdybym tego nie zrobił, to taki clob istnieje domyślnie maksymalnie do końca sesji.

Odtwarzanie procedury / funkcji a uprawnienia do niej

Taka szybka notko-ciekawostka na temat uprawnień w PL/SQL :

Jeśli skasujesz procedurę lub funkcję, a następnie stworzysz nową o takiej samej nazwie to wszystkie uprawnienia do wykonywania owej procedury nadane użytkownikom idą do diabła. Jeśli zastosujesz CREATE or REPLACE, poprzednia procedura zostanie nadpisana, ale uprawnienia pozostaną.
Dziękuję, dobranoc.

Oracle - zmiana dbid bazy (łatwo, prosto i przyjemnie)

Kursant na szkoleniu zapytał mnie ostatnio o jakąś bezproblemową możliwość zmiany dbid bazy. Wrzucam , bo pewnie nie jeden z Was spotkał się z taką potrzebą (np. podczas duplikacji).

Step 1:
Odpalamy bazę w trybie mount  :
shutdown immediate;
startup mount; (z sqlplusa)

Step 2:

nid =xe  lub nid=/ (jeśli sid wybranej bazy mamy w zmiennej ORACLE_SID) -z konsoli

powinniśmy zobaczyć coś takiego:

Step 3 :

odpalamy bazkę z RESETLOGS :

startup mount;
alter database open resetlogs;

Step 4:

Robimy backup, bo po zmianie dbid nie będziemy mogli odtworzyć bazy z poprzednich backupów, a warto mieć jakieś zabezpieczenie (chyba że jesteś hardcorem)


PS. Dzięki Ci Sebastian  za to pytanie, bo to w sumie dobry temat do odnotowania.

Sprawdzanie zajętości tablespace'ów

Nie mojego autorstwa zapytanie bo znalezione na tej stronie:
http://www.orafaq.com/wiki/Tablespace
niemniej fajne i na pewno się przyda zwłaszcza jak ktoś nie ma Enterszajz Manadżejro.

SELECT /* + RULE */  df.tablespace_name "Tablespace",
       df.bytes / (1024 * 1024) "Size (MB)",
       SUM(fs.bytes) / (1024 * 1024) "Free (MB)",
       Nvl(Round(SUM(fs.bytes) * 100 / df.bytes),1) "% Free",
       Round((df.bytes - SUM(fs.bytes)) * 100 / df.bytes) "% Used"
  FROM dba_free_space fs,
       (SELECT tablespace_name,SUM(bytes) bytes
          FROM dba_data_files
         GROUP BY tablespace_name) df
 WHERE fs.tablespace_name (+)  = df.tablespace_name
 GROUP BY df.tablespace_name,df.bytes
UNION ALL
SELECT /* + RULE */ df.tablespace_name tspace,
       fs.bytes / (1024 * 1024),
       SUM(df.bytes_free) / (1024 * 1024),
       Nvl(Round((SUM(fs.bytes) - df.bytes_used) * 100 / fs.bytes), 1),
       Round((SUM(fs.bytes) - df.bytes_free) * 100 / fs.bytes)
  FROM dba_temp_files fs,
       (SELECT tablespace_name,bytes_free,bytes_used
          FROM v$temp_space_header
         GROUP BY tablespace_name,bytes_free,bytes_used) df
 WHERE fs.tablespace_name (+)  = df.tablespace_name
 GROUP BY df.tablespace_name,fs.bytes,df.bytes_free,df.bytes_used
 ORDER BY 4 DESC;

Ustawienia sieciowe

Mechanizm Oracle Net umożliwia nam rozłożenie obciążenia związanego z aplikacjami bazodanowymi. Odpowiada za komunikację między klientem, a serwerem. Dzięki Oracle Net możliwa jest również konfiguracja serwer-serwer, gdzie każdy serwer obsługuje aplikację klienta, a także dysponuje możliwością połączenia się z innymi serwerami sieciowymi.

Deskryptory połączeń

Nazwy serwera i instancji są identyfikowane przy pomocy deskryptora połączeń. Określa on sposób komunikowania , nazwę serwera i nazwę usługi instancji używaną w czasie przetwarzania zapytania.

Ogólny format deskryptora wygląda w następujący sposób:

(DESCRIPTION=

(ADDRESS=

(PROTOCOL=TCP)

(HOST=HQ

(PORT=1521))

(CONNECT DATA=

SERVICE_NAME=XE)))

W tym deskryptorze zastosowaliśmy protokół TCP/IP, serwer o nazwie HQ i jego port 1521 (zarejestrowany numer używany przez Oracle dla mechanizmu Oracle Net), który powinien obsługiwać połączenie, a także zdefiniowaliśmy połączenie z instancją XE serwera HQ.

Nazwy usług sieciowych

Aby użytkownicy nie musieli wprowadzać deskryptora połączeń każdorazowo, możemy zdefiniować nazwy usług (lub aliasy), które odwołują się do deskryptorów. Nazwy usług znajdują się w pliku TNSNAMES.ORA. Ten plik powinien znajdować się na każdym serwerze bazodanowym, który jest w sieci (każdy klient i serwer powinien mieć kopię tego pliku).

Użytkownik, który chce się połączyć z instancją XE serwera localhost, może skorzystać z nazwy usługi XE.

SQLPLUS HR/HR@XE

Procesy nasłuchujące

Każdy serwer bazodanowy, który znajduje się w sieci musi posiadać plik LISTENER.ORA. Plik ten zawiera w sobie nazwy i adresy procesów nasłuchujących, a także wyszczególnia instancje, obsługiwane przez te procesy. Procesy nasłuchujące obsługują żądania połączeń pochodzące z klientów Oracle Net.

Przykładowa sekcja pliku LISTENER.ORA:

gdzie:

LISTENER – to nazwa procesu nasłuchującego

DESCRIPTION – pełni rolę kontenera adresów protokołów procesu nasłuchującego

ADDRESS – określa pojedynczy adres protokołu procesu nasłuchującego

PROTOCOL – nazwa protokołu służącego do łączenia z instancją

HOST – nazwa serwera

PORT – port służący do połączeń z instancją

Dodatkowo widzimy klauzulę

DEFAULT_SERVICE_LISTENER = (XE)

która to informuje nas, z którą instancją połączymy się domyślnie, łącząc się z serwerem na którym zdefiniowany jest powyższy plik LISTENER.ORA.

Eksport i import

Oracle mamy dwa programy do tego celu EXP – do eksportowania danych, oraz IMP – do ich importowania. Przy

ich użyciu możemy eksportować i importować :

- całą bazę

- wybrany schemat

- wybrane tabele

Eksport całej bazy danych

Kod:

EXP USERID=system/tajne_haslo FILE='c:\kopia_bazy\calosc.dat'

LOG='c:\kopia_bazy\calosc.log' FULL=Y

To, co następuje po userid to nazwa użytkownika łamana przez hasło. W tym wypadku musimy to zrobić jako system, ponieważ jako zwykły użytkownik nie mamy dostępu do całej bazy (a całą chcemy eksportować). Po file podajemy nazwę pliku do którego zostanie wrzucona zawartość bazy. Plik stworzy się sam, ale struktura katalogów musi zostać przez nas uprzednio stworzona. Po log podajemy plik do którego mają być zrzucane logi. Podawanie tego nie jest obowiązkowe. Opcja Full=y nakazuje eksport całej bazy. Jeśli jej nie podamy, musimy wyeksportować schemat, albo tabelę, ale i tak musimy określić które.

Eksport całego schematu

Kod:

EXP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log' OWNER=HR

Parametry userid, file, log oznaczą to samo co poprzednio. Eksportujemy jako user hr swój własny schemat. Oczywiście możemy eksportować również schematy innych userów, ale musimy do tego być zalogowany jako user system (albo user który jest ownerem schematu). Poza tym zamiast "full=y" pojawiło się "owner=hr", co oznacza że wyeksportowany ma zostać cały schemat usera hr.

Możemy zrobić również eksport schematu na innym komputerze. Dodajemy wtedy „@adres_ip” w userid:

EXP USERID@adres_ip=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log'

OWNER=HR

Eksport wybranych tabel

Możemy chcieć też zrobić sobie kopię zapasową tylko kilku tabel. Do tego celu w miejsce wcześniejszego full=y

czy owner=hr wpisujemy np. tables=employees, departments :

EXP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' LOG='c:\kopia_bazy\schemat.log'

TABLES=employees, departments

Import danych

Kiedy wykonamy eksport bazy mamy możliwość przywrócenia jej z powrotem, lub przeniesienia/skopiowania jej

na inny serwer. Do tego użyjemy programu IMP.

Import całej bazy

Kod:

IMP USERID=system/tajne_haslo FILE='c:\kopia_bazy\calosc.dat' LOG='c:\kopia_bazy\calosc.log' FULL=Y

DESTROY=Y

Parametr userid - oznacza to samo co w exp, kiedy importujemy całość bazy musimy być zalogowani jako user system. File to plik z wcześniejszego eksportu danych, log tak jak wcześniej. Full=y ponieważ importujemy całość, destroy=y oznacza, że jeśli istnieje już obiekt w bazie o takiej nazwie to zostanie skasowany i nadpisany. Jeśli tego nie dodamy, to w takiej sytuacji będziemy dostawali zapytanie czy chcemy wprowadzić zmiany (możemy zamiast tego dodać ignore=y, wtedy nie będzie nadpisywał i kasował zmian).

Import schematu

Importować możemy zawartość schematu nie tylko z powrotem do schematu usera z którego zostały dane

wyciągnięte, ale też możemy je wstawić innemu userowi. Dlatego przy imporcie nie ma już 'owner=hr', ale za to

jest 'touser=hr' określający do schematu jakiego usera mają dane zostać wrzucone, oraz 'fromuser=hr' czyli

schemat jakiego usera może być wciągnięty (bo jeżeli importujemy jakiś schemat z eksportu całej bazy, mamy tam

bardzo wiele schematów i musimy któryś wybrać).

IMP USERID=hr/hr FILE='c:\kopia_bazy\schemat.dat' fromuser=hr touser=hr destroy=y

Możemy tutaj też dodać LOG='c:\kopia_bazy\schemat.log' jak przy eksporcie, ale nie jest to konieczne.

Import poszczególnych tabel

Podobnie jak przy imporcie schematu wprowadzamy fromuser i touser - w tym względzie działa to tak samo.

Wybieramy też tabele które chcemy zaimportować.

Kod:

IMP USERID=hr/hr FILE='c:\kopia_bazy\tabele.dat' FROMUSER=hr TOUSER=hr TABLES=EMPLOYEES

!! Musimy uważać z importem, bo Oracle nadpisuje tabele importowane bez żadnej informacji.

RMAN - Kopie zapasowe w Oracle. Backup i odtwarzanie

Podstawowe informacje i wstępna konfiguracja

Backupy możemy wykonywać na dwa sposoby:

- wyłączając bazę i kopiując fizyczne pliki (tzw. zimny backup)

- wykorzystując RMANa i zrobić backup bez wyłączania bazy (hot backup)

Aby wykonać hot backup należy ustawić bazę w tryb ARCHIVELOG. Po tym zabiegu pliki

dzienników powtórzeń przed nadpisaniem zostaną zarchiwizowane. Dzięki temu mamy pewność że

nie zostaną wyczyszczone w trakcie backupu. Wykonujemy to w następujący sposób:

- Logujemy się SQL*Plusem jako SYS do bazy.

- Robimy SHUTDOWN IMMEDIATE; (tylko ten jeden raz jest to konieczne).

- Uruchamiamy bazę w trybie MOUNT (poleceniem STARTUP MOUNT).

- Wywołujemy polecenie ALTER DATABASE ARCHIVELOG;

- otwieramy bazę dla użytkowników poleceniem ALTER DATABASE OPEN;

Ten krok można pominąć ale ta konfiguracja pozwoli nam na wybór innego niż domyślne miejsce

składowania plików backupu. Oracle zawiera w sobie Flash Recovery Area. To przestrzeń

zawierająca backupy, służąca do ich przywracania. Jest ona zarządzana przez silnik bazy danych, a

nie system operacyjny. W niej właśnie będą składowane nasze backupy. Sprawdzamy aktualne

położenie FRA:

SELECT * FROM v$recovery_file_dest;

Jeśli chcemy zmienić dostępną dla FRA przestrzeń dyskową stosujemy komendę:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G;

Parametr ten ustawia ile miejsca na dysku mogą maksymalnie zajmować backupy oraz archivelogi.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='c:\FRA';

Parametr ten ustawia gdzie na dysku mają znajdować się backupy.

Po ustaleniu w/w parametrów, warto sprawdzić, czy wszystko zostało przez nas poprawnie

ustawione. Wybieramy więc komendy:

SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest';

SELECT * FROM v$parameter WHERE NAME='db_recovery_file_dest_size';

Włączamy konsolę command line a następnie wpisujemy RMAN.

Podłączenie do bazy

Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych. Robi się to

wpisując komendę:

CONNECT TARGET

lub

CONNECT TARGET /

lub

CONNECT TARGET nazwabazy

Pełny backup

W celu wykonania pełnego backupu bazy danych wywołujemy komendę:

BACKUP DATABASE;

Jako że to jest pełny backup, trwa on dosyć długo. Należy cierpliwie poczekać na pojawienie się

komunikatu RMANa. Nasz backup pojawi się w zdefiniowanym przez nas Flash Recovery Area.

Jeśli chcemy by nasz backup znalazł się w innym niż domyślne miejscu wpisujemy komendę:

BACKUP DATABASE FORMAT 'c:\rman\calabaza%u.bck';

Tag %u to unikalny numer generowany m.in. na podstawie daty i godziny utworzenia, dzięki

czemu każdy plik kopii zapasowej będzie miał unikalny numer.

Formatów tych jest kilka i można je wplatać w nazwę pliku. Przedstawiam te podstawowe:

%s – numer backupu

%d – nazwa bazy danych

%D – dzień

%M – miesiąc

%Y – rok

%u – wartość unikalna wyliczona na podstawie wszystkich w.w opcji

Taki backup obejmuje dane oraz plik kontrolny. Jeśli chcemy wykonać backup razem z plikami

zarchiwizowanymi dziennika powtórzeń, to wywołujemy komendę:

BACKUP DATABASE PLUS ARCHIVELOG;

Backup skompresowany

Pliki backupów zajmują sporo miejsca. Warto więc by były kompresowane. Jest możliwość

kompresowania przy użyciu RMANa. RMAN stosuje algorytm podobny do tego używanego przez

program archiwizujący ZIP.

Zamiast BACKUP DATABASE; wpisujemy:

BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT

'c:\FRA\full_compressed%u';

lub przykładowo z plikami (zarchiwizowanymi) dziennika powtórzeń:

BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG FORMAT

'c:\FRA\full_compressed%u';

Taką kompresję można stosować też przy backupach tablespace'ów oraz backupach przyrostowych

i kumulatywnych. Co prawda kopia zapasowa jeśli jest kompresowana wykonywana jest dużo

dłużej, ale zajmuje w efekcie mniej miejsca.

Backup przyrostowy i kumulatywny

Nie zawsze musimy chcieć wykonywać pełną kopię zapasową. Z resztą po co nam za każdym

razem całość jeśli można pełny backup zrobić raz, a później wykorzystywać zajmujące znacznie

mniej miejsca kopie przyrostowe.

Definicje:

Kopia pełna - czyli kopia wszystkich plików danych oraz pliku kontrolnego

Kopia przyrostowa - czyli kopia tylko tych bloków danych które uległy zmianie od ostatniego

pełnego lub przyrostowego backupu.

Kopia kumulatywna - kopia wszystkich bloków danych które uległy zmianie od ostatniego

pełnego (!!! już nie ostatniego przyrostowego) backupu.

Backup przyrostowy

Od wersji 10g Oracle obsługuje dwa poziomy kopii przyrostowej 0 i 1. Kopia przyrostowa poziomu

0 fizycznie nie różni się niczym od pełnego backupu, z tą różnicą że na jej podstawie możemy

wykonywać normalne kopie przyrostowe (poziom 1). Tak więc przynajmniej raz musimy wykonać

komendę:

BACKUP INCREMENTAL LEVEL 0 DATABASE FORMAT 'c:\FRA\przyrostowa_0_%u';

aby następnie móc wykonywać :

BACKUP INCREMENTAL LEVEL 1 DATABASE FORMAT 'c:\FRA\przyrostowa_1_%u';

Komenda z level 1, jest to już normalna kopia przyrostowa.

Backup kumulatywny

Aby wykonać backup kumulatywny wywołujemy komendę:

BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

Warto dość często wykonywać kopie przyrostowe, a raz na jakiś czas (np. tydzień) kopię

kumulatywną. Dzięki temu będziemy mogli później pozbyć się kopii przyrostowych, a co za tym

idzie, mieć mniejszą ilość plików do przechowywania.

Ten tag możemy łączyć z innymi poznanymi wcześniej, np.:

BACKUP INCREMENTAL LEVEL 1 FORMAT 'c:\FRA\inc_comp%u' AS COMPRESSED

BACKUPSET DATABASE PLUS ARCHIVELOG;

Szybki backup przyrostowy

Normalnie backup przyrostowy realizowany jest tak, że ostatni backup z danymi porównywany jest

blok po bloku. Zamiast tego, można zrobić tak by Oracle tworzyło sobie listę zmienionych bloków.

W takim wypadku backup przebiegał będzie znacznie szybciej. Niestety ta opcja jest dostępna tylko

w wersjach Standard i Enterprise.

Najpierw sprawdźmy czy już ta opcja nie jest włączona:

SELECT * FROM v$parameter WHERE NAME='db_create_file_dest';

Jeśli pole value będziemy mieli puste, to znaczy że nie było to wcześniej ustawiane.

Tworzymy katalog w którym taka lista będzie przechowywana, a następnie wpisujemy:

ALTER SYSTEM SET db_create_file_dest='c:\FRA\fib';

oraz włączamy tą opcję:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Backup tablespace'ów

RMANem możemy wykonywać również backupy tablespace'ów, plików danych, pliku parametrów, pliku kontrolnego.

Najpierw sprawdźmy jakie mamy tablespace'y:

SELECT * FROM DBA_TABLESPACES;

Komenda do backupu wybranego tablespace'a:

BACKUP TABLESPACE USERS FORMAT 'c:\FRA\users%u';

Klauzula format jest oczywiście nieobowiązkowa. Możemy też chcieć zapisać kilka tablespace'ów,

wtedy rozdzielamy ich nazwy przecinkami:

BACKUP TABLESPACE USERS, SYSTEM FORMAT 'c:\FRA\users_system%u';

albo zechcieć je dodatkowo skompresować:

BACKUP AS COMPRESSED BACKUPSTE TABLESPACE USERS FORMAT

'c:\FRA\users_compressed%u';

lub zrobić nie dość że skompresowaną to jeszcze przyrostową (oszczędzamy miejsce - dyski kiedyś

się kończą).:

BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FORMAT

'c:\FRA\users_comp_przyr%u' TABLESPACE USERS;

Backup pliku parametrów

Komenda (format jest opcjonalny):

BACKUP SPFILE FORMAT 'c:\FRA\spfile%u';

Backup pliku kontrolnego

Warto abyśmy wykonywali osobną kopię pliku kontrolnego. Dlaczego? Ponieważ informacje o

backupach przechowywane są właśnie w nim. Co prawda w pełnych backupach jest też kopia pliku

kontrolnego, ale nie będziemy w stanie przywrócić backupu, jeśli plik kontrolny ulegnie

uszkodzeniu. W takim przypadku dużo łatwiej odzyskać najpierw plik kontrolny a później resztę.

Aby wykonać taki backup wpisujemy:

BACKUP CURRENT CONTROLFILE FORMAT 'c:\FRA\controlfile%u';

Taką kopię pliku kontrolnego (zwłaszcza że nie zajmuje wiele miejsca) warto mieć jak najświeższą.

Dbanie o to by tak było możemy zlecić silnikowi bazy:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

Od tej pory jeśli nastąpi jakakolwiek zmiana wpływająca na plik kontrolny, ten zostanie

automatycznie zbackupowany po zmianach. Możemy teraz chcieć by RMAN backupował nam plik

kontrolny w inne miejsce niż domyślne. Wywołujemy komendę:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO

'd:\FRA\plikkontrolny%u';

Kopia zapasowa plików zarchiwizowanych dziennika powtórzeń

SELECT * FROM v$datafile;

BACKUP AS COPY DATAFILE 'c:\app\administrator\oradata\orcl\users01.dbf' FORMAT

'c:\FRA\users.dbf';

Komenda ta kopiuje wszystkie bloki, zajęte oraz puste. Jeśli więc będziemy mięli określony

tablespace o wyznaczonej z góry sporej wielkości, backup zajmie niepotrzebnie bardzo dużo

miejsca.

Odtwarzanie przy użyciu RMAN

Aby rozpocząć przywracanie interesujących nas rzeczy z backupu, włączamy konsolę command

line a następnie wpisujemy RMAN.

Przede wszystkim po włączeniu RMANa, musimy podłączyć się do bazy danych (tak jak w

przypadku tworzenia plików backupu). Wpisujemy zatem komendę:

CONNECT TARGET

lub

CONNECT TARGET /

lub

CONNECT TARGET nazwabazy

Możemy przywrócić teraz to, co wcześniej zbackupowaliśmy (bazę, tablespace'y, plik kontrolny,

czy pliki zarchiwizowanych dzienników powtórzeń).

Przywracanie bazy z pełnego backupu

Zaczniemy od przywrócenia pełnej bazy z naszego backupu. Aby to zrobić musimy najpierw

wyłączyć bazę, a następnie włączyć ją w tryb mount (możemy to zrobić wprowadzając listę

komend):

RUN{

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

RESTORE DATABASE;

RECOVER DATABASE;

ALTER DATABASE OPEN;

}

RMAN sam sprawdzi który backup jest tym ostatnim, bez względu na to, czy robiliśmy pełny

backup, inkrementalny, czy też kumulatywny. Również sam załaduje odpowiedni controlfile i

archivelogi.

Przywracanie bazy do określonego punktu w czasie

Możemy przywrócić bazę do określonego punktu w czasie, w tym celu wyłączamy, a następnie

uruchamiamy bazę do trybu mount:

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Podajemy do którego momentu chcemy przywrócić bazę:

run{

set until time ”to_timestamp('12:00:00 01-09-2011','hh24-mi-ss dd-mm-yyyy')”;

restore database;

recover database;

}

Następnie uruchamiamy bazę, resetując archivelogi:

ALTER DATABASE OPEN RESETLOGS;

Walidacja bazy i backupów

W celu sprawdzenia poprawności plików bazy danych wywołujemy komendę:

BACKUP VALIDATE DATABASE;

możemy również wykonać walidacje dla bazy, wraz z archivelogami:

BACKUP VALIDATE DATABASE PLUS ARCHIVELOG;

Co ważne, podając tę komendę nie wykonujemy backupu!

Aby sprawdzić poprawność ostatnio wykonanego backupu wprowadzamy:

RESTORE DATABASE VALIDATE;

aby sprawdzić poprawność pliku backupu wraz z archivelogami:

RESTORE ARCHIVELOG ALL VALIDATE;

Zarządzanie backupami

Chcąc sprawdzić nasze backupy możemy je wylistować wpisując komendę:

LIST BACKUP;

Warto czasem sprawdzić, czy pliki do których odnosi się backup wciąż są obecne na dysku. Aby to

zrobić wywołujemy:

CROSSCHECK BACKUP;

Jeśli powyższe zapytanie wykaże nam błąd (różne od found to be 'AVALIABLE'), możemy wtedy usunąć niepotrzebne pliki backupu używając komendy:

DELETE EXPIRED BACKUP;

Możemy również wykasować nieaktualne, niepotrzebne już backupy np. przestarzałe:

DELETE OBSOLETE;

Aby ustawić politykę backupów, tzn. kiedy pliki backupów będą uważane przez RMANa za przestarzałe musimy zmodyfikować parametr RETENTION POLICY. Mamy możliwość ustawienia ilości backupów, które mają być uważane za aktualne, bądź czas, podawany w dniach.

Ustawienie dla ilości dni przez jakie backupy będą uważane za „ważne” ustawiamy poleceniem:

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

Powyższym poleceniem ustawimy, iż RMAN będzie uważał za przestarzałe pliki backupów stworzone później niż 3 dni wstecz.

Ustawienie dla ilości przetrzymywanych backupów ustawiamy wywołując polecenie:

CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

Tym poleceniem ustawiamy, iż RMAN będzie uważał za aktualne 3 ostatnie pliki backupów.

Po wylistowaniu backupów (LIST BACKUP) zobaczymy jaki numer odpowiada konkretnemu

plikowi backupu. Znając ten numer, możemy usunąć konkretny backup posługując się właśnie tym

numerem:

DELETE BACKUPSET 69;

Przywracanie tablespaceów

Aby odtworzyć tablespace musimy odłączyć go od bazy przy pomocy komendy OFFLINE. W tym

wypadku również możemy posłużyć listą komend:

RUN{

SQL 'ALTER TABLESPACE USERS OFFLINE';

RESTORE TABLESPACE USER;

RECOVER TABLESPACE USERS;

SQL 'ALTER TABLESPACE USERS ONLINE';

}

Przywracamy tablespace systemowy

Tutaj również możemy posłużyć się listą komend. Jako, że jest to tablespace systemowy, jesteśmy

zmuszeni zamknąć bazę danych i wprowadzić ją w tryb MOUNT:

RUN{

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

RESTORE TABLESPACE SYSTEM, SYSAUX;

RECOVER TABLESPACE SYSTEM, SYSAUX;

ALTER DATABASE OPEN;

}

Przywracanie pliku kontrolnego

Plik kontrolny przywracamy dodając na końcu komend dodatek RESETLOGS:

RUN{

SHUTDOWN IMMEDIATE;

STARTUP NOMOUNT;

RESTORE CONTROLFILE FROM AUTOBACKUP ;

ALTER DATABASE MOUNT;

RESTORE DATABASE;

RECOVER DATABASE;

ALTER DATABASE OPEN RESETLOGS;

}