Rman Backup vs Cold Backup (Ogromna różnica w ilości zajmowanego miejsca)

Witam serdecznie, jestem Administratorem Bazy Oracle 10g, zacząłem wdrażać rozwiązanie RMANowe do swojej firmy ponieważ posiadamy licencję Enterprise a backupy są robione na taśmę kopiując pliki fizycznie co wymusza wyłącznie bazy. Chciałbym trochę usprawnić to rozwiązanie, ponieważ taśmy to jednak nie jest zbyt dobry pomysł + backupy Rmanowe ważą o wiele mniej. Backup Rmanowy składa się z pełnego backupu + Archivelog.

Po pomyślnym odtworzeniu bazy używając w.w backupu baza danych waży 57 GB. Co mnie zastanawia to fakt, że pliki bazodanowe na bazie produkcyjnej (Oradata) ważą 150GB...

Moje pytanie brzmi, co spowodowało taki spadek użycia miejsca na dysku między bazą produkcyjną vs testową (po odtworzeniu).

Różnica to prawie 100GB, co jest bardzo zastanawiające. Po udanym uruchomieniu bazy testowej(Alter database open resetlogs) zliczyłem rekordy z trzech głównych tabel systemów funkcjonujących w mojej firmie, ilość rekordów się zgadza między prodem a testem.

Użycie miejsca badam z poziomu OS(SUSE Linux) komendą "df -h".

Czy macie może pomysły co może powodować tak duże zużycie na bazie produkcyjnej, ewentualnie w jakie miejsca powinienem zajrzeć. Ewentualnie może istnieje coś w stylu defragmentacji tablespaceow co zwolniłoby niezajmowane miejsce.

Z niecierpliwością czekam na sugestie, jeżeli będą potrzebne skrypty z RMANa oraz kroki odtwarzania, to dorzucę później do postu.

Pozdrawiam,

Poczytaj o "RMAN unused block compression". RMAN pomija bloki, które nie były użyte, a są zaallokowane do pliku.

jak dla mnie to stwierdzenie jestem Administratorem Bazy Oracle 10g oraz treść Twojego pytania wykluczają się nawzajem. Dodatkowo potwierdza to backupy są robione na taśmę kopiując pliki fizycznie co wymusza wyłącznie bazy. No ale do rzeczy.

Najpierw trochę teorii - w większości SQLowych baz danych usunięcie rekordu (wykonanie DELETE FROM ... WHERE ...) nie powoduje "wyrzucenia" rekordu z pliku z danymi a jedynie oznaczenie go jako usunięty. Rozmiar pliku z danymi nie jest zmniejszany, usunięte dane nie są nadpisywane przez "resztę pliku". Jeśli nie domyślasz się dlaczego to odpowiedź jest bardzo prosta - było by to zabójstwo dla wydajności. Dodatkowo w dzisiejszych czasach przestrzeń dyskowa jest znacznie tańsza od mocy obliczeniowej więc znaczne przyspieszenie operacji (a właściwie zaniechanie ich opóźniania) kosztem większego zapotrzebowania na dane (w zależności od ilości operacji DELETE i UPDATE) jest ekonomicznie akceptowalna. TIP: część baz danych operację UPDATE zamienia na dwie inne - DELETE zmienianego rekordu oraz INSERT rekordu ze zmienionymi danymi co eliminuje czasochłonne operacje "rozszerzania" pliku jeśli "nowy" rekord jest większy od "starego".

Żeby sobie zobaczyć jak są wykorzystywane pliki danych naprawdę można uruchomić poniższe zapytanie

SET PAUSE ON
SET PAUSE 'Press Return to Continue'
SET PAGESIZE 60
SET LINESIZE 300
COLUMN "Tablespace Name" FORMAT A20
COLUMN "File Name" FORMAT A80
 
SELECT  Substr(df.tablespace_name,1,20) "Tablespace Name",
        Substr(df.file_name,1,80) "File Name",
        Round(df.bytes/1024/1024,0) "Size (M)",
        decode(e.used_bytes,NULL,0,Round(e.used_bytes/1024/1024,0)) "Used (M)",
        decode(f.free_bytes,NULL,0,Round(f.free_bytes/1024/1024,0)) "Free (M)",
        decode(e.used_bytes,NULL,0,Round((e.used_bytes/df.bytes)*100,0)) "% Used"
FROM    DBA_DATA_FILES DF,
       (SELECT file_id,
               sum(bytes) used_bytes
        FROM dba_extents
        GROUP by file_id) E,
       (SELECT sum(bytes) free_bytes,
               file_id
        FROM dba_free_space
        GROUP BY file_id) f
WHERE    e.file_id (+) = df.file_id
AND      df.file_id  = f.file_id (+)
ORDER BY df.tablespace_name,
         df.file_name

Od wersji 10 Oracle wprowadził coś takiego jak Oracle Data Pump do poczytania - szybszy i wygodniejszy zamiennik starego exp,którego powinieneś używać zamiast chamskiego kopiowania plików bazy. Następnie wynikowy plik pakuje się zazwyczaj (jeśli nie masz w bazie dużej ilości binarnych danych) poniżej 10%.

BTW. czy przywracałeś kiedyś bazę z tych kopiowanych plików? Czy zdajesz sobie sprawę, że jeśli przyjdzie Ci uruchomić bazę z kopii na innym środowisku to będziesz się kopał z koniem i samo przekopiowanie tych plików nic nie da.