programming4us
programming4us
ENTERPRISE

Microsoft Exchange Server 2010 : Navigating the Information Store (part 1) - Using Databases, Understanding Database Structures

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
2/22/2014 8:44:21 PM

Exchange 2010 integrates high availability and messaging resilience into the core architecture, providing a simple unified framework for both high availability and disaster recovery. This approach allows Exchange 2010 to improve continuous replication and replace the clustering features in Exchange 2007 with a more robust solution that doesn't require expensive hardware and also requires less maintenance.

Using Databases

Mailbox databases continue to be the primary type of database used with Exchange Server. Exchange Server 2010 also supports public folder databases. However, Exchange Server 2010 does not make public folders mandatory because Microsoft Office Outlook 2007 and later releases do not use public folders for accessing free/busy data or the offline address book (OAB). Instead, Outlook 2007 and later access this information from the organization's Client Access servers. How does this work? Client Access servers provide Web services, which in turn allow clients to access mail, free/busy data, OAB data, and other Exchange data using Hypertext Transfer Protocol (HTTP).

Outlook 2003 clients and earlier clients require a public folder database to connect to Exchange Server. These clients use public folders to access free/busy information and the OAB. If you have Outlook 2003 or earlier clients, as well as other Messaging Application Programming Interface (MAPI) clients, these clients can continue to access public folders on mailbox servers running Exchange Server 2010. You manage public folder configuration using the Public Folder Management Console and the Exchange Management Shell.

Note

Exchange Server 2010 does not support public folder access using Network News Transfer Protocol (NNTP) or public folder access using Internet Message Access Protocol version 4 (IMAP4). Exchange Server 2010 also does not support non-MAPI top-level folders in your public folder databases. The only way to maintain this functionality in an Exchange 2010 organization is to maintain a server running Exchange Server 2003.

When you install the first mailbox server in the organization, this server's information store typically has a single, default mailbox database and a single, default public folder database. However, the specific configuration depends on your responses during setup. When you are installing the first mailbox server, Setup prompts you to:

  • Specify whether you want to create the default mailbox database. If you decide to create one, you can also specify its name and location.

  • Specify whether any client computers run Outlook 2003 or earlier or Entourage. If you answer yes, a default public folder database is created. If you answer no, a default public folder database is not created.

Note

In an Exchange organization with existing Exchange 2003 servers, you are not prompted about clients running Outlook 2003 or earlier or Entourage. In a mixed organization like this, Setup creates a public folder database automatically to ensure backward compatibility.

When you install additional mailbox servers in the organization, these servers have only one database initially—the default mailbox database, if you choose to create it. The reason for this default configuration is that the decision whether a public folder database is needed in the organization is determined only when you install the first mailbox server. When you install additional mailbox servers, you are not prompted about clients running Outlook 2003 and earlier or Entourage. A key reason for this is that only one public folder database is required in an Exchange organization and any other public folder databases are optional. Keep in mind that regardless of your selections during setup, you can create a default public folder database as well as additional public folder databases at any time using the Exchange Management tools.

Understanding Database Structures

Unlike earlier releases of Exchange, Exchange Server 2010 does not use storage groups, and functionality associated with storage groups has been moved to the database level. Because of these changes, Exchange databases have a single, dedicated log stream, which is represented by a series of sequentially named log files. Each log file is 1 megabyte (MB) in size.

In addition to log files, databases have several other types of files associated with them. As Table 1 shows, these files include one or more checkpoint files, a temporary working file, and one or more transaction log files. Depending on the state of Exchange Server, you might see other working files as well. When you create a database, you can specify separate folder locations to use for database files and transaction logs. Each database has content-indexing files associated with it as well. These files are generated by the full-text search services running on mailbox servers.

Table 1. Data and Log Files Used by Databases

TYPE OF FILE

FILE NAME

DESCRIPTION

DATA FILES

  

Database file

DatabaseName.edb

Primary database file that contains mailbox data

Temporary data

Tmp.edb

Temporary workspace for processing transactions

Checkpoint file

E##.chk

Checkpoint file that tracks the point up to which the transactions in the log file have been committed

TRANSACTION LOG FILES

  

Primary log file

E##.log

Primary log file that contains a record of all changes that have yet to be committed

Secondary log files

E##00000001.log, E##00000002.log, …

Additional log files used as needed

Reserve log files

E##Res00001.jrs, E##Res00002.jrs, …

Files used to reserve space for additional log files if the primary log file becomes full

FULL-TEXT INDEXING FILES

  

Content index-related files

.ci, .wid, .dir, .000, .001, .002

Files used for full-text indexing of mailbox data

You use Exchange databases to ease the administrative burden that comes with managing large installations. For example, instead of having a single 10-terabyte (TB) database for the entire organization, you can create ten 1-TB databases that you can manage more easily.

Tip

As a best practice, 2 TB is the largest recommended size for Exchange Server 2010 databases when you have two or more mailbox database copies. This large size is made possible by the significant core improvements in Exchange Server 2010. You'll also find that large databases make it easier to support the large mailboxes that might be required by your organization's managers and executives. Still, most mailboxes should be limited to between 2 GB and 10 GB in size.

When you create a mailbox or public folder database, you specify the name for the database, and this name sets the name of the primary database file as well. For example, if you create a mailbox database called MarketingDept, the primary database file is set as MarketingDept.edb. With Exchange Server 2010, the default location for database files is the same as the log folder. If you want a database to be in a different location, you can specify the location you want to use. Separating database files and log files from the same database and putting them on different volumes backed by different physical disks can help you scale your organization while ensuring high performance and recoverability.

Tip

Recoverability is the primary reason for separating database files and log files. For example, in the case of a failure on a drive where a database is stored, the transaction logs needed for complete recovery would then be on a different (and probably functioning) drive. Whether you want to use this approach depends on the size and configuration of your Exchange Mailbox servers as well as the service level agreements you need to comply with.

The many files associated with databases provide granular control over Exchange Server, and if you configure the data files properly, they can help you scale your Exchange organization efficiently while ensuring optimal performance. In a small implementation of Exchange, you might want to place all the data files on the same drive. As you scale from a small organization to a larger organization, you'll generally want to organize data according to databases, placing all the data for each database on separate drives. You can't always do this, however, in a small-to-medium-size organization with limited resources. For example, if you have ten 1-TB databases and only five data drives, you might want to have the five data drives configured as follows:

  • Drive 1 with Database 1 and Database 2 and all related data files.

  • Drive 2 with Database 3 and Database 4 and all related data files.

  • Drive 3 with Database 5 and Database 6 and all related data files.

  • Drive 4 with Database 7 and Database 8 and all related data files.

  • Drive 5 with Database 9 and Database 10 and all related data files.

In a storage area network (SAN) implementation where you are using logical unit numbers (LUNs) and don't know about the underlying disk structure, placing the databases on separate LUNs should be sufficient. To protect the data, you might want to consider using hardware RAID (Redundant Array Of Inexpensive Disks), which is likely already implemented if you are using a SAN. However, if you configure a database availability group with multiple member servers that each have one or more copies of mailbox databases, you likely don't need to use any type of RAID—you likely won't need daily backups either. Just remember that Microsoft recommends having at least three database copies in addition to the active copy.

Note

REAL WORLD If the idea of not needing RAID seems like a radical concept, the idea of not needing to perform backups of your Exchange data might seem revolutionary. However, when you have multiple copies of your data on separate servers, you really might not need to create daily backups of your Exchange data. This doesn't mean that you won't need to create backups ever—it just means you might not need daily backups of Exchange data. You will probably still want to create regular backups of your Exchange servers and still create periodic full backups of all server and Exchange data to rotate to off-site storage as a safeguard against catastrophe.

Database available groups can also make you rethink your use of SANs. Rather than having a single, massive (and likely very expensive) storage device, you might want to rely on a server's internal drives or multiple smaller (and likely less expensive) storage devices. One reason to use internal drives is that reliable, multiple-TB hard drives are becoming increasingly available, and several servers with multiple, large internal hard drives will likely cost a fraction of the price of a single massive SAN. If you use SANs, you might find that multiple smaller storage devices are better than a single, massive storage device because you'll then be protected against a single source of failure (the storage device) causing an outage on all your mailbox servers. I know, I know…the SAN should never go down, but it can (and does) happen.

Other  
  •  Byod – Good Or Bad Or Unknown?
  •  Windows 7 : WORKING WITH THE FIREWALL (part 6) - Using the GPO Technique - Adding a New Application Rule, Removing an Application Rule
  •  Windows 7 : WORKING WITH THE FIREWALL (part 5) - Using the GPO Technique - Obtaining a List of Rules
  •  Windows 7 : WORKING WITH THE FIREWALL (part 4) - Using the GPO Technique - Configuring the Rule Technique Example
  •  Windows 7 : WORKING WITH THE FIREWALL (part 3) - Adding and Deleting Ports
  •  Windows 7 : WORKING WITH THE FIREWALL (part 3) - Adding and Deleting Ports
  •  Windows 7 : WORKING WITH THE FIREWALL (part 2) - Modifying a Setting
  •  Windows 7 : WORKING WITH THE FIREWALL (part 1) - Interacting with the Firewall , Verifying the Firewall Status
  •  Windows 7 : Developing Applications with Enhanced Security - DEVISING AND IMPLEMENTING A SECURITY POLICY
  •  Windows 7 : Developing Applications with Enhanced Security - CREATING AN APPLICATION WITH ENHANCED SECURITY (part 3) - Developing for Permissions
  •  
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    REVIEW
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us
    programming4us
     
     
    programming4us