Re: Oracle Design For Performance Question

  • From: Stefan Koehler <contact@xxxxxxxx>
  • To: "oracle-l@freelists org" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 28 Jan 2015 17:41:08 +0100 (CET)

Hi Michael,

> Could this be done in a single Oracle 12c database? What do you suppose would 
> be hardware requirements? Could SAS disk work or SSD disk required?

Unfortunately these questions can not be answered that easily just by looking 
at the amount of messages in average or at peak time. Just think about
message length, data types, possible attachments (stored in LOBs), etc.. What 
is your expected redo rate per sec and per transaction? Disregarding
application and data design or SQLs and their execution plans for now, the max 
data throughput is mostly (physically) limited by (single) LGWR. The
large servers can handle a tremendous amount of workload (in respective of CPU 
and I/O), but you still have such a single point of contention like the
LGWR. The next question would be: Do these messages have to be persistent (e.g. 
redo settings) at any time, etc.?

So as you can see it is impossible to answer without having a full spec of the 
business and data.

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK
 
> Michael Cunningham <napacunningham@xxxxxxxxx> hat am 28. Januar 2015 um 17:10 
> geschrieben:
> 
>  I have a question about designing a messaging app. The messaging app is 
> being moved to Oracle and receives around 20 million messages per day (231
> per second avg). I'm not sure about the # of messages at peak time, but let's 
> assume 2000 per second.
>   
>  Could this be done in a single Oracle 12c database? What do you suppose 
> would be hardware requirements? Could SAS disk work or SSD disk required?
> We may want HA as well so RAC may come up.
>   
>  I've never designed a system with this high of throughput so please bombard 
> me with your feedback.
>   
>  Also, I'm curious about scaling to 100 million messages per day.
>   
>  Another option would be to have several databases accepting the data, but 
> then we have to be able to accept that a transaction committing data to
> 2+ databases may have a failure and the data consistency may be lost. 
> Thoughts?
>   
>  --
>  Michael Cunningham
> 
--
//www.freelists.org/webpage/oracle-l


Other related posts: