Re: Peformance degradation

In my experience striping disks used by OnLine should be avoided. The problem is that you lose control over the positioning of the data. You may have by the reorganisation, arranged your data in contiguous extents but has your striping software actually placed the data in physically contiguous locations. Ideally your OnLine data should be on a separate disk(s) (and for optimum performance with its own controller). I wouldn't guarantee that this will solve your problem, but it might be worth trying. I have also known 'bugs' in striping software to corrupt OnLine data; this was on an Altos SCO Unix platform. If your inserts are fine, but deletes are slow, have your checked your index strategy (assuming you are deleting selected rows)? Check your writes with tbstat -F, are there any foreground (fg) writes. If there are then performance will be poor. If this is the case adjusting your LRU queues (MINDIRTY) or checkpoint frequency may help. If performance slumped the next day, are you running any overnight processes which could be effecting performance? I recommend you run 'update statistics' each night if your application is adding a fair amount of new rows each day. Perhaps it is the rebooting of the machine that is improving performance. Have you checked the performance of the operating system itself? Is it swapping? Do you have enough memory? Temporary disk space? Use tools like 'sar' to check for disk drive bottlenecks. Regards Paul McGuire