Very Computer

by **hongying yi** » Fri, 24 May 2002 00:07:03

Hi,

I'd like to know how the Oracle can support the real-time application.
E.g, can Oracle set up the priorities for the processes, so that when
the higher-priority process came to (modify the same record), the Oracle
can roll-back the low-priority process and let the high priority process
to operate first.

Another issue is if it's possible that we can set the time-out in DB so
that if the process takes too long time, Oracle can roll it back.

Thnaks a lot in advance.

Best Regards,

Hongying Yin

by **Daniel Morga** » Fri, 24 May 2002 00:52:18

> Hi,

> I'd like to know how the Oracle can support the real-time application.
> E.g, can Oracle set up the priorities for the processes, so that when
> the higher-priority process came to (modify the same record), the Oracle
> can roll-back the low-priority process and let the high priority process
> to operate first.

> Another issue is if it's possible that we can set the time-out in DB so
> that if the process takes too long time, Oracle can roll it back.

> Thnaks a lot in advance.

> Best Regards,

> Hongying Yin

I am not aware that it can do that. I am also not aware of ever having any
need to wish that it did. And that includes work on enterprise wide
applications in a company with 200,000 employees.

You have inquired about a feature (?) that would serve no real purpose.

What you can do, if you choose, is use a profile to limit the CPU and
resources available to specific users.

Daniel Morgan

by **A.Liggin** » Fri, 24 May 2002 02:56:54

You may want to investigate Advanced Queueing, but I suspect that really
need to think about what
you are trying to do.

Most Unix's and NT aren't real time systems, so you really must come up with
a definition of what your 'real-time'
really is, what you want the system to do, and why it is real time. You may
have to investigate other databases and os's to
satisfy your application.

Oracle can't do real time because the OS can't.

Alun

> > Hi,

> > I'd like to know how the Oracle can support the real-time application.
> > E.g, can Oracle set up the priorities for the processes, so that when
> > the higher-priority process came to (modify the same record), the Oracle
> > can roll-back the low-priority process and let the high priority process
> > to operate first.

> > Another issue is if it's possible that we can set the time-out in DB so
> > that if the process takes too long time, Oracle can roll it back.

> > Thnaks a lot in advance.

> > Best Regards,

> > Hongying Yin

> I am not aware that it can do that. I am also not aware of ever having any
> need to wish that it did. And that includes work on enterprise wide
> applications in a company with 200,000 employees.

> You have inquired about a feature (?) that would serve no real purpose.

> What you can do, if you choose, is use a profile to limit the CPU and
> resources available to specific users.

> Daniel Morgan

by **RSH** » Fri, 24 May 2002 03:52:51

Hey, this is what TPM's are for, like BEA's Tuxedo. Transaction (or
Teleprocessing) Processing Monitors, all the way back to IBM CICS.

Do not ever count on process priority for this mechanism, and do not use
UNIX process scheduling / job priority in an attempt to do this with the
Oracle core.

Oracle's AQM is helpful if you wish to go that route; also both BEA and NCR
have TPMs that can coordinate transactions.

It's a lot of work, but if it is critical that first come, first served be
part of your paradigm, a TPM would be part of the answer. As well as raw
i/o, where DB writes are guaranteed and not queued through the UNIX file
management systems.

RSH.

Quote:> Hi,

> I'd like to know how the Oracle can support the real-time application.
> E.g, can Oracle set up the priorities for the processes, so that when
> the higher-priority process came to (modify the same record), the Oracle
> can roll-back the low-priority process and let the high priority process
> to operate first.

> Another issue is if it's possible that we can set the time-out in DB so
> that if the process takes too long time, Oracle can roll it back.

> Thnaks a lot in advance.

> Best Regards,

> Hongying Yin

by **Pete Sharma** » Fri, 24 May 2002 03:42:07

Quote:
>You may want to investigate Advanced Queueing, but I suspect that really
>need to think about what
>you are trying to do.

But AQ is asynchronous. What use is that in a real-time system? Or am I
missing something fundamental here?

>Most Unix's and NT aren't real time systems, so you really must come up with
>a definition of what your 'real-time'
>really is, what you want the system to do, and why it is real time. You may
>have to investigate other databases and os's to
>satisfy your application.

>Oracle can't do real time because the OS can't.

>Alun

>> > Hi,

>> > I'd like to know how the Oracle can support the real-time application.
>> > E.g, can Oracle set up the priorities for the processes, so that when
>> > the higher-priority process came to (modify the same record), the Oracle
>> > can roll-back the low-priority process and let the high priority process
>> > to operate first.

>> > Another issue is if it's possible that we can set the time-out in DB so
>> > that if the process takes too long time, Oracle can roll it back.

>> > Thnaks a lot in advance.

>> > Best Regards,

>> > Hongying Yin

>> I am not aware that it can do that. I am also not aware of ever having any
>> need to wish that it did. And that includes work on enterprise wide
>> applications in a company with 200,000 employees.

>> You have inquired about a feature (?) that would serve no real purpose.

>> What you can do, if you choose, is use a profile to limit the CPU and
>> resources available to specific users.

>> Daniel Morgan

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements;

by **Richard Foot** » Fri, 24 May 2002 13:36:58

Hi

I'm not entirely sure how/why you would apply suggest a definition of a
real-time application.

However you might want to explore the features available with the Database
Resource Manager. It provides the ability to group users into different
categories and define different levels of priority to each group. You can
also ensure that if a particular user were to use up too much resources, it
can stop that unit of work from executing in the first place.

It might be what you're looking for.

Regards

Richard

Quote:> Hi,

> I'd like to know how the Oracle can support the real-time application.
> E.g, can Oracle set up the priorities for the processes, so that when
> the higher-priority process came to (modify the same record), the Oracle
> can roll-back the low-priority process and let the high priority process
> to operate first.

> Another issue is if it's possible that we can set the time-out in DB so
> that if the process takes too long time, Oracle can roll it back.

> Thnaks a lot in advance.

> Best Regards,

> Hongying Yin

by **Pete Sharma** » Sat, 25 May 2002 00:24:46

Quote:
>Hi

>I'm not entirely sure how/why you would apply suggest a definition of a
>real-time application.

>However you might want to explore the features available with the Database
>Resource Manager. It provides the ability to group users into different
>categories and define different levels of priority to each group. You can
>also ensure that if a particular user were to use up too much resources, it
>can stop that unit of work from executing in the first place.

>It might be what you're looking for.

>Regards

>Richard

Hey, Mr Foote, good to see you contributing something useful! ;)

(For those who are concerned I'm putting s**t on Richard, I am, but then again
I've known him for years and what are friends for? ;)

One additional thing to be aware of here though is that Resource Manager only
kicks in when whatever resource you're talking about is maxed out e.g. CPU has
hit 100%.

- Show quoted text -

>> Hi,

>> I'd like to know how the Oracle can support the real-time application.
>> E.g, can Oracle set up the priorities for the processes, so that when
>> the higher-priority process came to (modify the same record), the Oracle
>> can roll-back the low-priority process and let the high priority process
>> to operate first.

>> Another issue is if it's possible that we can set the time-out in DB so
>> that if the process takes too long time, Oracle can roll it back.

>> Thnaks a lot in advance.

>> Best Regards,

>> Hongying Yin

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements;

by **Howard J. Roger** » Sat, 25 May 2002 11:27:23

> >Hi

> >I'm not entirely sure how/why you would apply suggest a definition of a
> >real-time application.

> >However you might want to explore the features available with the
Database
> >Resource Manager. It provides the ability to group users into different
> >categories and define different levels of priority to each group. You can
> >also ensure that if a particular user were to use up too much resources,
it
> >can stop that unit of work from executing in the first place.

> >It might be what you're looking for.

> >Regards

> >Richard

> Hey, Mr Foote, good to see you contributing something useful! ;)

> (For those who are concerned I'm putting s**t on Richard, I am, but then
again
> I've known him for years and what are friends for? ;)

> One additional thing to be aware of here though is that Resource Manager
only
> kicks in when whatever resource you're talking about is maxed out e.g. CPU
has
> hit 100%.

Er, not true, I think. If your CPU was maxed out, what would be the point of
having DBA group set to 100% at level 1, OLTP group set to 100% at level 2,
and the DSS group set to 100% at level 3 (which is what the SYSTEM_PLAN
does, if I recall correctly). The idea is that if I, the DBA, don't use all
of my 100% allocation, the OLTP lot get 100% of whatever I have left behind.
For that 'spill over' to happen, it is obvious that I must NOT be using 100%
of the CPU in the first place.

Therefore, Resource Manager kicks in at all times.

Regards
HJR

by **Mark Townsen** » Sat, 25 May 2002 11:50:12

Quote:> The idea is that if I, the DBA, don't use all
> of my 100% allocation, the OLTP lot get 100% of whatever I have left behind.
> For that 'spill over' to happen, it is obvious that I must NOT be using 100%
> of the CPU in the first place.

Pete is right and Howard is right. Resource Manager is active at all times -
but the plan (for CPU management) is only "in effect" when the CPU maxes out
-

If the CPU is not maxed, all groups will share whatever CPU is available on
a first come, first served basis. The aim is not to starve a group unless it
is necessary. It's the Nike principle - if you can, just do it.

If you, as the DBA group, start to use 100% of CPU, then the OLTP and DSS
group will starve.

If, you, as the DBA, only consume 80% of the CPU at level 1, then the OLTP
and DSS group will share any remaining CPU equally, providing the CPU is not
maxed out.

If the OLTP group then maxes out the remaining 20%, then the DSS group will
start to starve.

In the same way, a 60/40 split at level one does not get applied until the
CPU is at 100 %. So it's entirely possible that a consumer group with the
40% can actually use 99.999% of the CPU.

by **Richard Foot** » Sat, 25 May 2002 12:12:35

Until the CPU has maxed out as Pete suggests, there's no need for Resource
Manager to kick in as there's enough CPU to go around.

However, you've missed the more important point and that's Pete putting s**t
on me (which I must say I'm very much used to ;)

Richard

says...

> > >Hi

> > >I'm not entirely sure how/why you would apply suggest a definition of a
> > >real-time application.

> > >However you might want to explore the features available with the
> Database
> > >Resource Manager. It provides the ability to group users into different
> > >categories and define different levels of priority to each group. You
can
> > >also ensure that if a particular user were to use up too much
resources,
> it
> > >can stop that unit of work from executing in the first place.

> > >It might be what you're looking for.

> > >Regards

> > >Richard

> > Hey, Mr Foote, good to see you contributing something useful! ;)

> > (For those who are concerned I'm putting s**t on Richard, I am, but then
> again
> > I've known him for years and what are friends for? ;)

> > One additional thing to be aware of here though is that Resource Manager
> only
> > kicks in when whatever resource you're talking about is maxed out e.g.
CPU
> has
> > hit 100%.

> Er, not true, I think. If your CPU was maxed out, what would be the point
of
> having DBA group set to 100% at level 1, OLTP group set to 100% at level
2,
> and the DSS group set to 100% at level 3 (which is what the SYSTEM_PLAN
> does, if I recall correctly). The idea is that if I, the DBA, don't use
all
> of my 100% allocation, the OLTP lot get 100% of whatever I have left
behind.
> For that 'spill over' to happen, it is obvious that I must NOT be using
100%
> of the CPU in the first place.

> Therefore, Resource Manager kicks in at all times.

> Regards
> HJR

by **Pete Sharma** » Sat, 25 May 2002 14:00:14

>> The idea is that if I, the DBA, don't use all
>> of my 100% allocation, the OLTP lot get 100% of whatever I have left behind.
>> For that 'spill over' to happen, it is obvious that I must NOT be using 100%
>> of the CPU in the first place.

>Pete is right and Howard is right. Resource Manager is active at all times -
>but the plan (for CPU management) is only "in effect" when the CPU maxes out
>-

>If the CPU is not maxed, all groups will share whatever CPU is available on
>a first come, first served basis. The aim is not to starve a group unless it
>is necessary. It's the Nike principle - if you can, just do it.

>If you, as the DBA group, start to use 100% of CPU, then the OLTP and DSS
>group will starve.

>If, you, as the DBA, only consume 80% of the CPU at level 1, then the OLTP
>and DSS group will share any remaining CPU equally, providing the CPU is not
>maxed out.

>If the OLTP group then maxes out the remaining 20%, then the DSS group will
>start to starve.

>In the same way, a 60/40 split at level one does not get applied until the
>CPU is at 100 %. So it's entirely possible that a consumer group with the
>40% can actually use 99.999% of the CPU.

I couldn't have put it better myself - thanks Mark! :)

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements;

by **Yong Hua** » Sat, 25 May 2002 23:25:47

Hi, Hongying,

I've read all messages in this thread. I think the only way to achieve
your goal exactly is to write your own program that runs periodically,
say every 10 seconds. First you define priorities in a table, maybe
based on schemaname, or osuser, as in v$session. Your program checks
v$sessstat for all sessions for "CPU used by this session" and kills
those exceeding the assigned limit so they roll back. This is easy.
It's a little harder to achieve your first goal. You keep checking
v$lock and v$session_wait. If a higher priority session is waiting for
enqueue which is showned by a lower priority session, kill the latter
session.

That's a project. Once you're done, you may set up a web site for
people to download your code.

Yong Huang

> E.g, can Oracle set up the priorities for the processes, so that when
> the higher-priority process came to (modify the same record), the Oracle
> can roll-back the low-priority process and let the high priority process
> to operate first.

> Another issue is if it's possible that we can set the time-out in DB so
> that if the process takes too long time, Oracle can roll it back.

Very Computer

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle

real time app. on Oracle