Re: onmonitor and NT
> 1. MS caches *result* *sets*, not data -- so if you run the same query twice, it > is *unbelievably* quick the second time. Um yes, that would explain why a 30 second query suddenly dropped to nothing.... I smiled because I got it to run in 4 seconds.. Then he did that. > 2. Oracle salesmen are *very* good, and will do things like _give_ you the > software, then screw it all back out of you in training, maintenance and Yea, did you see the offer they make about $$$ back if thier product doesn't perform better than some of the mainstream db's? > 3. What is the front-end that you're going to use? If VB with ADO, then make > sure you have more than 1 CPUVP (the more, the better). I don't know why, but it > makes a *huge* difference. Interesting, it actually will end up being ASP with ADO. Much as I hate the idea. Recommended PHP but got some long story. I'm not a web page designer so I really don't care. I just want it to be fast. brett -- ----------------------------------------------------------------- Brett's 10th law of UNIX administration... rm is forever ----------------------------------------------------------------- Brett Geer - UNIX Admin/Analyst/Programmer - Intratex Holdings. Tel. +27 31 717 4000 Direct. +27 31 717 4146 Fax. +27 31 717 4001 ----------------------------------------------------------------- The little voices are talking to me again, telling me to reach for a keyboard and type rm -rf /* last week they had me rm -rf `echo $MANPATH | sed 's/:/ /g'` now I fear I have no answers -----------------------------------------------------------------
In the year of Our Lord Wed, 20 Dec 2000 08:20:00 +0200, Brett Geer <brett@brabys.co.za> broke a vow of silence to utter: >> 1. MS caches *result* *sets*, not data -- so if you run the same query twice, it >> is *unbelievably* quick the second time. > >Um yes, that would explain why a 30 second query suddenly dropped to >nothing.... I smiled because I got it to run in 4 seconds.. Then he did >that. SO, here's what you do: generate a whole slew of really big, random queries that will cause memory to fill and then run it in a loop.. >> 2. Oracle salesmen are *very* good, and will do things like _give_ you the >> software, then screw it all back out of you in training, maintenance and > >Yea, did you see the offer they make about $$$ back if thier product >doesn't perform better than some of the mainstream db's? Mmmm...quite a loaded offer -- you had to buy it first and then prove to them that it wasn't faster and *then* they would give you the dosh. Which would probably be less than the license / maintenance fee. >> 3. What is the front-end that you're going to use? If VB with ADO, then make >> sure you have more than 1 CPUVP (the more, the better). I don't know why, but it >> makes a *huge* difference. > >Interesting, it actually will end up being ASP with ADO. Much as >I hate the idea. Recommended PHP but got some long story. I'm >not a web page designer so I really don't care. I just want >it to be fast. I worked at a .com that ran with ASP and stored procedures (*all* SQL via stored procedures) and it was stonking. One of the most heavily hit websites in the UK. FWIW.