Re: Problem with database 8.1.7. release 3 with patchset 2

In article <9tjm3m$jil$1_at_sunce.iskon.hr>, "Đuro Dretvić" <Djuro.Dretvic_at_infodom.hr> wrote:

> Thanks for all your answers.
>
> Here are some additional information about that computer and database.
>
> Question:
> Answer:
>
> 1.What type of disk controller do you have? - SCSI (2 disks in
> (second one is a mirror disk) Database is on one phisical disk 2. What
> kind of disks do you have? - IBM 3. Do you have
> NG2IO boards? - No 4. What kind of RAM?
> - 100 MHZ (2 modules of 512)
> 5. What kind of network connection? - 100baseT? 6.
> Manufactor of Computer - Compaq (1 CPU)

Thanks! SCSI disks are good. Nevertheless, you should monitor your OS and try finding out what exactly is a bottleneck. Unfortunately, I cannot determine that without an access to the machine.

> 7. Number of rollback segments in RBS in RBS tablespace: 28 (storage
> parameters : initial 512 K, next 512 K optimal 4096, minimum number 8)

How many of those are active (online) and being currently in use? You've mentioned 20 users, which would mean that 4 or 5 rollback segments would be completely sufficient.    

> 8. ROLLBACK (1 segment DES_ROLLBACK) (do i need this rollback tablespace
> and segment)

No. If you have other rollback segments then you do not need this one.

> ( I have created it when was installing repository)
> 9. Number of REDO LOG files - 3 ( 10 MB
> each)

The 10 MB log files are exceptionally small. If your database is even remotely active, you will have log switches and checkpoints hitting your database within seconds from each other. In other words, your database will be busy doing frequent checkpoints and what you created it for. You should increase your redo logs to 128M or even 256M. That would probably boost your performance immediately. That can be done online by adding new redo logs and dropping the old ones. Take a look into the alert log. Run STATSPACK.
> 10. Fragmentation is possible. ( I'm planning to perform reorganization
> using Quest Space Manager).

Are you using LMT's (Locally Managed Tablespaces)? You should, as these are the best cure for the fragmentation.

> -Aditional question: Is this normal behavior. When I start this database
> (8.1.7.3) it is occupied about 700 MB of memory. But at peek time of work
> (when all users working) it raises to 1.5 GB (then it uses about 500 MB
> of virtual memory).

SGA allocation is fixed (no longer true for 9i) which means that your additional memory allocation is done by server processes (I do not know the exact architecture of NT 2000, because my company is running HP-UX and at home I am running Linux.) , mainly for UGA (cursors, sort areas, hash areas). The best way to save on memory is deactivate Java because Java is extremely expensive memorywise and uses a ton of CPU cycles. In other words, if you are using Java, your machine can not support 20 users. If you are not using Java, you can balance the memory usage by using MTS and large pool.

-- 
Mladen Gogala