Radosław Mańkowski

IBM Principal Consultant - Power and Storage HA&DR architecture, database and analytics solutions

Wypowiedzi

• Wszystko
• Tylko fora

• 
  Wpis na grupie Oracle DBA w temacie RAC: o jeden rm za daleko :)

  10.06.2010, 18:21

  mozna bez problemu po prostu z crsctl usun VD z force a potem dodaj z force i po sprawie (wtedy przeformatuje na nowo VD).Radosław Mańkowski edytował(a) ten post dnia 10.06.10 o godzinie 18:34

• 
  Wpis na grupie Bazy Danych w temacie oracle - getting started

  8.05.2008, 12:40

  Piotr B.:
  

  Radosław Mańkowski:
  

  Olbrzymim zagrożeniem jest niestety w takich operacjach jest optymalizator. Osobiście podczas migracji hurtowni (bagatela 8TB) na inny serwer oraz storage spotkałem się z przypadkiem iż zwykłe dzielenie podczas liczenia agregatów powodowało nieskończoną pętlę. Rozwiązaniem był patch oczywiście, ale wymagał pełnej rekreacji bazy. Wcześniejsze testy tego nie wykazały ze względu na ilość danych(partycja). Co do aplikacji to należy sprawdzić czy statystki wykonywane automatycznie nie wpłyną na działanie aplikacji - nie jest to miła niespodzianka, zwłaszcza w oracle 10g w 11g jest to bardzo poprawione. W razie jakiś pytań służę radą :)

  
  Trzeba było zastosować SharePlexa :)))

  
  
  Shareplex na 8 TB :) Przy okazji była przeprowadza pełna rekonfiguracja tablespaces oraz nazw :)

• 
  Wpis na grupie Bazy Danych w temacie oracle - getting started

  8.05.2008, 12:28

  Katarzyna Bielecka:
  

  Bartosz Zieliński:
  ---"Poza tym, może trochę głupi przykład - ale po co uczyć się statspacka, nie lepiej od razu przyzwyczaić się do AWRa?"---
  
  Idac tym tokiem rozumowania mozna pomyslec: po co sie uczyc dodawac skoro kalkulator mam w komorce ?

  
  Ale AWR już jest na 10ce, a statspaka trzeba sobie dorzucić.
  

  
  Ktos kto zrozumie statspacka nie bedzie mial problemu ze zrozumieniem AWR czy ADDM albo TKPROF.

  
  No co ma do tego tkprof to już nie wiem :) Jest już od 7ki :)
  

  A ktos kto widzial w zyciu tylko 10g a przyjdzie mu pracowac na 9i czy 8i (lub jeszcze nizej) rozlozy rece bo statspacka nie bedzie znal a czym badziej nie bedzie umial przeczytac to co statspack splodzi.

  
  Albo odpali metalinka, wpisze statspack, znajdzie notkę, przeczyta i sobie poradzi.
  

  A co do 9i jeszcze jest wspierane. Wlasnie pojawil sie niedawno CPUApr2008 i nadal jest dostepny dla 9.2.0.8.

  
  Wiem, ostatnio aplikowalam.
  Ale jeżeli firma nie ma ECSa i natrafi na bug, to już jej nikt tego nie naprawi.
  

  A co do migrowania z 9i na 10g to jest nieprawda ze duze korporacje chca miec wszystko "najnowsze". Skoro maja 9.2.0.8 i wszystko dziala bez zarzutu to po jaka cholere maja upgradowac do
  10.2.0.3 ?
  Mam klienta ktory ma jeszcze 8.1.7.4 i wszystko dziala, aplikacja
  dziala bez zarzutu.
  

  W mojej korpo bazki są migrowane, albo migracja jest w planach, chyba że po zmigrowaniu wystąpiły jakieś problemy.
  Nie twierdzę, że stare wersje bazy są złe, ale powoli przestają być politycznie poprawne.

  
  Co do kwestii migracji...
  Nalezy rozpatrzyć nastepujące kwestie:
  1. Hardware( czy warto go wymieniać)
  2. Storage
  3. Co da nam wersja do której chcemy się zmigrować?
  4. Wirtualizacja i ewentualne oszczędności licencencyjne
  
  Olbrzymim zagrożeniem jest niestety w takich operacjach jest optymalizator. Osobiście podczas migracji hurtowni (bagatela 8TB) na inny serwer oraz storage spotkałem się z przypadkiem iż zwykłe dzielenie podczas liczenia agregatów powodowało nieskończoną pętlę. Rozwiązaniem był patch oczywiście, ale wymagał pełnej rekreacji bazy. Wcześniejsze testy tego nie wykazały ze względu na ilość danych(partycja). Co do aplikacji to należy sprawdzić czy statystki wykonywane automatycznie nie wpłyną na działanie aplikacji - nie jest to miła niespodzianka, zwłaszcza w oracle 10g w 11g jest to bardzo poprawione. W razie jakiś pytań służę radą :)