7. Read-Only Content Databases
SharePoint 2010 introduces the capability of recognizing content databases that have been set to read-only in SQL Server. This can be helpful during a disaster
recovery to prevent changes from being made to the content during the
recovery. After changing a content database to read-only, all users
(including SharePoint administrators) are prevented from making any
changes to the information contained within the site collections stored
in the read-only database.
Note:
This procedure is for
content databases only and should not be set on the SharePoint
configuration, Central Administration, or search databases.
The procedure to set the database to read-only can be performed using either SQL Server Management Studio or a T-SQL ALTER
DATABASE statement. However, you must be a member of the SQL Server
db_owner fixed database role for each database that you want to set to read-only.
The SQL Server read-only
feature can be helpful in the following scenarios.
Disaster recovery
Mirrored databases
Log-shipping databases
High availability
SharePoint patching
Mirrored databases
As you can see in Figure 7,
even though the user is logged in as a SharePoint administrator, there
are no commands available within Site Actions that allow the user to
modify the site after the database is set to read-only. Also, the
documents or list items contained within the content database cannot be
modified.
SQL Server read-only
content databases that allow you to create an entire read-only farm as
part of your disaster recovery environment are something new to
SharePoint 2010. The read-only farm also can be part of a highly
available maintenance, patching, or upgrade environment by providing
users access to the read-only content while the production farm is being
updated. In a read-only farm, all your SQL Server content databases are
set to read-only by your SQL DBA. All other databases including the
configuration database, Central Administration content database, and
search database, still have read/write access.
The following changes will be apparent to a user who accesses a read-only site.
Most tasks that
require writing to the content database are not available, because they
are no longer available in the user interface, or because the user is no
longer allowed to apply changes. All tasks that do not require writing to the content database are fully functional. Some
tasks that do write to the content database appear to be available but
will return errors when the user attempts to write to a read-only
database.
|
8. Unattached Content Databases
SharePoint 2010
introduces the capability to access databases that are available in SQL
Server but aren’t currently part of the farm. This allows you to perform
granular restores of SharePoint content using SharePoint. It eliminates
the need to perform an alternate farm restore, which was required to
perform granular recoveries in SharePoint Server 2007. Accessing
unattached content databases will allow SharePoint administrators to
connect to read-only content databases, restored SharePoint content
databases, and content database snapshots. You are able to restore site
collections, sites, libraries, and lists from these unattached content
databases.
Using the interface shown in Figure 8,
you can browse the contents of the database and retrieve any content
you need to recover. After you export the content, simply import the
content to the appropriate container within SharePoint.