Understanding the Default Databases and Changes from the Database Structure in SharePoint Portal Server 2003

The installation of SharePoint Server 2007 implements many changes to the database structure, particularly when compared to SharePoint Portal Server 2003. As part of the reduction in resource overhead of a portal, setup creates only one content database for each Web application, unlike the three databases that were created for each portal in SharePoint Portal Server 2003.

The Configuration database, which was always central to a farm, has taken on many new important roles. One major shift you will see is that the configuration database must be backed up for disaster recovery. In SharePoint Portal Server 2003, the configuration database was rebuilt "on-the-fly" during a recovery operation. In SharePoint Server 2007, the configuration database is restored from backup. However, members of the farm still must check the configuration database constantly to see whether their role in the farm has changed, as well as to check where all the other roles within the farm are located. By default, each server in the farm checks with the configuration database every 30 seconds.

The Job Server role in SharePoint Portal Server 2003 has been eliminated in SharePoint Server 2007. The configuration database now stores information on the various jobs, their parameters, and their schedules. In addition, many SharePoint settings formerly stored only in an individual member's registry are now also stored in the configuration database, as well as the IIS metabase configurations and file system changes on the WFE servers. When new applications are "created" in Central Administration, the information is first placed in the configuration database and then all WFEs complete the appropriate actions on their servers. This new centralized storage enables quick duplication when a new WFE is added to the farm, and it allows for replication of local changes on the WFE members. This also means that changes to a Web application's configurations in IIS Manager made after the Web application has been created are not written to the configuration database. Best practice is to not make configuration changes to this Web application using the IIS Manager after the Web application has been created.

In addition to the configuration database, the following databases are created as part of the installation and configuration of SharePoint Server 2007:

• Admin_content database Stores the information related to lists, document libraries, tasks, and so on of the Central Administration site. You can add information and documents to the site.

• SSP database Each SSP requires a database for service-specific data. The SSP database stores any nonsearchable data that needs to be accessed by multiple sites. This data includes, but is not limited to, the following:

  q	User information imported from Active Directory or another directory-for example, people profiles
  q	Calculated audiences and organizational hierarchies
  q	Security information needed for the rights for the administrative delegation of the SSP site
  q	Business Data Catalog (BDC)-related imported data
  q	Business application data such as Service Advertising Protocol (SAP)
  q	Business Intelligence (BI) methods
  q	Site usage data
  q	IPFS session state information

• SSP search database Separated from the SSP database primarily to ease the management of these databases. The SSP search database also enables a database administrator to back up other Office Server databases at a more granular level. One SEARCH database is created per SSP. The search database contains frequently changing search-related data that is created during the search indexing process, such as crawl properties, document properties, and propagation properties. This is similar to the metadata information stored in the Embedded Database Engine (edb) database by the search service of SharePoint Portal Server 2003. The SEARCH database serves as the data store for the following:

  q	Search metadata (also called the property store)
  q	History log
  q	Search log
  q	Calculation tables for crawl statistics
  q	Links tables and statistical tables

  These SSP databases do not contain the index created by the gatherer service.

• Content databases Used for site collections to store all Office Server data, including the following data:

  q	All site details
  q	Structure details
  q	User content
  q	Files
  q	Security information
  q	InfoPath form server templates
  q	Excel server data

A significant change in database structure is the creation of content databases for each application regardless of the application's function. So although we no longer get the extra _serv and _prof databases for each portal as we did in SharePoint Portal Server 2003, we do get content databases for the Shared Service Provider (SSP) application, the Web Services application, and the Central Administration application. These content databases serve the same functions as those of every other Web application's content database.