Re: Oracle architecture - any help would be preferred

Comments embedded (wait for other dissenting opinions and weigh the arguments as well).
"Martin" <mwolski_at_poczta.fm> wrote in message news:277610dc.0208210620.370edc27_at_posting.google.com...
> Hello,
>
> I am a beginner at Oracle administration and I would be grateful for
> any suggestions:
> Target - Oracle9i database designed mainly for Web applications,
> 100-150 connections working concurrently (average value), max 300
> connections. Operating System: SUN Solaris 8 with 4GB Ram.
>
> Dedicated or MTS???;

Dedicated - let your web app handle connection pooling.

> memory size (shared and buffer cache) - I think, 100MB for shared
> memory size and 70 MB for cache size;

Its pretty well impossible to tell without knowing the app. The only comment I'd make is that presumably the box was sized to handle the app and now you are only using 100mb of ram (out of 4 gb) for Oracle. I'd expect to start somewhere closer to the 1gb mark. In anycase tuning this will be an iterative process

> block size??;

8k if using a buffered file system
(http://www.ixora.com.au/tips/buffered_block_size.htm for rationale) Otherwise as large as possible (though I'm not sure that that doesn't limit you to 8k as well on Solaris) http://www.ixora.com.au/tips/block_size.htm

> 3 control files (one of them on the different disk)

3 control files is fine but they should all be on different disks (so you can never be down to just one.).

> 3 groups of log files (2 files in the group)

suck it and see.

> Should I use undo management provided by Oracle9i??

My take on this is yes. Otherwise you will have to create and size rollback segments appropriately.

> How many space is needed for users' tablespace??

Now this is impossible to tell. How much data is going in there? As a start you could just pick your data volume and add 50% or you could do a google search for database sizing and take a somewhat more scientific approach.

> ...and any information, that could help me.

Don't just create one users tablespace but consider the size of the objects that will go in it. If you have database objects with wildly different sizes then create multiple users tablespaces with different extent sizes (comon values seem to be 64k,1m,8m,64m), Make these tablespace locally managed with a uniform extent size and use freelists for segment space management. A search on google for locally managed tablespace will lead you to extensive discussions on these beasties (and why they will make your job way easier than it used to be). .

HTH

--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer

******************************************