Exchange 2010 New Store &amp; Database Features

Snehal_India

I am recently started to read the new features on Exchange 2010 and now after reading lot of article and blog i have little bit information on Exchange 2010 but still need to know more about on Exchange 2010 Store Level changes or Database level.

Can someone explain me what are the new changes...

Thanks & Regards,
Snehal

S

Subhash Tiwari Orient

Please go through the below some new features for Exchange 2010 Store & Database level new features...

Exchange 2010 New Database Features or Store Features
Increased page size from 8KB to 32KBâ€”with this change, more data can be stored in a single page, avoiding the need to scatter across the database the pages required for a single item, including any attachments. Header data for all mailbox items is stored in a single database tableâ€”this change makes the database more efficient because it can process a single table for a mailbox during a client session instead of accessing different tables for different mailbox folders. A side effect of this schema change is that Exchange no longer uses Single Instance Storage (SIS) to keep just one copy of message content per database. Most servers support multiple databases, so the efficiency gained from SIS is less and less as time goes on. The Store compresses attachmentsâ€”Microsoft calculates that the CPU time spent compressing and decompressing attachments is less than the work required to manage the storage of very large uncompressed data within the database. This change also reduces the overall size of Exchange databases, which speeds up operations such as backups. The Store updates views (indexes) only when they're accessedâ€”An Outlook client can create many different views for a folder on the fly (e.g., items ordered by subject), and the Store maintains these views within the database. The Store ages unused views out after 40 days, but it needs to maintain views until then. Updating views only when needed eliminates a lot of background processing. The concept of storage groups is eliminated, so the database becomes the management unit to plan high availability aroundâ€”this is a sensible step given that log replication works only for a storage group containing a single database. Single copy clusters are eliminated and not supported in Exchange 2010. Microsoft is moving toward the idea that maintaining multiple copies of data on multiple servers delivers better high availability than attempting to update a single copy of data. Microsoft has also removed LCR from Exchange 2010 because log replication on the same server delivers limited value. Exchange 2010 introduces Database Availability Groups (DAGs), which are groupings of up to 16 servers in which some or all of the databases are marked for replication to one or more other servers. Microsoft uses some components of Windows clustering (e.g., heartbeats, the file share witness) to connect servers within the DAG, which can span physical locations. The big feature is that you can replicate databases to multiple servers within the DAG through log shipping, so locations within a DAG must share sufficient network resources to be able to copy logs quickly enough so that queues of unplayed logs don't build up; think of this requirement as being similar to that of SCR today. Replication targets are chosen at the database level rather than the server level, so you can replicate different databases from a server to different servers within the DAG. For example, a server in New York that has two databases could replicate one database to a server in Los Angeles and the other to a server in Seattle. The live database is referred to as the master; if a problem occurs with the master database, a component called the Active Manager switches to one of its replicas and makes it the live master. Microsoft includes management for DAGs in Exchange 2010's version of Exchange Management Console (EMC) and adds Exchange Management Shell (EMS) commands, so you can control DAGs through the GUI or the command line. A new component in Exchange 2010 called the RPC Client Access Layer upgrades the Client Access server role so that all client connections flow through a predictable point in the network. With the potential for live copies of databases switching between servers, clients can become confused when they attempt to connect to a mailbox. Exchange 2007 introduced the Client Access role, which manages connections from all clients except MAPI (i.e., Outlook). In Exchange 2010, the Client Access role determines which server currently hosts the live copy of a mailbox by reference to the DAG information, which is held in Active Directory (AD), and is therefore able to redirect clients when a database has been switched.

· The Exchange PG is also working on increasing the cache effectiveness by changing the checkpoint depth to 100MB for HA configurations, using cache compressions and DB cache priority.

· In Exchange 2010, the store schema has changed so that all data in a mailbox have stored-in tables close to each other in the database. Actually, each mailbox has its own folder, message header, body, and its own view table. So, the concept of single instance storage no longer exists when it comes to Exchange databases. A side effect of removing SIS from Exchange was that a database was bloated by approximately 20%. Exchange PG found a solution to this by compressing the databases (more specifically message headers and text/HTML bodies). By giving each mailbox its own set of tables, most I/Os performed against a DB are now mostly sequential I/Os.

· Exchange 2010, the Exchange Product group focused on delivering large (+10GB) and fast mailboxes while taking advantage of cheap storage/disks. Because of the ESE changes made in this version, we now have the option to utilize low performance disks such as desktop-like SATA disks (aka SATA/Tier 2 disks). Yes, I am talking about 7200 SATA disks, just like the ones in your workstation! If you use database availability groups (DAGs) for HA (+2 DB copies), you can even use JBOD (a single 7200RPM disk storing both a DB and the transaction logs) instead of expensive RAID configurations.

Snehal_India

ajay.talk

"The Store compresses attachments&mdash;Microsoft calculates that the CPU time spent compressing and decompressing attachments is less than the work required to manage the storage of very large uncompressed data within the database. This change also reduces the overall size of Exchange databases, which speeds up operations such as backups ."

can u please tell us the name of algorithm to decompress the attachment in Exchange server 2010?