FAQ
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 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
==============================

--
http://www.freelists.org/webpage/oracle-l

Search Discussions

  • Kumar Madduri at Dec 6, 2010 at 1:28 am
    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_at_googlemail.com> 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 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_at_freelists.org [mailto:
    oracle-l-bounce@freelists.org] *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
    --
    http://www.freelists.org/webpage/oracle-l
  • Subodh Deshpande at Dec 6, 2010 at 11:51 am
    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 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_at_googlemail.com> 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 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_at_freelists.org [mailto:
    oracle-l-bounce@freelists.org] *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
    ==============================

    --
    http://www.freelists.org/webpage/oracle-l

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedDec 2, '10 at 2:54p
activeDec 6, '10 at 11:51a
posts3
users2
websiteoracle.com

2 users in discussion

Subodh Deshpande: 2 posts Kumar Madduri: 1 post

People

Translate

site design / logo © 2022 Grokbase