Re: Design/Strategy question
- From: David Roberts <big.dave.roberts@xxxxxxxxxxxxxx>
- To: mark.powell2@xxxxxx
- Date: Sun, 5 Dec 2010 14:24:03 +0000
The problem as presented leads to a no RAC conclusion.
There is the possibility that due to design limitations that the application
will no scale well on RAC.
OTOH, the biggest argument against RAC, is that with tuning a single node
can cope with the throughput.
I would suggest tuning on a single node should be the first, albeit
simplistic approach.
Active data guard has licensing implications, but only to reflect that it
is a valid competitor to RAC in some situations.
But the killer question (in my opinion) is, if copying data to a second
server works for reporting, why change things?
Dave
On Thu, Dec 2, 2010 at 5:02 PM, Powell, Mark <mark.powell2@xxxxxx> wrote:
> We have an OLTP. We do lots of reporting both as part of the MRP system
> at the application's heart, via BIRT for Web Reporting, and via Oracle
> Discoverer. Unless you are on a 32 bit Windows platform there should be
> no need to migrate the reporting to another server using a copy of the
> instance to begin wtih.
>
>
> ------------------------------
> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Kumar Madduri
> *Sent:* Thursday, December 02, 2010 9:28 AM
> *To:* oracle Freelists
> *Subject:* Design/Strategy question
>
> 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
>
Other related posts:
