Attaching and Detaching Databases Detaching/attaching is used in moving a database between computers or physical disks. When a database is detached, the links from the server to the data files and transaction logs are removed. When you attach a database, you re-establish those links. When you detach and re-attach, you eliminate the need to restore the database backup manually. When a database is reattached, all files that have changed location must be specified.

Filegroups Filegroups are database files that have been grouped together for administrative purposes only. There are times when filegroup organization can increase performance, but that is not the primary goal of the filegroup. Filegroups are useful because they increase the flexibility of the database as a whole. Filegroups allow an administrator to partially back up a database. Filegroups also allow greater fault tolerance by granting the ability to spread the database over several physical disks. The filegroup that contains the primary data file is called the primary filegroup. While other, user defined filegroups can be created, the primary filegroup is the default unless explicitly changed. Also, unless explicitly specified, all files will be placed in the default filegroup. Unless explicitly specified when a database is created, the database will grow as large as necessary until disk space is physically exhausted. Filegroups can be assigned a maximum size and a growth rate that determines how much they will grow when their current space is exhausted. These attributes can be established during filegroup creation and can be changed after the filegroup is created.

Expanding and Shrinking a Database When a database is created, it is assigned a maximum size and an automatic growth rate to use when the initial file size is exceeded. A database can be manually expanded or shrunk once it has been created. The CREATE DATABASE Command The CREATE DATABASE statement allows you to establish many of the options on a database during its creation. The syntax for the CREATE DATABASE statement is as follows:

The CREATE DATABASE Command
The CREATE DATABASE statement allows you to establish many of the options on a database during its creation. The syntax for the CREATE DATABASE statement is as follows:

CREATE DATABASE <database_name>
[ON <filegroup_name>
NAME = <filename_1>,
FILENAME = 'drive:\directory\filename.mdf',
SIZE = <initial size in MB>,
MAXSIZE = <maximum size in MB>,
FILEGROWTH = <size in MB to add >
]

The ALTER DATABASE Command
The ALTER DATABASE command is used to change a data file after it has been created. The syntax for the ALTER DATABASE statement is as follows:

ALTER DATABASE <database_name>
{ ADD FILE [TO FILEGROUP filegroup] [FOR RESTORE]
(FILENAME = 'drive:\directory\filename.mdf'
SIZE = <Size in MB>
MAXSIZE = <size in MB>
FILEGROWTH = <size in MB to add>
TO FILEGROUP <filegroup_name>
}

The ADD FILE can also be replaced with the following statements to achieve the following results:

Statement Purpose

ADD LOG FILE Add a log file to the database
REMOVE FILE Remove a data, transaction, or log file from a database
ADD FILEGROUP Add a filegroup to a database
REMOVE FILEGROUP Remove a filegroup from a database
MODIFY FILE Change the attributes (SIZE, MAXSIZE, or FILEGROWTH) of a file in the database
MODIFY FILEGROUP Change the changes the properties on a specified filegroup (READONLY, READWRITE, DEFAULT)

Transaction Logs A transaction log records all changes made to a database and allows changes to be rolled back or forward in the event of a system failure or in the case of an erroneous entry. The transaction log is associated with the data files when the database is created. The transaction log actually consists of several files that exactly describe the changes made to the database. These files are treated by the database as one file for the purposes of space and placement.

There comes a point when old log records are no longer needed for recovering or restoring a database and must be deleted to make room for new log records. The process of deleting these log records is called truncating the log.

If possible, transaction logs should be placed on a different physical disk than the data files. This placement will increase performance by removing competition for hard drive access time from the transaction logs and the data files.

Write-Ahead Transaction Log SQL Server 2000 uses a write-ahead log. A write-ahead log ensures that no data modifications are written to disk before the associated log record. SQL Server 2000 maintains a buffer cache into which it reads data pages. Data modifications are not made directly to disk, but to the copy of the page in the buffer cache. The modification is not written to disk until the lazywriter process schedules a write for the page.

At the time a modification is made to a page in the buffer, a log record is built in the log cache recording the modification. This log record must be written to disk before the associated dirty page is flushed from the buffer cache to disk. If the dirty page were flushed before the log record, it would create a modification on disk that could not be rolled back if the server failed before the log record were written to disk. SQL Server has logic that prevents a dirty page from being flushed before the associated log record. Because log records are always written ahead of the associated data pages, the log is called a write-ahead log.

Managing Database Objects

Tables are database objects that contain all data in a database. Tables organize data into a row and column format where each row represents a unique record and each column represents a field in that record. Tables are created by the CREATE TABLE command. Changes to a table can be made using the ALTER TABLE command.

Indexes are objects that are associated with tables that speed the retrieval of rows in the table containing keys that have been built from one or more columns in a table. Indexes come in two varieties, clustered and nonclustered. A clustered index sorts and stores rows of data in a table based on the key values. Nonclustered indexes do not affect how data rows are sorted in a table. Nonclustered indexes contain values that point to rows in the indexed table.

Constraints are conditions placed on data entered into a column that are meant to ensure data integrity. Generally constraints are placed on the column designated as the primary key. Constraints are by no means exclusive to the primary key column but they are a useful way to ensure that all row values in the primary key column are unique.

A foreign key is a column that is used to establish and enforce a link between data in two tables. Foreign key constraints are used to maintain referential integrity between tables by controlling the data that can be entered and the changes made to foreign keys in referring tables.

Stored Procedures are collections of SQL statements residing on the server that can be executed by users to achieve a desired goal. Stored procedures can have values or variables that can be passed to them by the user or the system that they can act upon. Since they are located on the server, stored procedures can greatly increase performance as there is only one authentication, the authentication for the initial execution of the stored procedure, for all the commands that are executed. You can nest stored procedures and can call other procedures within the body of a stored procedure. Stored procedures are useful in implementing consistent logic across applications. In a stored procedure SQL statements and logic needed to perform a commonly performed task can be designed, coded, and tested once. Each application needing to perform that task can then simply execute the stored procedure. A structure using a stored procedure offers a single point of control for control of business processes.

Triggers are stored procedures that are activated on an event driven basis, instead of being explicitly called. Triggers are typically used to maintain data integrity, cascade referential actions, or to utilize external resources (e.g. send an e-mail, notify a pager, etc.). There are two types of triggers; AFTER triggers and instead-of triggers.

AFTER Triggers The default type of trigger is the AFTER trigger. On a table there can be multiple triggers defined for an event. You can designate the first and last triggers to fire but you cannot control the order that any other triggers will fire.

INSTEAD OF Triggers INSTEAD OF triggers are set up to specify the action to take when data is modified. INSTEAD OF triggers must be explicitly declared as instead-of or they will default to AFTER triggers. You can only have one IN STEAD OF trigger for each action.

Views A view is a filter that dynamically interprets information in one or more tables and creates a composite table that other operations can be performed upon. Rows can be updated, deleted, or inserted from views. A view is not an actual table, but it is presented in table format.