Re: Still Having Novell Problems

>*** Quoting Dagmara_at_Delphi.Com to All dated 10-22-94 ***
>> SYS1, SYS2, SYS3: striped FISERV tablepsace, 160M per device
>> SYS2, SYS3: striped rollback tablespace, 160M per device
>> SYS, SYS1: striped temporary tablespace, 160M per device
 

>Hold on a moment here -- striped HOW? If you mean that the tablespace exists
>in several datafiles that are spread across volumes, that's one thing (weird,
>but okay) but if you are using some kind of file system NLM or RAID
>abstraction, that's where you should be looking for performance problems and
>problems in creating files...

I agree I think your bottleneck is at the i/o level.

You may want to consider dropping the raid stuff. It's great for read but is real slow on writes. If you do go to individual drives then try what I do, put your individual tablespaces on different physical drives, place data in them based on size, use, etc. AND have there indexes on a different drive seperate from the table data. I believe that this gives me slightly better performance.You may want to consider it.

I am curious as to how you are doing the raid stuff. Is it software or hardware? What Raid level are you? Are all the drives part of this raid or are some not? If it is software is there a problem between directfs.nlm and whatever you are using? Also, like I said before the, scsi driver ibmps2.dsk ( I think thats the name ) is buggy and you said it was an IBM machine. There is a new one out there.

>If you are "striping" by providing multiple datafiles for each tablespace,
your>set-up probably isn't the best (e.g., SYS1 will experience lots of contention,>SYS3 may never be used) but it seems acceptable.

>> In addition to totally restructuring Novell, the data architecture, I
>> cranked up DB_BLOCK_BUFFERS and SHARED_POOL_SIZE to 18MG; ZERO gain.
 

>A couple of questions: what is your DB_BLOCK_BUFFERS parameter, and what are
>you using to test performance?
Received on Tue Oct 25 1994 - 17:35:55 CET