Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Oracle 11 - jak zmniejszyc rozrośnięte przestrzenie tabel
1,630 views
Skip to first unread message
rgrzes
May 8, 2013, 7:39:05 AM5/8/13
to
Witam,
Baza urosła do 800 GB... głównie przez kilka tabel z blobami, teraz te bloby zostały usunięte z rekordów, ale przestrzenie wiadomo - zostały duże...
jak bezpiecznie je poprzycinać ?
ja znam tylko metodę taka:
sprawdzić co ile zajmuje, np:
select DE.owner, DE.tablespace_name, DE.segment_type, DE.Segment_name, DDF.file_name, DDF.file_id, SUM(DE.Bytes)/1024/1024/1024
from dba_extents DE, dba_data_files DDF
where DE.tablespace_name = 'MY_TBS' and
DDF.file_id = DE.file_id
group by DE.owner, DE.tablespace_name, DE.segment_type, DE.segment_name, DDF.file_name, DDF.file_id
order by 7 desc
pozniej po kolei próbować:
ALTER DATABASE DATAFILE '_____' RESIZE __G jakąś rozsądną wartością
ale to oczywiście na ogół nie idzie od razu bo cos wysoko w extentach blokuj, wiec:
select * from dba_extents
where tablespace_name = 'MY_TBS' and file_id = 10
order by block_id desc
i to co blokuje przenieść np do jakiejś tymczasowej przestrzeni,
pozniej zmienic rozmiar pliku ile sie da, zmeinic znow przestrzen i tymczasowa usunac... uffff, straszna rzezba... poza tym nie bardzo mam juz miejsce na ta tymczasowa przestrzen...
znacie jakies sensowniejsze i bezpieczniejsze rozwiazanie ?
pozdrawiam
Robert
Baza urosła do 800 GB... głównie przez kilka tabel z blobami, teraz te bloby zostały usunięte z rekordów, ale przestrzenie wiadomo - zostały duże...
jak bezpiecznie je poprzycinać ?
ja znam tylko metodę taka:
sprawdzić co ile zajmuje, np:
select DE.owner, DE.tablespace_name, DE.segment_type, DE.Segment_name, DDF.file_name, DDF.file_id, SUM(DE.Bytes)/1024/1024/1024
from dba_extents DE, dba_data_files DDF
where DE.tablespace_name = 'MY_TBS' and
DDF.file_id = DE.file_id
group by DE.owner, DE.tablespace_name, DE.segment_type, DE.segment_name, DDF.file_name, DDF.file_id
order by 7 desc
pozniej po kolei próbować:
ALTER DATABASE DATAFILE '_____' RESIZE __G jakąś rozsądną wartością
ale to oczywiście na ogół nie idzie od razu bo cos wysoko w extentach blokuj, wiec:
select * from dba_extents
where tablespace_name = 'MY_TBS' and file_id = 10
order by block_id desc
i to co blokuje przenieść np do jakiejś tymczasowej przestrzeni,
pozniej zmienic rozmiar pliku ile sie da, zmeinic znow przestrzen i tymczasowa usunac... uffff, straszna rzezba... poza tym nie bardzo mam juz miejsce na ta tymczasowa przestrzen...
znacie jakies sensowniejsze i bezpieczniejsze rozwiazanie ?
pozdrawiam
Robert
rgrzes
May 9, 2013, 4:59:54 AM5/9/13
to
Lucyna Witkowska
May 9, 2013, 9:05:51 AM5/9/13
to
rgrzes <rgr...@gmail.com> napisa?:
> Baza uros�a do 800 GB... g��wnie przez kilka tabel z blobami,
> teraz te bloby zosta�y usuni�te z rekord�w, ale przestrzenie wiadomo -
> zosta�y du�e...
> jak bezpiecznie je poprzycinaďż˝ ?
No niestety te bloby nawet usni�te dalej "trzymaj�" przestrze�.
Rozwiazaniem mogloby byďż˝:
ALTER TABLE test_lob MODIFY LOB (image) (SHRINK SPACE);
tutaj jest o tym artykul:
http://www.idevelopment.info/data/Oracle/DBA_tips/LOBs/LOBS_85.shtml
Pozdrowienia,
LW
> Baza uros�a do 800 GB... g��wnie przez kilka tabel z blobami,
> teraz te bloby zosta�y usuni�te z rekord�w, ale przestrzenie wiadomo -
> zosta�y du�e...
> jak bezpiecznie je poprzycinaďż˝ ?
No niestety te bloby nawet usni�te dalej "trzymaj�" przestrze�.
Rozwiazaniem mogloby byďż˝:
ALTER TABLE test_lob MODIFY LOB (image) (SHRINK SPACE);
tutaj jest o tym artykul:
http://www.idevelopment.info/data/Oracle/DBA_tips/LOBs/LOBS_85.shtml
Pozdrowienia,
LW
Maseł
May 9, 2013, 9:05:34 AM5/9/13
to
W dniu 2013-05-09 10:59, rgrzes pisze:
> chyba jednak zrobi� metod�: backup (na wszelki wypadek) a p�niej exp/imp full db - z automatu 'poskurcza' wszystkie przestrzenie...
Witaj
exp/imp jest dobrym pomyslem
zawsze tez mozesz zastosowac stare rozwiazanie "alter table move" do
innej (roboczej) przestrzeni, i tak wszystkie tabelki po kolei, pozniej
drop/create tej Twojej ulubionej i powrot z danymi do tej Twojej
wybranej przestrzeni...
Pozdrawiam
Mariusz Masewicz
> chyba jednak zrobi� metod�: backup (na wszelki wypadek) a p�niej exp/imp full db - z automatu 'poskurcza' wszystkie przestrzenie...
Witaj
exp/imp jest dobrym pomyslem
zawsze tez mozesz zastosowac stare rozwiazanie "alter table move" do
innej (roboczej) przestrzeni, i tak wszystkie tabelki po kolei, pozniej
drop/create tej Twojej ulubionej i powrot z danymi do tej Twojej
wybranej przestrzeni...
Pozdrawiam
Mariusz Masewicz
rgrzes
May 13, 2013, 10:40:08 AM5/13/13
to
Nie wiem czy pamiętasz ale kiedyś przeprowadzałeś u nas szkolenie :)))
Właśnie zrobiłem starą metodą z move i resize na plikach, zauważyłem jednak jedną cienkość... Jak mam tablespace w którym jest sporo miejsca wolnego a zarezerwowanego już przez plik tablespace (rozmiar pliku większy niż rozmiar zajętych ekstentów w nim) to Oracle zamiast upychać dane w to wolne miejsce często niepotrzebnie rozszerza sobie pliki które są rozszerzalne (nie robi tak tylko jeśli nie są autoextensible) - efekt jest taki że one niepotrzebnie się rozrastają... Przypuszczam iż robi tak dlatego że ważniejsza jest szybkość niż oszczędność miejsca, ale jak dla mnie to nie za fajne -> w efekcie bazy testowe z duplikacji są duże, backup też (bo mam SE a nie EE)...
Jedyne co wymyśliłem to ustawienie w plikach przestrzeni autoextensible na false, a żeby kontrolować to napisanie joba który będzie sprawdzał co jakiś czas czy nie ma za mało zapasu wolnej przestrzeni i automatycznie zwiększa o tyle ile chcę...
A masz jakiś sposób na zmniejszenie rozmiaru tbs SYSTEM które się rozrosło przez włączony autyt ? Trochę się obawiam starą metodą move/resize działać na tbs SYSTEM :)
pozdrawiam
Robert
Maseł
May 13, 2013, 5:14:22 PM5/13/13
to
W dniu 2013-05-13 16:40, rgrzes pisze:
> Cze�� Mariusz,
>
> Nie wiem czy pami�tasz ale kiedy� przeprowadza�e� u nas szkolenie :)))
pamietam :-)
> W�a�nie zrobi�em star� metod� z move i resize na plikach, zauwa�y�em jednak jedn� cienko��... Jak mam tablespace w kt�rym jest sporo miejsca wolnego a zarezerwowanego ju� przez plik tablespace (rozmiar pliku wi�kszy ni� rozmiar zaj�tych ekstent�w w nim) to Oracle zamiast upycha� dane w to wolne miejsce cz�sto niepotrzebnie rozszerza sobie pliki kt�re s� rozszerzalne (nie robi tak tylko je�li nie s� autoextensible) - efekt jest taki �e one niepotrzebnie si� rozrastaj�... Przypuszczam i� robi tak dlatego �e wa�niejsza jest szybko�� ni� oszcz�dno�� miejsca, ale jak dla mnie to nie za fajne -> w efekcie bazy testowe z duplikacji s� du�e, backup te� (bo mam SE a nie EE)...
Dokladnie - prawda znana od wersji 7 oracla. Mozesz jeszcze zobaczyc co
sie dzieje jak przestrzen jest "wieloplikowa" i wszystkie pliki maja
autoextend (ale to tylko potwierdzi Twoje spostrzezenia).
> Jedyne co wymy�li�em to ustawienie w plikach przestrzeni autoextensible na false, a �eby kontrolowa� to napisanie joba kt�ry b�dzie sprawdza� co jaki� czas czy nie ma za ma�o zapasu wolnej przestrzeni i automatycznie zwi�ksza o tyle ile chc�...
ojatam - dyski teraz tanie, wiec po co sie przejmowac takimi glupotami
> A masz jaki� spos�b na zmniejszenie rozmiaru tbs SYSTEM kt�re si� rozros�o przez w��czony autyt ? Troch� si� obawiam star� metod� move/resize dzia�a� na tbs SYSTEM :)
No coz - audyt trail w przestrzeni tabel innej niz system jest
"unsupported", natomiast w systemowej jest - jak sam zauwazyles - dosc
kiepskim pomyslem. Niestety jedyny znany mi sposob na zmniejszenie
systemowej przestrzeni to exp/imp (import oczywiscie do nowej, pustej
bazy). Ewentualnie skorzystac z "transportable tablespaces" i podpiac
wszystkie przestrzenie z "felernej" bazy do nowej bazy danych (takiej z
malutkim systemem).
Na przyszlosc pozostaje Ci albo - audyt w systemowej plus job, ktory
regularnie wyrzuca logi z audytu "gzieindziej", albo rozwiazanie
niesupportowane. Jakis czas temu w bazie, gdzie audytowalo sie wszystko
co sie da wdrazalem rozwiazanie z audit trailem partycjonowanym po
czasie (bo to oracle 11g byl) i do tego w przestrzeni innej niz
systemowa. Jedynie za rada oslawionego "Interneta" zadbalem, zeby na
czas aplikowania oraclowych poprawek system widzial poprawnego,
supportowanego audit traila.
Pozdrawiam
Mariusz Masewicz
> Cze�� Mariusz,
>
> Nie wiem czy pami�tasz ale kiedy� przeprowadza�e� u nas szkolenie :)))
pamietam :-)
> W�a�nie zrobi�em star� metod� z move i resize na plikach, zauwa�y�em jednak jedn� cienko��... Jak mam tablespace w kt�rym jest sporo miejsca wolnego a zarezerwowanego ju� przez plik tablespace (rozmiar pliku wi�kszy ni� rozmiar zaj�tych ekstent�w w nim) to Oracle zamiast upycha� dane w to wolne miejsce cz�sto niepotrzebnie rozszerza sobie pliki kt�re s� rozszerzalne (nie robi tak tylko je�li nie s� autoextensible) - efekt jest taki �e one niepotrzebnie si� rozrastaj�... Przypuszczam i� robi tak dlatego �e wa�niejsza jest szybko�� ni� oszcz�dno�� miejsca, ale jak dla mnie to nie za fajne -> w efekcie bazy testowe z duplikacji s� du�e, backup te� (bo mam SE a nie EE)...
Dokladnie - prawda znana od wersji 7 oracla. Mozesz jeszcze zobaczyc co
sie dzieje jak przestrzen jest "wieloplikowa" i wszystkie pliki maja
autoextend (ale to tylko potwierdzi Twoje spostrzezenia).
> Jedyne co wymy�li�em to ustawienie w plikach przestrzeni autoextensible na false, a �eby kontrolowa� to napisanie joba kt�ry b�dzie sprawdza� co jaki� czas czy nie ma za ma�o zapasu wolnej przestrzeni i automatycznie zwi�ksza o tyle ile chc�...
ojatam - dyski teraz tanie, wiec po co sie przejmowac takimi glupotami
> A masz jaki� spos�b na zmniejszenie rozmiaru tbs SYSTEM kt�re si� rozros�o przez w��czony autyt ? Troch� si� obawiam star� metod� move/resize dzia�a� na tbs SYSTEM :)
No coz - audyt trail w przestrzeni tabel innej niz system jest
"unsupported", natomiast w systemowej jest - jak sam zauwazyles - dosc
kiepskim pomyslem. Niestety jedyny znany mi sposob na zmniejszenie
systemowej przestrzeni to exp/imp (import oczywiscie do nowej, pustej
bazy). Ewentualnie skorzystac z "transportable tablespaces" i podpiac
wszystkie przestrzenie z "felernej" bazy do nowej bazy danych (takiej z
malutkim systemem).
Na przyszlosc pozostaje Ci albo - audyt w systemowej plus job, ktory
regularnie wyrzuca logi z audytu "gzieindziej", albo rozwiazanie
niesupportowane. Jakis czas temu w bazie, gdzie audytowalo sie wszystko
co sie da wdrazalem rozwiazanie z audit trailem partycjonowanym po
czasie (bo to oracle 11g byl) i do tego w przestrzeni innej niz
systemowa. Jedynie za rada oslawionego "Interneta" zadbalem, zeby na
czas aplikowania oraclowych poprawek system widzial poprawnego,
supportowanego audit traila.
Pozdrawiam
Mariusz Masewicz
rgrzes
May 14, 2013, 5:27:55 AM5/14/13
to
W dniu poniedziałek, 13 maja 2013 23:14:22 UTC+2 użytkownik Maseł napisał:
> W dniu 2013-05-13 16:40, rgrzes pisze:
>
> > Cze�� Mariusz,
>
> >
>
> > Nie wiem czy pami�tasz ale kiedy� przeprowadza�e� u nas szkolenie :)))
>
>
>
> pamietam :-)
>
>
>
> > W�a�nie zrobi�em star� metod� z move i resize na plikach, zauwa�y�em jednak jedn� cienko��... Jak mam tablespace w kt�rym jest sporo miejsca wolnego a zarezerwowanego ju� przez plik tablespace (rozmiar pliku wi�kszy ni� rozmiar zaj�tych ekstent�w w nim) to Oracle zamiast upycha� dane w to wolne miejsce cz�sto niepotrzebnie rozszerza sobie pliki kt�re s� rozszerzalne (nie robi tak tylko je�li nie s� autoextensible) - efekt jest taki �e one niepotrzebnie si� rozrastaj�... Przypuszczam i� robi tak dlatego �e wa�niejsza jest szybko�� ni� oszcz�dno�� miejsca, ale jak dla mnie to nie za fajne -> w efekcie bazy testowe z duplikacji s� du�e, backup te� (bo mam SE a nie EE)...
>
>
>
> Dokladnie - prawda znana od wersji 7 oracla. Mozesz jeszcze zobaczyc co
>
> sie dzieje jak przestrzen jest "wieloplikowa" i wszystkie pliki maja
>
> autoextend (ale to tylko potwierdzi Twoje spostrzezenia).
>
>
dokladnie, efekt podobny, rozszerza po kolei pliki... :)
> W dniu 2013-05-13 16:40, rgrzes pisze:
>
> > Cze�� Mariusz,
>
> >
>
> > Nie wiem czy pami�tasz ale kiedy� przeprowadza�e� u nas szkolenie :)))
>
>
>
> pamietam :-)
>
>
>
> > W�a�nie zrobi�em star� metod� z move i resize na plikach, zauwa�y�em jednak jedn� cienko��... Jak mam tablespace w kt�rym jest sporo miejsca wolnego a zarezerwowanego ju� przez plik tablespace (rozmiar pliku wi�kszy ni� rozmiar zaj�tych ekstent�w w nim) to Oracle zamiast upycha� dane w to wolne miejsce cz�sto niepotrzebnie rozszerza sobie pliki kt�re s� rozszerzalne (nie robi tak tylko je�li nie s� autoextensible) - efekt jest taki �e one niepotrzebnie si� rozrastaj�... Przypuszczam i� robi tak dlatego �e wa�niejsza jest szybko�� ni� oszcz�dno�� miejsca, ale jak dla mnie to nie za fajne -> w efekcie bazy testowe z duplikacji s� du�e, backup te� (bo mam SE a nie EE)...
>
>
>
> Dokladnie - prawda znana od wersji 7 oracla. Mozesz jeszcze zobaczyc co
>
> sie dzieje jak przestrzen jest "wieloplikowa" i wszystkie pliki maja
>
> autoextend (ale to tylko potwierdzi Twoje spostrzezenia).
>
>
>
> > Jedyne co wymy�li�em to ustawienie w plikach przestrzeni autoextensible na false, a �eby kontrolowa� to napisanie joba kt�ry b�dzie sprawdza� co jaki� czas czy nie ma za ma�o zapasu wolnej przestrzeni i automatycznie zwi�ksza o tyle ile chc�...
>
>
>
> ojatam - dyski teraz tanie, wiec po co sie przejmowac takimi glupotami
>
>
>
> > A masz jaki� spos�b na zmniejszenie rozmiaru tbs SYSTEM kt�re si� rozros�o przez w��czony autyt ? Troch� si� obawiam star� metod� move/resize dzia�a� na tbs SYSTEM :)
>
>
>
> No coz - audyt trail w przestrzeni tabel innej niz system jest
>
> "unsupported", natomiast w systemowej jest - jak sam zauwazyles - dosc
>
> kiepskim pomyslem. Niestety jedyny znany mi sposob na zmniejszenie
>
> systemowej przestrzeni to exp/imp (import oczywiscie do nowej, pustej
>
> bazy). Ewentualnie skorzystac z "transportable tablespaces" i podpiac
>
> wszystkie przestrzenie z "felernej" bazy do nowej bazy danych (takiej z
>
> malutkim systemem).
>
>
>
> Na przyszlosc pozostaje Ci albo - audyt w systemowej plus job, ktory
>
> regularnie wyrzuca logi z audytu "gzieindziej", albo rozwiazanie
>
> niesupportowane. Jakis czas temu w bazie, gdzie audytowalo sie wszystko
>
> co sie da wdrazalem rozwiazanie z audit trailem partycjonowanym po
>
> czasie (bo to oracle 11g byl) i do tego w przestrzeni innej niz
>
> systemowa. Jedynie za rada oslawionego "Interneta" zadbalem, zeby na
>
> czas aplikowania oraclowych poprawek system widzial poprawnego,
>
> supportowanego audit traila.
>
>
zrobie kiedys na spokojnie exp/imp i bedzie git -> tez tylko ten sposob znalem
>
> Pozdrawiam
>
>
>
> Mariusz Masewicz
pozdrawiam
Robert
0 new messages