[Building Sakai] Experience with Oracle RAC

[Stephen Jaegle]

URI is in the process of switching its Oracle databases to use Oracle RAC.
The previous postings in this thread do not bode well, but also go back to
2009. Does anyone have any more current experience with RAC and Sakai that
they would like to share?

Thanks,

Steve Jaegle
Lead Programmer/Analyst
University Computing Systems
University of Rhode Island


Jon Gorrono wrote
> ASSM (auto segment space management)... are we mincing words?
> 
> it consistently got it wrong, and we could not turn it off. We could
> not turn it off on RAC, without RAC, we can.
> 
> ...
> 
> We had some pretty lofty experts (FMP) looking at it... we get pretty
> good response from Oracle when we need help ... 
> 
> 
>>
>> In regards to segment space management,  RAC environments and really all
>> db environments should use ASSM (auto segment space management).  It was
>> introduced in 9i and it became the DEFAULT in 10gR2.
> 
> Maybe one should use it, but it seemed to be killing us
> 
> We found a tripartite correlation over time among the level of
> fragmentation of tablespaces, the cost calculations, the deterioration
> in performance.
> 
>>
>> In this release (10gR2), Automatic Segment Space Management (ASSM) is
>> enabled by default. The tablespace attribute, Segment Space Management,
>> now has the default value of AUTO.
>>
>> All new tablespaces created using default attributes benefit from the
>> manageability and performance advantages of ASSM over Freelist-based
>> space management.
>>
>> This has nothing to do with RAC though.
> 
> Except that with RAC, AFAIK, you can't turn it off.
> 
> ...
> 
>>
>>
>> --- On Wed, 10/7/09, Jon Gorrono <

> jpgorrono@

> > wrote:
>>
>>> From: Jon Gorrono <

> jpgorrono@

> >
>>> Subject: Re: [Building Sakai] Experience with Oracle RAC
>>> To: 

> mame-awa.diop@

>>> Cc: "sakai-dev" <

> sakai-dev at .sakaiproject

> >
>>> Date: Wednesday, October 7, 2009, 7:30 PM
>>> Did you say Oracle RAC? Slowly I
>>> turned... step by step....
>>> (http://www.youtube.com/watch?v=9pQii1L8fGk)
>>>
>>> We have some cool headed doc's about our experiences with
>>> rac in out
>>> confluence, which I can dig out if you would like the
>>> details.
>>>
>>> In contrast I can give you a sense of our experience with
>>> RAC: it was
>>> not good. There were to issues that bubbled to the top of
>>> the heap and
>>> lingered long enough for us to decide to give ip on the
>>> RAC
>>>
>>> 1). a) the RAC insists on managing segment fragmentation
>>> and b) it sux at it
>>>  - we would setup our tables views and mviews and a bunch
>>> of nicely
>>> performing indexes and the RAC would split up the table and
>>> index
>>> segments until the performance tanked. And we coul dnot
>>> turn it off
>>> even though it appeared that we had declaratively
>>> 2) There was a lot of speculation that the number of small
>>> tables used
>>> in sakai for simple low data lookups would harm performance
>>> in a RAC
>>> environment due to the added overhead for synch'ing those
>>> tables over
>>> the RAC private network... but we never tested this: #1
>>> killed the
>>> project.
>>>
>>> On Tue, Oct 6, 2009 at 11:12 AM, Mame-Awa Diop <

> mame-awa.diop@

> >
>>> wrote:
>>> > Hello everybody,
>>> >
>>> > I was wondering if you guys using Oracle as a database
>>> for Sakai and using a
>>> > clustering tool like Oracle RAC has had any special
>>> behavior with the
>>> > clustering tool ? Is there something worth monitoring
>>> with the clustering
>>> > tool ?
>>> > If you use another clustering tool, your input would
>>> be appreciated also.
>>> >
>>> >
>>> > Cheers,
>>> >
>>> > --
>>> >
>>> > Mame Awa Diop
>>> > Analyste programmeur
>>> > Service de gestion des technologies et de
>>> l'information
>>> > HEC Montréal
>>> > 3000, chemin de la côte-Sainte-Catherine
>>> > Montréal  (Québec)   H3T 2A7
>>> >
>>> > GTI: 514.340.6000 #2029 - Bureau 3.755
>>> > Projet OpenSyllabus: 514.340.6776 - Bureau 4.521
>>> > 5255, avenue Decelles
>>> > Montréal (Québec) Canada
>>> > H3T 2B
>>> >
>>> > Télécopieur: (514)340-5637
>>> >
>>> > _______________________________________________
>>> > sakai-dev mailing list
>>> > 

> sakai-dev at .sakaiproject

>>> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> >
>>> > TO UNSUBSCRIBE: send email to 

> sakai-dev-unsubscribe at .sakaiproject

>>> > with a subject of "unsubscribe"
>>> >
>>>
>>>
>>>
>>> --
>>> Jon Gorrono
>>> PGP Key: 0x5434509D -
>>> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
>>> Thawte Notary -
>>> https{www.thawte.com/cgi/personal/wot/directory.exe?node=312}
>>> GSWoT Introducer - {GSWoT:US75 5434509D Jon P. Gorrono
>>> 
> <jpgorrono - gswot.org>
> }
>>> http{ats.ucdavis.edu}
>>>
>>> Sent from Davis, CA, United States
>>> _______________________________________________
>>> sakai-dev mailing list
>>> 

> sakai-dev at .sakaiproject

>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to 

> sakai-dev-unsubscribe at .sakaiproject

>>> with a subject of "unsubscribe"
>>>
>>
>>
>>
>>
> 
> 
> 
> -- 
> Jon Gorrono
> PGP Key: 0x5434509D -
> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
> Thawte Notary -
> https{www.thawte.com/cgi/personal/wot/directory.exe?node=312}
> GSWoT Introducer - {GSWoT:US75 5434509D Jon P. Gorrono 
> <jpgorrono - gswot.org>
> }
> http{ats.ucdavis.edu}
> 
> Sent from Davis, CA, United States
> _______________________________________________
> sakai-dev mailing list

> sakai-dev at .sakaiproject

> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to 

> sakai-dev-unsubscribe at .sakaiproject

>  with a subject of "unsubscribe"





--
View this message in context: http://sakai-project-mail-list-archives.1343168.n2.nabble.com/Building-Sakai-Experience-with-Oracle-RAC-tp3776774p7595871.html
Sent from the DG: Development / Buidling Sakai (sakai-dev at collab.sakaiproject.org) mailing list archive at Nabble.com.