SQL Server and Read-Only Databases

By Chris Miller on 5 July 2000 | 4 Comments | Tags: Administration


This article discusses creating read-only databases to improve performance throughput. This can be especially handy in a web environment where many users want to view information.

Sometimes there are good reasons to have read-only databases. For internet applications, it's pretty common to have a consolidated database that provides information for users. The traditional internet model is a model which provides a lot of data to users who normally only send a small amount of data to the web. It's pretty common to have a lot of data which is read only, or at least that can be segregated into a read-only section (archive) and read-write section.

If you've got a read only database, mark it read-only in SQL Server. If you do that, then SQL Server will make some assumptions about the database, like that the database doesn't have anybody making changes on it, and SQL Server will disable locking in the database. That means less overhead, and it should speed things up a bit.

Also, if you go one step farther and actually make the database files read-only you can back up the database without shutting SQL Server down while the files are in use. Just directly back up the MDF and LDF files, and they can be restored and reattached. To mark the files read only, detach the database using sp_detach_db, use the "attrib" command to mark the files read only, and then use sp_attach_db to reattach the database.

There are a few caveats here. If you mark a database read only, it is very really and truly read only. That means that any auto-shrink options are not going to happen, and neither are automatic statistics. DBCC commands to fix database corruption will not work. As a result, you'll need to make sure that the database is already shrunk (dbcc shrinkdatabase) and that the database has all of the statistics and indexes it needs to run efficiently.

In addition, if you elect to copy the database to another path and reattach it, you'll need to make sure that the files are not marked read only or they won't attach. Why? Well, the path for the LDF file is stored inside the MDF file, so if the path needs to change, for example from one drive letter to another, then the MDF file will need to change in order to store the new path, and the LDF file will need to change in order to add the transaction log record for the change to the MDF file (funny how these things work).

Discuss this article: 4 Comments so far. Print this Article.

If you like this article you can sign up for our weekly newsletter. There's an opt-out link at the bottom of each newsletter so it's easy to unsubscribe at any time.

Email Address:

Related Articles

Advanced SQL Server 2008 Extended Events with Examples (25 May 2009)

Introduction to SQL Server 2008 Extended Events (19 May 2009)

Monitoring SQL Server Agent with Powershell (24 March 2009)

SQL Server Version (29 January 2009)

Scheduling Jobs in SQL Server Express - Part 2 (1 December 2008)

Alerts for when Login Failures Strike (14 July 2008)

Using xp_ReadErrorLog in SQL Server 2005 (12 May 2008)

Moving the tempdb database (5 November 2007)

Other Recent Forum Posts

Violation of %ls constraint '%.*ls'. Cannot insert (1 Reply)

CHARINDEX (10 Replies)

Parameterized query for a List of Items (2 Replies)

CHECKDB Failing (14 Replies)

SQL server & SIEM (1 Reply)

Checking permissions to a database (1 Reply)

How to get Microsoft SQL Server 2012 started? (1 Reply)

Query 2 tables, update one with data from other (4 Replies)

Subscribe to SQLTeam.com

Weekly SQL Server newsletter with articles, forum posts, and blog posts via email. Subscribers receive our white paper with performance tips for developers.

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -