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

ImplementingObjects•Chapter14 617 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 618 Chapter14•ImplementingObjects 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 Bulk-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. ImplementingObjects•Chapter14 619 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. 620 Chapter14•ImplementingObjects 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 ImplementingObjects•Chapter14 621 Table 14.1 summarizes built-in data types that are available to you when you are defining columns. Numeric Character Dates and Times Other Tinyint Char Datetime Binary Smallint Nchar Smalldatetime Bit Int Varchar Date Cursor Bigint Nvarchar Datetime2 Xml Smallmoney Text Datetimeoffet Smalldatetime Money Ntext Time Varbinary Decimal Timestamp Uniqueidentifier Double Hierarchyid Float Rowversion Real Sql_variant 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 . 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. Rowversion Real Sql_ variant 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. 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