DA Morgan wrote:
> Serge Rielau wrote:
>
>> DA Morgan wrote:
>>
>>> Joel Garry wrote:
>>>
>>>> Keith wrote:
>>>>
>>>>
>>>>> How about this.... create a Pro/C program where you can pass the
>>>>> number
>>>>> of instances you want to run -- say 100. Then the Pro/C program can
>>>>> fork 100 times, connect to Oracle , and execute the procedure with
>>>>> appropriate values for fromX and toY.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Wouldn't that not be any better, since Oracle is going to have to latch
>>>> the system tables to serialize each table creation? Perhaps even much
>>>> worse, as the latch queues grow and grow and... I think this would just
>>>> be a grotesque denial of service attack, if it can even create that
>>>> many processes. Then you'll deadlock as the underlying system tables
>>>> need to extend (even LMT's given 500000 tables).
>>>>
>>>> Since some apps have tens of thousands of tables I don't think the
>>>> requirement is _inherently_ ridiculous, but I don't think it can be
>>>> sped up, either. And it might be ridiculous anyways, not enough detail
>>>> to know.
>>>>
>>>> jg
>>>> --
>>>> @home.com is bogus.
>>>> http://inquirer.stanford.edu/2005/jstaffor/woz.html
>>>
>>>
>>>
>>>
>>> I'm sticking with inherently ridiculous until there is a better
>>> explanation. ;-)
>>>
>>> In fact I'll up the ante. I say it is intrinsically, explicitly and
>>> patently ridiculous.
>>
>>
>> FWIW, I have seen a design recently requiring 1.5M stored procedures
>> and 1M tables. (that's million,not milli :-)
>> The SAP schema suddenly looks boring....
>>
>> Cheers
>> Serge
>
>
> Too bad the designers never took a class on set theory.
Gotta roll with the punches... *sigh*
--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Received on Fri Dec 09 2005 - 19:22:17 CST
