On Fri, May 29, 2009 at 9:44 AM, Carl Houseman <c.house...@gmail.com> wrote: > As for memory/CPU, does eliminating SIS mean lower RAM or slower CPU > requirements for the product? Doubtful.
Someone already explained that Exchange 2010 moves from a single set of tables for all mailboxes, to a separate set of tables for each mailbox. This was apparently done to increase locality of reference. With one giant table for all messages in all mailboxes, then when a mailbox is opened, the IS has to jump all over the disk to find all the messages that belong to that user. Then again for attributes. With Ex 2010, each mailbox has its own set of tables, and the IS takes pain to keep those tables together on disk. The result is that when a mailbox is opened, most of the I/O is in one spot on the disk. I can definitely see this being a big win in performance, especially on large systems with thousands of mailboxes and millions of messages. I presume that the attachments table was also allocated on a per-mailbox basis. With each mailbox keeping track of its own attachments separately, SIS becomes much harder to do. Before, there was one giant table for every attachment in the system. SIS was easy; every message instance just referenced the same entry in the giant attachment table. I do think that getting rid of SIS for attachments may be throwing the baby out with the bathwater for many environments. If some shops are that desperate for the performance improvement of per-mailbox attachment tables, make it an option for each storage group or database, set upon creation. If SIS is enabled, use one giant table for attachments. If SIS is disabled, use per-mailbox attachment tables. Alas, seems that is not to be. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
