SQL Server Reference Guide

Read-Only Data

Last updated Mar 28, 2003.

All databases store and retrieve data. But some applications only require that the storage work one time — that data is entered once, but read multiple times. In fact, for some tracking applications, it's a requirement that data is only written one time, but can be read multiple times after that first entry.

SQL Server has the ability to simply flip a switch or two and set either a group of data or an entire database to a read-only mode. But before you do that, you need to decide which data should be protected and delivered this way, and what the considerations are for flipping those switches.

Most of the data you work with is probably set to read/write. That makes sense, because most applications allow users to enter and edit data. But some data does not need to be altered once it is written. Let's say you have an application that tracks the route of a vehicle, or the shipping status of an item. Once that status is set, it is rare that you need to change it — if it is a historical record. And that is the key for data that you might set to read-only. If a datum is set for a certain period of time, place, or both, it is a possible candidate for being read-only.

There are distinct advantages for setting the data to read-only. One of the most important is that the data can be read without the need for excessive locks, since the system knows the data won't change. Everyone can be given a shared lock on the data rather than blocking reads for write operations. Another advantage is that the data is easy and fast to back up, for the same reason. It's also protected from change, which is the obvious reason to set the data that way in the first place.

Making Portions of a Database Read Only

After you examine your data to see if it is a candidate for being set to read-only, you have a few options. You can make the data read-only by using the application logic, meaning that you write the application code such that changes aren't made to the data, and the transaction isolation levels are set to take a "dirty read." But that doesn't actually change the data or guarantee that another application (or a direct access to the database) couldn't change the data anyway.

To guarantee no read operations work, you need to set the system to make data into a read-only. You have two choices: You can use a FileGroup in SQL Server, or you can set the entire database to be read-only. It all depends on whether you want to lock only some of the data or all of it.

You can mark any FileGroup read-only, with the exception of the Primary FileGroup. You can then place the data you want on that FileGroup when you create the object. Let's take a look at a simple example.

First, let's create a database:

CREATE DATABASE Test; 
GO 

Now, let's add a FileGroup to it, called "ReadOnlyFileGroup." For that we'll use the "ALTER DATABASE" command, with the ADD FILEGROUP qualifier:

ALTER DATABASE Test 
  ADD FILEGROUP ReadOnlyFileGroup 
GO 

As I've described in another tutorial, FileGroups contain files. Let's add one of those now, once again using the ALTER DATABASE command, this time with the ADD FILE qualifier. We'll use the name ReadOnlyFile as the logical name, and in this example the file is set to the C:\TEMP directory. You can alter it to place yours wherever you like:

ALTER DATABASE Test 
  ADD FILE 
   (Name = ReadOnlyFile, 
   FILENAME = ’C:\temp\ReadOnlyFile.ndf’, 
   SIZE = 2) 
  TO FILEGROUP ReadOnlyFileGroup 
GO 

At this point you can create tables or indexes on that FileGroup. This example does just that and then loads it with a little data:

USE Test; 
GO 

CREATE TABLE TestTable (c1 INT) 
ON ReadOnlyFileGroup; 
GO 

INSERT INTO TestTable VALUES (1); 
INSERT INTO TestTable VALUES (2); 
INSERT INTO TestTable VALUES (3); 
INSERT INTO TestTable VALUES (4); 
INSERT INTO TestTable VALUES (5); 
GO 

Only one step left — we just use the ALTER DATABASE statement again to change the FileGroup to read-only mode:

ALTER DATABASE Test 
  MODIFY FILEGROUP ReadOnlyFileGroup READONLY; 
GO 

We can still read data from the table in the standard way:

SELECT * 
FROM TestTable; 
GO 

But we can't put any new data in, because the table is on the read-only FileGroup. This statement will fail:

INSERT INTO TestTable VALUES (6); 
GO 

Let's go ahead and clean up this example:

USE master; 
GO 
DROP DATABASE Test; 
GO 

The rest of the tables and other objects in the database can be placed by default on the Default FileGroup (which can't be set to read-only), or you can create other FileGroups to store that data. That way part of your data is read-only, and the rest is not. Remember, if you want to enter more data in the read-only table, you'll need to use the ALTER DATABASE statement again, this time with the READWRITE qualifier on the FileGroup, and then enter your data. Then put it back to READONLY as we did in the example.

Checking the Status of a Database

You can also set an entire database to be read-only. Of course before you do that you need to have all the data loaded, and it's a good idea to update all of the indexes and statistics before you take it to read-only mode.

You can do that by checking the status. You can see the status in the Properties panel in the graphical tools, and you can also use the DATABASEPROPERTYEX() function. Here's an example that uses that function to find out if the database "Test" is set to read-only or read/write:

SELECT DATABASEPROPERTYEX(’Test’, ’Updateability’);

Setting a database to Read-Only Mode

If you decide you want to set the database to read-only mode, you have two choices. You use the graphical tools, and choose the Properties of the database you want to control. Navigate to the Options panel and just change the status there.

The second method is to use commands. Once again we'll use the ALTER DATABASE command, this time with a SET option. You'll need to be in the master database to run the command. This example does that for a database called "Test":

USE master;
GO
ALTER DATABASE Test
SET READ_ONLY WITH NO_WAIT
GO

Making a Database for a CD

In SQL Server 2000 and 2005, you can create what Microsoft calls a "Removable Database." This is an entire database, configured and set up for distribution on a CD.

To create a removable database, you use a different command to create the database than CREATE DATABASE. Instead, you use the sp_create_removable stored procedure. It basically locks the data files, but places the data required for adding users and so on in a writable area. You can read more about that here.

This option is slated for removal in SQL Server versions after 2005, so this isn't something you should create now as a future practice, but it is kind of interesting to see.

Database Maintenance on Read-Only Data

Backups don't just take a backup of the database — they also make various changes to the system tables to indicate state and to track the dates and times of the backups. Of course, when things are Read-Only this is more of an issue.

If you leave the entire database in Read-Only mode, then you have some special considerations for backups. As long as it stays in Read-Only mode, then you'll need to take a full database backup. If you want to take a differential or another type of backup, set the database to Read/Write and then do the other type of backup — and backup the master database right away.

Also, you need to modify your other maintenance to ensure that it doesn't try to run against any read-only data, since that data can't be changed. I've got a pointer to more information on that in the Online References section.

InformIT Articles and Sample Chapters

Sometimes you don't really need a read-only data set, you want a reporting system. You can find out more here.

Online Resources

There's more on read-only database maintenance here.