GoldenLine
Zaloguj się
Mirek Kiryk

Mirek Kiryk DBA ORACLE / Unix
Administrator /
Aplication
Administrator

Temat: Migracja z 9 na 10 g ORACLE

Witam.
chcę się was podpytać czy może ktoś na forum doświadczył już takiego przejścia.

po pierwsze interesują mnie wszelkie wasze spostrzeżenia i podpowiedzi..

po drugie interesuje mnie wszystko :)

mam w tej chwili IAS i bazę na 9 oraz od jakiegoś czasu OASA 10g (sam serwer Aplikacji) no i oczywiście w planach mam przejście na 10 z bazą.
prośba o wszelkie nawet najmniejsze informację.
dzięki z góry i pozdrawiam wszystkich no i Oczywiście HAPPY NEW YEAR
Link do wypowiedziLink
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: Migracja z 9 na 10 g ORACLE

Moze to niewiele i oczywiste, ale... dwie rzeczy na ktore warto zwrocic uwage:
- zestaw wspieranych funkcjonalnosci (np. przy Oracle 10 XE nie ma m.in. indeksow bitmapowych ;-)
- zestaw zainstalowanych pakietow PL/SQL na starej bazie (byc moze sa jakies zaleznosci od pakietow systemowych, ktore na nowej nalezy doinstalowac)

pozdr
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

W szczególności zwróć uwagę na parametr OPTIMIZER_MODE, w 10g domyślnie ma on inną wartość co najczęściej powoduje załamanie w pracy systemu po migracji :)

Poza tym ... nie podałeś systemu operacyjnego. W Solarisie 10 x86 jest bug, który powoduje problem w pracy w 10g przy DELETE na tabeli z triggerem BEFORE ROW (Notka 418341.1) - warto to obejrzeć.

Jeśli aplikacja używa tabel PL/SQL indeksowanych varcharem to do patchsetu 10.2.0.3 należy obowiązkowo doinstalować patch 5890966, ewentualnie pozostać przy patchu 10.2.0.2

Z ciekawostek jest jeszcze błąd w 10.2.0.2 przy wyspecyfikowaniu jawnym ROWID w widoku ....

I mnóstwo mnóstwo innych ....

Po prostu robisz próbną migrację i trzeba to potem testować, testować i testować ...

A i tak najgorsze problemy wyjdą po wejściu w tryb produkcyjny :)
Link do wypowiedziLink
Łukasz Schabek

Łukasz Schabek Architekt Rozwiązań

Temat: Migracja z 9 na 10 g ORACLE

Jeśli używasz partycjonowanych tabel zwróć uwagę na błąd:

ORA-600 [15264] DURING DROP OF A (PARTITIONED) TABLE

Note:338953.1
Link do wypowiedziLink
Mirek Kiryk

Mirek Kiryk DBA ORACLE / Unix
Administrator /
Aplication
Administrator

Temat: Migracja z 9 na 10 g ORACLE

dzieki za wszelkie informacje.
a czy orjętuje się jaki jest "Standardowy" :) czs takiej operacji. bo ja na migrację będę miał ok 52 h i jestem ciekaw czy się wyrobię, oczywiście wpierw zrobię to na testówce ale to innego niż prod.

Dzieki
Mirek
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

a czy orjętuje się jaki jest "Standardowy" :) czs takiej

Rozmiar bazy i konfiguracja docelowego sprzętu ?
Link do wypowiedziLink
Mirek Kiryk

Mirek Kiryk DBA ORACLE / Unix
Administrator /
Aplication
Administrator

Temat: Migracja z 9 na 10 g ORACLE

ok 600 GB
Serwer SUN 5000
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

Mirek Kiryk:
ok 600 GB
Serwer SUN 5000

Ach ta precyzja :)

600GB to objętość plików ? Ona czasami nie ma nic wspólnego z objętością danych. Niejednokrotnie UNDO i TEMP zajmowały ponad 50GB ponieważ ktoś zapomniał im wyłączyć autoextend.

Jeśli to przejście z 9i na 10i, to pewnie będziesz to robił standardowym exp/imp ... przy 600GB wyrobienie się w 52h może sie
okazać problematyczne. Nie mówię, że nie ma szansy, ale czasu jest trochę mało. Jeśli do tego dojdzie ci transfer przez sieć na inną maszynę (nie napisałeś czy migracja obejmuje przeniesienie na inną maszyne) to może dojść ci w niesprzyjajacych warunkach niemal 20h na przeniesienie plików przez
kabelek 100mbit.

Przyjmij sobie teoretyczną prędkość 30MB/s przy eksporcie i 20MB/s przy imporcie. Te liczby to są teoretyczne transfery do/z na dysk przy 5letnim sprzęcie z równie starymi macierzami.

To by dawało jakieś 5-7h na eksport, a 9-12h na import. Czyli na same operacje I/O około 20h ? Ale oczywiście to teoria. Na końcu importu następuje walidacja kluczy obcych oraz włączanie indeksów co może trwać kilka razy dłużej niż sam import.

No i pamiętać o aktualizacji statystyk.

Nie pisałeś też o docelowej architekturze, ale przy tak dużej bazie odradzałbym trzymać to na ufs'ie, a raczej na raw devices lub ASM'ie.Krzysztof P. edytował(a) ten post dnia 08.01.08 o godzinie 15:14
Link do wypowiedziLink
Mirek Kiryk

Mirek Kiryk DBA ORACLE / Unix
Administrator /
Aplication
Administrator

Temat: Migracja z 9 na 10 g ORACLE

profesjonalista - aż się chce czytać .:)
myślę że jeszcze zadam ci jakieś pytanie ale dopiero jak będę znał szczegóły sprzętu i końcowej konfiguracji.
dzięki raz jeszcze.
Pozdrawiam
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

profesjonalista - aż się chce czytać .:)

A dziekuję :) Się zaczerwieniłem, hehe :)
Link do wypowiedziLink
Mirek Kiryk

Mirek Kiryk DBA ORACLE / Unix
Administrator /
Aplication
Administrator

Temat: Migracja z 9 na 10 g ORACLE

No to może ostatnie pytanie w tym wątku.

jak uwarzacie która z metod migracji jest najbardziej wydajna ????

Pozdrawiam
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

jak uwarzacie która z metod migracji jest najbardziej wydajna ?

Tak właściwie ... to co rozumiesz przez migrację ?

Przenosisz dane na osobną bazę 10g, na osobną maszynę z bazą 10g czy po prostu robisz upgrade ?

W jednej wypowiedzi uzyłes zwrotu "docelowej maszyny". Tak więc będzie to przejście na nową maszynę z bazą 10g ?

W takim przypadku mozesz to robic dwoma metodami.

Przeniesc fizycznie bazę 9i a dopiero potem uzyc "Database Upgrade Assistant".
Lub utworzyc 10g na docelowej maszynie i uzyc exp/imp.
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

Krzysztof P.:
To by dawało jakieś 5-7h na eksport, a 9-12h na import. Czyli na same operacje I/O około 20h ?

optymista :) na sunach imp/exp trwa dużo dłużej niż by się mogło wydawać, pewnie przez dziwny system plików. Dla pocieszenia 20GB DMP importował się 8h :)
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

Czyli na same operacje I/O około 20h ?

optymista :) na sunach imp/exp trwa dużo dłużej niż by się mogło wydawać, pewnie przez dziwny system plików. Dla pocieszenia 20GB DMP importował się 8h :)

Dlatego użyłem zwrotu "Ale oczywiście to teoria."

:-)
Link do wypowiedziLink
Mirek Kiryk

Mirek Kiryk DBA ORACLE / Unix
Administrator /
Aplication
Administrator

Temat: Migracja z 9 na 10 g ORACLE

dzięki raz jeszcze za słowa otuchy :) i wyczerpujące info.
Pozdrawiam
Link do wypowiedziLink
Przemysław B.

Przemysław B. Unix and Storage
Systems
Administrator, CMC
Markets

Temat: Migracja z 9 na 10 g ORACLE

Krzysztof P.:
Nie pisałeś też o docelowej architekturze, ale przy tak dużej bazie odradzałbym trzymać to na ufs'ie, a raczej na raw devices lub ASM'ie.Krzysztof P. edytował(a) ten post dnia 08.01.08 o godzinie 15:14

A to dlaczego ? Kiedyś różnica w wydajności pomiędzy raw devices a filesystemem była bardzo duża. Teraz ta różnica spadła do tak małej wielkości, że nie warto się o to bić. A zysk (management !) poprzez trzymanie plików na filesystemie jest ogromny.
Link do wypowiedziLink
Przemysław B.

Przemysław B. Unix and Storage
Systems
Administrator, CMC
Markets

Temat: Migracja z 9 na 10 g ORACLE

Arkadiusz Rosinski:
optymista :) na sunach imp/exp trwa dużo dłużej niż by się mogło wydawać, pewnie przez dziwny system plików. Dla pocieszenia 20GB DMP importował się 8h :)

A jak podczas importu wyglądały:
vmstat 1
prstat
iostat -xnzC 5

Jakie były procesory w tej maszynie ?
Link do wypowiedziLink

konto usunięte

Temat: Migracja z 9 na 10 g ORACLE

zysk (management !) poprzez trzymanie plików na filesystemie jest ogromny.

Zgadza sie, że się łatwiej tym administruje ... ale wówczas te same dane są "cache'owane" minimum dwa razy: raz przez system operacyjny, a drugi raz przez bazę.

A w przypadku ASM baza zajmuje się wszystkim.Krzysztof P. edytował(a) ten post dnia 22.01.08 o godzinie 14:25
Link do wypowiedziLink
Piotr Biel

Piotr Biel SysAdm / DBA /
System Architect

Temat: Migracja z 9 na 10 g ORACLE

Mirek Kiryk:
No to może ostatnie pytanie w tym wątku.

jak uwarzacie która z metod migracji jest najbardziej wydajna ????

Najbardziej wydajna? Znaczy najszybsza? Jesli chodzi o przeniesienie surowych danych to najszybszy bedzie dblink + CTAS ( o ile to migracja do "calkiem nowej" bazy a nie upgrade ).

--

p.
Link do wypowiedziLink
Przemysław B.

Przemysław B. Unix and Storage
Systems
Administrator, CMC
Markets

Temat: Migracja z 9 na 10 g ORACLE

Krzysztof P.:
Zgadza sie, że się łatwiej tym administruje ... ale wówczas te same dane są "cache'owane" minimum dwa razy: raz przez system operacyjny, a drugi raz przez bazę.

Jesli montujesz filesystem z cache-owaniem to owszem. Ale kto to robi ?
Proponuję zainteresować się opcją 'forcedirectio' przy ufs-ie i convosync=direct,mincache=direct przy vxfs. WTedy unikasz podwójnego cache-owania. Co więcej, użycie oracle-owej opcji 'filesystemio_options=setall' jest jeszcze lepsze, bo ceduje decyzję o dostępie cache-owanym/nie-cache-owanym (oj ten polsko-angielski ;-) ) na Oracle-a. A ten to zrobi najlepiej. Innymi słowy z 'setall' nawet na cache-owanym filesystemie będzie się dostawał bezpośrednio (raw) do plików, do których tak bedzie najlepiej.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Migracja Postgresql do Oracle




Wyślij zaproszenie do
Anuluj