The Real MTCS SQL Server 2008 Exam 70/432 Prep Kit- P128 docx

Configuring & Implementing… Minimally Logged Operations and the Database Recovery Model Earlier examples in this chapter have made use of INSERT, UPDATE, and DELETE DML statements.. Th

When preparing for the exam, ensure you have practiced using the CREATE,

ALTER, and DROP DDL statements and have achieved a good understanding of

the DDL syntax The AdventureWorks sample database is a great tool for learning

Transact-SQL without the risk of damaging your live databases Exercises in this

chapter are based on the AdventureWorks database Perform all exercises to get

hands-on experience in writing and executing DDL queries

Configuring & Implementing…

Minimally Logged Operations

and the Database Recovery Model

Earlier examples in this chapter have made use of INSERT, UPDATE, and

DELETE DML statements These DML operations (as well as the MERGE

statement) are logged operations When an operation is logged, data

about the operation is stored in the SQL Server transaction log The

trans-action log files can be backed up and replayed into an earlier database

backup Although the log replay functionality is slow, it allows you to

restore the database to the point in time when the database file was

lost.

For performance reasons, some operations that affect SQL Server

data can be performed as nonlogged or minimally logged This means

that the information about these operations is not fully recorded in the

SQL Server transaction log Nonlogged operations offer much better

per-formance than logged operations If a nonlogged operation occurs after

the database has been backed up, you will not be able to replay the logs

into the database after you have restored the database from backup.

The following DML operations are either nonlogged or minimally

logged, depending on database recovery model:

■

■ TRUNCATE TABLE.

■

■ WRITETEXT and UPDATETEXT These statements are deprecated

and should not be used Use column.Write instead.

■

■ SELECT INTO.

Continued

You cannot use these statements when publishing tables as part of replication The selected database recovery model determines what trans-actions are recorded in the transaction log Three recovery models are available for SQL Server 2008 databases:

Simple recovery model

■

■

Full recovery model

■

■

Bulk-Logged recovery model

■

■

When the database recovery model is set to Simple, log files are reused as soon as they become full This means that the transaction logs use up very little space, and you don’t need to worry about log file management However, when a database is set to the Simple recovery model and the database file is lost, you will not be able to recover any changes made after the last full backup You will also not be able to recover to a point-in time, as transaction details are stored in transaction logs that have been overwritten in this case.

The Full recovery model could be said to be the opposite of the Simple recovery model Transaction logs are kept, and all transactions without exception are written to the logs This includes nonlogged

operations like TRUNCATE TABLE and SELECT…INTO Although you lose

the performance advantages of nonlogged operations with this recovery model, all data is recoverable provided transaction logs are intact You can also restore to a point in time if necessary.

The Bulk-Logged recovery model is similar to the Full recovery model, except that nonlogged operations are performed as nonlogged This pro-vides a performance advantage for Logged operations If a Bulk-Logged operation has occurred since the last full backup, you will not be able to recover any changes made since the last full backup The Bulk-Logged recovery model does not support point-in-time recovery.

In production environments, the full database recovery model is gen-erally used, as it ensures maximum recoverability If you wish to perform

a high-performance nonlogged operation, you can temporarily switch the recovery model to Bulk-Logged, perform the operation, switch the recovery model back to Full, and perform a full backup The Full recovery model is the default when creating databases in SQL Server.

Working with Tables and Views

Tables are the database objects that store data in a SQL Server database Tables are

structured as columns and rows, like a spreadsheet The columns define the type and

length of data they can store Every table must have at least one column Column

names must be unique within a table; that is, you cannot specify ProductName

column to appear twice in the Product table Tables store the underlying data within

the MDF and NDF data files as pages and extents (These are discussed in more

detail in Chapter 7.) Columns are sometimes associated with constraints, for example,

PRIMARY KEY, UNIQUE, or DEFAULT Types of constraints will be explained

later in this chapter You can also mark columns with the following special attributes:

■

■ Identity Columns Values for these columns are generated automatically

in sequence by incrementing every time a row is added Usually, values

1, 2, 3, n are used, but you can define your own seed (starting value) and

increment value for the identity column

■

■ Computed Columns These columns do not store any data; instead, they

define a formula that calculates the column value at query time

■

■ Timestamp Columns These columns are used as a mechanism for

version-stamping table rows and tracking changes

■

■ Uniqueidentifier Columns These columns store Globally Unique

Identifiers (GUID) GUID values are used for replication and are

guaran-teed to be unique

When defining columns for a new or existing table, you can specify column

null-ibility A column is said to be nullible if it allows storing null (empty) values You can

choose to mark a column as not nullible If anyone attempts to insert a NULL value

into this column, an error will be raised, and the INSERT operation will fail.

Creating Tables

Tables can be created and modified using the SQL Server Management Studio table

designer or the CREATE TABLE or ALTER TABLE statements To access the SQL

Server Management Studio graphical table designer, in Object Explorer expand the

database in you wish to create the table Then, right-click Tables and click New

Table To modify an existing table, right-click it and then click Design The table

designer shows the columns that will be created for your table at the top and the

properties of the selected column in the Column Properties pane, usually located

at the bottom of the screen Figure 14.2 shows the use of SQL Server Management

Studio to create a new table

To create a table using DDL, use the CREATE TABLE statement along with

the syntax shown in Example 14.4

Example 14.4 CREATE TABLE Statement—Syntax

CREATE TABLE [database_name].[schema_name].table_name

(column1_name data_type [NULL | NOT NULL] | [PRIMARY KEY] | [IDENTITY], Column2_name data_type [NULL | NOT NULL],

[<computed_column_definition>]

In this statement, the table_name is the name of the table you wish to create When defining columns, you can specify whether or not they will allow NULL values You can also state that a column will be designated as the PRIMARY KEY

for the table and whether it will contain automatically incrementing values,

known as IDENTITY columns The computed_column_definition is the formula for

a calculated column When defining columns, you must designate a data type, like varchar or int, and in some cases a length

Figure 14.2 Using the SQL Server Management Studio Table Designer

Table 14.1 summarizes built-in data types that are available to you when you

are defining columns

Image

Table 14.1 Built-In Data Types

Some of the data types shown in the table also allow you to specify the length

or precision for the data stored in the column you are creating For example,

a column of type char(1000) allows you to store up to 1000 characters per row

A column of type decimal(10) allows you to store up to 10 digits on either side of

the decimal point, while decimal(10,5) allows you to store numbers of up to 10

digits with up to 5 digits to the right of the decimal point Variable-length data

types, like varchar, nvarchar, and varbinary, consume only the space that the characters stored in the column take up Fixed-length equivalents of char, nchar, and binary

consume a fixed amount of space regardless of the amount of actual data contained

in the column Data types prefixed with “n”—nvarchar and nchar—store Unicode

text and can be used to store characters from multiple languages in one column

Creating User-Defined Data Types

Sometimes you need to create your own data types that are based on the built-in

data types introduced earlier Custom data types are also known as user-defined data

types (UDFs) UDFs are especially useful when you must store the data with the

same length or precision over and over again For example, you can create a new