Re: stress tests for a scale to 30,000 users

Since you are on 9i, have you considered monitoring the tables? ( alter/create table monitor )

This would reduce the need to collect statistics so often.

Jared

On Mon, 2003-12-22 at 12:19, ryan_oracle_at_cox.net wrote:
> My estimate right now is about a 500GB instance(but could grow). There are several complexities.
>
> 1. high transaction system, but also will have alot of long running queries
>
> 2. We deliver data daily and rebuild large parts of the database nightly with loads. Im not certain I have the window to analyze every index or get histograms on all the tables. There are VERY large data loads and deliveries. Data has to be delivered by a certain time and we get data feeds from other groups. I cannot control when we recieve data to load.
>
> 3. We will not be actively managing the production server. Its going to be delivered as an off the shelf product. I do not know what statistics ill be allowed to have for security reasons(this is not govenment stuff so dont worry about what I say). Its up to the client.
>
> 4. We are using web server level connection pooling so tracing isnt very useful.
>
> Im essentially the lone performance guy on the team. Ive never done a scale up this large, or with this many complexities. We just managed to convince them to use bind variables... but they haven't been implemented yet.
>
> Im having trouble getting accurate test cases. This is what I am 'attempting' to do at first. Please let me know if my approach is accurate.
>
> 1. Find out which queries will be run the most. Are there things people will do in the mornings, but not in the afternoon(so far its 'dunno').
>
> 2. Hopefully, I can get a hold of either the use cases or 'preferebly' test cases, so we can design our stress tests around actual user processes. All they are doing now is opening up 50+ users and running queries in loops.
>
> What other approach should I take to get started. Im rather troubled by this...
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: <ryan_oracle_at_cox.net
> INET: ryan_oracle_at_cox.net
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).