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, [EMAIL PROTECTED] 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: <[EMAIL PROTECTED]
>   INET: [EMAIL PROTECTED]
> 
> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to