Re: 10g Rel 2 Problems, Possible DOS threat????

From: Bob Jones <email_at_me.not>
Date: Fri, 29 Sep 2006 02:38:35 GMT
Message-ID: <LG%Sg.11370$7I1.4304@newssvr27.news.prodigy.net>

<Geek.Empire_at_gmail.com> wrote in message news:1159494222.641733.57620_at_i42g2000cwa.googlegroups.com...
> Bob Jones wrote:

>> "hpuxrac" <johnbhurley_at_sbcglobal.net> wrote in message
>> news:1159441570.920205.236070_at_i3g2000cwc.googlegroups.com...
>> >
>> > Bob Jones wrote:
>> >> <Geek.Empire_at_gmail.com> wrote in message
>> >> news:1159379127.264537.44730_at_i3g2000cwc.googlegroups.com...
>> >> > While upgrading a 9i database to 10g Rel 2 we came across some bad
>> >> > code.  When executed this code would cause that sql session to fully
>> >> > consume one whole CPU and never return even if the user canceled the
>> >> > session.  I'm sure you can see where this would lead.  We have been
>> >> > able to recreate this with the following code:
>> >> >
>> >> > DECLARE
>> >> > TYPE DOSTestTab IS TABLE OF dual.dummy%TYPE;
>> >> > vDTab DOSTestTab;
>> >> > CURSOR c_DOScursor IS
>> >> > SELECT dummy BULK COLLECT INTO vDTab FROM dual;
>> >> > BEGIN
>> >> > OPEN c_DOScursor ;
>> >> > FETCH c_DOScursor BULK COLLECT INTO vDTab;
>> >> > CLOSE c_DOScursor ;
>> >> > END;
>> >> >
>> >> > This, although very bad looking code, did work in 9.2.0.x.
>> >> >
>> >>
>> >> This code is not only bad but pointless. Why is there BULK COLLECT in 
>> >> the
>> >> DECLARE section?
>> >
>> > The OP never claimed the code was good or that is was useful or had a
>> > point.
>> >
>> > What they claim is that this demonstrates a repeatable test case
>> > showing an oracle bug in handling this bad code.
>> >
>> > Did you even read the original posting?
>> >
>>
>> Yes. I don't see why OP had the code on the system if he didn't think it 
>> was
>> useful.
>>
>> He could either simply fix the code or wait for Oracle's fix. Then again,
>> Oracle may not consider it as a bug.
>

> its funny that Oracle consulting actually wrote this application for
> us. This was a oversight of the programmer and it ran fine for the
> last 4 years. Works like a champ in 9i. The problem arises only in
> any version of 10g.

>

> Of course we fixed to the code and continue to move toward going into
> production with 10g, but this could put a server to its knees with a
> simple script and a user id you could take down any oracle 10g server.

>

> Geek

>

Yup, that's why you need quality control. Received on Thu Sep 28 2006 - 21:38:35 CDT