>Hi im running on SATA RAID level 1 software level in Windows 2003. I have a physical table and more logical tables (views) and updates and insertion are done in views. All of the routine were done using ATOMICITY method using TRANSACTION. Lately our data is just 700MB (mdf) file on a raid 1 harddisk and i notice there is a very slow performance every time a call is made to the procedure with BEGIN Transaction call. The procedure manipulate the view (update, insert , delete) and when running on multiuser mode on a terminal server, the disk queue reaches 100% (Performance Monitor). Does this means when using TRANSACTION i really need to use Ultra SCSI and run it on RAID 5 ? Is this a normal issue when using BEGIN TRANSACTION? I also assume that when we issue BEGIN TRANSACTION there will be a TABLE LOCK so since I have different table views with 1 source of physical Table I assume that this is the problem. Should I change my table view to physical table to seperate the locking? Also
> in the SQL Enterprise manager I notice sometimes that there are Blocking Process.

Can you describe the index(s) on the table? What triggers are running is another place to look, but I'll wager on sloppy index creation. Are pages getting created in your inserts because the engine has to break existing pages for this new data in the index? SQL indexs are not like a fox index.

Go to quest.com and demo the Spotlight tool. You will be able to see what your fighting in slowness with it's amazing array of monitors. Make a batch insert statement of 1000 to 5000 rows to test your table. Fire that script and watch this tool show you wnat is really going on.