Re: Design/Strategy question
- From: Subodh Deshpande <deshpande.subodh@xxxxxxxxx>
- To: ksmadduri@xxxxxxxxx
- Date: Thu, 2 Dec 2010 20:24:21 +0530
yes, if load and HA is not that much then RAC is not required
do think of keeping database on one host and appliations on another host
additioanlly implement parallel concurrent processing (PCP) then most of
your reports problem will be solved.
How much concurrent users are connected..how many concurrent requests are
processed usually in day and at peak load time.
if non RAC is the solution then did you people thought of increaseing the
capacity of existing hardware say from 2CPU to 4 CPU or say from 10GB ram to
20GB etc.
By the way there is note available on metalink which has some very good
information on sizing for Ebiz.
If all of the above had been tried and then the solution from dba is to for
RAC then it is defiantely not to have RAC in resume :)
by having an RAC your dbas are trying to reduce the job of fulltime one dba
job and that too this datatransfer, monitoring, archival gap rsolving etc is
mudan and intericate..:)
thanks!
Subodh
On 2 December 2010 19:57, Kumar Madduri <ksmadduri@xxxxxxxxx> wrote:
> Background:
> We were single node (database) Oracle Ebiz shop. There was another
> database that was created off the Ebiz database that was used for reporting
> (this reporting database was built every day).
> Management and few senior DBAs thought RAC was 'cool' and that is the way
> to go (RAC looks good on resume :) )
> In my opinion
> 1. This is a bad choice. Dont mix OLTP and Reporting.
> 2. You are accessing the same database and the same data blocks in the end
> probably. You would gain in terms of not having additional storage (prior to
> this, there were 2 databases and storage requirements were double because
> the entire database was recreated eventhough only a small set of schemas
> were used for reporting. Another bad design I think but dont want to go
> there now) but users of different requirements are competing for the same
> resources
> 3. Our ebiz is not really high availabilty (one of the reasons why rac is
> implemented is HA) because of the above way in which rac is implemented
> here. Plus, in addition, ebiz does not support TAF (in 11i. May be in R12 it
> does but I have to check). We can do application load balancing but we are
> not even doing that
> 4. When CPU is pegged on OLTP (ebiz) node, we are trying to move some of
> the applications to node 2. But unless done properly this can be disastrous
> (example, users go to node 2 for login (pls application controlled through
> wdbsvr or dads.conf and again come back to node 1 for launching forms or
> open an apex application using pls goes to node2 and user does some DML on
> the apex application going to node 2 and comes back to the main page and
> decides to launch forms trying to use the data from the apex application
> which uses node 1 )
>
> Proposed solution:
> 1. un-rac (go back to non-rac ). RAC is not the right solution for our
> requirements because of our requirements to have a ebiz oltp application and
> a reporting database. DBAs are opposed to this idea because it is viewed as
> a step backward and viewed as chickening out from RAC.
> 2, For reporting requirement
> (a) use streams
> (b) use active data guard (additional cost)
> (c) use Materialized views which take data off the primary ebiz database
> because reporting dont need to use all the 200 + schemas that exist in
> oracle applications and may need 4 or 5 schemas. Developers/Users should be
> able to give the requirements on exactly what tables are required.
> (d) Change data capture.
>
> Are there any other solutions that can be suggested. I wanted to put my
> ideas and get a thought from the list before I go to management and propose
> my solution (regardless of outcome).
>
> Thank you for your time
> Kumar
>
--
==============================
DO NOT FORGET TO SMILE TODAY
==============================
Other related posts:
