Addcontentdb: Stsadm operation (Windows SharePoint Services)
Applies To: Windows SharePoint Services 3.0
Topic Last Modified: 2008-06-26
Operation name: Addcontentdb
Description
Creates a new content database or adds a database that needs to be upgraded when the url and databasename parameters are specified.
When a content database is created, the location of the data and log file is determined by the default database settings established on the SQL database server. A content database is created with a primary file group hosting one data (.mdf) file and one transaction log (.ldf) file. When the addcontentdb operation is used to create a content database, you must run the spsearch operation to associate a content database with a specific server that is running the Windows SharePoint Services search service. For additional information about the spsearch operation, see Spsearch: Stsadm operation (Windows SharePoint Services).
Important
If you detach and reattach a content database, be aware that the next time the content within that content database is crawled a full crawl will occur even if an incremental crawl has been requested. Because a full crawl re-crawls all content that the crawler encounters, regardless of whether that content has been previously crawled, full crawls can take significantly more time to complete than incremental crawls.
Syntax
stsadm.exe -o addcontentdb
-url <URL name>
-[-assignnewdatabaseid]
-[-clearchangelog]
-databasename <database name>
[-databaseserver <database server name>]
[-databaseuser <database username>]
[-databasepassword <database password>]
[-sitewarning <site warning count>]
[-sitemax <site max count>]
Parameters
| Parameter name and short form | Value | Required? | Description |
|---|---|---|---|
url |
A valid URL, such as http://server_name |
Yes |
URL of the Web application to which the content database is being added. |
assignnewdatabaseid |
A valid GUID, such as "12345678-90ab-cdef-1234-567890bcdefgh" |
No |
Creates a new database ID automatically when a content database is attached. This parameter was first introduced in the Infrastructure Update for Windows SharePoint Services 3.0. For more information, see Remarks. |
clearchangelog |
<none> |
No |
Clears the change log Forces the change log to be cleared when necessary, for example, when restoring a content database to a prior point in time using separate SQL Server-level backup tools. This parameter was first introduced in the Infrastructure Update for Windows SharePoint Services 3.0. For more information, see Remarks. |
databasename (dn) |
A valid database name, such as "DB1" |
Yes |
Database name. |
databaseserver (ds) |
A valid database server name, such as "Sales", where named instances are used; the format may appear as server\server |
No |
Database server name. The default server is used if a value not provided. |
databaseuser |
A valid user name in the form "Username1" |
No |
Account used for SQL authentication. Must be used in conjunction with the databasepassword parameter. |
databasepassword |
A valid SQL password |
No |
The databasepassword parameter should only be used where Windows authentication is not implemented Therefore, in a Microsoft SQL Server authentication scenario, you need to pass the databaseuser and databasepassword parameters to authenticate against the database server. Under Windows authentication, you can omit these parameters because the credentials are passed using NTLM. |
sitewarning |
A valid integer number, such as 10 |
No |
Integer number of site collections allowed in the content database prior to generating a warning event in the Windows event log. |
sitemax |
A valid integer number, such as 10 |
No |
Specifies the maximum number of site collections allowed in the content database. |
Remarks
If you are running the Infrastructure Update for Windows SharePoint Services 3.0, the identifier (ID) of each content database is retained when you restore or reattach the database by using built-in tools. Default change log retention behavior when using built-in tools is as follows:
The change logs for all databases are retained when you restore a farm.
The change log for a content database is retained when you reattach the database.
The change log for a content database is NOT retained when you restore just the content database.
For more information, see Move content databases (Windows SharePoint Services 3.0) and Back up and restore the entire farm (Windows SharePoint Services 3.0 technology).
If you restore an older SQL Server backup of a content database, the Search index may contain more entries than the restored databases in the farm. First, use the Stsadm command stsadm –o deletecontentdb to detach the database from the SharePoint farm, and then restore the database by using SQL Server tools. Next, use the Stsadm command stsadm –o addcontentdb –clearchangelog to reattach the content database and clear the change log. Clearing the change log forces Search to run a full crawl on that database so that the index no longer references items that do not exist.
As an administrator, you should always know when and if a change log should be cleared. For example, if a content database is restored to an earlier time than the last crawl by using Microsoft SQL Server-level backup tools, and this operation is used to reattach it to the farm, not clearing the change log causes the index to potentially have entries for items in that content database that do not exist in the restored database. To prevent this issue from occurring in this scenario, use the clearchangelog parameter to clear the log. If a content database has been attached mistakenly without the clearchangelog parameter, you should detach and then reattach the content database using the clearchangelog parameter so that the next crawl will be able to reset the index for that content database.
When a content database is attached to the same Web application, the change log will by default be preserved along with the database ID. If it becomes necessary to change the database ID, such as an ID conflict, the assignnewdatabaseid parameter will force a new ID to be selected for the content database.
You will receive the following error if you are unable to attach the database to the farm due to a conflict: The attach operation cannot continue because another object in this farm already contains the same ID. Each object in a farm must have a unique ID. In order to proceed with the attach operation you must assign a new ID to this database. To attach this database with a new ID, use the "stsadm.exe -o addcontentdb" operation with the -assignnewdatabaseid parameter. Note that if this new database and an existing database contain the same site collections, attaching this database will likely result in orphaned site collections due to conflicts between the two databases.