Re: Design/Strategy question
- From: Kumar Madduri <ksmadduri@xxxxxxxxx>
- To: Job Miller <jobmiller@xxxxxxxxx>
- Date: Mon, 6 Dec 2010 04:49:58 -0800
Hi Job
Here are my responses
For the reporting environment, do the users need the full capability of
EBS? EBS didn't support being run against a full logical standby (logically
replicated environment) I didn't think.
>>> No, the reporting environment does not need the entire EBS capability.
The reporting database bases off their reports based on a few schemas and
earlier we used to replicate the entire reporting database (even that was
nto required if somebody did a proper analysis of the tables they actually
required and built a schema off that).
>> The reason why I think it is bad is
(a) Mixture of OLTP and DSS loads to the same database
(b) During day time, DSS reports are queried no builds happen. Pretty much
node2 is idle and node 1 is used by online users.
(c) Application partitioning is not done at the app level (by setting
profile options) or database level (through services for example).
(d) No PCP configuration is used (PCP could also be used in non-rac but
atleast if we used PCP and redirectred few long running concurrent requests
to node2 or node1, it would be nice).
>> Some of the modules of ebiz do support streams completly (I think
irecruitment does). But that is not a requirement for us as well.
Thank you
Kumar
On Mon, Dec 6, 2010 at 4:04 AM, Job Miller <jobmiller@xxxxxxxxx> wrote:
> What were the symptons/problems associated with the move to RAC?
>
> Within a cluster, there are many configurations possible to support the
> layout of various databases in that cluster.
>
> It sounds like you think it will be bad, but you don't state why.
>
> RAC just pools resources in a cluster. A large single database across more
> than one server, may support both transactional and reporting like
> workloads.
>
> For the reporting environment, do the users need the full capability of
> EBS? EBS didn't support being run against a full logical standby (logically
> replicated environment) I didn't think.
>
> So Streams/CDC/Golden Gate could logically replicate certain data for
> reporting, but I wouldn't anticipate getting a configuration going that
> supports the actual use of EBS against the logical reporting environment.
>
> EBS can't run against an Active DG environment either. In 12i (latest
> patch), with a 11gR2 DB, you can partially offload certain concurrent
> manager reporting, but it isn't everything because all writes have to be
> redirected back to the primary and EBS records lots of things even for
> simple reporting purposes.
>
> ------------------------------
> *From:* Subodh Deshpande <deshpande.subodh@xxxxxxxxx>
> *To:* ksmadduri@xxxxxxxxx
> *Cc:* oracle Freelists <Oracle-L@xxxxxxxxxxxxx>
> *Sent:* Mon, December 6, 2010 6:51:08 AM
> *Subject:* Re: Design/Strategy question
>
> I think you are hurrying...
>
> teup you may not need RAC but what to do with the present configurations.
>
> I belive if oracle apps has to be installed or if it need to be migrated to
> RAC from single node there is different note available on MOS, cehck whether
> that is followed or not.if that is followed then you need to un RAC. In this
> world there are lot of configurations with RAC and apps, how these people
> are using it :)
> Thanks!
> Subodh
> On 6 December 2010 06:58, Kumar Madduri <ksmadduri@xxxxxxxxx> wrote:
>
>> Hello All:
>> Thank you for the responses so far.
>> yes exactly that was my point. We dont need RAC and we went ahead with
>> rac when there was no requirement and we have so much bad code that the
>> problems with single node just compounded when we added a 2 node rac
>> (expected lines). So my suggestions now is to un-rac (go back to single
>> node) and implemement streams or active data guard or CDC.
>> I presented our scenario and asking for opinions just to make sure that
>> I was thinking right and was not stirring any hornets nest.
>>
>> Thank you
>> Kumar
>>
>> On Sun, Dec 5, 2010 at 6:24 AM, David Roberts <
>> big.dave.roberts@xxxxxxxxxxxxxx> wrote:
>>
>>> 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
>>>>
>>>
>>>
>>
>
>
> --
> ==============================
> DO NOT FORGET TO SMILE TODAY
> ==============================
>
>
Other related posts:
