Re: Sorry, but...
From: Noons <wizofoz2k_at_gmail.com>
Date: Sun, 15 Jan 2012 17:28:03 -0800 (PST)
Message-ID: <585f9fb2-08d0-4d2a-8cc9-9e34a3d5a5b2_at_k3g2000pbn.googlegroups.com>
On Jan 11, 12:07 am, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
> Motivation for two undo spaces is clear: you would want one small undo
> tablespace for OLTP loads and another, larger one, for reports. It
> wouldn't necessarily help with ORA-01555 because there isn't a natural
> separation of undo records. The only good solution would enable DBA to
> choose per table undo space and that would immensely complicate things.
> You cannot separate undo tablespaces by the load type. A table can be
> modified by an OLTP application and reported from by a report.
> Consistency would still need to be maintained, which means that the
> report can only see the changes committed before the query has started,
> including OLTP changes. That means that there can be no separation per
> load type, only per table separation. That might prove beneficial, but
> would probably immensely complicate coding and end up being largely
> unused because one undo tablespace is quite adequate.
Date: Sun, 15 Jan 2012 17:28:03 -0800 (PST)
Message-ID: <585f9fb2-08d0-4d2a-8cc9-9e34a3d5a5b2_at_k3g2000pbn.googlegroups.com>
On Jan 11, 12:07 am, Mladen Gogala <gogala.mla..._at_gmail.com> wrote:
>
> Motivation for two undo spaces is clear: you would want one small undo
> tablespace for OLTP loads and another, larger one, for reports. It
> wouldn't necessarily help with ORA-01555 because there isn't a natural
> separation of undo records. The only good solution would enable DBA to
> choose per table undo space and that would immensely complicate things.
> You cannot separate undo tablespaces by the load type. A table can be
> modified by an OLTP application and reported from by a report.
> Consistency would still need to be maintained, which means that the
> report can only see the changes committed before the query has started,
> including OLTP changes. That means that there can be no separation per
> load type, only per table separation. That might prove beneficial, but
> would probably immensely complicate coding and end up being largely
> unused because one undo tablespace is quite adequate.
or do the same as temp tablespaces: assign a set of schemas to each. I do multiple temps all the time, one for each application set. Why can't I do the same for undo?
Yes, sure: cross schema access could present a problem. But that's what assigning undo per schema, like we do for temp, would be for.
Just pick all relevant schemas and assign them the same undo. And another for the next set. Exactly the same as for temp. Received on Sun Jan 15 2012 - 19:28:03 CST